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