https://learnku.com/articles/36303
要理解微服務(wù)，首先要先理解不是微服務(wù)的那些泡躯。通常跟微服務(wù)相對(duì)的是單體應(yīng)用乍狐，即將所有功能都打包成在一個(gè)獨(dú)立單元的應(yīng)用程序。從單體應(yīng)用到微服務(wù)并不是一蹴而就的尘应，這是一個(gè)逐漸演變的過(guò)程谁帕。本文將以一個(gè)網(wǎng)上超市應(yīng)用為例來(lái)說(shuō)明這一過(guò)程峡继。
最初的需求
幾年前，小明和小皮一起創(chuàng)業(yè)做網(wǎng)上超市匈挖。小明負(fù)責(zé)程序開(kāi)發(fā)碾牌，小皮負(fù)責(zé)其他事宜。當(dāng)時(shí)互聯(lián)網(wǎng)還不發(fā)達(dá)儡循，網(wǎng)上超市還是藍(lán)海舶吗。只要功能實(shí)現(xiàn)了就能隨便賺錢(qián)。所以他們的需求很簡(jiǎn)單择膝，只需要一個(gè)網(wǎng)站掛在公網(wǎng)誓琼，用戶能夠在這個(gè)網(wǎng)站上瀏覽商品、購(gòu)買(mǎi)商品肴捉；另外還需一個(gè)管理后臺(tái)腹侣，可以管理商品、用戶齿穗、以及訂單數(shù)據(jù)傲隶。
我們整理一下功能清單：
- 網(wǎng)站
- 用戶注冊(cè)、登錄功能
- 商品展示
- 下單
- 管理后臺(tái)
- 用戶管理
- 商品管理
- 訂單管理
由于需求簡(jiǎn)單窃页，小明左手右手一個(gè)慢動(dòng)作跺株，網(wǎng)站就做好了复濒。管理后臺(tái)出于安全考慮，不和網(wǎng)站做在一起乒省，小明右手左手慢動(dòng)作重播巧颈，管理網(wǎng)站也做好了⌒淇福總體架構(gòu)圖如下：
小明揮一揮手砸泛，找了家云服務(wù)部署上去，網(wǎng)站就上線了攻锰。上線后好評(píng)如潮晾嘶，深受各類(lèi)肥宅喜愛(ài)妓雾。小明小皮美滋滋地開(kāi)始躺著收錢(qián)娶吞。
隨著業(yè)務(wù)發(fā)展……
好景不長(zhǎng)哼鬓，沒(méi)過(guò)幾天蹋偏，各類(lèi)網(wǎng)上超市緊跟著拔地而起掷空，對(duì)小明小皮造成了強(qiáng)烈的沖擊碰凶。
在競(jìng)爭(zhēng)的壓力下线椰，小明小皮決定開(kāi)展一些營(yíng)銷(xiāo)手段：
開(kāi)展促銷(xiāo)活動(dòng)舰罚。比如元旦全場(chǎng)打折方援，春節(jié)買(mǎi)二送一黎休，情人節(jié)狗糧優(yōu)惠券等等欢揖。
拓展渠道陶耍，新增移動(dòng)端營(yíng)銷(xiāo)。除了網(wǎng)站外她混，還需要開(kāi)發(fā)移動(dòng)端 APP烈钞，微信小程序等。
精準(zhǔn)營(yíng)銷(xiāo)坤按。利用歷史數(shù)據(jù)對(duì)用戶進(jìn)行分析毯欣，提供個(gè)性化服務(wù)。
……
這些活動(dòng)都需要程序開(kāi)發(fā)的支持臭脓。小明拉了同學(xué)小紅加入團(tuán)隊(duì)酗钞。小紅負(fù)責(zé)數(shù)據(jù)分析以及移動(dòng)端相關(guān)開(kāi)發(fā)。小明負(fù)責(zé)促銷(xiāo)活動(dòng)相關(guān)功能的開(kāi)發(fā)来累。
因?yàn)殚_(kāi)發(fā)任務(wù)比較緊迫砚作，小明小紅沒(méi)有好好規(guī)劃整個(gè)系統(tǒng)的架構(gòu)，隨便拍了拍腦袋嘹锁，決定把促銷(xiāo)管理和數(shù)據(jù)分析放在管理后臺(tái)里偎巢，微信和移動(dòng)端 APP 另外搭建。通宵了幾天后兼耀，新功能和新應(yīng)用基本完工压昼。這時(shí)架構(gòu)圖如下：
這一階段存在很多不合理的地方：
網(wǎng)站和移動(dòng)端應(yīng)用有很多相同業(yè)務(wù)邏輯的重復(fù)代碼求冷。
數(shù)據(jù)有時(shí)候通過(guò)數(shù)據(jù)庫(kù)共享，有時(shí)候通過(guò)接口調(diào)用傳輸窍霞。接口調(diào)用關(guān)系雜亂匠题。
單個(gè)應(yīng)用為了給其他應(yīng)用提供接口，漸漸地越改越大但金，包含了很多本來(lái)就不屬于它的邏輯韭山。應(yīng)用邊界模糊，功能歸屬混亂冷溃。
管理后臺(tái)在一開(kāi)始的設(shè)計(jì)中保障級(jí)別較低钱磅。加入數(shù)據(jù)分析和促銷(xiāo)管理相關(guān)功能后出現(xiàn)性能瓶頸，影響了其他應(yīng)用似枕。
數(shù)據(jù)庫(kù)表結(jié)構(gòu)被多個(gè)應(yīng)用依賴(lài)盖淡，無(wú)法重構(gòu)和優(yōu)化。
所有應(yīng)用都在一個(gè)數(shù)據(jù)庫(kù)上操作凿歼，數(shù)據(jù)庫(kù)出現(xiàn)性能瓶頸褪迟。特別是數(shù)據(jù)分析跑起來(lái)的時(shí)候，數(shù)據(jù)庫(kù)性能急劇下降答憔。
開(kāi)發(fā)味赃、測(cè)試、部署虐拓、維護(hù)愈發(fā)困難心俗。即使只改動(dòng)一個(gè)小功能，也需要整個(gè)應(yīng)用一起發(fā)布蓉驹。有時(shí)候發(fā)布會(huì)不小心帶上了一些未經(jīng)測(cè)試的代碼城榛，或者修改了一個(gè)功能后，另一個(gè)意想不到的地方出錯(cuò)了戒幔。為了減輕發(fā)布可能產(chǎn)生的問(wèn)題的影響和線上業(yè)務(wù)停頓的影響吠谢，所有應(yīng)用都要在凌晨三四點(diǎn)執(zhí)行發(fā)布。發(fā)布后為了驗(yàn)證應(yīng)用正常運(yùn)行诗茎，還得盯到第二天白天的用戶高峰期……
團(tuán)隊(duì)出現(xiàn)推諉扯皮現(xiàn)象工坊。關(guān)于一些公用的功能應(yīng)該建設(shè)在哪個(gè)應(yīng)用上的問(wèn)題常常要爭(zhēng)論很久，最后要么干脆各做各的敢订，或者隨便放個(gè)地方但是都不維護(hù)王污。
盡管有著諸多問(wèn)題，但也不能否認(rèn)這一階段的成果：快速地根據(jù)業(yè)務(wù)變化建設(shè)了系統(tǒng)楚午。不過(guò)緊迫且繁重的任務(wù)容易使人陷入局部昭齐、短淺的思維方式，從而做出妥協(xié)式的決策矾柜。在這種架構(gòu)中阱驾，每個(gè)人都只關(guān)注在自己的一畝三分地就谜，缺乏全局的、長(zhǎng)遠(yuǎn)的設(shè)計(jì)里覆。長(zhǎng)此以往丧荐，系統(tǒng)建設(shè)將會(huì)越來(lái)越困難，甚至陷入不斷推翻喧枷、重建的循環(huán)虹统。
是時(shí)候做出改變了
幸好小明和小紅是有追求有理想的好青年。意識(shí)到問(wèn)題后隧甚，小明和小紅從瑣碎的業(yè)務(wù)需求中騰出了一部分精力车荔，開(kāi)始梳理整體架構(gòu)，針對(duì)問(wèn)題準(zhǔn)備著手改造戚扳。
要做改造忧便，首先你需要有足夠的精力和資源。如果你的需求方（業(yè)務(wù)人員咖城、項(xiàng)目經(jīng)理茬腿、上司等）很強(qiáng)勢(shì)地一心追求需求進(jìn)度呼奢，以致于你無(wú)法挪出額外的精力和資源的話宜雀，那么你可能無(wú)法做任何事……
在編程的世界中，最重要的便是抽象能力握础。微服務(wù)改造的過(guò)程實(shí)際上也是個(gè)抽象的過(guò)程辐董。小明和小紅整理了網(wǎng)上超市的業(yè)務(wù)邏輯，抽象出公用的業(yè)務(wù)能力禀综，做成幾個(gè)公共服務(wù)：
- 用戶服務(wù)
- 商品服務(wù)
- 促銷(xiāo)服務(wù)
- 訂單服務(wù)
- 數(shù)據(jù)分析服務(wù)
各個(gè)應(yīng)用后臺(tái)只需從這些服務(wù)獲取所需的數(shù)據(jù)简烘，從而刪去了大量冗余的代碼，就剩個(gè)輕薄的控制層和前端定枷。這一階段的架構(gòu)如下：
這個(gè)階段只是將服務(wù)分開(kāi)了孤澎，數(shù)據(jù)庫(kù)依然是共用的，所以一些煙囪式系統(tǒng)的缺點(diǎn)仍然存在：
數(shù)據(jù)庫(kù)成為性能瓶頸欠窒，并且有單點(diǎn)故障的風(fēng)險(xiǎn)覆旭。
數(shù)據(jù)管理趨向混亂。即使一開(kāi)始有良好的模塊化設(shè)計(jì)岖妄，隨著時(shí)間推移型将，總會(huì)有一個(gè)服務(wù)直接從數(shù)據(jù)庫(kù)取另一個(gè)服務(wù)的數(shù)據(jù)的現(xiàn)象。
數(shù)據(jù)庫(kù)表結(jié)構(gòu)可能被多個(gè)服務(wù)依賴(lài)荐虐，牽一發(fā)而動(dòng)全身七兜，很難調(diào)整。
如果一直保持共用數(shù)據(jù)庫(kù)的模式福扬，則整個(gè)架構(gòu)會(huì)越來(lái)越僵化腕铸，失去了微服務(wù)架構(gòu)的意義惜犀。因此小明和小紅一鼓作氣，把數(shù)據(jù)庫(kù)也拆分了狠裹。所有持久化層相互隔離向拆，由各個(gè)服務(wù)自己負(fù)責(zé)。另外酪耳，為了提高系統(tǒng)的實(shí)時(shí)性浓恳，加入了消息隊(duì)列機(jī)制。架構(gòu)如下：
完全拆分后各個(gè)服務(wù)可以采用異構(gòu)的技術(shù)碗暗。比如數(shù)據(jù)分析服務(wù)可以使用數(shù)據(jù)倉(cāng)庫(kù)作為持久化層颈将，以便于高效地做一些統(tǒng)計(jì)計(jì)算；商品服務(wù)和促銷(xiāo)服務(wù)訪問(wèn)頻率比較大言疗，因此加入了緩存機(jī)制等晴圾。
還有一種抽象出公共邏輯的方法是把這些公共邏輯做成公共的框架庫(kù)。這種方法可以減少服務(wù)調(diào)用的性能損耗噪奄。但是這種方法的管理成本非常高昂死姚，很難保證所有應(yīng)用版本的一致性。
數(shù)據(jù)庫(kù)拆分也有一些問(wèn)題和挑戰(zhàn)：比如說(shuō)跨庫(kù)級(jí)聯(lián)的需求勤篮，通過(guò)服務(wù)查詢(xún)數(shù)據(jù)顆粒度的粗細(xì)問(wèn)題等都毒。但是這些問(wèn)題可以通過(guò)合理的設(shè)計(jì)來(lái)解決∨龅蓿總體來(lái)說(shuō)账劲，數(shù)據(jù)庫(kù)拆分是一個(gè)利大于弊的。
微服務(wù)架構(gòu)還有一個(gè)技術(shù)外的好處金抡，它使整個(gè)系統(tǒng)的分工更加明確瀑焦，責(zé)任更加清晰，每個(gè)人專(zhuān)心負(fù)責(zé)為其他人提供更好的服務(wù)梗肝。在單體應(yīng)用的時(shí)代榛瓮，公共的業(yè)務(wù)功能經(jīng)常沒(méi)有明確的歸屬。最后要么各做各的巫击，每個(gè)人都重新實(shí)現(xiàn)了一遍禀晓；要么是隨機(jī)一個(gè)人（一般是能力比較強(qiáng)或者比較熱心的人）做到他負(fù)責(zé)的應(yīng)用里面。在后者的情況下喘鸟，這個(gè)人在負(fù)責(zé)自己應(yīng)用之外匆绣，還要額外負(fù)責(zé)給別人提供這些公共的功能 —— 而這個(gè)功能本來(lái)是無(wú)人負(fù)責(zé)的，僅僅因?yàn)樗芰^強(qiáng) / 比較熱心什黑，就莫名地背鍋（這種情況還被美其名曰能者多勞）崎淳。結(jié)果最后大家都不愿意提供公共的功能。長(zhǎng)此以往愕把，團(tuán)隊(duì)里的人漸漸變得各自為政拣凹，不再關(guān)心全局的架構(gòu)設(shè)計(jì)森爽。
從這個(gè)角度上看，使用微服務(wù)架構(gòu)同時(shí)也需要組織結(jié)構(gòu)做相應(yīng)的調(diào)整嚣镜。所以說(shuō)做微服務(wù)改造需要管理者的支持爬迟。
改造完成后，小明和小紅分清楚各自的鍋菊匿。兩人十分滿意付呕，一切就像是麥克斯韋方程組一樣漂亮完美。
然而……
沒(méi)有銀彈
春天來(lái)了跌捆，萬(wàn)物復(fù)蘇徽职，又到了一年一度的購(gòu)物狂歡節(jié)。眼看著日訂單數(shù)量蹭蹭地上漲佩厚，小皮小明小紅喜笑顏開(kāi)姆钉。可惜好景不長(zhǎng)抄瓦，樂(lè)極生悲潮瓶，突然嘣的一下，系統(tǒng)掛了钙姊。
以往單體應(yīng)用毯辅，排查問(wèn)題通常是看一下日志，研究錯(cuò)誤信息和調(diào)用堆棧摸恍。而微服務(wù)架構(gòu)整個(gè)應(yīng)用分散成多個(gè)服務(wù)悉罕，定位故障點(diǎn)非常困難赤屋。小明一個(gè)臺(tái)機(jī)器一臺(tái)機(jī)器地查看日志立镶，一個(gè)服務(wù)一個(gè)服務(wù)地手工調(diào)用。經(jīng)過(guò)十幾分鐘的查找类早，小明終于定位到故障點(diǎn)：促銷(xiāo)服務(wù)由于接收的請(qǐng)求量太大而停止響應(yīng)了媚媒。其他服務(wù)都直接或間接地會(huì)調(diào)用促銷(xiāo)服務(wù)，于是也跟著宕機(jī)了涩僻。在微服務(wù)架構(gòu)中缭召，一個(gè)服務(wù)故障可能會(huì)產(chǎn)生雪崩效用，導(dǎo)致整個(gè)系統(tǒng)故障逆日。其實(shí)在節(jié)前嵌巷，小明和小紅是有做過(guò)請(qǐng)求量評(píng)估的。按照預(yù)計(jì)室抽，服務(wù)器資源是足以支持節(jié)日的請(qǐng)求量的搪哪，所以肯定是哪里出了問(wèn)題。不過(guò)形勢(shì)緊急坪圾，隨著每一分每一秒流逝的都是白花花的銀子晓折，因此小明也沒(méi)時(shí)間排查問(wèn)題惑朦，當(dāng)機(jī)立斷在云上新建了幾臺(tái)虛擬機(jī)，然后一臺(tái)一臺(tái)地部署新的促銷(xiāo)服務(wù)節(jié)點(diǎn)漓概。幾分鐘的操作后漾月，系統(tǒng)總算是勉強(qiáng)恢復(fù)正常了。整個(gè)故障時(shí)間內(nèi)估計(jì)損失了幾十萬(wàn)的銷(xiāo)售額胃珍，三人的心在滴血……
事后梁肿，小明簡(jiǎn)單寫(xiě)了個(gè)日志分析工具（量太大了，文本編輯器幾乎打不開(kāi)觅彰，打開(kāi)了肉眼也看不過(guò)來(lái)）栈雳，統(tǒng)計(jì)了促銷(xiāo)服務(wù)的訪問(wèn)日志，發(fā)現(xiàn)在故障期間缔莲，商品服務(wù)由于代碼問(wèn)題哥纫，在某些場(chǎng)景下會(huì)對(duì)促銷(xiāo)服務(wù)發(fā)起大量請(qǐng)求。這個(gè)問(wèn)題并不復(fù)雜痴奏，小明手指抖一抖蛀骇，修復(fù)了這個(gè)價(jià)值幾十萬(wàn)的 Bug。
問(wèn)題是解決了读拆，但誰(shuí)也無(wú)法保證不會(huì)再發(fā)生類(lèi)似的其他問(wèn)題擅憔。微服務(wù)架構(gòu)雖然邏輯設(shè)計(jì)上看是完美的，但就像積木搭建的華麗宮殿一樣檐晕，經(jīng)不起風(fēng)吹草動(dòng)暑诸。微服務(wù)架構(gòu)雖然解決了舊問(wèn)題，也引入了新的問(wèn)題：
微服務(wù)架構(gòu)整個(gè)應(yīng)用分散成多個(gè)服務(wù)辟灰，定位故障點(diǎn)非常困難个榕。
穩(wěn)定性下降。服務(wù)數(shù)量變多導(dǎo)致其中一個(gè)服務(wù)出現(xiàn)故障的概率增大芥喇，并且一個(gè)服務(wù)故障可能導(dǎo)致整個(gè)系統(tǒng)掛掉西采。事實(shí)上，在大訪問(wèn)量的生產(chǎn)場(chǎng)景下继控，故障總是會(huì)出現(xiàn)的械馆。
服務(wù)數(shù)量非常多，部署武通、管理的工作量很大霹崎。
開(kāi)發(fā)方面：如何保證各個(gè)服務(wù)在持續(xù)開(kāi)發(fā)的情況下仍然保持協(xié)同合作。
測(cè)試方面：服務(wù)拆分后冶忱，幾乎所有功能都會(huì)涉及多個(gè)服務(wù)尾菇。原本單個(gè)程序的測(cè)試變?yōu)榉?wù)間調(diào)用的測(cè)試。測(cè)試變得更加復(fù)雜。
小明小紅痛定思痛错沽，決心好好解決這些問(wèn)題簿晓。對(duì)故障的處理一般從兩方面入手，一方面盡量減少故障發(fā)生的概率千埃，另一方面降低故障造成的影響憔儿。
監(jiān)控 - 發(fā)現(xiàn)故障的征兆
在高并發(fā)分布式的場(chǎng)景下，故障經(jīng)常是突然間就雪崩式爆發(fā)放可。所以必須建立完善的監(jiān)控體系谒臼，盡可能發(fā)現(xiàn)故障的征兆。
微服務(wù)架構(gòu)中組件繁多耀里，各個(gè)組件所需要監(jiān)控的指標(biāo)不同蜈缤。比如 Redis 緩存一般監(jiān)控占用內(nèi)存值、網(wǎng)絡(luò)流量冯挎，數(shù)據(jù)庫(kù)監(jiān)控連接數(shù)底哥、磁盤(pán)空間，業(yè)務(wù)服務(wù)監(jiān)控并發(fā)數(shù)房官、響應(yīng)延遲趾徽、錯(cuò)誤率等。因此如果做一個(gè)大而全的監(jiān)控系統(tǒng)來(lái)監(jiān)控各個(gè)組件是不大現(xiàn)實(shí)的翰守，而且擴(kuò)展性會(huì)很差孵奶。一般的做法是讓各個(gè)組件提供報(bào)告自己當(dāng)前狀態(tài)的接口（metrics 接口），這個(gè)接口輸出的數(shù)據(jù)格式應(yīng)該是一致的蜡峰。然后部署一個(gè)指標(biāo)采集器組件了袁，定時(shí)從這些接口獲取并保持組件狀態(tài)，同時(shí)提供查詢(xún)服務(wù)湿颅。最后還需要一個(gè) UI载绿，從指標(biāo)采集器查詢(xún)各項(xiàng)指標(biāo)，繪制監(jiān)控界面或者根據(jù)閾值發(fā)出告警肖爵。
大部分組件都不需要自己動(dòng)手開(kāi)發(fā)卢鹦，網(wǎng)絡(luò)上有開(kāi)源組件。小明下載了 RedisExporter 和 MySQLExporter劝堪，這兩個(gè)組件分別提供了 Redis 緩存和 MySQL 數(shù)據(jù)庫(kù)的指標(biāo)接口。微服務(wù)則根據(jù)各個(gè)服務(wù)的業(yè)務(wù)邏輯實(shí)現(xiàn)自定義的指標(biāo)接口揉稚。然后小明采用 Prometheus 作為指標(biāo)采集器秒啦，Grafana 配置監(jiān)控界面和郵件告警。這樣一套微服務(wù)監(jiān)控系統(tǒng)就搭建起來(lái)了：
定位問(wèn)題 - 鏈路跟蹤
在微服務(wù)架構(gòu)下搀玖，一個(gè)用戶的請(qǐng)求往往涉及多個(gè)內(nèi)部服務(wù)調(diào)用余境。為了方便定位問(wèn)題，需要能夠記錄每個(gè)用戶請(qǐng)求時(shí)，微服務(wù)內(nèi)部產(chǎn)生了多少服務(wù)調(diào)用芳来，及其調(diào)用關(guān)系含末。這個(gè)叫做鏈路跟蹤。
我們用一個(gè) Istio 文檔里的鏈路跟蹤例子來(lái)看看效果：
圖片來(lái)自 Istio 文檔
從圖中可以看到即舌，這是一個(gè)用戶訪問(wèn) productpage 頁(yè)面的請(qǐng)求佣盒。在請(qǐng)求過(guò)程中，productpage 服務(wù)順序調(diào)用了 details 和 reviews 服務(wù)的接口顽聂。而 reviews 服務(wù)在響應(yīng)過(guò)程中又調(diào)用了 ratings 的接口肥惭。整個(gè)鏈路跟蹤的記錄是一棵樹(shù)：
要實(shí)現(xiàn)鏈路跟蹤，每次服務(wù)調(diào)用會(huì)在 HTTP 的 HEADERS 中記錄至少記錄四項(xiàng)數(shù)據(jù)：
traceId：traceId 標(biāo)識(shí)一個(gè)用戶請(qǐng)求的調(diào)用鏈路紊搪。具有相同 traceId 的調(diào)用屬于同一條鏈路蜜葱。
spanId：標(biāo)識(shí)一次服務(wù)調(diào)用的 ID，即鏈路跟蹤的節(jié)點(diǎn) ID耀石。
parentId：父節(jié)點(diǎn)的 spanId牵囤。
requestTime & responseTime：請(qǐng)求時(shí)間和響應(yīng)時(shí)間。
另外滞伟，還需要調(diào)用日志收集與存儲(chǔ)的組件奔浅，以及展示鏈路調(diào)用的 UI 組件。
以上只是一個(gè)極簡(jiǎn)的說(shuō)明诗良，關(guān)于鏈路跟蹤的理論依據(jù)可詳見(jiàn) Google 的 Dapper
了解了理論基礎(chǔ)后汹桦，小明選用了 Dapper 的一個(gè)開(kāi)源實(shí)現(xiàn) Zipkin。然后手指一抖鉴裹，寫(xiě)了個(gè) HTTP 請(qǐng)求的攔截器舞骆，在每次 HTTP 請(qǐng)求時(shí)生成這些數(shù)據(jù)注入到 HEADERS，同時(shí)異步發(fā)送調(diào)用日志到 Zipkin 的日志收集器中径荔。這里額外提一下督禽，HTTP 請(qǐng)求的攔截器，可以在微服務(wù)的代碼中實(shí)現(xiàn)总处，也可以使用一個(gè)網(wǎng)絡(luò)代理組件來(lái)實(shí)現(xiàn)（不過(guò)這樣子每個(gè)微服務(wù)都需要加一層代理）狈惫。
鏈路跟蹤只能定位到哪個(gè)服務(wù)出現(xiàn)問(wèn)題，不能提供具體的錯(cuò)誤信息鹦马。查找具體的錯(cuò)誤信息的能力則需要由日志分析組件來(lái)提供胧谈。
分析問(wèn)題 - 日志分析
日志分析組件應(yīng)該在微服務(wù)興起之前就被廣泛使用了。即使單體應(yīng)用架構(gòu)荸频，當(dāng)訪問(wèn)數(shù)變大菱肖、或服務(wù)器規(guī)模增多時(shí)，日志文件的大小會(huì)膨脹到難以用文本編輯器進(jìn)行訪問(wèn)旭从，更糟的是它們分散在多臺(tái)服務(wù)器上面稳强。排查一個(gè)問(wèn)題场仲，需要登錄到各臺(tái)服務(wù)器去獲取日志文件，一個(gè)一個(gè)地查找（而且打開(kāi)退疫、查找都很慢）想要的日志信息渠缕。
因此，在應(yīng)用規(guī)模變大時(shí)褒繁，我們需要一個(gè)日志的 “搜索引擎”亦鳞。以便于能準(zhǔn)確的找到想要的日志。另外澜汤，數(shù)據(jù)源一側(cè)還需要收集日志的組件和展示結(jié)果的 UI 組件：
小明調(diào)查了一下蚜迅，使用了大名鼎鼎地 ELK 日志分析組件。ELK 是 Elasticsearch俊抵、Logstash 和 Kibana 三個(gè)組件的縮寫(xiě)谁不。
- Elasticsearch：搜索引擎，同時(shí)也是日志的存儲(chǔ)徽诲。
- Logstash：日志采集器刹帕，它接收日志輸入，對(duì)日志進(jìn)行一些預(yù)處理谎替，然后輸出到 Elasticsearch偷溺。
- Kibana：UI 組件，通過(guò) Elasticsearch 的 API 查找數(shù)據(jù)并展示給用戶钱贯。
最后還有一個(gè)小問(wèn)題是如何將日志發(fā)送到 Logstash挫掏。一種方案是在日志輸出的時(shí)候直接調(diào)用 Logstash 接口將日志發(fā)送過(guò)去。這樣一來(lái)又（咦秩命，為啥要用 “又”）要修改代碼…… 于是小明選用了另一種方案：日志仍然輸出到文件尉共，每個(gè)服務(wù)里再部署個(gè) Agent 掃描日志文件然后輸出給 Logstash。
網(wǎng)關(guān) - 權(quán)限控制弃锐，服務(wù)治理
拆分成微服務(wù)后袄友，出現(xiàn)大量的服務(wù)，大量的接口霹菊，使得整個(gè)調(diào)用關(guān)系亂糟糟的剧蚣。經(jīng)常在開(kāi)發(fā)過(guò)程中，寫(xiě)著寫(xiě)著旋廷，忽然想不起某個(gè)數(shù)據(jù)應(yīng)該調(diào)用哪個(gè)服務(wù)鸠按。或者寫(xiě)歪了柳洋，調(diào)用了不該調(diào)用的服務(wù)待诅，本來(lái)一個(gè)只讀的功能結(jié)果修改了數(shù)據(jù)……
為了應(yīng)對(duì)這些情況，微服務(wù)的調(diào)用需要一個(gè)把關(guān)的東西熊镣，也就是網(wǎng)關(guān)。在調(diào)用者和被調(diào)用者中間加一層網(wǎng)關(guān)，每次調(diào)用時(shí)進(jìn)行權(quán)限校驗(yàn)绪囱。另外测蹲，網(wǎng)關(guān)也可以作為一個(gè)提供服務(wù)接口文檔的平臺(tái)。
使用網(wǎng)關(guān)有一個(gè)問(wèn)題就是要決定在多大粒度上使用：最粗粒度的方案是整個(gè)微服務(wù)一個(gè)網(wǎng)關(guān)鬼吵，微服務(wù)外部通過(guò)網(wǎng)關(guān)訪問(wèn)微服務(wù)扣甲，微服務(wù)內(nèi)部則直接調(diào)用；最細(xì)粒度則是所有調(diào)用齿椅，不管是微服務(wù)內(nèi)部調(diào)用或者來(lái)自外部的調(diào)用琉挖，都必須通過(guò)網(wǎng)關(guān)。折中的方案是按照業(yè)務(wù)領(lǐng)域?qū)⑽⒎?wù)分成幾個(gè)區(qū)涣脚，區(qū)內(nèi)直接調(diào)用示辈，區(qū)間通過(guò)網(wǎng)關(guān)調(diào)用。
由于整個(gè)網(wǎng)上超市的服務(wù)數(shù)量還不算特別多遣蚀，小明采用的最粗粒度的方案：
服務(wù)注冊(cè)與發(fā)現(xiàn) - 動(dòng)態(tài)擴(kuò)容
前面的組件矾麻，都是旨在降低故障發(fā)生的可能性。然而故障總是會(huì)發(fā)生的芭梯，所以另一個(gè)需要研究的是如何降低故障產(chǎn)生的影響险耀。
最粗暴的（也是最常用的）故障處理策略就是冗余。一般來(lái)說(shuō)玖喘，一個(gè)服務(wù)都會(huì)部署多個(gè)實(shí)例甩牺，這樣一來(lái)能夠分擔(dān)壓力提高性能，二來(lái)即使一個(gè)實(shí)例掛了其他實(shí)例還能響應(yīng)累奈。
冗余的一個(gè)問(wèn)題是使用幾個(gè)冗余贬派？這個(gè)問(wèn)題在時(shí)間軸上并沒(méi)有一個(gè)切確的答案。根據(jù)服務(wù)功能费尽、時(shí)間段的不同赠群，需要不同數(shù)量的實(shí)例。比如在平日里旱幼，可能 4 個(gè)實(shí)例已經(jīng)夠用查描；而在促銷(xiāo)活動(dòng)時(shí)，流量大增柏卤，可能需要 40 個(gè)實(shí)例冬三。因此冗余數(shù)量并不是一個(gè)固定的值，而是根據(jù)需要實(shí)時(shí)調(diào)整的缘缚。
一般來(lái)說(shuō)新增實(shí)例的操作為：
- 部署新實(shí)例
- 將新實(shí)例注冊(cè)到負(fù)載均衡或 DNS 上
操作只有兩步勾笆，但如果注冊(cè)到負(fù)載均衡或 DNS 的操作為人工操作的話，那事情就不簡(jiǎn)單了桥滨。想想新增 40 個(gè)實(shí)例后窝爪，要手工輸入 40 個(gè) IP 的感覺(jué)……
解決這個(gè)問(wèn)題的方案是服務(wù)自動(dòng)注冊(cè)與發(fā)現(xiàn)弛车。首先，需要部署一個(gè)服務(wù)發(fā)現(xiàn)服務(wù)蒲每，它提供所有已注冊(cè)服務(wù)的地址信息的服務(wù)纷跛。DNS 也算是一種服務(wù)發(fā)現(xiàn)服務(wù)。然后各個(gè)應(yīng)用服務(wù)在啟動(dòng)時(shí)自動(dòng)將自己注冊(cè)到服務(wù)發(fā)現(xiàn)服務(wù)上邀杏。并且應(yīng)用服務(wù)啟動(dòng)后會(huì)實(shí)時(shí)（定期）從服務(wù)發(fā)現(xiàn)服務(wù)同步各個(gè)應(yīng)用服務(wù)的地址列表到本地贫奠。服務(wù)發(fā)現(xiàn)服務(wù)也會(huì)定期檢查應(yīng)用服務(wù)的健康狀態(tài)，去掉不健康的實(shí)例地址望蜡。這樣新增實(shí)例時(shí)只需要部署新實(shí)例唤崭，實(shí)例下線時(shí)直接關(guān)停服務(wù)即可，服務(wù)發(fā)現(xiàn)會(huì)自動(dòng)檢查服務(wù)實(shí)例的增減脖律。
服務(wù)發(fā)現(xiàn)還會(huì)跟客戶端負(fù)載均衡配合使用谢肾。由于應(yīng)用服務(wù)已經(jīng)同步服務(wù)地址列表在本地了，所以訪問(wèn)微服務(wù)時(shí)状您，可以自己決定負(fù)載策略勒叠。甚至可以在服務(wù)注冊(cè)時(shí)加入一些元數(shù)據(jù)（服務(wù)版本等信息），客戶端負(fù)載則根據(jù)這些元數(shù)據(jù)進(jìn)行流量控制膏孟，實(shí)現(xiàn) A/B 測(cè)試眯分、藍(lán)綠發(fā)布等功能。
服務(wù)發(fā)現(xiàn)有很多組件可以選擇柒桑，比如說(shuō) Zookeeper 弊决、Eureka、Consul魁淳、Etcd 等飘诗。不過(guò)小明覺(jué)得自己水平不錯(cuò)，想炫技界逛，于是基于 Redis 自己寫(xiě)了一個(gè)……
熔斷昆稿、服務(wù)降級(jí)、限流
熔斷
當(dāng)一個(gè)服務(wù)因?yàn)楦鞣N原因停止響應(yīng)時(shí)息拜，調(diào)用方通常會(huì)等待一段時(shí)間溉潭，然后超時(shí)或者收到錯(cuò)誤返回。如果調(diào)用鏈路比較長(zhǎng)少欺，可能會(huì)導(dǎo)致請(qǐng)求堆積喳瓣，整條鏈路占用大量資源一直在等待下游響應(yīng)。所以當(dāng)多次訪問(wèn)一個(gè)服務(wù)失敗時(shí)赞别，應(yīng)熔斷畏陕，標(biāo)記該服務(wù)已停止工作，直接返回錯(cuò)誤仿滔。直至該服務(wù)恢復(fù)正常后再重新建立連接惠毁。
圖片來(lái)自《微服務(wù)設(shè)計(jì)》
服務(wù)降級(jí)
當(dāng)下游服務(wù)停止工作后犹芹，如果該服務(wù)并非核心業(yè)務(wù)，則上游服務(wù)應(yīng)該降級(jí)仁讨，以保證核心業(yè)務(wù)不中斷羽莺。比如網(wǎng)上超市下單界面有一個(gè)推薦商品湊單的功能实昨，當(dāng)推薦模塊掛了后洞豁，下單功能不能一起掛掉，只需要暫時(shí)關(guān)閉推薦功能即可荒给。
限流
一個(gè)服務(wù)掛掉后丈挟，上游服務(wù)或者用戶一般會(huì)習(xí)慣性地重試訪問(wèn)。這導(dǎo)致一旦服務(wù)恢復(fù)正常志电，很可能因?yàn)樗查g網(wǎng)絡(luò)流量過(guò)大又立刻掛掉曙咽，在棺材里重復(fù)著仰臥起坐。因此服務(wù)需要能夠自我保護(hù) —— 限流挑辆。限流策略有很多例朱，最簡(jiǎn)單的比如當(dāng)單位時(shí)間內(nèi)請(qǐng)求數(shù)過(guò)多時(shí)，丟棄多余的請(qǐng)求鱼蝉。另外洒嗤，也可以考慮分區(qū)限流。僅拒絕來(lái)自產(chǎn)生大量請(qǐng)求的服務(wù)的請(qǐng)求魁亦。例如商品服務(wù)和訂單服務(wù)都需要訪問(wèn)促銷(xiāo)服務(wù)渔隶，商品服務(wù)由于代碼問(wèn)題發(fā)起了大量請(qǐng)求，促銷(xiāo)服務(wù)則只限制來(lái)自商品服務(wù)的請(qǐng)求洁奈，來(lái)自訂單服務(wù)的請(qǐng)求則正常響應(yīng)间唉。
測(cè)試
微服務(wù)架構(gòu)下蘸劈，測(cè)試分為三個(gè)層次：
- 端到端測(cè)試：覆蓋整個(gè)系統(tǒng)托猩，一般在用戶界面機(jī)型測(cè)試。
- 服務(wù)測(cè)試：針對(duì)服務(wù)接口進(jìn)行測(cè)試汉额。
- 單元測(cè)試：針對(duì)代碼單元進(jìn)行測(cè)試印叁。
三種測(cè)試從上到下實(shí)施的容易程度遞增被冒，但是測(cè)試效果遞減。端到端測(cè)試最費(fèi)時(shí)費(fèi)力喉钢，但是通過(guò)測(cè)試后我們對(duì)系統(tǒng)最有信心姆打。單元測(cè)試最容易實(shí)施，效率也最高肠虽，但是測(cè)試后不能保證整個(gè)系統(tǒng)沒(méi)有問(wèn)題幔戏。
由于端到端測(cè)試實(shí)施難度較大，一般只對(duì)核心功能做端到端測(cè)試税课。一旦端到端測(cè)試失敗闲延，則需要將其分解到單元測(cè)試：則分析失敗原因痊剖，然后編寫(xiě)單元測(cè)試來(lái)重現(xiàn)這個(gè)問(wèn)題，這樣未來(lái)我們便可以更快地捕獲同樣的錯(cuò)誤垒玲。
服務(wù)測(cè)試的難度在于服務(wù)會(huì)經(jīng)常依賴(lài)一些其他服務(wù)陆馁。這個(gè)問(wèn)題可以通過(guò) Mock Server 解決：
單元測(cè)試大家都很熟悉了。我們一般會(huì)編寫(xiě)大量的單元測(cè)試（包括回歸測(cè)試）盡量覆蓋所有代碼合愈。
微服務(wù)框架
指標(biāo)接口叮贩、鏈路跟蹤注入、日志引流佛析、服務(wù)注冊(cè)發(fā)現(xiàn)益老、路由規(guī)則等組件以及熔斷、限流等功能都需要在應(yīng)用服務(wù)上添加一些對(duì)接代碼寸莫。如果讓每個(gè)應(yīng)用服務(wù)自己實(shí)現(xiàn)是非常耗時(shí)耗力的捺萌。基于 DRY 的原則膘茎，小明開(kāi)發(fā)了一套微服務(wù)框架桃纯，將與各個(gè)組件對(duì)接的代碼和另外一些公共代碼抽離到框架中，所有的應(yīng)用服務(wù)都統(tǒng)一使用這套框架進(jìn)行開(kāi)發(fā)披坏。
使用微服務(wù)框架可以實(shí)現(xiàn)很多自定義的功能态坦。甚至可以將程序調(diào)用堆棧信息注入到鏈路跟蹤，實(shí)現(xiàn)代碼級(jí)別的鏈路跟蹤刮萌⊥耘洌或者輸出線程池、連接池的狀態(tài)信息着茸，實(shí)時(shí)監(jiān)控服務(wù)底層狀態(tài)壮锻。
使用統(tǒng)一的微服務(wù)框架有一個(gè)比較嚴(yán)重的問(wèn)題：框架更新成本很高。每次框架升級(jí)涮阔，都需要所有應(yīng)用服務(wù)配合升級(jí)猜绣。當(dāng)然，一般會(huì)使用兼容方案敬特，留出一段并行時(shí)間等待所有應(yīng)用服務(wù)升級(jí)掰邢。但是如果應(yīng)用服務(wù)非常多時(shí)，升級(jí)時(shí)間可能會(huì)非常漫長(zhǎng)伟阔。并且有一些很穩(wěn)定幾乎不更新的應(yīng)用服務(wù)辣之，其負(fù)責(zé)人可能會(huì)拒絕升級(jí)…… 因此，使用統(tǒng)一微服務(wù)框架需要完善的版本管理方法和開(kāi)發(fā)管理規(guī)范皱炉。
另一條路 - Service Mesh
另一種抽象公共代碼的方法是直接將這些代碼抽象到一個(gè)反向代理組件怀估。每個(gè)服務(wù)都額外部署這個(gè)代理組件，所有出站入站的流量都通過(guò)該組件進(jìn)行處理和轉(zhuǎn)發(fā)。這個(gè)組件被稱(chēng)為 Sidecar多搀。
Sidecar 不會(huì)產(chǎn)生額外網(wǎng)絡(luò)成本歧蕉。Sidecar 會(huì)和微服務(wù)節(jié)點(diǎn)部署在同一臺(tái)主機(jī)上并且共用相同的虛擬網(wǎng)卡。所以 sidecar 和微服務(wù)節(jié)點(diǎn)的通信實(shí)際上都只是通過(guò)內(nèi)存拷貝實(shí)現(xiàn)的康铭。
圖片來(lái)自：Pattern: Service Mesh
Sidecar 只負(fù)責(zé)網(wǎng)絡(luò)通信惯退。還需要有個(gè)組件來(lái)統(tǒng)一管理所有 sidecar 的配置。在 Service Mesh 中从藤，負(fù)責(zé)網(wǎng)絡(luò)通信的部分叫數(shù)據(jù)平面（data plane）催跪，負(fù)責(zé)配置管理的部分叫控制平面（control plane）。數(shù)據(jù)平面和控制平面構(gòu)成了 Service Mesh 的基本架構(gòu)呛哟。
圖片來(lái)自：Pattern: Service Mesh
Sevice Mesh 相比于微服務(wù)框架的優(yōu)點(diǎn)在于它不侵入代碼叠荠，升級(jí)和維護(hù)更方便。它經(jīng)常被詬病的則是性能問(wèn)題扫责。即使回環(huán)網(wǎng)絡(luò)不會(huì)產(chǎn)生實(shí)際的網(wǎng)絡(luò)請(qǐng)求，但仍然有內(nèi)存拷貝的額外成本逃呼。另外有一些集中式的流量處理也會(huì)影響性能鳖孤。
結(jié)束、也是開(kāi)始
微服務(wù)不是架構(gòu)演變的終點(diǎn)抡笼。往細(xì)走還有 Serverless苏揣、FaaS 等方向。另一方面也有人在唱合久必分分久必合推姻，重新發(fā)現(xiàn)單體架構(gòu)……
不管怎樣平匈，微服務(wù)架構(gòu)的改造暫時(shí)告一段落了。小明滿足地摸了摸日益光滑的腦袋藏古，打算這個(gè)周末休息一下約小紅喝杯咖啡增炭。
