在微服務架構的世界中，我們通過一系列服務構建應用。集合中的每項服務都符合以下標准：
- 松散耦合
- 可維護和可測試
- 可以獨立部署
微服務架構中的每個服務都解決了應用中的業務問題，或至少支持一個。一個團隊對應用中的一個或多個服務負責。
微服務架構可以解鎖許多好處。
- 它們通常更容易構建和維護
- 服務是圍繞業務問題組織的
- 它們可以提高生產力和速度
- 它們鼓勵自主、獨立的團隊
這些好處是微服務越來越受歡迎的一個重要原因。但有一些可能會破壞這些好處的坑。如果不小心掉進去了，你將得到一個不斷產生技術債的架構。
微服務之間的通信就是一個坑，假如不提前考慮就會造成嚴重的破壞。
該體系結構的目標是創建松散耦合的服務，並且通信在實現這一目標中起着關鍵作用。在本文中，我們將重點關注在微服務架構中進行通信的三種方式，每一種都有其自己的利弊和權衡。
HTTP通信
選擇服務如何相互通信時，最直接的方式往往是 HTTP。事實上，我們可以提出一個案例，即所有通信渠道都來自這個渠道。但是除此之外，服務之間的 HTTP 調用是服務到服務通信的可行選擇。
如果我們的架構中有兩個服務，它可能看起來像這樣： ServiceA 可以請求並調用 ServiceB 來獲取另一條信息。
function process(name: string): Promise<boolean> { /** do some ServiceA business logic .... .... */ /** * call ServiceB to run some different business logic */ return fetch('https://service-b.com/api/endpoint') .then((response) => { if (!response.ok) { throw new Error(response.statusText) } else { return response.json().then(({saved}) => { return saved }) } }) }這是一段很容易理解的適合微服務架構的代碼。 ServiceA 提供了一個業務邏輯。它運行其代碼然后調用 ServiceB 來運行另一個業務邏輯。在這段代碼中，第一個服務在返回之前完成等待第二個服務完成。
這里有兩個服務之間進行同步的 HTTP 調用。這是一種可行的通信模式，但它確實在兩種服務之間建立了耦合。
另一個選擇是異步 HTTP。這可能是這樣的：
function asyncProcess(name: string): Promise<string> { /** do some ServiceA business logic .... .... */ /** * call ServiceB to run some different business logic */ return fetch('https://service-b.com/api/endpoint') .then((response) => { if (!response.ok) { throw new Error(response.statusText) } else { return response.json().then(({statusUrl}) => { return statusUrl }) } }) }這種變化是微妙的。現在， ServiceB 不返回 saved 屬性，而是返回一個 statusUrl。這意味着此服務現在正在接收來自第一個服務的請求，並且立即返回一個URL。此 URL 可用來檢查請求的進度。
將兩種服務之間的通信從同步轉換為異步，第一個服務不再停留等待第二個服務完成，然后再返回其工作。
通過這種方法可以使服務彼此隔離，並且耦合松散。
缺點是需要在第二個服務上創建額外的 HTTP 請求，它從外部進行輪詢，直到請求完成。這也引入了客戶端的復雜性，因為必須檢查請求的進度。
但是，異步通信允許服務直接保持松散耦合。
消息通信
另一種通信模式是基於消息的通信。
與HTTP通信不同，所涉及的服務不直接相互通信。相反，服務將消息推送到其他服務訂閱的消息代理。這消除了許多與 HTTP 通信相關的復雜性。
它不需要服務知道該如何相互交流，它消除了直接相互調用的服務需求。相反，所有服務都知道消息代理，並且它們將消息推送到該代理。其他服務可以訂閱代理中自己關心的消息。
如果我們的應用在 Amazon Web Services 中，可以用簡單通知服務（SNS）作為消息代理。現在 ServiceA 可以將消息推送到 ServiceB 監聽的 SNS 主題。
function asyncProcessMessage(name: string): Promise<string> { /** do some ServiceA business logic .... .... */ /** * send message to SNS that ServiceB is listening on */ let snsClient = new AWS.SNS() let params = { Message: JSON.stringify({ 'data': 'our message data' }), TopicArn: 'our-sns-topic-message-broker' } return snsClient.publish(params) .then((response) => { return response.MessageId }) }ServiceB 偵聽 SNS 主題上的消息，當收到一個關心的消息時，就會執行它的業務邏輯。
這引入了它自己的復雜性。請注意，ServiceA 不再接收狀態 URL 檢查進度。這是因為我們只知道消息已經被發送，而不知道 ServiceB 是否已經收到了它。
這可以通過許多不同的方式解決。一種方法是將 MessageId 返回給調用者。可以用它來查詢 ServiceB，它將存儲它收到的消息的 MessageId。
注意，使用此模式的兩個服務之間仍然存在一些耦合。例如，ServiceB 和 ServiceA 必須就消息結構的定義以及其中包含什么達成一致。
廣州品牌設計公司https://www.houdianzi.com PPT模板下載大全https://redbox.wode007.com
事件驅動的通信
最后一種模式是事件驅動模式。這是另一種異步方法，它看起來完全消除了服務之間的耦合。
與消息傳遞模式不同，事件驅動方法不需要服務必須知道公共消息結構。服務之間的通信通過各個服務產生的事件進行。
此處仍然需要消息代理，因為各個服務會將其事件寫入其中。但是與消息方法不同，消費服務不需要知道事件的細節，它們對事件的發生做出反應，而不是產生能會或可能不會傳遞的信息。
在形式上，這通常被稱為“僅事件驅動的通信”。下面的代碼和消息傳遞方法類似，但推送到SNS的事件是通用的。
function asyncProcessEvent(name: string): Promise<string> { /** do some ServiceA business logic .... .... */ /** * call ServiceB to run some different business logic */ let snsClient = new AWS.SNS() let params = { Message: JSON.stringify({ 'event': 'service-a-event' }), TopicArn: 'our-sns-topic-message-broker' } return snsClient.publish(params) .then((response) => { return response.MessageId }) }注意，我們的 SNS 主題消息是一個簡單的 event 屬性。每個服務都同意以這種格式將事件推送到代理，這使得通信松散耦合。服務可以監聽他們關心的事件，並且提供為響應它們而需要運行的邏輯。
此模式使服務的耦合松散，因為事件中不包含任何有效負載。此方法中的每個服務都會響應事件的發生並運行其業務邏輯。在這里，我們通過 SNS 主題發送事件。也可以使用其他事件，例如文件上傳或數據庫行更新。
結論
這些是基於微服務的架構中所有可能的通信模式嗎？當然不是。基於同步和異步模式進行通信的方式還有很多種。但是這三個突出了支持同步與異步的優缺點。在選擇時要考慮耦合因素，但也需要考慮開發和調試的具體情況與注意事項。