使用微服務往往是有代價的，而這種代價往往會被低估。
原文連結：https://code-held.com/2022/07/28/microservices/
聲明：本文為 CSDN 翻譯，未經允許，禁止轉載。
作者 | Marcus Held
譯者 | 彎月 責編 | 屠敏
在過去的幾年裡，我曾圍繞微服務這個話題採訪過數百個人，很多人都自豪地講述了他們使用微服務架構開發項目的故事。然而，無需太多提問就可以看出他們發射了一枚大火箭，最後卻只是幹掉了一隻老鼠。
微服務很難。每個接觸過這類架構的人都有著痛苦的經歷。終有一天，你會被複雜性淹沒，而且你不得不對架構進行多次重構。我很納悶，為什麼這種架構對開發人員如此有吸引力？然後，我想起十年前自己也被這種框架所吸引。
大多人的共同經歷是，他們不得不面對一個遺留下來的單體系統，而且整個程式碼庫都是一團糟。遇到這種情況很令人沮喪。實現需要很長時間，編寫測試很乏味甚至幾乎不可能，理解程式碼也很困難，bug 堆積如山，部署也不可靠，每次程式碼變更都會引發問題。重構遺留程式碼似乎是不可能的，而且一想到這個問題就會讓你覺得頭疼，甚至徹夜難眠。
這個時候，微服務就會變得非常具有吸引力。那一刻，小型、可管理、分離的程式碼庫會帶給你極大的安全感和解脫感。
但是，使用微服務也是有代價的，而且往往容易被低估。
弊端1：無法正確切分領域
只有當你能夠正確切分領域時，使用微服務才有效。然而，領域的劃分非常艱難。你需要知道自己構建的是什麼，但往往大多數時候我們並不是特別清楚。完全綁定到一個領域，會導致系統的靈活性降低，而這恰恰與你實際的期望背道而馳。
在切分領域時，有可能你還不清楚產品需求。將來難免會出現一個功能，迫使兩個服務糾纏在一起，這就導致它們屬於同一個領域，卻還是分散式的。
弊端2：複雜性
雖然剛開始的時候，微服務的架構看起來非常簡單。架構師非常確定這種架構不會被打破，而且對於團隊來說，只需要維護一個小型程式碼庫，感覺很舒服。然而到了部署服務時，情況就會發生變化。你需要協調一切。儀表板、監控系統、日誌聚合器、部署、CI 作業、警報、文件……而且你引入這些服務只是因為你的架構有這種需求。你需要分散式隊列、共享快取、共享資料庫、服務發現、多個負載均衡器、動態路由器、API 網關、中央配置伺服器……
於是，程式碼泥沼變成了基礎設施泥沼。優步這樣的大公司經歷過慘痛的教訓後，終於意識到了這一點：
弊端3：過早最佳化
幾十年來，我們將軟體分割成了各種服務，只不過我們沒有稱它們為「微服務」。我們拆分應用程序主要有兩個原因。
首先，這種拆分對組織來說有意義。
很明顯，我們應該建立兩個獨立的團隊分別負責客戶關係管理工具和電子商務平臺，儘管這兩個平臺有時候需要相互交流。這已經是一個面向服務的架構。為了實現銷售產品的單一業務目標，我們需要兩項服務。只不過我們從未稱其為微服務架構。
其次，為了性能。
根據我的經驗，受這個原因影響的軟體只有1%。如果只有幾百個使用者，使用垂直擴展就可以了。我們開發的系統有數以萬計的併發使用者，這些使用者與系統進行了大量互動，但我們仍然能夠垂直擴展。
我們想要什麼？
我們發現了一個問題：遺留系統這個巨大的泥潭。可惜微服務架構並不是解決這個問題的正確方法。你需要的是模組，正確的模組，因為模組使得我們很難越界，而且可以根據需要輕鬆、獨立地部署模組。這個概念本身並不新穎，但很多人往往無法正確實施。
十年前，我想要模組，卻採納了微服務架構，現在是時候結束這種過度設計了。
