高并發(fā)性能的軟件開發(fā)架構(gòu)設(shè)計(jì)咨詢-資料下載頁(yè)
2025-06-04 21:04本頁(yè)面
【正文】 if (response != null) { var serializer = new JavaScriptSerializer()。 var json = ()。 returnVal = T(json)。 } } return returnVal。 } } 我們用 來實(shí)現(xiàn) Batch Job。通過定義一個(gè)實(shí)現(xiàn)了 IStatefulJob 接口的 Job 類，在Execute()方法中完成對(duì)隊(duì)列的偵聽。 Job中 RabbitMQSubscriber類的 ListenTo()方法會(huì)調(diào)用 Queue的 Dequeue()方法，當(dāng)接收的消息到達(dá)隊(duì)列時(shí)， Job 會(huì)偵聽到 消息達(dá)到的事件，然后以同步的方式使得消息彈出隊(duì)列，并將消息作為參數(shù)傳遞給 Action 委托。因此，在 Batch Job 的 Execute()方法中，可以定義消息處理的方法，并調(diào)用 RabbitMQSubscriber 類的 ListenTo()方法，如下所示（注 意，這里傳遞的消息 事實(shí)上是 Job 的 Id）： public void Execute(JobExecutionContext context) { string queueName = ().。 try { MyJob( queueName, job = (()))。 } catch(Exception err) { (Unexpected exception while processing queue 39。{0}39。, Details: {1}, queueName, err)。 } } 隊(duì)列的相關(guān)信息例如隊(duì)列名都存儲(chǔ)在配置文件中。 Execute()方法調(diào)用了 request 對(duì)象的MakeRequest()方法，并將獲得的消息（即 JobId）傳遞給該方法。它會(huì)根據(jù) JobId 到數(shù)據(jù)庫(kù)中查詢?cè)?Job 對(duì)應(yīng)的信息，并執(zhí)行真正的業(yè)務(wù)處理。 在對(duì)基于消息處理的架構(gòu)進(jìn)行決策時(shí)，除了前面提到的考慮因素外，還需要就許多設(shè)計(jì)細(xì)節(jié)進(jìn)行多方位的判斷與權(quán)衡。例如針對(duì) Job 的執(zhí)行以及隊(duì)列的管理，就需要考慮如下因素： ? 對(duì) Queue 中 Job 狀態(tài) 的 監(jiān) 控與查詢； ? 對(duì) Job 優(yōu)先 級(jí) 的管理； ? 能否取消或 終 止 執(zhí) 行 時(shí) 間 過 長(zhǎng)的 Job； ? 是 否能夠設(shè)定 Job 的 執(zhí) 行 時(shí) 間； ? 是否能夠設(shè)定 Poll 的間隔 時(shí) 間； ? 能否跨機(jī)器分布式的放入 Job； ? 對(duì) 失 敗 Job 的處理； ? 能否支持多個(gè) 隊(duì) 列，命名 隊(duì) 列； ? 能否允 許執(zhí) 行 Job 的工作 進(jìn) 程 對(duì)應(yīng) 特定的 隊(duì) 列； ? 對(duì) Dead Message 的支持 。 選擇的時(shí)機(jī) 究竟在什么時(shí)候，我們應(yīng)該選擇基于消息處理的分布式架構(gòu)？根據(jù)我參與的多個(gè)企業(yè)應(yīng)用系統(tǒng)的經(jīng)驗(yàn)，竊以為需要滿足如下幾個(gè)條件： ? 對(duì) 操作的實(shí) 時(shí) 性要求不高，而需要 執(zhí) 行的任務(wù)極 為 耗 時(shí) ； ? 存在企業(yè) 內(nèi) 部的異構(gòu)系統(tǒng)間的整合； ? 服務(wù)器 資 源需要合理分配與利用； 對(duì)于第一種情況，我們常常會(huì)選擇消息隊(duì)列來處理執(zhí)行時(shí)間較長(zhǎng)的任務(wù)。此時(shí)引入的消息隊(duì)列就成了消息處理的緩沖區(qū)。消息隊(duì)列引入的異步通信機(jī)制，使得 發(fā)送方和接收方都不用等待對(duì)方返回成功消息，就可以繼續(xù)執(zhí)行下面的代碼，從而提高了數(shù)據(jù)處理的能力。尤其是當(dāng)訪問量和數(shù)據(jù)流量較大的情況下，就可以結(jié)合消 息隊(duì)列與后臺(tái)任務(wù)，通過避開高峰期對(duì)大數(shù)據(jù)進(jìn)行處理，就可以有效降低數(shù)據(jù)庫(kù)處理數(shù)據(jù)的負(fù)荷。前面提到的醫(yī)療衛(wèi)生系統(tǒng)正是這樣一種適用場(chǎng)景。 對(duì)于不同系統(tǒng)乃至于異構(gòu)系統(tǒng)的整合，恰恰是消息模式善于處理的場(chǎng)景。只要規(guī)定了消息的格式與傳遞方式 ，就可以有效地實(shí)現(xiàn)不同系統(tǒng)之間的通信。在為某 汽車制造商開發(fā)一個(gè)大型系統(tǒng)時(shí)，分銷商作為 .NET客戶端，需要將數(shù)據(jù)傳遞到管理中心。這些數(shù)據(jù)將被 Oracle 的 EBS（ EBusiness Suite）使用。分銷商管理系統(tǒng)（ Dealer Management System， DMS）采用了 C/S 結(jié)構(gòu)，數(shù)據(jù)庫(kù)為 SQL Server，汽車制造商管理中心的 EBS 數(shù)據(jù)庫(kù)為 Oracle 10g。我們需要解決兩種不同數(shù)據(jù)庫(kù)間數(shù)據(jù)的傳遞。解決方案就是利用 MSMQ，將數(shù)據(jù)轉(zhuǎn)換為與數(shù)據(jù)庫(kù)無關(guān)的消息數(shù)據(jù)，并在兩端部署 MSMQ 服務(wù)器，建 立消 息隊(duì)列以便于存儲(chǔ)消息數(shù)據(jù)。實(shí)現(xiàn)架構(gòu)如圖 9 所示。 圖 10 利用 MSMQ 實(shí)現(xiàn)的分布式處理架構(gòu) 首先，分銷商的數(shù)據(jù)通過 MSMQ 傳遞到 MSMQ Server，再將數(shù)據(jù)插入到 SQL Server 數(shù)據(jù)庫(kù)的同時(shí)，利用 FTP 將數(shù)據(jù)傳送到專門的文件服務(wù)器上。 EBS App Server 會(huì)將文件服務(wù)器中的文件，基于接口規(guī)范寫入到 Oracle 數(shù)據(jù)庫(kù)，從而實(shí)現(xiàn) .NET系統(tǒng)與 Oracle 系統(tǒng)之間的整合。 分布式系統(tǒng)通常能夠緩解單個(gè)服務(wù)器的壓力，通過將不同的業(yè)務(wù)操作與數(shù)據(jù)處理以不同的服務(wù)形式部署并運(yùn)行在不同的服務(wù)器上，就可以 有效地分配與利用服 務(wù)器資源。在這種情況下，部署在不同服務(wù)器上的服務(wù)，既可能作為服務(wù)端，用以處理客戶端調(diào)用的請(qǐng)求，也可能作為客戶端，在處理完自己的業(yè)務(wù)后，將其余業(yè)務(wù) 請(qǐng)求委派給其他服務(wù)。在早期的 CORBA系統(tǒng)中，通過建立統(tǒng)一的 Naming Service，用以管理和分派服務(wù)，并通過 Event Service 實(shí)現(xiàn)事件的分發(fā)與處理。但 CORBA系統(tǒng)采用的是 RPC 的方式，需要將服務(wù)設(shè)計(jì)和部署為遠(yuǎn)程對(duì)象，并建立代理。如果通過消息通道的方式，則 既可以解除這種對(duì)遠(yuǎn)程對(duì)象的依賴，又可以很好地支持異步調(diào)用模型。在前面提到 的 CIMS 系統(tǒng)，就是通過消息總線提供消息傳遞的基礎(chǔ)設(shè)施，并建立統(tǒng)一的消息 處理服務(wù)模型，解除服務(wù)見的依賴，使得各個(gè)服務(wù)能夠獨(dú)立地部署到不同服務(wù)器上。
畢業(yè)設(shè)計(jì)相關(guān)推薦
鄂ICP備17016276號(hào)-1