微服務(wù)全做錯(cuò)了！谷歌提出新方法，成本直接降為1/9！

作者：言征 2023-12-27 18:12:50

也許對(duì)于一個(gè)創(chuàng)造數(shù)十億收入的機(jī)構(gòu)來(lái)說，6500萬(wàn)美元的可觀測(cè)性賬單可能是值得的。但是對(duì)于架構(gòu)師而言，面對(duì)過去十年中做出的工程決策帶來(lái)的技術(shù)債，也許是時(shí)候做出一些調(diào)整的決定。

撰稿 | 言征如煙

2023，微服務(wù)“水逆”之年。

長(zhǎng)期以來(lái)，不管大廠還是小廠，微服務(wù)都被認(rèn)為是云原生服務(wù)應(yīng)用程序架構(gòu)的事實(shí)標(biāo)準(zhǔn)，然而2023，不止那位37signals的DHH決心下云，放棄微服務(wù)，就連亞馬遜和谷歌等這些云巨頭，正在帶頭開始革了微服務(wù)的命。

1、谷歌坐不住了：我們做的微服務(wù)都錯(cuò)了！

“在編寫分布式應(yīng)用程序時(shí)，傳統(tǒng)觀點(diǎn)認(rèn)為將應(yīng)用程序拆分為可以獨(dú)立推出的獨(dú)立服務(wù)。這種方法的初衷是好的，但像這樣基于微服務(wù)的體系結(jié)構(gòu)往往會(huì)適得其反，帶來(lái)的挑戰(zhàn)抵消了體系結(jié)構(gòu)試圖實(shí)現(xiàn)的好處。”

今年6月，一群谷歌員工（由谷歌軟件工程師Michael Whittaker領(lǐng)導(dǎo)）發(fā)表了一篇名為“Towards Modern Development of Cloud Applications”的論文，開篇就對(duì)當(dāng)下的微服務(wù)架構(gòu)開懟。

圖片

文章認(rèn)為，從架構(gòu)上講，微服務(wù)本身設(shè)置就有問題，它是一個(gè)沒有邊界的結(jié)構(gòu)：“從根本上說，這是因?yàn)槲⒎?wù)將邏輯邊界（如何編寫代碼）與物理邊界（如何部署代碼）混為一談。”

因此，谷歌的工程師們提出了一種堪稱“微服務(wù)2.0”的方法。將應(yīng)用程序構(gòu)建為邏輯整體，但將其交給自動(dòng)化運(yùn)行時(shí)，后者可以根據(jù)應(yīng)用程序所需的內(nèi)容和可用的內(nèi)容來(lái)決定在哪里運(yùn)行工作負(fù)載。

圖片

基于新提出的結(jié)構(gòu)，他們能夠?qū)⑾到y(tǒng)的延遲降低到1/15，成本降低到1/9。

“從有組織的模塊化代碼開始，我們就可以將部署架構(gòu)作為實(shí)現(xiàn)細(xì)節(jié)，”Google開發(fā)人員倡導(dǎo)者Kelsey Hightower在10月份對(duì)這項(xiàng)工作表示了下一步計(jì)劃。

圖片

這群谷歌開發(fā)者們發(fā)現(xiàn)了將應(yīng)用程序拆分為獨(dú)立部署的服務(wù)方法缺點(diǎn)太明顯，并給出了非常有創(chuàng)新性的3條原則：

（1）鼓勵(lì)開發(fā)人員編寫分為邏輯組件的單片應(yīng)用程序

（2）將物理分布和執(zhí)行模塊化單片的挑戰(zhàn)推遲到運(yùn)行時(shí)

（3）原子部署應(yīng)用程序。

這三個(gè)指導(dǎo)原則帶來(lái)了許多好處，并會(huì)為未來(lái)的開發(fā)創(chuàng)新打開大門。

2、亞馬遜Prime Video團(tuán)隊(duì)：放棄微服務(wù)，改用單體

無(wú)獨(dú)有偶，同樣是在6月，亞馬遜流媒體平臺(tái) Prime Video發(fā)布的一則案例研究似乎改變了風(fēng)向：“我們放棄了無(wú)服務(wù)器、微服務(wù)架構(gòu)，改用單體架構(gòu)取而代之，此舉為客戶節(jié)省90%的運(yùn)營(yíng)成本，還簡(jiǎn)化了系統(tǒng)復(fù)雜度”。

單體應(yīng)用對(duì)微服務(wù)的“反戈一擊”，還是亞馬遜團(tuán)隊(duì)提出來(lái)的，再次讓這個(gè)話題迅速引爆技術(shù)圈。

整個(gè)案例看下來(lái)，微服務(wù)跟降本增效似乎也扯不到一起去。問題出在哪里？

Prime Video 團(tuán)隊(duì)需要一個(gè)監(jiān)控視頻流質(zhì)量問題的工具，由于視頻數(shù)量太大，就要求該工具有很強(qiáng)的可擴(kuò)展性。

最初這項(xiàng)工作是由一組分布式組件完成的，這些組件由AWS Step Functions（一種無(wú)服務(wù)器編排服務(wù)，AWS Lambda無(wú)服務(wù)器服務(wù)）編排，分分鐘就能搭出一個(gè)有模有樣的監(jiān)控系統(tǒng)。但誰(shuí)能想到，Step Function 伸縮問題竟然成為最大的絆腳石。

具體來(lái)看，一是對(duì)于視頻流的每一秒，需要很多并發(fā)的 AWS Step Function，所以很快就達(dá)到了賬戶限制；二是 AWS Step Function 是按照狀態(tài)轉(zhuǎn)換向用戶收費(fèi)的，太貴了實(shí)在用不起。

無(wú)奈之下，Prime Video開始考慮用單體的解決方案以降低成本和增加應(yīng)用的擴(kuò)展能力，在經(jīng)歷了反復(fù)試驗(yàn)后，團(tuán)隊(duì)最終決定重建Prime Video的整個(gè)基礎(chǔ)設(shè)施。

亞馬遜在博客文章總結(jié)道：“微服務(wù)和無(wú)服務(wù)器組件是可以大規(guī)模工作的工具，但是否在整體上使用它們必須根據(jù)具體情況而定……將服務(wù)遷移成單體讓我們的基礎(chǔ)設(shè)施成本降低了 90%以上，還提升了我們的伸縮能力。”

這就說明，至少在視頻監(jiān)控領(lǐng)域，單體架構(gòu)比微服務(wù)、無(wú)服務(wù)器主導(dǎo)的方法產(chǎn)生了更高的性能、更能降本增效。

始終鼓吹下云和反對(duì)微服務(wù)化的DHH（ Ruby on Rails創(chuàng)始人，David Heinemeier Hansson）一針見血地指出：連亞馬遜自個(gè)都覺得微服務(wù)或無(wú)服務(wù)器“扯淡”了。

3、放棄微服務(wù)的，不止谷歌、亞馬遜

最近幾年，無(wú)數(shù)的中小團(tuán)隊(duì)在權(quán)衡利弊后選擇放棄微服務(wù)。

Uber 就是其中一家，此前 Uber 通過構(gòu)建微服務(wù)來(lái)完成很小的需求或功能，甚至出現(xiàn)很多由一個(gè)人構(gòu)建維護(hù)的微服務(wù)。這些微服務(wù)的存在給Uber帶來(lái)了更多的挑戰(zhàn)，比如監(jiān)控、測(cè)試、持續(xù)集成 / 持續(xù)交付（CI/CD）、服務(wù)級(jí)別協(xié)議（SLA）等。

踩了微服務(wù)的“坑”之后，Uber 團(tuán)隊(duì)對(duì)新服務(wù)進(jìn)行了更加深思熟慮的規(guī)劃：不再只是完成一件事，而是使其服務(wù)于一項(xiàng)業(yè)務(wù)功能，由 5-10 個(gè)工程師負(fù)責(zé)維護(hù)，還總結(jié)出了血淚教訓(xùn)：要在正確的時(shí)間選擇正確的解決方案來(lái)構(gòu)建產(chǎn)品。

辦公管理軟件公司 Managed by Q 的應(yīng)用程序是一個(gè)部署在 ECS 上的 Django 單體。為了趕上現(xiàn)代化開發(fā)實(shí)踐的步伐，他們轉(zhuǎn)向微服務(wù)架構(gòu)。但他們很快發(fā)現(xiàn)，每多一個(gè)新服務(wù)，就會(huì)增加一些基礎(chǔ)設(shè)施，而且開發(fā)一個(gè)跨多個(gè)服務(wù)的功能需要做更多的工作。

結(jié)果，在轉(zhuǎn)向微服務(wù)兩年之后，他們開始合并微服務(wù)。一些微服務(wù)被合到了單體中，其他的則合并成較大的服務(wù)。他們也在實(shí)踐中得出經(jīng)驗(yàn)：不能理所當(dāng)然地認(rèn)為微服務(wù)就是正確的選擇。

本來(lái)想把微服務(wù)當(dāng)銀彈，結(jié)果工程開銷太大，得不償失。以上提到的企業(yè)最大的問題是在只有20位工程師的環(huán)境中實(shí)現(xiàn)了幾十個(gè)微服務(wù)，有種殺雞焉用牛刀的錯(cuò)位感。

4、微服務(wù)的虛假繁榮：從單體變成“分布式單體”

隨著越來(lái)越多“逃離微服務(wù)”的案例發(fā)生，人們對(duì)于2005年就提出的“微服務(wù)”再度審視，甚至批評(píng)。

比如開頭提到的谷歌工程師們，就在他們的論文中列出了目前微服務(wù)方法的缺陷，包括：

性能：通過網(wǎng)絡(luò)將數(shù)據(jù)序列化并發(fā)送到遠(yuǎn)程服務(wù)會(huì)損害性能，如果應(yīng)用程序變得足夠復(fù)雜，甚至可能導(dǎo)致瓶頸。
理解追蹤：眾所周知，在分布式系統(tǒng)中，考慮到微服務(wù)之間的許多交互，很難追蹤Bug。
管理問題：應(yīng)用程序的不同部分可以按照自己的時(shí)間表進(jìn)行更新，這被認(rèn)為是一個(gè)優(yōu)勢(shì)。但這導(dǎo)致開發(fā)人員不得不管理大量的二進(jìn)制文件，每個(gè)二進(jìn)制文件都有自己的發(fā)布時(shí)間表。祝您好運(yùn)，使用本地運(yùn)行的服務(wù)運(yùn)行端到端測(cè)試。
API變得脆弱：微服務(wù)互操作性的關(guān)鍵是，一旦建立了微服務(wù)，API就不能改變，讓它們破壞任何其他依賴API的微服務(wù)。因此，API只能用更多的API進(jìn)行擴(kuò)展，從而產(chǎn)生膨脹。

看起來(lái)跟之前提到的“過度設(shè)計(jì)”的概念不謀而合。

事實(shí)上有些團(tuán)隊(duì)在將集中式單體應(yīng)用拆分為微服務(wù)時(shí)，首先進(jìn)行的往往不是建立領(lǐng)域模型，而只是按照業(yè)務(wù)功能將原來(lái)單體應(yīng)用的一個(gè)軟件包拆分成多個(gè)所謂的“微服務(wù)”軟件包，而這些“微服務(wù)”內(nèi)的代碼高度耦合，邏輯邊界不清晰，本質(zhì)上還是單體架構(gòu)模式，所以只是實(shí)現(xiàn)了“表面繁榮”，并沒有實(shí)現(xiàn)想要的結(jié)果。

正如Sam Newman在《構(gòu)建微服務(wù)》一書中提到的那樣，架構(gòu)需要滿足一定的前提條件，否則就可能過度設(shè)計(jì)。

5、谷歌提出了一種新的微服務(wù)

業(yè)內(nèi)有這樣一種依舊支持微服務(wù)架構(gòu)的觀點(diǎn)：微服務(wù)需要與之匹配的規(guī)模。“如果你知道最終會(huì)以一定的規(guī)模來(lái)做這件事，在開始時(shí)可能會(huì)以不同的方式來(lái)構(gòu)建它。但問題就在于，你知道如何做這件事情嗎？你知道你將以多大的規(guī)模來(lái)運(yùn)營(yíng)它嗎？”

事實(shí)上在許多應(yīng)用程序中，尤其是內(nèi)部應(yīng)用程序，開發(fā)成本往往會(huì)超過了運(yùn)行時(shí)成本。

谷歌的論文恰恰解決了這個(gè)問題，編程模式和部署模式的分開，可以讓開發(fā)人員更加輕松，同時(shí)讓運(yùn)行時(shí)基礎(chǔ)設(shè)施的“賭注”找到運(yùn)行這些應(yīng)用程序的最具成本效益的方法。

正如谷歌研究人員所寫道的：“通過將所有執(zhí)行責(zé)任委托給運(yùn)行時(shí)，我們的解決方案能夠提供與微服務(wù)相同的好處，但性能更高，成本更低。”

6、基礎(chǔ)架構(gòu)重新思考的一年

今年進(jìn)行了許多基礎(chǔ)架構(gòu)的重新思考，微服務(wù)并不是唯一被質(zhì)疑的泡沫。例如，云計(jì)算也受到了審查。

6月，同時(shí)運(yùn)行Basecamp和Hey電子郵件應(yīng)用程序的37signals公司采購(gòu)了一批戴爾服務(wù)器，并離開了云計(jì)算，打破了幾十年來(lái)大家拋棄老舊擁抱新故事的傳統(tǒng)。

David Heinemeier Hansson在一篇博客文章中解釋道：“這是云營(yíng)銷的常用話術(shù)：它會(huì)變得容易得多，幾乎不需要任何人來(lái)操作。”“（但事實(shí)是）我從來(lái)沒有見過。37signals沒有，來(lái)自大型互聯(lián)網(wǎng)公司的人也沒有見過。云有一些優(yōu)勢(shì)，但它通常不會(huì)減少運(yùn)維人員。”

當(dāng)然，DHH是一名賽車手，有可能更喜歡裸機(jī)。但也有不少擁躉愿意支持這一賭注。今年晚些時(shí)候，Oxide Computers推出了他們的新系統(tǒng)，希望能為其他人提供類似的服務(wù)：運(yùn)行云計(jì)算工作負(fù)載，但在自己的數(shù)據(jù)中心更具成本效益。

此外，在云賬單即將到期的情況下，這種情緒似乎更加強(qiáng)烈。2023年，隨著越來(lái)越多的組織轉(zhuǎn)向KubeCost等公司來(lái)控制其云支出，F(xiàn)inOps成為一件引人注目的事。一位DataDog的客戶收到6500萬(wàn)美元的云監(jiān)控賬單的消息，也再次讓業(yè)界無(wú)數(shù)人驚到了。

當(dāng)然，微服務(wù)也不例外。