微服務框架
- 6個基本組件：服務描述、註冊中心、服務框架、服務監控、服務治理、服務追蹤。
- 常用的服務描述方式： RESTful API（http協議）、XML配置（PRC協議）、IDL文件（跨語言服務調用）。
- 註冊中心：服務的發佈和訂閱。
- 服務框架參考標準
- 通信協議（TCP/UDP四層-HTTP七層）；
- 數據傳輸方式（同步/異步-！單連接/多路複用）；
- 數據壓縮。
- 服務監控：
- 指標收集（QPS、耗時、成功）
- 數據處理
- 數據展示（業務報警）
- 服務追蹤：問題追蹤、故障定位。生成、傳遞requestid、spanid。服務治理、集羣。
- http協議包含冗餘信息，類比xml。
監控微服務調用
- 監控對象
- 用戶端監控。指監控業務直接對用戶提供的功能。
- 接口監控。指監控業務提供的功能所依賴的具體PRC接口。
- 資源監控。指監控某個接口依賴的資源。
- 基礎監控。指監控對服務器本身的健康狀況。
- 監控指標
- 請求量。實時請求量用QPS（ Queries Per Second ），統計請求量用PV（ Page View），即一段時間內的用戶訪問量。
- 響應時間。可以用一段時間內所調用的平均耗時反映請求的響應時間
- 錯誤率。通常用一段時間內調用失敗的次數佔調用總次數的比率表示。
- 監控維度
- 全局維度。從整體角度監控對象的請求量、平均耗時以及錯誤率。
- 分機房維護。不同機房地域對同一監控對象的各種指標差異很大。
- 單機維度。機器性能不同導致監控指標差異很大。
- 時間維度。對同一監控對象、每天同一時刻進行監控。
- 核心維度。根據業務重要性程度對監控對象進行分級。
- 監控系統原理。監控系統涉及四個環節：數據採集、數據傳輸、數據處理和數據展示。
- 數據採集。
- 兩種常見方式：服務主動上報、代理收集。首要考慮的問題是採樣率，即採集數據的頻率。採樣率決定了監控的實時性和精確度。但採樣對系統本身的性能也會有一定影響。
- 服務主動上報，通過在業務代碼或服務框架里加入數據收集代碼邏輯，在每一次服務調用完成後，主動上報服務的調用信息。
- 代理收集，通過服務調用後把調用的詳細信息記錄在本地日誌文件中，然後再通過代理去解析本地日誌文件，然後再上報服務的調用信息。
- 數據傳輸。兩種常用方式：UDP傳輸、Kafka傳輸。
- UDP傳輸,數據採集後通過UDP協議與服務器建立連接，把數據發送到數據處理單元提供的服務器地址。
- kafka傳輸，數據採集後擦送到指指定的Topic，然後數據處理單元再訂閱對應的Topic。
- 數據傳輸格式。常見數據格式兩種：二進制協議、文本協議。
- 數據處理。
- 數據處理時對收集來的原始數據進行聚合存儲。數據聚合存儲通常有兩個維度，接口維度聚合、機器維度聚合。接口維度聚合把數據按照接口名維度實時聚合，可得到每個接口的實時請求量、平均耗時等信息。機器維度聚合把數據按照調用的節點維度聚合，即可從單機維度查詢每個接口的實時請求量、平均耗時等信息。
- 數據處理存儲。兩種常用的數據庫：索引數據庫（如Elasticsearch）、時序數據庫（如OpenTSDB）。
- 數據展示。如曲線圖、餅狀圖、格子圖等。
追蹤微服務調用
-
服務追蹤的用途:
- 優化系統瓶頸；
- 優化鏈路調用；
- 生成網絡拓撲；
- 透明數據傳輸。
-
參考 Dapper, a Large-Scale Distributed Systems Tracing Infrastructure http://bigbully.github.io/Dapper-translation/
-
調用鏈：通過全局唯一ID將分佈在各個服務節點上的一次請求串聯，ID記錄請求信息、服務器路由、業務埋點數據信息。
-
traceId用於表示某一次具體的請求ID，在PRC調用第一層網絡生成，並往後傳入每一次PRC調用。
-
spanId用於標識一次PRC調用在分佈式請求中的位置，如0.1、0.2、0.3、0.3.1、0.4。
-
annotation用於業務自定義埋點數據，如用戶UID。
-
樣例報文：traceid=123456，spanId=0.1，appKey=A，method=B.method，start=103，duration=38。
-
追蹤系統分爲三層：數據採集、數據處理和數據展示。
-
數據採集層注意事務控制、分爲CS、SR、SS、CR。（C client，S server，S send，R recieve）。
-
數據處理分爲實時數據處理、離線數據處理。實時數據處理採用 Storm 或 Spark Streaming 。採用 OLTP 數據倉庫，如 HBase 。離線數據處理採用 MapReduce 或 Spark ，存儲用 Hive 。
-
數據展示一般使用調用鏈路圖和調用拓撲圖。調用鏈路圖用於故障定位，調用拓撲圖用於系統統計，如QPS、平均耗時。
服務治理手段
節點管理
- 註冊中心主動摘除機制；如心跳監控，服務提供者定時的主動向註冊中心彙報心跳。
- 服務消費者摘除機制；存活探測機制用在服務消費者這一端更合理。
負載均衡算法
- 隨機算法;均勻算法，均勻調用量。
- 輪詢算法；按照固定權重對服務節點輪詢。
- 最少活躍調用算法；內存裏維護連接數倒序排列，選擇連接數最小節點發起調用。
- 一致性 Hash 算法。相同參數的請求發到同一服務節點。
服務路由
- 服務存在灰度發佈的需求。類似尾號限行，針對特定人羣測試。
- 多機房就近訪問的需求。兩種配種方式：1、靜態配置，本地存放服務調用路由規則；2、動態配置，路由規則存放在註冊中心。
服務容錯
- FailOver :失敗自動切換。失敗或超時後自動從可用服務節點選擇下一個節點重新發起調用。適合讀請求的場景。
- FailBack :失敗通知。調用錯誤後不再重試，根據失敗信息決定後續執行策略；如非冪等的調用場景。
- FailCache :失敗緩存。失敗後隔斷時間繼續發起調用。
- FailFast ：快速失敗。調用一次失敗後不再重試。一般非核心業務的調用。
- 服務容錯即服務調用失敗自動恢復的手段。一般情況下對於冪等的調用，可以選擇 FailOver 或者 FailCache，非冪等的調用可以選擇 FailBack 或者 FailFast。