歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
本文來自雲+社群翻譯社，由使用者1196457編譯。
微服務是一種架構範例。在這種架構中，多個小型獨立元件協同工作，從而構成一個系統。儘管它的操作複雜性較高，但這種正規化已經被迅速採用。這是因為它有助於將複雜的系統分解為可管理的服務。這些服務更關注微觀層面的問題，包括單一責任，關注點分離，模組化等。
微服務模式是一個系列部落格。每篇博文都將聚焦一種微服務的架構模式，分析其可行性並概述它們適用的場景。所有這一切都要遵守各系統間相互制約的設計約束。
服務間通訊和執行流程是分散式系統的基礎，它可以是同步的也可以是非同步的。這兩種方法都有其利弊，本部落格試圖詳細剖析各種選擇並分析其影響。
維度
每種實現方式都可以從多種維度進行權衡。從這些維度對權衡點和系統約束進行評估，有助於我們分析其可行性和適用性。每種實現方式都有折衷。與此同時，考慮中的系統可能有各種各樣的維度。根據這些限制評估取捨可以幫助我們推斷方法和適用性。系統的各個維度都會影響系統的執行流程和通訊方式，下面我們來看看其中的一些維度。
消費者
系統的消費者可以是外部程式，網頁/手機介面，物聯網裝置等。消費者應用程式通常會同步處理伺服器，並期望介面支援。用消費者的統一介面掩蓋分散式系統的複雜性也是可取的，必要條件是，我們的通訊方式選擇能帶來便利。
工作流管理
業務工作流貫穿多個服務，因此，業務工作流的管理至關重要。它可以是隱含的，並且可以發生在每個服務上，因此仍然分佈在各個服務中。換言之，它可以是明確的。協調器服務可以承擔協調業務流程的責任。編排是兩者的結合。工作流規範規定了執行順序和對服務的實際呼叫。協調器與參與服務遵循的通訊正規化緊密相關。通訊風格和執行流程推動了協調器的實現。
第三個選項是基於事件編排的設計，通過一個將所有服務繫結的事件匯流排來代替編排器。
所有這些都是系統中的工作流管理機制，我們將在本系列的後續篇章詳細介紹工作流程管理。在我們評估和選擇通訊方式時，我們會考慮當前上下文中與其相關的約束條件。
讀/寫頻率偏差
系統的讀/寫頻率可能是其體系結構中的關鍵因素。一個讀取繁重的系統需要大部分操作同步完成。一個很好的例子就是大規模運營的天氣預報服務的公共API。或者，寫入繁重的系統可從非同步執行中受益。一個例子就是一個平臺，無數物聯網裝置都在不斷報告資料。當然，它們之間也有系統。由於讀寫偏斜，有時候傾向於一種風格是有用的。在其他時候，將讀取和寫入拆分為單獨的元件可能是有意義的。
在我們審視各種方法時，我們需要保持這些約束。這些維度將幫助我們提取每種實現方式的適用性。
同步
同步通訊是呼叫方等待響應可用的通訊方式，是一個突出並得到廣泛使用的方法。簡單且直觀的概念使其適用於大多數情況。
同步通訊與HTTP協議密切相關。但是，其他協議仍然是實現同步通訊的合理方式。另一個很好的例子是RPC呼叫，每個元件都公開一個其他服務所呼叫的同步介面。
入口點附近的攔截器攔截業務流程請求，然後將請求推送到下游服務，所有的後續呼叫本質上都是同步的。這些呼叫可以是並行或順序的，直到處理完成。系統內的呼叫處理可能會有不同的方式。一個編排者可以顯式排程所有的呼叫，或者呼叫可以跨元件有機地滲透。下面我們看看幾個可能的機制。
變化
在同步系統中，架構可以採用幾種方法，以下簡要說明各種方法的可行性。
去中心化和同步
去中心化的同步通訊方式在入口點攔截流量，攔截器將請求轉發到下一步並等待響應，該迴圈一直下行，直到所有服務都已完成執行，每個服務可以順序或並行執行一個或多個下游服務。
雖然實現很簡單，但流程細節分佈在整個系統中，從而導致元件之間的耦合。
這些呼叫在整個系統中保持同步。因此，這種通訊方式可以滿足同步消費者的期望。由於分散式工作流的性質，該方式缺少靈活性，並不適用於經常更改的複雜工作流。由於對系統的每個請求都可能阻塞服務，因此對於讀/寫頻率高的系統來說，這並不理想。
編排、同步和順序
同步通訊的一種變體帶有中央編排器，編排器仍然是攔截服務。它處理傳入的工作流定義請求並將其轉發到下游服務，並接受響應（如下圖所示）。在處理請求過程中，編排器一直在對服務進行呼叫。
在初始約束固定的情況下，工作流管理在這種方法中更加靈活。工作流更改對編排器來說仍然是本地化的，並保有一定的靈活性，由於通訊是同步的，所以同步消費者可以在沒有中介元件的情況下進行通訊。但是，編排器需要持續保持所有活動請求，這使得編排器比其他服務承擔更重的責任，也容易導致單點故障。這種風格的架構仍然適合讀取繁重的系統。
編排，同步和並行
在之前的方法基礎上的一個小改進是使獨立請求可以併發，這可以獲得更高的效率和效能。由於這個責任屬於編排器，所以很容易做到。工作流管理已經集中，需要做的只是更改宣告以區分並行和順序呼叫。這可以提高流程執行速度，通過縮短響應時間，協調器可以獲得更高的吞吐量。
工作流管理比以前的方法更復雜，但它仍然可能是一個合理的折衷方案，因為它可以提高吞吐量和效能並同時保持消費者的通訊同步。由於其同步特性，該系統對於讀取型架構來說仍然更好。
權衡
儘管同步呼叫更易於掌控，除錯和實現，但在分散式環境中實施則需要一些權衡。
平衡能力
它要求有意平衡所有服務的能力。一個元件上的流量激增可能淹沒其他服務請求。在非同步通訊中，佇列可以緩解流量激增。同步通訊缺少這種中介，需要服務容量在流量激增期間進行匹配。如果做不到這一點，可能會出現級聯故障。另外，像斷路器這樣的彈性範例可以幫助緩解同步系統中的流量激增。
級聯故障的風險
同步通訊使上游服務在微服務架構中容易出現級聯故障。如果下游服務出現故障或最壞情況，則需要很長時間才能迴應，資源會很快耗盡。這可能會導致系統產生多米諾骨牌效應。可能的緩解策略可能涉及一致的錯誤處理，合理的超時時間以及執行服務質量保障協議。在同步環境中，一個服務會立即影響到其他服務。如前所述，通過實施艙壁架構或斷路器可防止級聯錯誤。
增加負載平衡和服務發現開銷
通過將參與服務放置在負載均衡器後面可以解決其冗餘和可用性需求。這增加了每個服務的隔離級別。此外，每項服務都需要加入中央服務發現設定，這允許它推送它自己的地址並解析下游服務的地址。
耦合
同步系統會在一段時間內表現出更緊密的耦合。服務之間沒有抽象，服務直接和其他服務的合同繫結。這在一段時間內產生了強烈的關聯。對於合同中的簡單更改，擁有的服務不得不在早期採用版本控制。它增加了系統的複雜性，或者會導致與合同相關的所有消費者服務的變化。
隨著服務網格等新興架構範例的出現，有可能解決一些陳述的問題。Istio，Linkerd，特使等工具，允許服務網格建立。這個社群正在成熟並且充滿希望，它可以幫助構建同步的，解耦的和容錯的系統。
非同步
非同步通訊非常適合分散式體系結構。它不需要等待響應，從而將兩個或多個服務的執行分開。非同步通訊的實現有幾種方式，通過RPC（例如，grpc）或通過中介訊息匯流排直接呼叫遠端服務就是一些例子。編排訊息傳遞和事件編排都使用訊息匯流排通道。
中央訊息匯流排的一個優點是一致的通訊和訊息傳遞語義。這給服務間的直接非同步通訊帶來了巨大的便利。我們通常使用像訊息匯流排這樣的媒介來保證跨服務通訊的一致性。下面將基於使用中央訊息管道的假設來討論的非同步通訊的種類。
變體
非同步通訊可以更好地處理流量激增。體系結構中的每個服務都會生成訊息，消費訊息或執行兩者。我們來看看這種正規化的不同變體。
非同步事件協同
在這種方法中，每個元件監聽中央訊息匯流排並等待事件，事件的到來是執行的訊號，執行所需的任何上下文都是事件有效負載的一部分，觸發下游事件是每個服務所擁有的責任。基於事件的體系結構的目標之一是將元件分離，不幸的是，需要在設計層面滿足這種需求。
通知元件接受到事件時可能電子郵件或SMS傳送。由於所有其他服務需要做的事情是生產事件，因此它看起來可能是彼此分離的。但是，確實需要有元件承擔決定通知型別和內容的責任，通知可以根據傳入的事件資訊做出該決定，如果發生這種情況，我們就已經建立了通知和上游服務之間的耦合。如果上游服務將此作為有效負載的一部分，則他們仍然感覺到下游的流量。
即便如此，事件協同也非常適合需要發生的隱式操作。比如錯誤處理，通知，搜尋索引等。
這種體系結構遵循分散的工作流程管理。該體系結構適合寫入繁重的系統。缺點是同步讀取需要協調，並且工作流會在系統進行廣播。
編排、非同步和順序
我們可以從我們的協調同步通訊方法中借鑑一些。我們可以通過中央編排器建立非同步通訊。
每項服務都是中央訊息匯流排的生產者和消費者。編排器的職責是將訊息路由到他們相應的服務。每個元件消費一個傳入事件或訊息，並在訊息佇列上生成響應。編排器消耗此響應並進行轉換，然後再前進到下一步。該迴圈繼續，直到指定的工作流程達到系統中的最後一個狀態。
在這種風格下，工作流管理對於編排器來說是本地的。這種系統在處理寫入流量很大時有很好的表現，同步消費者需要調解。這在所有非同步通訊變體中都很流行。
在編排系統中，協同耦合問題的解決方案更加優雅。在這種情況下，工作流工作在編排器上，豐富的工作流規範可以捕獲通知型別和內容模板等資訊，對工作流程的任何更改都保留在編排器服務中。
編排和事件協同混合使用
另一個成功的變體是具有編排和事件協同的混合系統。編排非常適合顯示的工作流執行，而協同可以處理隱式執行。在工作流程中執行葉節點可能是隱含的，工作流規範可以促進在特定步驟中發生事件，這可能會導致執行任務，如通知，索引等等，編排可以繼續推動顯式執行。
這兩種方法的融合提供了近乎完美的方案，雖然仍需要採取預防措施以確保它們不會責任重疊，並且明確邊界以決定它們的功能。
概述
非同步風格的體系結構解決了同步體系結構系統所具有的一些缺陷。非同步結構在處理突發大量請求時表現更好。中央佇列允許服務趕上合理的請求積壓，當很多請求在短時間內出現或者服務暫時關閉時，這是非常有用的。
每個服務都以消費者或生產者的身份連線到訊息佇列，只有訊息佇列需要服務發現。因此，對中央服務發現解決方案的需求不那麼緊迫。此外，由於服務的多個例項連線到佇列，因此不需要外部負載平衡，這可以防止負載平衡器引入導致的隔離級別提升。它還使服務能夠無縫線擴充套件。
權衡
本質上是非同步的服務流可能很難通過系統進行跟蹤。採用非同步通訊的系統會有一些折衷，我們來看看其中的一些權衡點。
更高的系統複雜性
非同步系統往往比同步系統複雜得多。然而，系統的複雜性和效能以及規模的要求是合理的開銷。一旦採用協調器和單個元件，就需要接受非同步執行。
讀取/查詢需要中介
除非專門處理，否則同步消費者受非同步體系結構的影響最大。要麼消費者適應非同步系統的工作，要麼系統為消費者提供同步介面。
非同步架構非常適合寫入繁重的系統。但是，它需要協調讀取/查詢同步，有幾種方法來管理這種需求，每種都有一定的複雜性。
同步包裝
所有方法中最簡單的是在非同步系統上構建同步包裝。這是一個可以呼叫下游非同步流程的入口點。同時，它儲存等待的請求，直到響應返回或發生超時。同步包裝是一個有狀態的元件。傳入的請求將自己繫結到它所在的伺服器上。來自下游服務的響應需要到達原始請求正在等待的伺服器。這對分散式系統來說並不理想，尤其是那種大規模執行的系統。但是，編寫起來很簡單，而且易於管理。這種方法符合具有合理的縮放和效能需求的系統的需求。在進行更為劇烈的重構之前，可以考慮同步封裝。
CQRS
CQRS是一種將讀取與寫入分離的架構風格。CQRS給系統帶來了大量的風險和複雜性，它非常適合大規模執行並需要大量讀取和寫入的系統。在CQRS體系結構中，資料從寫資料庫流向讀資料庫，查詢在讀取優化的資料庫上執行，讀/寫層是分開的，系統保持最終一致性。兩個層的優化是獨立的。這樣的系統結構更復雜，但可以具有更大的規模。而且，元件可以保持無狀態（與同步包裝不同）。
雙重支援
在同步包裝器和CQRS實現之間有一箇中間地帶，每個服務/元件都可以支援同步查詢和非同步寫入，這適用於中等規模執行的系統。所以讀取查詢可以在元件之間跳轉以完成同步讀取。另一方面，寫入系統將流入非同步通道。這裡有一個權衡，對系統的讀和寫進行獨立優化是不可能的，或者，這對於在高流量下執行的系統是有益的。
訊息匯流排是故障的中心點
這不是一種折衷，而是一種預防措施。在非同步通訊方式中，訊息匯流排是系統的支柱，所有的服務都不斷地從訊息匯流排上生產和消費。這使得訊息匯流排成為系統的致命弱點, 因為它仍然是故障的中心點。訊息匯流排支援橫向擴充套件非常重要，否則它可能違背分散式系統的目標。
最終一致性
非同步系統可以是最終一致性，這意味著查詢結果可能不是最新的，即使系統已經發布了寫入。雖然這種權衡可以讓系統更好地擴充套件，但也需要同時考慮系統設計和使用者體驗。
混合
可以同時使用非同步和同步通訊，但這兩種方法的權衡會壓倒他們的優勢。一方面，系統必須交換處理兩種通訊風格，同步呼叫會導致級聯降級和失敗。另一方面，非同步通訊會增加設計的複雜性。根據我的經驗，選擇單一方式對於系統設計來說更加富有成效。
結語
馬丁福勒有一個關於如何構建微服務的偉大部落格。一旦決定構建微服務架構，需要仔細審議其執行流程風格。對於寫入繁重系統來說，帶有同步包裝的非同步系統是最佳選擇。而對於讀取繁重系統，同步通訊就很好。
對於讀寫繁重，但具有適度規模要求的系統而言，同步設計將大大簡化設計。如果一個系統具有顯著的規模和效能需求，那麼使用CQRS模式的非同步設計是一種可選方案。
騰訊雲分散式微服務
騰訊分散式微服務TSF圍繞應用和微服務的PaaS平臺，提供服務全生命週期管理能力和資料化運營支援，提供多維度應用、服務、機器的監控資料，助力服務效能優化；擁抱 Spring Cloud 開源社群技術更新和K8s容器化部署。
詳見 cloud.tencent.com/product/tsf
問答
相關閱讀
此文已由作者授權騰訊雲+社群釋出，原文連結：https://cloud.tencent.com/developer/article/1152802?fromSource=waitui
歡迎大家前往騰訊雲+社群或關注雲加社群微信公眾號（QcloudCommunity），第一時間獲取更多海量技術實踐乾貨哦~