微服務集成中的三個常見缺陷,以及如何避免它們
微服務風靡一時。他們有一個有趣的價值主張，即在與多個軟件開發團隊共同開發的同時，將軟件快速推向市場。因此，微服務是在擴展您的開發力量的同時保持高敏捷性和快速的開發速度。
簡而言之，您將系統分解為微服務。分解并不是什么新鮮事，但是通過微服務，您可以為團隊提供盡可能多的自主權。
例如，專用團隊完全擁有該服務，可以隨時部署或重新部署。他們通常也會使用devops來控制整個服務。他們可以做出相當自主的技術決策并運行他們自己的基礎設施數據庫。被迫操作軟件通常會限制有線技術選擇的數量，因為當人們知道他們將來必須操作它時，往往會更頻繁地選擇無聊技術。
Microservices are about decomposition, but giving each component a high degree of autonomy and isolation (微服務是關于分解，但為每個組件提供高度自治和隔離)
微服務架構的一個基本結果是每個微服務都是與其他微服務遠程通信的獨立應用程序。這使得微服務環境成為高度分散的系統。分布式系統有其自身的挑戰。在本文中，我將向您介紹我在最近的項目中看到的三個最常見的陷阱。
1.溝通很復雜
遠程通信不可避免地要尊重分布式編程的8個謬誤。隱藏復雜性是不可能的，并且許多努力（例如Corba或RMI）已經失敗了。一個重要原因是您必須在服務中設計失敗，以便在失敗是新常態的環境中取得成功。但是有一些共同的模式和框架可以幫助你。讓我們從一個例子開始 - 我經常遇到的真實情況。
我想飛往倫敦。當我收到辦理登機手續的邀請時，我去了航空公司的網站，選擇了我的座位，然后按下按鈕取回我的登機牌。它給了我以下回應：
讓我們假設航空公司使用微服務（可能不是這種情況，但我知道有其他航空公司這樣做）。
我注意到的第一件事：錯誤返回得相當快，網站的其他部分表現正常。所以他們使用了重要的失敗快速模式。條形碼生成中的錯誤不會影響整個網站。我可以做其他一切;我無法獲得登機牌。快速失敗非常重要，因為它可以防止本地錯誤導致整個系統崩潰。該領域眾所周知的模式是斷路器，隔板和維修網。這些模式對分布式系統的生存至關重要。
快速失敗是不夠的
但快速失敗是不夠的。它將故障處理卸載到客戶端。在這種情況下，我個人不得不重試。在上述情況下，我甚至要等到第二天，直到問題得到解決，我才能拿到登機牌！對我而言，這意味著我必須使用自己的工具來堅持重試（我的日歷），以確保我沒有忘記。
為什么航空公司不自行重試？他們知道我的聯系數據，并且可以在準備好時異步發送登機牌。更好的反應是：
這不僅會更方便，而且還會降低總體復雜性，因為需要查看故障的組件數量會減少：
您可以將相同的原則轉移到服務到服務通信。每當服務本身可以解決故障時，它就會封裝重要的行為。這使得所有客戶的生活更加輕松，API更加清潔。解決故障可能是有狀態的（有些人稱之為長時間運行）。我認為狀態處理是微服務中故障處理的關鍵問題。
當然，上面描述的行為并不總是你想要的，將故障移交給客戶端就可以了。但這應該是根據業務需求做出的有意識的決定。
我觀察到大多數情況下，另一個原因導致人們避免有狀態重試：它伴隨著狀態處理的復雜性。該服務必須重試幾分鐘，幾小時或幾天。它必須可靠地執行此操作（請記住：即使系統重新啟動，我也希望登機牌），這涉及處理持久狀態。
如何管理持久狀態？
我看到兩種處理持久狀態的典型方法：
存儲在數據庫中的實體等持久性事物。
雖然這開始非常簡單，但通常會導致很多意外的復雜性。您不僅需要數據庫表，還需要一些調度程序組件來進行重試。您可能需要一些監視組件來查看或編輯等待作業。如果整體業務邏輯發生變化，您仍需要進行版本控制，而您仍想進行重試。等等等等。
這種思路導致許多開發人員如上所述跳過正確的故障處理，導致整個架構的復雜性增加 - 以及糟糕的客戶體驗。
相反，我建議利用輕量級工作流引擎或狀態機。
構建這些引擎是為了保持持久狀態并處理圍繞流語言，監視和操作的后續要求，擴展以處理高容量等等。
市場上有幾個輕量級工作流引擎。他們中的許多人使用ISO標準BPMN來定義流，其中許多是開源的。在這里，我將使用Camunda的開源工作流引擎來說明基本原則（快速免責聲明：作為該項目背后的公司的共同創始人，我明顯偏向于我的工具選擇，但這是我最熟悉的工作流引擎）。對于前面描述的簡單用例，可以使用Java DSL輕松創建工作流：
另一種選擇是在BPMN中以圖形方式建模工作流程：
這些工作流引擎在架構方面非常靈活。許多開發人員認為工作流引擎是一個集中組件，但事實并非如此。沒有必要引入集中組件！如果不同的服務需要工作流引擎，則每個服務都可以運行自己的引擎來維護服務的自治和隔離。本博文中有關架構選項的更多細節將對此進行詳細討論。
另一個誤解是工作流迫使開發人員切換到異步處理。這也不是真的。在上面的示例中，當一切順利運行時，登記組件可以同步返回登機牌。只有在出現錯誤時才會回退到異步處理。這可以很容易地反映為HTTP返回碼，200表示“一切正常，這是你的結果”，202表示“得到它，我會給你回電話。”有一些具體的示例代碼來處理這個，它利用了一個簡單的信號。
我將工作流引擎視為工具箱的重要組成部分，用于正確的故障處理，這通常涉及長期運行的行為，如狀態重試。
2.異步性需要注意
這導致我們進行異步通信，這通常意味著消息傳遞。異步性通常被認為是分布式系統中的最佳默認值，因為它提供了解耦，尤其是時間解耦，因為任何消息都可以獨立于接收器的可用性發送。一旦服務提供商可用，該消息將立即發送，而無需額外的魔力。
因此，重試的問題已經過時，但會出現類似的問題：您必須擔心超時問題。假設航空公司在登記方案中使用異步通信。登記組件向條形碼生成服務發送消息，然后等待響應。您無需關心條形碼生成器的可用性，因為消息總線將在適當的時候傳遞消息。
但是，如果請求或響應因任何原因而丟失怎么辦？您是否會在辦理登機手續時遇到困難，未能在沒有注意到的情況下將登機牌發送給客戶？我打賭很多公司這樣做，這再次導致我，客戶監控響應并采取行動，如果沒有登機牌在超時內到達。同樣，我必須利用我的個人調度基礎設施（日歷）。
更好的方法是讓服務監控超時本身，并在條形碼未能及時到達時執行回退。可能的后備是重新發送消息，這實質上是重試。
您也可以利用工作流自動化技術來處理此用例。BPMN中的工作流可能如下所示：
作為獎勵，您可以免費報告重試次數，典型響應時間以及無法及時處理的工作流程數量。操作員可以通過提供大量上下文來輕松檢查和修復失敗的工作流實例，例如消息中包含的數據以及消息發送的時間。純粹的基于消息的解決方案通常會忽略這種級別的可見性和操作控制。
我甚至看到公司更進一步，使用工作流引擎而不是消息傳遞中間件來在微服務之間分配工作。如果工作流引擎不主動調用服務或發送消息（稱為推送原則）但依賴于工作者要求工作（稱為拉取原則），則這是可能的。現在，工作流引擎中的工作隊列就像一個消息隊列。當我問他們為什么喜歡工作流引擎時，他們說消息傳遞解決方案缺乏相同的可見性和工具質量，他們希望避免構建自己的操作工具。
3.分布式交易很難
事務是以全有或全無的方式執行的一系列操作。我們都從數據庫中知道這一點。您開始一個事務，做一些事情，然后提交或回滾事務。這些事務稱為ACID：原子，一致，隔離和持久。
在分布式系統中，您不能指望ACID事務。是的，有像XA這樣的協議實現了所謂的兩階段提交。或WS-AtomicTransaction。或像Google Spanner這樣復雜的實施。但目前的共識是，這些協議太昂貴，太復雜，或者根本無法擴展。Pat Helland的“超越分布式交易的生活：Apostate的意見”是一個很好的背景閱讀。
但當然，商業交易的要求并沒有消失。在沒有ACID的情況下解決業務交易的常見技巧是使用補償。這意味著您可以對過去不正確執行的所有活動執行撤消活動。BPMN具有此內置功能，因此您可以定義這些撤消活動，并且工作流引擎負責以正確的順序可靠地執行它們。這次我將使用預訂機票的例子：
這通常也被稱為Saga模式，最近變得非常流行。我在“Saga：如何在沒有兩階段提交的情況下實現復雜的業務交易”中寫到了這一點，其中我還鏈接了其他來源和一些代碼。
請注意，此方法與ACID事務不同，因為您可以具有不一致的中間狀態。所以，我可以保留一個座位，但尚未預訂有效的機票。或者我可以在沒有付款的情況下買票。實際情況是，只要確保最終清理它們并使系統恢復到一致狀態，通常可以忍受這些暫時的不一致。這稱為最終一致性，這是分布式系統中的一個重要概念。“在SoA網絡中擁抱最終的一致性”指出它非常好：
最終的一致性通常會產生更好的性能，更簡單的操作和更好的可伸縮性，同時要求程序員理解更復雜的數據模型。
好消息是工作流程自動化簡化了補償的處理。這是因為工作流引擎可以可靠地調用所有必要的補償活動。
服務提供商 - 做好功課！
到目前為止，我已經提出了三種簡單的補救措施來應對分布式系
- 重試
- 超時
- 賠償金
所有這些都可以使用輕量級工作流自動化技術實現。但是為了利用這些配方，每個服務提供商都必須做好功課。這意味著
- 提供補償活動和
- 實現冪等性。
雖然第一個要求應該是顯而易見的（如果有取消票證的服務，我只能取消票證），第二個 - 冪等性 - 需要更多解釋。
冪等
我談了很多關于重試的事情。一個常見的問題是，如果我通過重試兩次調用服務怎么辦？這個問題問得好！
首先要確保您了解每種形式的遠程通信都會遇到此問題！無論何時通過網絡進行通信，都無法區分三種故障情形：
- 該請求尚未到達提供商
- 請求已到達提供商，但在處理期間它已爆炸
- 提供程序處理了請求，但響應丟失了
一種可能性是詢問服務提供商是否已經看到此請求。但更常見的方法是使用重試并以允許重復調用的方式實現服務提供程序。這更容易設置。
我看到兩種簡單的方法來掌握冪等性：
- 自然的冪等性。有些方法可以隨意執行，因為它們只是翻轉一些狀態。示例：confirmCustomer（）
- 商業冪等。有時，您擁有允許您檢測重復呼叫的業務標識符。示例：createCustomer（email）
如果這些方法不起作用，您需要添加自己的冪等性處理：
- 唯一身份。您可以生成唯一標識符并將其添加到呼叫中。這樣，如果您在服務提供商端存儲該ID，則可以輕松發現重復呼叫。如果您利用工作流引擎，您可能會讓它完成繁重的工作（例如，當Camunda允許在啟動期間對密鑰進行重復檢查時）。示例：charge（transactionId，amount）
- 請求哈希。如果您使用消息傳遞，則可以通過存儲消息的哈希值來執行相同的操作。您可以再次利用工作流引擎，或者您可以使用具有內置租賃功能的數據庫（如Redis）。
長話短說：在您的服務中注意冪等性。這將帶來巨大的回報。
給我看一下代碼
您可以使用BPMN和開源Camunda引擎找到實現我在此描述的模式的源代碼
Java或C＃。(需要的后臺發消息)
摘要
在本文中，我介紹了三個常見的陷阱，我看到客戶在整合微服務時踩到了：低估了遠程通信的復雜性，忽略了異步性的挑戰，忘記了商業交易。
通過重試，超時和補償活動的狀態模式引入處理這些情況的功能可以降低微服務基礎架構的整體復雜性并增強其彈性。它還有助于：
- 將重要的故障處理和事務行為封裝在它所屬的位置：在服務本身的上下文中。
- 將故障或超時處理的工作量減少到更小的范圍，從而降低整體復雜性。
- 簡化服務API，只發布對客戶真正重要的故障。
- 改善客戶體驗，客戶可能是其他服務，內部員工，甚至是客戶。
使用輕量級工作流引擎，您可以通過應用自行開發的解決方案來處理有狀態模式，而無需投入大量精力或冒著意外復雜性的風險。隨附的源代碼提供了具體示例。
