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