盡管微服務(wù)架構(gòu)有著高度獨(dú)立的軟件模塊、單一的業(yè)務(wù)職責(zé)、可靈活調(diào)整的技術(shù)棧等優(yōu)勢(shì)，但也不能忽略它所帶來(lái)的弊端。本篇文章，我們從網(wǎng)絡(luò)、性能、運(yùn)維、組織架構(gòu)和集成測(cè)試五個(gè)方面來(lái)聊一下設(shè)計(jì)微服務(wù)架構(gòu)需要考慮哪些問(wèn)題，對(duì)設(shè)計(jì)有哪些挑戰(zhàn)呢？

1、跨進(jìn)程通信帶來(lái)的問(wèn)題

前面我們聊過(guò)了，以往的單體應(yīng)用，系統(tǒng)是在單機(jī)中進(jìn)行進(jìn)程通信，通信的穩(wěn)定性相當(dāng)好，只要服務(wù)器不宕機(jī)，基本上不會(huì)出現(xiàn)通信中斷或異常的問(wèn)題（超時(shí)不計(jì)入）。但是將單體應(yīng)用打散為分布式架構(gòu)后，系統(tǒng)的通信方式改變?yōu)榱诉M(jìn)程間通信，往往還有可能伴隨著跨設(shè)備的網(wǎng)絡(luò)訪問(wèn)，那么架構(gòu)師在設(shè)計(jì)的時(shí)候，就必須要考慮應(yīng)用的上下游系統(tǒng)因網(wǎng)絡(luò)因素導(dǎo)致無(wú)法通信的問(wèn)題。要假設(shè)網(wǎng)絡(luò)是不可靠的（就相當(dāng)于是前端頁(yè)面不應(yīng)該相信用戶的一切輸入，該做的數(shù)據(jù)校驗(yàn)一定要做），并對(duì)網(wǎng)絡(luò)異常情況作出符合預(yù)期的異常處理。

以支付場(chǎng)景為例：用戶支付成功后，系統(tǒng)自動(dòng)調(diào)用短信發(fā)送服務(wù)給用戶發(fā)送支付成功的短信，此時(shí)就需要考慮到如果短信發(fā)送不成功需要做什么異常處理。是標(biāo)記未發(fā)送后重試，還是通過(guò)App進(jìn)行消息提示，并將異常信息入庫(kù)提醒運(yùn)維檢查短信服務(wù)運(yùn)行情況。

單體應(yīng)用調(diào)用鏈路：

微服務(wù)架構(gòu)下的調(diào)用鏈路：

2、響應(yīng)延遲帶來(lái)的問(wèn)題

與單體架構(gòu)進(jìn)程內(nèi)通行相比，微服務(wù)架構(gòu)的跨進(jìn)程、跨網(wǎng)絡(luò)通信在網(wǎng)絡(luò)傳輸與消息序列化帶來(lái)的延遲是不可忽略的。尤其是在五個(gè)以上的微服務(wù)間消息調(diào)用時(shí)，網(wǎng)絡(luò)延遲對(duì)于實(shí)時(shí)系統(tǒng)的影響是很大的。

以紅海行動(dòng)電影中的1130近防炮的彈道計(jì)算為例：需要通過(guò)雷達(dá)監(jiān)測(cè)的敵方炮彈的射速、方位、風(fēng)速等因素計(jì)算近防炮在何時(shí)、哪些方位發(fā)射子彈進(jìn)行攔截。在這種情況下，使用微服務(wù)架構(gòu)帶來(lái)的延遲，可能導(dǎo)致炮彈都打到身上了，彈道計(jì)算數(shù)據(jù)還沒(méi)傳過(guò)來(lái)。顯然這類系統(tǒng)采用分布式設(shè)計(jì)就不合適。 以上例子純屬軍事外行瞎猜，只是為了舉例，說(shuō)的不對(duì)的還請(qǐng)不要介意。。

3、運(yùn)維方面的問(wèn)題

之前的單體架構(gòu)，運(yùn)維在部署系統(tǒng)時(shí)，直接將系統(tǒng)jar或war包丟到容器里啟動(dòng)就行了，就算是沒(méi)有自動(dòng)化部署，工作量也不是很大。同時(shí)，以前的系統(tǒng)升級(jí)都是以周或月為單位，就算是人肉運(yùn)維也都可以應(yīng)付得過(guò)來(lái)。而對(duì)于微服務(wù)而言，每個(gè)服務(wù)都是可獨(dú)立運(yùn)行、獨(dú)立部署、獨(dú)立維護(hù)的業(yè)務(wù)單元。再加上市場(chǎng)的需求越來(lái)越高，運(yùn)維人員每天面對(duì)成百上千臺(tái)服務(wù)器發(fā)布幾十次都是有可能的，人肉運(yùn)維和部署顯然已經(jīng)無(wú)法滿足互聯(lián)網(wǎng)的快速變化。

自動(dòng)化運(yùn)維架構(gòu)圖

4、組織架構(gòu)帶來(lái)的問(wèn)題

微服務(wù)架構(gòu)帶來(lái)的不僅是軟件架構(gòu)的改變，也是公司組織架構(gòu)的改變。

單體架構(gòu)下，公司以職能劃分部門(mén)（項(xiàng)目部、產(chǎn)品部、設(shè)計(jì)部、開(kāi)發(fā)部、測(cè)試部、運(yùn)維部）進(jìn)行獨(dú)立管理考核，技術(shù)人員負(fù)責(zé)其中的某幾個(gè)模塊開(kāi)發(fā)即可，可由統(tǒng)一的項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、UI設(shè)計(jì)師進(jìn)行支撐。

微服務(wù)架構(gòu)下，是以業(yè)務(wù)模塊進(jìn)行團(tuán)隊(duì)劃分，每個(gè)團(tuán)隊(duì)是內(nèi)聚的，要求可以完成從調(diào)研到發(fā)版的全流程，盡量減少對(duì)外界的依賴。如何將之前的職能團(tuán)隊(duì)調(diào)整為按業(yè)務(wù)劃分的研發(fā)團(tuán)隊(duì)，同樣是對(duì)組織架構(gòu)的巨大挑戰(zhàn)。畢竟人的思想比架構(gòu)更難改變。

單體架構(gòu)下團(tuán)隊(duì)配置

微服務(wù)架構(gòu)下團(tuán)隊(duì)配置

5、集成測(cè)試變得異常艱難

傳統(tǒng)的單體架構(gòu)集成測(cè)試是將不同的模塊按業(yè)務(wù)流程進(jìn)行組合，在進(jìn)程內(nèi)驗(yàn)證每種可能性下模塊間的協(xié)作是否符合預(yù)期即可。對(duì)于微服務(wù)而言，系統(tǒng)被拆解成獨(dú)立的運(yùn)行單元，服務(wù)間采用接口進(jìn)行通信。要獲取準(zhǔn)確的結(jié)果，必須搭建完整的微服務(wù)環(huán)境。同時(shí)，跨網(wǎng)絡(luò)通信帶來(lái)的網(wǎng)絡(luò)延遲、超時(shí)、帶寬、數(shù)據(jù)量等因素都將影響最終結(jié)果，測(cè)試結(jié)果容易產(chǎn)生偏差。

所以，微服務(wù)架構(gòu)并不是沒(méi)有缺點(diǎn)，在一定程度上，可能造成的影響比單體的影響大很多。那么我們是難道就不進(jìn)行改造嗎？有困難就退縮不是一個(gè)優(yōu)秀架構(gòu)師該有的品質(zhì)。那有什么可借鑒的經(jīng)驗(yàn)嗎？當(dāng)然有，我們以后再下篇接著聊！文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-845788.html

到了這里，關(guān)于深入淺出 -- 系統(tǒng)架構(gòu)之微服務(wù)架構(gòu)的新挑戰(zhàn)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！