微服務集成框架的模式
微服務已經在架構界流行起來了，但在實踐中，難免需要利用其它軟件廠商系統的能力，同時也沒有辦法一步到位把企業內的所有系統都改造成微服務架構的系統，所以系統集成仍然是 一個非常重要的問題。在筆者項目的早期階段，集成是由微服務系統的組件直接對接其它系統處理的，這種方式點對點的集成方式造成了系統和被集成系統的強耦合，影響了微服務系統的進一步發展。
在接手集成框架的設計工作以後，筆者先研究了什麼樣的集成模式更加符合微服務的架構思想。在Martin Fowler的文章中提到，微服務架構的特徵之一是“智能的端點，愚蠢的管道”。作爲參照，ESB是智能管道的典型代表，ESB產品通常包括複雜的基礎設 施，支持消息路由、編排、轉換和應用業務規則。在實踐中，ESB本身會逐漸發展爲系統中一個複雜的單塊應用；同時，這也於盡量解耦、內聚的微服務架構思想相左。因此，微服務團隊在解決問題時，倡議使用REST API和輕量級消息系統實現系統集成。其中，消息系統僅提供可靠的異步消息傳輸通道，而不參與消息路由、編排、轉換等環節，也不在消息系統中包含業務邏 輯。在各種消息通信模式中，事件驅動模式因其完全解耦、高度容錯的特性受到了微服務架構系統的歡迎。事件驅動消息系統的中心是一個不做消息路由、編排或者 轉換的Message Broker，Apache Kafka是很好的選擇。
考慮到將要和微服務系統集成的三方系統通常都不符合微服務的架構，同時也不一定支持使用REST API或微服務系統選型的Message Broker。筆者設計集成框架的基本思想是使用Adapter設計模式，爲將要集成的每一個三方系統構建一個集成服務。集成服務對外包裝所有和三方系統 的同步異步交互，對內遵循微服務系統的規範，可以作爲一個服務組件部署在當前微服務環境中。注意集成服務是針對每個三方系統獨立開發的，每個集成服務都是微服務的Component，都可以獨立部署。要避免一個集成服務面對多個三方系統，變成一個單塊的集成平臺。
微服務集成框架的設計和實現
微服務集成架構選則了通用性很強的REST、Kafka、Json格式消息作爲標準，只需遵循約定的REST接口和消息定義，集成服務的開發者可以選用自己熟悉的語言、框架來編寫。爲了能加速集成服務的開發，筆者在定義了微服務集成模式之後，又設計並開發了Java技術棧的微服務集成框架。集成框架提供了和微服務系統內組件同步、異步通信所需要的基礎能力，框架的組成主要包括：
- 服務註冊發現服務
- Message Broker服務
- 微服務集成基礎Jar包
微服務集成基礎Jar包中包括
- 項目骨架工程框架
- 異常框架
- 日誌框架
- 統一配置框架
- 服務註冊和發現客戶端
- 服務封裝和訪問框架
- REST服務文檔框架
- 消息發佈和訂閱客戶端
下圖展示了開發集成框架時的部分技術選型，供讀者參考
參考資料
- 微服務特徵-Smart endpoints and dumb pipes
- Microservices and the Integration Platform
- Building Microservices - Chapter 4. Integration
