一、服務熔斷
1、什麼是服務熔斷
熔斷這一概念來源于電子工程中的斷路器（Circuit Breaker）。在網際網路系統中，當下遊 服務因通路壓力過大而響應變慢或失敗，上遊服務為了保護系統整體的可用性，可以暫時切斷對下遊服務的調用。
這種犧牲局部，保全整體的措施就叫做熔斷。 如果不采取熔斷措施，我們的系統會怎樣呢？
舉例說明: 目前系統中有A，B，C三個服務，服務A是上遊，服務B是中遊，服務C是下遊. 它們的調用鍊如下：
一旦下遊服務C因某些原因變得不可用，積壓了大量請求，服務B的請求線程也随之阻塞。線程資源 逐漸耗盡，使得服務B也變得不可用。緊接着，服務 A也變為不可用，整個調用鍊路被拖垮。
像這種調用鍊路的連鎖故障，叫做雪崩。
2、熔斷機制
在這種時候，就需要我們的熔斷機制來挽救整個系統。
這裡需要解釋兩點：
1. 開啟熔斷 在固定時間視窗内，接口調用逾時比率達到一個門檻值，會開啟熔斷。 進入熔斷狀态後，後續對該服務接口的調用不再經過網絡，直接執行本地的預設方法，達到服務降 級的效果。
2. 熔斷恢複 熔斷不可能是永久的。當經過了規定時間之後，服務将從熔斷狀态恢複過來，再次接受調用方的遠端 調用。
3、熔斷機制實作
1. Spring Cloud Hystrix
Spring Cloud Hystrix是基于Netflix的開源架構Hystrix實作，該架構實作了服務熔斷、線程隔離等 一系列服務保護功能。
對于熔斷機制的實作，Hystrix設計了三種狀态：
熔斷關閉狀态（Closed）
服務沒有故障時，熔斷器所處的狀态，對調用方的調用不做任何限制。
熔斷開啟狀态（Open）
在固定時間内（Hystrix預設是10秒），接口調用出錯比率達到一個門檻值（Hystrix預設為 50%），會進入熔斷開啟狀态。進入熔斷狀态後， 後續對該服務接口的調用不再經過網絡， 直接執行本地的fallback方法。
半熔斷狀态（Half-Open）
在進入熔斷開啟狀态一段時間之後（Hystrix預設是5秒），熔斷器會進入半熔斷狀态。所謂半 熔斷就是嘗試恢複服務調用，允許有限的流量調用該服務，并監控調用成功率。如果成功率達 到預期，則說明服務已恢複，進入熔斷關閉狀态；如果成功率仍舊很低，則重新進入熔斷開啟 狀态。
三個狀态的轉化關系如下圖：
2. Sentinel
Sentinel 和 Hystrix 的原則是一緻的: 當調用鍊路中某個資源出現不穩定，例如，表現為
timeout，異常比例升高的時候，則對這個資源的調用進行限制，并讓請求快速失敗，防止避免影響到其它的資源，最終産生雪崩的效果。
Sentinel 熔斷手段:
- 通過并發線程數進行限制
- 通過響應時間對資源進行降級
- 系統負載保護
二、服務鍊路追蹤
1、什麼是服務鍊路追蹤
分布式微服務架構上通過業務來劃分服務的，通過REST調用對外暴露的一個接口，可能需要很多個 服務協同才能完成這個接口功能，如果鍊路上任何一個服務出現問題或者網絡逾時，都會形成導緻接口 調用失敗。随着業務的不斷擴張，服務之間互相調用會越來越複雜。
随着服務的越來越多，對調用鍊的分析會越來越複雜。它們之間的調用關系也許如下：
分布式鍊路追蹤（Distributed Tracing），也叫 分布式鍊路跟蹤，分布式跟蹤，分布式追蹤 等等. 其 實就是将一次分布式請求還原成調用鍊路。顯示的在後端檢視一次分布式請求的調用情況，比如各個節 點上的耗時、請求具體打到了哪台機器上、每個服務節點的請求狀态等等。
2、鍊路跟蹤具備的功能
1. 故障快速定位
通過調用鍊跟蹤，一次請求的邏輯軌迹可以用完整清晰的展示出來。開發中可以在業務日志中添 加調用鍊ID，可以通過調用鍊結合業務日志快速定位錯誤資訊。
2. 各個調用環節的性能分析
在調用鍊的各個環節分别添加調用時延，可以分析系統的性能瓶頸，可以進行針對性的優化。通 過分析各個環節的平均時延，QPS等資訊，可以找到系統的薄弱環節，對一些子產品做調整。
3. 資料分析
調用鍊綁定業務後檢視具體每條業務資料對應的鍊路問題，可以得到使用者的行為路徑，經過了哪些 伺服器上的哪個服務，彙總分析應用在很多業務場景。
4. 生成服務調用拓撲圖
通過可視化分布式系統的子產品和他們之間的互相聯系來了解系統拓撲。點選某個節點會展示這個 子產品的詳情，比如它目前的狀态和請求數量。
3、鍊路跟蹤設計原則
1. 設計目标
- 低侵入性，應用透明
- 低損耗
- 大範圍部署，擴充性
2. 埋點和生成日志
埋點即系統在目前節點的上下文資訊，可以分為用戶端埋點、服務端埋點，以及用戶端和服務 端雙向型埋點。埋點日志通常要包含以下内容：
TraceId、RPCId、調用的開始時間，調用類型，協定類型，調用方ip和端口，請求的服務名等 資訊；調用耗時，調用結果，異常資訊，消息封包等
3. 抓取和存儲日志
日志的采集和存儲有許多開源的工具可以選擇，一般來說，會使用離線+實時的方式去存儲日 志，主要是分布式日志采集的方式。典型的解決方案如Flume結合Kafka。
4. 分析和統計調用鍊資料
一條調用鍊的日志散落在調用經過的各個伺服器上，首先需要按 TraceId 彙總日志，然後按照 RpcId 對調用鍊進行順序整理。調用鍊資料不要求百分之百準确，可以允許中間的部分日志丢失。
5. 計算和展示
彙總得到各個應用節點的調用鍊日志後，可以針對性的對各個業務線進行分析。需要對具體日志 進行整理，進一步儲存在HBase或者關系型資料庫中，可以進行可視化的查詢。
4、鍊路跟蹤Trace模型
Trace調用模型，主要有以下概念：
Client && Server：對于跨服務的一次調用，請求發起方為client，服務提供方為Server各術語在一次 分布式調用中，關系如下圖所示
鍊路跟蹤系統實作:
大的網際網路公司都有自己的分布式跟蹤系統，比如Google的Dapper，Twitter的zipkin，淘寶的鷹 眼，新浪的Watchman，京東的Hydra等等。