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