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