避免小型單體反模式。微服務在多大規模上才有意義?避免比問題更糟糕的解決方案，并了解權衡取舍。

上個月，我寫了一篇關于模塊化單體和現代單體架構的價值的文章。該文章(和視頻)中出現的更有趣的討論之一是逆向討論：什么時候仍然選擇微服務是正確的?

與任何設計選擇一樣，答案是主觀的并且取決于很多因素。但是我們仍然可以使用一般的經驗法則和全球指標。在我們進入這些問題之前，我們需要了解擁有微服務架構意味著什么。然后我們可以衡量擁有這樣一個架構的好處和代價。

一個常見的誤解是微服務只是簡單地分解為單體。事實并非如此。我和很多仍然持有這種觀點的人談過，公平地說，他們可能有道理。AWS 是這樣定義微服務的：

微服務是一種軟件開發的架構和組織方法，其中軟件由通過定義明確的 API 進行通信的小型獨立服務組成。這些服務由獨立的小型團隊擁有。

微服務架構使應用程序更易于擴展和更快地開發，從而實現創新并加快新功能的上市時間。

較小的單體可能符合該定義，但如果您從字里行間中讀到，則它們不符合。“獨立”和“更易于擴展”這兩個詞暗示了這個問題。單體的問題(和優勢)是單點故障。通過一項服務，我們通?？梢愿菀椎匕l現問題。架構要簡單得多。

如果我們將此服務分解成更小的部分，我們實際上會創建分布式故障點。如果鏈條上的一個部分出現故障，整個架構就會崩潰。這不是獨立的，也不容易擴展。微服務不是小單體，分解單體不僅僅是處理較小的項目。這是關于改變我們的工作方式。

是什么造就了微服務?

一個好的微服務需要遵循以下健壯性和規模原則：

• 按業務功能劃分：這是一個邏輯劃分。微服務是提供完整包的獨立“產品”。這意味著負責微服務的團隊可以在沒有依賴關系的情況下進行業務所需的所有更改。
• 通過 CI/CD 實現自動化：如果沒有持續交付，更新成本將消除微服務的所有優勢。
• 獨立部署：這是隱含的，因為對一個微服務的提交只會觸發該特定服務的 CD。我們可以通過 Kubernetes 和基礎架構即代碼 (IaC) 解決方案來實現這一點。
• 封裝：它應該隱藏底層的實現細節。服務充當獨立產品，為其他產品發布 API。我們通常通過 REST 接口以及消息傳遞中間件來實現這一點。API 網關進一步增強了這一點。
• 去中心化，沒有單點故障：否則，我們會分散故障。
• 故障應該被隔離：否則，單個服務宕機可能會產生多米諾骨牌效應。斷路器可能是隔離故障的最重要工具。為了滿足這種依賴性，每個微服務都處理自己的數據。這意味著很多數據庫，有時可能具有挑戰性。
• 可觀察的：這是處理大規模故障所必需的。沒有適當的可觀察性，我們實際上是盲目的，因為各個團隊可以自動部署。

這一切都很好，但實際上這意味著什么?

它的大部分意思是我們需要對我們處理一些重要想法的方式做出幾項重大改變。我們需要將更多的復雜性轉移給 DevOps 團隊。我們需要以不同的方式處理跨微服務的事務狀態。這是處理微服務時最難掌握的概念之一。

在理想的世界中，我們所有的操作都將很簡單，并包含在一個小型微服務中。圍繞我們的微服務的服務網格框架將處理所有全球復雜性并為我們管理我們的個人服務。但這不是真實的世界。實際上，我們的微服務可能具有在服務之間傳輸的事務狀態。外部服務可能會失敗，為此，我們需要采取一些獨特的方法。

依賴 DevOps 團隊

如果您的公司沒有優秀的 DevOps 和平臺工程團隊，微服務就不是一個選擇。由于遷移，我們可能會部署數百個應用程序，而不是部署一個應用程序。雖然單個部署簡單且自動化，但您仍然會在操作上投入大量工作。

當某些東西不起作用或無法連接時。當需要集成新服務或需要采用服務配置時。在使用微服務時，運營會承擔更大的負擔。這需要良好的溝通和協作。這也意味著管理特定服務的團隊需要重新承擔一些 OPS 負擔。這不是一項簡單的任務。

作為開發人員，我們需要了解許多用于將我們的單獨服務綁定回單個統一服務的工具：

• 服務網格：讓我們組合獨立的服務，并有效地充當它們之間的負載均衡器。它還提供安全、授權、流量控制等功能。
• API 網關：應該使用而不是直接調用 API。這有時會很尷尬，但通常對于避免成本、防止速率限制等來說是必不可少的。
• 特征標志和秘密：在單體中也很有用。但如果沒有專用工具，它們就不可能在微服務規模上進行管理。
• 熔斷：讓我們終止斷開的 Web 服務連接并優雅地恢復。否則，單個損壞的服務可能會導致整個系統崩潰。
• 身份管理必須是獨立的：在處理微服務環境時，您無法擺脫數據庫中的身份驗證表。

我將跳過編排、CI/CD 等，但它們也需要針對出現的每項服務進行調整。其中一些工具對開發人員來說是不透明的，但我們在所有階段都需要 DevOps 的幫助。

傳奇模式

無狀態服務將是理想的，承載狀態會使一切變得更加復雜。如果我們將狀態存儲在客戶端中，我們需要一直來回發送它。如果它在服務器上，我們將需要不斷獲取它、緩存它或將其保存在本地，然后所有交互都將針對當前系統執行。這消除了系統的可擴展性。

典型的微服務將存儲在自己的數據庫中并使用本地數據。需要遠程信息的服務通常會緩存一些數據以避免往返于其他服務。這是微服務可以擴展的最大原因之一。在單體中，數據庫應該成為應用程序的瓶頸，這意味著單體是高效的并且受限于我們存儲和檢索數據的速度。這有兩個主要缺點：

• 大?。何覀儞碛械臄祿蕉?數據庫越大，性能會同時影響所有用戶。想象一下，查詢亞馬遜上每次購買的 SQL 表只是為了找到您的特定購買。
• 域：數據庫有不同的用例。一些數據庫針對一致性、寫入速度、讀取速度、時間數據、空間數據等進行了優化。跟蹤用戶信息的微服務可能會使用時間序列數據庫，該數據庫針對與時間相關的信息進行了優化，而購買服務將專注于傳統的保守 ACID 數據庫。
• 注意：一個整體可以使用多個數據庫。這可以很好地工作并且非常有用。但這是例外。不是規則。

saga 模式通過使用補償事務來撤銷 saga 失敗時的影響。當 saga 失敗時，將執行補償事務以撤消前一個事務所做的更改。這允許系統從故障中恢復并保持一致的狀態。我們可以使用 Apache Camel 等工具來完成此操作，但這并非易事，并且需要比現代系統中的典型事務更多的參與。這意味著對于每個主要的跨服務操作，您都需要執行等效的撤消操作來恢復狀態。那是不平凡的。有多種用于 saga 編排的工具，但這是一個超出本文范圍的大主題，我仍然會從廣義上對其進行解釋。

了解 saga 的重要之處在于它避免了經典的 ACID 數據庫原則，而側重于“最終一致性”。這意味著操作會在某個時候使數據庫處于一致狀態。那是一個非常艱難的過程。想象調試一個只有在系統處于不一致狀態時才會出現的問題。

下圖從廣義上展示了這個想法。假設我們有一個匯款流程：

對于匯款，我們需要先分配資金。

然后我們驗證收件人是否有效且存在。

接下來，我們需要從我們的賬戶中扣除資金。

最后，我們需要將錢添加到收款人的帳戶中。

那就是一筆成功的交易。對于常規數據庫，這將是一個事務，我們可以在下圖中左側的藍色列中看到它。但如果出現問題，我們需要運行相反的過程：

如果分配資金失敗，我們需要移除分配。我們需要創建一個單獨的代碼塊來執行分配的逆操作。

如果驗證收件人失敗，我們需要刪除該收件人。然后我們還需要刪除分配。

如果扣除資金失敗，我們需要恢復資金，移除接收者，移除分配。

最后，如果向收款人添加資金失敗，我們需要運行所有的撤銷操作!

saga 中的另一個問題在 CAP 定理中得到了說明。CAP 代表一致性、可用性和分區容錯性。問題是我們需要選擇任意兩個……別誤會我的意思，你可能三個都選。但是，在失敗的情況下，你只能保證兩個。

可用性意味著請求收到響應。但不能保證它們包含最新的寫入。

一致性意味著每次讀取都會收到最近的錯誤寫入。

容忍意味著即使許多消息在途中被丟棄，一切都會繼續工作。

這與我們處理交易失敗的歷史方法大不相同。

我們應該選擇微服務嗎?

希望您了解正確部署微服務有多么困難。我們需要做出一些重大妥協。這種新方式不一定更好，在某些方面，它更糟。但是微服務的支持者還是有道理的，我們可以通過微服務獲得很多，也應該關注這些好處。

我們預先提到了第一個要求：DevOps。擁有一支優秀的 DevOps 團隊是考慮微服務的先決條件。我看到團隊試圖在沒有 OPS 團隊的情況下解決這個問題，他們最終花在操作復雜性上的時間比編寫代碼還多。這是不值得的努力。

微服務最大的好處是給團隊的。這就是為什么擁有穩定的團隊和范圍至關重要的原因。將團隊拆分成獨立工作的垂直團隊是一個巨大的好處。世界上模塊化程度最高的單體無法與之抗衡。當我們有數百名開發人員單獨跟蹤 git 提交時，跟蹤代碼的規模變化就變得站不住腳了。微服務的價值只有在大團隊中才能體現出來。這聽起來很合理，但在創業環境中，事情突然發生了變化。我的一位同事在一家雇傭了數十名開發人員的初創公司工作。他們決定遵循微服務架構并構建了很多。然后是縮減和維護多種語言的數十種服務成為一個問題。

拆分單體很難但可行。將微服務統一到一個整體可能更難，我不知道有誰認真嘗試過這樣做但很想聽聽故事。

不是一個尺寸

要遷移到微服務架構，我們需要進行一些思維轉變。一個很好的例子是數據庫和用戶跟蹤微服務。在整體中，我們會將數據寫入表并繼續我們的工作。但這是有問題的。

隨著數據規模的擴大，這個用戶跟蹤表最終可能包含大量數據，這些數據很難在不影響操作系統其余部分的情況下進行實時分析。通過微服務，我們可以提供幾個優勢：

微服務的接口可以使用消息傳遞，這意味著發送跟蹤信息的成本將降至最低。

跟蹤數據可以使用時間序列數據庫，這對于這個用例來說會更有效。

我們可以流式傳輸數據并異步處理它以從該數據中獲取額外的價值。

存在復雜性，數據將不再本地化。因此，如果我們異步發送跟蹤數據，我們需要發送所有必要的信息，因為跟蹤服務將無法返回到原始服務以獲取額外的元數據。但它具有位置優勢，如果有關跟蹤存儲的法規發生變化，則只有一個地方可以存儲它。

動態控制和推出

您是否曾經按下過發布按鈕導致生產中斷?

我做了不止一次(太多次了)。那是一種可怕的感覺。微服務在生產中仍然會失敗，并且仍然會發生災難性的失敗，但是，它們的失敗通常是局部的。將它們推廣到系統的特定子集 (Canary) 并進行驗證也更容易。這些都是可以由實際掌握用戶脈搏的人深入控制的策略：OPS。

微服務的可觀察性是必不可少的、昂貴的，但也更強大。由于一切都發生在網絡層，因此都暴露給可觀察性工具。SRE 或 DevOps 可以更詳細地了解故障。這是以開發人員為代價的，他們可能需要面對增加的復雜性和有限的工具。

應用程序可能會變得太大而不能失敗。即使采用模塊化，一些最大的單體應用也有如此多的代碼，運行一個完整的 CI/CD 周期需要數小時。然后，如果部署失敗，恢復到上一個好的版本也可能需要一段時間。

分割

過去，我們曾經根據層級劃分團隊?？蛻舳?、服務器、數據庫等。這是有道理的，因為每一個都需要一套獨特的技能。今天，垂直團隊更有意義，但我們仍然有專長。

通常，移動開發人員不會在后端工作。但是假設我們有一個移動團隊想要使用 GraphQL 而不是 REST。對于單體，我們要么告訴他們“接受它”，要么我們必須完成這項工作。有了微服務，我們可以用很少的代碼為他們創建一個簡單的服務。核心服務的簡單外觀。我們不需要擔心移動團隊編寫服務器代碼，因為這相對孤立。我們可以對每個客戶層做同樣的事情，這樣更容易垂直整合一個團隊。

太大

很難將手指放在使整體式應用不切實際的尺寸上，但這是您應該問自己的問題：

我們擁有或想要多少支球隊?

如果你有幾個團隊，那么單體應用可能會很棒。如果您有十幾個團隊，那么您可能會在那里遇到問題。

衡量拉取請求和問題解決時間

隨著項目的增長，您的拉取請求將花費更多時間等待合并，并且問題將需要更長的時間來解決。這是不可避免的，因為項目的復雜性趨于增加。請注意，新項目將具有更大的功能，一旦您在項目統計中考慮到生產力的下降應該是可衡量的，這可能會影響結果。

請注意，這是一個指標。在許多情況下，它可以指示其他事情，例如需要優化測試管道、審查流程、模塊化等。

我們有知道代碼的專家嗎?

在某個時候，一個龐大的項目變得如此之大，以至于專家們開始忘記細節。當錯誤變得難以為繼并且沒有權威人物可以不經咨詢就做出決定時，這就成為一個問題。

你愿意花錢嗎?

微服務將花費更多。沒有辦法解決這個問題。在某些特殊情況下，我們可以調整規模，但最終，可觀察性和管理成本將消除任何潛在的成本節約。由于人員成本通常超過云托管成本，因此總成本可能仍對您有利，因為如果規模足夠大，這些成本可能會降低。

取舍

下面的雷達圖很好地說明了單體與微服務的權衡。請注意，此圖表是為大型項目設計的。項目越小，單體應用的前景就越好。

請注意，微服務在容錯和團隊獨立性方面為大型項目帶來了好處。但他們付出了代價。他們可以減少研發支出，但他們主要將其轉移到 DevOps，因此這并不是一個主要的好處。

最后一句話

微服務的復雜性是巨大的，有時會被實施團隊忽略。開發人員使用微服務作為一個大棒來拋棄他們不想維護的系統部分，而不是構建一個可持續的、可擴展的架構來取代單體。

我堅信項目應該從單體開始。微服務是擴展團隊的優化，過早優化是萬惡之源。問題是，什么時候做這樣的優化合適?

我們可以使用一些指標來簡化決策。最終，這種變化不僅僅是拆分單體。這意味著重新思考交易和核心概念。從單體開始，我們就有了一個藍圖，我們可以使用它來調整我們的新實現，因為它會加強。