馬蜂窩如何利用 APISIX 閘道器實現微服務架構升級

作者：董紅帥，馬蜂窩微服務體系建設以及基礎服務能力建設專家。

馬蜂窩作為旅行社交平臺，是資料驅動的新型旅行電商。基於十餘年的內容積累，馬蜂窩通過 AI 技術與大資料演算法，將個性化旅行資訊與來自全球各地的旅遊產品供應商實現連線，為使用者提供與眾不同的旅行體驗。

隨著業務的發展，馬蜂窩架構也在跟隨技術步伐進行更迭，開始基於 Kubernetes 進行更多的延展。在這個技術背景下，需要針對雲服務開啟新一輪的架構更新，比如：微服務場景建設新的蜂效平臺及周邊設施來支援迭代和流量泳道的能力，在多 Kubernetes 叢集場景引入 Karmada 實現多叢集管理，在微服務閘道器領域將 Istio + Envoy 的架構替換為 Apache APISIX 與 Envoy 共存的微服務閘道器模式。

微服務 1.0 模式現狀

目前馬蜂窩內部的微服務架構經歷了兩次迭代，本文中將針對原有架構的第一次調整定義為 1.0 版本。在進行微服務 1.0 架構的搭建之前，我們從釋出系統能力、Kubernetes 容器、服務發現和微服務閘道器等角度進行了一些考量與目標對齊。比如 Kubernetes 的廣泛應用，需要開始考慮基於容器做多語言支援，在 CI/CD 環節實現全面容器化，並支援多 Kubernetes 叢集等。

在進行第一次迭代之前，內部架構的微服務閘道器使用的是 NGINX Ingress，但它其實是存在問題的。比如配置變更基於 NGINX reload，會造成業務有損；同時在應用範圍內僅支援單 Kubernetes 叢集，場景受限；內建資源過於簡單，大量匹配規則依賴 Annotations，配置繁雜不友好，尤其是對外部服務發現能力支援很弱。

因此在進行微服務 1.0 迭代落地的過程中，為了滿足一些業務需求，我們進行了如下動作（選取部分操作列舉）：

• 在 Kubernetes 容器內，基於 macvlan 改造容器網路，IDC 機房網路與雲廠商網路互通（容器互通的通訊基礎）；藉助閘道器或容器直連實現服務互訪，不再使用 Kubernetes Service。
• 基於 Kubernetes 容器場景部署；基於 Consul 物理機虛擬機器部署。
• 增加統一服務發現能力，基於 Kubernetes、Consul 建設統一的發現中心 — Atlas；同時基於 Atlas 擴充套件微服務閘道器、Java 生態、監控體系等。
• 在微服務閘道器的選擇上，基於 Istio + Envoy 架構進行構建。對 Istio 中 Pilot 進行二次開發，對接 Atlas 發現中心，由於 Atlas 資料來源於多套 Kubernetes 和 Consul，進而將例項發現與 Kubernetes 叢集解耦，間接做到閘道器對接多 Kubernetes 叢集的能力，實現整個閘道器動態感知識別的變化。

痛點梳理

在微服務 1.0 的這套架構中，實踐下來還是存在一些痛點。

首先是在釋出系統能力方面，微服務 1.0 中的釋出系統，僅僅是一個釋出系統，無法有效融合專案需求的管理（釋出也是度量的一環）；同時這套釋出系統基於 PHP 構建，無法很好地支援自動化滾動部署、多版本滾動部署容量變更等較為複雜的部署場景；當多人對同一個專案開發，或一個需求關聯多個專案時，缺少機制讓流量在同一個迭代中自動串聯（流量泳道）。同時對多 Kubernetes 叢集管理並不方便，當 Kubernetes 下線時需要業務側參與，給業務線帶來了時間成本等。

其次就是微服務閘道器架構層面。前文也提到了 1.0 架構下閘道器是基於 Istio+Envoy 對 Pilot 做了二次開發，主要是對接 Atlas 發現中心。隨著業務的應用數量越來越多，訪問規則也越來越多，這就導致我們線上的閘道器生效延遲也越來越高。在流量巔峰狀態下，大概有 15 秒左右的延遲。這個延遲主要來自於 CRD 資源，幾乎全都在相同的 namespace 下，同時上下線時會觸發全量更新導致延遲較高。

而在早期的使用過程中，Envoy 在資料全量推送過程中還會出現連結中斷的狀況，造成 503 問題的產生。除此之外，Envoy 還存在使用記憶體持續增長導致 OOM 的情況，當網關出現問題時，對 Envoy 和 Pilot 進行排錯的成本較高。當使用一些高階配置時，需要藉助 Envoy Filter 實現，其上手門檻較高，對於想簡單實現熔斷、限流、Auth 鑑權等功能而言，成本較高。

除此之外，兩個社群（Istio 和 Envoy）的發展速度很快，這也導致我們的架構比較難跟進上游社群的發展。

基於 APISIX 的微服務 2.0 模式

新平臺與新架構

面對 1.0 架構下存在的痛點與問題，內部對於這套微服務架構進行了再次迭代，來到了 2.0 時代。2.0 架構場景下，我們新增了一套釋出平臺——蜂效平臺。

蜂效平臺重點突出了以下能力：

• 融合了需求管理，支援了迭代部署能力，使得釋出系統可以增益度量。
• 將容器部署和機器部署（物理機部署）在產品能力上進行了統一。
• 增強了精細化的流量管理能力、回滾能力（回滾策略：批次、例項數、間隔等）
• 與 Java 生態融合共建，支援了流量泳道能力，環境流量隔離。
• 閘道器基於 APISIX 進行重構，解決 Envoy OOM 及規則生效延遲較高的同時，通過 APISIX 產品化能力降低了問題排錯成本，降低了擴充套件和配置閘道器的上手門檻。

在蜂效平臺產品側中，我們將需求管理與迭代部署關聯結合，並且為了支援了多種迭代流水線模式。在流量管理方面，我們藉助 Atlas Instance 模型中的 env 屬性以及擴充套件屬性，實現了流量泳道能力。基於流量泳道模型，在上層產品側構建迭代流量環境呼叫鏈路隔離。

在周邊生態建設方面，Java SDK 側做到了應用在迭代環境中可以實現隔離的鏈路呼叫，閘道器側也進行了類似的操作。只是閘道器側作為整個流量的入口，我們是通過 Cookie 的規則，也就 Cookie 的方式進行配置的。基線環境的流量只能到達基線環境的版本中，迭代環境的流量就會轉發到迭代的版本上去。

同時在部署層的 Kubernetes 多叢集管理層面，我們則藉助 Karmada 實現了一個多 Kubernetes 叢集的管理。在整個架構中（如下圖所示），底層的能力主要是由 Kubernetes 多叢集和流量閘道器 Envoy 與 APISIX、發現中心 Atlas、日誌服務與監控服務等組成。

而蜂效平臺在整個架構中主要是進行配置管理、構建部署、擴縮容和上下線等等，同時包含任務流的模組。最上方則是應用市場的一些能力，比如迭代能力和外掛能力等。

整體來說，我們基於應用中心和服務打造出了 2.0 新架構。這套新架構在 Kubernetes 叢集發生變更時，可通過 PropagationPolicy、OveridePolicy 等策略，實現 Deployment 等在 Kubernetes 叢集級別的資源分發，減少叢集變更時業務參與的成本，減輕了業務研發側的一些壓力。

閘道器選型

在 2.0 模式的架構中，流量閘道器我們提到了兩個閘道器產品，即 Envoy 與 APISIX。Envoy 作為之前 1.0 版本的選擇，我們並沒有完全放棄，在 2.0 中我們也因為一些需求和產品期望，開始考慮新的閘道器產品進行替代，比如：

• 訪問規則變化時，閘道器的生效速度需要控制在毫秒級（生效慢，會導致閘道器生效速度不一，在使用了 CDN 場景下可能導致業務資源長時間 404）。
• 可在現有場景中，完全替換 Istio+Envoy 架構；同時支援 HTTP、gRPC，併兼容現有路由策略。
• 需要降低問題的排查成本，最好有產品化支援（如 Dashboard）。
• 產品足夠穩定，社群活躍，功能強（對限流等場景支援）。
• 不需要二次開發即可支援公司現有架構的替換。
• 在替換 Istio+Envoy 架構過程中，需要保持雙架構可用（Istio、Envoy 與新閘道器並存），如果新架構有問題可快速回退至原來方案。

在調研了一些關鍵閘道器產品的模型之後，我們最終將方案鎖定在了 Apache APISIX。APISIX 的架構也分為控制面和資料面，同時還附帶 Dashboard 產品。在功能使用上，APISIX 提供了豐富的外掛，比如限流、熔斷、日誌安全和監控等等。我們可以通過 APISIX 的 Admin API 提供的介面，去完整操作 APISIX 的所有能力，比如 Upstream、Consumer 還有各種外掛等。對我們而言，APISIX 還有一個特別有優勢的點，就是 APISIX 在升級時，能夠做到對低版本的 API 進行統一的相容。

除此之外，我們認為 APISIX 還有以下幾個優勢：

• APISIX 基於 Openresty 的效能很好，相比 Envoy 來說，效能損耗很少。在經過我們測試之後，在 QPS 的表現上，APISIX 損耗 3%，而 Envoy 損耗 16%；在時延表現上，APISIX 平均轉發耗時 2ms，而 Envoy 耗時 7ms。資料的體現，已經展示了 APISIX 在效能上的卓越優勢。
• APISIX 還附有 Dashboard 支援，對於路由匹配異常等場景可快速判斷是否為規則配置錯誤。
• 作為開源產品，APISIX 的社群更為活躍。在產品的功能上，在限流、鑑權、監控等方面相比 Envoy 成本更低，支援性更好。
• APISIX 相比 Envoy 記憶體佔用很低，但在配置的動態變更上相比 Envoy 要弱（Envoy 幾乎大部分配置可動態下發），但也足夠滿足需求。

因此，在調研與測試之後，我們在微服務 2.0 的架構下增添了 Apache APISIX 作為流量閘道器加入。由於閘道器是整個微服務流量的核心，如果從一套舊架構切換到一套新的架構，其實成本是比較高的。所以我們希望微服務的閘道器規則變化能夠對新舊兩套閘道器（Envoy 與 APISIX）同時生效，也就是一套配置可以適用於兩種架構，因此我們在 2.0 架構中，針對這些變動做了一些調整。

落地方案與實踐問題

首先考慮到成本問題，對原本的 Istio 架構保持不變，並未進行改造。同時在閘道器架構中，引入了新開發的關鍵元件—— istio-apisix-translator。

istio-apisix-translator 主要是去對接 Atlas 發現中心以及 Istio 的 CRD 資料。作為資料同步服務，實時將 VirtualService、DestinationRule 等規則變化轉換為 APISIX 路由規則，將 Atlas Instance 資料實時轉換為 APISIX Upstream 規則等。簡單來說，就是通過這樣一個服務元件，實現了對 Atlas 以及 Istio CRD 的資料支援。

藉助這種架構，我們就實現了對兩種閘道器的完整支援，如下圖所示。

閘道器架構的核心部分則是圖中最下方的 APISIX，上層的 istio-apisix-translator 則充當類似 Istio 架構中的 Pilot 角色，將 Instance 與 CR 資料整合後，藉由 APISIX Admin API 推送至 APISIX 中，例項則是對接到內部業務的 Atlas 發現中心。因此，無論是訪問規則發生變化還是 Atlas 的資料來源發生變化，都可以將這份資料變化轉換成 APISIX 的資料推到 APISIX 中。目前全鏈路都是基於 Watch 機制保證資料變化的實時處理，因此在實際應用場景下，基本可以達到資料變化的毫秒級生效。

當然，在使用 APISIX 的過程中，我們也遇到了幾處問題。但均已解決並將結果同步給了社群進行反饋。

第一個問題就是在 APISIX 使用證書對接 etcd 時，如果 APISIX 節點較多，可能會導致 APISIX Admin API 介面響應非常慢。這個問題的原因是因為目前 etcd 存在一個關於 HTTP/2 的 BUG。如果通過 HTTPS 操作 etcd（HTTP 不受影響），HTTP/2 的連線數上限為 Golang 預設的 250 個。而 APISIX 的控制面和 Istio 架構的控制面有區別，APISIX 節點是直連 etcd，當 APISIX 資料面節點數較多時，一旦所有 APISIX 節點與 etcd 連線數超過這個上限，則 APISIX 的介面響應會非常的慢。

為了解決這個問題，我們也在 etcd 和 APISIX 的社群均進行了反饋，後續也通過升級版本（etcd 3.4 升級到 3.4.20 及以上，etcd 3.5 升級到 3.5.5 及以上）解決了這個問題。同時我們也已將這個結果同步到了 APISIX 社群官網 Q&A 文件中，方便後續使用者遇到同樣問題時，可以有所參考。

第二個問題就是在使用 APISIX 的過程中會遇到效能抖動的問題。

首先是會出現 499 響應抖動，這個問題主要出現在連續兩次以上過快的 post 請求（也不止 post）的場景下。這種情況是 NGINX 認定為不安全的連線，則主動斷開了客戶端的連線。為了處理這個問題，只需將 proxy_ignore_client_abort 的配置調整為 on 即可。

除此之外，當 APISIX Admin API 介面請求密集時，也會出現 APISIX 資料面少部分響應超時的狀況。這個主要是因為 istio-apisix-translator 在重啟時，會將 Atlas、Istio CR 資料聚合，全量同步至 APISIX 中，大量請求引發 APISIX 資料變更，APISIX 資料面密集的同步變更導致小部分響應超時。為此，我們引入協程池和令牌桶限流，減少 APISIX 資料密集變更的場景來應對此問題。

總結與發展

馬蜂窩當前是基於 Kubernetes 容器部署以及基於 Consul 的機器部署場景，自建 Atlas 服務發現中心，同時，在 Java 生態、微服務閘道器，微服務體系的流量泳道，以及監控體系做對接和適配。

在微服務閘道器前期，是基於 Istio 1.5.10 對 Pilot 二次開發，也在閘道器側支援非容器部署場景。目前階段則是保持了 Istio+Envoy 架構與 APISIX 架構同時支援，通過引入外部服務元件，讓 APISIX 也複用 Istio CRD 資源。

從閘道器發展視角來看，未來我們也會跟隨閘道器的一些趨勢。比如現在很多產品都開始支援 Gateway API，像 APISIX Ingress、Traefik、Contour 等；同時閘道器的動態化配置也是未來非常明顯的趨勢，對於運維或者基礎研發的同學來說，在後續考慮閘道器架構的選型和迭代時，也可以更多關注閘道器動態配置的方面。