微服務的三種通信方法
在微服務架構的世界中，我們通過一系列服務構建應用。集合中的每項服務都符合以下標準：
- 松散耦合
- 可維護和可測試
- 可以獨立部署
微服務架構中的每個服務都解決了應用中的業務問題，或至少支持一個。一個團隊對應用中的一個或多個服務負責。
微服務架構可以解鎖許多好處。
- 它們通常更容易構建和維護
- 服務是圍繞業務問題組織的
- 它們可以提高生產力和速度
- 它們鼓勵自主、獨立的團隊
這些好處是微服務越來越受歡迎的一個重要原因。但有一些可能會破壞這些好處的坑。如果不小心掉進去了，你將得到一個不斷產生技術債的架構。
微服務之間的通信就是一個坑，假如不提前考慮就會造成嚴重的破壞。
該體系結構的目標是創建松散耦合的服務，并且通信在實現這一目標中起著關鍵作用。在本文中，我們將重點關注在微服務架構中進行通信的三種方式，每一種都有其自己的利弊和權衡。
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
- })
- }
- })
- }
這種變化是微妙的?，F在， ServiceB 不返回 saved 屬性，而是返回一個 statusUrl。這意味著此服務現在正在接收來自第一個服務的請求，并且立即返回一個URL。此 URL 可用來檢查請求的進度。
將兩種服務之間的通信從同步轉換為異步，第一個服務不再停留等待第二個服務完成，然后再返回其工作。
通過這種方法可以使服務彼此隔離，并且耦合松散。
缺點是需要在第二個服務上創建額外的 HTTP 請求，它從外部進行輪詢，直到請求完成。這也引入了客戶端的復雜性，因為必須檢查請求的進度。
但是，異步通信允許服務直接保持松散耦合。
消息通信
另一種通信模式是基于消息的通信。
與HTTP通信不同，所涉及的服務不直接相互通信。相反，服務將消息推送到其他服務訂閱的消息代理。這消除了許多與 HTTP 通信相關的復雜性。
它不需要服務知道該如何相互交流，它消除了直接相互調用的服務需求。相反，所有服務都知道消息代理，并且它們將消息推送到該代理。其他服務可以訂閱代理中自己關心的消息。
如果我們的應用在 Amazon Web Services 中，可以用簡單通知服務(SNS)作為消息代理?，F在 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 必須就消息結構的定義以及其中包含什么達成一致。
事件驅動的通信
最后一種模式是事件驅動模式。這是另一種異步方法，它看起來完全消除了服務之間的耦合。
與消息傳遞模式不同，事件驅動方法不需要服務必須知道公共消息結構。服務之間的通信通過各個服務產生的事件進行。
此處仍然需要消息代理，因為各個服務會將其事件寫入其中。但是與消息方法不同，消費服務不需要知道事件的細節，它們對事件的發生做出反應，而不是產生能會或可能不會傳遞的信息。
在形式上，這通常被稱為“僅事件驅動的通信”。下面的代碼和消息傳遞方法類似，但推送到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 主題發送事件。也可以使用其他事件，例如文件上傳或數據庫行更新。
結論
這些是基于微服務的架構中所有可能的通信模式嗎?當然不是?；谕胶彤惒侥Ｊ竭M行通信的方式還有很多種。
但是這三個突出了支持同步與異步的優缺點。在選擇時要考慮耦合因素，但也需要考慮開發和調試的具體情況與注意事項。
