什麼時候不應該使用微服務（譯）

在過去的幾年中，很多廠商的系統在從單體往微服務轉。大家被微服務所承諾的優點給吸引，比如高可用、低耦合、敏捷開發等。正是由於這些優點，很從團隊就更傾向於使用微服務，而不是建一個單體應用。

但是當人們引入微服務後，卻發現現實並沒且它承諾的美好。它就像一座圍城，城外的人想衝進去，城裏的人想逃出來。

本文將會討論微服務的一些缺點，以及什麼情況下你才應該選擇微服務。

什麼是微服務

微服務就是把一個大系統按照業務領域拆分成多個子服務，這些子服務不共享數據庫，服務與服務之間通過 RPC 接口調用進行交互。這些子服務可以獨立演進、發佈、部署。

微服務的挑戰

微服務很難被正確的設計出來

你很難一開始就把微服務的領域邊界定義清楚。服務之間的數據是否要共享，如何共享。共享數據就帶來一定的耦合，耦合到什麼程度是合適的。是通過同步接口還是異步消息來交換數據；UI 組件是否要放到服務包裏，還是拆分。

微服務帶來技術複雜性

這些複雜性和困難並不是沒有解決方案，比如現在流行的 skywalking 、 seata 等就是爲了解決其中的一些困難，但是引入這些方案又會帶來額外的學習成本和技術複雜性。

康威定律的魔力

康威定律是馬爾文康威 1967 提出的：“設計系統的架構受制於產生這些設計的組織的溝通結構。” 。舉個例子，假設你有 10 個服務，

如果你的微服務劃分與組織架構不匹配，你會發現這些服務會逐步朝你的組織架構的劃分進行演變。

另一種情況是棒打鴛鴦，強行把關聯度很高的服務拆散放到不同的團隊，你會發現研發效率指數級下降，最後忍爲可忍，就把這些服務合併到一個團隊來維護，然後這些服務可能會最終合成一個服務，於是服務劃分又朝着組織架構進行演進。

什麼情況下需慎重選擇微服務

應用體量太小

如果應用體量很小，就沒必要拆分成多個服務，就算需要拆分成多個服務，也需要慎重考慮服務的拆分粒度。服務的拆分要考慮投入產出比，當應用體量較小時，我們只需要在模塊間做好包的拆分和業務內聚，如果一個模塊不斷變大，這時候我們就可以考慮拆分成單獨服務。

業務域不清晰

我們常犯的一個錯誤是在業務域不清晰的時候，會把業務域無限放大，以應對後面可能出現的情況，但是在考慮可能的情況也需要考慮其可能性。當提供決策支撐的信息量不夠多時，推遲決策通常是更好的決策。

當業務域不清晰時，業務之間的邊界可能會調整，接口會變化，業務域本身可能也會拆分、合併。

組織架構不能相應調整

一個好的微服務團隊應該是內聚的，自組織的。當 Dev(前端、後端) 以及 Test(測試) 包括 Ops(部署、運維) 都在一個團隊時，其效率是最高的。否則你會發現各個崗位之間經常是在扯皮、指責，前端說後端接口定義不好，運維說服務服務複雜，研發說運維缺乏腳本能力，當系統出現性能問題或者宕機時，大家都說是對方的責任，找到問題了發現需要協調三四個部門共同解決，最後就不了了之了。

團隊欠缺微服務技術棧能力

以 java 技術棧來說，使用微服務通常涉及到 Spring Cloud 、RocketMQ 、elk 、k8s 、redis 等，這些技術棧上手簡單，但是在實際使用中就會遇到各種各樣的問題。

除了技術能力之外，我認爲使用微服務的團隊更重要的是要有工匠精神。單體應用再怎麼爛，他也是爛在鍋裏，出了問題這個團隊得兜底，問題在團隊內能解決。

使用微服務，這個服務是要對外提供能力的，他是否認識到他有義務 “服務好” 場景層，這個服務好包括穩定健壯的運行、清晰的文檔和日誌信息、部署簡單、接口定義清晰完備。。

場景層遇到問題能否先自己看看，不要一股腦往外拋。譯者團隊做了一個存儲服務，業務團隊丟了文件說是存儲服務給弄丟的。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/1sGjHRVRyGooFuNZjLcypA

猜你喜歡