撰稿 | 言征 如煙
2023，微服務“水逆”之年。
長期以來，不管大廠還是小廠，微服務都被認為是云原生服務應用程序架構的事實標準，然而2023，不止那位37signals的DHH決心下云，放棄微服務，就連亞馬遜和谷歌等這些云巨頭，正在帶頭開始革了微服務的命。
1、谷歌坐不住了：我們做的微服務都錯了！
“在編寫分布式應用程序時，傳統(tǒng)觀點認為將應用程序拆分為可以獨立推出的獨立服務。這種方法的初衷是好的，但像這樣基于微服務的體系結(jié)構往往會適得其反，帶來的挑戰(zhàn)抵消了體系結(jié)構試圖實現(xiàn)的好處?！?/p>
今年6月，一群谷歌員工（由谷歌軟件工程師Michael Whittaker領導）發(fā)表了一篇名為“Towards Modern Development of Cloud Applications”的論文，開篇就對當下的微服務架構開懟。
圖片
文章認為，從架構上講，微服務本身設置就有問題，它是一個沒有邊界的結(jié)構：“從根本上說，這是因為微服務將邏輯邊界（如何編寫代碼）與物理邊界（如何部署代碼）混為一談?！?/p>
因此，谷歌的工程師們提出了一種堪稱“微服務2.0”的方法。將應用程序構建為邏輯整體，但將其交給自動化運行時，后者可以根據(jù)應用程序所需的內(nèi)容和可用的內(nèi)容來決定在哪里運行工作負載。
圖片
基于新提出的結(jié)構，他們能夠?qū)⑾到y(tǒng)的延遲降低到1/15，成本降低到1/9。
“從有組織的模塊化代碼開始，我們就可以將部署架構作為實現(xiàn)細節(jié)，”Google開發(fā)人員倡導者Kelsey Hightower在10月份對這項工作表示了下一步計劃。
圖片
這群谷歌開發(fā)者們發(fā)現(xiàn)了將應用程序拆分為獨立部署的服務方法缺點太明顯，并給出了非常有創(chuàng)新性的3條原則：
（1）鼓勵開發(fā)人員編寫分為邏輯組件的單片應用程序
（2）將物理分布和執(zhí)行模塊化單片的挑戰(zhàn)推遲到運行時
（3）原子部署應用程序。
這三個指導原則帶來了許多好處，并會為未來的開發(fā)創(chuàng)新打開大門。
2、亞馬遜Prime Video團隊：放棄微服務，改用單體
無獨有偶，同樣是在6月，亞馬遜流媒體平臺 Prime Video發(fā)布的一則案例研究似乎改變了風向：“我們放棄了無服務器、微服務架構，改用單體架構取而代之，此舉為客戶節(jié)省90%的運營成本，還簡化了系統(tǒng)復雜度”。
單體應用對微服務的“反戈一擊”，還是亞馬遜團隊提出來的，再次讓這個話題迅速引爆技術圈。
整個案例看下來，微服務跟降本增效似乎也扯不到一起去。問題出在哪里？
Prime Video 團隊需要一個監(jiān)控視頻流質(zhì)量問題的工具，由于視頻數(shù)量太大，就要求該工具有很強的可擴展性。
最初這項工作是由一組分布式組件完成的，這些組件由AWS Step Functions（一種無服務器編排服務，AWS Lambda無服務器服務）編排，分分鐘就能搭出一個有模有樣的監(jiān)控系統(tǒng)。但誰能想到，Step Function 伸縮問題竟然成為最大的絆腳石。
具體來看，一是對于視頻流的每一秒，需要很多并發(fā)的 AWS Step Function，所以很快就達到了賬戶限制；二是 AWS Step Function 是按照狀態(tài)轉(zhuǎn)換向用戶收費的，太貴了實在用不起。
無奈之下，Prime Video開始考慮用單體的解決方案以降低成本和增加應用的擴展能力，在經(jīng)歷了反復試驗后，團隊最終決定重建Prime Video的整個基礎設施。
亞馬遜在博客文章總結(jié)道：“微服務和無服務器組件是可以大規(guī)模工作的工具，但是否在整體上使用它們必須根據(jù)具體情況而定……將服務遷移成單體讓我們的基礎設施成本降低了 90%以上，還提升了我們的伸縮能力?！?/p>
這就說明，至少在視頻監(jiān)控領域，單體架構比微服務、無服務器主導的方法產(chǎn)生了更高的性能、更能降本增效。
始終鼓吹下云和反對微服務化的DHH（ Ruby on Rails創(chuàng)始人，David Heinemeier Hansson）一針見血地指出：連亞馬遜自個都覺得微服務或無服務器“扯淡”了。
3、放棄微服務的，不止谷歌、亞馬遜
最近幾年，無數(shù)的中小團隊在權衡利弊后選擇放棄微服務。
Uber 就是其中一家，此前 Uber 通過構建微服務來完成很小的需求或功能，甚至出現(xiàn)很多由一個人構建維護的微服務。這些微服務的存在給Uber帶來了更多的挑戰(zhàn)，比如監(jiān)控、測試、持續(xù)集成 / 持續(xù)交付（CI/CD）、服務級別協(xié)議（SLA）等。
踩了微服務的“坑”之后，Uber 團隊對新服務進行了更加深思熟慮的規(guī)劃：不再只是完成一件事，而是使其服務于一項業(yè)務功能，由 5-10 個工程師負責維護，還總結(jié)出了血淚教訓：要在正確的時間選擇正確的解決方案來構建產(chǎn)品。
辦公管理軟件公司 Managed by Q 的應用程序是一個部署在 ECS 上的 Django 單體。為了趕上現(xiàn)代化開發(fā)實踐的步伐，他們轉(zhuǎn)向微服務架構。但他們很快發(fā)現(xiàn)，每多一個新服務，就會增加一些基礎設施，而且開發(fā)一個跨多個服務的功能需要做更多的工作。
結(jié)果，在轉(zhuǎn)向微服務兩年之后，他們開始合并微服務。一些微服務被合到了單體中，其他的則合并成較大的服務。他們也在實踐中得出經(jīng)驗：不能理所當然地認為微服務就是正確的選擇。
本來想把微服務當銀彈，結(jié)果工程開銷太大，得不償失。以上提到的企業(yè)最大的問題是在只有20位工程師的環(huán)境中實現(xiàn)了幾十個微服務，有種殺雞焉用牛刀的錯位感。
4、微服務的虛假繁榮：從單體變成“分布式單體”
隨著越來越多“逃離微服務”的案例發(fā)生，人們對于2005年就提出的“微服務”再度審視，甚至批評。
比如開頭提到的谷歌工程師們，就在他們的論文中列出了目前微服務方法的缺陷，包括：
- 性能：通過網(wǎng)絡將數(shù)據(jù)序列化并發(fā)送到遠程服務會損害性能，如果應用程序變得足夠復雜，甚至可能導致瓶頸。
- 理解追蹤：眾所周知，在分布式系統(tǒng)中，考慮到微服務之間的許多交互，很難追蹤Bug。
- 管理問題：應用程序的不同部分可以按照自己的時間表進行更新，這被認為是一個優(yōu)勢。但這導致開發(fā)人員不得不管理大量的二進制文件，每個二進制文件都有自己的發(fā)布時間表。祝您好運，使用本地運行的服務運行端到端測試。
- API變得脆弱：微服務互操作性的關鍵是，一旦建立了微服務，API就不能改變，讓它們破壞任何其他依賴API的微服務。因此，API只能用更多的API進行擴展，從而產(chǎn)生膨脹。
看起來跟之前提到的“過度設計”的概念不謀而合。
事實上有些團隊在將集中式單體應用拆分為微服務時，首先進行的往往不是建立領域模型，而只是按照業(yè)務功能將原來單體應用的一個軟件包拆分成多個所謂的“微服務”軟件包，而這些“微服務”內(nèi)的代碼高度耦合，邏輯邊界不清晰，本質(zhì)上還是單體架構模式，所以只是實現(xiàn)了“表面繁榮”，并沒有實現(xiàn)想要的結(jié)果。
正如Sam Newman在《構建微服務》一書中提到的那樣，架構需要滿足一定的前提條件，否則就可能過度設計。
5、谷歌提出了一種新的微服務
業(yè)內(nèi)有這樣一種依舊支持微服務架構的觀點：微服務需要與之匹配的規(guī)模?！叭绻阒雷罱K會以一定的規(guī)模來做這件事，在開始時可能會以不同的方式來構建它。但問題就在于，你知道如何做這件事情嗎？你知道你將以多大的規(guī)模來運營它嗎？”
事實上在許多應用程序中，尤其是內(nèi)部應用程序，開發(fā)成本往往會超過了運行時成本。
谷歌的論文恰恰解決了這個問題，編程模式和部署模式的分開，可以讓開發(fā)人員更加輕松，同時讓運行時基礎設施的“賭注”找到運行這些應用程序的最具成本效益的方法。
正如谷歌研究人員所寫道的：“通過將所有執(zhí)行責任委托給運行時，我們的解決方案能夠提供與微服務相同的好處，但性能更高，成本更低?！?/p>
6、基礎架構重新思考的一年
今年進行了許多基礎架構的重新思考，微服務并不是唯一被質(zhì)疑的泡沫。例如，云計算也受到了審查。
6月，同時運行Basecamp和Hey電子郵件應用程序的37signals公司采購了一批戴爾服務器，并離開了云計算，打破了幾十年來大家拋棄老舊擁抱新故事的傳統(tǒng)。
David Heinemeier Hansson在一篇博客文章中解釋道：“這是云營銷的常用話術：它會變得容易得多，幾乎不需要任何人來操作?！薄埃ǖ聦嵤牵┪覐膩頉]有見過。37signals沒有，來自大型互聯(lián)網(wǎng)公司的人也沒有見過。云有一些優(yōu)勢，但它通常不會減少運維人員?！?/p>
當然，DHH是一名賽車手，有可能更喜歡裸機。但也有不少擁躉愿意支持這一賭注。今年晚些時候，Oxide Computers推出了他們的新系統(tǒng)，希望能為其他人提供類似的服務：運行云計算工作負載，但在自己的數(shù)據(jù)中心更具成本效益。
此外，在云賬單即將到期的情況下，這種情緒似乎更加強烈。2023年，隨著越來越多的組織轉(zhuǎn)向KubeCost等公司來控制其云支出，F(xiàn)inOps成為一件引人注目的事。一位DataDog的客戶收到6500萬美元的云監(jiān)控賬單的消息，也再次讓業(yè)界無數(shù)人驚到了。
也許對于一個創(chuàng)造數(shù)十億收入的機構來說，6500萬美元的可觀測性賬單可能是值得的。但是對于架構師而言，面對過去十年中做出的工程決策帶來的技術債，也許是時候做出一些調(diào)整的決定。
當然，微服務也不例外。
參考鏈接：
https://thenewstack.io/year-in-review-was-2023-a-turning-point-for-microservices/
