前言

微服務(wù)在編程圈火的是不行不行的啦，可能還有很多小伙伴還沒有進(jìn)行微服務(wù)實(shí)操，但這個(gè)詞，要說沒聽過、沒看過，那小伙伴一定是假Programmer。

雖然微服務(wù)很火，但不能盲目使用；先不說涉及技術(shù)和工具有多少，首先應(yīng)該針對(duì)業(yè)務(wù)需求和開發(fā)團(tuán)隊(duì)有一個(gè)規(guī)劃，評(píng)估業(yè)務(wù)需求的復(fù)雜度和開發(fā)團(tuán)隊(duì)人數(shù)及技術(shù)能力。對(duì)于微服務(wù)本身，業(yè)務(wù)的劃分、開發(fā)的技能、部署的方案、維護(hù)的成本每一項(xiàng)都不能缺，否則很大一種可能就是以失敗告終。

來，小伙伴們一起聊聊，我先來說說我的理解，小伙伴可以評(píng)論，私聊都行.....

正文

微服務(wù)的出現(xiàn)，并不是為了替代原先單體架構(gòu)，而是為了解決單體架構(gòu)出現(xiàn)的相關(guān)問題；也不是為了取代面向SOA服務(wù)化的設(shè)計(jì)，其實(shí)應(yīng)用場(chǎng)景很關(guān)鍵，通常SOA面向服務(wù)化的方式，是企業(yè)信息化整合的常用的手段；對(duì)于SOA，雖然也是面向接口通訊，但我的理解其實(shí)是將更多的單體程序整合，業(yè)務(wù)細(xì)分沒有微服務(wù)那么精細(xì)。所以微服務(wù)并不是為了取代某一種程序架構(gòu)，而是它更適合于某種業(yè)務(wù)場(chǎng)景或更好地解決某種問題。

單體到微服務(wù)的演變

對(duì)于單體架構(gòu)而言，本身就是一種高生產(chǎn)力的架構(gòu)，程序員上來就干，干完就上線。盡管隨著業(yè)務(wù)復(fù)雜和訪問量的增多，也可以通過分布式+集群的方式實(shí)現(xiàn)應(yīng)用程序在高并發(fā)下的高可用；但是在Code過程中，當(dāng)每新出一種方案解決遺留問題時(shí)，隨之而來也有新問題的誕生，只是利益大于危害罷了。接下來，看看單體是如何演變到微服的，下圖只是針對(duì)軟件架構(gòu)進(jìn)行演變描述，圖片為自頂向下邏輯查閱。

從上圖看到，從最初的一臺(tái)服務(wù)器，隨著業(yè)務(wù)需求復(fù)雜及并發(fā)數(shù)據(jù)的增大，演變到三臺(tái)服務(wù)器，應(yīng)用程序、緩存、數(shù)據(jù)庫各自有專門的服務(wù)器的處理；通過緩存中間件緩解數(shù)據(jù)庫壓力，從而可以接受更多的請(qǐng)求，但是單臺(tái)應(yīng)用服務(wù)器的內(nèi)存、CPU處理能力、文件IO、網(wǎng)絡(luò)IO都有瓶頸，當(dāng)業(yè)務(wù)需求增加、并發(fā)量增大時(shí)，就要考慮集群啦。咱們接著聊↓↓↓

上圖為了應(yīng)對(duì)高并發(fā)實(shí)現(xiàn)高可用，剛開始采取了集群部署的方式，將請(qǐng)求合理分配到各個(gè)集群服務(wù)器中，提升處理能力。這樣一來，隨著長(zhǎng)時(shí)間數(shù)據(jù)的積累，特別針對(duì)數(shù)據(jù)比較多的系統(tǒng)，就會(huì)導(dǎo)致單庫或單表的數(shù)據(jù)量比較大，最終影響系統(tǒng)性能；這里一般的解決方案會(huì)采用分庫分表的形式解決，數(shù)據(jù)量特別大的，可以集合大數(shù)據(jù)平臺(tái)進(jìn)行數(shù)據(jù)保存和分析，這里就不在單獨(dú)作圖表示啦；

當(dāng)一個(gè)系統(tǒng)到了集群部署這一步，這個(gè)項(xiàng)目也不算小啦；通常業(yè)務(wù)需求會(huì)陸陸續(xù)續(xù)而來，最終會(huì)導(dǎo)致單體代碼量增大，維護(hù)和添加功能不容易，而最好的辦法是將比較單獨(dú)的業(yè)務(wù)獨(dú)立成一個(gè)項(xiàng)目，通過分布式的方式實(shí)現(xiàn)新增需求的擴(kuò)展，項(xiàng)目之間通常使用API、RPC或消息隊(duì)列的方式進(jìn)行通信；分布式+集群其實(shí)已經(jīng)足夠能應(yīng)付項(xiàng)目的開發(fā)啦，究竟存在哪些問題促使微服務(wù)的到來呢？

單體架構(gòu)面臨的問題：

?部署成本高：只要稍微改一處代碼，就可能導(dǎo)致整體替換部署；一些項(xiàng)目，時(shí)間就是金錢，不能接受；?迭代速度慢：項(xiàng)目整體龐大，稍一改動(dòng)，就得需要花費(fèi)大量的時(shí)間整體測(cè)試驗(yàn)證；?不易于擴(kuò)展：當(dāng)擴(kuò)展需求時(shí)，只能持續(xù)往項(xiàng)目中增加代碼，最后導(dǎo)致開發(fā)難度系數(shù)增大，風(fēng)險(xiǎn)高；部署擴(kuò)展也有風(fēng)險(xiǎn)；?大量代碼重用：雖然已經(jīng)分布式，但獨(dú)立出來的項(xiàng)目還是單體，存在大量代碼重用，比如權(quán)限和一些公共功能模塊等；?新人上手成本高：需要整體了解項(xiàng)目邏輯，花費(fèi)更多的時(shí)間，否則容易出錯(cuò)，風(fēng)險(xiǎn)高；

單體架構(gòu)的問題作為導(dǎo)火索，再加上當(dāng)今業(yè)務(wù)需求的復(fù)雜化及迭代速度要求高，最終就促進(jìn)了微服務(wù)的落地，為什么是落地呢？其實(shí)微服務(wù)概念在2014年一位馬丁.福勒的工程師就提出啦。

微服務(wù)這張圖去掉網(wǎng)關(guān)和服務(wù)治理是不是和分布式有異曲同工之處，其實(shí)微服務(wù)就是分布式，不過其劃分的更加精細(xì)，當(dāng)然對(duì)于監(jiān)控和追蹤那些沒在圖中體現(xiàn)，那微服務(wù)能解決什么問題呢？

微服務(wù)解決哪些問題(最接近開發(fā)的點(diǎn))

?部署成本低：針對(duì)具體的服務(wù)模塊進(jìn)行部署即可，不影響整體系統(tǒng)其它服務(wù)模塊運(yùn)行；?迭代速度快：單獨(dú)模塊服務(wù)易于開發(fā)和維護(hù)，負(fù)責(zé)人員能快速進(jìn)行開發(fā)、驗(yàn)證；?伸縮性好：開發(fā)可以根據(jù)業(yè)務(wù)進(jìn)行服務(wù)劃分，快速開發(fā)，不影響其他服務(wù)；部署易于擴(kuò)展；?代碼重用好：對(duì)于公共服務(wù)模塊進(jìn)行獨(dú)立共用，比如用戶認(rèn)證，權(quán)限管理等相關(guān)公用模塊；電商里面的支付、物流等；?新人上手成本低：針對(duì)進(jìn)入項(xiàng)目的新人，可以先從單個(gè)服務(wù)開始進(jìn)行開發(fā)，更容易上手，風(fēng)險(xiǎn)低；

是不是把單體對(duì)應(yīng)的問題都解決了，最起碼好處很明顯；當(dāng)然還有其他優(yōu)點(diǎn)，比如開發(fā)不限于語言，可以多語言進(jìn)行開發(fā)等；

對(duì)于每一種方案，解決問題的同時(shí)，肯定也有新問題的產(chǎn)生；絕對(duì)完美對(duì)于編程而言，好像這樣的方案還沒有，但相對(duì)完美還是得追求的，微服務(wù)究竟帶來哪些問題呢？

微服務(wù)帶來的問題(最接近開發(fā)的點(diǎn))

?分布式問題更加復(fù)雜化：因?yàn)楸緛矸植际絾栴}就存在，比如分布式鎖，分布式事務(wù)，數(shù)據(jù)一致性等問題，隨著服務(wù)的細(xì)化，自然就讓分布式問題更加復(fù)雜化；?問題排查增加難度：微服務(wù)很多時(shí)，如果出現(xiàn)問題，需要明確的定位，比起單體定位問題更加難啦，但可以借助追蹤工具和日志分析工具進(jìn)行輔助；?整體項(xiàng)目質(zhì)量管控更難：從性能方面，多服務(wù)交互需消耗網(wǎng)絡(luò)IO；單個(gè)服務(wù)掛了，如果處理不好可能導(dǎo)致系統(tǒng)雪崩；一般需要做熔斷、隔離、限流等相關(guān)防護(hù)；?對(duì)應(yīng)開發(fā)人員技術(shù)要求高：不僅是業(yè)務(wù)開發(fā)，對(duì)業(yè)務(wù)劃分、服務(wù)之間通訊、服務(wù)部署、服務(wù)監(jiān)控、虛擬化等都得有所熟悉，所以從技術(shù)開發(fā)到運(yùn)維監(jiān)控都得有對(duì)應(yīng)的技術(shù)棧知識(shí)的支撐；?部署難度增加：當(dāng)服務(wù)很多時(shí)，靠人為進(jìn)行操作已經(jīng)不現(xiàn)實(shí)；

所以，微服務(wù)并不是完美，只是在解決問題上帶來的好處相對(duì)比帶來問題更有價(jià)值；

既然最終都要演變到微服務(wù)，直接用是不是最好？

一般情況，各路大神都不建議直接使用微服務(wù)架構(gòu)，而是根據(jù)業(yè)務(wù)驅(qū)動(dòng)架構(gòu)的演進(jìn)，通常在使用微服務(wù)時(shí)，需要考慮以下情況：

?項(xiàng)目生產(chǎn)力要求，其實(shí)就是商務(wù)，如果公司允許有足夠的時(shí)間進(jìn)行開發(fā)，可以繼續(xù)考慮；否則單體架構(gòu)前期的生產(chǎn)力更容易體現(xiàn)，后續(xù)根據(jù)業(yè)務(wù)再演變?yōu)槲⒎?wù)架構(gòu)也是比較推薦的；?業(yè)務(wù)復(fù)雜度要求，如果業(yè)務(wù)需求本身不復(fù)雜，后續(xù)新增可能性不大，沒必要為了流行使用微服務(wù)；?開發(fā)團(tuán)隊(duì)要求，微服務(wù)初期是需要花費(fèi)大量的人力的，后期運(yùn)維也是重要活，如果團(tuán)隊(duì)人不多、技術(shù)不熟，得綜合考慮，否則會(huì)累死；

說這么多，不是說使用微服務(wù)不好，而是過早的使用，反而會(huì)一團(tuán)糟；還是那句話，一個(gè)項(xiàng)目在開發(fā)過程中過早的過度優(yōu)化，肯定等于玩火自焚：項(xiàng)目周期可能不能如期完成；當(dāng)前的優(yōu)化可能并不是適合后面的開發(fā)，可能還會(huì)重工等。

在刷博文的時(shí)候，看到一個(gè)詞：單體微服務(wù)，當(dāng)然這不是官方的詞，是博友自己的理解，就是用微服務(wù)的思想設(shè)計(jì)單體程序，這樣后續(xù)過渡到微服務(wù)的時(shí)候就相對(duì)平滑；

有沒有小伙伴關(guān)注到圖片上針對(duì)每一次演變都標(biāo)有段位，從倔強(qiáng)青銅到至尊星耀，那為什么沒有最強(qiáng)王者？或者說微服務(wù)為什么不是最強(qiáng)王者呢？軟件架構(gòu)隨著業(yè)務(wù)驅(qū)動(dòng)會(huì)不斷發(fā)展，總有一些新思路會(huì)出現(xiàn)，如今現(xiàn)在有些大廠在搞的Service Mesh(服務(wù)網(wǎng)格)可能就是下一個(gè)微服務(wù)演變的架構(gòu)，所以給最強(qiáng)王者留了個(gè)問號(hào)。

總結(jié)

微服務(wù)對(duì)于復(fù)雜業(yè)務(wù)的確很香，但同時(shí)也帶來了相關(guān)問題，同時(shí)要求的技術(shù)棧比較豐富，所以說它是麻辣味的，并不是一開始就能將其一下消化，需要慢慢實(shí)踐。好啦，微服務(wù)我理解的差不多是這樣，小伙伴歡迎指點(diǎn)及分享自己的想法，互相學(xué)習(xí)；

接下來會(huì)針對(duì)微服務(wù)的落地持續(xù)學(xué)習(xí)和分享相關(guān)文章，具體計(jì)劃在下一篇再好好說說。

一個(gè)被程序搞丑的帥小伙，關(guān)注"Code綜藝圈"，跟我一起學(xué)~

總結(jié)

以上是生活随笔為你收集整理的微服务很香--麻辣味，但要慢慢消化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。