放棄微服務,改用宏服務,Uber 這波什麼操作?

作者丨田曉旭

Uber 支付體驗平臺放棄了微服務，轉而使用了宏服務，這一消息在網友中引起了熱議。一向是微服務積極分子的 Uber 為什麼突然改用宏服務了？以「簡單」著稱的微服務為什麼又變得難以維護了呢？

1 Uber 支付團隊放棄微服務，轉用宏服務

4 月 6 日，Uber 支付體驗平臺的工程經理 Gergely Orosz 發布推文表示其團隊的架構方向已經發生了變化，放棄微服務，轉而使用宏服務。

為什麼會做出這樣的選擇呢？Gergely Orosz 表示：「最早，Uber 通過構建微服務來完成很小的需求或功能，以至於出現了很多由一個人構建維護的微服務。這些微服務的存在給我們帶來了新的複雜性和挑戰，例如監控、測試、持續集成 / 持續交付（CI/CD）、服務級別協議（SLA）、跨所有微服務的庫版本（安全和時區問題）等等。」

因此，在創建新平臺的時候，Uber 支付體驗團隊對新服務進行了更加深思熟慮的規劃：不再只是完成一件事，而是使其服務於一項業務功能，由 5-10 個工程師負責維護。Gergely Orosz 把這樣的服務規劃稱之為宏服務。

為什麼一向以簡單著稱的微服務，在 Uber 的實踐中突然就變得難以維護了呢？我們先來看一下微服務到底「微」的是什麼呢？

2 微服務到底「微」的是什麼？

微服務是什麼？百度百科給出的解釋是：「微服務是一個新興的軟體架構，就是把一個大型的單個應用程式和服務拆分為數十個的支持微服務。」其中，最關鍵的部分是開發者要能夠對服務中的某些部分進行衡量，並將其對應價值控制在最低水平。

那麼，微服務到底「微」的是什麼？

微團隊微服務首先「微」的就是服務開發團隊的規模，而且它有一個很特別的衡量單位——「披薩」。亞馬遜 CEO Jeff Bezos 提出了著名的兩個披薩原則，即每一個內部團隊的規模必須足夠小，小到兩個披薩餅就可以餵飽整個團隊。

兩個披薩團隊真的有效嗎？有人認可，但也有人質疑，有網友曾吐槽：「這種說法一看就很假，我手下有不少只需要一個披薩的團隊，但他們做出來的東西仍然是一團亂麻。」

微代碼庫

微服務，「微」的也可能是代碼庫，有人甚至會將「微代碼庫」這個概念發揮到極致，限制某項服務中所包含的代碼行數。

代碼庫小當然有好處，代碼庫越小，對應的業務範圍就越小，越易於理解、實施和開發，同時引發大失誤的概率低，而且出現失誤時，重構的難度也更低。

但是大家真的認可代碼庫這種硬性指標嗎？如果認可的話，那麼我們把範圍縮小到每行代碼包含多少個字符，豈不是更好？

我們可以通過很多種方式來定義服務邊界，代碼庫大小絕對是其中最低效的一種。—— Nick Tune

「微系統」

事實上，微團隊和微代碼庫都是「微服務」的理想化產物，大家似乎忘記了系統才是最關鍵的部分，系統是服務的容身之所。

我們真正需要構建的是系統，而不是一組服務。我們使用微服務的目的在於優化系統設計，而不是單純設計一個個獨立服務。事實上，我們很難使用真正獨立的組件建立起龐大的系統，因為這在本質上違背了「系統」的核心定義：

一組相互聯繫的事物或設備，它們能夠共同運作；

一組共同用於特定目標的計算機設備及程序；

彼此交互的服務才能建立起系統，如果只優化系統中的服務，而忽略服務間的交互，就會出現下圖的情況：

「微服務」本身可能非常簡單，但是交互建立起的系統將成為新的複雜性瓶頸。

3 從系統的角度來看服務的複雜性

系統複雜性並不是現在才有的問題，四十年前，沒有雲計算，沒有全球規模需求，也不需要 11.7 秒部署一次系統，但是工程師們仍然是需要克服系統中的複雜性挑戰，現在我們使用的工具雖然不同，但是面對的挑戰仍然存在。

Glenford J. Myers 寫過一本名為《複合 / 結構化設計（Composite/Structured Design）》的書，來講述如何構建面向過程代碼以降低系統複雜性。

除了嘗試直接降低系統中各個部分的局部複雜性之外，我們還可以通過多種方式來解決複雜性難題。複雜性中最重要的是全局複雜性，即系統整體結構的複雜性，程序主要部分之間的關聯或相互依賴程度。

通常，我們可以把局部複雜性理解為單一微服務的複雜性，由服務實現方式決定，而全局複雜性指的是系統整體複雜性，由服務間的交互和依賴關係決定。

一定程度上，這兩種複雜性是「互斥」的。如果想要使全局複雜性最低，那麼消除系統組件間的一切交互，在同一單體服務內實現所有功能即可，但是這會使得整個系統都特別擰巴，甚至可能會使得局部複雜性變得無法管理。而如果只優化局部複雜性，那麼這些代碼又會構成一個個新的複雜「單體」。所以，大規模分布式系統中，必須在全局和局部複雜性之間找到平衡。

4 宏服務是解決服務複雜性的「特效藥」嗎？

到底什麼是宏服務呢？相信國內開發者對這個概念會比較陌生，筆者在翻閱中文資料時，幾乎沒有見到關於宏服務的介紹文章，因此我們去諮詢了多位領域內的技術專家，有專家表示之前沒有聽過「宏服務」這個概念，有兩位專家表示：「宏服務應該是單體和微服務的折衷，關鍵區別是拆分粒度」。不過，也有專家吐槽：「宏服務這個概念沒啥亮點，畢竟沒人規定微服務應該拆多細。」

而在翻閱的英文資料中，有人是這麼描述宏服務的：

宏服務應該定義為運行 2-20 個單獨服務的應用程式體系結構，每個服務代表一個中等大小的代碼庫，可處理業務中定義明確的部分。宏服務的關鍵是拆分服務，最大程度地從拆分中獲得收益，同時最大程度地降低運行多個服務的開銷。

從概念描述中，宏服務似乎是在全局和局部複雜性之間找到了平衡，但理想豐滿、現實骨感，實際應用中，宏服務的實現也並非易事，大多數企業也都在嘗試階段。以 Uber 為例，目前企業內的微服務數量超過 4000，且數量還在不斷增加，而在實踐宏服務的只有一個技術團隊。

事實上，宏服務並非是比微服務更優的架構，只是架構演進中的不同選擇。如果想要解決複雜性問題，無論是微服務，還是宏服務，都應該思考以下幾個問題：

特定服務當中，面向業務與面向集成的端點各佔多大比例？

在服務當中，是否存在與業務不相關的端點？能否在不引入面向集成端點的前提下，將其拆分為兩項或者更多服務？

合併某兩項服務，是否能夠消除之前用於集成二者而添加的端點？

參考閱讀：

https://vladikk.com/2020/04/09/untangling-microservices/

http://highscalability.com/blog/2020/4/8/one-team-at-uber-is-moving-from-microservices-to-macroservic.html

https://mattsencenbaugh.com/macroservices-pragmatic-approach/

InfoQ 讀者交流群上線啦！各位小夥伴可以掃描下方二維碼，添加 InfoQ 小助手，回復關鍵字「進群」申請入群。大家可以和 InfoQ 讀者一起暢所欲言，和編輯們零距離接觸，超值的技術禮包等你領取，還有超值活動等你參加，快來加入我們吧！

點個在看少個 bug