微服務並不是銀彈，如果不結合企業現狀盲目地引入微服務架構可能會引起很多不必要的麻煩。微服務的副作用包括運維成本高、問題排查困難、系統複雜度高、引入分散式問題等。

運維成本提高:因為每個服務都要獨立部署，都需要維護單獨的程式碼庫和環境，因此會帶來程式碼分佈散亂，伺服器分散的問題，導致團隊沒有人能完全清楚所有程式碼在哪，或服務部署在哪的問題，造成運維成本直線飆升。如果企業內部有較成熟的CI/CD等自動化運維工具，則會對微服務運維問題起到很大幫助。

問題排查困難:系統微服務化也會帶來問題排查困難的副作用。系統在未微服務化時，遇到報錯，通常通過異常堆疊就能較快的定位問題。但是系統一旦微服務化後，一個服務報錯，往往可能不是該服務本身出現了錯誤，而是其依賴的其他微服務出現了問題。但微服務間依賴關係難以梳理，導致難以迅速找到問題源，造成問題排查效率下降明顯。

系統複雜度提高:在系統複雜度方面，若企業沒沒有較成熟的微服務鏈路跟蹤系統的話，一旦微服務數量達到一定規模。企業內部就很難找到一個人能清楚的知道系統全域性的依賴關係了。也不知道哪些微服務依賴了自己的服務，使得自己的服務不敢輕易的下線或介面改造，反而加大了微服務系統的維護成本。

分散式成本提高:還有一點就是系統微服務化之後，就引入了很多分散式問題，如分散式事務、介面冪等性等問題，都是微服務場景下不得不額外投入研發成本的問題。

在“微服務”這幾個字被明確地提出來之前，其實已經有很多it開發團隊在實施自己的類似概念了。針對客戶不同的業務需要，從設計階段就開始有意地拆分各項業務功能，使它們之間儘可能地降低耦合度，做到最大程度上的獨立；並且在具備足夠條件的情況下，將每一個獨立服務做單獨部署。

這麼做的好處顯而易見，在設計及開發階段，獨立服務模組就可以交給獨立團隊去開發，做到整個系統開發時間能夠大幅縮短；在實施階段，無論哪個服務模組需要升級或調整，只要遵循早期設計的介面規範，都能對其它服務做到最低程度的影響，而不是說因為需要調整某一項小功能而導致整個生產系統全面停止工作。

但微服務帶來的問題也是很顯著的，那就是各項獨立服務之間要怎麼通訊，換言之就是如何做到資料傳遞的有效性和及時性。所以伴隨著“微服務”概念的大規模提出，浮現出了大量的資料通訊和互動、訊息佇列、身份認證同步等等非業務產品和解決方案。並且微服務架構對開發團隊的綜合專案管理能力也會有一定的要求，否則繁雜的介面設計和溝通會拖垮整個開發過程。

所以說，使用微服務到底好不好，到底要不要使用，還是取決於具體的業務需要。切忌盲目跟風，為了微服務而微服務，很多時候反而會得不償失。

——什麼是微服務：微服務(Microservices Architecture)，它是一種架構風格，一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。

優點：每一個服務足夠內聚，足夠的小，所以程式碼容易理解，這樣能夠聚焦一個指定的業務功能或業務需求。它開發簡單，開發效率也提高，一個服務可能就是專一的只幹一件事情。微服務是鬆耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的，微服務能夠被小團隊單獨開發， 也能使用不同的語言開發。

微服務易於第三方整合，微服務允許容易且靈活的方式整合自動部署，通過持續整合工具，如Jenkins、Hudson等。微服務容易被一個開發人員理解、修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值，它允許你利用融合最新技術， 只是業務邏輯的程式碼，不會和HTML/CSS或其他介面元件混合，每個微服務都有自己的儲存能力，可以有自己的資料庫，也可以統一資料庫。

缺點：微服務將原來的函式式呼叫改為服務呼叫，不管是用rpc，還是http、rest方式，都是增大系統整體延遲。這個是再所難免的了，就需要我們將原來的序列程式設計改為併發程式設計甚至非同步程式設計，所以增加了技術門檻。

微服務應用程式是一個分散式系統，這帶來了複雜性，開發人員需要選擇並實現基於訊息傳遞或RPC的程序間通訊機制。此外呢，還必須編寫程式碼來處理部分故障，因為請求的目的地可能很慢或不可用。

總的來說： 單一架構只適用於簡單、輕量級的應用程式。如果將其用於複雜的應用程式，那麼會是很痛苦的。微服務體系結構模式對於複雜的、不斷髮展的應用程式是更好的選擇，儘管它有缺點和實現方面的挑戰。

架構複雜度呈指數上升，運維成本同比上漲，程式碼量倒是沒少，反而更多了，這個東西是在單體應用規模大到沒有辦法快速迭代更新的情況下催生出來的，所以想用微服務架構的，先問問你的應用單體升級一次的成本是不是已經達到無法忍受的程度了，比如一個包幾個g，只為了改一個錯別字

微服務是一個大坑。微服務目的是解決一個專案太複雜，拆成多個小專案，等你拆分之後發現，整體更復雜了。看著就像java程式設計師乾的事情，有困難要上，沒有困難製造困難也要上，出門不頂一個架構師的頭銜，都不好意思和別人說話。

微服務架構主要針對日流量千萬以上，研發團隊規模不少於50人的公司，如果小於這個規模我建議認真評估是否真的需要採用微服務架構。

— 這是我見過的最良心的話，BAT等大廠出來的技術，不斷禍害創業界。很有必要在這裡嚴正指出微服務的使用範圍，也就是規模匹配度，很多技術leader丟掉【規模】這個重要引數搭建不適合業務的架構。

想當年，當年毛澤東品讀《戰爭論》，深思到以少勝多的戰役，只是鳳毛麟角，於是拋棄其他奇技淫巧，集中優勢兵力，殲滅有生力量。

作為創業的你， 日訂單十萬就足夠對嗎？ 那就不要考慮微服務架構了。

太早了，等融資到D輪都不遲！

首先環節多了，系統架構複雜了，管理和維護難度加大了。

其次，微服務之間的呼叫相對於內部方法呼叫更加複雜，需要考慮更多的異常處理機制。

第三，微服務的拆分粒度大小一直都是困擾架構小組的問題，不僅僅是大小問題，還要考慮業務劃分合理性及應用呼叫便捷可靠性的問題。

第四，隨著系統規模的增長，微服務也會不斷增多，系統複雜度增長，故障定位會較為困難。相應的，如果要恢復出錯交易，可能需要涉及多個系統的協同和聯動，處理時間增加。

第五，多小組之間的協同開發也是個難題，溝通成本增加。

2014年用微服務解決了單體應用的問題；2016年用docker解決了微服務的問題；2018年用k8s解決了docker的問題…… 哪有銀彈？只是見招拆招。

我來說個大家都忽視了的缺點，微服務把系統劃得微了，自然就散了，把我們看問題的視角也拆散了，最大的問題就是很難把握全域性，需要整合，而這方面大多數公司都通過資料平臺來整合，因此使用微服務一定要考慮清楚，拆散了之後，你還能不能整合起來

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

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

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

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

微服務架構概述

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

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

微服務可以在“自己的程式”中執行，並通過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立程序所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小程序範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體程序。微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那麼，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有元件組合到一起時，開發人員需要非常確信這些元件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常複雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。

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

微服務模組拆分後，各微服務間整合複雜度指數級增加

簡單舉例來說，一個企業已經實施了5個業務系統，業務系統之間有10個介面。如果全部微服務化則可能設計到50個微服務模組，上100個介面和整合點。可想而知，在徹底實施微服務後，我們前期架構設計，後期整合和管控的複雜度增加10倍以上。這種整合難度會遠超大多數人想象，如果拿真實做的專案來說，如果談業務系統只有3個，而到微服務模組級別則有接近60個，而實際涉及到的整合介面上1000個。我們做任何一個複雜端到端業務的聯調基本就需要花2，3周甚至更長的時間。網際網路企業為何適合做微服務架構，其重要的一個原因就是網際網路企業如電商平臺，在進行了微服務化後各個模組之間耦合性很低，並不會有太多的整合和協同點。或者簡單來說，各個微服務模組更多的是向上面的PC端或APP端提供服務能力，而模組橫向間介面協同很少。正是在這種低耦合情況下，協同和整合相對來說容易。而轉回到企業內部你會發現，在微服務模組化後，各個模組之間的整合點相當多，特別是業務系統拆分到模組或元件這一個級別後，很多原有內部的整合和依賴點全部暴露出來了，你都需要去很好的管理。由於這裡面有大量的橫向整合和協同點，因此導致的就是微服務模組間的橫向整合異常複雜，遠超很多網際網路應用，這是實際你會面臨的問題。

微服務模組拆分後，各微服務間整合複雜度指數級增加微服務架構下運維難度增加

在實施了微服務架構後，運維的複雜度也是成倍增加，任何一個微服務模組出問題都可能影響到整個業務應用的功能使用。我們在運維時候不僅僅要健康單個微服務模組，還需要健康所有的介面服務監控狀態。如果跟Docker集成了，我們看到整個效能監控和問題分析都會變麻煩了，沒有實施微服務架構前發現問題，我們直接可以看應用伺服器上類似tomcat或jboss日誌，而實施了微服務架構後，應用容器已經是自動部署和動態分配的，原有的故障診斷模式行不通，而需要PaaS平臺本身提供完整的預警和日誌分析能力。再次，如果發現了效能問題或故障，我們的解決方案是如何的？我們如何保證不影響到業務執行，不出現資料的丟失，或者在微服務模組擴充套件的時候不出現業務中斷等。這些已經不是簡單的部署架構層面的冗餘能解決的問題，而涉及到我們在整個微服務架構中的訊息策略，事務管理機制，持久化機制等問題。

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

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

方式1：引入的外部開發商進行微服務架構化如果一個企業本身IT部門規模小，軟體以外購為主，那麼勢必在對ERP等各類軟體的選型評估後引入不同的軟體產品提供商或軟體開發商。那麼軟體商本身都有了成熟的產品或架構，其產品內部的模組是否符合元件化和微服務架構的要求，我們不得而知。即使招標要求寫明軟體提供商提供產品需要基於SOA或微服務參考架構，但是實際上由於企業本身的IT能力和水平往往也無法驗證，而對於軟體廠商來說一定希望是賣現有產品，減少改造和定製實現利潤的最大化。對於軟體開發廠商來說對已有的軟體產品是沒有微服務架構改造的動力的。那在這種情況下要推動微服務架構實施落地必須的就是企業本身有很強的架構管控能力和甲方話語權。在曾經實施的案例裡面可以看到，甲方在有較強的IT規劃和架構設計能力情況下，才可能一開始就劃分好微服務模組並且設計好微服務模組間的介面，在進行招標和選型。同時甲方話語權強的情況下，可以完全要求軟體供應商按照自己定義好的標準，規範，架構進行微服務模組的開發。簡單點來說頂層架構分解和介面設計能力不在單個微服務模組開發商手裡面，而是在甲方手裡，或者在甲方請的專門負責規劃架構設計的技術諮詢團隊手裡。在這種模式下，技術諮詢團隊應該對整體模組劃分和後續整合負責，技術諮詢團隊就需要有業務和技術兩方面的能力，同時有類似領域的規劃設計經驗，系統開發建設經驗等。這些本身就對技術諮詢團隊提出了相當高的要求，可以來講很少有技術諮詢團隊達到這個水平，包括埃森哲或德勤等也難。在微服務架構下，我們希望的是一個業務系統如果由三個微服務模組組成，在我們進行了前期的架構和介面設計後，我們完全可以將三個模組發標給不同的軟體開發商建設和實施，然後在根據預先定義的服務介面進行整合。這個從理論上是行得通的，但是實際上出現兩個問題。其一是剛開始的模組劃分或介面設計不合理，在後面開發過程中才發現又很難再大變更。其二是微服務模組間的介面服務太多，導致了模組間的整合和聯調異常複雜。從上面也看到引入微服務架構後，企業本身可以削弱單個軟體供應商對企業本身的約束，防止被單一廠商繫結。因此企業沒有特色要求，從軟體廠商來說沒有任何動力和意願推微服務架構。方式2：企業自由開發團隊實踐微服務架構如果企業本身的IT成熟度沒有達到一定階段，顯然是不可能推行實施微服務架構的。這個道理前面已經談到過，在企業IT建設中，如果連粗粒度的業務系統以及它們之間的整合都管理不好，那麼更沒有能力管理細粒度的微服務模組。那麼如果企業IT成熟度達到一定水平，在推廣微服務架構還存在的難點如下：首先是架構設計能力的顯性化，即架構設計這個工作的輸入，輸出和過程需要更加的顯性化出來形成團隊都認同的標準工件。一個業務系統沒有拆分開時候，雖然有架構設計和元件劃分，但是這個工作是屬於團隊內部的事情，即使架構設計不合理，在後期整合也可以通過諸多變通方式解決掉。而現在是不同的微服務模組可能分派到兩個獨立的團隊開發，原來屬於自己內部黑盒的問題變為團隊間問題。簡單來說你原來藏著或沒做規範的東西太多，而現在這些不能再藏著掖著了，當真要把這些東西拿出來的時候，你才會發現你原來架構能力是有欠缺的。正如我們理解了一個東西，那麼要讓我們清楚的講出來困難，那麼我們的理解有欠缺。對於我們能講清楚的東西，要系統的寫下來有困難，那麼說明我們講的結構和條理有欠缺。其次管控要求和規範體系的建立，對於管控要求可以看到如果兩個微服務模組分給同一個團隊開發，如何才能保證開發的團隊保持兩個模組的完全獨立和解耦，兩個模組間不會出現相互交叉的資料庫直接呼叫，也不會存在直接繞開Service介面的其它耦合呼叫？這些如果沒有完整的管控和檢查體系我們很難約束。以上即是引入微服務架構後帶來的難點或缺點，供參考。自己也長期專注於SOA，微服務，DevOps支撐平臺建設實施，歡迎交流。

微服務之前的架構——單體架構

在微服務沒有盛行的時候，所有的企業都是基於單體架構。也就是JAVA的一個WAR包，GoLang的單一可執行檔案，Ruby或

Node.js

的一個目錄和它之下的子目錄中包含的各種原始碼。

單體架構存在多種好處，包括：

1. 開發簡單

2. 易於更改

3. 測試相對簡單直觀

4. 部署簡單

5. 橫向擴充套件簡單

...

但是，隨著時間的推移，開發、測試、部署和擴充套件都會變得非常困難。

隨著公司的發展，研發團隊規模不斷狀大，程式碼庫規模變大。曾經小巧、簡單的，由一個團隊開發維護的專案，經過多年成長，演變成一個由大團隊開發的巨無霸單體架構應用程式。

如下圖所示

單一原始碼倉庫導致額外的溝通和協調成本，從程式碼得交到生產環境部署需要經歷很多周折，變更必須等待手工測試。 應用變得龐大、複雜、不可靠、難以維護。

也就是說，當單體架構變得過度龐大和複雜，以至於任何一個開發者都很難理解它的全部，修復軟體中的問題和正確地實現新功能將變得困難且耗時，而且非常容易出問題。

如圖，微服務的概括定義是：把應用功能性分解為一組服務的架構風格。每一個服務都是由一組專注的、內聚的功能職責組成。

所以，微服務可以有這些好處

1. 大型複雜應用程式可以持續交付和持續部署

2. 每個服務相對較小並容易維護

5. 可以實現團隊的自治

6. 更好的容錯性等

...

但是，微服務同樣也來帶了弊端。

1. 服務的拆分和定義是一項挑戰

2. 分散式系統帶來的各種複雜性，使開發、測試和部署變得困難

3. 當部署跨越多個服務的功能時需要謹慎地協調更多開發團隊

...

內容小結

所以，微服務是一把好處和弊端共存的雙刃劍，採用微服務架構是一個需要認真思考的決策。

在使用微服務架構時，一些問題無法迴避，必須得到解決。每個問題都可能存在多種解決辦法，同時伴隨著各種權衡和取捨，並沒有一種完美的解決方案。

在開發中使用單體架構還是直接使用微服務架構，需要根據具體的情況來判斷。

一切的脫離場景說架構，都是而流氓。

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

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