簡介

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

缺點技術要求變高

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

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

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

運維成本

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

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

複雜度高

微服務之間的呼叫方式是通過RPC方式來進行資料互動，相比傳統模式，你需要考慮過載、訊息丟失、重試、負載等場景，需要處理的邏輯也很多。

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

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

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

效能層面

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

總結

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

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

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

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

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

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

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

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

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

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

微服務的特徵

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

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

輕量級的通訊協議；

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

不僅服務微，團隊也要“微”；

微服務帶來的好處

每個微服務可以獨立擴充套件，因為服務微，所以單個服務可以快速擴充套件；

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

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

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

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

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

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

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

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

增加了整合測試的難度；

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

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

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

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

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

Node.js

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

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

1. 開發簡單

2. 易於更改

3. 測試相對簡單直觀

4. 部署簡單

5. 橫向擴充套件簡單

...

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

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

如下圖所示

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

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

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

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

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

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

5. 可以實現團隊的自治

6. 更好的容錯性等

...

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

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

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

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

...

內容小結

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

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

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

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