隨著網(wǎng)站規(guī)模越來越大，單體應(yīng)用往往很難再滿足要求，就需要向分布式，微服務(wù)架構(gòu)演變。 那么這個(gè)演變過程是怎么樣的呢？都涉及到哪些組件，會(huì)遇到哪些問題，以及相應(yīng)的解決方案都是什么，本篇文章就來回答這些問題。 本文將介紹微服務(wù)架構(gòu)和相關(guān)的組件，介紹他們是什么以及為什么要使用微服務(wù)架構(gòu)和這些組件。 本文側(cè)重于簡明地表達(dá)微服務(wù)架構(gòu)的全局圖景，因此不會(huì)涉及具體如何使用組件等細(xì)節(jié)。 要理解微服務(wù)，首先要先理解不是微服務(wù)的那些。通常跟微服務(wù)相對(duì)的是單體應(yīng)用，即將所有功能都打包成在一個(gè)獨(dú)立單元的應(yīng)用程序。 從單體應(yīng)用到微服務(wù)并不是一蹴而就的，這是一個(gè)逐漸演變的過程。 本文將以一個(gè)網(wǎng)上超市應(yīng)用為例來說明這一過程。

最初的需求

幾年前，小明和小皮一起創(chuàng)業(yè)做網(wǎng)上超市，小明負(fù)責(zé)程序開發(fā)，小皮負(fù)責(zé)其他事宜。當(dāng)時(shí)互聯(lián)網(wǎng)還不發(fā)達(dá)，網(wǎng)上超市還是藍(lán)海。只要功能實(shí)現(xiàn)了就能隨便賺錢。

所以他們的需求很簡單，只需要一個(gè)網(wǎng)站掛在公網(wǎng)，用戶能夠在這個(gè)網(wǎng)站上瀏覽商品、購買商品；另外還需一個(gè)管理后臺(tái)，可以管理商品、用戶、以及訂單數(shù)據(jù)。

我們整理一下功能清單：

網(wǎng)站

用戶注冊(cè)、登錄功能

商品展示

下單

管理后臺(tái)

用戶管理

商品管理

訂單管理

由于需求簡單，小明左手右手一個(gè)慢動(dòng)作，網(wǎng)站就做好了。 管理后臺(tái)出于安全考慮，不和網(wǎng)站做在一起，小明右手左手慢動(dòng)作重播，管理網(wǎng)站也做好了。 總體架構(gòu)圖如下：

小明揮一揮手，找了家云服務(wù)部署上去，網(wǎng)站就上線了。上線后好評(píng)如潮，深受各類肥宅喜愛。小明小皮美滋滋地開始躺著收錢。

隨著業(yè)務(wù)發(fā)展

好景不長，沒過幾天，各類網(wǎng)上超市緊跟著拔地而起，對(duì)小明小皮造成了強(qiáng)烈的沖擊。 在競(jìng)爭(zhēng)的壓力下，小明小皮決定開展一些營銷手段：

開展促銷活動(dòng)。比如元旦全場(chǎng)打折，春節(jié)買二送一，情人節(jié)狗糧優(yōu)惠券等等。

拓展渠道，新增移動(dòng)端營銷。除了網(wǎng)站外，還需要開發(fā)移動(dòng)端APP，微信小程序等。

精準(zhǔn)營銷。利用歷史數(shù)據(jù)對(duì)用戶進(jìn)行分析，提供個(gè)性化服務(wù)。

這些活動(dòng)都需要程序開發(fā)的支持，小明拉了同學(xué)小紅加入團(tuán)隊(duì)。小紅負(fù)責(zé)數(shù)據(jù)分析以及移動(dòng)端相關(guān)開發(fā)，小明負(fù)責(zé)促銷活動(dòng)相關(guān)功能的開發(fā)。 因?yàn)殚_發(fā)任務(wù)比較緊迫，小明小紅沒有好好規(guī)劃整個(gè)系統(tǒng)的架構(gòu)，隨便拍了拍腦袋，決定把促銷管理和數(shù)據(jù)分析放在管理后臺(tái)里，微信和移動(dòng)端 APP 另外搭建。通宵了幾天后，新功能和新應(yīng)用基本完工。 這時(shí)架構(gòu)圖如下：

這一階段存在很多不合理的地方：

網(wǎng)站和移動(dòng)端應(yīng)用有很多相同業(yè)務(wù)邏輯的重復(fù)代碼。

數(shù)據(jù)有時(shí)候通過數(shù)據(jù)庫共享，有時(shí)候通過接口調(diào)用傳輸。接口調(diào)用關(guān)系雜亂。

單個(gè)應(yīng)用為了給其他應(yīng)用提供接口，漸漸地越改越大，包含了很多本來就不屬于它的邏輯。應(yīng)用邊界模糊，功能歸屬混亂。

管理后臺(tái)在一開始的設(shè)計(jì)中保障級(jí)別較低。加入數(shù)據(jù)分析和促銷管理相關(guān)功能后出現(xiàn)性能瓶頸，影響了其他應(yīng)用。

數(shù)據(jù)庫表結(jié)構(gòu)被多個(gè)應(yīng)用依賴，無法重構(gòu)和優(yōu)化。

所有應(yīng)用都在一個(gè)數(shù)據(jù)庫上操作，數(shù)據(jù)庫出現(xiàn)性能瓶頸。特別是數(shù)據(jù)分析跑起來的時(shí)候，數(shù)據(jù)庫性能急劇下降。

開發(fā)、測(cè)試、部署、維護(hù)愈發(fā)困難。即使只改動(dòng)一個(gè)小功能，也需要整個(gè)應(yīng)用一起發(fā)布。有時(shí)候發(fā)布會(huì)不小心帶上了一些未經(jīng)測(cè)試的代碼，或者修改了一個(gè)功能后，另一個(gè)意想不到的地方出錯(cuò)了。為了減輕發(fā)布可能產(chǎ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)用上的問題常常要爭(zhēng)論很久，最后要么干脆各做各的，或者隨便放個(gè)地方但是都不維護(hù)。

盡管有著諸多問題，但也不能否認(rèn)這一階段的成果：快速地根據(jù)業(yè)務(wù)變化建設(shè)了系統(tǒng)。不過緊迫且繁重的任務(wù)容易使人陷入局部、短淺的思維方式，從而做出妥協(xié)式的決策。 在這種架構(gòu)中，每個(gè)人都只關(guān)注在自己的一畝三分地，缺乏全局的、長遠(yuǎn)的設(shè)計(jì)。長此以往，系統(tǒng)建設(shè)將會(huì)越來越困難，甚至陷入不斷推翻、重建的循環(huán)。

是時(shí)候做出改變了

幸好小明和小紅是有追求有理想的好青年。意識(shí)到問題后，小明和小紅從瑣碎的業(yè)務(wù)需求中騰出了一部分精力，開始梳理整體架構(gòu)，針對(duì)問題準(zhǔn)備著手改造。

要做改造，首先你需要有足夠的精力和資源。如果你的需求方（業(yè)務(wù)人員、項(xiàng)目經(jīng)理、上司等）很強(qiáng)勢(shì)地一心追求需求進(jìn)度，以致于你無法挪出額外的精力和資源的話，那么你可能無法做任何事

在編程的世界中，最重要的便是抽象能力。微服務(wù)改造的過程實(shí)際上也是個(gè)抽象的過程。 小明和小紅整理了網(wǎng)上超市的業(yè)務(wù)邏輯，抽象出公用的業(yè)務(wù)能力，做成幾個(gè)公共服務(wù)：

用戶服務(wù)

商品服務(wù)

促銷服務(wù)

訂單服務(wù)

數(shù)據(jù)分析服務(wù)

各個(gè)應(yīng)用后臺(tái)只需從這些服務(wù)獲取所需的數(shù)據(jù)，從而刪去了大量冗余的代碼，就剩個(gè)輕薄的控制層和前端。 這一階段的架構(gòu)如下：

這個(gè)階段只是將服務(wù)分開了，數(shù)據(jù)庫依然是共用的，所以一些煙囪式系統(tǒng)的缺點(diǎn)仍然存在：

數(shù)據(jù)庫成為性能瓶頸，并且有單點(diǎn)故障的風(fēng)險(xiǎn)。

數(shù)據(jù)管理趨向混亂。即使一開始有良好的模塊化設(shè)計(jì)，隨著時(shí)間推移，總會(huì)有一個(gè)服務(wù)直接從數(shù)據(jù)庫取另一個(gè)服務(wù)的數(shù)據(jù)的現(xiàn)象。

數(shù)據(jù)庫表結(jié)構(gòu)可能被多個(gè)服務(wù)依賴，牽一發(fā)而動(dòng)全身，很難調(diào)整。

如果一直保持共用數(shù)據(jù)庫的模式，則整個(gè)架構(gòu)會(huì)越來越僵化，失去了微服務(wù)架構(gòu)的意義。 因此小明和小紅一鼓作氣，把數(shù)據(jù)庫也拆分了。所有持久化層相互隔離，由各個(gè)服務(wù)自己負(fù)責(zé)。另外，為了提高系統(tǒng)的實(shí)時(shí)性，加入了消息隊(duì)列機(jī)制。 架構(gòu)如下：

完全拆分后各個(gè)服務(wù)可以采用異構(gòu)的技術(shù)。比如數(shù)據(jù)分析服務(wù)可以使用數(shù)據(jù)倉庫作為持久化層，以便于高效地做一些統(tǒng)計(jì)計(jì)算；商品服務(wù)和促銷服務(wù)訪問頻率比較大，因此加入了緩存機(jī)制等。

還有一種抽象出公共邏輯的方法是把這些公共邏輯做成公共的框架庫。這種方法可以減少服務(wù)調(diào)用的性能損耗。但是這種方法的管理成本非常高昂，很難保證所有應(yīng)用版本的一致性。

數(shù)據(jù)庫拆分也有一些問題和挑戰(zhàn)：比如說跨庫級(jí)聯(lián)的需求，通過服務(wù)查詢數(shù)據(jù)顆粒度的粗細(xì)問題等。但是這些問題可以通過合理的設(shè)計(jì)來解決?？傮w來說，數(shù)據(jù)庫拆分是一個(gè)利大于弊的。

微服務(wù)架構(gòu)還有一個(gè)技術(shù)外的好處，它使整個(gè)系統(tǒng)的分工更加明確，責(zé)任更加清晰，每個(gè)人專心負(fù)責(zé)為其他人提供更好的服務(wù)。 在單體應(yīng)用的時(shí)代，公共的業(yè)務(wù)功能經(jīng)常沒有明確的歸屬。最后要么各做各的，每個(gè)人都重新實(shí)現(xiàn)了一遍；要么是隨機(jī)一個(gè)人（一般是能力比較強(qiáng)或者比較熱心的人）做到他負(fù)責(zé)的應(yīng)用里面。 在后者的情況下，這個(gè)人在負(fù)責(zé)自己應(yīng)用之外，還要額外負(fù)責(zé)給別人提供這些公共的功能——而這個(gè)功能本來是無人負(fù)責(zé)的，僅僅因?yàn)樗芰^強(qiáng)/比較熱心，就莫名地背鍋（這種情況還被美其名曰能者多勞）。 結(jié)果最后大家都不愿意提供公共的功能。長此以往，團(tuán)隊(duì)里的人漸漸變得各自為政，不再關(guān)心全局的架構(gòu)設(shè)計(jì)。 從這個(gè)角度上看，使用微服務(wù)架構(gòu)同時(shí)也需要組織結(jié)構(gòu)做相應(yīng)的調(diào)整。所以說做微服務(wù)改造需要管理者的支持。 改造完成后，小明和小紅分清楚各自的鍋。兩人十分滿意，一切就像是麥克斯韋方程組一樣漂亮完美。

然而……

沒有銀彈

春天來了，萬物復(fù)蘇，又到了一年一度的購物狂歡節(jié)。眼看著日訂單數(shù)量蹭蹭地上漲，小皮小明小紅喜笑顏開。 可惜好景不長，樂極生悲，突然嘣的一下，系統(tǒng)掛了。 以往單體應(yīng)用，排查問題通常是看一下日志，研究錯(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)過十幾分鐘的查找，小明終于定位到故障點(diǎn)：促銷服務(wù)由于接收的請(qǐng)求量太大而停止響應(yīng)了。其他服務(wù)都直接或間接地會(huì)調(diào)用促銷服務(wù)，于是也跟著宕機(jī)了。 在微服務(wù)架構(gòu)中，一個(gè)服務(wù)故障可能會(huì)產(chǎn)生雪崩效用，導(dǎo)致整個(gè)系統(tǒng)故障。 其實(shí)在節(jié)前，小明和小紅是有做過請(qǐng)求量評(píng)估的。按照預(yù)計(jì)，服務(wù)器資源是足以支持節(jié)日的請(qǐng)求量的，所以肯定是哪里出了問題。 不過形勢(shì)緊急，隨著每一分每一秒流逝的都是白花花的銀子，因此小明也沒時(shí)間排查問題，當(dāng)機(jī)立斷在云上新建了幾臺(tái)虛擬機(jī)，然后一臺(tái)一臺(tái)地部署新的促銷服務(wù)節(jié)點(diǎn)。 幾分鐘的操作后，系統(tǒng)總算是勉強(qiáng)恢復(fù)正常了。整個(gè)故障時(shí)間內(nèi)估計(jì)損失了幾十萬的銷售額，三人的心在滴血。 事后，小明簡單寫了個(gè)日志分析工具（量太大了，文本編輯器幾乎打不開，打開了肉眼也看不過來），統(tǒng)計(jì)了促銷服務(wù)的訪問日志，發(fā)現(xiàn)在故障期間，商品服務(wù)由于代碼問題，在某些場(chǎng)景下會(huì)對(duì)促銷服務(wù)發(fā)起大量請(qǐng)求。 這個(gè)問題并不復(fù)雜，小明手指抖一抖，修復(fù)了這個(gè)價(jià)值幾十萬的 Bug。 問題是解決了，但誰也無法保證不會(huì)再發(fā)生類似的其他問題。微服務(wù)架構(gòu)雖然邏輯設(shè)計(jì)上看是完美的，但就像積木搭建的華麗宮殿一樣，經(jīng)不起風(fēng)吹草動(dòng)。微服務(wù)架構(gòu)雖然解決了舊問題，也引入了新的問題：

微服務(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í)上，在大訪問量的生產(chǎn)場(chǎng)景下，故障總是會(huì)出現(xiàn)的。

服務(wù)數(shù)量非常多，部署、管理的工作量很大。

開發(fā)方面：如何保證各個(gè)服務(wù)在持續(xù)開發(fā)的情況下仍然保持協(xié)同合作。

測(cè)試方面：服務(wù)拆分后，幾乎所有功能都會(huì)涉及多個(gè)服務(wù)。原本單個(gè)程序的測(cè)試變?yōu)榉?wù)間調(diào)用的測(cè)試。測(cè)試變得更加復(fù)雜。

小明小紅痛定思痛，決心好好解決這些問題。對(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ù)庫監(jiān)控連接數(shù)、磁盤空間，業(yè)務(wù)服務(wù)監(jiān)控并發(fā)數(shù)、響應(yīng)延遲、錯(cuò)誤率等。 因此如果做一個(gè)大而全的監(jiān)控系統(tǒng)來監(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í)提供查詢服務(wù)。 最后還需要一個(gè) UI，從指標(biāo)采集器查詢各項(xiàng)指標(biāo)，繪制監(jiān)控界面或者根據(jù)閾值發(fā)出告警。 大部分組件都不需要自己動(dòng)手開發(fā)，網(wǎng)絡(luò)上有開源組件。小明下載了 RedisExporter 和 MySQLExporter，這兩個(gè)組件分別提供了 Redis 緩存和 MySQL 數(shù)據(jù)庫的指標(biāo)接口。 微服務(wù)則根據(jù)各個(gè)服務(wù)的業(yè)務(wù)邏輯實(shí)現(xiàn)自定義的指標(biāo)接口。 然后小明采用 Prometheus 作為指標(biāo)采集器，Grafana 配置監(jiān)控界面和郵件告警。 這樣一套微服務(wù)監(jiān)控系統(tǒng)就搭建起來了：

定位問題 - 鏈路跟蹤

在微服務(wù)架構(gòu)下，一個(gè)用戶的請(qǐng)求往往涉及多個(gè)內(nèi)部服務(wù)調(diào)用。為了方便定位問題，需要能夠記錄每個(gè)用戶請(qǐng)求時(shí)，微服務(wù)內(nèi)部產(chǎn)生了多少服務(wù)調(diào)用，及其調(diào)用關(guān)系。這個(gè)叫做鏈路跟蹤。 我們用一個(gè) Istio 文檔里的鏈路跟蹤例子來看看效果：

從圖中可以看到，這是一個(gè)用戶訪問 productpage 頁面的請(qǐng)求。在請(qǐng)求過程中，productpage 服務(wù)順序調(diào)用了 details 和 reviews 服務(wù)的接口。 而 reviews 服務(wù)在響應(yīng)過程中又調(diào)用了 ratings 的接口。整個(gè)鏈路跟蹤的記錄是一棵樹：

要實(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è)極簡的說明，關(guān)于鏈路跟蹤的理論依據(jù)可詳見 Google 的 Dapper。 了解了理論基礎(chǔ)后，小明選用了 Dapper 的一個(gè)開源實(shí)現(xiàn) Zipkin。然后手指一抖，寫了個(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ò)代理組件來實(shí)現(xiàn)（不過這樣子每個(gè)微服務(wù)都需要加一層代理）。 鏈路跟蹤只能定位到哪個(gè)服務(wù)出現(xiàn)問題，不能提供具體的錯(cuò)誤信息。查找具體的錯(cuò)誤信息的能力則需要由日志分析組件來提供。

分析問題 - 日志分析

日志分析組件應(yīng)該在微服務(wù)興起之前就被廣泛使用了。即使單體應(yīng)用架構(gòu)，當(dāng)訪問數(shù)變大、或服務(wù)器規(guī)模增多時(shí)，日志文件的大小會(huì)膨脹到難以用文本編輯器進(jìn)行訪問，更糟的是它們分散在多臺(tái)服務(wù)器上面。排查一個(gè)問題，需要登錄到各臺(tái)服務(wù)器去獲取日志文件，一個(gè)一個(gè)地查找（而且打開、查找都很慢）想要的日志信息。 因此，在應(yīng)用規(guī)模變大時(shí)，我們需要一個(gè)日志的“搜索引擎”。以便于能準(zhǔn)確的找到想要的日志。 另外，數(shù)據(jù)源一側(cè)還需要收集日志的組件和展示結(jié)果的 UI 組件：

小明調(diào)查了一下，使用了大名鼎鼎地 ELK 日志分析組件。ELK 是 Elasticsearch、Logstash 和 Kibana 三個(gè)組件的縮寫。

Elasticsearch：搜索引擎，同時(shí)也是日志的存儲(chǔ)。

Logstash：日志采集器，它接收日志輸入，對(duì)日志進(jìn)行一些預(yù)處理，然后輸出到 Elasticsearch。

Kibana：UI組件，通過 Elasticsearch 的 API 查找數(shù)據(jù)并展示給用戶。

最后還有一個(gè)小問題是如何將日志發(fā)送到 Logstash。一種方案是在日志輸出的時(shí)候直接調(diào)用 Logstash 接口將日志發(fā)送過去。 這樣一來又（咦，為啥要用“又”）要修改代碼……于是小明選用了另一種方案：日志仍然輸出到文件，每個(gè)服務(wù)里再部署個(gè) Agent 掃描日志文件然后輸出給 Logstash。

網(wǎng)關(guān) - 權(quán)限控制，服務(wù)治理

拆分成微服務(wù)后，出現(xiàn)大量的服務(wù)，大量的接口，使得整個(gè)調(diào)用關(guān)系亂糟糟的。經(jīng)常在開發(fā)過程中，寫著寫著，忽然想不起某個(gè)數(shù)據(jù)應(yīng)該調(diào)用哪個(gè)服務(wù)?；蛘邔懲崃耍{(diào)用了不該調(diào)用的服務(wù)，本來一個(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è)問題就是要決定在多大粒度上使用：最粗粒度的方案是整個(gè)微服務(wù)一個(gè)網(wǎng)關(guān)，微服務(wù)外部通過網(wǎng)關(guān)訪問微服務(wù)，微服務(wù)內(nèi)部則直接調(diào)用；最細(xì)粒度則是所有調(diào)用，不管是微服務(wù)內(nèi)部調(diào)用或者來自外部的調(diào)用，都必須通過網(wǎng)關(guān)。折中的方案是按照業(yè)務(wù)領(lǐng)域?qū)⑽⒎?wù)分成幾個(gè)區(qū)，區(qū)內(nèi)直接調(diào)用，區(qū)間通過網(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)生的影響。 最粗暴的（也是最常用的）故障處理策略就是冗余。一般來說，一個(gè)服務(wù)都會(huì)部署多個(gè)實(shí)例，這樣一來能夠分擔(dān)壓力提高性能，二來即使一個(gè)實(shí)例掛了其他實(shí)例還能響應(yīng)。 冗余的一個(gè)問題是使用幾個(gè)冗余？這個(gè)問題在時(shí)間軸上并沒有一個(gè)切確的答案。根據(jù)服務(wù)功能、時(shí)間段的不同，需要不同數(shù)量的實(shí)例。比如在平日里，可能4個(gè)實(shí)例已經(jīng)夠用；而在促銷活動(dòng)時(shí)，流量大增，可能需要40個(gè)實(shí)例。因此冗余數(shù)量并不是一個(gè)固定的值，而是根據(jù)需要實(shí)時(shí)調(diào)整的。 一般來說新增實(shí)例的操作為：

部署新實(shí)例

將新實(shí)例注冊(cè)到負(fù)載均衡或 DNS 上

操作只有兩步，但如果注冊(cè)到負(fù)載均衡或DNS的操作為人工操作的話，那事情就不簡單了。想想新增40個(gè)實(shí)例后，要手工輸入40個(gè)IP的感覺…… 解決這個(gè)問題的方案是服務(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ù)時(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)有很多組件可以選擇，比如說 Zookeeper 、Eureka、Consul、Etcd 等。

不過小明覺得自己水平不錯(cuò)，想炫技，于是基于 Redis 自己寫了一個(gè)。

熔斷、服務(wù)降級(jí)、限流

熔斷

當(dāng)一個(gè)服務(wù)因?yàn)楦鞣N原因停止響應(yīng)時(shí)，調(diào)用方通常會(huì)等待一段時(shí)間，然后超時(shí)或者收到錯(cuò)誤返回。 如果調(diào)用鏈路比較長，可能會(huì)導(dǎo)致請(qǐng)求堆積，整條鏈路占用大量資源一直在等待下游響應(yīng)。 所以當(dāng)多次訪問一個(gè)服務(wù)失敗時(shí)，應(yīng)熔斷，標(biāo)記該服務(wù)已停止工作，直接返回錯(cuò)誤。直至該服務(wù)恢復(fù)正常后再重新建立連接。

服務(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í)慣性地重試訪問。這導(dǎo)致一旦服務(wù)恢復(fù)正常，很可能因?yàn)樗查g網(wǎng)絡(luò)流量過大又立刻掛掉，在棺材里重復(fù)著仰臥起坐。 因此服務(wù)需要能夠自我保護(hù)——限流。 限流策略有很多，最簡單的比如當(dāng)單位時(shí)間內(nèi)請(qǐng)求數(shù)過多時(shí)，丟棄多余的請(qǐng)求。另外，也可以考慮分區(qū)限流。僅拒絕來自產(chǎn)生大量請(qǐng)求的服務(wù)的請(qǐng)求。

例如商品服務(wù)和訂單服務(wù)都需要訪問促銷服務(wù)，商品服務(wù)由于代碼問題發(fā)起了大量請(qǐng)求，促銷服務(wù)則只限制來自商品服務(wù)的請(qǐng)求，來自訂單服務(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)力，但是通過測(cè)試后我們對(duì)系統(tǒng)最有信心。單元測(cè)試最容易實(shí)施，效率也最高，但是測(cè)試后不能保證整個(gè)系統(tǒng)沒有問題。

由于端到端測(cè)試實(shí)施難度較大，一般只對(duì)核心功能做端到端測(cè)試。一旦端到端測(cè)試失敗，則需要將其分解到單元測(cè)試：則分析失敗原因，然后編寫單元測(cè)試來重現(xiàn)這個(gè)問題，這樣未來我們便可以更快地捕獲同樣的錯(cuò)誤。 服務(wù)測(cè)試的難度在于服務(wù)會(huì)經(jīng)常依賴一些其他服務(wù)。這個(gè)問題可以通過 Mock Server 解決：

單元測(cè)試大家都很熟悉了。我們一般會(huì)編寫大量的單元測(cè)試（包括回歸測(cè)試）盡量覆蓋所有代碼。

微服務(wù)框架

指標(biāo)接口、鏈路跟蹤注入、日志引流、服務(wù)注冊(cè)發(fā)現(xiàn)、路由規(guī)則等組件以及熔斷、限流等功能都需要在應(yīng)用服務(wù)上添加一些對(duì)接代碼。如果讓每個(gè)應(yīng)用服務(wù)自己實(shí)現(xiàn)是非常耗時(shí)耗力的。 基于DRY的原則，小明開發(fā)了一套微服務(wù)框架，將與各個(gè)組件對(duì)接的代碼和另外一些公共代碼抽離到框架中，所有的應(yīng)用服務(wù)都統(tǒng)一使用這套框架進(jìn)行開發(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)重的問題：框架更新成本很高。每次框架升級(jí)，都需要所有應(yīng)用服務(wù)配合升級(jí)。 當(dāng)然，一般會(huì)使用兼容方案，留出一段并行時(shí)間等待所有應(yīng)用服務(wù)升級(jí)。但是如果應(yīng)用服務(wù)非常多時(shí)，升級(jí)時(shí)間可能會(huì)非常漫長。并且有一些很穩(wěn)定幾乎不更新的應(yīng)用服務(wù)，其負(fù)責(zé)人可能會(huì)拒絕升級(jí)。 因此，使用統(tǒng)一微服務(wù)框架需要完善的版本管理方法和開發(fā)管理規(guī)范。

另一條路 - Service Mesh

另一種抽象公共代碼的方法是直接將這些代碼抽象到一個(gè)反向代理組件。每個(gè)服務(wù)都額外部署這個(gè)代理組件，所有出站入站的流量都通過該組件進(jìn)行處理和轉(zhuǎn)發(fā)。這個(gè)組件被稱為 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í)際上都只是通過內(nèi)存拷貝實(shí)現(xiàn)的。

Sidecar 只負(fù)責(zé)網(wǎng)絡(luò)通信，還需要有個(gè)組件來統(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)。

Sevice Mesh 相比于微服務(wù)框架的優(yōu)點(diǎn)在于它不侵入代碼，升級(jí)和維護(hù)更方便。它經(jīng)常被詬病的則是性能問題。即使回環(huán)網(wǎng)絡(luò)不會(huì)產(chǎn)生實(shí)際的網(wǎng)絡(luò)請(qǐng)求，但仍然有內(nèi)存拷貝的額外成本。另外有一些集中式的流量處理也會(huì)影響性能。

結(jié)束、也是開始

微服務(wù)不是架構(gòu)演變的終點(diǎn)。往細(xì)走還有 Serverless、FaaS 等方向。另一方面也有人在唱合久必分分久必合，重新發(fā)現(xiàn)單體架構(gòu)。

不管怎樣，微服務(wù)架構(gòu)的改造暫時(shí)告一段落了。小明滿足地摸了摸日益光滑的腦袋，打算這個(gè)周末休息一下約小紅喝杯咖啡。

審核編輯 ：李倩