Uber 團隊放棄微服務改用宏服務，網友評論炸鍋了
對于微服務，大多數開發者的態度都是鮮明的，要么熱愛，要么痛恨，很少有人懷抱著比較“曖昧”的態度。所以，當 Uber 中的一個技術團隊宣布，放棄微服務，轉而使用宏服務，網友們就炸鍋了。
1. Uber 團隊放棄微服務，轉為使用宏服務
不久之前，Uber 支付體驗平臺的工程經理 Gergely Orosz 發布推文表示我們的架構方向已經發生了變化。
聲明一下，在 Uber，我們正將許多微服務轉移到 @copyconstruct 所稱的宏服務（大小適中的服務）。
確切地說，B/C 測試和維護成千上萬的微服務不僅很難——它可能會帶來更多的長期麻煩，而不是解決短期問題。
微服務確實可以幫助團隊在早期快速推進。
等你意識到服務越少越好時，已為時已晚。你需要解決很多服務的“困難”部分。
我們在不斷增加更多的服務，但也在停止使用服務，并且會更慎重的思考新的服務。
@GergelyOrosz:
是的，我們正在這樣做，這個方法觸及到了很多微服務的痛點。每項服務都需要支持租戶，包括很多無狀態的租戶。
我們還需要對現有的服務來進行改進，而針對新的服務，我們只需從頭開始添加即可。
@GergelyOrosz:
微服務之前能夠幫助企業（并且現在仍然幫助）快速行動、實現自治、便于實驗。
一個領域越成熟，“大小適中的的服務”就越有意義，就越容易論證。
@GergelyOrosz:
我可能早就該發一篇關于微服務缺點的帖子了。有關微服務幸福的蜜月期話題很多，但人們卻很少談及后來與微服務如何發生激烈的爭吵，然后又和好，但又改變了一些事情。就只為了一勞永逸。
Gregdoesit:
我寫的那條推文，已經流傳開來。一條推文最多只能發 280 個字符，寫不了什么太多的東西，而且在 Twitter 上一旦發布推文就無法編輯，因此，無法再修改補充新的東西，所以我在論壇中詳細說明一下。
以下內容只代表我自己的經驗，代表我所在的團隊，而不代表整個 Uber。Uber 有數百支團隊，其中 95% 我都不認識。而且，團隊有自治權，可以決定自己如何做、做什么，所以我也不能一概而論。
Uber 目前仍然擁有成千上萬的微服務。上一次我查看的時候，大概有 4000 個。而且，需要明確的是，這一數字還在繼續增長。
我在 Uber 工作快四年了，看到了我所在領域的一些趨勢。在過去，我們會構建一個微服務，它可以完成一件很小的事。我們有一批由一個人構建并維護的小型服務。這對于自治性、迭代速度、學習和使 DevOps 成為一個無需動腦的事情都是極好的。你可以隨時啟動一項服務，但你必須隨叫隨到。
現在，隨著領域逐漸成熟，展望未來變得更加容易。我們創建了新的平臺，因此，對于新的服務會進行更深思熟慮的規劃。這些服務并不僅僅只做一件事：它們服務于一項業務功能。它們是由一個團隊（5~10 名工程師）構建并維護的。與一些早期微服務公司相比，它們更具彈性，在開發和維護方面得到的投資要多得多。Cindy 調用了這些宏服務，我說我們也在做類似的事情。我們所做的事情唯一的區別是，一個服務是一個團隊的，而不是多個團隊的。
雖然很多微服務都是這樣發展的，但坦率地說，大部分微服務還是保持了原樣。成千上萬的微服務帶來了很多需要解決的問題。監控、測試、CI/CD、SLA、所有版本的庫（安全、時區問題）等等。一直以來，我們做了一些很好的舉措，并分享一些行之有效的方法，開源我們用來解決問題的一些工具，比如用多租戶方法測試微服務、跨服務的分布式跟蹤。所有這些都是一筆巨大的投資。只有在你準備好進行這項投資的時候，才能進行規模化的微服務。
所以，Uber 并不是像很多人解讀的那樣，沒有使用微服務。Uber 甚至都不會減少微服務的使用。因此，當我說 “我們要遷移” 的時候，這一措辭并不很確切。在我的團隊和組織中，新的微服務的構建都是經過深思熟慮才構建的。這些新的微服務比那些早期的、小型的、專注的微服務“更大”。
微服務在 Uber 的很多方面都運行得很好，并且在其他領域也不斷地提供幫助。當然，問題是存在的，但你可以一邊處理問題，一邊解決問題。例如，有數千名開發人員的一個單體，有數千名開發人員的 SOA，或者有數千名開發人員支持的其它系統。隨著業務的發展，服務的數量整體上還是在增長的，不過在一些組織中，比如我的組織，服務數量是幾近不變的，甚至略有下降。但并不是所有的微服務都是平等的。關鍵的微服務看起來不太像經典的微服務，或者至少是我幾年前所說的那種微服務。
另外說一下，每個人對 “微服務” 這一名字的理解都不一樣。我將會撰寫一篇帖子，總結我在微服務領域的經驗。
譯注：SOA（Service-oriented arhitecture），面向服務的架構，是構造分布式計算的應用進程的方法。它將應用進程功能作為服務發送給最終用戶或者其他服務。它采用開放標準、與軟件資源進行交互并采用表示的標準方式。
Gregdoesit:
Uber 在 2015 年從一個巨型企業轉變成了一個 SOA。這個 SOA 遵循了一個基于微服務的架構。而我們也一直在分享這一路上所學到的東西：構建微服務通常需要的步驟，用多租戶的方法解決測試問題，或者我們如何使用分布式跟蹤等等。我們還開源了一些工具，比如 Jaeger，它和 Kubernetes、Prometheus 都是云原生基金會（Cloud Native Foundation）的畢業項目……所有這些都可以作為靈感：但是，你需要在自己的環境中做出你認為最有效的決定。當業務環境完全不一樣，任何盲目照搬 Google、Uber/SHopify、Stack Overflow 或其他公司的技術團隊，都會很失望的。
@copyconstruct:
微服務很棘手。
構建可靠且可測試的微服務比大多數人認為的要難得多。
有效地測試微服務需要大量的工具和深謀遠慮。
許多組織不需要 Netflix/ 優步那樣的微服務。
宏服務？
宏服務：
不是整體式系統
每 3 個團隊最多只有 20 名開發人員在開發服務（5 個披薩規則？）
是否擁有 / 需要整體式代碼倉庫（monorepo）不好說。服務 / 代碼倉庫數量較少，依賴項管理就變得容易得多（不過仍并非易事）
更好的可觀察性和調試
2. 網友評論炸鍋了，有人批評有人贊揚
世界會因為我們有了一個類似于宏服務的新品牌術語，而為之瘋狂。
宏服務和我們幾十年來所知道的普通服務有什么不同？幾乎沒有人在乎這個問題。名字是時代的產物，大多數人都在為“微服務的終結”而歡呼，認為這才是微服務的最終歸宿。
@sandofsky:
2016 年的 Uber：“我們有成千上萬的微服務。”
每個人都說：“這聽起來很瘋狂。”
2020 年的 Uber：“事實證明，這太瘋狂了。”
@dhh:
過度采用微服務給人們帶來的痛苦是巨大的。
除了 Majestic Monolith 之外，還應該有人寫下 Citadel 的模式：單一 Majestic Monolith 抓住了大部分的應用程序，少數輔助前哨應用程序滿足高度專業化和多樣化的需求。
但也不全是負面的。
@saikishore001:
我們發現 Bayer 在微服務方面取得了相當大的成功。對我們來說，唯一一個大型的單體應用就是一場噩夢……現在，使用微服務架構就好多了。
@Carnage4Life:
Uber 在 2016 年就大力支持微服務，但現在卻放棄了，這其中有兩點重要的教訓：
大公司在規模化上所做的權衡，可能并不適合你的初創公司；大公司也會做出糟糕的架構選擇，所以要小心“船貨崇拜”（Cargo cult）。
譯注： 船貨崇拜（Cargo cult）是一種宗教形式，特別出現于一些與世隔絕的原住民中。當貨物崇拜者看見外來的先進科技物品，便會將之當作神祇般崇拜。最為知名的貨物崇拜，是瓦努阿圖塔納島的 “約翰布魯姆教”（John Frum Movement）。第二次世界大戰太平洋戰爭時，美軍于塔納島創建一臨時基地。當時島上的原住民看見美軍于 “大鐵船”（軍艦）內出來，皆覺得十分驚訝。此外，他們也看到，有一些 “大鐵鳥”（軍用飛機）運送穿著美軍軍服的人及許多物資。這些原住民看見這種情況均感到很驚訝，并覺得這些 “大鐵船” 及 “大鐵鳥” 十分厲害。加上美軍也提供部份物資給原住民，而這些物資對原住民來說十分有用，結果令這些原住民將美軍當作神。此處暗指那些大公司此前也沒有見過或者應用過微服務架構。
@adamzethraeus:
Uber 真的只是為了避免協調成本，才會這么做。大致來說，Uber 明確鼓勵不考慮重用或整合的構建。例如，Uber 的中國團隊復制了一堆三級架構，以更快的速度推進。（這在短期內很有效！）
對于架構炒作周期，也有一個值得考慮的經濟學論據：
@ridingwithrails：
在互聯網崩潰和經濟衰退期間，單體應用總是贏家。人們意識到，十個使用十種不同系統的團隊是很難保持的……再見，Felicia！
@sandofsky：
每一次科技談論都應該披露他們的風險投資資金消耗率。當你把別人的錢花在自己的問題上時，你什么都能逃過一劫。
行業對微服務可能衰落的幸災樂禍并不是什么好兆頭。我們需要的做的是集中精力把微服務用到正處，使用得當才是競爭的核心。
改變是進步的方式，在改變過程中，人為制造沖突矛盾，這對誰都沒有幫助。Uber 成熟、學習、重構是一件好事，這并非是承認失敗，甚至是早期決策失誤的證據。
坦率來講，我們對如何構建軟件幾乎一無所知。我相信，微服務之所以能夠迅速發展，部分原因在于它為程序員提供了一個關于如何構建程序的連貫理論。
每個人都給出自己的微服務替代方案，但目前并沒有達成共識，我們沒有系統的理論。希望這次Uber的嘗試，能夠給到我們更多的啟發。
軟件真是一團糟啊。
