弘康人壽基於 RocketMQ 構建微服務邊界匯流排的實踐

隨著網際網路+和平臺化戰略的興起，各個行業的 IT 系統都在向網際網路架構發展，涉及的主要技術包括微服務、訊息和彈性計算等，採用微服務架構實現服務高內聚、低耦合，通過非同步訊息完成交易快速響應和高併發。由於微服務和訊息是企業應用架構中用的比較多的，故希望通過本文探討以下問題：

• 企業服務匯流排（ESB）是否真的過時了？
• 為什麼 RocketMQ 是企業服務匯流排的最佳技術方案之一？
• 如何設計企業微服務架構演進路線圖？

SOA 架構演變史

階段 1：企業服務匯流排 ESB

當單體應用拆分成多個應用後，應用服務之間需要相互呼叫，而 ESB 剛好是用來解決服務呼叫方和服務提供者之間的點對點連線關係的，點對點連線不如大家都連到一個匯流排上，這樣就會實現物理位置、傳輸協議等多個方面透明。ESB 核心技術就是 MQ 訊息中介軟體，服務一旦接入匯流排，相互之間緊耦合呼叫變成了發訊息和收訊息，如下圖所示：

這樣做的好處如下：

1、服務之間的點對點變成了匯流排連線，服務提供方和呼叫方接入匯流排後指定相同的佇列名即可完成單向通訊。當然雙向通訊也是可以實現的，比如 IBM 的 MQ 產品在推 ESB 解決方案時就提供發訊息和收訊息自動配對功能，實現機制是通過訊息相關標識 CorrelId 欄位，將一個訊息與另一個訊息相關，或將一個訊息與應用程式正在執行的其他工作相關，使用這個機制可以完成訊息傳送和接收的 request-reply 模式，達到實時呼叫響應效果，從而使一些不適合非同步訊息呼叫的場景也可以使用 ESB。

2、服務之間負載均衡轉移到匯流排。服務呼叫方可以是多個，共同傳送訊息，服務提供方也可以是多個，共同接收訊息,因此只要匯流排本身是負載均衡的，那麼就不存在負載均衡問題。

3、匯流排是服務之間的緩衝器，確保請求訊息積壓不會沖垮被呼叫方，同時能保證服務呼叫方的體驗。

綜上，ESB 企業服務匯流排通過 MQ 訊息中介軟體實現 SOA 架構的兩點核心功能：服務註冊發現和負載均衡，服務接入 ESB 就完成了“註冊”，通過指定訊息佇列名實現“服務發現”，而負載均衡問題通過匯流排本身是否負載解決。由於 ESB 優勢明顯，故在金融業尤其是銀行業得到廣泛應用，但由於早期的 MQ 訊息中介軟體架構比較重，在高可用和高併發方面表現一般，更多關注的是訊息事務性，不能完全滿足 ESB 本身的職能要求，因此當 ESB 上到一定規模後就成了整個應用架構最大的效能和故障點。

階段 2：微服務

微服務架構出現於 2014 年，採用註冊中心實現了服務註冊發現、負載均衡、容錯、 監控等功能，同時服務拆分粒度可以更細，服務共享和 IT 組織協作也可以更加精細化，因此微服務架構也推進了 IT 團隊的專業分工和高效協作。

微服務的特徵：

• 通過服務實現元件化，服務拆分粒度更細，有利於服務共享和整合 ；
• 按業務能力來劃分服務和開發團隊，有利於 IT 組織高效協作 ；
• 去中心化，服務與服務之間直接點對點連線，沒有任何代理或負載均衡器，服務節點與註冊中心採用非同步心跳通訊。

缺點：

• 微服務架構技術邊界明顯，必須通過新建方式才能完成新舊系統替換，成本較大；
• 老系統和新系統之間的對接仍舊通過傳統負載均衡或閘道器來實現高可用，存在單點問題；
• 註冊中心是微服務架構邊界，隨著加入服務節點數增加，註冊中心會成為最大的故障點。

3、服務網格 ServiceMesh

針對微服務架構邊界和新舊技術對接問題，誕生了服務網路 ServiceMesh，也稱為代理邊車（Sidecar），這種架構的本質是將微服務架構中的註冊中心、負載均衡、故障處理等功能提取出來，單獨作為一個代理程式與應用服務部署在同一機器，同時在網路通訊層進行干預，實現服務的自動代理和自動發現，實際是把代理做成了微服務架構，這樣不用動原來的老系統，就可以用上微服務架構的核心功能，簡單高效。

服務網：

缺點：

每個服務部署的伺服器或容器上都要安裝一個代理，就單個服務而言，代理是單點，一旦代理掛了，則該服務不可用，這個問題對每個服務都存在。

ServiceMesh 要實現所有服務的互通互連，要求所有服務代理連線到註冊中心，那麼註冊中心又成為最大故障點。

ServiceMesh 實際是微服務版本的企業服務匯流排，用於服務解耦和負載均衡，而 SOA 架構除了具備這些功能，還需要通過服務拆分和共享滿足業務需求開發、上線、運維的快速迭代，從這個角度講 ServiceMesh 稱不上微服務架構，僅僅完成其中一部分功能。因此，
ServiceMesh 只是一個微服務架構實施的臨時方案。

啟示:

從單體應用到 SOA 架構的3個階段，每個階段都出現了不同的架構解決方案，通過以上分析不難看出，通過單一架構解決企業應用架構的所有問題是不可行的，因此我們要吸取各種架構的優點，採用多種架構融合的方式尋求最佳解決方案。

弘康人壽微服務架構建設

弘康人壽 IT 系統同國內大部分保險企業類似，都是從一個單體核心系統逐步拆分發展而來，服務與服務之間沒有通過 ESB 匯流排，而是採用傳統負載均衡方式進行通訊，還處於 SOA 架構演變的初級階段。去年公司陸續在官網和增值服務領域引入了微服務架構，新官網使用的 Dubbo，增值服務使用的是 SpringCloud，這裡說明一下，公司內部開發統一使用的微服務架構是 SpringCloud，由於新官網是外採的成型產品，技術架構無法改變，故使用 Dubbo ,這樣的情況在國內很多企業都存在。

所以，在微服務架構實施初期我們就意識到統一技術架構對企業來說是有很大困難的，不同的業務線，不同的團隊對技術架構的需求和理解不一樣，所以技術架構方面一定要是開放的，求同存異，不能為了架構而架構。另一方面我們仔細分析了公司業務結構和特點，全部放入一個微服務架構邊界（註冊中心）裡也是不合適的，那麼也就意味著微服務架構也會分成幾個不同區域，每個業務區域連線一個註冊中心，架構規劃圖如下：

區域1直接面向網際網路，屬於前置應用，區域2到5在內網，屬於中後臺服務，架構設計到這一步，擺在我們面前的問題是不同的區域有的是微服務架構，有的是舊的分散式架構，不同架構之間都存在註冊中心、負載入口等邊界問題，按照傳統思路各個區域使用閘道器或軟負載統一對外提供服務，架構圖如下：

在各個區域增加一個負載均衡器，每個區域內部使用微服務或老架構進行通訊，跨區域則通過負載均衡器，由於傳統的負載均衡器（如 Nginx）都存在單點問題，一旦出現當機或阻塞，將會影響整個系統執行，所以為了分攤風險，負載均衡器也採用分割槽設計。

另一方面，大家可以看到各個應用區域之間的互連互通也是非常必要的，尤其是在大資料、AI 等新科技驅動下，企業的資料化轉型一個最基本的要求是所有資料能否自由流通，所以從這個角度看，上圖中的負載均衡器實際上是一個資料匯流排的雛形，我認為可以參考企業服務匯流排 ESB 和 ServiceMesh 的設計思想，用高可用的訊息中介軟體取代上圖中各個區域的負載均衡器。

為什麼 RocketMQ 是企業服務匯流排的最佳技術方案之一

在 SOA 架構發展的三個階段，我們提到了 ESB 的優勢和缺點，對於 ESB 當時採用的訊息中介軟體過重、效能差等技術問題，隨著開源技術的不斷髮展和進步，這些問題得到有效解決，目前開源技術中訊息中介軟體大概有 RabbitMQ、RocketMQ 和 Kafka 三種選項，網上有很多純技術指標對比，單就 ESB 級別的應用來說 RocketMQ 是最均衡的，並且經過阿里巴巴"雙11"壓力考驗，效能穩定，下邊從以下幾個方面說明：

1、微服務架構、高效能、高可用

RocketMQ 訊息中介軟體架構上基於微服務設計，由 NameServer 註冊中心、 broker 叢集、Producer 叢集、Consumer 叢集四部分組成，每個部分都支援多節點擴充套件，broker 支援主從模式，有同步雙寫、非同步複製兩種模式。NameServer 註冊中心各節點互相獨立，彼此沒有通訊關係，單臺 NameServer 掛掉，不影響其他 NameServer，這一點比 zookeeper 輕量很多。同時 RocketMQ 底層基於 Netty 非同步事件驅動通訊框架，採用長連線，具有高效能、高可靠性特點。

2、單機支援上萬 Topic 主題，Topic 數量增加對效能影響很小

RocketMQ 是以 Topic 作為訊息通道的劃分單元，不同的業務使用不同的 Topic 傳送和接收訊息，這樣可以達到物理上劃分訊息通道資源的目的，這一點對企業服務匯流排很重要。
而 RocketMQ 單機支援上萬 Topic，Topic 的增加對效能影響很小，這一點是 Kafka 欠缺的。

如上圖，不同的業務可以劃分不同容量的匯流排通道，例如日誌通道可以通過分配更多的 broker 主題方式提高通道傳輸能力效果。

3、記憶體模式支援同步請求處理

一般訊息中介軟體適合非同步請求處理場景，RocketMQ 的記憶體模式支援訊息不落盤，效能更高，這樣也適用於“request-reply”同步請求處理場景。

4、延遲訊息優勢

RocketMQ 支援延遲訊息，訊息傳送後可指定延遲被消費的時間，例如1小時後被消費，這一特性對於不同系統間資料同步或對賬來說非常實用，特別是一些老系統比較多的企業，大量的批處理都是為了這個目的，使用 RocketMQ 訊息匯流排可以很好的治理這個問題，而不用大量使用定時任務。

5、流資料處理

對於日誌流資料處理需求，RocketMQ 支援 log4j、logback 等日誌非同步 appender，對於其他非交易資料處理需求，也可採用非同步傳送+batch 模式提高資料傳輸效率。

6、客戶端支援多語言，多 JDK 版本，相容性好

RocketMQ Producer、Consumer 客戶端支援 Java, C++, Go 語言，對於 java 語言，支援 JDK1.6 到 1.8，滿足目前各企業主流使用需求，適用新舊系統。

通過以上六大特性分析，我們認為 RocketMQ 是目前開源訊息中介軟體中最適合企業服務匯流排 ESB 的技術方案，因此我們選擇使用 RocketMQ 作為連線各個系統區域的邊界匯流排。

弘康人壽微服務邊界匯流排架構圖

我們將應用系統的5個區域連線到 RocketMQ 邊界匯流排，這樣所有跨區域的資料傳輸通過匯流排完成，每個區域（2-5）內部的服務與服務互動仍採用微服務架構。對於區域1屬於前置層，直接面向網際網路，採用微服務架構的意義不大，故在區域1的每個應用程式上繫結一個 RocketMQ 客戶端，負責收訊息和發訊息，這也得益於 RocketMQ 良好的 JDK 版本支援。

對於區域2-5，每個區域會部署2個以上的 RocketMQ 代理微服務，對區域內部提供收訊息和發訊息服務，避免過多 MQ 客戶端連線到匯流排，為匯流排 NameServer 減負。對於一些對於效能要求比較的業務場景，也允許區域內的系統直接客戶端方式連線到匯流排，提高處理效率，但這種情況不多。整體架構達到的最終效果為：

• 除區域 1 採用傳統負載負載均衡方式對終端使用者提供服務外，區域 2-5 各個系統均 無需使用傳統負載均衡，消滅單點問題 。

• RocketMQ 叢集只是作為一種邊界匯流排，不會與太多的系統連線，我們初步估算一下需要連線到匯流排的客戶端不會超過 100 個，這對 RocketMQ 叢集 幾乎沒有什麼壓力，所以 架構設計上保證了邊界匯流排是輕量級的 ，同時也保證了其穩定性和處理效能，前面我們講到在 ESB 那個階段大多數企業實施到最後階段都會覺得 ESB 過重，除技術本身問題外，認為 ESB 應該作為所有系統間呼叫的通道也是一種錯誤，這無形加重了 ESB 的負擔。

• 遵循“統一邊界匯流排，差異化服務治理”的架構設計思想 ，各個區域的微服務架構可以不統一，比如區域2可以使用 SpringCloud1.5.x 版本，區域3可以使用 SpringCloud2.x 版本，區域4可以使用 Dubbo，區域5可以使用低成本的 ServiceMesh，只要各個區域內的版本統一即可。

• 有利於各個區域內的技術升級換代 。所有的技術升級換代都是區域性的，隨著業務的發展，我們可以不斷拆分各個業務區域，這樣技術升級風險更小，也更平滑。

最後，回答一下剛開始提出的三個問題：

Q1.  企業服務匯流排（ESB）是否真的過時了？

A1.  企業服務匯流排（ESB）採用的核心技術是 MQ 訊息中介軟體，對於點對點服務解耦有不可超越的優勢，兩個服務點對點需要處理負載均衡、容錯、超時等問題，但是通過 ESB 訊息管道後這些問題迎刃而解，這是 ESB 最大的魅力，所以我認為 ESB 沒有過時，在技術不斷進步的今天，各個企業可以嘗試搭建自己的輕量級 ESB 邊界匯流排。

Q2.  為什麼 RocketMQ 是企業服務匯流排的最佳技術方案之一？

A2.  結合本文中描述 RocketMQ 六大優勢，符合這六點才能滿足網際網路時代的匯流排應用要求。

Q3.  如何設計企業微服務架構演進路線圖？

• 首先進行應用架構分割槽和微服務邊界匯流排規劃。
• 搭建RocketMQ叢集，建立統一ESB邊界匯流排服務。
• 逐個區域實施微服務架構改造，通過訊息代理或客戶端接入RocketMQ邊界匯流排。

本文作者： 舒平，弘康人壽架構部負責人，長期從事保險行業IT服務化治理工作。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69915408/viewspace-2651479/，如需轉載，請註明出處，否則將追究法律責任。