建站
咨詢
售后
建站咨詢
新聞中心
在微服務架構的世界中，我們通過一系列服務構建應用。集合中的每項服務都符合以下標準：
站在用戶的角度思考問題，與客戶深入溝通，找到貴定網站設計與貴定網站推廣的解決方案，憑借多年的經驗，讓設計與互聯(lián)網技術結合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：做網站、成都網站設計、企業(yè)官網、英文網站、手機端網站、網站推廣、空間域名、網絡空間、企業(yè)郵箱。業(yè)務覆蓋貴定地區(qū)。
- 松散耦合
- 可維護和可測試
- 可以獨立部署
微服務架構中的每個服務都解決了應用中的業(yè)務問題，或至少支持一個。一個團隊對應用中的一個或多個服務負責。
微服務架構可以解鎖許多好處。
- 它們通常更容易構建和維護
- 服務是圍繞業(yè)務問題組織的
- 它們可以提高生產力和速度
- 它們鼓勵自主、獨立的團隊
這些好處是微服務越來越受歡迎的一個重要原因。但有一些可能會破壞這些好處的坑。如果不小心掉進去了，你將得到一個不斷產生技術債的架構。
微服務之間的通信就是一個坑，假如不提前考慮就會造成嚴重的破壞。
該體系結構的目標是創(chuàng)建松散耦合的服務，并且通信在實現(xiàn)這一目標中起著關鍵作用。在本文中，我們將重點關注在微服務架構中進行通信的三種方式，每一種都有其自己的利弊和權衡。
HTTP通信
選擇服務如何相互通信時，最直接的方式往往是 HTTP。事實上，我們可以提出一個案例，即所有通信渠道都來自這個渠道。但是除此之外，服務之間的 HTTP 調用是服務到服務通信的可行選擇。
如果我們的架構中有兩個服務，它可能看起來像這樣： ServiceA 可以請求并調用 ServiceB 來獲取另一條信息。
- function process(name: string): Promise
{ - /** 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
{ - /** 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
- })
- }
- })
- }
這種變化是微妙的。現(xiàn)在， ServiceB 不返回 saved 屬性，而是返回一個 statusUrl。這意味著此服務現(xiàn)在正在接收來自第一個服務的請求，并且立即返回一個URL。此 URL 可用來檢查請求的進度。
將兩種服務之間的通信從同步轉換為異步，第一個服務不再停留等待第二個服務完成，然后再返回其工作。
通過這種方法可以使服務彼此隔離，并且耦合松散。
缺點是需要在第二個服務上創(chuàng)建額外的 HTTP 請求，它從外部進行輪詢，直到請求完成。這也引入了客戶端的復雜性，因為必須檢查請求的進度。
但是，異步通信允許服務直接保持松散耦合。
消息通信
另一種通信模式是基于消息的通信。
與HTTP通信不同，所涉及的服務不直接相互通信。相反，服務將消息推送到其他服務訂閱的消息代理。這消除了許多與 HTTP 通信相關的復雜性。
它不需要服務知道該如何相互交流，它消除了直接相互調用的服務需求。相反，所有服務都知道消息代理，并且它們將消息推送到該代理。其他服務可以訂閱代理中自己關心的消息。
如果我們的應用在 Amazon Web Services 中，可以用簡單通知服務(SNS)作為消息代理?，F(xiàn)在 ServiceA 可以將消息推送到 ServiceB 監(jiān)聽的 SNS 主題。
- function asyncProcessMessage(name: string): Promise
{ - /** 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 檢查進度。這是因為我們只知道消息已經被發(fā)??送，而不知道 ServiceB 是否已經收到了它。
這可以通過許多不同的方式解決。一種方法是將 MessageId 返回給調用者?？梢杂盟鼇聿樵?ServiceB，它將存儲它收到的消息的 MessageId。
注意，使用此模式的兩個服務之間仍然存在一些耦合。例如，ServiceB 和 ServiceA 必須就消息結構的定義以及其中包含什么達成一致。
事件驅動的通信
最后一種模式是事件驅動模式。這是另一種異步方法，它看起來完全消除了服務之間的耦合。
與消息傳遞模式不同，事件驅動方法不需要服務必須知道公共消息結構。服務之間的通信通過各個服務產生的事件進行。
此處仍然需要消息代理，因為各個服務會將其事件寫入其中。但是與消息方法不同，消費服務不需要知道事件的細節(jié)，它們對事件的發(fā)生做出反應，而不是產生能會或可能不會傳遞的信息。
在形式上，這通常被稱為“僅事件驅動的通信”。下面的代碼和消息傳遞方法類似，但推送到SNS的事件是通用的。
- function asyncProcessEvent(name: string): Promise
{ - /** 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ā)和調試的具體情況與注意事項。
本文題目：微服務的三種通信方法
文章URL：http://www.dlmjj.cn/article/dphispj.html
