瞭解微服務艱難的一面

2016年底，我和團隊開始構建一個全新的平臺。想要實現開發人員的終極夢想——沒有遺留程式碼，無需擔心向後相容的問題，最好的一點是，可以自由選擇最適合工作的正確技術。

三年後，在很多痛苦和折磨之後，我現在可以做一些反省了。在深入探討之前，我想宣佈兩件事。

我們無法知道如果選擇不同的方式結果是否會不同，但是在之前沒有重視的領域/架構方面的確有一些非常重要的建議。現在，我們自認為理解得更透徹了。

因此對於那些想要做類似專案的人來說，提出一些我很後悔自己當初沒有遵守的建議。

忽略的建議#1：康威定律

康威定律認為系統架構會不可避免地以某種方式重構所在企業的組織架構。

隨著平臺的演進，我們編寫並運維著30～40個微服務。其中一些用不同的語言重寫過。

自從開始構建起，熟練的後臺開發人員從來沒有超過一名。因為我們一直是小而緊湊的團隊，每個開發人員都得在所有服務上工作。團隊一起制定架構決策，on call意味著處理任何領域的可能問題。

從過高的服務/開發人員比例上你可能會猜到，我們的服務最終是看上去“分離“實際上緊耦合的。這對我們傷害很大。

因為耦合緊，所以一直透過同一時間“僅僅“部署跨服務的變更來降低工作量，這直接違反了獨立部署[1]的原則。

忽略的建議#2 你不是Google

微服務的一大好處是可以獨立擴充套件。在最初的設計裡，我們已經將在規模加大時可能成為瓶頸的元件分離了出來。事實證明，我們所預計的規模遠遠超出了現實裡可能遇到的任何規模。

實際上，我們不僅僅憑猜測確定域邊界，而且每個服務都有一定的overhead。我們為運維功能執行一系列的sidecar容器和Kubernetes的DaemonSet（比如監控和日誌）。這導致我們在這些支撐的基礎架構上花費的資源比實際應用程式還多，而且多很多。

我這裡並不是說使用單體應用更好，但是如果可以重新選擇從更為簡單的架構開始，我會：

忽略的建議#3：你仍然不是Google

微服務的另一個好處是可以為工作選擇最佳的工具。我們選擇了很多語言，執行著使用Python，NodeJS和Golang編寫的服務。總的來說這樣很不錯，但是要編寫共享庫的時候就是個噩夢了，因為同樣的功能得用三種不同的語言都實現一遍。

我的確相信應該實驗不同的工具，但是最終的所有東西都需要能夠支撐生產環境並且長期維護。如果編寫內部共享庫，讓服務都用這個庫，這就不再是實驗而已了。

最終我們只能選擇單一語言。而結果也很好。儘可能多地實驗，但是一定要構建出可以重複使用的主要技術棧，一致性也很有價值。如果你使用相同的工具運維所有服務的時候（比如，Web伺服器使用資料庫連線），這就尤其重要。

忽略的建議#4：所有東西都是權衡

微服務架構也有很多缺點。我在這裡不會詳細介紹（有人已經寫過文章[2]了），不過我覺得理解你將要做什麼很重要。

如果我們坐下來比對優缺點，很可能會發現只有在有多個後臺團隊，使用不同的軟體解決不同問題時微服務架構才有價值。

瞭解微服務艱難的一面

教訓

我們花費了時間和精力轉回了之前的道路。在2019年1月份，我們往回一步檢視架構，確定了10個耦合很緊的服務，將它們整合成1個服務。

我們也已經緩慢地構建了Python服務，以及一個Golang服務。有些情況下這意味著使用NodeJS重寫。最終需要維護的是一個共享的JavaScript庫。

收穫

如果我可以回到過去，會給當時的自己這些警告：

為已知的問題做設計，對未來的猜測要謹慎
從少數大型服務開始，並且仔細地設計邊界。首要法則是一個微服務比兩個要好，除非你真的能找到拆分它們的強烈理由。當然，總是有很多有效的理由，但是確保在決策之前真正理解這些理由。
當實驗以及構建MVP服務時，要非常清楚地知道不會做什麼並且要堅持住。不然很容易就會陷入維護錯誤方案的陷阱裡。

相關連結：

原文連結：

瞭解微服務艱難的一面

相關文章