一文詳解微服務(wù)架構(gòu)

轉(zhuǎn)載請注明出處:https://www.cnblogs.com/skabyy/p/11396571.html

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

要理解微服務(wù)，首先要先理解不是微服務(wù)的那些。通常跟微服務(wù)相對的是單體應(yīng)用玲献，即將所有功能都打包成在一個獨(dú)立單元的應(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)站： 1）用戶注冊2）登錄功能 3）商品展示 下單

管理后臺： 1)用戶管理2) 商品管理 3) 訂單管理

由于需求簡單游两，小明左手右手一個慢動作砾层，網(wǎng)站就做好了。管理后臺出于安全考慮贱案，不和網(wǎng)站做在一起肛炮，小明右手左手慢動作重播，管理網(wǎng)站也做好了宝踪∏仍悖總體架構(gòu)圖如下：

img

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

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

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

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

1. 開展促銷活動庐扫。比如元旦全場打折，春節(jié)買二送一仗哨，情人節(jié)狗糧優(yōu)惠券等等形庭。
2. 拓展渠道，新增移動端營銷藻治。除了網(wǎng)站外碘勉，還需要開發(fā)移動端APP，微信小程序等桩卵。
3. 精準(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)圖如下：

img

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

1. 網(wǎng)站和移動端應(yīng)用有很多相同業(yè)務(wù)邏輯的重復(fù)代碼。
2. 數(shù)據(jù)有時候通過數(shù)據(jù)庫共享崭孤，有時候通過接口調(diào)用傳輸类嗤。接口調(diào)用關(guān)系雜亂。
3. 單個應(yīng)用為了給其他應(yīng)用提供接口辨宠，漸漸地越改越大遗锣，包含了很多本來就不屬于它的邏輯。應(yīng)用邊界模糊嗤形，功能歸屬混亂精偿。
4. 管理后臺在一開始的設(shè)計中保障級別較低。加入數(shù)據(jù)分析和促銷管理相關(guān)功能后出現(xiàn)性能瓶頸派殷，影響了其他應(yīng)用还最。
5. 數(shù)據(jù)庫表結(jié)構(gòu)被多個應(yīng)用依賴，無法重構(gòu)和優(yōu)化毡惜。
6. 所有應(yīng)用都在一個數(shù)據(jù)庫上操作拓轻，數(shù)據(jù)庫出現(xiàn)性能瓶頸。特別是數(shù)據(jù)分析跑起來的時候经伙，數(shù)據(jù)庫性能急劇下降扶叉。
7. 開發(fā)、測試帕膜、部署枣氧、維護(hù)愈發(fā)困難。即使只改動一個小功能垮刹，也需要整個應(yīng)用一起發(fā)布达吞。有時候發(fā)布會不小心帶上了一些未經(jīng)測試的代碼，或者修改了一個功能后荒典，另一個意想不到的地方出錯了酪劫。為了減輕發(fā)布可能產(chǎn)生的問題的影響和線上業(yè)務(wù)停頓的影響吞鸭，所有應(yīng)用都要在凌晨三四點執(zhí)行發(fā)布。發(fā)布后為了驗證應(yīng)用正常運(yùn)行覆糟，還得盯到第二天白天的用戶高峰期……
8. 團(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ù)：

1. 用戶服務(wù)
2. 商品服務(wù)
3. 促銷服務(wù)
4. 訂單服務(wù)
5. 數(shù)據(jù)分析服務(wù)

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

img

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

1. 數(shù)據(jù)庫成為性能瓶頸操刀，并且有單點故障的風(fēng)險烁挟。
2. 數(shù)據(jù)管理趨向混亂。即使一開始有良好的模塊化設(shè)計骨坑，隨著時間推移撼嗓，總會有一個服務(wù)直接從數(shù)據(jù)庫取另一個服務(wù)的數(shù)據(jù)的現(xiàn)象。
3. 數(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)如下：

img

完全拆分后各個服務(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è)計來解決帅容∑南螅總體來說，數(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ù)量蹭蹭地上漲，小皮小明小紅喜笑顏開护盈⌒矗可惜好景不長，樂極生悲腐宋，突然嘣的一下紊服，系統(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)雖然解決了舊問題鲫趁，也引入了新的問題：

1. 微服務(wù)架構(gòu)整個應(yīng)用分散成多個服務(wù)斯嚎，定位故障點非常困難。
2. 穩(wěn)定性下降。服務(wù)數(shù)量變多導(dǎo)致其中一個服務(wù)出現(xiàn)故障的概率增大堡僻，并且一個服務(wù)故障可能導(dǎo)致整個系統(tǒng)掛掉糠惫。事實上，在大訪問量的生產(chǎn)場景下钉疫，故障總是會出現(xiàn)的硼讽。
3. 服務(wù)數(shù)量非常多，部署牲阁、管理的工作量很大固阁。
4. 開發(fā)方面：如何保證各個服務(wù)在持續(xù)開發(fā)的情況下仍然保持協(xié)同合作。
5. 測試方面：服務(wù)拆分后城菊，幾乎所有功能都會涉及多個服務(wù)备燃。原本單個程序的測試變?yōu)榉?wù)間調(diào)用的測試。測試變得更加復(fù)雜凌唬。

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

img

監(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)就搭建起來了：

img

定位問題 - 鏈路跟蹤

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

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

img

圖片來自 ：https://istio.io/zh/docs/tasks/telemetry/distributed-tracing/zipkin/
從圖中可以看到概而，這是一個用戶訪問productpage頁面的請求。在請求過程中囱修，productpage服務(wù)順序調(diào)用了details和reviews服務(wù)的接口赎瑰。而reviews服務(wù)在響應(yīng)過程中又調(diào)用了ratings的接口。整個鏈路跟蹤的記錄是一棵樹：

img

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

1. traceId：traceId標(biāo)識一個用戶請求的調(diào)用鏈路餐曼。具有相同traceId的調(diào)用屬于同一條鏈路。
2. spanId：標(biāo)識一次服務(wù)調(diào)用的ID鲜漩，即鏈路跟蹤的節(jié)點ID源譬。
3. parentId：父節(jié)點的spanId。
4. requestTime & responseTime：請求時間和響應(yīng)時間孕似。

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

img

以上只是一個極簡的說明养渴，關(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組件：

img

小明調(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ù)量還不算特別多菠镇，小明采用的最粗粒度的方案：

img

服務(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)整的笤妙。

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

1. 部署新實例
2. 將新實例注冊到負(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ù)實例的增減拂封。

img

服務(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ù)正常后再重新建立連接。

img

服務(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)。

img

測試

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

1. 端到端測試：覆蓋整個系統(tǒng)店溢，一般在用戶界面機(jī)型測試叁熔。
2. 服務(wù)測試：針對服務(wù)接口進(jìn)行測試。
3. 單元測試：針對代碼單元進(jìn)行測試床牧。

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

img

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

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

img

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

微服務(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)的。

img

圖片來自：http://philcalcado.com/2017/08/03/pattern_service_mesh.html
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)。

img

圖片來自：http://philcalcado.com/2017/08/03/pattern_service_mesh.html

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)的改造暫時告一段落了涮总。小明滿足地摸了摸日益光滑的腦袋胸囱，打算這個周末休息一下約小紅喝杯咖啡。