你真的需要微服務嗎？

雖然微服務概念流行已有一段時日，但任何技術都有其優缺點。看到微服務同時扮演正派和反派角色之後，thoughtfocus 的技術架構師埃賓·約翰（ebin john）發文建議開發者，如果你是傾向於將微服務作為預設架構的架構師或設計師，最好問自己以下幾個問題。

1. 你的應用程式龐大得足以細分成微服務嗎？

微服務是一大堆各司其職的小服務，在理想情況下，每個服務本身就是乙個完整的應用程式。

由於微服務在人力和計算成本方面需要最少資源，所以它需要的成本較高，哪怕是輕量級微服務。而且，你的**庫在將來會越來越大，**庫本身可能會新增乙個新的領域。但你應該永遠記住：當你接近閾值時，設計良好的**庫始終可以切換到微服務。

2. 你是否果真需要擴充套件應用程式的各個元件？

假設一下。產品負責人向你提出了使用人力資源管理系統（hrms）應用程式的想法，以滿足上萬人組織的需求。作為技術愛好者的你立馬有乙個解決方案：微服務架構。

使用微服務架構的主要優點之一是易於擴充套件單個元件。你可能會找到元件需要單獨擴充套件的大量應用程式，但你的應用程式果真需要這麼做嗎？

3. 你的事務跨諸多服務嗎？

現在，這可能是最難做出的戰略性選擇之一。跨多個服務的事務是整個架構的負擔。解決跨服務的事務意味著：服務之間的互鎖會導致一系列難以追蹤的僵局，以及會危及服務健康狀況、有時甚至是工程師健康狀況的競態條件。

按照定義，rest 服務是無狀態的。它們不應該參與邊界不僅限於一項服務的事務。在高效能環境下，兩階段提交 2pc 是不必要的麻煩。而 saga 模式只會增加你沒有準備好的另一層複雜性。

由於微服務堅持採用分布式資料管理，它帶來了最終一致性問題。如果是整體式應用程式，你可以在單個事務中一起更新一堆東西。而微服務需要多個資源才能更新，且分布式事務不受歡迎（這有充分的理由）。因此，開發人員需要意識到一致性問題。

4. 服務之間是否需要經常聯絡？

在傳統的整體式服務上，每個微服務例項由系統內的模組加以表示。模組之間的聯絡在記憶體中進行，延遲接近零。微服務的引入意味著，聯絡由記憶體中事務完全變成了通過網路傳達指令。

有眾多久經實踐考驗的解決方案，但是它們都有代價：延遲。從記憶體中事務改為基於網路的聯絡會將延遲從納秒變為微秒。想象一下，三個不同的服務通過網路彼此聯絡。假設每個服務呼叫要花費 100 微秒（這在負載情況下並不少見），那麼到頭來單單在網路上就要花掉 300 微秒。

而一些應用程式本質上與元件和服務緊密整合。新增的通訊層可能會給處理實時資料的應用程式造成災難性的後果。

除了上述四個問題，在使用微服務之前還需要考慮它的另一些缺點，比如：

1. 複雜性

雖然微服務原本旨在通過將應用程式分解成小組件來降低複雜性，但架構本身的部署和維護卻很複雜。

2. 分布成本

微服務是具有模組性的分布式系統，但是同樣的分布確實要付出代價。你的整體式服務會部署在大型虛擬機器或首選容器上。但如果是微服務，除了多個虛擬機器或容器外，服務需要獨立部署在理想的環境上。當然服務可能很小，但你可以計算一下總成本。

3. 改編 devops

這可能有益也可能有害，如果你是小型企業的成員，成立一支 devops 團隊會弊大於利。不過有一點倒可以肯定，要是沒有專門的 devops 團隊，你就無法維護和監控微服務。

4. 整合緊密

一些應用程式天生就緊密耦合。將它們分開來以「適應」架構將會帶來災難。

5. 缺乏經驗

這對任何新技術的採用來說都是重要的考慮因素。但是說到微服務，由於擁有抽象定義，造成的危害尤其大。

6. 混亂的資料合約

在團隊內部設定資料合約與團隊之間共享資料合約大不相同。你在接觸微服務時，你的團隊可能不在同乙個地區，更不要說團隊成員都採用同一種程式語言了。為特定要求制定資料合約會耗費你的時間和空間。

7. 除錯

每個服務都會有自己的一組日誌檔案要審查，更多服務意味著更多的日誌檔案。

住手！！你不需要微服務！