為什么 Uber 一個團隊直接放棄微服務(wù)，改用宏服務(wù)？

點擊“開發(fā)者技術(shù)前線”，選擇“星標?”

在看|星標|留言,? 真愛

人們要么愛微服務(wù)，要么恨微服務(wù)，沒多少人既愛又恨微服務(wù)。

因此，當優(yōu)步（Uber）這種公司的哪怕一個團隊宣布從微服務(wù)改用宏服務(wù)，這頗能說明問題。想想你對優(yōu)步公司有什么看法，不過從軟件角度來看，優(yōu)步一向是良好的企業(yè)公民。

優(yōu)步支付體驗平臺的工程經(jīng)理Gergely Orosz在一條推文中暗示了架構(gòu)方向發(fā)生變化：

@GergelyOrosz：鄭重申明一下，我們優(yōu)步正將許多微服務(wù)轉(zhuǎn)移到@Cindy Sridharan?所說的宏服務(wù)（macroservice，即大小適中的服務(wù)）。

對成千上萬個微服務(wù)進行測試和維護不僅很棘手，長期造成的麻煩比短期解決的麻煩還要多。

微服務(wù)確實可以幫助團隊盡早迅速行動。

等到你意識到數(shù)量更少的服務(wù)會很好時，已為時已晚。你需要解決許多服務(wù)的“棘手”部分。

我們不斷添加更多的服務(wù)，但也在停止使用服務(wù)，并更慎重地考慮新服務(wù)。

@GergelyOrosz：

是的，我們正在這么做，這種方法觸及許多微服務(wù)的痛點。

每個服務(wù)都需要支持租約，包括許多無狀態(tài)的租約。

我們還需要針對現(xiàn)有服務(wù)改進這方面的許多工作。至于新服務(wù)，我們一開始就添加該方法。

@GergelyOrosz：

1. 微服務(wù)曾經(jīng)幫助（仍會幫助）快速行動、保持自主并便于試驗。

2. 某個方面變得越成熟，使用“大小適中的服務(wù)”就越明智/越容易論證。

稍后，我會以更長的篇幅總結(jié)一下想法。

@GergelyOrosz：

我可能早該寫一篇文章來介紹深有感觸的微服務(wù)缺點了。微服務(wù)方面關(guān)于幸福的蜜月期談得夠多了，但人們很少談?wù)撍麄兒髞砣绾闻c微服務(wù)打得不可開交，隨后和好但改變了幾個方面。

Gregdoesit：

我發(fā)了那條流傳甚廣的推特。短短280個字符寫不下太多的內(nèi)容，而Twitter的政策短期內(nèi)又不會變，所以好多東西你沒法回過頭去闡明。不妨容我在此作一番更詳細的介紹。

1. 以下內(nèi)容僅代表我的經(jīng)驗，代表我所在的團隊，而不代表優(yōu)步的所有團隊。我們優(yōu)步有數(shù)百支團隊，其中95%我都不認識。這些團隊具有自主權(quán)，可以決定自己怎么做、做什么（包括部分或完全遵循準則或忽視準則）——就算我想，也沒法發(fā)表總括性的說法。

2. 優(yōu)步現(xiàn)在仍有數(shù)千項微服務(wù)。我上次清點了一下有約4000項微服務(wù) （https://eng.uber.com/optimizing-observability/）。有必要明確一下：這個數(shù)字在增加，而且會不斷增加。

3. 我在優(yōu)步工作了近4年，看到我的組織/部門（支付）出現(xiàn)了一些趨勢。想當初，我們會啟動一個微服務(wù)，它就完成一項小小的任務(wù)。我們專門有一個人構(gòu)建和維護一批小服務(wù)。這適合于自主、迭代速度和學(xué)習(xí)，使得DevOps成為不二的選擇。你任何時候都可以啟動一個服務(wù)，但你得為此而隨叫隨到。

4. 現(xiàn)在，隨著我所在部門日趨成熟，更傾向于從長計議，我們在構(gòu)建新平臺時，在新服務(wù)方面做的規(guī)劃要周到得多。這些服務(wù)不僅僅只做一件事：服務(wù)于一個業(yè)務(wù)職能部門。它們由一個團隊（5至10位工程師）構(gòu)建和維護。與那些早期的微服務(wù)相比，它們更具彈性，并且在開發(fā)和維護方面獲得多得多的投入。Cindy稱這些服務(wù)為宏服務(wù)，我說我們在做類似的事情。我們之間所做的唯一區(qū)別就是，服務(wù)歸一個團隊擁有，而不是歸多個團隊擁有。

5. 坦率地說，雖然許多微服務(wù)在不斷發(fā)展，但大多數(shù)微服務(wù)保持原狀。成千上萬的微服務(wù)帶來了許多需要解決的問題。監(jiān)控、測試、持續(xù)集成/持續(xù)交付（CI/CD）、服務(wù)級別協(xié)議（SLA）、跨所有微服務(wù)的庫版本（安全和時區(qū)問題），不一而足。我們在不斷采取好的做法——共享切實可行的微服務(wù)，并開源我們?yōu)樘幚硇鲁霈F(xiàn)的問題而構(gòu)建的一些工具。比如使用多租戶方法測試微服務(wù)一樣，以及跨諸多服務(wù)的分布式跟蹤。這一切都是大筆投入。如果你準備進行這種投入，才可以搞大規(guī)模微服務(wù)。

因此，不，優(yōu)步不會像我見到許多人解讀的那樣對微服務(wù)說不。它甚至不會因此少用微服務(wù)。我說“我們在搬遷”，這么說其實措辭并不準確。我的團隊和組織在更深思熟慮地創(chuàng)建新的微服務(wù)。與一些早期小型專注的微服務(wù)相比，它們是“更龐大”的服務(wù)。

從許多方面來看，微服務(wù)在優(yōu)步運作良好，并在其他部門繼續(xù)提供幫助。當然也有問題，你邊摸索邊處理問題。這就跟成千上萬開發(fā)人員支持的整體式系統(tǒng)、成千上萬開發(fā)人員支持的面向服務(wù)對象（SOA）或成千上萬開發(fā)人員支持的其他任何系統(tǒng)一樣?？傮w上，隨著公司發(fā)展，服務(wù)的數(shù)量仍在增長——不過在一些組織（比如我所在組織），數(shù)量保持穩(wěn)定，或甚至減少了一點（不過這不是目標本身）。但是所有微服務(wù)不再是一個樣。關(guān)鍵的服務(wù)看起來不太像你的經(jīng)典微服務(wù)（或至少多年前我所說的微服務(wù)）。

另一方面，每個人對“微服務(wù)”這個名詞的解讀有所不同。我會撰寫一篇文章，總結(jié)我在使用大規(guī)模微服務(wù)方面的感受。

Gregdoesit：

優(yōu)步在2015年從整體式系統(tǒng)改用SOA。這種SOA遵循基于微服務(wù)的架構(gòu)。而我們一直在分享我們一路所學(xué)到的東西：構(gòu)建微服務(wù)通常需要采取的步驟，采用多租戶方法解決測試問題，以及我們?nèi)绾我约盀楹问褂梅植际礁櫋Ｎ覀冞€開源了自己的一些工具，比如Jaeger（它是云原生基金會的眾多畢業(yè)項目的一部分），與Kubernetes和Prometheus一樣。所有這些都給人帶來靈感和啟發(fā)：但是到頭來，你需要在自己的環(huán)境中做出你認為最有效的決定。誰要是明明連系統(tǒng)環(huán)境都不相似，就盲目照搬照抄谷歌、優(yōu)步、Uber、Shopify、Stack Overflow或其他公司，只會大失所望。

@copyconstruct：

?微服務(wù)很棘手。

?構(gòu)建可靠且可測試的微服務(wù)比大多數(shù)人認為的要難得多。

?有效地*測試*微服務(wù)需要大量的工具和深謀遠慮。

?許多（大多數(shù)？）組織不需要Netflix/優(yōu)步那樣的微服務(wù)。

?宏服務(wù)？

宏服務(wù)：

?不是整體式系統(tǒng)

?每3個團隊最多只有20名開發(fā)人員在開發(fā)服務(wù)（5個披薩規(guī)則？）

?是否擁有/需要整體式代碼倉庫（monorepo）不好說。服務(wù)/代碼倉庫數(shù)量較少，依賴項管理就變得容易得多（不過仍并非易事）

?更好的可觀察性和調(diào)試

當然，如果我們有一個像宏服務(wù)這樣新的半品牌術(shù)語，世界會為之瘋狂。

宏服務(wù)與我們幾十年來所熟知的老式服務(wù)有何不同？誰在乎。名稱只不過其時代的產(chǎn)物。名稱只是討論的基礎(chǔ)而已。這又不是什么魔法。名稱不是必須嚴加保管的秘密符號，以免魔術(shù)師將你變成他們手中的道具。名稱只是個聚集地，只是個標記，幫助我們找到出路。叫什么，無關(guān)緊要。

你可能也料到了，反響熱烈。大多數(shù)人熱情贊頌微服務(wù)這個禍害終于到頭了。持異議者的普遍共識就是，微服務(wù)向來是個壞主意。

@sandofsky：

優(yōu)步在2016年聲稱：“我們有數(shù)千個微服務(wù)?！?/span>

所有人：“這聽起來很瘋狂?！?/span>

優(yōu)步在2020年聲稱：“結(jié)果證明這太瘋狂了?！?/span>

@dhh：

過分熱情地采用微服務(wù)帶來了巨大的痛苦。

除了Majestic Monolith外，有人還應(yīng)詳細記述The Citadel的模式：單單一個Majestic Monolith占據(jù)了應(yīng)用程序的大部分，幾個輔助性的前哨應(yīng)用程序用于滿足高度專業(yè)化和多樣化的需求。

但評論不全是負面的。

@ saikishore001：

我們拜耳使用微服務(wù)取得了相當大的成功。對于我們來說，維護一個龐大的整體式系統(tǒng)如同噩夢……現(xiàn)在，采用了微服務(wù)架構(gòu)，情況好多了。

@ Carnage4Life：

優(yōu)步在2016年大力倡導(dǎo)微服務(wù)，但隨后卻遷離微服務(wù)，這給了世人兩大經(jīng)驗教訓(xùn)

1. 大公司在大規(guī)模環(huán)境下所做的取舍可能不適合你這家初創(chuàng)公司。

2. 大公司也會做出糟糕的架構(gòu)選擇，所以要提防貨物崇拜（cargo culting）。

@adam_zethraeus：

優(yōu)步這么做其實完全是為了避免協(xié)調(diào)成本。大體來說，明確鼓勵在無須關(guān)注重用或合并的情況下構(gòu)建，比如優(yōu)步的中國團隊復(fù)制了一批三級架構(gòu)，以加快行動速度。（短期內(nèi)奏效?。?/span>

這種架構(gòu)炒作周期有一個經(jīng)濟層面的觀點也值得考慮：

@ridingwithrails

在互聯(lián)網(wǎng)崩潰和衰退期間，整體式系統(tǒng)總是勝出。人們意識到，很難保持使用10種不同系統(tǒng)的10個團隊……

@sandofsky

每次技術(shù)討論都應(yīng)該披露風(fēng)險資金的燒錢速度。如果砸別人的錢來處理你的問題，你幾乎可以為所欲為而安然無事。

為微服務(wù)可能崩潰而欣喜對業(yè)界來說不是該有的樣子。我們需要專注于把事情做對，而不是暫時做對。我知道，目光短淺的人只想著暫時做對。

變革是我們前進的方式，而變革過程中添加阻力幫不了任何人。優(yōu)步成熟、學(xué)習(xí)和重構(gòu)是一件好事。這不是承認失敗，甚至不是表明早期做出錯誤決策的證據(jù)。如果你有大量資金，又有稱霸世界這一大膽冒險的目標，微服務(wù)大有意義。當貴公司增長的這個階段告一段落時，裁員和合并也大有意義。實際情況發(fā)生變化時，你如何是好？

實話實說，我們幾乎不知道怎么構(gòu)建軟件。我確信，微服務(wù)之所以大行其道，一方面是由于它至少為程序員提供了關(guān)于如何構(gòu)建程序的一個連貫的理論。

每個人都給出了自己偏愛的方法以替代微服務(wù)，但是缺乏共識，我們根本沒有系統(tǒng)性的理論。這整個討論就是明證。

軟件是一團糟。

END

歷史推薦

當當網(wǎng)的羊毛被網(wǎng)友薅慘了！這一次到底被薅了多少？

2020年六大容器應(yīng)用趨勢

為什么API需要網(wǎng)關(guān)？京東API網(wǎng)關(guān)實踐之路！

阿里巴巴為什么不用ZooKeeper做服務(wù)發(fā)現(xiàn)？

“中臺不就是微服務(wù)嘛？有啥區(qū)別?。俊?/a>

點個在看吧