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

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

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

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

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

開源SDK定制

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

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

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

3.安全性增強：支持了服務(wù)間調(diào)用的認證機制；

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

這部分內(nèi)容已通過其他的公眾號文章進行了詳細的介紹，這里不再展開，有興趣的讀者可以參考Apache Dubbo的愛奇藝之旅。

注冊中心演進

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

1.無法橫向擴展；

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

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

1.高性能，可以橫向擴展；

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

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

Nacos高可用部署

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

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

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

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

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

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

注冊中心平滑遷移方案

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

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

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

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

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

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

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

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

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

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

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

2.日志監(jiān)控：如錯誤日志的數(shù)量；也可以利用AI技術(shù)，對日志的模式進行統(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)系上的核心指標。

指標監(jiān)控

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

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

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

指標查看主要采用了基于skywalking UI開發(fā)界面及grafana，我們提供了一套通用化的配置模板，業(yè)務(wù)也可以根據(jù)需要自行擴展。

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

監(jiān)控dashboard查看、告警策略設(shè)置、訂閱的入口統(tǒng)一設(shè)置在我們內(nèi)部的全鏈路監(jiā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，通過我們的實時分析程序進行分析。分析結(jié)果大致可以分為三類，原始的調(diào)用鏈數(shù)據(jù)我們會使用ES+HBase進行存儲，調(diào)用關(guān)系上的實時監(jiān)控數(shù)據(jù)我們采用時序數(shù)據(jù)庫druid進行存儲，拓撲關(guān)系采用圖數(shù)據(jù)存儲。

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

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

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

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

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

熔斷限流方案

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

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

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

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

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

愛奇藝 API 網(wǎng)關(guān)底層基于開源項目 Kong 實現(xiàn)，旨在為開發(fā)者提供穩(wěn)定、便捷、高性能、可擴展的服務(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)支持認證、限流、訪問控制等通用功能。

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

API網(wǎng)關(guān)的具體功能及實現(xiàn)原理也已通過公眾號文章進行了介紹，有興趣的讀者可以參考一站式入口服務(wù)|愛奇藝微服務(wù)平臺 API 網(wǎng)關(guān)實戰(zhàn)。

QDAS

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

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

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

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

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

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

    (3)Sentinel dashboard托管；

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

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

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

4服務(wù)市場

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

混沌工程

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

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

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

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

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

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

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