本文要點
- 在企業級軟體開發中，API、服務、數據和系統集成是最具挑戰性，同時也是最重要的需求；
- 過去，我們曾經將這些獨立的應用以點對點的風格集成在一起，隨後這種方式被 ESB（企業服務匯流排，Enterprise Service Bus）風格所代替，與之同時出現的還有面向服務架構（Service Oriented Architecture，SOA）；
- 隨著微服務和「雲原生」架構的普及，出現了「服務網格」的概念。服務網格的核心思想是將所有業務邏輯的代碼作為服務的一部分，同時將網路通信相關的邏輯放到到服務間通信基礎設施之中。
- 因為服務網格提供了一些 ESB 的功能，所以有人將其誤解為分散式 ESB，讓它也負責應用集成。這是不正確的。
- 服務網格只是用來在服務間進行通信的基礎設施，開發人員不應該在服務網格中構建任何業務邏輯。有一些其他的框架和庫可以用來實現雲原生企業應用的集成模式。
在企業級軟體應用開發中，長期以來，API、服務、數據以及系統的集成都是最具挑戰性同時也是最基本的需求。
在過去，我們會將這些獨立的應用以點對點的方式進行集成，這種方式隨後被企業服務匯流排（enterprise service bus，ESB）和面向服務架構（service-oriented architecture，SOA）所替代。
但是，在現代微服務和雲原生架構中，我們很少再去討論應用集成了。但這並不意味著這種現代架構已經解決了企業應用集成的所有挑戰。
應用集成的挑戰幾乎沒有什麼變化，但是我們解決它們的方式卻發生了變化。
從 ESB 到智能端點和啞管道
大多數採用 SOA 的企業都會使用 ESB 作為中心匯流排，以連接和集成所有獨立的 API、服務、數據和系統。
如果給定的業務場景需要與組織中不同的實體進行通信的話，ESB 的職責就是探測所有的實體並創建組合功能。
因此，通常來講，ESB 解決方案是所有內置集成功能的動力源，例如到不同系統和 API 的連接器、消息路由、轉換、彈性通信、持久性和事務。
圖 1：使用 USB 進行集成
但是， 微服務架構 傾向於通過構造智能端點和啞管道來 替代 ESB ，這意味著我們的微服務必須要負責所有的應用程序集成。
智能 ESB 去中心化的一個代價就是微服務代碼的複雜性會明顯增加，因為除了服務的業務邏輯之外，它們必須還要處理這些應用集成的功能。例如，圖 2 展現了多個作為智能端點的微服務（B、F 和 G），它們同時包含了與多個其他服務通信的結構和業務本身的邏輯。
圖 2：微服務的服務間通信和組合
微服務架構的另一項挑戰是如何構建不屬於服務業務邏輯的特性，如彈性通信、傳輸級別的安全性、發布統計數據、將跟蹤數據發布到可觀察性工具等。服務本身必須將這些特性作為服務邏輯的一部分來進行實現。在每個微服務中實現所有的這些特性是非常複雜的，如果我們的服務是使用多語言（polyglot）實現的話，這會極大地增加相關的工作量，而服務網格可以解決這個問題。
圖 3：實際的服務網格
服務網格的核心思想是將所有業務邏輯的代碼作為服務的一部分，同時將網路通信相關的邏輯放到到服務間通信基礎設施之中。在使用服務網格的時候，給定的微服務不會直接與其他的微服務進行通信。服務和服務之間的通信會通過一個額外的軟體組件來進行，這個組件運行在服務的進程之外，叫做服務網格代理或 sidecar 代理。sidecar 進程和服務位於同一個虛擬機（VM）或 Pod（Kubernetes）中。sidecar 代理層也被成為數據平面（data plane）。所有的 sidecar 代理都會由控制平面（control plane）來進行控制，服務間通信相關的配置都會用到這裡。
服務網格並不是用來進行應用集成的
因為服務網格提供了一些 ESB 的功能，所以有人將其誤解為分散式 ESB，讓它也負責應用集成。這是不正確的。服務網格只是用來在服務間進行通信的基礎設施，我們不應該在服務網格中構建任何業務邏輯。假設我們有三個微服務，名為 X、Y 和 Z，它們以請求 / 響應的方式進行通信，為了實現業務功能，X 需要與 Y 和 Z 進行通信（參加圖 4）。業務邏輯的組合應該是微服務 A 的代碼，服務網格的 sidecar 不應該包含任何與組合邏輯相關的內容。
圖 4：服務組合邏輯與服務網格
類似的，對於使用事件驅動通信的服務來講，服務的代碼應該處理所有的業務邏輯細節（值得一提的是，服務網格還沒有完全支持事件驅動架構）。所以，即便我們基於服務網格運行微服務或雲原生應用，這些服務和應用的集成依然是必要的。在現代微服務和雲原生架構時代，應用集成是最關鍵的需求之一，但在很大程度上它依然是隱形的需求。
微服務和雲原生應用的集成
在微服務和雲原生應用中，應用集成或構建智能終端都涉及到集成微服務、API、數據和系統。這些集成需求涉及的範圍從幾個微服務之間的集成到與單體子系統的集成，再到創建反腐敗層（anti-corruption layer）。深入研究微服務和雲原生應用程序中的應用程序集成需求，我們會發現在應用程序集成框架中需要具備以下關鍵功能：
- 集成運行時必須是雲原生的，能夠平穩運行在 Docker/Kubernetes 中，並且提供與雲原生生態系統的無縫集成。
- 它需要支持服務編排（orchestrations）/ 活動組合，這樣給定的服務要包含調用多個其他服務的邏輯，從而能夠組合業務功能。
- 它需要支持服務協同（choreography）/ 反應式組合，這樣服務間通信可以通過同步的事件驅動通信來實現，避免出現包含服務交互邏輯的中心化服務。
- 它必須具有對各種消息協議（HTTP、gRPC、GraphQL、Kafka、NATS、AMQP、FTP、SFTP、WebSockets、TCP）的內置抽象。
- 它必須要支持消息和服務調用的分叉（forking）、連接（joining）、分割（splitting）、循環（looping）和聚合（aggregation）。
- 它需要支持存儲和轉發、持久化投遞和冪等消息等技術。
- 它必須具有消息類型映射和轉換的功能。
- 它必須能夠與 SaaS（如 Salesforce）、專有方案（如 SAP）和遺留系統進行集成。
- 應該具有面向業務邏輯的消息路由。
- 它必須支持以補償的方式實現分散式事務。
- 它必須具備長時間運行的工作流。
- 反腐敗層必須能夠連接微服務和單體子系統。
在任何微服務和雲原生應用中，這些功能都是很常見的，但是從頭進行構建可能是一項艱巨的任務。這也是為什麼在構建微服務和雲原生應用時，仔細分析這些功能並基於集成需求選擇合適的技術和框架為何如此重要。例如，如果我們要構建的服務需要複雜的編排邏輯，那麼我們選擇的框架或技術應該能讓這種類型的組合更易於編寫。如果我們想要構建的服務要長期運行並且具備補償功能，那麼就要選擇一個內置工作流和補償功能的框架（參見 InfoQ 的文章「 事件、流程和長期運行的服務：工作流自動化的現代解決方案 」，Martin Schimak 和 Bernd Rücker 深入分析了當前面向雲原生架構的工作流技術）。
儘管應用集成被大多數的微服務專家所忽視，但是像 Christian Posta（Red Hat 前首席架構師，Solo.io 的 Field CTO）這樣的文章作者已經強調了應用集成的重要性，比如 Posta 的博客文章 不能將應用程序的安全性和正確性放到 Istio 或其他服務網格上 。Bilgin Ibryam 在 InfoQ 文章 後 Kubernetes 時代的微服務 一文中，強調了雲原生架構中應用集成的去中心化，以及如何基於服務網格構建應用集成。
CNCF 視野下的開發和集成
雲原生計算基金會（Cloud Native Computing Foundation，CNCF）處在構建微服務和雲原生應用程序的最前沿，它的目標是構建可持續的生態系統，並圍繞一組高質量的項目打造一個社區，將容器編排作為微服務架構的一部分。CNCF 託管由開源技術和框架組成的項目，這些項目可以實現微服務或雲原生架構的不同方面。我們可以看一下這些應用集成技術位於技術棧的什麼位置。
CNCF 推薦的 雲原生路徑 有一個應用定義和開發（App Definition and Development）部分，但是沒有專門的應用開發或集成的分類。考慮到應用程序集成的重要性，我們可以看到它將來會納入 CNCF 之中。圖 5 展示了應用定義和開發下的應用集成技術。
圖 5：未來 CNCF 中的應用集成
應用集成相關的技術
儘管有很多單體的應用集成技術可供使用，但是，它們中的大多數並不適合雲原生或微服務架構。在已有的集成提供商中，只有很少一部分為它們的產品和工具實現了針對雲原生的變種。
有一些專門的集成框架，可以在應用集成領域實現通用的集成模式。通常，大多數這樣的技術都是從傳統的基於 ESB 的集成方式中繼承而來的，但是它們都經過了修改，並且可以直接集成到雲原生架構中：
- Apache Camel/Camel-K 是最流行的開源集成框架之一，Camel-K 項目基於 Camel 運行時為 Kubernetes 生態系統提供了無縫支持。
- WSO2 Micro Integrator 是開源 WSO2 企業級集成平台的雲原生變種形式。Micro Integrator 提供了輕量級的集成運行時，它能在 Kubernetes 生態系統中直接運行。
- 儘管 Spring Integration 沒有專門在 Kubernetes 上的運行時版本，但是它能夠很好地用到雲原生架構中的應用集成功能中。
一些應用開發框架也能滿足應用集成的需求：
- Spring Boot 本身並不是一個集成框架，但是它具備應用集成所需的很多重要功能。
- Vert.x 是一個用於構建反應式雲原生應用的工具包，它也能用來進行應用集成。
- Micronaut 是一個現代的、基於 JVM 的全棧框架，能夠用來構建模塊化和易於測試的微服務以及 serverless 應用。該框架內置了很多集成抽象，並且避免了傳統框架（如 Spring）的複雜性。
- Go 、 JavaScript/Node.js 等編程語言有一些內置的或者可以以庫的形式使用的應用集成特性。一些新興的語言，比如 Ballerina ，語言本身就提供了對集成的抽象。
- Quarkus 是一個新的 Kubernetes 原生 Java 棧，它針對 GraalVM 和 OpenJDK 進行了定製，由最好的 Java 庫和標準組裝而成。它組合了多個應用開發庫，比如 RESTeasy、Camel、Netty 等。
結論
在將單體應用拆分為微服務和雲原生應用的過程中，如何連接這些應用的需求變得越來越具有挑戰性。服務和應用程序分散在網路中，並通過不同的通信結構連接。實現任何的業務場景都需要微服務集成，這需要作為服務實現邏輯的一部分來完成。因此，在微服務和雲原生架構時代，雲原生應用集成是最關鍵的需求之一，但它在很大程度上是隱形的需求。
服務網格模式克服了微服務集成方面的一些挑戰，但是它只提供了服務間通信的通用特性，這是獨立於服務的業務邏輯的，因此業務場景相關的應用集成邏輯還是要在服務級別來實現。所以，最重要的是選擇合適的開發技術來構建集成服務，並將服務組合在一起所需的開發時間最小化。有一些框架和技術正在出現，以滿足雲原生環境中應用集成相關的需求，我們需要根據每個特定的用例來評估這些技術。
