停止盲目使用微服務

作者 | GreekDataGuy

譯者 | Sambodhi

策劃 | 辛曉亮

為什麼大多數公司最好要避免使用微服務呢？微服務看起來是一種很好的解決方案。從理論上講，微服務可以加快開發速度，同時允許你獨立擴充應用程式的不同部分。但在現實中，微服務是有隐藏成本的。也就是說，我認為，在沒有親自建構微服務之前，你不可能了解它們有多複雜。

下面是我在建構微服務（有時是失敗的）時所學到的經驗心得。

管理資料是一場噩夢

保持微服務間的資料同步可能是一項挑戰。

每個微服務都有一個資料庫，這是推薦的模式。它允許松散的耦合，并且可以讓特定服務團隊在無需放慢速度協作共享代碼的情況下，獨立地工作。但如果本應同步啟動的微服務中的一個出現故障時，會發生什麼呢？比如，其中一個微服務更新了其資料庫，而另外一個卻沒有。這種情形會導緻資料不一緻。

根據個人的經驗，調查跨服務的資料不一緻會非常痛苦。錯誤的跨服務性質需要一個人在不同的服務中工作來修正錯誤。遺憾的是，這就導緻了微服務的優勢，即專門針對團隊的服務，無法發揮作用。

在一個單體應用中，隻要把兩個資料庫調用合并到一個原子事務中，就能很容易地避免這種情況，是以，所有的插入都會成功，或者都不會成功。非常的簡單。但是，松散的藕合會使微服務變得更為難以實作。

設定時間更長

建構一個微服務架構所花費的時間要比将相同的特性整合到一個單體應用中要多得多。盡管單個服務是非常簡單的，但是互動的服務集合要遠比單一的單體更加複雜。在一個單體中，一個函數可以調用任何其他公共函數。但是，微服務中的函數僅限于調用同一個微服務中的函數。這就需要服務之間的通信。建構 API 或者消息傳遞來促進這一點并不容易。而且，跨微服務的代碼重複也是不可避免的。當一個單體應用可以一次定義一個子產品并多次導入，而微服務是它自己的應用：在每一個子產品都必須定義子產品和庫。

微服務最适合大型團隊

将微服務分派到各個團隊的奢侈做法是留給大型工程部門。盡管這對這個架構來說是一個很大的優勢，但是如果你擁有足夠的工程師來為每一項服務指定一些工程師，那麼這才是可行的。減少代碼範圍，可以讓開發人員對代碼有更好的了解，加快開發的速度。但是，大部分的初創公司都沒有這樣的奢侈。在一個創業早期的公司，由于缺乏足夠的資源，有些工程師必須在所有的服務之間工作。遺憾的是，這樣做會降低工作效率，因為在不同的應用中跳躍，可能會導緻環境的變化。我發現，在我已經很久沒有關注的微服務中調查 Bug，是一件非常令人筋疲力盡的事情。

DevOps 更複雜

選擇微服務最有說服力的一個原因就是可以在不同類型的伺服器上運作不同的服務。這是為什麼呢？React 前端的記憶體、CPU 和啟動時間的需求與訓練機器學習模型的服務大相徑庭。為每一項服務選擇适當的基礎架構類型，可以極大地減少費用。但是，這也給自己帶來了一個挑戰。

舉個例子，在我的職業生涯初期，由于忘記重新開機一個更新過代碼的服務，導緻我丢失了大量的生産資料。過期的代碼會通過 API 來接收資料，卻沒有把資料存入資料庫，反而消無聲息地失敗。這樣的資料就會永遠丢失了。

我之是以提出這一點，是想要表明，配置、維護和監控多個微服務，要比單一的單體應用要複雜得多。擁有多個應用程式，還為駭客增加了多個攻擊面。

從理論上講，“松散耦合”的服務允許每個服務在其他服務失敗時繼續工作。但這隻是一廂情願的想法：對于有客戶的複雜業務來說，很難實作真正的松散耦合。

最終，你的應用程式架構的可靠程度取決于最薄弱的部分。移動的碎片越多，出錯的可能性就越大。

總 結

許多公司使用微服務并不是真正需要它們，而且盡管微服務現在很流行，但它們并不适合初學者。大多數公司最好的做法是建構一個單體，然後在絕對必要的時候将單體的部分拆分到微服務中。

把從頭開始的微服務架構的機會留給那些财力雄厚的大型科技公司。

你的早期階段的創業公司也許還沒有準備好。我的公司就沒有準備好，結果，讓我們付出了大量的時間和精力。

作者介紹：

GreekDataGuy，開發者。

https://betterprogramming.pub/stop-using-microservices-build-monoliths-instead-9eac180ac908