原文地址：https://xintu.infoq.cn/article/AJj3lKQyaKVeA08Bgj9e

背景

為數(shù)以億計的用戶提供優(yōu)質(zhì)的視頻服務(wù)的愛奇藝技術(shù)產(chǎn)品團(tuán)隊，為了適應(yīng)業(yè)務(wù)的快速迭代和創(chuàng)新，并支撐海量的用戶請求，很多團(tuán)隊都對各自的業(yè)務(wù)系統(tǒng)自發(fā)地進(jìn)行了微服務(wù)架構(gòu)的改造。

在微服務(wù)化的過程中，各業(yè)務(wù)團(tuán)隊根據(jù)自身需要選擇了不同的開源框架，如 Apache Dubbo/Spring Cloud 等，此外也存在一些自研性質(zhì)的框架；另外為了滿足對微服務(wù)應(yīng)用的監(jiān)控等需求，不少團(tuán)隊還自行維護(hù)了監(jiān)控系統(tǒng)等基礎(chǔ)設(shè)施。

隨著實踐的深入，一些問題逐漸開始暴露，這其中包括：

·部分基礎(chǔ)設(shè)施存在重復(fù)建設(shè)，在資源浪費的同時穩(wěn)定性也不易保證；

·由于使用的技術(shù)架構(gòu)和 SDK 不統(tǒng)一，最佳實踐難以在團(tuán)隊間快速推廣；

·技術(shù)架構(gòu)不統(tǒng)一導(dǎo)致在東西向流量中大量引入了業(yè)務(wù)自行維護(hù)的網(wǎng)關(guān)，使得鏈路加長，影響排障效率和響應(yīng)延時。

為了解決以上問題，愛奇藝中間件團(tuán)隊充分聽取了業(yè)務(wù)在微服務(wù)實踐中的需求和問題，推出了愛奇藝的微服務(wù)標(biāo)準(zhǔn)架構(gòu)。在標(biāo)準(zhǔn)架構(gòu)的建設(shè)過程中，我們主要遵循了以下的一些原則：

1.架構(gòu)統(tǒng)一：同一技術(shù)領(lǐng)域往往有多種技術(shù)實現(xiàn)，但是過多的技術(shù)框架的采用容易造成維護(hù)成本過高，缺乏專人支持等問題。在微服務(wù)標(biāo)準(zhǔn)架構(gòu)的選型過程中，我們綜合了各開源項目的實際情況和業(yè)界的主流技術(shù)方案，將各個領(lǐng)域中的技術(shù)選型進(jìn)行了統(tǒng)一，每個領(lǐng)域的技術(shù)選型原則上均不超過 1 種。

2.可擴(kuò)展：微服務(wù)標(biāo)準(zhǔn)架構(gòu)中有不少開發(fā) SDK 的選型，為了滿足各個開發(fā)團(tuán)隊不同的業(yè)務(wù)需求，需要保證各個 SDK 的可擴(kuò)展性，如果開源版本無法滿足內(nèi)部需求的，愛奇藝中間件團(tuán)隊都會維護(hù)統(tǒng)一化的內(nèi)部定制版本。

3.高可用：標(biāo)準(zhǔn)架構(gòu)的建設(shè)目的之一是將各個團(tuán)隊維護(hù)的基礎(chǔ)設(shè)施（如注冊中心、監(jiān)控系統(tǒng)等）逐漸收攏至內(nèi)部的公共平臺。對相關(guān)平臺的技術(shù)架構(gòu) review 及可用性維護(hù)也是我們的重要工作之一，此外我們還建設(shè)了服務(wù)成熟度體系 SMMI，會定期對核心系統(tǒng)及基礎(chǔ)服務(wù)進(jìn)行成熟度評估。

4.技術(shù)演進(jìn)：開源軟件均有其生命周期，需要充分考慮各個軟件的社區(qū)維護(hù)情況，比如在熔斷技術(shù)選型上，我們在標(biāo)準(zhǔn)架構(gòu)中主推了 Sentinel，而不是目前已經(jīng)停止維護(hù)的 Hystrix。另外標(biāo)準(zhǔn)架構(gòu)也并非一個一成不變的體系，對于新技術(shù)的采納，我們也提供了標(biāo)準(zhǔn)化的流程，確保我們的技術(shù)體系能持續(xù)迭代。

5.內(nèi)部開源：在標(biāo)準(zhǔn)架構(gòu)的建設(shè)過程中，在愛奇藝內(nèi)部開展了內(nèi)部開源的協(xié)作模式。除了基礎(chǔ)服務(wù)部門以外，也鼓勵業(yè)務(wù)團(tuán)隊參與到這些基礎(chǔ)服務(wù)的維護(hù)工作中來，共同打造一個即符合業(yè)務(wù)需求，又有一定業(yè)界領(lǐng)先度的微服務(wù)技術(shù)體系，這樣也進(jìn)一步促進(jìn)了相關(guān)標(biāo)準(zhǔn)架構(gòu)的推廣和完善。

愛奇藝微服務(wù)標(biāo)準(zhǔn)架構(gòu)

下圖展示了愛奇藝微服務(wù)標(biāo)準(zhǔn)架構(gòu)的全貌：

標(biāo)準(zhǔn)架構(gòu)主要包括如下主要內(nèi)容：

*統(tǒng)一的微服務(wù)開發(fā) SDK：核心開發(fā)框架 Dubbo/Spring Cloud；熔斷限流框架 Sentinel 等；

*統(tǒng)一的微服務(wù)基礎(chǔ)設(shè)施，包括：

·注冊中心：Nacos/consul；

·服務(wù)網(wǎng)關(guān)：基于 kong 進(jìn)行二次開發(fā)的網(wǎng)關(guān)平臺，提供鑒權(quán)、限流等功能；

· 配置中心：基于攜程 Apollo 進(jìn)行二次開發(fā)的平臺

·指標(biāo)監(jiān)控：prometheus 集群托管服務(wù)；

·鏈路監(jiān)控：全鏈路平臺（基于 skywalking 進(jìn)行定制開發(fā)）；

·混沌工程：在 ChaosBlade 基礎(chǔ)上進(jìn)行二次研發(fā)，提供各類故障演練功能。

*統(tǒng)一的微服務(wù)平臺：QDAS（QIYI Distributed Application Service，愛奇藝分布式應(yīng)用服務(wù)），提供微服務(wù)應(yīng)用生命周期管理、服務(wù)治理、服務(wù)市場等功能。

標(biāo)準(zhǔn)架構(gòu)生態(tài)建設(shè)

以下將從微服務(wù) SDK、注冊中心、監(jiān)控體系、熔斷限流、API 網(wǎng)關(guān)、微服務(wù)平臺等幾個微服務(wù)標(biāo)準(zhǔn)架構(gòu)的核心點做一些展開的介紹。

開源 SDK 定制

根據(jù)各個業(yè)務(wù)團(tuán)隊的需求，愛奇藝中間件團(tuán)隊主要對 Dubbo SDK 做了以下幾方面的擴(kuò)展：

1.基礎(chǔ)設(shè)施的適配：包括注冊中心、監(jiān)控系統(tǒng)、內(nèi)部的容器平臺等等；

2.可用性增強(qiáng)：包括非健康實例隔離以及區(qū)域就近路由的機(jī)制；

3.安全性增強(qiáng)：支持了服務(wù)間調(diào)用的認(rèn)證機(jī)制；

4.序列化：增加了對 protobuf 序列化方式的支持。

注冊中心演進(jìn)

注冊中心在微服務(wù)應(yīng)用中是最重要的基礎(chǔ)設(shè)施之一，原先在愛奇藝內(nèi)部，注冊中心的選型并不統(tǒng)一，之前在線上運行的注冊中心有 ZooKeeper、eureka、consul 等。事實上，ZooKeeper、eureka 等并不是當(dāng)前業(yè)界中微服務(wù)注冊中心的最佳選型，以 Zookeeper 為例，其主要缺點包括：

1.無法橫向擴(kuò)展；

2.作為一個一致性的系統(tǒng)，在網(wǎng)絡(luò)分區(qū)會產(chǎn)生不可用。

在調(diào)研了業(yè)界的各個方案后，我們選用了 Nacos 作為我們下一代的微服務(wù)注冊中心。右下角是 Nacos 的整體介紹圖，選用 Nacos 的主要原因是：

1.高性能，可以橫向擴(kuò)展；

2.既適用于傳統(tǒng)為服務(wù)架構(gòu)，也能適用于云原生環(huán)境，包括支持與 Istio 控制面對接；

3.提供了 Nacos-Sync 組件，可與其他注冊中心進(jìn)行數(shù)據(jù)同步，也使注冊中心的遷移變得簡便。

Nacos 高可用部署

在部署 Nacos 服務(wù)時，我們充分考慮了服務(wù)部署架構(gòu)方面的高可用性。目前我們的 Nacos 服務(wù)是一個大集群，實例分布在多個不同的可用區(qū)中，在每個可用區(qū)內(nèi)部，我們會申請不同的 VIP，最終的內(nèi)網(wǎng)域名是綁定在這些 VIP 上。另外其底層所使用的 MySQL 也采用了多機(jī)房部署。這樣的架構(gòu)可以避免單個 Nacos 實例或者單機(jī)房故障造成整個 Nacos 服務(wù)的不可用。以下是一些可能的故障場景的模擬：

1.單個 Nacos 實例故障：利用 Load Balancer 集群提供的健康檢查能力自動從 VIP 中摘除；

2.某個 VIP 集群故障：利用客戶端重試機(jī)制解決；

3.單個 AZ 故障：利用客戶端重試機(jī)制解決；

4.MySQL 集群故障：MySQL 與注冊發(fā)現(xiàn)過程無關(guān)，不受影響；

5.整個 Nacos 服務(wù)故障：客戶端兜底機(jī)制，如服務(wù)實例緩存等。

注冊中心平滑遷移方案

接下來將簡單介紹一下如何使用 Nacos-Sync 進(jìn)行注冊中心的平滑遷移。

1.首先要部署一個 Nacos-Sync 服務(wù)，從舊的注冊中心向 Nacos 同步數(shù)據(jù)。Nacos-Sync 支持集群化部署，部署多個實例時，其向新注冊中心的寫入時冪等的，并且它原生支持 Dubbo 的注冊數(shù)據(jù)格式；

2.檢查數(shù)據(jù)無誤后，首先升級 Consumer 端，改為從 Nacos 注冊中心進(jìn)行發(fā)現(xiàn)。這時的服務(wù)發(fā)現(xiàn)的數(shù)據(jù)均是由 Nacos-Sync 從舊的注冊中心同步過來的；

3.再升級 Provider 端，改為向 Nacos 進(jìn)行服務(wù)注冊；

4.下線 Nacos-Sync 服務(wù)及舊的注冊中心，整個遷移流程就結(jié)束了。

以上方案的主要優(yōu)點包括：

*服務(wù)提供方和消費方的升級完全獨立，可以自行進(jìn)行；

*遷移涉及的應(yīng)用僅需升級一次。

監(jiān)控體系建設(shè)

服務(wù)監(jiān)控是所有業(yè)務(wù)團(tuán)隊都極為關(guān)注的主題。完整的微服務(wù)監(jiān)控體系一般需要有以下 3 個方面組成：

1.指標(biāo)監(jiān)控：包括 QPS/響應(yīng)延時/錯誤率等黃金指標(biāo)、業(yè)務(wù)的自定義指標(biāo)、JAVA 應(yīng)用的 JVM 指標(biāo)，此外還需要采集和基礎(chǔ)環(huán)境的相關(guān)指標(biāo)，包括 CPU/內(nèi)存利用率等；

2.日志監(jiān)控：如錯誤日志的數(shù)量；也可以利用 AI 技術(shù)，對日志的模式進(jìn)行統(tǒng)計分析等；

3.鏈路監(jiān)控：由于微服務(wù)調(diào)用關(guān)系的復(fù)雜性，調(diào)用鏈追蹤也是非常必要的，它可以幫助業(yè)務(wù)人員更好地分析應(yīng)用間的依賴關(guān)系，并能夠監(jiān)控各個調(diào)用關(guān)系上的核心指標(biāo)。

指標(biāo)監(jiān)控

指標(biāo)監(jiān)控方面，我們內(nèi)部圍繞著 Prometheus 建設(shè)了一套較為完整的監(jiān)控和告警的標(biāo)準(zhǔn)化方案。這里面要解決幾個問題：

首先是指標(biāo)計算的問題，為了降低侵入性，我們在 skywalking agent 的基礎(chǔ)上進(jìn)行了二次開發(fā)，可以自動攔截 Spring MVC/Dubbo 等主流框架的調(diào)用，統(tǒng)計其調(diào)用次數(shù)、處理耗時、是否錯誤等等。

其次是指標(biāo)采集的問題，Prometheus 是采用拉模式采集指標(biāo)的，對于微服務(wù)場景一般是利用 Prometheus 的服務(wù)發(fā)現(xiàn)機(jī)制。Prometheus 默認(rèn)集成了 consul、k8s 等服務(wù)發(fā)現(xiàn)方式，不過并未對 Nacos 注冊中心直接提供支持，我們在開源的 Nacos adapter 的基礎(chǔ)上進(jìn)行了改造，使得 Prometheus 能夠從 Nacos 中發(fā)現(xiàn)要采集的應(yīng)用實例信息。

指標(biāo)查看主要采用了 grafana，我們提供了一套通用化的配置模板，業(yè)務(wù)也可以根據(jù)需要自行擴(kuò)展。

告警方面，我們將告警策略設(shè)置在 Prometheus 中，具體的告警會由 alert-manager 通過 adapter 發(fā)送給內(nèi)部的監(jiān)控告警平臺。

監(jiān)控 dashboard 查看、告警策略設(shè)置、訂閱的入口統(tǒng)一設(shè)置在我們內(nèi)部的全鏈路監(jiān)控平臺上，用戶可以在該平臺上查看進(jìn)行相應(yīng)的操作。

下圖展示了服務(wù)監(jiān)控界面：

鏈路追蹤

鏈路追蹤的基本原理也和 google 關(guān)于 Dapper 的論文一致，應(yīng)用程序通過埋點的 agent 產(chǎn)生調(diào)用鏈數(shù)據(jù)，通過日志采集或者網(wǎng)絡(luò)直接上報的方式統(tǒng)一匯總至 kafka，通過我們的實時分析程序進(jìn)行分析。分析結(jié)果大致可以分為三類，原始的調(diào)用鏈數(shù)據(jù)我們會使用 ES+HBase 進(jìn)行存儲，調(diào)用關(guān)系上的實時監(jiān)控數(shù)據(jù)我們采用時序數(shù)據(jù)庫 druid 進(jìn)行存儲，拓?fù)潢P(guān)系采用圖數(shù)據(jù)存儲。

鏈路追蹤主要提供了一下功能：

1.調(diào)用依賴關(guān)系分析：提供了服務(wù)間依賴及接口間依賴的多個層次粒度，支持 MySQL/Redis 等各類中間件，為開發(fā)人員提供各種上下游依賴的直觀展示；

2.服務(wù)間調(diào)用關(guān)系指標(biāo)：提供 QPS/響應(yīng)延時錯誤率等核心指標(biāo)監(jiān)控，且能在一個調(diào)用關(guān)系上同時提供客戶端及服務(wù)端兩個視角的監(jiān)控值，便于進(jìn)行問題定位；

3.程序異常分析：在調(diào)用鏈數(shù)據(jù)中心記錄異常類型及堆棧信息并進(jìn)行分析，支持展示某個應(yīng)用的程序異常種類及每分鐘發(fā)生次數(shù)等；

4.日志關(guān)聯(lián)：將調(diào)用鏈與業(yè)務(wù)日志進(jìn)行關(guān)聯(lián)查詢，便于獲取程序運行的詳細(xì)信息。

熔斷限流方案

由于微服務(wù)架構(gòu)的特點，上下游依賴和網(wǎng)絡(luò)通信都比較多，這些因素都會對應(yīng)用本身產(chǎn)生一定的風(fēng)險，比如上游系統(tǒng)的突發(fā)流量或者熱點參數(shù)；下游系統(tǒng)服務(wù)不可用、延時增大、錯誤率升高等等。如果缺少對自身系統(tǒng)的保護(hù)，有可能產(chǎn)生雪崩的效應(yīng)。為了應(yīng)對這些場景，我們主要引入了 Sentinel 框架進(jìn)行解決。Sentinel 的核心原理是用戶可以定義各類資源（資源可以是本地的一個接口，或者遠(yuǎn)程的某個依賴），并在資源上設(shè)置各種規(guī)則（比如限流規(guī)則），在訪問某個資源時，Sentinel 組件會檢查這些規(guī)則是否滿足，在不滿足的情況下會拋出特定的異常。用戶可以通過捕捉這些異常實現(xiàn)快速失敗或者降級等業(yè)務(wù)邏輯。Sentinel 還提供了一個控制臺，可以用來管理規(guī)則的參數(shù)設(shè)置以及查看實時監(jiān)控等。

為了適應(yīng)愛奇藝各個業(yè)務(wù)團(tuán)隊的需求，我們對 sentinel 框架做了一定的擴(kuò)展，下面的例子即是我們實現(xiàn)的復(fù)雜參數(shù)限流功能。Sentinel 框架本身就自帶熱點參數(shù)限流的功能，不過僅支持一些簡單類型的參數(shù)（如 String、int 等）。在有些情況下，限流的場景可能比較復(fù)雜，比如下圖中，可能要根據(jù)第一個參數(shù)的 id 屬性進(jìn)行限流，這種場景原生的 sentinel 并未提供支持。針對這種情況，我們提供了一個抽象的接口，允許用戶通過自己的實現(xiàn)從參數(shù)中提取出需要限流的資源。

為了實現(xiàn)規(guī)則參數(shù)的動態(tài)下發(fā)，我們將 sentinel 與內(nèi)部的配置中心進(jìn)行了適配。在 sentinel dashboard 上進(jìn)行的參數(shù)改動，最后都會保存至配置中心，業(yè)務(wù)系統(tǒng)通過引入配置中心的 SDK，即可實現(xiàn)在不重啟應(yīng)用的前提下進(jìn)行參數(shù)的動態(tài)調(diào)整。

在 QDAS 管理平臺上，我們還利用 k8s 技術(shù)提供了 sentinel dashboard 的托管功能，省去了各業(yè)務(wù)團(tuán)隊在這方面的部署維護(hù)成本。

API 網(wǎng)關(guān)

愛奇藝 API 網(wǎng)關(guān)底層基于開源項目 Kong 實現(xiàn)，旨在為開發(fā)者提供穩(wěn)定、便捷、高性能、可擴(kuò)展的服務(wù)入口功能，一站式管理 API 配置和生命周期，對微服務(wù)治理具有重要意義。

在 API 網(wǎng)關(guān)控制流架構(gòu)設(shè)計中，微服務(wù)平臺 API 網(wǎng)關(guān)模塊通過內(nèi)部系統(tǒng)集成及服務(wù)化實現(xiàn)，為開發(fā)者提供全部所需入口配置及管理功能，且無需代碼侵入、工單申請等人工干涉，實現(xiàn) API 創(chuàng)建即可用。API 網(wǎng)關(guān)支持認(rèn)證、限流、訪問控制等通用功能。

結(jié)構(gòu)如下圖所示：

QDAS

在完善的微服務(wù)體系架構(gòu)中，微服務(wù)治理平臺也必不可少。QDAS 是一個以應(yīng)用為中心的一站式平臺，通過功能插件的形式，對微服務(wù)應(yīng)用的開發(fā)、部署、運維各個環(huán)節(jié)進(jìn)行全生命周期的支持，同時兼容 Dubbo/Spring Cloud 傳統(tǒng)微服務(wù)框架和 Istio 服務(wù)網(wǎng)格架構(gòu)。

QDAS 平臺主要支持的功能包括：

1.應(yīng)用基本信息維護(hù)

2.傳統(tǒng)微服務(wù)治理

(1)實例列表及與 Nacos 注冊中心集成的實例上下線管理；

(2)Grafana 核心指標(biāo)監(jiān)控大盤；

(3)Sentinel dashboard 托管；

(4)基于 Sentinel 的接口鑒權(quán)和流量配額管理（開發(fā)中）；

3.應(yīng)用生命周期管理

支持在各類平臺（容器/虛機(jī)）上的應(yīng)用部署和版本升級功能

4 服務(wù)市場

接口契約管理：包括基于 Swagger UI 的接口描述查看等。

混沌工程

Netflix 最早系統(tǒng)化地提出了混沌工程的概念，目的是盡早的識別風(fēng)險，對薄弱的地方做針對性的加強(qiáng)。我們也一直在注重自己的故障演練，借助一些內(nèi)部的工具跟外部開源項目，逐步演化出自己的故障注入平臺——小鹿亂撞。借助平臺，可以編排自己的演練方案進(jìn)行演練，檢驗服務(wù)的健壯性。

目前小鹿亂撞平臺已經(jīng)支持包括服務(wù)器、容器(docker)、數(shù)據(jù)庫、中間件、網(wǎng)路設(shè)備、k8s 集群等進(jìn)行故障注入，并可在演練過程中實時展示關(guān)聯(lián)的監(jiān)控、日志以及報警等，演練結(jié)束后自動生成演練報告。

另外，借助平臺定時演練的能力，用戶可以方便的實現(xiàn)周期性演練的效果。

未來規(guī)劃

對于微服務(wù)標(biāo)準(zhǔn)架構(gòu)的未來規(guī)劃，大概分為以下幾方面的工作：

微服務(wù)技術(shù)趨勢方面，云原生與 service mesh 已經(jīng)是微服務(wù)技術(shù)演進(jìn)的一個趨勢了，如何引入 service mesh 技術(shù)，并向各個業(yè)務(wù)提供平滑過渡的解決方案，將會是我們今后工作的一個重點。

在服務(wù)治理方面，我們會進(jìn)一步擴(kuò)展 QDAS 平臺的功能，以期建成一個對 service mesh 和傳統(tǒng)微服務(wù)都適用的控制面。

在開發(fā)者支持方面，未來計劃推出項目腳手架以及在線調(diào)試等服務(wù)，使得開發(fā)人員能更方便地進(jìn)行項目開發(fā)，以及線上問題的排查等。