系統集成

系統集成是相對拆分而言的，當巨石型應用拆分爲細粒度的微服務後，錯綜複雜的代碼可以分解爲獨立的模塊加以治理。然而，傳統應用內部原本基於方法的調用方式可能會轉變爲跨進程的分佈式網絡調用方式，網絡的不可靠性給服務模塊之間的交互帶來了複雜性。所以，微服務系統的集成對微服務架構能否成功落地至關重要。

微服務架構強調基於 HTTP 的輕量級的服務交互模式，這一章我們將這種基於請求 / 響應模式的交互模式與 RESTful 架構結合，介紹微服務 “聲明式 API” 和契約優先的開發原則。同時我們會深入講解主流 RPC 架構的實現原理和 RPC 通信方式的優勢和缺點。

微服務架構的另外一種集成模式基於消息中間件的異步交互方式。這種交互模式無疑帶給了微服務更多的靈活性和自治性，但也帶來了複雜性，我們需要在使用場景中做出權衡，選擇適合自己的消息中間件。

服務集成交互技術

我們知道軟件系統的集成主要分爲服務接口集成和數據集成。數據集成一般通過 ETL（全稱爲 Extract-Transform-Load，用來描述將數據從來源端經過抽取、轉換、加載至目的端的過程）方式實現數據的傳遞、聚合等操作。ETL、實時數據流處理是數據領域與數據處理相關的技術話題，這裏不贅述，本章我們只關心應用之間的交互技術和服務之間通過接口集成的技術。

微服務通常使用分佈式跨網絡的交互調用。我們通過網絡協議、Linux I/O 模式、序列化方式三個關鍵要素來講解服務集成交互技術，它們是決定服務交互效果、影響交互效率最關鍵的因素。

本文主要講解網絡協議

分佈式系統採用跨網絡的協議進行通信。

網絡協議是計算機網絡中爲進行數據交換而建立的規則、標準或約定的集合。

無論是前端與後端之間，還是後端微服務之間，交互都會涉及網絡協議。

爲了使不同計算機廠家生產的計算機能夠相互通信，以便在更大的範圍內建立計算機網絡，國際標準化組織（ISO）提出了 “開放系統互聯參考模型”，即 著名的 OSI/RM 模型（ 
OpenSystemInterconnection/Reference Model），它將計算機網絡體系結構的通信協議劃分爲七層，自下而上依次爲：

● 物理層（Physics Layer）

● 數據鏈路層（Data Link Layer）

● 網絡層（Network Layer）

● 傳輸層（Transport Layer）

● 會話層（Session Layer）

● 表示層（Presentation Layer）

● 應用層（Application Layer）

TCP/IP 無疑是當今互聯網使用最廣泛的網絡互聯協議。TCP/IP 與 OSI 體系一樣也採用了分層結構，它們之間的分層架構映射如下表所示。

TCP（Transmission Control Protocol，傳輸控制協議）是一種面向連接的、可靠的、基於字節流的傳輸層通信協議，由 IETF（TheInternet Engineering Task Force，國際互聯網工程任務組）的 RFC793 定義。TCP 旨在適應支持多網絡應用的分層協議層次結構。連接到不同但互聯的計算機通信網絡的主計算機中的成對進程之間依靠 TCP 提供可靠的通信服務。

TCP 主要包括兩大事務：連接管理（建立、關閉連接），以及面向字節流的數據傳輸及控制。

建立連接 TCP 是互聯網中的傳輸層協議，使用三次握手協議建立連接。當主動方發出 SYN 連接請求後，等待對方回答 SYN-ACK，並最終對對方的 SYN 執行 ACK 確認。TCP 三次握手如下圖所示。

終止連接

建立一個連接需要三次握手，而終止一個連接要經過四次握手，這是由 TCP 的半關閉（Half-Close）造成的。具體 TCP 連接終止過程如下圖所示。

長短連接

短連接是指當客戶端與服務端建立連接後，雙方完成一次讀寫過程，然後關閉連接，雙方不需要額外的控制手段維持連接。優點是管理簡單，缺點是延時高、效率低，每次傳輸數據需要重新建立連接。

長連接是指當客戶端與服務端建立連接後，它們之間的連接不會主動關閉，後續的讀寫操作都會繼續使用這個連接，優點是可以連續發送多個數據包，減少資源消耗、降低延時。數據傳輸下面是 TCP 在數據傳輸過程中的一些主要功能特性：

● TCP 把數據流分割成適當長度的報文段，最大傳輸段大小（MSS）通常受該計算機連接的網絡的數據鏈路層的最大傳送單元（MTU）限制。

● 在可靠性上，TCP 爲了保證報文傳輸的可靠性，給每個包一個序號，序號也保證了傳送到接收端實體的包按序接收。然後接 收 端 實 體 對 已 成 功 收 到 的 字 節 發 回 一 個 相 應 的 確 認（ACK）。如果發送端實體在合理的往返時延（RTT）內未收到確認，那麼對應的數據（假設丟失了）將會被重傳。

● 在正確性上，TCP 用一個校驗和函數來檢驗數據是否有錯誤，在發送和接收時都要計算校驗和來保證數據的正確性與合法性。

● 在流量控制上，採用滑動窗口協議，協議中規定對於窗口內未經確認的分組需要重傳機制。

微服務常用的應用協議

● HTTP（Hyper Text Transfer Protocol，超文本傳輸協議）：

HTTP 可以說是目前互聯網上使用的公共語言，Web 瀏覽器、服務器和相關的 Web 應用程序都是通過 HTTP 完成通信的。HTTP 基於 TCP，屬於應用層的面向資源存取和修改的協議，由於具有簡捷、快速的特性，適用於分佈式超媒體信息系統。HTTP 對 API 技術無關性的支持是其最大的優點，瀏覽器的支持及不需要中間代理都簡化了協議的架構。同時 HTTP 對 RESTful 架構的天然友好的支持，使其成爲開發接口和系統集成的標準。

● gRPC：由 Google 開發，是一款語言中立、平臺中立、開源的遠程過程調用協議。基於 HTTP2 標準設計，具有諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多複用請求等特性。這些特性使得其在移動設備上表現更好，更省電和節省空間。gRPC 客戶端應用可以像調用本地對象一樣直接調用另一臺機器上服務端應用的方法，使得我們能夠更容易地創建分佈式應用和服務。與許多 RPC 系統類似，gRPC 也基於以下理念：定義一個服務，指定其能夠被遠程調用的方法（包含參數和返回類型）；在服務端實現這個方法，並運行一個 gRPC 服務器來處理客戶端調用；在客戶端擁有一個像服務端一樣的方法。

gRPC 最大的優勢就是語言無關性，對於微服務架構技術棧多樣性的特性有非常好的支持，也是很多公司採用 gRPC 作爲自己後端系統集成的協議標準的原因。

● AMQP：全稱 Advanced Message Queuing Protocol，是一個進程間傳遞異步消息的協議。AMQP 使用長連接，是一個使用 TCP 提供可靠投遞的應用層協議。RabbitMQ 就是遵從 AMQP 協議開發的一個 RPC 遠程調用框架。RabbitMQ 中的交換器、交換器類型、隊列、綁定、路由鍵等都遵循 AMQP 中相應的概念。可以將 AMQP 看作一系列結構化命令的集合，這裏的命令代表一種操作，類似 HTTP 中的方法（GET、POST、PUT、DELETE 等）。

● RSocket：是一種用於反應式應用程序的新網絡協議，是第七層語言無關的應用網絡協議，是一種基於 Reactive Streams 背壓的雙向、多路複用、消息的二進制協議。除了 TCP，同時支持的通信協議還有 UDP、WebSocket 等。RSocket 與 HTTP 的不同之處在於它定義了四種交互模型。

○ fire-and-forget：異步觸發，不需要響應。

○ request/response：請求 / 響應，發出一個請求，獲取一個響應，就像 HTTP 一樣。

○ request/stream：請求 / 流式響應，一個請求對應多個或無數個流式響應。

○ channel：雙向異步通信，也就是支持 Channel。

選擇適合你的協議

上述應用層協議是我們精心選擇的微服務可能會使用的網絡協議，不同的網絡協議適合不同的應用場景。

● 如果你的微服務之間是 “點對點” 的請求 / 響應交互方式，可以採用基於 HTTP 的 REST 方式或者 RPC 方式的調用。一般來說，HTTP 具備更好的通用性，RPC（如 gPRC）交互的性能優勢更加明顯，使用何種方式作爲你的微服務集成標準你需要做利弊權衡。至於使用同步 I/O 還是異步 I/O，這個基礎性的選擇會不可避免地影響後續的代碼實現和技術架構，下一節我們會詳細講解 I/O 中的同步和異步、阻塞和非阻塞的相關技術和其對服務集成的影響。

● 如果你的微服務系統屬於 “異步執行”，或者屬於一對多的發佈 / 訂閱場景，那麼可以考慮使用消息中間件作爲交互平臺。

服務生產者與服務消費者可以使用一個第三方消息代理平臺通過事件驅動機制完成服務集成。

● 對於 Reactive 風格的應用，通常需要非阻塞並且與異步行爲匹配。很多場景是服務端從客戶端請求數據，支持單個連接上的多路複用，允許任意交互模式的雙向消息流。這個時候 HTTP 可能已經無法滿足你的需求，RSocket 網絡協議給微服務提供了很好的端到端的網絡體驗，我們將會在本文的進階篇中進一步講解。

來源：

https://www.toutiao.com/a7050337784975950347/?log_from=8376e22638c56_1641779733320

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/EnFNSE3KTN1xhYZ5Wly8Ng