微服務通訊策略

在GeeCON 2018大會上，Michael Plöd在一場介紹微服務之間不同的通訊策略的演講中解釋說，在從單體架構遷移到微服務架構時，暗含在單體架構中的複雜性會明確顯露出來，通訊挑戰將呈指數級增長。

\\

Plöd是InnoQ首席顧問。他首先指出，根據他的經驗，團隊經常把微服務視為預設架構。他強調，分散式系統是高難度的系統；如果你不需要一個分散式系統，你就不必為了微服務而力爭實現那樣的架構。在這種情況下，構建良好的單體通常是更好的選擇。

\\

當單體不滿足需求而使用微服務時，必須把它們整合，Plöd指出，這不只是技術問題，還有其他方面的影響：

\\

• 團隊之間需要通過溝通來解決整合問題，這可能會導致政治和治理問題。\\t
• 耦合：實現服務之間的鬆耦合非常重要，否則，你很容易最終得到一個分散式單體。\\t
• 質量標準：在一致性、效能、可擴充套件性、健壯性方面，找出真正需要的是什麼，你應該儘早評估你的應用程式。\\t
• 技術：雖然REST很常用，但那不是唯一的通訊選項。\

為了幫助團隊通訊及管理耦合，Plöd指出，領域驅動設計（DDD）對在業務層面找出邊界非常有幫助——有界上下文。這些上下文彼此之間通常以不同的方式進行互動，為了描述它們之間的關係，可以使用上下文對映。這些互動模式包括：

\\

• 開啟主機服務：指定一個可供服務使用的協議，如REST；\\t
• 共享核心：兩個服務可以共享部分程式碼或定義互動的庫；\\t
• 消費者/供應商：一個服務是另一個服務的消費者，因此，可能會影響它的實現；\\t
• 防腐層：消費者服務建立一個介面卡，最小化它與之互動的另一個服務所帶來的影響。\

看下通訊的技術方面，Plöd首先介紹了通訊的一般分類——Orchestration和Choreography。使用Orchestration，微服務知道過程，會主動呼叫其他服務來完成任務。使用Choreography，微服務會釋出一個事件，其他服務會響應事件，完成相應的動作。在Plöd看來，這是一個重要的區別，他認為，我們應該就係統首選的工作方式做架構決策。他還建議考慮巨集架構和微架構，並指出，微服務並不是說團隊可以隨意選擇他們喜歡的東西，因為那樣做的話，你最終會陷入完全的混亂。相反，他建議採用一種有規則的巨集架構，所有團隊都必須遵守這些規則。在微架構中，團隊有更大的自由，可以選擇他們自己的實現風格。

\\

讓我們看下通訊的技術選項，Plöd指出了四種型別：

\\

• RESTful資源\\t
• 訊息傳遞\\t
• 領域事件\\t
• 訂閱\

雖然REST如今已經廣為人知，但根據Plöd的經驗，只有很少團隊很好地實現了，尤其是在超媒體和多表示形式方面。他指出，實現一個RESTful資源呼叫非常簡單，但是，實現一個可以在微服務環境中正常執行的健壯呼叫要困難許多。以下是需要知道的一些陷阱和挑戰：

\\

• 服務發現：一種服務用來發現它與之通訊的服務的URL的方式。\\t
• 彈性：包括如何處理錯誤和當機。服務的優雅退化非常重要，可以避免異常服務使整個應用程式效能下降。\\t
• 負載均衡：可以處理不斷增長的負載。有許多不同的實現方法，使用哪種方法取決於應用程式的執行環境。\

下一個選項是訊息傳遞，微服務傳送和消費訊息，通常是通過一個訊息代理。下面描述的這些有關REST的挑戰不是很切題：

\\

• 服務發現已經沒意義，因為服務僅知道訊息系統。\\t
• 彈性主要由訊息系統處理。主要的風險是延遲因為錯誤或當機增加。\\t
• 負載均衡是通過向上擴充套件訊息系統或增加訊息消費者數量來實現的。\

Plöd的第三個選項是領域事件。它們表示過去在業務層面上已經發生的事實。使用它們進行通訊會得到事件驅動的微服務，現如今，這是一種非常流行的架構風格。當使用事件通訊時，對於事件中的有效載荷，他介紹了幾個可選方案：

\\

• 滿負載模式：事件中包含處理事件所需的所有資料，例如關於客戶的所有資料。這可以簡化消費者的工作，但也意味著更緊密的耦合。\\t
• REST URL：只有一個指向代表事件的資源的URL。\\t
• 空模式：僅包含關於事件本身的資料。消費者必須通過其他方式找到它需要的資料。\\t
• 混合模式：比如，有少量的資料和一個用於找到其他資料的URL。在大多數情況下，這都是Plöd首選的方式。\

Plöd最後的選項是使用Atom Feeds組合REST和事件。現在，服務會利用事件釋出推送資訊，消費者訂閱並非同步讀取。在大多數環境中，使用HTTP都非常容易通訊，而且可以利用像ETags、最後修改時間、分頁和連結這樣的特性。另外一個好處是，服務釋出推送資訊，可以從消費者完全解耦。推送訊息的讀取完全是由消費者按照它們認為恰當的方式進行的，而且，已消費事件的跟蹤也是由消費者完成的。

\\

為了提供推送訊息，事件必須持久化，這就輪到事件源登場了。我們可以使用這些事件作為我們主要的持久化模型，這還使得我們可以使用CQRS來獲得檢視，這些檢視是經過優化的事件讀取模型。Plöd特別指出，CQRS和事件源只是系統特定部分的解決方案，而不代表系統中隨處都在使用的架構。

\\

要了解更多有關整合的資訊，Plöd強烈推薦由Gregor Hophe和Bobby Wolf所著的Enterprise Integration Patterns一書。

\\

檢視英文原文：Strategies for Microservices Communication

\\