1

背景描述

愛奇藝在之前有開發了一款閘道器——Skywalker，它是基於 Kong 做的二次開發，目前流量使用也是比較大的，閘道器存量業務

日常峰值為百萬級別 QPS，API 路由數量上萬

。但這款產品的不足隨著使用也開始逐步體現。

效能差強人意，因為業務量大，每天收到很多 CPU IDLE 過低的告警

系統架構的元件依賴多

運維開發成本較高

今年在交接到此專案後，我們根據上述問題和困境，開始對相關閘道器類產品做了一些調研，然後發現了 Apache APISIX。

2

Apache APISIX 優勢

在選擇 Apache APISIX 之前，愛奇藝平臺已經在使用 Kong 了，但是後來 Kong 被放棄了。

為什麼放棄 Kong？

Kong 使用 PostgreSQL 來儲存它的資訊，這顯然不是一個好方式。同時在調研過程中我們查看了 Apache APISIX 與 Kong 的效能的對比，在效能最佳化方面 Apache APISIX 比 Kong 提升了 10 倍，這個指標是非常讓人驚喜的。同時我們也比較了一些主要的閘道器產品，Apache APISIX 的響應延遲比其它閘道器低 50% 以上，在 CPU 達到 70% 以上時 Apache APISIX 仍能穩定運轉。

我們也發現 Apache APISIX 其實和 Kong 一樣，都是基於 OpenResty 技術層面做的開發，所以在技術層面的遷移成本就比較低。而且 Apache APISIX 具有良好的環境適應性，能夠被輕易地部署在包括雲計算平臺在內的各種環境上。

同時也看到 Apache APISIX 整個開源專案的活躍度非常高，對問題的處理非常迅速，並且專案的雲原生架構也符合我司後續規劃，所以我們選擇了 Apache APISIX。

3

基於 Apache APISIX 下的愛奇藝閘道器架構

愛奇藝閘道器的總體架構如下圖所示，包含域名、閘道器到服務例項和監控告警。DPVS 是公司內部基於 LVS 做的一個開源專案，Hubble 監控告警也是基於開源專案做的深度二次開發，Consul 這塊做了些效能和高可用性方面的最佳化。

應用場景一：微服務閘道器

關於閘道器這塊，簡單從控制面和資料面介紹一下。

資料面主要面向前端使用者，從 LB 到閘道器整個架構都是多地多鏈路災備部署，以使用者就近接入原則進行布點。

從控制面的角度來說，因為多叢集構成，會存在一個微服務平臺，去做叢集管理和服務管理。微服務平臺可以讓使用者體驗服務暴露的一站式服務，立即使用，無需提交工單。控制面後端會有 Gateway Controller 和 Service Controller，前者主要控制所有的 API 的建立、外掛等相關配置，後者則是控制服務註冊登出和健康檢查。

應用場景二：基礎功能

目前階段，基於 Apache APISIX 調整後的 API 架構實現了一些基礎功能，如限流、認證、報警、監控等。

首先是 HTTPS 部分，愛奇藝方面出於對安全性的考慮，證書和金鑰是不會存放在閘道器機器上，會放在一個專門的遠端伺服器上。之前使用 Kong 時我們沒有在這方面做相關支援，採用前置 Nginx 做 HTTPS Offload，此次遷移到 Apache APISIX 後，我們在 Apache APISIX 上實現了該功能，從鏈路上來說就少了一層轉發。

在限流功能上，除了基礎的限流、還添加了精準限流以及針對使用者粒度的限流。認證功能上，除了基本的 API Key 等認證，針對專門業務也提供了相關的 Passport 認證。對於黑產的過濾，則接入了公司的 WAF 安全雲。

監控功能的實現目前是使用了 Apache APISIX 自帶外掛——Prometheus，指標資料會直接對接公司的監控系統。日誌和呼叫鏈分析也透過 Apache APISIX 得到了相關功能支援。

應用場景三：服務發現

關於前面提到的服務發現，主要是透過服務中心把服務註冊到 Consul 叢集，然後透過 DNS 服務發現的方式去做動態更新，其中 QAE 是我們公司內部的一個微服務平臺。簡單舉例說明一下更新後端應用例項時的大體流程。

例項變更時，首先會從 Consul 中登出對應節點，並透過 API 閘道器 Controller 向閘道器傳送更新 DNS 快取的請求。快取更新成功後，Controller 再反饋 QAE 平臺可以停止相關後端應用節點，避免業務流量再轉發到已下線節點。

應用場景四：定向路由

閘道器是多地部署的，事先搭建好一整套多地互備鏈路，同時建議使用者後端服務也是多地就近部署。隨後使用者在 Skywalker 閘道器平臺上建立一個 API 服務，Controller 會在全 DC 閘道器叢集上都部署好 API 路由，同時業務域名預設 CNAME 到統一的閘道器域名上。

直接為業務提供多地就近接入、故障災備切換能力，同時也支援使用者自定義解析路由。針對使用者自身的故障切流、藍綠部署、灰度釋出等需求，使用者可以透過採用 uuid 域名來自定義解析路由配置，同時也支援後端服務發現的自定義排程。

應用場景五：多地多級容災

前邊我們也提到過，針對業務量大、叢集多，還有客戶端受眾廣的情況，在業務層面我們會有業務就近接入和災備的需求。

針對災備，除了要多地多鏈路互備，還要考慮多級多節點問題，故障節點越向客戶端靠近，受影響的業務和流量越大。

如果是最遠的後端服務節點故障，依靠閘道器和服務中心的健康檢查機制，可以實現故障單節點的熔斷或者故障 DC 的切換，影響範圍限制在指定業務上，使用者無感知。

如果是閘道器級別故障，需要依靠 L4 DPVS 的健康檢查機制，熔斷故障閘道器節點，影響範圍小，使用者無感知。

如果故障點並非上述述熔斷措施所能修復，就需要依靠域名粒度的外網多點可用性撥測，實現域名解析級別的故障自動切換，這種方式故障修復速度相對較慢，影響業務多，使用者可感知。

4

遷移過程中遇到的問題

在我們從 Kong 到 Apache APISIX 的遷移實踐過程中，我們解決、優化了一些架構存在的已知問題，但同時也遇到了一些新的問題。

成果一：解決了前端不支援 SNI 的相容問題

現在大部分前端都是支援 SNI 的，但也會碰到有一些前端在 SSL 過程中無法傳遞 hostname。目前我們針對這種情況做了一個相容，採取埠匹配的方式進行相關證書獲取。

成果二：優化了大量 API 路由匹配問題

前邊也說過，目前我們線上直接執行的 API 業務數量就有 9000 多個，後續可能還會增加。針對這一問題我們進行了相關效能上的最佳化，根據 API 來決定優先匹配域名還是路徑。

成果三：解決了 ETCD 介面限制問題

在接入 Apache APISIX 後，ETCD 介面的限制問題也已經解決，目前已經解除了 4M 的限制。

成果四：優化了 ETCD 連線數量的效能問題

目前是 Apache APISIX 的每個 worker 都會跟 ETCD 連線，每一個監聽目錄都會去建一個連線。比如一臺物理機是 80 core，監聽目錄有 10 個，單臺網關伺服器就有 800 個連線。一個閘道器叢集 10 臺的話，8000 個連線對 ETCD 壓力蠻大的。我們做的最佳化是隻拿一個 worker 去監聽有限的必要目錄，和其餘 worker 之間共享資訊。

除了上述問題，還有一些問題也正在努力最佳化中。

大量 API 的問題，即使 APISIX 能夠支援，我們也要考慮其他依賴元件的瓶頸。比如上述的 ETCD、Prometheus 監控和日誌服務。所以後續我們可能會採取大叢集共享和小叢集獨立這兩種方式來混合部署業務，比如一些重要業務我們會以小叢集方式進行部署。

關於 Prometheus 監控指標，後續我們也會進行相應的縮減和最佳化，對 DNS 服務發現這塊做更多的最佳化。

5

對 Apache APISIX 的期望

我們希望 Apache APISIX 能在後續的開發更新中，除了支援更多的功能，也可以一直保持效能的高效和穩定。

6

關於 Apache APISIX

Apache APISIX 是一個動態、實時、高效能的開源 API 閘道器，提供負載均衡、動態上游、灰度釋出、服務熔斷、身份認證、可觀測性等豐富的流量管理功能。Apache APISIX 可以幫忙企業快速、安全的處理 API 和微服務流量，包括閘道器、Kubernetes Ingress 和服務網格等。

全球已有數百家企業使用 Apache APISIX 處理關鍵業務流量，涵蓋金融、網際網路、製造、零售、運營商等等，比如美國航空航天局（NASA）、歐盟的數字工廠、中國航信、中國移動、騰訊、華為、微博、網易、貝殼找房、360、泰康、奈雪的茶等。

200 餘位貢獻者，一同締造了 Apache APISIX 這個世界上最活躍的開源閘道器專案。聰明的開發者們！快來加入這個活躍而多樣化的社群，一起來給這個世界帶來更多美好的東西吧！

Apache APISIX GitHub：https：//github。com/apache/apisix

Apache APISIX 官網：https：//apisix。apache。org/

Apache APISIX 文件：https：//apisix。apache。org/zh/docs/apisix/getting-started