什麼是微服務？爲何你要用微服務？

​

前言

最近幾年微服務很火，你們都在建設微服務，彷彿不談點微服務相關的技術，都顯得不是那麼主流了。

近幾年見識到身邊朋友的不少公司和團隊都在嘗試進行微服務的改變，但不少團隊並無實際微服務踩坑經驗，不少團隊甚至強行爲了微服務而去微服務，最終寫成一個大型的分佈式單體應用，就是改造後的系統既沒有微服務的快速擴容，靈活發佈的特性，也讓本來的單體應用失去了方便開發，部署容易的特性（項目拆爲多份，開發部署複雜度都提升了），不得不說是得不償失。

做者親身經歷和參與幾個大型項目微服務的改造和建設。因此想做爲實踐者跟你們分享關於微服務的實際經驗，幫助你們瞭解微服務的優缺點，從而能夠結合自身業務作出更加合適的選擇，做爲本篇文章的三個主題，例如：

1. 什麼是微服務？爲何要用微服務？
2. 微服務解決什麼問題，又引入了什麼問題？
3. 使用微服務應該要遵循哪些原則？什麼樣的狀況你不該該使用微服務？

（PS：由於市面上太多對若是使用微服務框架工具的教程，因此本篇只是一篇關於微服務的整體概述性文章，不涉及各類微服務框架的安裝和使用教程，咱們只談論微服務自己的設計模式的優缺點和適合應用的場景）

一：什麼是微服務？爲何要用微服務？

什麼是微服務？（熟悉的同窗能夠直接跳過）

簡單舉例：看軍事新聞的同窗應該都知道，一艘航空母艦做戰能力雖然很強，可是弱點太明顯，就是防護能力太差，單艘的航空母艦不多單獨行動，一般航空母艦戰鬥羣纔是主要軍事力量，你能夠把單艘航母理解爲的單體應用（防護差，機動性很差），把航母戰鬥羣（調度複雜，維護費用高）理解爲微服務。

大部分的開發者經歷和開發過單體應用，不管是傳統的 Servlet + JSP，仍是 SSM，仍是如今的 SpringBoot，它們都是單體應用，那麼長期陪伴咱們的單體應用有什麼弊端？咱們是面臨了什麼問題，致使咱們要拋棄單體應用轉向微服務架構？我的總結主要問題以下：

• 部署成本高（不管是修改1行代碼，仍是10行代碼，都要全量替換）
• 改動影響大，風險高（不論代碼改動多小，成本都相同）
• 由於成本高，風險高，因此致使部署頻率低（沒法快速交付客戶需求）

固然還有例如沒法知足快速擴容，彈性伸縮，沒法適應雲環境特性等問題，但咱們不一一詳談了，以上的問題，都是微服務架構要解決的問題，至於具體是怎麼解決的，咱們先放到後面再聊

 

 

​

二：微服務解決什麼問題，又引入了什麼問題？

咱們先看看微服務能帶給咱們什麼？微服務架構的特色：

• 針對特定服務發佈，影響小，風險小，成本低
• 頻繁發佈版本，快速交付需求
• 低成本擴容，彈性伸縮，適應雲環境

 

咱們知道一個樸素的理念，沒有任何事物是完美的，任何東西都有兩面性，有得必有失，那麼在選擇微服務在解決了快速響應和彈性伸縮的問題同時，它又給咱們帶來了什麼問題？我的總結以下：

• 分佈式系統的複雜性
• 部署，測試和監控的成本問題
• 分佈式事務和CAP的相關問題

 

系統應用由原來的單體變成幾十到幾百個不一樣的工程，會所產生例如包括服務間的依賴，服務如何拆封，內部接口規範，數據傳遞等等問題，尤爲是服務拆分，須要團隊熟悉業務流程，懂得取捨，要保證拆分的粒度服務既符合「高內聚，低耦合」的基本原則，還要兼顧業務的發展以及公司的願景，要還要說服團隊成員爲之努力，而且積極投入，在多方中間取得平衡。

對於分佈式系統，部署，測試和監控都須要大量的中間件來支撐，並且中間件自己也要維護，原先單體應用很簡單的事務問題 ，轉到分佈式環境就變得很複雜，分佈式事務是採用簡單的重試+補償機制，仍是採用二階段提交協議等強一致性方法來解決，就要取決對業務場景的熟悉加上反覆的權衡了，相同問題還包括對 CAP 模型的權衡，總之微服務對團隊總體的技術棧水平總體要求更高

​

 

 

三：使用微服務應該遵循哪些原則？

古人云：兵馬未動，糧草先行。建設微服務是須要創建長遠規劃，不是像寫CMS那樣建好數據庫表，而後就開始幹活，這樣十有八九是會失敗的。咱們要進行微服務改造前，架構師要提早作好規劃，咱們把這裏分爲三步，前期階段，設計階段，技術階段

前期階段，大體要作好以下事情：

• 和多方充分溝通，確保能符合客戶和組織的需求，而且獲得認同
• 和團隊溝通，讓隊友（開發/測試/運維）理解，而且積極投入
• 和業務部門溝通，指定版本計劃和上線時間

 

設計階段，參考 Sam Newman 的著做《微服務設計》，單微服務必需要知足如下的條件，才符合微服務的基本要求：

• 標準的 REST 風格接口（基於 HTTP 和 JSON 格式）
• 獨立部署，避免共享數據庫（避免由於數據庫而影響整個分佈式系統）
• 業務上的高內聚，減小依賴（從設計上要避免服務過大或者過小）

 

龐大的分佈式系統，須要強大基礎設施來支撐，微服務涉及哪些基礎設施？

• CI/CD和自動化（分佈式系統幾乎不可能經過人工手動發佈）
• 虛擬化技術（要保證微服務運行環境隔離，目前行業主流的是使用 Docker 容器）
• 日誌聚合，全鏈路監控（高度可觀察和分析診斷問題）

 

說了那麼多，那什麼樣的狀況下，你的團隊不適合建設微服務？（請勿對號入座）

1. 開發團隊不具有自主性，所在組織對開發團隊限制很是多（具體請參考 康威定律）
2. 團隊不熟悉業務，沒法識別出服務的邊界，進行合理的拆分（請參考 DDD 領域驅動設計）

 

 

​

 

總結

微服務設計實際上是很早就有的設計思想，由於隨着虛擬化技術的崛起，微服務能夠低成本的實現，因此也開始流行和興起。

微服務的內涵很深，其中就包括，自動化，去中心化，獨立性等等，其中細節沒法用一篇文章概述清楚，咱們在作技術選型或者方案的時候，儘量多去了解技術的自己和起源再結合咱們業務的特色，進行更好的選擇。

我的知識有限，不喜勿噴，對於微服務你又有什麼不一樣的見解呢？歡迎來留言進行討論和交流