緊接上一篇，??服務(wù)化框架落地的挑戰(zhàn)和核心需求??，那么基于這些核心訴求，我們整個的微服務(wù)框架的模型是如何？又該具備哪些核心的治理能力呢？通過本文來一一知曉！

一、服務(wù)治理的理解

隨著互聯(lián)網(wǎng)的發(fā)展和容器化的發(fā)展，更進一步的推動了微服務(wù)化的建設(shè)，在微服務(wù)體系下，我們的服務(wù)治理，首先要做的就是針對我們大量的服務(wù)怎么更好的進行管理，保證我們系統(tǒng)在運行過程中能夠自動化的發(fā)現(xiàn)問題并自動解決一些問題，從而使我們的系統(tǒng)更加的穩(wěn)定。而這些治理的策略，至少要包括服務(wù)的限流、降級、容錯，以及服務(wù)的彈性伸縮、灰度發(fā)布，還有自動化的運維。

服務(wù)治理與管控包含幾大塊：服務(wù)的治理、服務(wù)的監(jiān)控、服務(wù)的可用性保障

(資料圖片)

服務(wù)的治理： 服務(wù)提供方的管理、服務(wù)使用方的管理、服務(wù)依賴的管理、服務(wù)的調(diào)用管理、服務(wù)的注冊和發(fā)現(xiàn)、服務(wù)的部署和升級、服務(wù)的版本化管理服務(wù)的監(jiān)控：數(shù)據(jù)采集、數(shù)據(jù)處理、鏈路跟蹤、白盒化的報表展示、系統(tǒng)級的監(jiān)控服務(wù)的可用性： 容錯（Failover、Failfast）、負載均衡、過載保護、服務(wù)降級、頻率限制

服務(wù)化框架的核心能力，括：RPC、服務(wù)發(fā)現(xiàn)與注冊、負載均衡、容錯、熔斷、限流、降級、權(quán)限、全鏈路日志跟蹤也是屬于服務(wù)治理的范疇之內(nèi)，當(dāng)然服務(wù)治理不僅僅包含這些核心能力，還包括各種管理，框架要做的就是全套服務(wù)，使用只管放心接入使用，所有治理相關(guān)的都由框架去實現(xiàn)。

二、微服務(wù)架構(gòu)模型

在我前面一篇文章??《微服務(wù)化框架落地的挑戰(zhàn)和核心需求》??中，我梳理了微服務(wù)化框架落地的一些挑戰(zhàn)和核心需求，那么針對這些核心需求，我們看看微服務(wù)要實現(xiàn)那些核心能力，也就是將上述需求進行實現(xiàn)，實現(xiàn)的時候基于現(xiàn)有的技術(shù)方案來進行抽象和統(tǒng)一，最終就可以形成我們的微服務(wù)框架。我將我理解的微服務(wù)架構(gòu)模型分為如下三部分：

核心能力，這個是框架必須要實現(xiàn)的，而且是任何一個服務(wù)化框架必備的能力擴展能力，這個是可以通過框架的插件化進行擴展的支持，當(dāng)然，框架本身也可以支持，但是從我個人的理解上來看，這個通過外部組件進行擴展，會更加契合整體的設(shè)計管理平臺，這個是圍繞整個服務(wù)化框架、業(yè)務(wù)系統(tǒng)、開發(fā)流程所需要依賴的一些基礎(chǔ)平臺，這些平臺可以更好的幫助我們進行服務(wù)的發(fā)布和上線，以及上線后的管理

三、微服務(wù)框架的治理能力設(shè)計

3-1、微服務(wù)框架的核心能力

微服務(wù)需要提供的核心能力包括：微服務(wù)架構(gòu)模型中通訊的基礎(chǔ)協(xié)議RPC、服務(wù)發(fā)現(xiàn)與注冊、負載均衡、容錯、熔斷、限流、降級、彈性擴縮容等

服務(wù)間通信：RPC

在微服務(wù)架構(gòu)中，服務(wù)之間的通信，一般都是通過 遠程訪問的方式來進行。遠程訪問的通信方式有很多中，包括：

從通信風(fēng)格上， 一般有 REST，RPC 和 定制協(xié)議這三種方式從交互方式上，按照交互對象的數(shù)量可以分為一對一和一對多，按照應(yīng)答返回的方式分為同步和異步。

RPC 是服務(wù)通訊的基礎(chǔ)，如果沒有統(tǒng)一的 RPC 框架，各個團隊就需要實現(xiàn)自己的一套接口協(xié)議定義、序列化、反序列化、網(wǎng)絡(luò)框架、服務(wù)治理等重復(fù)工作，因此可以說，微服務(wù)的核心就是要有一個統(tǒng)一的 RPC 框架，統(tǒng)一一套 RPC 是微服務(wù)化首先要解決的問題。通過統(tǒng)一的 RPC 框架協(xié)議，可以統(tǒng)一我們的接口定義，減少接入和學(xué)習(xí)的成本。同時，如果我們是基于已有的框架來實現(xiàn)，那么需要盡可能的保證兼容原有協(xié)議（比如基于 gRPC 的話，就要盡量保證兼容 gRPC 的接口協(xié)議）

業(yè)內(nèi)可選的 RPC 框架有很多，比如 dubbo/dubbox，motan，thrift，grpc，Karyon/Ribbon等，在我之前的公司，我們推行服務(wù)化框架的時候，是選擇了 gRPC 作為我們的基礎(chǔ)框架，然后基于 gRPC 豐富了很多服務(wù)治理的策略，整體線上運行良好，并且有較多業(yè)務(wù)接入。

服務(wù)注冊與發(fā)現(xiàn)

微服務(wù)架構(gòu)下，我們的業(yè)務(wù)都是由一系列獨立的微服務(wù)組成，那么這些微服務(wù)之間如何才能發(fā)現(xiàn)彼此？這就要求微服務(wù)之間存在一種發(fā)現(xiàn)的機制。這個機制，叫做服務(wù)發(fā)現(xiàn)，服務(wù)發(fā)現(xiàn)的核心功能就是服務(wù)注冊表，注冊表記錄了所有的服務(wù)節(jié)點的配置和狀態(tài)，每個微服務(wù)啟動后都需要將自己的信息注冊到服務(wù)注冊表，然后由微服務(wù)或者負載均衡系統(tǒng)到服務(wù)注冊表查詢可用服務(wù)。

服務(wù)端發(fā)現(xiàn)和客戶端發(fā)現(xiàn)模式

在設(shè)計上，服務(wù)發(fā)現(xiàn)機制的設(shè)計有服務(wù)端發(fā)現(xiàn)和客戶端發(fā)現(xiàn)兩種實現(xiàn)方式。

服務(wù)端發(fā)現(xiàn)模式(server-side):可以通過 DNS 或者帶 VIP 的負載均衡來實現(xiàn)。優(yōu)點是對客戶端無侵入性，客戶端只需要簡單的向負載均衡或者服務(wù)域名發(fā)起請求，無需關(guān)系服務(wù)發(fā)現(xiàn)的具體細節(jié)，也不用引入服務(wù)發(fā)現(xiàn)的邏輯缺點是不靈活，不方便難異化處理；并且同時需要引入一個統(tǒng)一的負載均衡器?？蛻舳税l(fā)現(xiàn)模式(client-side):需要客戶端服務(wù)注冊中心中查詢服務(wù)地址列表，然后再決定通過哪個地址請求服務(wù)。靈活性更高，可以根據(jù)客戶端的訴求進行滿足自身業(yè)務(wù)的負載均衡，但是客戶端需要引入服務(wù)發(fā)現(xiàn)的邏輯，同時依賴服務(wù)注冊中心常見服務(wù)注冊組件包括：zookeeper、etcd、Consul

在我曾經(jīng)的項目中，我們是通過客戶端發(fā)現(xiàn)模式來設(shè)計的，我們會把這個能力集成在微服務(wù)框架里面，然后微服務(wù)框架在啟動的時候，會將自己服務(wù)的信息注冊到注冊中心，注冊中心我們當(dāng)時選用的是 ETCD。

服務(wù)注冊和分析的一致性要求

服務(wù)注冊和服務(wù)發(fā)現(xiàn)，在實現(xiàn)時根據(jù)對一致性要求的不同，分成兩個流派：

強一致性比較常見的分布式一致性協(xié)議是 PAXOS 協(xié)議和 Raft 協(xié)議。相比 PAXOS 而言，Raft 協(xié)議易于理解和實現(xiàn)，因此最新的分布式一致性方案大都選擇 Raft 協(xié)議。zookeeper 采用的是 PAXOS 協(xié)議，consul 和 etcd 采用的是 Raft 協(xié)議。弱一致性如果對一致性要求不高，可以選擇以 DNS 為基礎(chǔ)的方案。弱一致性方案比較少，一般多用于 REST 或者 HTTP + json / web service 等簡單場合

雖然方案眾多，但是對于普通用戶的大多數(shù)場景而言，一般互聯(lián)網(wǎng)公司建議從 zookeeper、etcd、consul 這三個主流方案中選擇，我之前的設(shè)計里面，我們選擇的就是 etcd。

服務(wù)負載均衡

路由算法

服務(wù)負載均衡，一般情況下，是會和服務(wù)發(fā)現(xiàn)放在一起設(shè)計的，因為服務(wù)發(fā)現(xiàn)后，緊接著，就是要對服務(wù)進行路由，也就是服務(wù)的負載均衡，他們一般是作為一個整體系統(tǒng)來設(shè)計。雖然服務(wù)發(fā)現(xiàn)機制有服務(wù)端發(fā)現(xiàn)和客戶端發(fā)現(xiàn)兩種實現(xiàn)方式，但是無論放在哪里實現(xiàn)，針對服務(wù)進行路由，也就是負載均衡的核心的功能就是路由算法。常見的路由算法有：隨機路由、輪詢路由、最小壓力路由、最小連接數(shù)路由等。

目前微服務(wù)框架中，大都是在客戶端發(fā)現(xiàn)模式(client-side) 來實現(xiàn)服務(wù)路和負載均衡，一般也都會支持常見的負載均衡策略，如隨機，輪訓(xùn)，hash，權(quán)重，連接數(shù)【連接數(shù)越少，優(yōu)先級越高】。

心跳檢測與摘除

我們要對服務(wù)進行負載均衡的話，有一個先決條件，就是我們要路由的服務(wù)，一定是可用的，怎么保證服務(wù)可用，那么就需要進行心跳檢測與摘除：進行心跳檢測，每個 N 秒檢測一次，超過 M 次心跳連不上就進行摘除。這樣的話，就可以保證我們路由的服務(wù)都是正常的。

多機房路由

如果服務(wù)部署在多個不同的機房，那么我們路由的時候，一般的策略就是優(yōu)先調(diào)用本地機房，失敗重試也是本機房調(diào)用，如果本地機房沒有可用節(jié)點則路由到其他機房。同時可以增加一個開關(guān)控制是否 failover 到遠程機房。

服務(wù)容錯

負載均衡和容錯是服務(wù)高可用的重要手段。服務(wù)容錯的設(shè)計在業(yè)內(nèi)有個基本原則，就是“Design for Failure”。常見的服務(wù)容錯策略如請求重試、限流、降級、熔斷等策略

超時與重試

超時是一種最常見的服務(wù)容錯模式，只要涉及到網(wǎng)絡(luò)調(diào)用，那么就有可能因為網(wǎng)絡(luò)問題、依賴服務(wù)問題，導(dǎo)致調(diào)用的時候出現(xiàn)請求超時，一般情況下，我們都會對每個請求設(shè)置好超時時間(一般接口不應(yīng)該超過 1s)，如果超時未返回，那么就會斷開連接，從而可以做對應(yīng)的處理，比如返回失敗、釋放連接、釋放資源等。如果不做超時處理，那么可能會導(dǎo)致請求一直卡在，然后一直占用系統(tǒng)資源，從而使得整個系統(tǒng)資源耗盡，或者用戶一直刷不到數(shù)據(jù)。

重試，是指下游出錯（不管是真的出錯，還是超時）的時候進行使用，通過重試可以較好的保證數(shù)據(jù)的可靠性，尤其是當(dāng)下游有網(wǎng)絡(luò)波動導(dǎo)致超時的場景下，會比較有效。重試的設(shè)計，有幾個要點：

重試的次數(shù)，一定要有一個最大值，經(jīng)過一定的重試次數(shù)，還是拿不到正確的數(shù)據(jù)，那么就應(yīng)該返回錯誤，而不能一直重試，重試的時間間隔，需要設(shè)置，不能不停的重試，避免因為重試過多、過快導(dǎo)致系統(tǒng)負擔(dān)增大，重試的時間策略，我們一般都會引入Exponential Backoff 的策略，也就是所謂的 "指數(shù)級退避"。在這種情況下，每一次重試所需要的 sleep 時間都會指數(shù)增加。這其實和 TCP 的擁塞控制有點像。

服務(wù)限流

限流和降級都是用來保證核心服務(wù)穩(wěn)定性的有效策略。限流是指限制每個服務(wù)(或者接口)的最大訪問量，超過這個閾值就會被拒絕，是從用戶訪問的請求量量去考慮問題；降級是指高峰期對非核心的系統(tǒng)進行降級從而保證核心服務(wù)的可用性，是從系統(tǒng)功能的優(yōu)先級角度考慮問題。

限流的目的是為了保證我們的系統(tǒng)不過載，當(dāng)系統(tǒng)流量增大的時候，通過限流，可以保證能夠在系統(tǒng)可承受的壓力之下穩(wěn)定運行，否則，一旦過載則會導(dǎo)致整個系統(tǒng)不可用。在我們實際應(yīng)用中，到處都可以看到限流的一些策略場景，比如 Nginx 的 limit_conn 模塊用來限制最大并發(fā)連接數(shù)、limit_req 模塊用來限制每秒平均速率。

常見的限流方式可以分為兩類：基于請求限流和基于資源限流。

基于請求限流。從外部系統(tǒng)的訪問請求量的角度來考慮限流，常見的方式有：限制總量、限制時間量?；谫Y源限流。從內(nèi)部系統(tǒng)的使用資源的角度來考慮限流，找到系統(tǒng)內(nèi)部影響性能的關(guān)鍵資源，對其使用上限進行限制。常見的內(nèi)部資源有：連接數(shù)、文件句柄、線程數(shù)、請求隊列等。

限流的維度和級別主要可以分為以下幾類：服務(wù)級別維度的限流、接口級別維度的限流、業(yè)務(wù)細粒度級別維度的限流。

服務(wù)級別維度的限流、接口級別維度的限流主要目的是保護我們的系統(tǒng)，防止服務(wù)過載。業(yè)務(wù)細粒度級別維度的限流。主要目的是防刷，也是防止單用戶或占用過多處理能力，影響其他用戶。就是我們根據(jù)業(yè)務(wù)內(nèi)部的具體維度去限流，比如我們可以通過 APPID 和 UID 這兩個常見的業(yè)務(wù)維度。appid 就是對應(yīng)某一類請求或者一個業(yè)務(wù)類型，UID 就是對應(yīng)一個唯一的用戶。

服務(wù)降級

首先，降級之前，一定是要先限流，限流之后，系統(tǒng)還是可能存在問題，才考慮降級。同時，降級不僅僅是開發(fā)人員的事情，還需要和產(chǎn)品人員溝通和協(xié)商降級后的處理以及對應(yīng)的效果。

降級設(shè)計（Degradation）本質(zhì)是為了解決資源不足和訪問量過大的問題，當(dāng)資源和訪問量出現(xiàn)矛盾的時候，在有限的資源下，為了能夠扛住大量的請求，我們就需要對系統(tǒng)進行降級操作。降級是指我們劃分好系統(tǒng)的核心功能和非核心功能，然后當(dāng)我們的系統(tǒng)超過最大處理能力之后，直接關(guān)閉掉非核心的功能，從而保障核心功能的可用。關(guān)閉掉非核心的功能后可以使我們的系統(tǒng)釋放部分資源，從而可以有資源來處理核心功能。

熔斷設(shè)計

當(dāng)下游服務(wù)出現(xiàn)異常的時候（包括出錯、超時），一般我們會進行短時間且少量的重試操作，但是如果重試幾次依然無法解決，那么我們也不能一直重試，這樣會給下游帶來更大的壓力。

熔斷，就是在重試、限流等策略執(zhí)行之后，還是無法解決的情況下的另外一種保護系統(tǒng)的策略手段，通過熔斷，可以較好的保護好下游服務(wù)。熔斷最重要的價值在于限制故障影響范圍，通過熔斷減少或拒絕請求從而有利于下游系統(tǒng)的恢復(fù)。

熔斷系統(tǒng)設(shè)計的思路就是圍繞熔斷的三個狀態(tài)來設(shè)計，一般我們通過三個模塊（異常請求計算模塊、熔斷探測恢復(fù)模塊、熔斷記錄和報警模塊）來設(shè)計，主要的流程就是，在 Close 狀態(tài)下，當(dāng)我們的請求失敗 N 次后，在 X 時間不再繼續(xù)請求，實現(xiàn)熔斷，進入 Half-Open 狀態(tài)；與此同時，在 X 時間后恢復(fù) M% 的請求，如果 M% 的請求都成功，則恢復(fù)到正常狀態(tài)，進入 close 狀態(tài)，否則再熔斷 Y 時間，依此循環(huán)。如果一直無法恢復(fù)，那么可以直接進入 Open 狀態(tài)。

熔斷和降級這兩個策略，看著比較像，字面的意思上來看都是要快速拒絕掉請求。但是他們是兩個維度的設(shè)計，降級的目的是應(yīng)對系統(tǒng)自身的故障，而熔斷的目的是應(yīng)對我們系統(tǒng)依賴的外部服務(wù)故障的情況。

集群容錯

微服務(wù)化后，服務(wù)可能會部署到多個不同的機房，也就是可能會部署到多個不同的集群上，為此，就有集群容錯一說，集群容錯里面，我們常見的兩個策略是

failfast 策略，快速失敗，只發(fā)起一次調(diào)用，失敗立即報錯。設(shè)計的時候需要注意控制超時時間的判斷和記錄：連接超時、響應(yīng)超時failover 策略，失敗自動切換，當(dāng)出現(xiàn)失敗，重試到其他集群的服務(wù)優(yōu)先調(diào)用本地機房，失敗也是本機房調(diào)用默認不 failover 到遠程機房，開關(guān)開啟的時候才啟用一定比例的 failover 策略調(diào)用到遠程機房需要根據(jù)錯誤碼來區(qū)分不同的響應(yīng)信息決定是否重試，比如404 400等情況是不需要重試的

彈性擴縮容

彈性擴縮容就要求應(yīng)用服務(wù)設(shè)計為無狀態(tài)模型，一般微服務(wù)框架無法實現(xiàn)彈性擴縮容，還需要配合其他的技術(shù)如容器技術(shù)（Kubernetes）、云服務(wù)技術(shù)等，這樣才能實現(xiàn)彈性。

這里更多的是結(jié)合其他能力比如 K8s，特意單獨提出來，是為了說明這個的重要性。

3-2、微服務(wù)框架的擴展能力

API 接入層網(wǎng)關(guān)

微服務(wù)需要一個統(tǒng)一的 API 網(wǎng)關(guān)，負責(zé)外部系統(tǒng)的訪問操作。API 網(wǎng)關(guān)是外部系統(tǒng)訪問的入口，所有的外部系統(tǒng)接?內(nèi)部系統(tǒng)都需要通過 API 網(wǎng)關(guān)，我們一般的后端服務(wù)，外網(wǎng)是無法直接訪問的，API 需要做一層處理，主要包括接入鑒權(quán)（是否允許接入）、權(quán)限控制（可以訪問哪些功能）、傳輸加密、請求路由、流量控制等功能。一切 ok 后才能訪問到我們的內(nèi)網(wǎng)服務(wù)。

監(jiān)控和告警

監(jiān)控系統(tǒng)的開源代表作： Prometheus + Grafana，遵循 OpenMetrics 規(guī)范，基本數(shù)據(jù)格式分為 Gauge、Count、Summary、Histogram。在我們之前的實現(xiàn)中，公司也是采用普羅米修斯【prometheus】+ dashboard(grafana) 來實現(xiàn)整套監(jiān)控系統(tǒng)的。

需要采集、監(jiān)控的指標(biāo)項有如下：

QPS組合查詢 ，節(jié)點 ，服務(wù)，region，接口，時間 等latency組合查詢 ，節(jié)點 ，服務(wù)，region，接口，時間 等SLA指定時間段內(nèi)請求成功且耗時低于X毫秒的請求個數(shù)比例，API接口級別消費節(jié)點當(dāng)前消費節(jié)點的狀態(tài)，有多少個服務(wù)節(jié)點，健康狀態(tài)，熔斷狀態(tài)等

配置系統(tǒng)

我們的一個業(yè)務(wù)服務(wù)，一般，都會有一個對應(yīng)的配置文件，而且，我們需要盡可能的做到動態(tài)配置，而不是每次修改配置都要重新發(fā)布服務(wù)。比如說，我們定義好一個 Elasticserach 的賬號密碼，那么這個最好的方式，肯定是在配置文件里面，和代碼隔離； 比如我們定義一個域名前綴，而這個前綴有可能會改變；比如我們定義一個請求的重試次數(shù)，這些，建議都是通過配置文件來管理。

每個服務(wù)一個配置文件，微服務(wù)化后，大量服務(wù)，就會有大量配置文件，那么這些配置文件怎么統(tǒng)一管理，怎么讀取，怎么發(fā)布，就需要一個配置系統(tǒng)，配置系統(tǒng)也需要逐步演進為自動化治理方向，因此就需要一個完善的統(tǒng)一的自動化配置中心。

日志系統(tǒng)

遠程日志上報

日志的重要性不言而喻，每次服務(wù)出問題，用戶出問題，我們要查問題，必然要通過日志，而我們的服務(wù)這么多，部署的機器這么多，我們不能每次出問題之后，還要去每臺機器上一個個的檢索。為此，這個就必然需要能夠?qū)⑷罩具M行遠程上報，然后統(tǒng)一收集和管理。

這里，遠程日志組件的代表作是 ELK 系統(tǒng)：Elasticsearch, Logstash, Kibana。 通過引入 ELK，我們在代碼里面，將日志上報，后續(xù)就可以通過 Kibana 去根據(jù)情況進行檢索，然后拉取出對應(yīng)的日志。

traceID

在微服務(wù)架構(gòu)中，一個客戶端請求的接入，往往涉及到后端一系列服務(wù)的調(diào)用，如何將這些請求串聯(lián)起來？業(yè)界常用的方案是采用全局流水號【traceID】串聯(lián)起來。通過全局流水號【traceID】，從日志里面可以拉出整條調(diào)用鏈路。

traceID 需要在所有日志里體現(xiàn)，包括訪問日志、錯誤日志、警告日志等任何日志，唯一標(biāo)識一個請求。調(diào)用鏈上每個環(huán)節(jié)的入口都先判斷是否存在 traceID ，如果沒有 traceID 則生成一個唯一值，存在請求上下文 context 中，輸出日志的時候就可以把 traceID 打印并輸出。然后調(diào)用其他服務(wù)的時候同時傳遞統(tǒng)一名稱的header 給目標(biāo)服務(wù)，目標(biāo)服務(wù)處理請求是有獲取到 traceID 就設(shè)置到自己的請求上線文，以此類推，整個請求鏈條就都使用統(tǒng)一的 traceID。同時 APP 客戶端也可以傳遞一個自己的請求業(yè)務(wù)標(biāo)識(可能不一定會唯一)，服務(wù)端把傳上來的請求標(biāo)識作為 traceID 的一部分

分布式鏈路追蹤系統(tǒng)和 OpenTelemetry

一般公司的后端架構(gòu)應(yīng)用構(gòu)建在不同的服務(wù)模塊集上，可能是由不同的團隊開發(fā)、使用不同的編程語言來實現(xiàn)、部署在多臺服務(wù)器上。對于這種分布服務(wù)系統(tǒng)，傳統(tǒng)查日志方式排查問題繁瑣，用時較久。因此，需要一個工具能夠梳理這些服務(wù)之間的關(guān)系，感知上下游服務(wù)的形態(tài)。比如一次請求的流量從哪個服務(wù)而來、最終落到了哪個服務(wù)中去？服務(wù)之間是RPC調(diào)用，還是HTTP調(diào)用？一次分布式請求中的瓶頸節(jié)點是哪一個，等等。如果我們需要跟蹤某一個請求在微服務(wù)中的完整路徑就要引入我們的分布式鏈路追蹤系統(tǒng)了，目前業(yè)內(nèi)分布式鏈路追蹤系統(tǒng)基本上都是以 ??Google Dapper?? (??中文版??) 為藍本進行設(shè)計與開發(fā)。

OpenTracing 制定了一套平臺無關(guān)、廠商無關(guān)的Trace協(xié)議，使得開發(fā)人員能夠方便的添加或更換分布式追蹤系統(tǒng)的實現(xiàn)。在2016年11月的時候CNCF技術(shù)委員會投票接受OpenTracing作為Hosted項目，這是CNCF的第三個項目，第一個是Kubernetes，第二個是Prometheus，可見CNCF對OpenTracing背后可觀察性的重視。比如大名鼎鼎的Zipkin、Jaeger都遵循OpenTracing協(xié)議。

然后時間走到 2022 年，OpenTracing 都已經(jīng)快要過時， 現(xiàn)在最優(yōu)的是 OpenTelemetry。OpenTelemetry 的終態(tài)就是實現(xiàn) Metrics、Tracing、Logging 的融合，作為CNCF可觀察性的終極解決方案，OpenTelemetry 可觀測性領(lǐng)域的標(biāo)準，OpenTelemetry 的三大數(shù)據(jù)模型如下：。

**Tracing：分布式追蹤，觀測請求調(diào)用鏈路。**提供了一個請求從接收到處理完畢整個生命周期的跟蹤路徑，通常請求都是在分布式的系統(tǒng)中處理，所以也叫做分布式鏈路追蹤。**Metrics：指標(biāo)監(jiān)控，監(jiān)控服務(wù)質(zhì)量狀況。**提供量化的系統(tǒng)內(nèi)/外部各個維度的指標(biāo)，一般包括Counter、Gauge、Histogram等。**Logging：服務(wù)日志，用來分析服務(wù)故障。**提供系統(tǒng)/進程最精細化的信息，例如某個關(guān)鍵變量、事件、訪問記錄等。

3-2、微服務(wù)體系下的管理平臺

服務(wù)編排管理平臺

在之前的文章里面，我們談到，微服務(wù)和容器化結(jié)合是必然趨勢，在當(dāng)下，容器化平臺基本都是采用 K8s ，那么基于 K8s 平臺，我們的服務(wù)編排當(dāng)然就需要圍繞 K8s 來建設(shè)了。微服務(wù)框架 + K8s 容器平臺 是當(dāng)今互聯(lián)網(wǎng)業(yè)務(wù)的黃金標(biāo)準

如果是采用公有云的話，那么服務(wù)編排的管理平臺，公有云已經(jīng)幫你提供了。

如果是私有云的話，那么我們也需要基于 K8s 來搭建一套我們自己的服務(wù)編排的管理平臺，用來幫助開發(fā)人員更好的去發(fā)布服務(wù)、線上管理服務(wù)。這個平臺上的的功能可以包括：

服務(wù)發(fā)布和管理灰度發(fā)布服務(wù)重啟/停止支持回滾服務(wù)登錄登錄到服務(wù)所在的容器里面服務(wù)擴縮容手動擴縮容自動擴縮容打通外部平臺如監(jiān)控平臺、日志平臺如服務(wù)限流和降級平臺支持 debug 管理工具比如可以動態(tài)查看 go 相關(guān)的 runtime 信息，或者 pprof 等

DevOps 平臺

微服務(wù)體系下，有大量的服務(wù)需要進行運維管理，包括測試、發(fā)布上線、灰度放量、擴縮容等，那我們怎么合理的去處理好這些運維能力呢，這里就必須要有一套自動化運維管理體系，而這套東西，在業(yè)界，有一個叫做 DevOps 的文化，基于 DevOps 可以方便快捷的實現(xiàn) CICD。CI 就是持續(xù)集成，是一種質(zhì)量反饋機制，目的是盡快發(fā)現(xiàn)代碼中的質(zhì)量問題，CD 就是 持續(xù)部署，是指能夠自動化、多批次、可控的實現(xiàn)軟件部署，控制故障的影響范圍或方便輕松的解決故障問題。通過 DevOps 的建設(shè)，可以實現(xiàn)軟件生產(chǎn)流水線和軟件運維自動化。

DevOps 平臺這里，更多的集成代碼管理平臺、流水線構(gòu)建、單測測試、接口測試判斷等。比如我們開發(fā)完一個功能，那么代碼首先要合入到 master，然后對代碼進行一些檢測，隨后打 tag，構(gòu)造鏡像，最后發(fā)布。這一系列的流程，如果沒有一個合適的管理平臺，每個步驟都手動去處理的話，那么就會相當(dāng)麻煩，而且耗時。

DevOps 平臺的一些建議和實戰(zhàn)經(jīng)驗：

代碼分支合入 master 的時候，進行檢測校驗代碼靜態(tài)檢查代碼規(guī)范檢查單測覆蓋度檢測接口測試檢測檢測通過后，可以合入 master 分支，然后自動打 tag，構(gòu)造線上發(fā)布的鏡像包鏡像包構(gòu)造完后，自動和服務(wù)編排管理平臺打通，推送鏡像到服務(wù)編排管理平臺，自動觸發(fā)發(fā)布流程發(fā)布流程需要有灰度的過程可隨時中斷和回滾

自動化測試平臺

微服務(wù)化會帶來服務(wù)模塊增多的問題，會在一定程度上帶來開發(fā)成本的提升，所以需要通過配套的工具鏈來減少服務(wù)化后的開發(fā)成本。自動化測試平臺的建設(shè)，可以有助于我們在開發(fā)測試階段就盡可能的減少系統(tǒng)出現(xiàn)的問題，提供一層保障。自動化測試平臺主要的目的是用來進行接口測試和接口撥測，后續(xù)也可以進一步去整合 流量錄制和回放、全鏈路壓測等相關(guān)功能。

自動化測試平臺的主要的目的就是確保你上線發(fā)布的服務(wù)是正常運行的，而且盡量做到自動發(fā)現(xiàn)問題而不是通過人工反饋后才能知道問題。接口撥測這個事情，類似巡檢，就是每個一段時間，自動調(diào)用你的后端接口，如果出現(xiàn)非預(yù)期的錯誤，那么就認為異常，可以進行告警。

由于這些都是基礎(chǔ)功能，因此沒有必要每個團隊都各自搞一套，應(yīng)該是公司內(nèi)部統(tǒng)一搞一套這樣的系統(tǒng)。

最后

這篇文章首發(fā)在我微信公眾號【后端系統(tǒng)和架構(gòu)】中，??點擊這里可以前往公眾號查看原文鏈接，如果對你有幫助，歡迎前往關(guān)注，更加方便快捷的接收最新優(yōu)質(zhì)文章??

推薦閱讀

推薦閱讀我的其他文章：

??《高并發(fā)架構(gòu)和系統(tǒng)設(shè)計經(jīng)驗》????《TCP 長連接層的設(shè)計和 在 IM 項目中實戰(zhàn)應(yīng)用》????《萬字解讀云原生時代，如何從 0 到 1 構(gòu)建 K8s 容器平臺的 LB（Nginx）負載均衡體系??》??《我終于統(tǒng)一了團隊的技術(shù)方案設(shè)計模板》??