長期以來，微服務一直被認為是雲原生服務應用程式架構的事實標準，現在像亞馬遜和谷歌這樣的雲巨頭正在重構它們。
翻譯自年度回顧：2023 年是微服務的轉折點 作者：Joab Jackson 是 The New Stack 的高階編輯，負責雲原生計算和系統運營。 他從事 IT 基礎設施和開發工作已超過 25 年，曾在 IDG 和 Government Computer News 任職。 在那之前，他。 也許我們對微服務的理解有問題？
這正是文章“邁向雲應用程式的現代開發”（PDF） 中關於 HOTOS 的一組 Google 工程師（由 Google 軟體工程師 Michael Whittaker 領導）'6月舉辦的第23屆（第19屆作業系統熱點問題研討會）。 正如 Whittaker 等人所指出的，微服務大多在架構上沒有正確設定。 它們混淆了邏輯邊界（如何編寫）和物理邊界（如何部署）。 這就是問題所在。 相反，谷歌工程師想出了另一種方法。 將應用程式構建為邏輯整體，然後由自動化執行時處理，該執行時根據應用程式的需求和可用資源決定在何處執行工作負載。 通過這種型別的延遲，他們能夠將系統的延遲降低 15 倍，並將成本降低多達 9 倍。
如果人們可以從有序的模組化開始，我們可以將部署架構視為實現細節，“Kelsey Hightower*** 在評論這項工作時說。 幾個月前，Amazon Prime Video 的工程團隊發表了一篇部落格文章，解釋說單體架構的效能優於微服務和無伺服器方法，至少在監控方面是這樣。 事實上，亞馬遜通過放棄微服務架構節省了 90% 的運營成本。
這一代工程師和架構師是在微服務的優越性下成長起來的，這種說法確實令人震驚。 “這篇文章對於亞馬遜作為一家公司來說是乙個真正的完全尷尬。 根本沒有內部協調或協同溝通，“Platify的分析師Donnie Berkholz寫道，她最近創辦了自己的行業分析公司。 “這個故事的獨特之處在於，亞馬遜是面向服務架構的縮影，”Ruby-on-Rails的建立者兼BaseCamp的聯合創始人D**Id Heinemeier Hansson說。 另一方面，無伺服器只會讓事情變得更糟。 ”
亞馬遜工程師的任務是監控 Prime 向客戶提供的數千個 ** 流。 最初，這項工作由一組分布式元件完成，這些元件由 AWS Step Functions（一種使用 AWS Lambda 無伺服器服務的無伺服器編排服務）協調。 從理論上講，使用無伺服器應該允許團隊獨立擴充套件每個服務。 然而，事實證明，至少在團隊實現元件的方式上，當他們只達到預期負載的 5% 時，他們遇到了硬性擴充套件限制。 由於需要在多個元件之間傳輸資料，擴充套件以監控數千個流的成本也將變得不經濟。 最初，該團隊試圖優化各個元件，但這並沒有帶來顯著的改進。 因此，該團隊將所有元件遷移到乙個程序中，該程序託管在 Amazon Elastic Compute Cloud （Amazon EC2） 和 Amazon Elastic Container Service （Amazon ECS） 上。
微服務和無伺服器元件是大規模執行工作的工具，但必須根據具體情況選擇它們而不是單體架構，“亞馬遜團隊總結道。
可以說，“微服務”一詞最早是由 Peter Rodgers 在 2005 年創造的，儘管他稱它們為“微 Web 服務”。 他為這個概念起了個名字，這個概念在當時的網路服務和面向服務架構（SOA）時代越來越受歡迎。
當時'微網服務'背後的主要動力是將單個大型'單體'設計拆分為多個獨立的元件程序，使庫更加精細和易於管理，“軟體工程師Amanda Bennett在一篇部落格文章中解釋道。 這個概念在隨後的幾十年裡得到了廣泛的採用，尤其是在雲原生計算時代，直到最近幾年，它才開始在某些領域受到批評。
軟體工程師 Alexander Kainz 對單體架構和微服務與 TNS 進行了出色的比較。
在他們的文章中，谷歌工程師列出了微服務方法的一些缺點，包括：
效能：序列化資料並通過網路將其傳送到遠端服務可能會影響效能，如果應用程式變得足夠複雜，甚至會導致瓶頸。
理解：在分布式系統中，由於微服務之間的許多互動，臭蟲通常難以跟蹤。
管理問題：認為應用程式的不同部分可以根據自己的時間表進行更新是乙個優勢。 但這導致開發人員必須管理大量二進位檔案，每個二進位檔案都有自己的發布時間表。 當您想要在本地執行的服務上執行端到端測試時，您可能會遇到困難。 API 變得易受攻擊微服務互操作性的關鍵在於，一旦建立了微服務，就無法更改 API，以免破壞依賴於該 API 的其他微服務。 因此，只能通過新增更多 API 來擴充套件 API，從而導致膨脹。
一種新型的微服務？
當 The New Stack 首次報道有關亞馬遜的新聞時，許多人很快指出，該團隊使用的架構也不完全是單體的。
這絕對不是乙個從微服務到單體的故事，“亞馬遜網路服務前副總裁、現任Nubank顧問的Adrian Cockcroft在接受The New Stack採訪時說。 我認為問題之一是標籤錯誤。 ”
他指出，在許多應用程式中，尤其是內部應用程式，開發成本超過了執行時成本。 在這些情況下，Step Functions 在節省開發時間方面很有意義，但在處理大量工作負載時可能會付出代價。
如果你知道你最終會以一定的規模執行它，“Cockcroft說，”你可能一開始就會以不同的方式構建它。 所以問題是，你知道怎麼做嗎，你知道它會以什麼規模執行嗎？科克羅夫特說。
Google 通過簡化開發人員的工作並使執行時基礎架構能夠找出執行這些應用程式的最具成本效益的方式來解決這個問題。
通過將所有執行責任委託給執行時，我們的解決方案能夠提供與微服務相同的優勢，但具有更高的效能和更低的成本，“谷歌研究人員寫道。
今年已經進行了許多基本的架構重新審視，微服務並不是唯一受到質疑的理想。
例如，雲計算也受到了審查。
今年6月，同時運營Basecamp和Hey電子郵件應用程式的公司37signals收購了一批戴爾伺服器並離開了雲，打破了數十年來將運營遷移到更高效率的傳統，並給出了更模糊的異地定義。 “這是雲營銷的核心欺騙，即一切都會變得如此簡單，以至於你幾乎不需要任何人來操作它，”D**ID Heinemeier Hansson在一篇部落格文章中解釋道。 “我從來沒見過。 在37signals，也沒有其他人執行大型網際網絡應用程式。 雲計算具有一些優勢，但通常不會在減少操作人員數量方面。 當然，DHH是一名賽車手，所以他很自然地深入挖掘硬體層。 但也有其他人願意支援這個賭注。 今年晚些時候，Oxide Computers推出了他們的新系統，希望為其他具有類似觀點的人提供服務：在自己的資料中心以更具成本效益的方式執行雲計算工作負載。 這種情緒似乎得到了更多的考慮，至少在雲賬單到期時是這樣。 FinOps 在 2023 年變得可見，越來越多的組織轉向像 Kubecost 這樣的公司來控制他們的雲支出。 有多少人對 Datadog 客戶收到 6500 萬美元的雲監控賬單感到驚訝可以說，對於一家產生數十億美元收入的公司來說，支付 6500 萬美元的可觀測性賬單可能是值得的。 但是，當首席建築師仔細研究過去十年的工程決策時，他們可能會決定進行一些調整。 微服務也不例外。
TNS 雲原生記者 Scott M富爾頓三世為本報告做出了貢獻。