弘康人壽基於 RocketMQ 構建微服務邊界總線的實踐

隨着互聯網+和平臺化戰略的興起，各個行業的 IT 系統都在向互聯網架構發展，涉及的主要技術包括微服務、消息和彈性計算等，採用微服務架構實現服務高內聚、低耦合，經過異步消息完成交易快速響應和高併發。因爲微服務和消息是企業應用架構中用的比較多的，故但願經過本文探討如下問題：

• 企業服務總線（ESB）是否真的過期了？
• 爲何 RocketMQ 是企業服務總線的最佳技術方案之一？
• 如何設計企業微服務架構演進路線圖？

SOA 架構演變史

階段 1：企業服務總線 ESB

當單體應用拆分紅多個應用後，應用服務之間須要相互調用，而 ESB 恰好是用來解決服務調用方和服務提供者之間的點對點鏈接關係的，點對點鏈接不如你們都連到一個總線上，這樣就會實現物理位置、傳輸協議等多個方面透明。ESB 核心技術就是 MQ 消息中間件，服務一旦接入總線，相互之間緊耦合調用變成了發消息和收消息，以下圖所示：

這樣作的好處以下：

一、服務之間的點對點變成了總線鏈接，服務提供方和調用方接入總線後指定相同的隊列名便可完成單向通信。固然雙向通信也是能夠實現的，好比 IBM 的 MQ 產品在推 ESB 解決方案時就提供發消息和收消息自動配對功能，實現機制是經過消息相關標識 CorrelId 字段，將一個消息與另外一個消息相關，或將一個消息與應用程序正在執行的其餘工做相關，使用這個機制能夠完成消息發送和接收的 request-reply 模式，達到實時調用響應效果，從而使一些不適合異步消息調用的場景也可使用 ESB。

二、服務之間負載均衡轉移到總線。服務調用方能夠是多個，共同發送消息，服務提供方也能夠是多個，共同接收消息,所以只要總線自己是負載均衡的，那麼就不存在負載均衡問題。

三、總線是服務之間的緩衝器，確保請求消息積壓不會沖垮被調用方，同時能保證服務調用方的體驗。

綜上，ESB 企業服務總線經過 MQ 消息中間件實現 SOA 架構的兩點核心功能：服務註冊發現和負載均衡，服務接入 ESB 就完成了「註冊」，經過指定消息隊列名實現「服務發現」，而負載均衡問題經過總線自己是否負載解決。因爲 ESB 優點明顯，故在金融業尤爲是銀行業獲得普遍應用，但因爲早期的 MQ 消息中間件架構比較重，在高可用和高併發方面表現通常，更多關注的是消息事務性，不能徹底知足 ESB 自己的職能要求，所以當 ESB 上到必定規模後就成了整個應用架構最大的性能和故障點。

階段 2：微服務

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

微服務的特徵：

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

缺點：

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

三、服務網格 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"壓力考驗，性能穩定，下邊從如下幾個方面說明：

一、微服務架構、高性能、高可用

RocketMQ 消息中間件架構上基於微服務設計，由 NameServer 註冊中心、 broker 集羣、Producer 集羣、Consumer 集羣四部分組成，每一個部分都支持多節點擴展，broker 支持主從模式，有同步雙寫、異步複製兩種模式。NameServer 註冊中心各節點互相獨立，彼此沒有通訊關係，單臺 NameServer 掛掉，不影響其餘 NameServer，這一點比 zookeeper 輕量不少。同時 RocketMQ 底層基於 Netty 異步事件驅動通信框架，採用長鏈接，具備高性能、高可靠性特色。

二、單機支持上萬 Topic 主題，Topic 數量增長對性能影響很小

RocketMQ 是以 Topic 做爲消息通道的劃分單元，不一樣的業務使用不一樣的 Topic 發送和接收消息，這樣能夠達到物理上劃分消息通道資源的目的，這一點對企業服務總線很重要。
而 RocketMQ 單機支持上萬 Topic，Topic 的增長對性能影響很小，這一點是 Kafka 欠缺的。

如上圖，不一樣的業務能夠劃分不一樣容量的總線通道，例如日誌通道能夠經過分配更多的 broker 主題方式提升通道傳輸能力效果。

三、內存模式支持同步請求處理

通常消息中間件適合異步請求處理場景，RocketMQ 的內存模式支持消息不落盤，性能更高，這樣也適用於「request-reply」同步請求處理場景。

四、延遲消息優點

RocketMQ 支持延遲消息，消息發送後可指定延遲被消費的時間，例如1小時後被消費，這一特性對於不一樣系統間數據同步或對帳來講很是實用，特別是一些老系統比較多的企業，大量的批處理都是爲了這個目的，使用 RocketMQ 消息總線能夠很好的治理這個問題，而不用大量使用定時任務。

五、流數據處理

對於日誌流數據處理需求，RocketMQ 支持 log4j、logback 等日誌異步 appender，對於其餘非交易數據處理需求，也可採用異步發送+batch 模式提升數據傳輸效率。

六、客戶端支持多語言，多 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服務化治理工做。

---

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。