雖然微服務概念流行已有一段時日，但任何技術都有其優缺點。看到微服務同時扮演正派和反派角色之後，ThoughtFocus 的技術架構師埃賓·約翰（Ebin John）發文建議開發者，如果你是傾向於將微服務作爲默認架構的架構師或設計師，最好問自己以下幾個問題。
1. 你的應用程序龐大得足以細分成微服務嗎？
微服務是一大堆各司其職的小服務，在理想情況下，每個服務本身就是一個完整的應用程序。
由於微服務在人力和計算成本方面需要最少資源，所以它需要的成本較高，哪怕是輕量級微服務。而且，你的代碼庫在將來會越來越大，代碼庫本身可能會添加一個新的領域。但你應該永遠記住：當你接近閾值時，設計良好的代碼庫始終可以切換到微服務。
2. 你是否果真需要擴展應用程序的各個組件？
假設一下。產品負責人向你提出了使用人力資源管理系統（HRMS）應用程序的想法，以滿足上萬人組織的需求。作爲技術愛好者的你立馬有一個解決方案：微服務架構。
使用微服務架構的主要優點之一是易於擴展單個組件。你可能會找到組件需要單獨擴展的大量應用程序，但你的應用程序果真需要這麼做嗎？
3. 你的事務跨諸多服務嗎？
現在，這可能是最難做出的戰略性選擇之一。跨多個服務的事務是整個架構的負擔。解決跨服務的事務意味着：服務之間的互鎖會導致一系列難以追蹤的僵局，以及會危及服務健康狀況、有時甚至是工程師健康狀況的競態條件。
按照定義，REST 服務是無狀態的。它們不應該參與邊界不僅限於一項服務的事務。在高性能環境下，兩階段提交 2PC 是不必要的麻煩。而 SAGA 模式只會增加你沒有準備好的另一層複雜性。
由於微服務堅持採用分散式數據管理，它帶來了最終一致性問題。如果是整體式應用程序，你可以在單個事務中一起更新一堆東西。而微服務需要多個資源才能更新，且分佈式事務不受歡迎（這有充分的理由）。因此，開發人員需要意識到一致性問題。
4. 服務之間是否需要經常聯繫？
在傳統的整體式服務上，每個微服務實例由系統內的模塊加以表示。模塊之間的聯繫在內存中進行，延遲接近零。微服務的引入意味着，聯繫由內存中事務完全變成了通過網絡傳達指令。
有衆多久經實踐考驗的解決方案，但是它們都有代價：延遲。從內存中事務改爲基於網絡的聯繫會將延遲從納秒變爲微秒。想象一下，三個不同的服務通過網絡彼此聯繫。假設每個服務調用要花費 100 微秒（這在負載情況下並不少見），那麼到頭來單單在網絡上就要花掉 300 微秒。
而一些應用程序本質上與組件和服務緊密集成。添加的通信層可能會給處理實時數據的應用程序造成災難性的後果。
除了上述四個問題，在使用微服務之前還需要考慮它的另一些缺點，比如：
1. 複雜性
雖然微服務原本旨在通過將應用程序分解成小組件來降低複雜性，但架構本身的部署和維護卻很複雜。
2. 分佈成本
微服務是具有模塊性的分佈式系統，但是同樣的分佈確實要付出代價。你的整體式服務會部署在大型虛擬機或首選容器上。但如果是微服務，除了多個虛擬機或容器外，服務需要獨立部署在理想的環境上。當然服務可能很小，但你可以計算一下總成本。
3. 改編 DevOps
這可能有益也可能有害，如果你是小型企業的成員，成立一支 DevOps 團隊會弊大於利。不過有一點倒可以肯定，要是沒有專門的 DevOps 團隊，你就無法維護和監控微服務。
4. 集成緊密
一些應用程序天生就緊密耦合。將它們分開來以“適應”架構將會帶來災難。
5. 缺乏經驗
這對任何新技術的採用來說都是重要的考慮因素。但是說到微服務，由於擁有抽象定義，造成的危害尤其大。
6. 混亂的數據合約
在團隊內部設定數據合約與團隊之間共享數據合約大不相同。你在接觸微服務時，你的團隊可能不在同一個地區，更不要說團隊成員都採用同一種編程語言了。爲特定要求制定數據合約會耗費你的時間和空間。
7. 調試
每個服務都會有自己的一組日誌文件要審查，更多服務意味着更多的日誌文件。
以上就是採用微服務前需要思考的一些問題，也歡迎你在評論區留下自己的看法
來源：住手！！你不需要微服務！