【文章內(nèi)容簡介】 body = ()。 (subname1,subvalue1)。 (subname2,subvalue2)。 IMessageItem item1 = (”item1”)。 (subsubname11,subsubvalue11)。 (subsubname12,subsubvalue12)。 //Send Request Message MyServiceClient service = new MyServiceClient(Client)。 (message)。 我們在客戶端引入了一個(gè) ServiceLocator 對象，它通過 MessageQueueListener 對消息隊(duì)列進(jìn)行偵聽，一旦接收到消息，就獲取該消息中的 name 去定位它所對應(yīng)的服務(wù)，然后調(diào)用服務(wù)的Execute(aMessage)方法，執(zhí)行相關(guān)的業(yè)務(wù)。 ServiceLocator 承擔(dān)的定位職責(zé)其實(shí)是對存儲在 ServiceContainer 容器中的服務(wù)進(jìn)行查詢。 ServiceContainer 容器可以讀取配置文件，在啟動服務(wù)的時(shí)候初始化所有的分布式服務(wù)（注意，這些服務(wù)都是無狀態(tài)的），并對這些服務(wù)進(jìn)行管 理。它封裝了服務(wù)的基本信息，諸如服務(wù)所在的位置，服務(wù)的部署方式等，從而避免服務(wù)的調(diào)用者直接依賴于服務(wù)的細(xì)節(jié)，既減輕了調(diào)用者的負(fù)擔(dān)，還能夠較好地實(shí) 現(xiàn)服務(wù)的擴(kuò)展與遷移。 在這個(gè)系統(tǒng)中，我們主要引入了 Messaging 模式，通過定義的 IMessage 接口，使得我們更好地對服務(wù)進(jìn)行抽象，并以一種扁平的格式存儲數(shù) 據(jù)信息，從而解除服務(wù)之間的耦合。只要各個(gè)服務(wù)就共用的消息格式達(dá)成一致，請求者就可以不依賴于接收者的具體接口。通過引入的Message 對象，我們就 可以建立一種在行業(yè)中通用的消息模型與分布式服務(wù)模型。事實(shí)上 ，基于這樣的一個(gè)框架與平臺，在對制造行業(yè)的業(yè)務(wù)進(jìn)行開發(fā)時(shí)，開發(fā)人員最主要的活動是與領(lǐng)域 專家就各種業(yè)務(wù)的消息格式進(jìn)行討論，這樣一種面向領(lǐng)域的消息語言，很好地掃清了技術(shù)人員與業(yè)務(wù)人員的溝通障礙；同時(shí)在各個(gè)子系統(tǒng)之間，我們也只需要維護(hù)服 務(wù)間相互傳遞的消息接口表。每個(gè)服務(wù)的實(shí)現(xiàn)都是完全隔離的，有效地做到了對業(yè)務(wù)知識與基礎(chǔ)設(shè)施的合理封裝與隔離。 對于消息的格式和內(nèi)容，我們考慮引入了 Message Translator 模式，負(fù)責(zé)對前面定義的消息結(jié)構(gòu)進(jìn)行翻譯和解析。為了進(jìn)一步減輕開發(fā)人員的負(fù)擔(dān)，我們還可以基于該平臺搭 建一個(gè)消息 對象 關(guān)系的映 射框架，引入實(shí)體引擎（ Entity Engine）將消息轉(zhuǎn)換為領(lǐng)域?qū)嶓w，使得服務(wù)的開發(fā)者能夠以完全面向?qū)ο蟮乃枷腴_發(fā)各個(gè)服務(wù)組件，并通過調(diào)用持久層實(shí)現(xiàn)消息數(shù)據(jù)的持久化。同時(shí)，利用消 息總線（此時(shí)的消息總線可以看做是各個(gè)服務(wù)組件的連接器）連接不同的服務(wù)，并允許異步地傳遞消息，對消息進(jìn)行編碼。這樣一個(gè)基于消息的分布式架構(gòu)如圖 7 所 示： 圖 7 基于 Message Bus 的 CIMS 分布式架構(gòu) 場景二：消息中間件的架構(gòu)決策 在一個(gè)醫(yī)療衛(wèi)生系統(tǒng)中，我們面臨了客戶對系統(tǒng)性能 /可用性的非功能 需求。在我們最初啟動該項(xiàng)目時(shí)，客戶就表達(dá)了對性能與可用性的特別關(guān)注?？蛻粝Ｍ? 最終用戶在進(jìn)行復(fù)雜的替換刪除操作時(shí)，能夠具有很好的用戶體驗(yàn)，簡言之，就是希望能夠快速地得到操作的響應(yīng)。問題在于這樣的替換刪除操作需要處理比較復(fù)雜 的業(yè)務(wù)邏輯，同時(shí)牽涉到的關(guān)聯(lián)數(shù)據(jù)量非常大，整個(gè)操作若需完成，最壞情況下可能需要幾分鐘的時(shí)間。我們可以通過引入緩存、索引、分頁等多種方式對數(shù)據(jù)庫操 作進(jìn)行性能調(diào)優(yōu)，但整個(gè)操作的耗時(shí)始終無法達(dá)到客戶的要求。由于該系統(tǒng)是在一個(gè)遺留系統(tǒng)的基礎(chǔ)上開發(fā)，如果要引入 MapReduce 來處理這些操作， 以 滿足質(zhì)量需求，則對架構(gòu)的影響太大，且不能很好地重用之前系統(tǒng)的某些組件。顯然，付出的成本與收益并不成正比。 通過對需求進(jìn)行分析，我們注意到最終客戶并不需要實(shí)時(shí)獲得結(jié)果，只要能夠保證最終結(jié)果的一致性和完整性即可。關(guān)鍵在于就用戶體驗(yàn)而言，他們不希望經(jīng)歷漫長的等待，然后再通知他們操作究竟是成功還是失敗。這是一個(gè)典型需要通過后臺任務(wù)進(jìn)行異步處理的場景。 在企業(yè)應(yīng)用系統(tǒng)中，我們常常會遭遇這樣的場景。我們曾經(jīng)在一個(gè)金融系統(tǒng)中嘗試通過自己編寫任務(wù)的方式來控制后臺線程的并發(fā)訪問，并完成對任務(wù)的調(diào)度。事實(shí)證明，這樣的設(shè)計(jì)并非行之有效。對于這種典型的異步處理來說，基于消息傳遞的架構(gòu)模式才是解決這一問題的最佳辦法。 因?yàn)橄⒅虚g件的逐步成熟，對于這一問題的架構(gòu)設(shè)計(jì)，已經(jīng)由原來對設(shè)計(jì)實(shí)現(xiàn)的關(guān)注轉(zhuǎn)為如何進(jìn)行產(chǎn)品選型和技術(shù)決策。 通過分析業(yè)務(wù)場景以及客戶性質(zhì)，我們發(fā)現(xiàn)該業(yè)務(wù)場景具有如下特征： ? 在一些特定情形下，可能會集中發(fā)生批量的替 換 刪除操作，使得操作的并發(fā)量達(dá)到高峰；例如 FDA 要求召回一些 違規(guī) 藥品 時(shí) ，就需要?jiǎng)h除藥品 庫 中該 藥品的信息； ? 操作 結(jié) 果不要求實(shí) 時(shí) 性，但需要保 證 操作的可靠性，不能因 為 異常失 敗 而導(dǎo) 致某些操作無法 進(jìn) 行； ? 自動操作的 過 程是不可逆 轉(zhuǎn) 的，因此需要 記錄 操作 歷 史； ? 基于性能考 慮 ，大多 數(shù) 操作需要 調(diào) 用 數(shù) 據(jù) 庫 的存 儲過 程； ? 操作的 數(shù) 據(jù)需要具備一定的安全性，避免被非法用戶 對數(shù) 據(jù)造成破壞； ? 與操作相 關(guān) 的功能以 組 件形式封裝，保 證組 件的可重用性 、 可 擴(kuò) 展性與可測試 性； ? 數(shù) 據(jù)量可能隨著最 終 用戶的增多而逐 漸 增大； 針對如上的業(yè)務(wù)需求，我們決定從以下幾個(gè)方面對各種技術(shù)方案進(jìn)行橫向的比較與考量。 ? 并發(fā)： 選擇 的消息 隊(duì) 列一定要很好地支持用戶 訪問 的并發(fā)性； ? 安全：消息 隊(duì) 列是否提供了足夠的安全機(jī)制； ? 性能伸 縮 ：不能 讓 消息 隊(duì) 列成 為 整個(gè)系統(tǒng)的 單 一性能瓶 頸 ； ? 部署： 盡 可能 讓 消息 隊(duì) 列的部署更 為 容易； ? 災(zāi)備：不能因 為 意外的 錯(cuò)誤 、 故障或其他因素 導(dǎo) 致處理 數(shù) 據(jù)的 丟 失； ? API 易用性：處理消息的 API 必 須 足夠 簡單 、 并能夠很好地支持 測試 與 擴(kuò)展； 我們先后考察了 MSMQ、 Resque、 ActiveMQ 和 RabbitMQ，通過查詢相關(guān)資料，以及編寫Spike 代碼驗(yàn)證相關(guān)質(zhì)量，我們最終選擇了 RabbitMQ。 我們選擇放棄 MSMQ，是因?yàn)樗鼑?yán)重依賴 Windows 操作系統(tǒng)；它雖然提供了易用的 GUI 方便管理人員對其進(jìn)行安裝和部署，但若要編寫自動化部署 腳本，卻非常困難。同時(shí)， MSMQ 的隊(duì)