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