?

前言

最近幾年微服務(wù)很火，大家都在建設(shè)微服務(wù)，仿佛不談點(diǎn)微服務(wù)相關(guān)的技術(shù)，都顯得不是那么主流了。


近幾年見識(shí)到身邊朋友的很多公司和團(tuán)隊(duì)都在嘗試進(jìn)行微服務(wù)的改變，但很多團(tuán)隊(duì)并沒有實(shí)際微服務(wù)踩坑經(jīng)驗(yàn)，很多團(tuán)隊(duì)甚至強(qiáng)行為了微服務(wù)而去微服務(wù)，最終寫成一個(gè)大型的分布式單體應(yīng)用，就是改造后的系統(tǒng)既沒有微服務(wù)的快速擴(kuò)容，靈活發(fā)布的特性，也讓原本的單體應(yīng)用失去了方便開發(fā)，部署容易的特性（項(xiàng)目拆為多份，開發(fā)部署復(fù)雜度都提高了），不得不說是得不償失。


作者親身經(jīng)歷和參與幾個(gè)大型項(xiàng)目微服務(wù)的改造和建設(shè)。所以想作為實(shí)踐者跟大家分享關(guān)于微服務(wù)的實(shí)際經(jīng)驗(yàn)，幫助大家了解微服務(wù)的優(yōu)缺點(diǎn)，從而可以結(jié)合自身業(yè)務(wù)做出更加合適的選擇，作為本篇文章的三個(gè)主題，例如：

* 什么是微服務(wù)？為什么要用微服務(wù)？
* 微服務(wù)解決什么問題，又引入了什么問題？
* 使用微服務(wù)應(yīng)該要遵循哪些原則？什么樣的情況你不應(yīng)該使用微服務(wù)？

（PS：因?yàn)槭忻嫔咸鄬?duì)如果使用微服務(wù)框架工具的教程，所以本篇只是一篇關(guān)于微服務(wù)的總體概述性文章，不涉及各種微服務(wù)框架的安裝和使用教程，我們只談?wù)撐⒎?wù)本身的設(shè)計(jì)模式的優(yōu)缺點(diǎn)和適合應(yīng)用的場(chǎng)景）

一：什么是微服務(wù)？為什么要用微服務(wù)？

什么是微服務(wù)？（熟悉的同學(xué)可以直接跳過）


簡單舉例：看軍事新聞的同學(xué)應(yīng)該都知道，一艘航空母艦作戰(zhàn)能力雖然很強(qiáng)，但是弱點(diǎn)太明顯，就是防御能力太差，單艘的航空母艦很少單獨(dú)行動(dòng)，通常航空母艦戰(zhàn)斗群才是主要軍事力量，你可以把單艘航母理解為的單體應(yīng)用（防御差，機(jī)動(dòng)性不好），把航母戰(zhàn)斗群（調(diào)度復(fù)雜，維護(hù)費(fèi)用高）理解為微服務(wù)。

大部分的開發(fā)者經(jīng)歷和開發(fā)過單體應(yīng)用，無論是傳統(tǒng)的 Servlet + JSP，還是 SSM，還是現(xiàn)在的
SpringBoot，它們都是單體應(yīng)用，那么長期陪伴我們的單體應(yīng)用有什么弊端？我們是面臨了什么問題，導(dǎo)致我們要拋棄單體應(yīng)用轉(zhuǎn)向微服務(wù)架構(gòu)？個(gè)人總結(jié)主要問題如下：

* 部署成本高（無論是修改1行代碼，還是10行代碼，都要全量替換）
* 改動(dòng)影響大，風(fēng)險(xiǎn)高（不論代碼改動(dòng)多小，成本都相同）
* 因?yàn)槌杀靖撸L(fēng)險(xiǎn)高，所以導(dǎo)致部署頻率低（無法快速交付客戶需求）

當(dāng)然還有例如無法滿足快速擴(kuò)容，彈性伸縮，無法適應(yīng)云環(huán)境特性等問題，但我們不一一詳談了，以上的問題，都是微服務(wù)架構(gòu)要解決的問題，至于具體是怎么解決的，我們先放到后面再聊

?

二：微服務(wù)解決什么問題，又引入了什么問題？

我們先看看微服務(wù)能帶給我們什么？微服務(wù)架構(gòu)的特點(diǎn)：

* 針對(duì)特定服務(wù)發(fā)布，影響小，風(fēng)險(xiǎn)小，成本低
* 頻繁發(fā)布版本，快速交付需求
* 低成本擴(kuò)容，彈性伸縮，適應(yīng)云環(huán)境
?


我們知道一個(gè)樸素的理念，沒有任何事物是完美的，任何東西都有兩面性，有得必有失，那么在選擇微服務(wù)在解決了快速響應(yīng)和彈性伸縮的問題同時(shí)，它又給我們帶來了什么問題？個(gè)人總結(jié)如下：

* 分布式系統(tǒng)的復(fù)雜性
* 部署，測(cè)試和監(jiān)控的成本問題
* 分布式事務(wù)和CAP的相關(guān)問題
?


系統(tǒng)應(yīng)用由原來的單體變成幾十到幾百個(gè)不同的工程，會(huì)所產(chǎn)生例如包括服務(wù)間的依賴，服務(wù)如何拆封，內(nèi)部接口規(guī)范，數(shù)據(jù)傳遞等等問題，尤其是服務(wù)拆分，需要團(tuán)隊(duì)熟悉業(yè)務(wù)流程，懂得取舍，要保證拆分的粒度服務(wù)既符合“高內(nèi)聚，低耦合”的基本原則，還要兼顧業(yè)務(wù)的發(fā)展以及公司的愿景，要還要說服團(tuán)隊(duì)成員為之努力，并且積極投入，在多方中間取得平衡。

對(duì)于分布式系統(tǒng)，部署，測(cè)試和監(jiān)控都需要大量的中間件來支撐，而且中間件本身也要維護(hù)，原先單體應(yīng)用很簡單的事務(wù)問題
，轉(zhuǎn)到分布式環(huán)境就變得很復(fù)雜，分布式事務(wù)是采用簡單的重試+補(bǔ)償機(jī)制，還是采用二階段提交協(xié)議等強(qiáng)一致性方法來解決，就要取決對(duì)業(yè)務(wù)場(chǎng)景的熟悉加上反復(fù)的權(quán)衡了，相同問題還包括對(duì)
CAP 模型的權(quán)衡，總之微服務(wù)對(duì)團(tuán)隊(duì)整體的技術(shù)棧水平整體要求更高

?

?

三：使用微服務(wù)應(yīng)該遵循哪些原則？


古人云：兵馬未動(dòng)，糧草先行。建設(shè)微服務(wù)是需要建立長遠(yuǎn)規(guī)劃，不是像寫CMS那樣建好數(shù)據(jù)庫表，然后就開始干活，這樣十有八九是會(huì)失敗的。我們要進(jìn)行微服務(wù)改造前，架構(gòu)師要提前做好規(guī)劃，我們把這里分為三步，前期階段，設(shè)計(jì)階段，技術(shù)階段

前期階段，大致要做好如下事情：

* 和多方充分溝通，確保能符合客戶和組織的需求，并且得到認(rèn)同
* 和團(tuán)隊(duì)溝通，讓隊(duì)友（開發(fā)/測(cè)試/運(yùn)維）理解，并且積極投入
* 和業(yè)務(wù)部門溝通，指定版本計(jì)劃和上線時(shí)間
?

設(shè)計(jì)階段，參考?Sam Newman 的著作《微服務(wù)設(shè)計(jì)》 <https://book.douban.com/subject/26772677/>
，單微服務(wù)必須要滿足以下的條件，才符合微服務(wù)的基本要求：

* 標(biāo)準(zhǔn)的 REST 風(fēng)格接口（基于 HTTP 和 JSON 格式）
* 獨(dú)立部署，避免共享數(shù)據(jù)庫（避免因?yàn)閿?shù)據(jù)庫而影響整個(gè)分布式系統(tǒng)）
* 業(yè)務(wù)上的高內(nèi)聚，減少依賴（從設(shè)計(jì)上要避免服務(wù)過大或者太小）
?

龐大的分布式系統(tǒng)，需要強(qiáng)大基礎(chǔ)設(shè)施來支撐，微服務(wù)涉及哪些基礎(chǔ)設(shè)施？

* CI/CD和自動(dòng)化（分布式系統(tǒng)幾乎不可能通過人工手動(dòng)發(fā)布）
* 虛擬化技術(shù)（要保證微服務(wù)運(yùn)行環(huán)境隔離，目前行業(yè)主流的是使用 Docker 容器）
* 日志聚合，全鏈路監(jiān)控（高度可觀察和分析診斷問題）
?

說了那么多，那什么樣的情況下，你的團(tuán)隊(duì)不適合建設(shè)微服務(wù)？（請(qǐng)勿對(duì)號(hào)入座）

* 開發(fā)團(tuán)隊(duì)不具備自主性，所在組織對(duì)開發(fā)團(tuán)隊(duì)限制非常多（具體請(qǐng)參考?康威定律
<https://zh.wikipedia.org/wiki/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B>）
* 團(tuán)隊(duì)不熟悉業(yè)務(wù)，無法識(shí)別出服務(wù)的邊界，進(jìn)行合理的拆分（請(qǐng)參考 DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)
<https://en.wikipedia.org/wiki/Domain-driven_design>）
?

?

?

?

總結(jié)

微服務(wù)設(shè)計(jì)其實(shí)是很早就有的設(shè)計(jì)思想，因?yàn)殡S著虛擬化技術(shù)的崛起，微服務(wù)可以低成本的實(shí)現(xiàn)，所以也開始流行和興起。


微服務(wù)的內(nèi)涵很深，其中就包括，自動(dòng)化，去中心化，獨(dú)立性等等，其中細(xì)節(jié)無法用一篇文章概述清楚，我們?cè)谧黾夹g(shù)選型或者方案的時(shí)候，盡可能多去了解技術(shù)的本身和起源再結(jié)合我們業(yè)務(wù)的特點(diǎn)，進(jìn)行更好的選擇。

個(gè)人知識(shí)有限，不喜勿噴，對(duì)于微服務(wù)你又有什么不同的看法呢？歡迎來留言進(jìn)行討論和交流

• ? 上一篇：Vim高手，從來不用鼠標(biāo)
• ? 下一篇：如何閱讀JDK源碼