Categories
程式開發

Uber 一團隊正從微服務轉向宏服務


也許在某個叢林深處的某個地方,有一個未被發現的部落還沒有對微服務下定決心,但我很懷疑這一說法。因為人們對微服務的態度是非愛即恨。這兩者之間並沒有什麼太多的中間地帶。

所以,當 Uber 這樣的公司的一支團隊宣布從微服務轉向其他東西時,這意味著什麼?什麼?宏服務。但我們會講這個問題的。想想看,你對 Uber 這家公司是怎麼看的?但從軟件的角度來看,Uber 一直是個“好公民”。

Uber 支付體驗平台的工程經理 Gergely Orosz 在一條推文中表示,架構方向已發生變化:

@GergelyOrosz:

聲明一下,在 Uber,我們正將許多微服務轉移到 @copyconstruct 所稱的宏服務(大小適中的服務)。

確切地說,B/C 測試和維護成千上萬的微服務不僅很難——它可能會帶來更多的長期麻煩,而不是解決短期問題。

  • 微服務確實可以幫助團隊在早期快速推進。
  • 等你意識到服務越少越好時,已為時已晚。你需要解決很多服務的“困難”部分。
  • 我們不斷增加更多的服務,但也有退下來的,並在新的服務中投入更多的考慮。

@GergelyOrosz:

是的,我們正在這樣做,這個方法觸及到了很多微服務的痛點。

每項服務都需要支持租戶,包括很多無狀態的租戶。

我們還需要對現有的服務來進行這方面的大部分工作。對於新的服務,我們只需從頭開始添加它。

@GergelyOrosz:

1.微服務幫助(並且現在仍然幫助)快速推進、自治和實驗。

2.一個領域越成熟,“大小適中的的服務”就越有意義/越容易推理。

看來以後我得用更長的篇幅將我的想法寫出來。

@GergelyOrosz:

我可能早就該發一篇關於微服務缺點的帖子了。有關幸福的蜜月期話題很多,但人們卻很少談及後來與微服務如何發生激烈的爭吵,然後又和好,但又改變了一些事情。就只為了一勞永逸。

Gregdoesit:

我寫的那條推文,已經流傳開來。一條推文最多只能發 280 個字符,寫不了什麼太多的東西,而且在 Twitter 上一旦發布推文就無法編輯,因此,沒有多少東西可以讓你回去進一步澄清。所以,讓我在這個論壇上詳細地說明一下。

  1. 我只代表我自己的經驗,代表我的團隊,而不代表整個 Uber。哎呀,我們 Uber 有數百支團隊,其中 95% 我都不認識。而且,團隊有自治權,可以決定自己如何做、做什麼(包括部分或完全遵循指導原則或或完全忽視指導原則)——即使我想這樣做,我也不能一概而論。
  2. Uber 已經並且仍然擁有成千上萬的微服務。上一次我查看的時候,大概有 4000 個。 (https://eng.uber.com/optimizing-observability/)。 而且,需要明確的是,這一數字還在(並將繼續)增長。
  3. 我在 Uber 工作快四年了,看到了我所在的組織/領域(支付)的一些趨勢。在過去,我們會構建一個微服務,它可以完成一件很小的事。我們有一批由一個人構建並維護的小型服務。這對於自治性、迭代速度、學習和使 DevOps 成為一個無需動腦的事情都是極好的。你可以隨時啟動一項服務,但你必須隨叫隨到。
  4. 現在,隨著我的領域逐漸成熟,展望未來變得更加容易,隨著我們創建新的平台,我們正在對新的服務進行更深思熟慮的規劃。這些服務並不僅僅只做一件事:它們服務於一項業務功能。它們是由一個團隊(5~10 名工程師)構建並維護的。與一些早期微服務公司相比,它們更具彈性,在開發和維護方面得到的投資要多得多。 Cindy 調用了這些宏服務,我說我們也在做類似的事情。我們所做的事情唯一的區別是,一個服務是一個團隊的,而不是多個團隊的。
  5. 雖然很多微服務都是這樣發展的,但坦率地說,大部分微服務還是保持了原樣。成千上萬的微服務帶來了很多需要解決的問題。監控、測試、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/Uber 風格的微服務並不是許多(大多數?)組織所需要的。
  • 宏服務?

宏服務:

  • 不是單體應用。
  • 服務的開發只有不超過 20 個開發人員/3 個團隊(五個披薩原則?)
  • 可能有,也可能沒有,或者不需要 monorepo(單體倉庫)。服務/倉庫越少,依賴項管理就越容易(儘管仍然很不平凡)。
  • 更好的可觀測性、調試能力

世界會因為我們有了一個新的半正式品牌術語,比如宏服務,全世界都會為之瘋狂。

宏服務和我們幾十年來所知道的普通服務有什麼不同?沒人在乎這個問題。名稱是他們時代的產物。名稱只是一個討論的腳手架。這不是魔術。名稱並不是一個什麼秘密的象徵,必須保密,以免黑魔法師把你變成他們的肉食傀儡。名稱只不過是一個聚集地,一個標記,幫助我們找到方向。深吸一口氣,讓任何因名稱而產生的煩躁情緒消失吧!

正如你可以想像的那樣,人們的反應非常熱烈。他們當中的大部分人都在欣喜若狂地頌揚微服務這一禍害的終結,認為微服務這樣的結局是 “理所當然” 的。微服務一直以來都是個壞主意,這是反對派的普遍共識。

@sandofsky:

2016 年的 Uber:“我們有成千上萬的微服務。”

每個人都說:“這聽起來很瘋狂。”

2020 年的 Uber:“事實證明,這太瘋狂了。”

@dhh:

過度採用微服務給人們帶來的痛苦是巨大的。

除了 Majestic Monolith 之外,還應該有人寫下 Citadel 的模式:單一 Majestic Monolith 抓住了大部分的應用程序,少數輔助前哨應用程序滿足高度專業化和多樣化的需求。

但也不全是負面的。

@saikishore001:

我們發現 Bayer 在微服務方面取得了相當大的成功。對我們來說,唯一一個大型的單體應用就是一場噩夢……現在,使用微服務架構就好多了。

@Carnage4Life:

Uber 在 2016 年就大力支持微服務,但現在卻放棄了,這其中有兩點重要的教訓:

  1. 大公司在規模化上所做的權衡,可能並不適合你的初創公司。
  2. 大公司也會做出糟糕的架構選擇,所以要小心“船貨崇拜”(Cargo cult)。

譯註: 船貨崇拜(Cargo cult)是一種宗教形式,特別出現於一些與世隔絕的原住民中。當貨物崇拜者看見外來的先進科技物品,便會將之當作神祇般崇拜。最為知名的貨物崇拜,是瓦努阿圖塔納島的 “約翰布魯姆教”(John Frum Movement)。第二次世界大戰太平洋戰爭時,美軍於塔納島創建一臨時基地。當時島上的原住民看見美軍於 “大鐵船”(軍艦)內出來,皆覺得十分驚訝。此外,他們也看到,有一些 “大鐵鳥”(軍用飛機)運送穿著美軍軍服的人及許多物資。這些原住民看見這種情況均感到很驚訝,並覺得這些 “大鐵船” 及 “大鐵鳥” 十分厲害。加上美軍也提供部份物資給原住民,而這些物資對原住民來說十分有用,結果令這些原住民將美軍當作神。此處暗指那些大公司此前也沒有見過或者應用過微服務架構。

@adamzethraeus:

Uber 真的只是為了避免協調成本,才會這麼做。大致來說,Uber 明確鼓勵不考慮重用或整合的構建。例如,Uber 的中國團隊複製了一堆三級架構,以更快的速度推進。 (這在短期內很有效!)

對於架構炒作週期,也有一個值得考慮的經濟學論據:

@ridingwithrails

在互聯網崩潰和經濟衰退期間,單體應用總是贏家。人們意識到,十個使用十種不同系統的團隊是很難保持的……再見,Felicia!

@sandofsky

每一次科技談論都應該披露他們的風險投資資金消耗率。當你把別人的錢花在自己的問題上時,你什麼都能逃過一劫。

對微服務行業來說,對微服務可能衰落的幸災樂禍並不是什麼好兆頭。我們需要的是集中精力把事情做正確,而不是做對。我知道,正確是學霸競爭的核心。

改變是我們進步的方式,在改變過程中人為製造摩擦對誰都沒有幫助。 Uber 成熟、學習、重構是一件好事。這並非承認失敗,甚至是早期決策失誤的證據。當你有了很多錢,並且有了統治世界的宏偉藍圖,微服務就有了很大的意義。當你的成長階段走到盡頭時,你也可以採取緊縮和鞏固的措施。當實際情況發生變化時,你會怎麼做?

面對現實吧,我們對如何構建軟件幾乎一無所知。我相信,微服務之所以能夠迅速發展,部分原因在於它至少為程序員提供了一個關於如何構建程序的連貫理論。

每個人都給出了自己個人愛好的替代微服務,但並沒有達成共識,我們沒有系統的理論。見證整個討論,作為證據吧。

軟件真是一團糟啊。

原文鏈接:

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