微服務(wù)風(fēng)靡一時。他們有一個有趣的價值主張，即在與多個軟件開發(fā)團隊共同開發(fā)的同時，將軟件快速推向市場。因此，微服務(wù)是在擴展您的開發(fā)力量的同時保持高敏捷性和快速的開發(fā)速度。

簡而言之，您將系統(tǒng)分解為微服務(wù)。分解并不是什么新鮮事，但是通過微服務(wù)，您可以為團隊提供盡可能多的自主權(quán)。

例如，專用團隊完全擁有該服務(wù)，可以隨時部署或重新部署。他們通常也會使用devops來控制整個服務(wù)。他們可以做出相當自主的技術(shù)決策并運行他們自己的基礎(chǔ)設(shè)施數(shù)據(jù)庫。被迫操作軟件通常會限制有線技術(shù)選擇的數(shù)量，因為當人們知道他們將來必須操作它時，往往會更頻繁地選擇無聊技術(shù)。

Microservices are about decomposition, but giving each component a high degree of autonomy and isolation (微服務(wù)是關(guān)于分解，但為每個組件提供高度自治和隔離)

微服務(wù)架構(gòu)的一個基本結(jié)果是每個微服務(wù)都是與其他微服務(wù)遠程通信的獨立應(yīng)用程序。這使得微服務(wù)環(huán)境成為高度分散的系統(tǒng)。分布式系統(tǒng)有其自身的挑戰(zhàn)。在本文中，我將向您介紹我在最近的項目中看到的三個最常見的陷阱。

1.溝通很復(fù)雜

遠程通信不可避免地要尊重分布式編程的8個謬誤。隱藏復(fù)雜性是不可能的，并且許多努力（例如Corba或RMI）已經(jīng)失敗了。一個重要原因是您必須在服務(wù)中設(shè)計失敗，以便在失敗是新常態(tài)的環(huán)境中取得成功。但是有一些共同的模式和框架可以幫助你。讓我們從一個例子開始 - 我經(jīng)常遇到的真實情況。

我想飛往倫敦。當我收到辦理登機手續(xù)的邀請時，我去了航空公司的網(wǎng)站，選擇了我的座位，然后按下按鈕取回我的登機牌。它給了我以下回應(yīng)：

讓我們假設(shè)航空公司使用微服務(wù)（可能不是這種情況，但我知道有其他航空公司這樣做）。

我注意到的第一件事：錯誤返回得相當快，網(wǎng)站的其他部分表現(xiàn)正常。所以他們使用了重要的失敗快速模式。條形碼生成中的錯誤不會影響整個網(wǎng)站。我可以做其他一切;我無法獲得登機牌?？焖偈》浅Ｖ匾?，因為它可以防止本地錯誤導(dǎo)致整個系統(tǒng)崩潰。該領(lǐng)域眾所周知的模式是斷路器，隔板和維修網(wǎng)。這些模式對分布式系統(tǒng)的生存至關(guān)重要。

快速失敗是不夠的

但快速失敗是不夠的。它將故障處理卸載到客戶端。在這種情況下，我個人不得不重試。在上述情況下，我甚至要等到第二天，直到問題得到解決，我才能拿到登機牌！對我而言，這意味著我必須使用自己的工具來堅持重試（我的日歷），以確保我沒有忘記。

為什么航空公司不自行重試？他們知道我的聯(lián)系數(shù)據(jù)，并且可以在準備好時異步發(fā)送登機牌。更好的反應(yīng)是：

這不僅會更方便，而且還會降低總體復(fù)雜性，因為需要查看故障的組件數(shù)量會減少：

您可以將相同的原則轉(zhuǎn)移到服務(wù)到服務(wù)通信。每當服務(wù)本身可以解決故障時，它就會封裝重要的行為。這使得所有客戶的生活更加輕松，API更加清潔。解決故障可能是有狀態(tài)的（有些人稱之為長時間運行）。我認為狀態(tài)處理是微服務(wù)中故障處理的關(guān)鍵問題。

當然，上面描述的行為并不總是你想要的，將故障移交給客戶端就可以了。但這應(yīng)該是根據(jù)業(yè)務(wù)需求做出的有意識的決定。

我觀察到大多數(shù)情況下，另一個原因?qū)е氯藗儽苊庥袪顟B(tài)重試：它伴隨著狀態(tài)處理的復(fù)雜性。該服務(wù)必須重試幾分鐘，幾小時或幾天。它必須可靠地執(zhí)行此操作（請記住：即使系統(tǒng)重新啟動，我也希望登機牌），這涉及處理持久狀態(tài)。

如何管理持久狀態(tài)？

我看到兩種處理持久狀態(tài)的典型方法：

存儲在數(shù)據(jù)庫中的實體等持久性事物。

雖然這開始非常簡單，但通常會導(dǎo)致很多意外的復(fù)雜性。您不僅需要數(shù)據(jù)庫表，還需要一些調(diào)度程序組件來進行重試。您可能需要一些監(jiān)視組件來查看或編輯等待作業(yè)。如果整體業(yè)務(wù)邏輯發(fā)生變化，您仍需要進行版本控制，而您仍想進行重試。等等等等。

這種思路導(dǎo)致許多開發(fā)人員如上所述跳過正確的故障處理，導(dǎo)致整個架構(gòu)的復(fù)雜性增加 - 以及糟糕的客戶體驗。

相反，我建議利用輕量級工作流引擎或狀態(tài)機。

構(gòu)建這些引擎是為了保持持久狀態(tài)并處理圍繞流語言，監(jiān)視和操作的后續(xù)要求，擴展以處理高容量等等。

市場上有幾個輕量級工作流引擎。他們中的許多人使用ISO標準BPMN來定義流，其中許多是開源的。在這里，我將使用Camunda的開源工作流引擎來說明基本原則（快速免責(zé)聲明：作為該項目背后的公司的共同創(chuàng)始人，我明顯偏向于我的工具選擇，但這是我最熟悉的工作流引擎）。對于前面描述的簡單用例，可以使用Java DSL輕松創(chuàng)建工作流：

另一種選擇是在BPMN中以圖形方式建模工作流程：

這些工作流引擎在架構(gòu)方面非常靈活。許多開發(fā)人員認為工作流引擎是一個集中組件，但事實并非如此。沒有必要引入集中組件！如果不同的服務(wù)需要工作流引擎，則每個服務(wù)都可以運行自己的引擎來維護服務(wù)的自治和隔離。本博文中有關(guān)架構(gòu)選項的更多細節(jié)將對此進行詳細討論。

另一個誤解是工作流迫使開發(fā)人員切換到異步處理。這也不是真的。在上面的示例中，當一切順利運行時，登記組件可以同步返回登機牌。只有在出現(xiàn)錯誤時才會回退到異步處理。這可以很容易地反映為HTTP返回碼，200表示“一切正常，這是你的結(jié)果”，202表示“得到它，我會給你回電話?！庇幸恍┚唧w的示例代碼來處理這個，它利用了一個簡單的信號。

我將工作流引擎視為工具箱的重要組成部分，用于正確的故障處理，這通常涉及長期運行的行為，如狀態(tài)重試。

2.異步性需要注意

這導(dǎo)致我們進行異步通信，這通常意味著消息傳遞。異步性通常被認為是分布式系統(tǒng)中的最佳默認值，因為它提供了解耦，尤其是時間解耦，因為任何消息都可以獨立于接收器的可用性發(fā)送。一旦服務(wù)提供商可用，該消息將立即發(fā)送，而無需額外的魔力。

因此，重試的問題已經(jīng)過時，但會出現(xiàn)類似的問題：您必須擔心超時問題。假設(shè)航空公司在登記方案中使用異步通信。登記組件向條形碼生成服務(wù)發(fā)送消息，然后等待響應(yīng)。您無需關(guān)心條形碼生成器的可用性，因為消息總線將在適當?shù)臅r候傳遞消息。

但是，如果請求或響應(yīng)因任何原因而丟失怎么辦？您是否會在辦理登機手續(xù)時遇到困難，未能在沒有注意到的情況下將登機牌發(fā)送給客戶？我打賭很多公司這樣做，這再次導(dǎo)致我，客戶監(jiān)控響應(yīng)并采取行動，如果沒有登機牌在超時內(nèi)到達。同樣，我必須利用我的個人調(diào)度基礎(chǔ)設(shè)施（日歷）。

更好的方法是讓服務(wù)監(jiān)控超時本身，并在條形碼未能及時到達時執(zhí)行回退?？赡艿暮髠涫侵匦掳l(fā)送消息，這實質(zhì)上是重試。

您也可以利用工作流自動化技術(shù)來處理此用例。BPMN中的工作流可能如下所示：

作為獎勵，您可以免費報告重試次數(shù)，典型響應(yīng)時間以及無法及時處理的工作流程數(shù)量。操作員可以通過提供大量上下文來輕松檢查和修復(fù)失敗的工作流實例，例如消息中包含的數(shù)據(jù)以及消息發(fā)送的時間。純粹的基于消息的解決方案通常會忽略這種級別的可見性和操作控制。

我甚至看到公司更進一步，使用工作流引擎而不是消息傳遞中間件來在微服務(wù)之間分配工作。如果工作流引擎不主動調(diào)用服務(wù)或發(fā)送消息（稱為推送原則）但依賴于工作者要求工作（稱為拉取原則），則這是可能的?，F(xiàn)在，工作流引擎中的工作隊列就像一個消息隊列。當我問他們?yōu)槭裁聪矚g工作流引擎時，他們說消息傳遞解決方案缺乏相同的可見性和工具質(zhì)量，他們希望避免構(gòu)建自己的操作工具。

3.分布式交易很難

事務(wù)是以全有或全無的方式執(zhí)行的一系列操作。我們都從數(shù)據(jù)庫中知道這一點。您開始一個事務(wù)，做一些事情，然后提交或回滾事務(wù)。這些事務(wù)稱為ACID：原子，一致，隔離和持久。

在分布式系統(tǒng)中，您不能指望ACID事務(wù)。是的，有像XA這樣的協(xié)議實現(xiàn)了所謂的兩階段提交?；騑S-AtomicTransaction?；蛳馟oogle Spanner這樣復(fù)雜的實施。但目前的共識是，這些協(xié)議太昂貴，太復(fù)雜，或者根本無法擴展。Pat Helland的“超越分布式交易的生活：Apostate的意見”是一個很好的背景閱讀。

但當然，商業(yè)交易的要求并沒有消失。在沒有ACID的情況下解決業(yè)務(wù)交易的常見技巧是使用補償。這意味著您可以對過去不正確執(zhí)行的所有活動執(zhí)行撤消活動。BPMN具有此內(nèi)置功能，因此您可以定義這些撤消活動，并且工作流引擎負責(zé)以正確的順序可靠地執(zhí)行它們。這次我將使用預(yù)訂機票的例子：

這通常也被稱為Saga模式，最近變得非常流行。我在“Saga：如何在沒有兩階段提交的情況下實現(xiàn)復(fù)雜的業(yè)務(wù)交易”中寫到了這一點，其中我還鏈接了其他來源和一些代碼。

請注意，此方法與ACID事務(wù)不同，因為您可以具有不一致的中間狀態(tài)。所以，我可以保留一個座位，但尚未預(yù)訂有效的機票。或者我可以在沒有付款的情況下買票。實際情況是，只要確保最終清理它們并使系統(tǒng)恢復(fù)到一致狀態(tài)，通常可以忍受這些暫時的不一致。這稱為最終一致性，這是分布式系統(tǒng)中的一個重要概念。“在SoA網(wǎng)絡(luò)中擁抱最終的一致性”指出它非常好：

最終的一致性通常會產(chǎn)生更好的性能，更簡單的操作和更好的可伸縮性，同時要求程序員理解更復(fù)雜的數(shù)據(jù)模型。

好消息是工作流程自動化簡化了補償?shù)奶幚?。這是因為工作流引擎可以可靠地調(diào)用所有必要的補償活動。

服務(wù)提供商 - 做好功課！

到目前為止，我已經(jīng)提出了三種簡單的補救措施來應(yīng)對分布式系

1. 重試
2. 超時
3. 賠償金

所有這些都可以使用輕量級工作流自動化技術(shù)實現(xiàn)。但是為了利用這些配方，每個服務(wù)提供商都必須做好功課。這意味著

1. 提供補償活動和
2. 實現(xiàn)冪等性。

雖然第一個要求應(yīng)該是顯而易見的（如果有取消票證的服務(wù)，我只能取消票證），第二個 - 冪等性 - 需要更多解釋。

冪等

我談了很多關(guān)于重試的事情。一個常見的問題是，如果我通過重試兩次調(diào)用服務(wù)怎么辦？這個問題問得好！

首先要確保您了解每種形式的遠程通信都會遇到此問題！無論何時通過網(wǎng)絡(luò)進行通信，都無法區(qū)分三種故障情形：

1. 該請求尚未到達提供商
2. 請求已到達提供商，但在處理期間它已爆炸
3. 提供程序處理了請求，但響應(yīng)丟失了

一種可能性是詢問服務(wù)提供商是否已經(jīng)看到此請求。但更常見的方法是使用重試并以允許重復(fù)調(diào)用的方式實現(xiàn)服務(wù)提供程序。這更容易設(shè)置。

我看到兩種簡單的方法來掌握冪等性：

1. 自然的冪等性。有些方法可以隨意執(zhí)行，因為它們只是翻轉(zhuǎn)一些狀態(tài)。示例：confirmCustomer（）
2. 商業(yè)冪等。有時，您擁有允許您檢測重復(fù)呼叫的業(yè)務(wù)標識符。示例：createCustomer（email）

如果這些方法不起作用，您需要添加自己的冪等性處理：

1. 唯一身份。您可以生成唯一標識符并將其添加到呼叫中。這樣，如果您在服務(wù)提供商端存儲該ID，則可以輕松發(fā)現(xiàn)重復(fù)呼叫。如果您利用工作流引擎，您可能會讓它完成繁重的工作（例如，當Camunda允許在啟動期間對密鑰進行重復(fù)檢查時）。示例：charge（transactionId，amount）
2. 請求哈希。如果您使用消息傳遞，則可以通過存儲消息的哈希值來執(zhí)行相同的操作。您可以再次利用工作流引擎，或者您可以使用具有內(nèi)置租賃功能的數(shù)據(jù)庫（如Redis）。

長話短說：在您的服務(wù)中注意冪等性。這將帶來巨大的回報。

給我看一下代碼

您可以使用BPMN和開源Camunda引擎找到實現(xiàn)我在此描述的模式的源代碼

Java或C＃。(需要的后臺發(fā)消息)

摘要

在本文中，我介紹了三個常見的陷阱，我看到客戶在整合微服務(wù)時踩到了：低估了遠程通信的復(fù)雜性，忽略了異步性的挑戰(zhàn)，忘記了商業(yè)交易。

通過重試，超時和補償活動的狀態(tài)模式引入處理這些情況的功能可以降低微服務(wù)基礎(chǔ)架構(gòu)的整體復(fù)雜性并增強其彈性。它還有助于：

1. 將重要的故障處理和事務(wù)行為封裝在它所屬的位置：在服務(wù)本身的上下文中。
2. 將故障或超時處理的工作量減少到更小的范圍，從而降低整體復(fù)雜性。
3. 簡化服務(wù)API，只發(fā)布對客戶真正重要的故障。
4. 改善客戶體驗，客戶可能是其他服務(wù)，內(nèi)部員工，甚至是客戶。

使用輕量級工作流引擎，您可以通過應(yīng)用自行開發(fā)的解決方案來處理有狀態(tài)模式，而無需投入大量精力或冒著意外復(fù)雜性的風(fēng)險。隨附的源代碼提供了具體示例。