導(dǎo)語：消息中間件在郵政電子商務(wù)平臺(tái)的應(yīng)用一文來源于網(wǎng)友上傳，不代表本站觀點(diǎn)，若需要原創(chuàng)文章可咨詢客服老師，歡迎參考。

摘要：通過對(duì)郵政電子商務(wù)平臺(tái)系統(tǒng)架構(gòu)及RocketMQ消息中間件技術(shù)的分析，提出對(duì)平臺(tái)架構(gòu)進(jìn)行優(yōu)化設(shè)計(jì)，利用消息中間件實(shí)現(xiàn)系統(tǒng)模塊之間的解耦合，減少相互依賴的建議。

關(guān)鍵詞：RocketMQ；消息中間件；電子商務(wù)平臺(tái)；集群郵政

電子商務(wù)平臺(tái)業(yè)務(wù)受理的一個(gè)重要特征是全天營(yíng)業(yè)，實(shí)時(shí)交易占比高，接入渠道豐富，對(duì)接第三方系統(tǒng)繁多。電子商務(wù)的業(yè)務(wù)特點(diǎn)決定了系統(tǒng)在響應(yīng)時(shí)間上必須滿足要求，以達(dá)到更好的客戶體驗(yàn)，確保交易完整性。對(duì)于平臺(tái)自有系統(tǒng)，可以通過邏輯優(yōu)化，盡可能避免延時(shí)，但是第三方系統(tǒng)的延時(shí)則不可控，通常無法干預(yù)其系統(tǒng)優(yōu)化。本文描述了消息中間件技術(shù)在省郵政電子商務(wù)平臺(tái)上的應(yīng)用，實(shí)現(xiàn)平臺(tái)交易模塊的解耦合，減少模塊處理延時(shí)的疊加效應(yīng)，提高平臺(tái)的響應(yīng)速度，提升客戶體驗(yàn)。

1消息中間件的選型分析

隨著企業(yè)信息化建設(shè)的不斷深入，多種業(yè)務(wù)應(yīng)用相互關(guān)聯(lián)，容易造成底層數(shù)據(jù)分散，應(yīng)用系統(tǒng)間的耦合度高。消息中間件技術(shù)有兩個(gè)核心功能：異步和解耦。這兩個(gè)核心功能可對(duì)不同系統(tǒng)間的交互進(jìn)行解耦，總體上提高應(yīng)用系統(tǒng)的工作效率，增強(qiáng)系統(tǒng)的可用性、穩(wěn)定性和可擴(kuò)展性。消息隊(duì)列已經(jīng)逐漸成為企業(yè)IT系統(tǒng)內(nèi)部通信的核心手段，可以在分布式環(huán)境下提供應(yīng)用解耦、彈性伸縮、冗余存儲(chǔ)、流量削峰、異步通信、數(shù)據(jù)同步等功能。常用消息中間件相關(guān)特點(diǎn)及對(duì)比如表1所示。系統(tǒng)在技術(shù)選型上包含以下幾方面考量：一是系統(tǒng)要保證數(shù)據(jù)的完整性，因此選用的中間件應(yīng)該支持事務(wù)處理，并保證交易數(shù)據(jù)不會(huì)丟失；二是某些業(yè)務(wù)場(chǎng)景會(huì)引起高并發(fā)交易，因此中間件應(yīng)具備應(yīng)對(duì)突發(fā)業(yè)務(wù)高峰的處理能力；三是省平臺(tái)選型應(yīng)與集團(tuán)平臺(tái)所用技術(shù)保持一致；四是優(yōu)先選擇支持云部署的產(chǎn)品。綜上分析，對(duì)比常用中間件的技術(shù)特點(diǎn)，最終選擇RocketMQ作為本次應(yīng)用的消息中間件。

2RocketMQ技術(shù)簡(jiǎn)介

RocketMQ是阿里開源的消息中間件，目前歸屬于Apache頂級(jí)項(xiàng)目，它是純Java開發(fā)，具有高吞吐量、高可用性、適合大規(guī)模分布式系統(tǒng)應(yīng)用的特點(diǎn)。RocketMQ集群包含4個(gè)模塊：Namesrv、Broker、Producer、Consumer。Namesrv存儲(chǔ)當(dāng)前集群所有Brokers信息、Topic與Broker的對(duì)應(yīng)關(guān)系，功能簡(jiǎn)單，穩(wěn)定性高。多個(gè)Namesrv之間相互沒有通信，單臺(tái)Namesrv宕機(jī)不影響其他Namesrv與集群。Broker是集群最核心的模塊，主要負(fù)責(zé)Topic消息存儲(chǔ)、消費(fèi)者的消費(fèi)位點(diǎn)管理（消費(fèi)進(jìn)度），可理解為RocketMQ服務(wù)的注冊(cè)中心。Producer是消息生產(chǎn)者，每個(gè)生產(chǎn)者都有一個(gè)ID（編號(hào)），多個(gè)生產(chǎn)者實(shí)例可以共用一個(gè)ID，同一個(gè)ID下所有實(shí)例組成一個(gè)生產(chǎn)者集群。生產(chǎn)者通過Namesrv獲取Topic與Broker的映射關(guān)系，更新到本地內(nèi)存中，再和Topic涉及的所有Broker建立長(zhǎng)連接。Consumer是消息消費(fèi)者，每個(gè)訂閱者也有一個(gè)ID，多個(gè)消費(fèi)者實(shí)例可以共用一個(gè)ID，同一個(gè)ID下所有實(shí)例組成一個(gè)消費(fèi)者集群。消費(fèi)者通過Namesrv獲取當(dāng)前消費(fèi)Topic所涉及的Broker，直連Broker。

3郵政電子商務(wù)平臺(tái)架構(gòu)分析及優(yōu)化

3.1平臺(tái)架構(gòu)分析。郵政電子商務(wù)平臺(tái)架構(gòu)如圖1所示，業(yè)務(wù)受理交易通過各渠道系統(tǒng)的渠道前置子系統(tǒng)接入核心應(yīng)用子系統(tǒng)，核心應(yīng)用分配一個(gè)服務(wù)進(jìn)程處理，再調(diào)用外聯(lián)前置，將交易請(qǐng)求轉(zhuǎn)發(fā)至第三方。整個(gè)交易過程串行，每個(gè)子系統(tǒng)的處理時(shí)間疊加則為整個(gè)交易的處理時(shí)間，任意環(huán)節(jié)出現(xiàn)延時(shí)，都會(huì)在整個(gè)交易的處理時(shí)間上產(chǎn)生疊加效應(yīng)。對(duì)于本地系統(tǒng)，可以通過對(duì)各子系統(tǒng)的優(yōu)化處理，減少延時(shí)，但對(duì)于第三方系統(tǒng)郵政無法干預(yù)其優(yōu)化過程，因此第三方系統(tǒng)延時(shí)產(chǎn)生的影響更大。3.2RocketMQ消息中間件在平臺(tái)的應(yīng)用。為了解決交易延時(shí)，在核心應(yīng)用子系統(tǒng)與外聯(lián)前置之間部署一套R(shí)ocketMQ消息中間件子系統(tǒng)，同時(shí)在核心應(yīng)用和外聯(lián)前置增加一對(duì)消息生產(chǎn)者與消費(fèi)者模塊，用于生產(chǎn)及消費(fèi)消息。系統(tǒng)模塊設(shè)計(jì)時(shí)，選擇在訂單生成與訂單支付之間進(jìn)行解耦合，訂單生成后，會(huì)調(diào)用消息生產(chǎn)者模塊主動(dòng)向消息中間件登記一條消息，標(biāo)志訂單生成成功；后續(xù)消息消費(fèi)者（位于外聯(lián)前置）取走消息，并根據(jù)消息類型進(jìn)行個(gè)性化處理，這里主要是進(jìn)行第三方保險(xiǎn)公司投保操作，以此實(shí)現(xiàn)訂單生成與支付投保異步處理。優(yōu)化后的電子商務(wù)平臺(tái)架構(gòu)如圖2所示。首先，平臺(tái)交易到達(dá)核心應(yīng)用后，通過生產(chǎn)者模塊向RocketMQ消息中間件推送一條消息。然后，核心應(yīng)用返回前端交易已提交成功，前端交易完成，后續(xù)進(jìn)行交易狀態(tài)查詢。最后，外聯(lián)前置通過消費(fèi)者模塊取出消息，根據(jù)消息內(nèi)容獲取訂單信息組裝報(bào)文發(fā)送至第三方，獲取第三方返回后將結(jié)果更新到訂單信息中。交易流程優(yōu)化后，前端的訂單支付交易無需等待第三方結(jié)果，很快提示交易提交成功，通過訂單狀態(tài)查詢功能即可獲取訂單狀態(tài)；外聯(lián)前置在第三方調(diào)用時(shí)，可以對(duì)失敗的消息進(jìn)行多次調(diào)用，直至達(dá)到閾值或調(diào)用成功為止。3.3RocketMQ集群部署。RocketMQ部署比較靈活，提供多種集群部署方式，通過配置可以快速形成集群部署，部署方式為異步多Master多Slave模式，每個(gè)Master配置一個(gè)Slave，部署兩組Master-Slave，HA采用異步復(fù)制方式，主備消息延遲短，僅為毫秒級(jí)。這種模式的優(yōu)點(diǎn)是，即使磁盤損壞，消息丟失也較少，且消息實(shí)時(shí)性不受影響，因?yàn)镸aster宕機(jī)后，消費(fèi)者仍然可以從Slave消費(fèi)，此過程對(duì)應(yīng)用透明，不需要人工進(jìn)行干預(yù)。RocketMQ在系統(tǒng)應(yīng)用時(shí)，需要進(jìn)行相關(guān)的約束設(shè)計(jì)。3.3.1增加消息去重策略。在某些情況下，應(yīng)用消費(fèi)了消息，但沒有反饋給RocketMQ，該消息將會(huì)再次被消費(fèi)，因此需要增加消息去重策略，可通過對(duì)應(yīng)的狀態(tài)位決定是否需要再次處理消息。3.3.2限制消息報(bào)文大小。生產(chǎn)消息時(shí)需控制消息報(bào)文的大小，某些應(yīng)用場(chǎng)景不需要將所有信息都封裝到消息體中，僅記錄關(guān)鍵信息即可。3.3.3合理規(guī)劃消息分組。根據(jù)RocketMQ提供的消息特性，結(jié)合業(yè)務(wù)特點(diǎn)，使用分組-Topic-Tag三級(jí)結(jié)構(gòu)，按平臺(tái)-業(yè)務(wù)-模式將消息分類。

4應(yīng)用效果

RocketMQ消息中間件的應(yīng)用，使交易的本地處理與第三方調(diào)用解耦合，交易各項(xiàng)指標(biāo)都有所提升。系統(tǒng)優(yōu)化改造后，使用LoadRunner等測(cè)試工具對(duì)郵政各業(yè)務(wù)場(chǎng)景進(jìn)行了性能壓力測(cè)試，結(jié)果顯示，事務(wù)平均通過率達(dá)98%以上，事務(wù)平均響應(yīng)時(shí)間為1.305s，90%的事務(wù)響應(yīng)時(shí)間在2s內(nèi)。前端最直接的體驗(yàn)是交易耗時(shí)短，系統(tǒng)監(jiān)控發(fā)現(xiàn)，第三方處理超時(shí)對(duì)前端請(qǐng)求影響較小。

參考文獻(xiàn)

1歐志芳．基于RocketMQ實(shí)現(xiàn)異構(gòu)數(shù)據(jù)庫(kù)同步．網(wǎng)絡(luò)安全技術(shù)與應(yīng)用，2016，12

2趙偉，周兵．基于ERP系統(tǒng)的消息中間件設(shè)計(jì)與實(shí)現(xiàn).計(jì)算機(jī)工程，2008，10

3楊開元．RocketMQ實(shí)戰(zhàn)與原理解析．北京：機(jī)械工業(yè)出版社，2018

作者:香華冠 單位:中國(guó)郵政集團(tuán)公司廣東省信息技術(shù)局