我們在日常中想要管理或者解決壹些人或者事情，需要盡可能地了解對方，才能進行。所以想要服務治理，我們也要了解服務。但是需要了解哪些方面呢？
我們可以通過指標來了解服務狀態。指標可以分為兩種：基礎指標和業務指標。
基礎指標主要是壹些通用的指標。下面是壹些常見的基礎指標：
? 機器指標（cpu、內存、網絡）
? jvm metric
? pod metric
? 基礎組件指標（db metric、redis metric等）
業務指標是指和業務相關的指標。這些指標反映了業務的狀態。比如業務處理延遲、速度等。
我們在管理服務時需要知道服務需要哪些資源，需要多少。這樣我們才能給服務分配資源。資源調度的前提是：我們知道還剩多少資源。所以我們需要基礎指標。只有基礎指標健全，我們才能獲得剩余資源的信息，才能進行資源調度。目前資源調度壹般都是用k8s來管理。
服務正常運行需要其依賴的服務正常運行。所以我們需要知道服務的依賴關系，調用鏈情況。通過調用鏈我們可以知道依賴關系，業務瓶頸在哪，哪些業務是關鍵業務，需要擴縮容。
常見的調用鏈中間：jeager、skywalking、zipkin。在選型時，優先考慮業務入侵小的方案，例如Java 字節碼技術。
隨著服務數量的增加，管理的難度也隨之劇增。所以我們需要搭建基礎設施來輔助管理。
k8s 是目前最火的服務編排系統，我們也就在贅述了。
配置中心是為服務提供配置的，我們可以通過配置中心對服務進行管理，比如業務使用哪套算法模型，業務出現線程數量等。常見的配置中心有：zookeeper、consul、Nacos、apollo、spring cloud config。
zookeeper和consul 只具有簡單的配置中心功能，相當於nosql db。在服務體量不大，服務治理場景簡單的時候可以使用。但是對於復雜或者高級的服務治理場景還是捉襟見肘。比如灰度發布。
Nacos、apollo、spring cloud config 提供了配置中心高級功能：配置推送，配置刷新，配置隔離等。有如下場景的時優先從三者中選擇：
? 多環境（開發、測試、線上）
? 多租戶
? 灰度發布
? 資源隔離
註冊中心的本質是服務探活。註冊中心會對外提供可用服務地址查詢。比如gprc 可以使用註冊中心查詢存活實例，然後做負載均衡。在spring cloud 中的feign的負載均衡也都是基於註冊中心。
服務治理的最終目標就是實現自動化。但是自動化是建立在前面兩項之上的，擁有必要的數據我們才能自動化。
流量治理有兩種主要場景：激增大流量和灰度發布。激增大流量可以通過自動擴縮容解決，我們後面在說。
不同版本配置不同：這個問題需要使用配置中心解決。
不同版本流量不同：service mesh 可以解決這個問題。
要實現自動擴縮容，我們就需要知道哪些服務需要擴縮容。我們需要定義壹系列指標，用於衡量服務。
負載負載情況：我們可以監控pod cpu 情況；api 調用時長P99情況；api 調用頻率情況。
流量情況：api 調用數量；網絡情況。
通過各種指標我們可以知道服務狀態，從而我們可以指定擴縮容規則。
上面提到的每項技術都能展開講很久，之後的文章我們在詳細聊聊。