[[275412]]

在微服務架構的世界中，我們通過一系列服務構建應用。集合中的每項服務都符合以下標準：

• 松散耦合
• 可維護和可測試
• 可以獨立部署

微服務架構中的每個服務都解決了應用中的業(yè)務問題，或至少支持一個。一個團隊對應用中的一個或多個服務負責。

微服務架構可以解鎖許多好處。

• 它們通常更容易構建和維護
• 服務是圍繞業(yè)務問題組織的
• 它們可以提高生產(chǎn)力和速度
• 它們鼓勵自主、獨立的團隊

這些好處是微服務越來越受歡迎的一個重要原因。但有一些可能會破壞這些好處的坑。如果不小心掉進去了，你將得到一個不斷產(chǎn)生技術債的架構。

微服務之間的通信就是一個坑，假如不提前考慮就會造成嚴重的破壞。

該體系結構的目標是創(chuàng)建松散耦合的服務，并且通信在實現(xiàn)這一目標中起著關鍵作用。在本文中，我們將重點關注在微服務架構中進行通信的三種方式，每一種都有其自己的利弊和權衡。

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 提供了一個業(yè)務邏輯。它運行其代碼然后調用 ServiceB 來運行另一個業(yè)務邏輯。在這段代碼中，第一個服務在返回之前完成等待第二個服務完成。

這里有兩個服務之間進行同步的 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(xiàn)在， ServiceB 不返回 saved 屬性，而是返回一個 statusUrl。這意味著此服務現(xiàn)在正在接收來自第一個服務的請求，并且立即返回一個URL。此 URL 可用來檢查請求的進度。

將兩種服務之間的通信從同步轉換為異步，第一個服務不再停留等待第二個服務完成，然后再返回其工作。

通過這種方法可以使服務彼此隔離，并且耦合松散。

缺點是需要在第二個服務上創(chuàng)建額外的 HTTP 請求，它從外部進行輪詢，直到請求完成。這也引入了客戶端的復雜性，因為必須檢查請求的進度。

但是，異步通信允許服務直接保持松散耦合。

消息通信

另一種通信模式是基于消息的通信。

與HTTP通信不同，所涉及的服務不直接相互通信。相反，服務將消息推送到其他服務訂閱的消息代理。這消除了許多與 HTTP 通信相關的復雜性。

它不需要服務知道該如何相互交流，它消除了直接相互調用的服務需求。相反，所有服務都知道消息代理，并且它們將消息推送到該代理。其他服務可以訂閱代理中自己關心的消息。

如果我們的應用在 Amazon Web Services 中，可以用簡單通知服務(SNS)作為消息代理。現(xiàn)在 ServiceA 可以將消息推送到 ServiceB 監(jiān)聽的 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 主題上的消息，當收到一個關心的消息時，就會執(zhí)行它的業(yè)務邏輯。

這引入了它自己的復雜性。請注意，ServiceA 不再接收狀態(tài) URL 檢查進度。這是因為我們只知道消息已經(jīng)被發(fā)​​送，而不知道 ServiceB 是否已經(jīng)收到了它。

這可以通過許多不同的方式解決。一種方法是將 MessageId 返回給調用者?？梢杂盟鼇聿樵?ServiceB，它將存儲它收到的消息的 MessageId。

注意，使用此模式的兩個服務之間仍然存在一些耦合。例如，ServiceB 和 ServiceA 必須就消息結構的定義以及其中包含什么達成一致。

事件驅動的通信

最后一種模式是事件驅動模式。這是另一種異步方法，它看起來完全消除了服務之間的耦合。

與消息傳遞模式不同，事件驅動方法不需要服務必須知道公共消息結構。服務之間的通信通過各個服務產(chǎn)生的事件進行。

此處仍然需要消息代理，因為各個服務會將其事件寫入其中。但是與消息方法不同，消費服務不需要知道事件的細節(jié)，它們對事件的發(fā)生做出反應，而不是產(chǎn)生能會或可能不會傳遞的信息。

在形式上，這通常被稱為“僅事件驅動的通信”。下面的代碼和消息傳遞方法類似，但推送到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 屬性。每個服務都同意以這種格式將事件推送到代理，這使得通信松散耦合。服務可以監(jiān)聽他們關心的事件，并且提供為響應它們而需要運行的邏輯。

此模式使服務的耦合松散，因為事件中不包含任何有效負載。此方法中的每個服務都會響應事件的發(fā)生并運行其業(yè)務邏輯。在這里，我們通過 SNS 主題發(fā)送事件。也可以使用其他事件，例如文件上傳或數(shù)據(jù)庫行更新。

結論

這些是基于微服務的架構中所有可能的通信模式嗎?當然不是?；谕胶彤惒侥Ｊ竭M行通信的方式還有很多種。

但是這三個突出了支持同步與異步的優(yōu)缺點。在選擇時要考慮耦合因素，但也需要考慮開發(fā)和調試的具體情況與注意事項。