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，且數量還在不斷增加，而在實踐宏服務的隻有一個技術團隊。
事實上，宏服務并非是比微服務更優的架構，隻是架構演進中的不同選擇。如果想要解決複雜性問題，無論是微服務，還是宏服務，都應該思考以下幾個問題：
特定服務當中，面向業務與面向內建的端點各占多大比例？
在服務當中，是否存在與業務不相關的端點？能否在不引入面向內建端點的前提下，将其拆分為兩項或者更多服務？
合并某兩項服務，是否能夠消除之前用于內建二者而添加的端點？