在分布式架構(gòu)中，服務(wù)間的依賴非常常見，一個(gè)業(yè)務(wù)調(diào)用通常依賴多個(gè)基礎(chǔ)服務(wù)。如下圖， 對于同步調(diào)用，當(dāng)會員服務(wù)不可用時(shí)，訂單服務(wù)請求線程被阻塞，當(dāng)有大批量請求調(diào)用會員服務(wù)時(shí)， 最終可能導(dǎo)致整個(gè)會員服務(wù)資源耗盡，無法繼續(xù)對外提供服務(wù)。并且這種不可用可能沿請求調(diào)用鏈向上傳遞，從而引發(fā)服務(wù)間的雪崩效應(yīng)。
在微服務(wù)的演進(jìn)過程中，為了最大化利用微服務(wù)的優(yōu)勢，保障系統(tǒng)的高可用性，需要通過一些服務(wù)支撐組件來協(xié)助服務(wù)間有效的協(xié)作，這便是服務(wù)治理的范疇。
服務(wù)注冊與發(fā)現(xiàn)
服務(wù)化可以降低各系統(tǒng)間的高度耦合，使系統(tǒng)更易于維護(hù)和水平擴(kuò)展，可以通過流控、隔離、降級等手段保障系統(tǒng)的可用性，以下是有貨的服務(wù)化設(shè)計(jì)。
對于微服務(wù)的治理而言，核心就是服務(wù)的注冊和發(fā)現(xiàn)。所以選擇哪個(gè)組件，很大程度上要看它對于服務(wù)注冊與發(fā)現(xiàn)的解決方案。在這個(gè)領(lǐng)域，開源架構(gòu)很多，最常見的是Zookeeper和Eureka。采用Zookeeper做為注冊中心時(shí)，由于Zookeeper CP(一致性和分區(qū)容錯(cuò)性)的設(shè)計(jì)方式，需要做高可用的補(bǔ)充，一般采用在調(diào)用端緩存服務(wù)提供者信息。
負(fù)載均衡
將負(fù)載均衡的功能以庫的形式集成到服務(wù)消費(fèi)中。服務(wù)消費(fèi)者需要訪問某服務(wù)時(shí)，需要通過內(nèi)置的負(fù)載均衡組件向服務(wù)注冊中心查詢，得到可用的服務(wù)提供者列表，然后按照某種負(fù)載均衡策略選擇一個(gè)目標(biāo)服務(wù)地址，最后向目標(biāo)服務(wù)發(fā)起請求。
- 隨機(jī)策略：
從可用的服務(wù)節(jié)點(diǎn)隨機(jī)選取一個(gè)節(jié)點(diǎn)調(diào)用。 - 輪詢策略：
對可用的服務(wù)節(jié)點(diǎn)列表按順序依次調(diào)用。 - 加權(quán)輪詢策略：
按照固定的權(quán)重，對可用服務(wù)節(jié)點(diǎn)進(jìn)行輪詢。 - 最小活躍數(shù)策略：
對各可用服務(wù)節(jié)點(diǎn)的請求數(shù)計(jì)數(shù)，選擇連接數(shù)小的節(jié)點(diǎn)調(diào)用。 - 本地優(yōu)先策略：
服務(wù)的調(diào)用者和提供者有可能被部署在同一臺機(jī)器上，可通過本地調(diào)用減少網(wǎng)絡(luò)調(diào)用中性能損耗。
服務(wù)調(diào)用客戶端
服務(wù)調(diào)用客戶端為服務(wù)提供了透明化和高效的RPC遠(yuǎn)程調(diào)用，將服務(wù)的注冊與發(fā)現(xiàn)，服務(wù)調(diào)用的負(fù)載均衡以及服務(wù)的隔離和容錯(cuò)等服務(wù)治理策略內(nèi)嵌其中，并提供服務(wù)監(jiān)控和治理能力。本文采用hystrix命令模式封裝REST調(diào)用，將服務(wù)的隔離、超時(shí)、限流、降級、負(fù)載均衡等策略持久化到Zookeeper上，以服務(wù)發(fā)現(xiàn)的方式發(fā)現(xiàn)服務(wù)的治理策略，并將策略應(yīng)用到服務(wù)調(diào)用中，將服務(wù)的成功和失敗通過Spring異步事件通知上報(bào)到influxDB中。
服務(wù)治理
服務(wù)監(jiān)控
Hystrix Dashboard
Hystrix Dashboard主要用來實(shí)時(shí)監(jiān)控Hystrix的各項(xiàng)指標(biāo)信息。通過Hystrix Dashboard反饋的實(shí)時(shí)信息，可以幫助我們快速發(fā)現(xiàn)系統(tǒng)中存在的問題。
集群環(huán)境監(jiān)控可使用Netflix提供的turbine進(jìn)行監(jiān)控。通過maven公服https://search.maven.org下載并部署war包turbine-web，修改集群節(jié)點(diǎn)配置，將turbine地址 http://localhost{port}/turbine.stream?cluster=default 添加監(jiān)控到hystrix dashboard
turbine.aggregator.clusterConfig=default
turbine.instanceUrlSuffix=:8080/gateway/hystrix.stream
turbine.ConfigPropertyBasedDiscovery.default.instances=10.66.70.1,10.66.70.2,10.66.70.3
Hystrix Dashboard通過顏色的變化代表了實(shí)例的健康程度，它的健康程度從 綠色 > 黃色 > 橙色 > 紅色 遞減； 該實(shí)心圓除了顏色的變化之外，它的大小也會根據(jù)實(shí)例的請求流量發(fā)生變化，流量越大實(shí)心圓就越大，所以通過該實(shí)心圓的展示，就可以在大量實(shí)例中快速的發(fā)現(xiàn)故障實(shí)例和高壓力實(shí)例。
grafana監(jiān)控
通過Spring攔截器記錄服務(wù)的調(diào)用日志，并采集日志分析上報(bào)到influxDB中，通過grafana將服務(wù)調(diào)用信息近實(shí)時(shí)可視化。
服務(wù)發(fā)現(xiàn)客戶端采集服務(wù)調(diào)用的成功及失敗請求經(jīng)Spring異步事件上報(bào)到influxdb，由grafana將監(jiān)控?cái)?shù)據(jù)可視化，并推送服務(wù)異常的告警信息。
服務(wù)治理
服務(wù)調(diào)用客戶端的服務(wù)發(fā)現(xiàn)與治理的類UML圖如下：
服務(wù)治理平臺管理各服務(wù)的資源組，并把核心業(yè)務(wù)獨(dú)立出單獨(dú)的資源組進(jìn)行管理。監(jiān)控各服務(wù)調(diào)用的壓力、平均耗時(shí)、錯(cuò)誤數(shù)、調(diào)用趨勢等信息，并可以對單個(gè)服務(wù)的超時(shí)、限流、降級、資源池、負(fù)載均衡策略進(jìn)行都動(dòng)態(tài)調(diào)整。
資源隔離
對服務(wù)調(diào)用實(shí)行線程池隔離，避免不同的服務(wù)失敗導(dǎo)致線程被耗盡產(chǎn)生故障傳播，對于部分核心流程如登錄、注冊、商品信息、下單支付等可在原線程隔離基礎(chǔ)上再隔離出單獨(dú)的線程池，保障核心業(yè)務(wù)不受影響。
熔斷
可對不同的接口請求應(yīng)用不同的超時(shí)策略，超時(shí)后直接熔斷走服務(wù)降級邏輯，避免服務(wù)被拖垮。依賴服務(wù)異常次數(shù)超限后直接熔斷，通過hystrix定時(shí)檢查服務(wù)是否恢復(fù)。
降級
在服務(wù)調(diào)用失敗、超時(shí)、熔斷器開路、線程池或信號量容量超額，服務(wù)執(zhí)行后備邏輯，支持服務(wù)的failfast和failsafe等容錯(cuò)。
限流
基于網(wǎng)關(guān)的服務(wù)限流措施，可結(jié)合Nginx限流使用，避免流量高峰期的系統(tǒng)過載過高，影響核心業(yè)務(wù)的運(yùn)行。
負(fù)載均衡策略
可對不同的服務(wù)應(yīng)用不同的負(fù)載均衡策略，可選擇輪詢、加權(quán)輪詢、隨機(jī)、本地優(yōu)先和最小活躍數(shù)等策略。
Service Mesh
Service Mesh（服務(wù)網(wǎng)格） 是一個(gè)基礎(chǔ)設(shè)施層，用于處理服務(wù)間通信。Service Mesh 實(shí)際上就是處于 TCP/IP 之上的一個(gè)抽象層。在實(shí)際應(yīng)用當(dāng)中，Service Mesh 通常是由一系列輕量級的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但應(yīng)用程序不需要知道它們的存在。Service Mesh 是一種新的服務(wù)治理思想，它是把對服務(wù)的治理由應(yīng)用層下沉到基礎(chǔ)服務(wù)層。
Service Mesh作為一個(gè)獨(dú)立的代理進(jìn)程部署在每一臺主機(jī)上，主機(jī)上的多個(gè)服務(wù)消費(fèi)者（Consumer）應(yīng)用可以共用這個(gè)代理來實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡。
Service Mesh將負(fù)責(zé)服務(wù)發(fā)現(xiàn)、負(fù)載均衡、熔斷限流等相關(guān)邏輯從原有的消費(fèi)客戶端進(jìn)程拆分到單獨(dú)的代理進(jìn)程中，由這個(gè)獨(dú)立部署的代理來負(fù)責(zé)服務(wù)發(fā)現(xiàn)、路由分流（負(fù)載均衡）、熔斷限流、安全控制、監(jiān)控等功能。
Service mesh 有如下幾個(gè)特點(diǎn)：
- 應(yīng)用程序間通訊的中間層
- 輕量級網(wǎng)絡(luò)代理
- 應(yīng)用程序無感知
- 解耦應(yīng)用程序的重試、超時(shí)、監(jiān)控、追蹤和服務(wù)發(fā)現(xiàn)
目前Service Mesh的開源解決方案有：Buoyant 公司推出的 Linkerd 和 google、IBM 等廠商牽頭的 Istio。Linkerd 更加成熟穩(wěn)定些，Istio 功能更加豐富、設(shè)計(jì)上更為強(qiáng)大，社區(qū)相對也更加強(qiáng)大一些。
本文轉(zhuǎn)載于博客園，原文：https://www.cnblogs.com/qingfengEthan/p/12633149.html
