微服務(wù)架構(gòu)的全局圖景簡析

本文將介紹微服務(wù)架構(gòu)和相關(guān)的組件，介紹他們是什么以及為什么要使用微服務(wù)架構(gòu)和這些組件。本文側(cè)重于簡明地表達(dá)微服務(wù)架構(gòu)的全局圖景，因此不會涉及具體如何使用組件等細(xì)節(jié)。

要理解微服務(wù)，首先要先理解不是微服務(wù)的那些。通常跟微服務(wù)相對的是單體應(yīng)用，即將所有功能都打包成在一個獨立單元的應(yīng)用程序。從單體應(yīng)用到微服務(wù)并不是一蹴而就的，這是一個逐漸演變的過程。

本文將以一個網(wǎng)上超市應(yīng)用為例來說明這一過程。

最初的需求

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

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

我們整理一下功能清單：

網(wǎng)站

用戶注冊、登錄功能

商品展示

下單

管理后臺

用戶管理

商品管理

訂單管理

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

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

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

好景不長，沒過幾天，各類網(wǎng)上超市緊跟著拔地而起，對小明小皮造成了強(qiáng)烈的沖擊。

在競爭的壓力下，小明小皮決定開展一些營銷手段：

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

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

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

……

這些活動都需要程序開發(fā)的支持。小明拉了同學(xué)小紅加入團(tuán)隊。小紅負(fù)責(zé)數(shù)據(jù)分析以及移動端相關(guān)開發(fā)。小明負(fù)責(zé)促銷活動相關(guān)功能的開發(fā)。

因為開發(fā)任務(wù)比較緊迫，小明小紅沒有好好規(guī)劃整個系統(tǒng)的架構(gòu)，隨便拍了拍腦袋，決定把促銷管理和數(shù)據(jù)分析放在管理后臺里，微信和移動端 APP 另外搭建。通宵了幾天后，新功能和新應(yīng)用基本完工。這時架構(gòu)圖如下：

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

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

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

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

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

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

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

開發(fā)、測試、部署、維護(hù)愈發(fā)困難。即使只改動一個小功能，也需要整個應(yīng)用一起發(fā)布。有時候發(fā)布會不小心帶上了一些未經(jīng)測試的代碼，或者修改了一個功能后，另一個意想不到的地方出錯了。為了減輕發(fā)布可能產(chǎn)生的問題的影響和線上業(yè)務(wù)停頓的影響，所有應(yīng)用都要在凌晨三四點執(zhí)行發(fā)布。發(fā)布后為了驗證應(yīng)用正常運行，還得盯到第二天白天的用戶高峰期……

團(tuán)隊出現(xiàn)推諉扯皮現(xiàn)象。關(guān)于一些公用的功能應(yīng)該建設(shè)在哪個應(yīng)用上的問題常常要爭論很久，最后要么干脆各做各的，或者隨便放個地方但是都不維護(hù)。

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

是時候做出改變了

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

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

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

用戶服務(wù)

商品服務(wù)

促銷服務(wù)

訂單服務(wù)

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

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

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

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

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

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

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

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

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

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

微服務(wù)架構(gòu)還有一個技術(shù)外的好處，它使整個系統(tǒng)的分工更加明確，責(zé)任更加清晰，每個人專心負(fù)責(zé)為其他人提供更好的服務(wù)。在單體應(yīng)用的時代，公共的業(yè)務(wù)功能經(jīng)常沒有明確的歸屬。最后要么各做各的，每個人都重新實現(xiàn)了一遍；要么是隨機(jī)一個人（一般是能力比較強(qiáng)或者比較熱心的人）做到他負(fù)責(zé)的應(yīng)用里面。在后者的情況下，這個人在負(fù)責(zé)自己應(yīng)用之外，還要額外負(fù)責(zé)給別人提供這些公共的功能——而這個功能本來是無人負(fù)責(zé)的，僅僅因為他能力較強(qiáng)/比較熱心，就莫名地背鍋（這種情況還被美其名曰能者多勞）。結(jié)果最后大家都不愿意提供公共的功能。長此以往，團(tuán)隊里的人漸漸變得各自為政，不再關(guān)心全局的架構(gòu)設(shè)計。

從這個角度上看，使用微服務(wù)架構(gòu)同時也需要組織結(jié)構(gòu)做相應(yīng)的調(diào)整。所以說做微服務(wù)改造需要管理者的支持。

改造完成后，小明和小紅分清楚各自的鍋。兩人十分滿意，一切就像是麥克斯韋方程組一樣漂亮完美。

然而……

沒有銀彈

春天來了，萬物復(fù)蘇，又到了一年一度的購物狂歡節(jié)。眼看著日訂單數(shù)量蹭蹭地上漲，小皮小明小紅喜笑顏開?？上Ш镁安婚L，樂極生悲，突然嘣的一下，系統(tǒng)掛了。

以往單體應(yīng)用，排查問題通常是看一下日志，研究錯誤信息和調(diào)用堆棧。而微服務(wù)架構(gòu)整個應(yīng)用分散成多個服務(wù)，定位故障點非常困難。小明一個臺機(jī)器一臺機(jī)器地查看日志，一個服務(wù)一個服務(wù)地手工調(diào)用。經(jīng)過十幾分鐘的查找，小明終于定位到故障點：促銷服務(wù)由于接收的請求量太大而停止響應(yīng)了。其他服務(wù)都直接或間接地會調(diào)用促銷服務(wù)，于是也跟著宕機(jī)了。在微服務(wù)架構(gòu)中，一個服務(wù)故障可能會產(chǎn)生雪崩效用，導(dǎo)致整個系統(tǒng)故障。其實在節(jié)前，小明和小紅是有做過請求量評估的。按照預(yù)計，服務(wù)器資源是足以支持節(jié)日的請求量的，所以肯定是哪里出了問題。不過形勢緊急，隨著每一分每一秒流逝的都是白花花的銀子，因此小明也沒時間排查問題，當(dāng)機(jī)立斷在云上新建了幾臺虛擬機(jī)，然后一臺一臺地部署新的促銷服務(wù)節(jié)點。幾分鐘的操作后，系統(tǒng)總算是勉強(qiáng)恢復(fù)正常了。整個故障時間內(nèi)估計損失了幾十萬的銷售額，三人的心在滴血……

事后，小明簡單寫了個日志分析工具（量太大了，文本編輯器幾乎打不開，打開了肉眼也看不過來），統(tǒng)計了促銷服務(wù)的訪問日志，發(fā)現(xiàn)在故障期間，商品服務(wù)由于代碼問題，在某些場景下會對促銷服務(wù)發(fā)起大量請求。這個問題并不復(fù)雜，小明手指抖一抖，修復(fù)了這個價值幾十萬的 Bug。

問題是解決了，但誰也無法保證不會再發(fā)生類似的其他問題。微服務(wù)架構(gòu)雖然邏輯設(shè)計上看是完美的，但就像積木搭建的華麗宮殿一樣，經(jīng)不起風(fēng)吹草動。微服務(wù)架構(gòu)雖然解決了舊問題，也引入了新的問題：

微服務(wù)架構(gòu)整個應(yīng)用分散成多個服務(wù)，定位故障點非常困難。

穩(wěn)定性下降。服務(wù)數(shù)量變多導(dǎo)致其中一個服務(wù)出現(xiàn)故障的概率增大，并且一個服務(wù)故障可能導(dǎo)致整個系統(tǒng)掛掉。事實上，在大訪問量的生產(chǎn)場景下，故障總是會出現(xiàn)的。

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

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

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

小明小紅痛定思痛，決心好好解決這些問題。對故障的處理一般從兩方面入手，一方面盡量減少故障發(fā)生的概率，另一方面降低故障造成的影響。

監(jiān)控 - 發(fā)現(xiàn)故障的征兆

在高并發(fā)分布式的場景下，故障經(jīng)常是突然間就雪崩式爆發(fā)。所以必須建立完善的監(jiān)控體系，盡可能發(fā)現(xiàn)故障的征兆。

微服務(wù)架構(gòu)中組件繁多，各個組件所需要監(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)延遲、錯誤率等。因此如果做一個大而全的監(jiān)控系統(tǒng)來監(jiān)控各個組件是不大現(xiàn)實的，而且擴(kuò)展性會很差。一般的做法是讓各個組件提供報告自己當(dāng)前狀態(tài)的接口（metrics 接口），這個接口輸出的數(shù)據(jù)格式應(yīng)該是一致的。然后部署一個指標(biāo)采集器組件，定時從這些接口獲取并保持組件狀態(tài)，同時提供查詢服務(wù)。最后還需要一個 UI，從指標(biāo)采集器查詢各項指標(biāo)，繪制監(jiān)控界面或者根據(jù)閾值發(fā)出告警。

大部分組件都不需要自己動手開發(fā)，網(wǎng)絡(luò)上有開源組件。小明下載了 RedisExporter 和 MySQLExporter，這兩個組件分別提供了 Redis 緩存和 MySQL 數(shù)據(jù)庫的指標(biāo)接口。微服務(wù)則根據(jù)各個服務(wù)的業(yè)務(wù)邏輯實現(xiàn)自定義的指標(biāo)接口。然后小明采用 Prometheus 作為指標(biāo)采集器，Grafana 配置監(jiān)控界面和郵件告警。這樣一套微服務(wù)監(jiān)控系統(tǒng)就搭建起來了：

定位問題 - 鏈路跟蹤

在微服務(wù)架構(gòu)下，一個用戶的請求往往涉及多個內(nèi)部服務(wù)調(diào)用。為了方便定位問題，需要能夠記錄每個用戶請求時，微服務(wù)內(nèi)部產(chǎn)生了多少服務(wù)調(diào)用，及其調(diào)用關(guān)系。這個叫做鏈路跟蹤。

我們用一個 Istio 文檔里的鏈路跟蹤例子來看看效果：

圖片來自Istio 文檔[1]

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

要實現(xiàn)鏈路跟蹤，每次服務(wù)調(diào)用會在 HTTP 的 HEADERS 中記錄至少記錄四項數(shù)據(jù)：

traceId：traceId 標(biāo)識一個用戶請求的調(diào)用鏈路。具有相同 traceId 的調(diào)用屬于同一條鏈路。

spanId：標(biāo)識一次服務(wù)調(diào)用的 ID，即鏈路跟蹤的節(jié)點 ID。

parentId：父節(jié)點的 spanId。

requestTime & responseTime：請求時間和響應(yīng)時間。

另外，還需要調(diào)用日志收集與存儲的組件，以及展示鏈路調(diào)用的 UI 組件。

以上只是一個極簡的說明，關(guān)于鏈路跟蹤的理論依據(jù)可詳見 Google 的Dapper

了解了理論基礎(chǔ)后，小明選用了 Dapper 的一個開源實現(xiàn) Zipkin。然后手指一抖，寫了個 HTTP 請求的攔截器，在每次 HTTP 請求時生成這些數(shù)據(jù)注入到 HEADERS，同時異步發(fā)送調(diào)用日志到 Zipkin 的日志收集器中。這里額外提一下，HTTP 請求的攔截器，可以在微服務(wù)的代碼中實現(xiàn)，也可以使用一個網(wǎng)絡(luò)代理組件來實現(xiàn)（不過這樣子每個微服務(wù)都需要加一層代理）。

鏈路跟蹤只能定位到哪個服務(wù)出現(xiàn)問題，不能提供具體的錯誤信息。查找具體的錯誤信息的能力則需要由日志分析組件來提供。

分析問題 - 日志分析

日志分析組件應(yīng)該在微服務(wù)興起之前就被廣泛使用了。即使單體應(yīng)用架構(gòu)，當(dāng)訪問數(shù)變大、或服務(wù)器規(guī)模增多時，日志文件的大小會膨脹到難以用文本編輯器進(jìn)行訪問，更糟的是它們分散在多臺服務(wù)器上面。排查一個問題，需要登錄到各臺服務(wù)器去獲取日志文件，一個一個地查找（而且打開、查找都很慢）想要的日志信息。

因此，在應(yīng)用規(guī)模變大時，我們需要一個日志的“搜索引擎”。以便于能準(zhǔn)確的找到想要的日志。另外，數(shù)據(jù)源一側(cè)還需要收集日志的組件和展示結(jié)果的 UI 組件：

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

Elasticsearch：搜索引擎，同時也是日志的存儲。

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

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

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

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

拆分成微服務(wù)后，出現(xiàn)大量的服務(wù)，大量的接口，使得整個調(diào)用關(guān)系亂糟糟的。經(jīng)常在開發(fā)過程中，寫著寫著，忽然想不起某個數(shù)據(jù)應(yīng)該調(diào)用哪個服務(wù)?；蛘邔懲崃?，調(diào)用了不該調(diào)用的服務(wù)，本來一個只讀的功能結(jié)果修改了數(shù)據(jù)……

為了應(yīng)對這些情況，微服務(wù)的調(diào)用需要一個把關(guān)的東西，也就是網(wǎng)關(guān)。在調(diào)用者和被調(diào)用者中間加一層網(wǎng)關(guān)，每次調(diào)用時進(jìn)行權(quán)限校驗。另外，網(wǎng)關(guān)也可以作為一個提供服務(wù)接口文檔的平臺。

使用網(wǎng)關(guān)有一個問題就是要決定在多大粒度上使用：最粗粒度的方案是整個微服務(wù)一個網(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ù)分成幾個區(qū)，區(qū)內(nèi)直接調(diào)用，區(qū)間通過網(wǎng)關(guān)調(diào)用。

由于整個網(wǎng)上超市的服務(wù)數(shù)量還不算特別多，小明采用的最粗粒度的方案：

服務(wù)注冊于發(fā)現(xiàn) - 動態(tài)擴(kuò)容

前面的組件，都是旨在降低故障發(fā)生的可能性。然而故障總是會發(fā)生的，所以另一個需要研究的是如何降低故障產(chǎn)生的影響。

最粗暴的（也是最常用的）故障處理策略就是冗余。一般來說，一個服務(wù)都會部署多個實例，這樣一來能夠分擔(dān)壓力提高性能，二來即使一個實例掛了其他實例還能響應(yīng)。

冗余的一個問題是使用幾個冗余？這個問題在時間軸上并沒有一個切確的答案。根據(jù)服務(wù)功能、時間段的不同，需要不同數(shù)量的實例。比如在平日里，可能 4 個實例已經(jīng)夠用；而在促銷活動時，流量大增，可能需要 40 個實例。因此冗余數(shù)量并不是一個固定的值，而是根據(jù)需要實時調(diào)整的。

一般來說新增實例的操作為：

部署新實例

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

操作只有兩步，但如果注冊到負(fù)載均衡或 DNS 的操作為人工操作的話，那事情就不簡單了。想想新增 40 個實例后，要手工輸入 40 個 IP 的感覺……

解決這個問題的方案是服務(wù)自動注冊與發(fā)現(xiàn)。首先，需要部署一個服務(wù)發(fā)現(xiàn)服務(wù)，它提供所有已注冊服務(wù)的地址信息的服務(wù)。DNS 也算是一種服務(wù)發(fā)現(xiàn)服務(wù)。然后各個應(yīng)用服務(wù)在啟動時自動將自己注冊到服務(wù)發(fā)現(xiàn)服務(wù)上。并且應(yīng)用服務(wù)啟動后會實時（定期）從服務(wù)發(fā)現(xiàn)服務(wù)同步各個應(yīng)用服務(wù)的地址列表到本地。服務(wù)發(fā)現(xiàn)服務(wù)也會定期檢查應(yīng)用服務(wù)的健康狀態(tài)，去掉不健康的實例地址。這樣新增實例時只需要部署新實例，實例下線時直接關(guān)停服務(wù)即可，服務(wù)發(fā)現(xiàn)會自動檢查服務(wù)實例的增減。

服務(wù)發(fā)現(xiàn)還會跟客戶端負(fù)載均衡配合使用。由于應(yīng)用服務(wù)已經(jīng)同步服務(wù)地址列表在本地了，所以訪問微服務(wù)時，可以自己決定負(fù)載策略。甚至可以在服務(wù)注冊時加入一些元數(shù)據(jù)（服務(wù)版本等信息），客戶端負(fù)載則根據(jù)這些元數(shù)據(jù)進(jìn)行流量控制，實現(xiàn) A/B 測試、藍(lán)綠發(fā)布等功能。

服務(wù)發(fā)現(xiàn)有很多組件可以選擇，比如說 Zookeeper 、Eureka、Consul、Etcd 等。不過小明覺得自己水平不錯，想炫技，于是基于 Redis 自己寫了一個……

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

熔斷

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

圖片來自《微服務(wù)設(shè)計[3]》

服務(wù)降級

當(dāng)下游服務(wù)停止工作后，如果該服務(wù)并非核心業(yè)務(wù)，則上游服務(wù)應(yīng)該降級，以保證核心業(yè)務(wù)不中斷。比如網(wǎng)上超市下單界面有一個推薦商品湊單的功能，當(dāng)推薦模塊掛了后，下單功能不能一起掛掉，只需要暫時關(guān)閉推薦功能即可。

限流

一個服務(wù)掛掉后，上游服務(wù)或者用戶一般會習(xí)慣性地重試訪問。這導(dǎo)致一旦服務(wù)恢復(fù)正常，很可能因為瞬間網(wǎng)絡(luò)流量過大又立刻掛掉，在棺材里重復(fù)著仰臥起坐。因此服務(wù)需要能夠自我保護(hù)——限流。限流策略有很多，最簡單的比如當(dāng)單位時間內(nèi)請求數(shù)過多時，丟棄多余的請求。另外，也可以考慮分區(qū)限流。僅拒絕來自產(chǎn)生大量請求的服務(wù)的請求。例如商品服務(wù)和訂單服務(wù)都需要訪問促銷服務(wù)，商品服務(wù)由于代碼問題發(fā)起了大量請求，促銷服務(wù)則只限制來自商品服務(wù)的請求，來自訂單服務(wù)的請求則正常響應(yīng)。

測試

微服務(wù)架構(gòu)下，測試分為三個層次：

端到端測試：覆蓋整個系統(tǒng)，一般在用戶界面機(jī)型測試。

服務(wù)測試：針對服務(wù)接口進(jìn)行測試。

單元測試：針對代碼單元進(jìn)行測試。

三種測試從上到下實施的容易程度遞增，但是測試效果遞減。端到端測試最費時費力，但是通過測試后我們對系統(tǒng)最有信心。單元測試最容易實施，效率也最高，但是測試后不能保證整個系統(tǒng)沒有問題。

由于端到端測試實施難度較大，一般只對核心功能做端到端測試。一旦端到端測試失敗，則需要將其分解到單元測試：則分析失敗原因，然后編寫單元測試來重現(xiàn)這個問題，這樣未來我們便可以更快地捕獲同樣的錯誤。

服務(wù)測試的難度在于服務(wù)會經(jīng)常依賴一些其他服務(wù)。這個問題可以通過 Mock Server 解決：

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

微服務(wù)框架

指標(biāo)接口、鏈路跟蹤注入、日志引流、服務(wù)注冊發(fā)現(xiàn)、路由規(guī)則等組件以及熔斷、限流等功能都需要在應(yīng)用服務(wù)上添加一些對接代碼。如果讓每個應(yīng)用服務(wù)自己實現(xiàn)是非常耗時耗力的?；?DRY 的原則，小明開發(fā)了一套微服務(wù)框架，將與各個組件對接的代碼和另外一些公共代碼抽離到框架中，所有的應(yīng)用服務(wù)都統(tǒng)一使用這套框架進(jìn)行開發(fā)。

使用微服務(wù)框架可以實現(xiàn)很多自定義的功能。甚至可以將程序調(diào)用堆棧信息注入到鏈路跟蹤，實現(xiàn)代碼級別的鏈路跟蹤?；蛘咻敵鼍€程池、連接池的狀態(tài)信息，實時監(jiān)控服務(wù)底層狀態(tài)。

使用統(tǒng)一的微服務(wù)框架有一個比較嚴(yán)重的問題：框架更新成本很高。每次框架升級，都需要所有應(yīng)用服務(wù)配合升級。當(dāng)然，一般會使用兼容方案，留出一段并行時間等待所有應(yīng)用服務(wù)升級。但是如果應(yīng)用服務(wù)非常多時，升級時間可能會非常漫長。并且有一些很穩(wěn)定幾乎不更新的應(yīng)用服務(wù)，其負(fù)責(zé)人可能會拒絕升級……因此，使用統(tǒng)一微服務(wù)框架需要完善的版本管理方法和開發(fā)管理規(guī)范。

另一條路 - Service Mesh

另一種抽象公共代碼的方法是直接將這些代碼抽象到一個反向代理組件。每個服務(wù)都額外部署這個代理組件，所有出站入站的流量都通過該組件進(jìn)行處理和轉(zhuǎn)發(fā)。這個組件被稱為 Sidecar。

Sidecar 不會產(chǎn)生額外網(wǎng)絡(luò)成本。Sidecar 會和微服務(wù)節(jié)點部署在同一臺主機(jī)上并且共用相同的虛擬網(wǎng)卡。所以 sidecar 和微服務(wù)節(jié)點的通信實際上都只是通過內(nèi)存拷貝實現(xiàn)的。

圖片來自：Pattern: Service Mesh[4]

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

圖片來自：Pattern: Service Mesh[5]

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

結(jié)束、也是開始

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

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

審核編輯：劉清