什麼是微服務？為什麼你要用微服務？
- 2019 年 10 月 3 日
- 筆記
前言
最近幾年微服務很火，大家都在建設微服務，彷彿不談點微服務相關的技術，都顯得不是那麼主流了。
近幾年見識到身邊朋友的很多公司和團隊都在嘗試進行微服務的改變，但很多團隊並沒有實際微服務踩坑經驗，很多團隊甚至強行為了微服務而去微服務，最終寫成一個大型的分散式單體應用，就是改造後的系統既沒有微服務的快速擴容，靈活發布的特性，也讓原本的單體應用失去了方便開發，部署容易的特性（項目拆為多份，開發部署複雜度都提高了），不得不說是得不償失。
作者親身經歷和參與幾個大型項目微服務的改造和建設。所以想作為實踐者跟大家分享關於微服務的實際經驗，幫助大家了解微服務的優缺點，從而可以結合自身業務做出更加合適的選擇，作為本篇文章的三個主題，例如：
- 什麼是微服務？為什麼要用微服務？
- 微服務解決什麼問題，又引入了什麼問題？
- 使用微服務應該要遵循哪些原則？什麼樣的情況你不應該使用微服務？
（PS：因為市面上太多對如果使用微服務框架工具的教程，所以本篇只是一篇關於微服務的總體概述性文章，不涉及各種微服務框架的安裝和使用教程，我們只談論微服務本身的設計模式的優缺點和適合應用的場景）
一：什麼是微服務？為什麼要用微服務？
什麼是微服務？（熟悉的同學可以直接跳過）
簡單舉例：看軍事新聞的同學應該都知道，一艘航空母艦作戰能力雖然很強，但是弱點太明顯，就是防禦能力太差，單艘的航空母艦很少單獨行動，通常航空母艦戰鬥群才是主要軍事力量，你可以把單艘航母理解為的單體應用（防禦差，機動性不好），把航母戰鬥群（調度複雜，維護費用高）理解為微服務。
大部分的開發者經歷和開發過單體應用，無論是傳統的 Servlet + JSP，還是 SSM，還是現在的 SpringBoot，它們都是單體應用，那麼長期陪伴我們的單體應用有什麼弊端？我們是面臨了什麼問題，導致我們要拋棄單體應用轉向微服務架構？個人總結主要問題如下：
- 部署成本高（無論是修改1行程式碼，還是10行程式碼，都要全量替換）
- 改動影響大，風險高（不論程式碼改動多小，成本都相同）
- 因為成本高，風險高，所以導致部署頻率低（無法快速交付客戶需求）
當然還有例如無法滿足快速擴容，彈性伸縮，無法適應雲環境特性等問題，但我們不一一詳談了，以上的問題，都是微服務架構要解決的問題，至於具體是怎麼解決的，我們先放到後面再聊
二：微服務解決什麼問題，又引入了什麼問題？
我們先看看微服務能帶給我們什麼？微服務架構的特點：
- 針對特定服務發布，影響小，風險小，成本低
- 頻繁發布版本，快速交付需求
- 低成本擴容，彈性伸縮，適應雲環境
我們知道一個樸素的理念，沒有任何事物是完美的，任何東西都有兩面性，有得必有失，那麼在選擇微服務在解決了快速響應和彈性伸縮的問題同時，它又給我們帶來了什麼問題？個人總結如下：
- 分散式系統的複雜性
- 部署，測試和監控的成本問題
- 分散式事務和CAP的相關問題
系統應用由原來的單體變成幾十到幾百個不同的工程，會所產生例如包括服務間的依賴，服務如何拆封，內部介面規範，數據傳遞等等問題，尤其是服務拆分，需要團隊熟悉業務流程，懂得取捨，要保證拆分的粒度服務既符合“高內聚，低耦合”的基本原則，還要兼顧業務的發展以及公司的願景，要還要說服團隊成員為之努力，並且積極投入，在多方中間取得平衡。
對於分散式系統，部署，測試和監控都需要大量的中間件來支撐，而且中間件本身也要維護，原先單體應用很簡單的事務問題 ，轉到分散式環境就變得很複雜，分散式事務是採用簡單的重試+補償機制，還是採用二階段提交協議等強一致性方法來解決，就要取決對業務場景的熟悉加上反覆的權衡了，相同問題還包括對 CAP 模型的權衡，總之微服務對團隊整體的技術棧水平整體要求更高
三：使用微服務應該遵循哪些原則？
古人云：兵馬未動，糧草先行。建設微服務是需要建立長遠規劃，不是像寫CMS那樣建好資料庫表，然後就開始幹活，這樣十有八九是會失敗的。我們要進行微服務改造前，架構師要提前做好規劃，我們把這裡分為三步，前期階段，設計階段，技術階段
前期階段，大致要做好如下事情：
- 和多方充分溝通，確保能符合客戶和組織的需求，並且得到認同
- 和團隊溝通，讓隊友（開發/測試/運維）理解，並且積極投入
- 和業務部門溝通，指定版本計劃和上線時間
設計階段，參考 Sam Newman 的著作《微服務設計》，單微服務必須要滿足以下的條件，才符合微服務的基本要求：
- 標準的 REST 風格介面（基於 HTTP 和 JSON 格式）
- 獨立部署，避免共享資料庫（避免因為資料庫而影響整個分散式系統）
- 業務上的高內聚，減少依賴（從設計上要避免服務過大或者太小）
龐大的分散式系統，需要強大基礎設施來支撐，微服務涉及哪些基礎設施？
- CI/CD和自動化（分散式系統幾乎不可能通過人工手動發布）
- 虛擬化技術（要保證微服務運行環境隔離，目前行業主流的是使用 Docker 容器）
- 日誌聚合，全鏈路監控（高度可觀察和分析診斷問題）
說了那麼多，那什麼樣的情況下，你的團隊不適合建設微服務？（請勿對號入座）
總結
微服務設計其實是很早就有的設計思想，因為隨著虛擬化技術的崛起，微服務可以低成本的實現，所以也開始流行和興起。
微服務的內涵很深，其中就包括，自動化，去中心化，獨立性等等，其中細節無法用一篇文章概述清楚，我們在做技術選型或者方案的時候，儘可能多去了解技術的本身和起源再結合我們業務的特點，進行更好的選擇。
個人知識有限，不喜勿噴，對於微服務你又有什麼不同的看法呢？歡迎來留言進行討論和交流
