使用微服務往往是有代價的，而這種代價往往會被低估。
原文鏈接：https://code-held.com/2022/07/28/microservices/
(資料圖片)
作者 | Marcus Held
譯者 | 彎月 責編 | 屠敏
出品 | CSDN（ID：CSDNnews）
在過去的幾年里，我曾圍繞微服務這個話題采訪過數百個人，很多人都自豪地講述了他們使用微服務架構開發項目的故事。然而，無需太多提問就可以看出他們發射了一枚大火箭，最后卻只是干掉了一只老鼠。
微服務很難。每個接觸過這類架構的人都有著痛苦的經歷。終有一天，你會被復雜性淹沒，而且你不得不對架構進行多次重構。我很納悶，為什么這種架構對開發人員如此有吸引力？然后，我想起十年前自己也被這種框架所吸引。
大多人的共同經歷是，他們不得不面對一個遺留下來的單體系統，而且整個代碼庫都是一團糟。遇到這種情況很令人沮喪。實現需要很長時間，編寫測試很乏味甚至幾乎不可能，理解代碼也很困難，bug 堆積如山，部署也不可靠，每次代碼變更都會引發問題。重構遺留代碼似乎是不可能的，而且一想到這個問題就會讓你覺得頭疼，甚至徹夜難眠。
這個時候，微服務就會變得非常具有吸引力。那一刻，小型、可管理、分離的代碼庫會帶給你極大的安全感和解脫感。
但是，使用微服務也是有代價的，而且往往容易被低估。
弊端1：無法正確切分領域
只有當你能夠正確切分領域時，使用微服務才有效。然而，領域的劃分非常艱難。你需要知道自己構建的是什么，但往往大多數時候我們并不是特別清楚。完全綁定到一個領域，會導致系統的靈活性降低，而這恰恰與你實際的期望背道而馳。
在切分領域時，有可能你還不清楚產品需求。將來難免會出現一個功能，迫使兩個服務糾纏在一起，這就導致它們屬于同一個領域，卻還是分布式的。
弊端2：復雜性
雖然剛開始的時候，微服務的架構看起來非常簡單。架構師非常確定這種架構不會被打破，而且對于團隊來說，只需要維護一個小型代碼庫，感覺很舒服。然而到了部署服務時，情況就會發生變化。你需要協調一切。儀表板、監控系統、日志聚合器、部署、CI 作業、警報、文檔……而且你引入這些服務只是因為你的架構有這種需求。你需要分布式隊列、共享緩存、共享數據庫、服務發現、多個負載均衡器、動態路由器、API 網關、中央配置服務器……
于是，代碼泥沼變成了基礎設施泥沼。優步這樣的大公司經歷過慘痛的教訓后，終于意識到了這一點：
弊端3：過早優化
幾十年來，我們將軟件分割成了各種服務，只不過我們沒有稱它們為“微服務”。我們拆分應用程序主要有兩個原因。
首先，這種拆分對組織來說有意義。
很明顯，我們應該建立兩個獨立的團隊分別負責客戶關系管理工具和電子商務平臺，盡管這兩個平臺有時候需要相互交流。這已經是一個面向服務的架構。為了實現銷售產品的單一業務目標，我們需要兩項服務。只不過我們從未稱其為微服務架構。
其次，為了性能。
根據我的經驗，受這個原因影響的軟件只有1%。如果只有幾百個用戶，使用垂直擴展就可以了。我們開發的系統有數以萬計的并發用戶，這些用戶與系統進行了大量交互，但我們仍然能夠垂直擴展。
我們想要什么？
我們發現了一個問題：遺留系統這個巨大的泥潭。可惜微服務架構并不是解決這個問題的正確方法。你需要的是模塊，正確的模塊，因為模塊使得我們很難越界，而且可以根據需要輕松、獨立地部署模塊。這個概念本身并不新穎，但很多人往往無法正確實施。
十年前，我想要模塊，卻采納了微服務架構，現在是時候結束這種過度設計了。
《2022-2023 中國開發者大調查》重磅啟動，歡迎掃描下方二維碼，參與問卷調研，更有 iPad 等精美大禮等你拿！
? 兩萬字長文，史上最全 C++ 年度總結！
? 在 MacOS 上運行 Docker 太慢！
? 為了忘卻的紀念——2022 Linux 內核十大技術革新功能 | 年終盤點
責任編輯：Rex_19
營業執照公示信息