系統軟體架構中，現在很流行微服務，那麼使用微服務就一定好么？微服務有哪些缺點呢？(伺服系統軟體架構)

下面簡單回答下這個問題。在回答這個問題前還是先回顧下微服務架構。

微服務架構概述

微服務架構本質是單個業務系統徹底的組件化（前端，邏輯層，資料庫）解耦，同時相互之間通過輕量的服務介面和協議進行協同。這和很早就談到的組件化架構思想是一致的，實現微服務架構後，你會看到沒有傳統業務系統的概念了，有的只是微服務模塊或小應用。
微服務架構最近又炒的相當活，很多人會說SOA過時了，ESB過時了，甚至還有人用微服務架構去徹底的否定SOA和ESB，這些都是相當危險的信號。在我12，13年寫企業私有雲PaaS平台的一系列文章的時候，已經提出了業務能力組件化，組件服務化的微服務架構思想，但是實際應用實施效果並不太理想。

我們可以先看下從單體應用到微服務架構的變化圖。

把這個核心搞清楚後，再來看下網上找到的對微服務架構的一些定義和闡述：

微服務可以在「自己的程序」中運行，並通過「輕量級設備與HTTP型API進行溝通」。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程。

微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常複雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。

在了解了微服務架構後，我們來分析下微服務架構又哪些缺點和難點。

微服務模塊拆分後，各微服務間集成複雜度指數級增加

簡單舉例來說，一個企業已經實施了5個業務系統，業務系統之間有10個介面。如果全部微服務化則可能設計到50個微服務模塊，上100個介面和集成點。可想而知，在徹底實施微服務後，我們前期架構設計，後期集成和管控的複雜度增加10倍以上。

這種集成難度會遠超大多數人想像，如果拿真實做的項目來說，如果談業務系統只有3個，而到微服務模塊級別則有接近60個，而實際涉及到的集成介面上1000個。我們做任何一個複雜端到端業務的聯調基本就需要花2，3周甚至更長的時間。

互聯網企業為何適合做微服務架構，其重要的一個原因就是互聯網企業如電商平台，在進行了微服務化後各個模塊之間耦合性很低，並不會有太多的集成和協同點。或者簡單來說，各個微服務模塊更多的是向上面的PC端或APP端提供服務能力，而模塊橫向間介面協同很少。

正是在這種低耦合情況下，協同和集成相對來說容易。而轉回到企業內部你會發現，在微服務模塊化後，各個模塊之間的集成點相當多，特別是業務系統拆分到模塊或組件這一個級別後，很多原有內部的集成和依賴點全部暴露出來了，你都需要去很好的管理。由於這裡面有大量的橫向集成和協同點，因此導致的就是微服務模塊間的橫向集成異常複雜，遠超很多互聯網應用，這是實際你會面臨的問題。

微服務模塊拆分後，各微服務間集成複雜度指數級增加

只談微服務架構的松耦合和高擴展性，而不談開發和集成複雜度的都是耍流氓。

實際上當前很多企業對微服務架構並沒有如此迫切，互聯網很多企業推行微服務架構更多的還是考慮到巨大的業務並發量下的系統彈性擴展能力，而實際大多數企業內應用往往並沒有如此海量並發。其次，即使在並發量增加的情況下通過進行代碼本身的優化，資料庫調優或者升級硬體伺服器資源都可以較好的解決性能問題。而做這些事情投入的成本遠遠小於微服務架構帶來的開發複雜度增加成本，後期的運維管控成本。

要做到完全微服務模塊獨立，微服務架構下最大的一個變化就是資料庫也拆分開了，原來的一個業務系統如果分為5個微服務模塊，那理論上就是5個獨立的後台資料庫，而且資料庫間還不能隨便相互連接和訪問。只有這樣微服務模塊才能做到獨立部署和管理。

由於資料庫拆分帶來兩個問題，其一是我們原來很簡單的一個跨表查詢操作現在無法做了，我們必須調用兩個微服務模塊提供的服務，查詢到數據後再到邏輯層進行組合。其次最大的問題就是如果一個業務操作需要同時更新兩個微服務模塊的數據，由於服務本身無狀態，導致了這種分散式事務問題很難解決。

企業內業務系統很大一個特點就是業務邏輯和規則相對互聯網更加複雜，而且有更高的事務一致性要求。正是由於這個原因，無法解決好分散式事務的問題都將直接導致後續數據不一致和業務錯誤。

原來通過調用項目內一個API方法就能解決的問題，現在要調用遠程WS介面才能解決，這本身就增加了開發和調試的複雜度。一個微服務模塊與外部其它模塊的集成和協同越少，你會發現該微服務模塊和傳統業務系統開發沒太大區別，但是當其涉及到完成任何一個功能都需要調用外部微服務模塊的服務介面時候，其開發模式和效率上就會帶來巨大的變化。

微服務架構下運維難度增加

在實施了微服務架構後，運維的複雜度也是成倍增加，任何一個微服務模塊出問題都可能影響到整個業務應用的功能使用。我們在運維時候不僅僅要健康單個微服務模塊，還需要健康所有的介面服務監控狀態。

如果跟Docker集成了，我們看到整個性能監控和問題分析都會變麻煩了，沒有實施微服務架構前發現問題，我們直接可以看應用伺服器上類似tomcat或jboss日誌，而實施了微服務架構後，應用容器已經是自動部署和動態分配的，原有的故障診斷模式行不通，而需要PaaS平台本身提供完整的預警和日誌分析能力。

再次，如果發現了性能問題或故障，我們的解決方案是如何的？我們如何保證不影響到業務運行，不出現數據的丟失，或者在微服務模塊擴展的時候不出現業務中斷等。這些已經不是簡單的部署架構層面的冗餘能解決的問題，而涉及到我們在整個微服務架構中的消息策略，事務管理機制，持久化機制等問題。

引入微服務後的實施難度增加

一個企業所涉及到的IT開發和架構能力以及企業本身的IT治理管控成熟度都將直接影響到微服務架構能否實施成功，要知道引入微服務架構後集成和後續運維等的複雜度都會成指數級增長。

方式1：引入的外部開發商進行微服務架構化

如果一個企業本身IT部門規模小，軟體以外購為主，那麼勢必在對ERP等各類軟體的選型評估後引入不同的軟體產品提供商或軟體開發商。那麼軟體商本身都有了成熟的產品或架構，其產品內部的模塊是否符合組件化和微服務架構的要求，我們不得而知。

即使招標要求寫明軟體提供商提供產品需要基於SOA或微服務參考架構，但是實際上由於企業本身的IT能力和水平往往也無法驗證，而對於軟體廠商來說一定希望是賣現有產品，減少改造和定製實現利潤的最大化。

對於軟體開發廠商來說對已有的軟體產品是沒有微服務架構改造的動力的。那在這種情況下要推動微服務架構實施落地必須的就是企業本身有很強的架構管控能力和甲方話語權。

在曾經實施的案例裡面可以看到，甲方在有較強的IT規劃和架構設計能力情況下，才可能一開始就劃分好微服務模塊並且設計好微服務模塊間的介面，在進行招標和選型。同時甲方話語權強的情況下，可以完全要求軟體供應商按照自己定義好的標準，規範，架構進行微服務模塊的開發。

簡單點來說頂層架構分解和介面設計能力不在單個微服務模塊開發商手裡面，而是在甲方手裡，或者在甲方請的專門負責規劃架構設計的技術諮詢團隊手裡。

在這種模式下，技術諮詢團隊應該對整體模塊劃分和後續集成負責，技術諮詢團隊就需要有業務和技術兩方面的能力，同時有類似領域的規劃設計經驗，系統開發建設經驗等。這些本身就對技術諮詢團隊提出了相當高的要求，可以來講很少有技術諮詢團隊達到這個水平，包括埃森哲或德勤等也難。

在微服務架構下，我們希望的是一個業務系統如果由三個微服務模塊組成，在我們進行了前期的架構和介面設計後，我們完全可以將三個模塊發標給不同的軟體開發商建設和實施，然後在根據預先定義的服務介面進行集成。這個從理論上是行得通的，但是實際上出現兩個問題。

其一是剛開始的模塊劃分或介面設計不合理，在後面開發過程中才發現又很難再大變更。
其二是微服務模塊間的介面服務太多，導致了模塊間的集成和聯調異常複雜。

從上面也看到引入微服務架構後，企業本身可以削弱單個軟體供應商對企業本身的約束，防止被單一廠商綁定。因此企業沒有特色要求，從軟體廠商來說沒有任何動力和意願推微服務架構。

方式2：企業自由開發團隊實踐微服務架構

如果企業本身的IT成熟度沒有達到一定階段，顯然是不可能推行實施微服務架構的。這個道理前面已經談到過，在企業IT建設中，如果連粗粒度的業務系統以及它們之間的集成都管理不好，那麼更沒有能力管理細粒度的微服務模塊。那麼如果企業IT成熟度達到一定水平，在推廣微服務架構還存在的難點如下：

首先是架構設計能力的顯性化，即架構設計這個工作的輸入，輸出和過程需要更加的顯性化出來形成團隊都認同的標準工件。一個業務系統沒有拆分開時候，雖然有架構設計和組件劃分，但是這個工作是屬於團隊內部的事情，即使架構設計不合理，在後期集成也可以通過諸多變通方式解決掉。而現在是不同的微服務模塊可能分派到兩個獨立的團隊開發，原來屬於自己內部黑盒的問題變為團隊間問題。

簡單來說你原來藏著或沒做規範的東西太多，而現在這些不能再藏著掖著了，當真要把這些東西拿出來的時候，你才會發現你原來架構能力是有欠缺的。正如我們理解了一個東西，那麼要讓我們清楚的講出來困難，那麼我們的理解有欠缺。對於我們能講清楚的東西，要系統的寫下來有困難，那麼說明我們講的結構和條理有欠缺。

其次管控要求和規範體系的建立，對於管控要求可以看到如果兩個微服務模塊分給同一個團隊開發，如何才能保證開發的團隊保持兩個模塊的完全獨立和解耦，兩個模塊間不會出現相互交叉的資料庫直接調用，也不會存在直接繞開Service介面的其它耦合調用？這些如果沒有完整的管控和檢查體系我們很難約束。以上即是引入微服務架構後帶來的難點或缺點，供參考。自己也長期專註於SOA，微服務，DevOps支撐平台建設實施，歡迎交流。

#####

1. 問題描述

系統軟體架構中，現在很流行微服務，那麼使用微服務就一定好么？微服務有哪些缺點呢？

問題結論

架構都是為業務而服務的，我們在選擇具體哪個架構的時候肯定是基於業務進行選型。微服務適用於大型互聯網公司，需求迭代比較快。如果業務相對而言比較簡單，單體應用不失為一個很好的選擇。

2. 微服務簡述

2.1 微服務的理解

• 微服務就是按照業務劃分，將一組特定的業務劃分成一個服務（比如：支付系統，只是服務庫存做操作，不涉及到其他任何業務），每個服務都有自己獨立的資料庫，獨立部署，服務直接通過rest api（或rpc api）進行通訊。每一個獨立運行的服務組成整個系統。

• 微服務的架構風格就是一個大型軟體系統由一個或多個微服務組成。每個微服務僅負責一件業務任務，系統中各個微服務可被獨立部署，更快地交付並推出市場，各個微服務之間是松耦合的。

比如我們所看到的各種電商App，其對接的服務端很可能是成百上千個微服務，即使團隊內部，也很難說清楚到底有多少個服務，也許一個頁面就涉及到4~5個微服務，其各自均有獨立的資料庫與之對應。

2.2 微服務的優點

相比起集成式大型應用。微服務主要優點在於：

• 每個服務足夠內聚，足夠小，代碼容易理解、開發效率提高。
• 服務之間可以獨立部署，微服務架構讓持續部署成為可能。
• 每個服務可以各自進行負載均衡擴展和資料庫擴展，而且，每個服務可以根據自己的需要部署到合適的硬體伺服器上。
• 容易擴大開發團隊，可以針對每個服務（service）組建開發團隊。
• 提高容錯性（fault isolation），一個服務的內存泄露並不會讓整個系統癱瘓。
• 統不會被長期限制在某個技術棧上，在合理的通信機制下，每個微服務可以獨立使用自己的技術棧。

2.3 微服務的缺點

• 運維要求比較高：之前就一個war包，現在一個系統中會有很多的服務，每個服務都對應一個war包，維護起來就會變得很麻煩。
• 技術複雜性提高：微服務就會帶來一系列的問題，事務問題，Session一致性問題，鎖問題，服務治理問題、多環境實例管理問題、微服務架構拆分粒度和時機的把我問題等。

3. 小結

不必強求微服務「全家桶」套餐，理解微服務的優勢，也要警惕微服務造成的問題。一般來講，能單應用就用單應用，業務量大可以考慮做分散式集群。更大規模的場景，單應用已經無法支撐業務，考慮微服務化。為了微服務而微服務完全沒有必要，在提出微服務概念以前，一個大系統本身分成很多小系統，這和現在的微服務並沒有本質的區別。而微服務本質是應對複雜的系統架構，n個小團隊維護大的系統規模，在遺留系統中做架構演進，各個微服務獨立部署又緊密集成，共同支撐業務系統提供服務。

作者：夕陽雨晴，歡迎關注我的頭條號：偶爾美文，主流Java，為你講述不一樣的碼農生活。

#####

還是以公司的實際情況來選擇技術架構吧，不要為了微服務而微服務。

微服務的特徵

微服務是一種軟體架構設計思想，它以【單一責任】的功能模塊為基礎，再利用模組化的方式組合出複雜的大型應用程序；微服務的主要特徵有這些：

• 每個微服務的業務功能會儘可能的單一（只關注負責的業務）；

• 可以獨立部署；

• 輕量級的通信協議；

• 每個微服務擁有單獨的數據持久化（有些項目的微服務改造，資料庫依然是一個資料庫）；

• 不僅服務微，團隊也要「微」；

微服務帶來的好處

• 每個微服務可以獨立擴展，因為服務微，所以單個服務可以快速擴展；

• 因為彼此沒有依賴關係，所以可以獨立升級（需要使用到灰度發布）；

• 故障和資源隔離，出現事故只會影響單個或幾個微服務（當然如果是關鍵服務發生問題，影響面也會比較大）；

• 只要約定好通信協議，每個微服務可以採用不同的技術棧；

• 如果採用微服務的架構來管理團隊，團隊將不再以職責劃分（開發團隊、需求團隊、測試團隊、運維團隊），每個微服務團隊都包含各個方面的人員，合作起來會更加「敏捷」。

微服務的缺點和它的優點一樣明顯

說是缺點，也可以說是挑戰：

• 極大地增加了運維的複雜程度，包括上線發布、BUG排查、故障解決等；如果沒有良好的自動化運維平台和工具，上微服務要謹慎（人肉運維會死人的）；

• 數據一致性不好控制；如果是單體服務，幾張表的讀寫通過事務很容易控制，但是在微服務的架構中，數據一致性是一個很大的難題；

• 增加了集成測試的難度；

• 需要一個統籌全局的角色，否則很容易做很多重複性的開發；

• 微服務間的調用會有延遲（通信成本），網路延遲可能帶來整體系統的響應緩慢問題；

總之，微服務不僅僅是技術方面的問題，它涉及的方方面面還有很多，還是要選擇適合公司的架構。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

#####

題主做軟體的應該聽說過「沒有銀彈」這句話吧？如果真有一個能解決所有問題的軟體，還要這麼多軟體開發人員幹嘛？如果有人說有，不是沒幹過軟體，就是在打廣告。

「微服務」不是銀彈，解決不了所有問題，有其自己的適應場景。我大致總結了如下場景：

• 業務發展較快，希望能在後期快速的支撐爆發增長的訪問量（首先確認是不是真的業務發展很快）
• 業務非常複雜，且有很多不確定性，可以考慮領域驅動設計+微服務實現
• 項目很大，人員很多，考慮切分為多個小組進行微服務開發
• 需要整合很多的老系統，可以考慮微服務的sidecar模式或者SOA
• 希望在公司層面構建一套統一的業務技術平台。登陸，文件服務，日終服務等，由業務平台提供，開發人員只需要關注業務服務

相對的，需要快速落地的簡單業務就不適合微服務，後期維護成本遠超成本。

就像，大型超市有多個收銀台，小超市也搞多個收銀台，營業額還不夠發人員工資的。

最後，技術是為業務服務的，一個技術在某個場景的優勢，在另一個場景下可能就變成了劣勢，拋開業務討論哪個技術好不好，都是耍流氓～

#####

微服務主要是經過組件分離各自擁有獨立的生命周期，並且按需進行擴展，這種方式打破了組件之間的技術依賴，這就允許每個服務各自選擇最合適的技術進行實現，即不同的服務甚至可以採用不同的編程語言來實現，一定程度上微服務使技術方案變得更加靈活。

微服務在使用過程中開發、測試、部署等環節十分便捷，整體是以松耦合高內聚的形式存在，符合IT技術思想。但是在實際使用過程中，還是存在一些不足，比如在開發微服務時，對於服務粒度的設計需要對業務理解比較深刻；客戶端調用微服務耗時比較嚴重，隨著需求的迭代，管理難度越來越大，服務間耦合度開始增強，代碼難以復用和修改等等。

綜上所述，對於複雜的大型的項目來說，採用微服務實現就會變得十分複雜且周期也會很長。在這種情況下，通常建議採用SOA架構幫助企業制定正確的IT架構戰略（具體包括應用架構、數據架構、技術架構），通過微服務輔助實現應用架構，是一個不錯的選擇。

#####

從個人從業角度來看的話，我覺得微服務跟人工智慧、區塊鏈等一樣被很多公司吹的過頭了，軟體系統架構沒有說哪一個是一定好的，不是什麼流行就必須要上的，軟體架構的核心應該是要結合業務應用場景來設計，這樣的架構才是合適和合理的。

現在對於很多政府單位、企事業單位來說，像前幾年炒的很火的大數據、人工智慧，到現在實際應用到哪個程度了呢？我相信只要是行業內的人都知道，目前別說是大數據了，連基本的一些業務應用系統都沒有上全，更別說做數據採集、清洗、整合和挖掘了，傳統政府行業目前還沒有到達這樣的數據體量，這不像互聯網公司，電商數據、搜索數據、交易數據等那麼多。

那是否不用使用微服務架構呢？這個真的要結合實際情況來看，如一些政府便民服務類的應用，這些是非常適合做成微服務架構的，這類應用因為牽涉到所有居民，用戶的使用量和使用頻率會比較多，把它做成微服務架構能很好的提升系統的穩定性和訪問效率，提升整體的政府服務形象，而其他的一些應用，建議只有牽涉到跨部門數據交換頻繁和訪問並發要求高的可以考慮採用微服務架構。

希望我的回答，對你有幫助。

#####

我認為沒有最好的服務架構，只有最適合的服務架構。微服務好不好要根據公司的業務來判斷。很多互聯網大公司在做中台化改造是因為業務發展的需要，當業務體量上來之後倒逼公司服務架構和組織架構調整。

微服務的優勢顯而易見，主要有幾個特點：無中心化，松耦合，服務自治，組件化。這樣的結構便於將複雜的系統結構拆分，各個服務團隊更加靈活，能夠提高交付速度，快速響應市場變化。

然而不能為了微服務而微服務，公司在架構選型的時候首先要評估業務體量與複雜度是否有微服務化的必要，如果業務本身不複雜，那麼完全沒必要去微服務化。否則不僅不能提高業務運行效率，反而為增加開發運維的負擔。

微服務的缺點如下：

首先服務的切分需要慎重考慮，微服務化是手段不是目的，最終目的是通過有效的拆分應用，實現敏捷開發和部署，提高交付速度，擁抱變化。

其次微服務應用是典型的分散式系統，需要更加關注服務的可用性和一致性問題。服務註冊與發現，容錯，降級，熔斷，限流等服務治理問題在微服務場景下可能要複雜的多。

第三微服務帶來了運維的複雜性。一次完整的業務調用可能需要多個服務協同完成，服務的調用關係更加複雜，可能是串列/並行，可能同步/非同步。如果沒有強大的工具鏈的支撐，運維會是一場噩夢。

最後微服務不僅是技術架構的調整也是組織架構的調整。伴隨著業務系統微服務化的同時，組織架構也應該打破傳統的筒倉效應，更加扁平和靈活。

#####

簡介

系統架構中，微服務是很流行的，尤其是現在我們的系統的數據越來越大，越來越複雜，為了設計更合理，支持高可用、高性能，最好的實踐方式就是進行微服務化。其中的優點就不多說了。單就從缺點層面來分析。

缺點

技術要求變高

對於開發人員的技術要求越來越高，隨著服務的微服務化。一個系統的微服務應該怎麼拆，拆的維度是什麼？這個是沒有一定的標準可言，而是要根據項目本身的業務而定，這就需要一個有經驗的架構師進行微服務化。而是簡單的進行垂直拆分即可。

除此之外你還需要考慮如何避免多個微服務之間開發人員的重複開發工作，做到公共資源的合理分配。微服務中的監控指標數據等。

這樣的拆分對於之後的系統升級、擴展是不是合理，會不會導致系統架構重組等問題，都是其中的一個弊端。

運維成本

隨著你的微服務化，會導致服務數量的激增，你需要去維護更多的服務，以及服務之間的性能監控，數據調用鏈等數據指標。而傳統的單體方式，本身的調用都是內部的，你只需要維護單個應用即可。

注意，這個也並非是指分散式，而是你的系統微服務化，所以傳統單體應用也可以做到高可用。

複雜度高

微服務之間的調用方式是通過RPC方式來進行數據交互，相比傳統模式，你需要考慮過載、消息丟失、重試、負載等場景，需要處理的邏輯也很多。

首先你需要有一個註冊中心，來幫助微服務之間的調用，這是一個需要額外實現的點。

另外在服務調用（服務發現）的時候，會存在負載均衡、容錯、代理透明、RPC協議中的序列化、協議編解碼等比較複雜的詳細邏輯，都是需要微服務化需要去考慮的。

分散式鎖、分散式事務層面的問題，你都需要再進行設計，在傳統的模式下，這些都是在同一個應用裡面進行，不存在問題。但是微服務化後，你為了保證數據一致性，這些相關的點，都是你需要進行額外的開發。難度成本也會成倍加高。

性能層面

隨著你需要為了微服務化，而加入更多的解決方案的時候，你的系統會變得更加的複雜，雖然架構清晰，設計合理。但是其中的性能問題，也是你不得不考慮的問題，越多的中間件組合在一起，只要其中一個環節出現問題。你整體的性能就會大打折扣，比如你微服務RPC環節、通信延遲、微服務宕機等情況。不像傳統模式，環節少。

總結

微服務化的優點很多，但是同時帶來的問題也是客觀存在的開發要求高、複雜性、性能等。

針對以上的一些拙見，個人的建議是對於你是否引入微服務化，應當考慮維度在於業務邏輯和系統邊界是否清晰。可以先從最簡單的傳統單機模式開發，漸漸穩定系統後可以再慢慢的微服務化的拆分工作。

#####

非常有興趣來回答題主的問題。

首先，軟體架構只有合適不合適，並沒有絕對的好壞之分。隨著系統、業務的發展，架構也是需要不斷進行調整的。架構的選型和行業、企業、團隊以及系統、業務等多個方面都有關聯，因此我們在進行架構選型時需要從多個維度來分析和論證。回到正題，微服務的優劣勢有哪些呢？

一、微服務架構的優勢

1、高內聚、低耦合實踐者

微服務架構是「模塊化」的延伸，是SOA架構的一種思想。微服務體現的並不是服務有多「小」，而是「高內聚、低耦合」的具體實現。在微服務架構中，每個服務都足夠內聚，易於迭代和發布。整個系統由多個微服務構成，微服務之間的調用有標準的規範，從而儘可能降低微服務之間的耦合程度。而且，容器時代的到來，使得服務的部署和運維成本進一步的得到的控制。因此，微服務+容器成了很多企業追捧的方案。

2、服務的專註程度高

每個微服務都只專註與其自身，有助於降低開發難度以及提升開發效率，同時也可以讓整個系統的層級和組成變更清晰和調理，降低系統整體的維護難度。

3、語言、技術棧不受限

在微服務架構中，服務之間調用都滿足公共的標準，不再關注具體的技術實現。因此，在開發語言和技術棧的選擇上會更加靈活。

二、微服務架構的劣勢

1、微服務架構是天然的分散式架構，因此其繼承了分散式架構的所有劣勢

分散式和單體應用在設計、開發、維護層面的差異是巨大的，最經典的問題就是數據一致性問題（分散式事務），此外還有維護成本高（相對）、定位問題困難（相對）、等等問題。雖然Docker出現大大降低了自動化的成本，部署服務的成本得到了控制，但是相對單體應用來說，成本還是不容忽略的。

2、對人的要求更高

微服務並不是單純的進行服務拆分，而是要從相對更高的層面進行設計，而任何業務系統都必然會存在業務的依賴，因此對設計人員的要求人員也會更高。

總之，在架構選擇上需要結合實際情況具體進行分析，接下來我舉兩個例子來說明吧。

1、城市商業銀行的系統建設。銀行本身是一個對數據一致性有很高要求的行業，大多城市商業銀行自身的技術儲備有限，系統建設需要依賴第三方（各種外包服務商），而且城商行的規模和交易量相對於互聯網企業也有一定的差距。因此，大多城商行在架構選型上更加喜歡具備一定伸縮能力的單體架構，不但可以通過增加軟硬體的方式來提升系統的能力，同時也相對易於維護。

2、我們最近在考慮開發一個系統，用於日常辦公。用戶群穩定且單一，可投入的開發測試人員又非常少，經費也少的可憐，那還搞什麼微服務，直接單體干就完了。

以上就是我的一些觀點，希望可以幫助到您。

#####

微服務一般用於大型嗯架構 比較重量級 更多的可以隔離 解藕 適合數據中台 雲平台 大數據平台等 缺點就是不太靈活 小型的系統平台沒有使用的必要 不如使用ssm