作者 | 周曉軍? 愛奇藝中間件團隊負責人

導讀：本文整理自作者于 2020 年云原生微服務大會上的分享《愛奇藝在 Dubbo 生態下的微服務架構實踐》，重點介紹了愛奇藝在 Dubbo、Sentinel 等開發框架方面的使用經驗以及微服務生態體系的建設經驗。

阿里巴巴云原生公眾號后臺回復?818?即可獲取直播回看地址和大會 PPT 合集。

本文將主要圍繞以下幾個主題展開：

• Apache Dubbo 簡介及其在愛奇藝的發展歷史
• 愛奇藝內部對 Dubbo SDK 的擴展及圍繞 Dubbo 相關的微服務生態建設
• 后續規劃

Apache Dubbo 簡介及其在愛奇藝的發展歷史

1. Apache Dubbo 簡介

Apache Dubbo 是一款由阿里開源的高性能 RPC 框架。Dubbo 框架本身除了通信外，還內置了微服務治理的多項功能（如注冊發現，路由規則等）。

自從 2017 年重啟維護以來，Dubbo 社區一直保持了較高的活躍度。從周邊生態來看也相對比較完善，比如 Nacos、Sentinel 等開源框架都對其提供了支持。在語言支持方面，除了 Java 語言之外，Dubbo-go 社區目前也非常活躍，且針對 python，nodejs 等主流開發語言 Dubbo 也有一些開源實現。基于以上這些因素，我們決定引入 Dubbo 框架，用以替換原先自研的 RPC 框架。

愛奇藝是在 2019 年 6 月正式開始引入 Dubbo 框架的。我們將其與對接公司內部的基礎設施做了對接，如注冊中心、監控系統等等，并在 2019 年 8 月正式發布了第一個內部版本。

這里值得一提的是我們并沒有維護自己的 Dubbo 分支，而是利用 Dubbo 強大的擴展機制開發我們的新特性，這樣使得我們能夠在跟進 Dubbo 社區新版本方面沒有障礙。在這個內部版本發布后，很快就有第一個生產應用在同年 9 月份上線。后續我們在進一步擴展 Dubbo SDK 功能的同時，在周邊生態建設方面也做了不少工作，其中就包括在 2020 年 3 月份上線的 Nacos 注冊中心等。

2. Apache Dubbo 在愛奇藝的發展歷史

優秀的微服務開發框架是業務服務化的基石，但是由于微服務應用的復雜性，要幫助業務團隊更好地實踐微服務架構，還需要一個相對完善的微服務生態體系作為支撐。

微服務生態體系

下圖展示了目前愛奇藝內部微服務生態體系的全景。

這里面分為幾個層面：

• 首先是開發框架層面，Dubbo SDK 集成了注冊發現、通信及負載均衡的能力，但是類似熔斷及限流功能還是需要采用 Sentinel 等框架來進行支持；

• 在基礎設施層面，注冊中心/配置中心均是微服務生態中重要組件；此外為了保證應用的可用性，完整的監控體系也必不可少，如指標監控、日志監控、鏈路追蹤等；

• 最后，為了方便運維人員管理微服務應用，還需要一套功能完善的管理平臺，其中包括了服務管理、配置下發、監控告警及一些對開發人員的支持功能。

可以看到，整個微服務的生態體系還是非常龐大的，限于篇幅，以下的演講會主要會集中在以下幾個方面展開：

• Dubbo SDK 的擴展
• 生態體系建設
  • 注冊中心的演進
  • 監控體系的建設
  • 熔斷限流方面的支持

1. Dubbo SDK 的擴展

根據愛奇藝內部的實際情況，以及各個業務團隊的需求，我們主要對 Dubbo SDK 做了以下幾方面的擴展：

• 基礎設施的適配：包括注冊中心、監控系統、內部的容器平臺等等；
• 可用性增強：包括非健康實例隔離以及區域就近路由的機制；
• 安全性增強：支持了服務間調用的認證機制；
• 序列化：增加了對 protobuf 序列化方式的支持。

1）非健康實例隔離機制

首先介紹非健康實例隔離機制。

Dubbo SDK 默認采用隨機的負載均衡策略，并通過失敗重試的策略來保證調用的成功率。通過實踐發現，生產環境中有時會出現少數 Provider 節點雖然已經處于不健康的狀態（比如磁盤寫滿等），但是還是能與注冊中心進行正常通信，這樣 Consumer 端還是能發現這些實例，導致部分請求還是會被分發過去。這些請求由于實例本身的問題，可能會出現響應時間變慢或者錯誤率上升，從而引起整個服務質量的下降（響應時間抖動或整體調用成功率下降）。

為了解決這樣一個問題，我們的思路是引入客戶端健康檢查機制，即 Consumer 端會對每個 Provider 實例的請求成功率進行統計，判斷其是否健康；對于不健康的 Provider 實例，Consumer 端會對其進行隔離一段時間，后續的請求不再通過負載均衡策略發送到這些實例上。另外 Consumer 端會維護每個 Provider 實例被隔離的次數，如果某個實例被多次隔離，每次隔離的時間也會相應變長。

我們的擴展機制中提供了默認的健康檢查策略，包括檢查最近一次調用是否出現服務端異常，或者一段時間內是否有大量發出的請求未被返回。用戶也可以通過擴展我們提供的接口來實現自己的檢查策略。

為了避免因為網絡抖動等造成的意外影響，我們還設計了一套兜底機制。即當 Provider 實例中不健康的比例超過一定閾值時，Consumer 會忽略實例隔離的策略，避免集中的流量將剩余的實例打垮。

2）區域就近路由機制

接下來介紹一下區域就近路由機制。

愛奇藝在多地都建有機房，為了確保在單個機房出現故障時各業務系統仍能正常工作，核心業務一般會采用兩地三中心的架構進行部署。在這種場景下，系統如果產生跨地域的訪問請求，由于網絡延時的原因勢必導致請求延時增大，所以各業務一般都有客戶端就近訪問服務端實例的需求。

我們通過擴展 Dubbo 的路由機制實現了這樣的策略。大致的實現原理是，Provider 和 Consumer 實例在啟動時，會先從一個公共的地域服務中獲取實例當前所在地域信息（比如可用區等）。Provider 實例在服務注冊時會將上述的地域信息作為 URL 的一部分注冊到注冊中心，這樣 Consumer 實例就能夠在服務發現時獲知每個 Provider 實例的地域信息并和自身的地域信息進行比對，優先選擇臨近的實例就近訪問。

此外，Consumer 實例也會通過上文中提到的健康檢查機制對服務端實例進行檢查，如果發現本地域健康的 provider 實例低于設定比例時，則會忽略就近路由的策略，改為在所有的 Provider 實例中進行負載均衡，從而實現自動的 failover 機制。

3）認證機制

部分內部服務有安全認證相關的需求，不希望非授權應用對其進行訪問。為了解決這個問題，我們開發了一套基于數字簽名及 AK/SK 的認證體系。

其基本原理是：

• Provider 服務可以通過配置在某個service上開啟鑒權；
• 需要訪問敏感服務的 Consumer 應用，需要在微服務平臺上進行申請，審批后會在這個授權關系上生成一對 AK/SK 并同步至鑒權服務；
• Provider/Consumer 與鑒權服務進行通信，獲取相關的 AK/SK，這個過程使用 HTTPS 進行通信；
• Consumer 在發起調用時，會對請求參數等生成一個數字簽名，連同時間戳、AK 等信息一起發送給 Provider 端；
• Provider 在收到請求時，會對其數字簽名等信息進行核對，確認請求信息的來源及數據的完整性。

以上介紹的是我們針對 Dubbo SDK 的擴展內容，接下來主要介紹我們在微服務生態方面的建設。

2. 生態體系建設

注冊中心在微服務應用中是最重要的基礎設施之一，在 Dubbo SDK 引入之初，為了快速落地，我們使用了 ZooKeeper 作為注冊中心。當然實際上 ZooKeeper 并不是微服務注冊中心的最佳選型，它的主要缺點包括：

• 無法橫向擴展；
• 作為一個一致性的系統，在網絡分區會產生不可用。

1）注冊中心演進

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

• 高性能，可以橫向擴展；
• 既適用于傳統為服務架構，也能適用于云原生環境，包括支持與 Istio 控制面對接；
• 提供了 Nacos-Sync 組件，可以用較低的成本進行注冊中心的遷移。

在部署 Nacos 服務時，我們充分考慮了服務部署架構方面的高可用性。目前我們的 Nacos 服務是一個大集群，實例分布在多個不同的可用區中，在每個可用區內部，我們會申請不同的 VIP，最終的內網域名是綁定在這些 VIP 上。另外其底層所使用的 MySQL 也采用了多機房部署。這樣的架構可以避免單個 Nacos 實例或者單機房故障造成整個 Nacos 服務的不可用。

以下是一些可能的故障場景的模擬：

• 單個 Nacos 實例故障：利用 Load Balancer 集群提供的健康檢查能力自動從 VIP 中摘除；
• 某個 VIP 集群故障：利用客戶端重試機制解決；
• 單個 AZ 故障：利用客戶端重試機制解決；
• MySQL 集群故障：MySQL 與注冊發現過程無關，不受影響；
• 整個 Nacos 服務故障：客戶端兜底機制，如服務實例緩存等。

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

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

• 檢查數據無誤后，首先升級 Consumer 端，改為從 Nacos 注冊中心進行發現。這時的服務發現的數據均是由 Nacos-Sync 從舊的注冊中心同步過來的；

• 再升級 Provider 端，改為向 Nacos 進行服務注冊；

• 下線 Nacos-Sync 服務及舊的注冊中心，整個遷移流程就結束了。

2）監控體系建設

接下來主要介紹我們內部微服務監控體系的建設。完整的微服務監控體系一般由以下 3 個方面組成：

• 指標監控：包括 QPS / 響應延時 / 錯誤率等黃金指標、業務的自定義指標、JAVA 應用的 JVM 指標，此外還需要采集和基礎環境的相關指標，包括 CPU / 內存利用率等；

• 日志監控：如錯誤日志的數量；也可以利用 AI 技術，對日志的模式進行統計分析等；

• 鏈路監控：由于微服務調用關系的復雜性，調用鏈追蹤也是非常必要的，它可以幫助業務人員更好地分析應用間的依賴關系，并能夠監控各個調用關系上的核心指標。

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

首先是指標計算的問題，為了降低侵入性，我們在 skywalking agent 的基礎上進行了二次開發，可以自動攔截 Dubbo 的調用，統計其調用次數、處理耗時、是否錯誤等等。

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

指標查看主要采用了 grafana，我們提供了一套通用化的配置模板，業務也可以根據需要自行擴展。

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

監控 dashboard 查看、告警策略設置、訂閱的入口統一設置在我們內部的全鏈路監控平臺上，用戶可以在該平臺上查看進行相應的操作。

下圖展示的是服務監控界面：

鏈路追蹤的基本原理也和 google 關于 Dapper 的論文一致，應用程序通過埋點的 agent 產生調用鏈數據，通過日志采集或者網絡直接上報的方式統一匯總至 kafka，通過我們的實時分析程序進行分析。

分析結果大致可以分為三類：

• 原始的調用鏈數據我們會使用 ES+HBase 進行存儲；
• 調用關系上的實時監控數據我們采用時序數據庫 druid 進行存儲；
• 拓撲關系采用圖數據存儲。

3）熔斷限流

最后簡單介紹一下利用 sentinel 框架進行熔斷和限流的相關內容。

由于微服務架構的特點，上下游依賴和網絡通信都比較多，這些因素都會對應用本身產生一定的風險，比如上游系統的突發流量或者熱點參數；下游系統服務不可用、延時增大、錯誤率升高等等。如果缺少對自身系統的保護，有可能產生雪崩的效應。為了應對這些場景，我們主要引入了 Sentinel 框架進行解決。

Sentinel 的核心原理是用戶可以定義各類資源（資源可以是本地的一個接口，或者遠程的某個依賴），并在資源上設置各種規則（比如限流規則），在訪問某個資源時，Sentinel 組件會檢查這些規則是否滿足，在不滿足的情況下會拋出特定的異常。用戶可以通過捕捉這些異常實現快速失敗或者降級等業務邏輯。Sentinel 還提供了一個控制臺，可以用來管理規則的參數設置以及查看實時監控等。

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

為了實現規則參數的動態下發，我們將 sentinel 與內部的配置中心進行了適配。在 sentinel dashboard 上進行的參數改動，最后都會保存至配置中心，業務系統通過引入配置中心的 SDK，即可實現在不重啟應用的前提下進行參數的動態調整。

在我們的微服務管理平臺上，還提供了 sentinel dashboard 的托管功能。

發展現狀及開源貢獻

愛奇藝引入 Dubbo 的時間并不長，但是由于其較為穩定的線上表現使得的各個業務團隊的整體接受度較高，上線的規模也在快速增長。短短一年內累計已上線了一百多個線上服務，實例數也已經超過五千個。

此外，我們也在使用過程中積極回饋社區，截止目前共提交了三十個左右的補丁，上文中提到的認證機制也已貢獻給社區，成為 Dubbo 2.7.6 版本的新特性之一。在這個過程中，團隊中也誕生了一位社區的 committer。

未來規劃

對于未來的規劃，大概有以下幾方面的工作：

• 云原生與 service mesh 已經是微服務技術演進的一個趨勢了，且在一些公司已經有了比較大規模的實踐。如何將 dubbo 與 service mesh 結合，如何提供平滑過渡的解決方案，將會是我們今后工作的一個重點；

• 在服務治理方面，后續我們希望能夠建立一個對 service mesh 和傳統微服務都適用的控制面；

• 在開發者支持方面，我們計劃推出項目腳手架以及在線調試等服務，使得開發人員能更方便地進行項目開發，以及線上問題的排查等。

阿里巴巴云原生公眾號后臺回復?818?即可獲取直播回看地址和大會 PPT 合集。

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號。”

總結

以上是生活随笔為你收集整理的爱奇艺在 Dubbo 生态下的微服务架构实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。