![1.png](https://ucc.alicdn.com/pic/developer-ecology/634283f618004fe786681329d6f73fe5.png)

作者 | 周曉軍  愛奇藝中介軟體團隊負責人

> **導讀**：本文整理自作者於 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 框架。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/7ab43c58e1684867ba666cad26019c8c.png)

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

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

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/dc6bf5f751014ff7bd4d1b5f557ee76c.png)

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

# 微服務生態體系

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

![4.png](https://ucc.alicdn.com/pic/developer-ecology/0811a11203464d37a0728b386aaaa0e9.png)

這裡面分為幾個層面：

- 首先是開發框架層面，Dubbo SDK 整合了註冊發現、通訊及負載均衡的能力，但是類似熔斷及限流功能還是需要採用 Sentinel 等框架來進行支援；

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

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

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

- Dubbo SDK 的擴充套件
- 生態體系建設
   - 註冊中心的演進
   - 監控體系的建設
   - 熔斷限流方面的支援

## 1. Dubbo SDK 的擴充套件

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

![5.png](https://ucc.alicdn.com/pic/developer-ecology/f42c9735b9154aa69e0938acd9356698.png)

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

### 1）非健康例項隔離機制

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

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

![6.png](https://ucc.alicdn.com/pic/developer-ecology/8e483ed9421f40ecb30116ec4309850b.png)

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

我們的擴充套件機制中提供了預設的健康檢查策略，包括檢查最近一次呼叫是否出現服務端異常，或者一段時間內是否有大量發出的請求未被返回。使用者也可以透過擴充套件我們提供的介面來實現自己的檢查策略。

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

### 2）區域就近路由機制

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

![7.png](https://ucc.alicdn.com/pic/developer-ecology/86315147f93840cc994beb4c4c2e4671.png)

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

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

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

### 3）認證機制

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

![8.png](https://ucc.alicdn.com/pic/developer-ecology/680bb46512f7480c8351060a3a5302be.png)

其基本原理是：

- 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 元件，可以用較低的成本進行註冊中心的遷移。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/c866806901f441f0bab7854fcafb5d6b.png)

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

![10.png](https://ucc.alicdn.com/pic/developer-ecology/4b08c265820f425f9736ab1079ba26cc.png)

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

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

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

![11.png](https://ucc.alicdn.com/pic/developer-ecology/b5c9016668ea4f959a9f548cc75d317e.png)

- 首先要部署一個 Nacos-Sync 服務，從舊的註冊中心向 Nacos 同步資料。Nacos-Sync 支援叢集化部署，部署多個例項時，其向新註冊中心的寫入時冪等的，並且它原生支援 Dubbo 的註冊資料格式；

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

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

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

### 2）監控體系建設

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

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

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

- 鏈路監控：由於微服務呼叫關係的複雜性，呼叫鏈追蹤也是非常必要的，它可以幫助業務人員更好地分析應用間的依賴關係，並能夠監控各個呼叫關係上的核心指標。

![12.png](https://ucc.alicdn.com/pic/developer-ecology/a836cb981d7f46d89fced6cc74c214a9.png)

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

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

其次是指標採集的問題，Prometheus 是採用拉模式採集指標的，對於微服務場景一般是利用 Prometheus 的服務發現機制。Prometheus 預設整合了 consul、K8s 等服務發現方式，不過並未對 Nacos 註冊中心直接提供支援，我們在開源的 Nacos adapter 的基礎上進行了改造，使得 Prometheus 能夠從 Nacos 中發現要採集的應用例項資訊。

指標檢視主要採用了 grafana，我們提供了一套通用化的配置模板，業務也可以根據需要自行擴充套件。

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

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

![13.png](https://ucc.alicdn.com/pic/developer-ecology/07ed9b4ef9974bbfaa434d2fd71d0b01.png)

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

![14.png](https://ucc.alicdn.com/pic/developer-ecology/dc91b4dc5ac3439cb142e803f54c9612.png)

鏈路追蹤的基本原理也和 google 關於 Dapper 的論文一致，應用程式透過埋點的 agent 產生呼叫鏈資料，透過日誌採集或者網路直接上報的方式統一彙總至 kafka，透過我們的實時分析程式進行分析。

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

- 原始的呼叫鏈資料我們會使用 ES+HBase 進行儲存；
- 呼叫關係上的實時監控資料我們採用時序資料庫 druid 進行儲存；
- 拓撲關係採用圖資料儲存。

![15.png](https://ucc.alicdn.com/pic/developer-ecology/27226c70909b453187d56e6e92057c59.png)

### 3）熔斷限流

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

![16.png](https://ucc.alicdn.com/pic/developer-ecology/43b109f22d944cd3ad456179fb28a18d.png)

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

Sentinel 的核心原理是使用者可以定義各類資源（資源可以是本地的一個介面，或者遠端的某個依賴），並在資源上設定各種規則（比如限流規則），在訪問某個資源時，Sentinel 元件會檢查這些規則是否滿足，在不滿足的情況下會丟擲特定的異常。使用者可以透過捕捉這些異常實現快速失敗或者降級等業務邏輯。Sentinel 還提供了一個控制檯，可以用來管理規則的引數設定以及檢視實時監控等。

![17.png](https://ucc.alicdn.com/pic/developer-ecology/75d2c8a0f28c48aa86b8d684eaf877a9.png)

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

![18.png](https://ucc.alicdn.com/pic/developer-ecology/00759a4bb1d5411397ab8607b34197b3.png)

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

![19.png](https://ucc.alicdn.com/pic/developer-ecology/e5d97b3947ae4a8c82f58c058ba5fd1c.png)

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

![20.png](https://ucc.alicdn.com/pic/developer-ecology/eb69a3ed24e04831aa28583d433bee20.png)

# 發展現狀及開源貢獻

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

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

![21.png](https://ucc.alicdn.com/pic/developer-ecology/22cfdd43a4d24102a1acfaf77d033888.png)

# 未來規劃

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

![22.png](https://ucc.alicdn.com/pic/developer-ecology/9a3a6f1c55cc4e26a445b0019b9794d7.png)

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

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

- 在開發者支援方面，我們計劃推出專案腳手架以及線上除錯等服務，使得開發人員能更方便地進行專案開發，以及線上問題的排查等。

**阿里巴巴雲原生公眾號後臺回覆 818 即可獲取直播回看地址和大會 PPT 合集。**

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/x7OObZbsiPl5t9FFigHg-Q)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

愛奇藝在 Dubbo 生態下的微服務架構實踐

相關文章