為什麼 APISIX Ingress 是比 Emissary-ingress 更好的選擇？

本文從可擴展性和服務發現集成等多個維度對比了 APISIX Ingress 與 Emissary-ingress 的性能。

作者：容鑫，API7.ai 雲原生技術工程師，Apache APISIX Committer。

原文鏈接

背景

Kubernetes Ingress 是一種 API 對象，用於定義集羣外部流量如何路由到集羣內部服務的規則。Ingress Controller 通常用於實現 Ingress 資源的相關邏輯，並統一管理這些流量規則。

在實踐中，企業用户往往需要 mTLS、重試、限流和鑑權等流量管理功能，但 Ingress 資源語義無法滿足需要。因此，Ingress Controller 實現往往使用新增 CRD 等方式對功能進行擴展。接下來將詳細介紹和對比 APISIX Ingresss 和 Emissary-ingress 兩種實現的差異。

什麼是 APISIX Ingress

Apache APISIX Ingress 是 Apache 軟件基金會旗下的開源項目，其控制平面負責對 Kubernetes 中資源進行配置轉換並進行交付，實際的業務流量則由 APISIX 承載。為了提高安全性，整個部署過程採用了數據面和控制面完全分離的架構，從而有效避免了數據面被攻擊導致 Kubernetes 集羣權限泄露的風險。

什麼是 Emissary-ingress

Emissary-ingress 是 CNCF 的孵化項目，作為 Envoy proxy 的控制平面，它負責解析 Kubernetes 資源，所有流量都直接由數據面 Envoy 來處理。通過將控制面和數據面打包為一個容器，使整體更易接入和部署。

APISIX Ingress 和 Emissary-ingress 的區別

除了對 Ingress 資源的支持外，兩者都支持了 CRDs、Gateway API 的配置方式，以彌補 Ingress 語義的不足。

下文將從基本能力、服務發現、可擴展性等方面分析兩者之間的區別和優勢。

基本功能

常見的網關功能，包括流量管理、負載均衡、鑑權等。值得注意的是，Emissary-ingress 在鑑權方面的支持相對較少，只包含了最基本的 Basic Auth 和 External Auth 能力。

服務發現

在微服務架構中，應用通常被拆分為多個微服務，它們相互協作以完成具體的業務邏輯。由於微服務實例的數量不斷變化，這就需要一種機制來幫助服務之間相互發現和定位。

服務發現是指微服務在網絡上的定位方式，通過服務名獲取服務發現的信息以確定請求路由到哪個實例。對於傳統的微服務框架，註冊中心的選型往往是結合業務自身需求，如果將已存在的服務註冊和發現組件遷移到基於 Kubernetes 的 DNS 服務發現機制，這需要一定的改造成本。如果網關支持現有的服務註冊和發現組件，就不需要進行這些改造，從而更好地支持微服務框架。

以下是兩者對服務發現組件的支持情況：

Service Discovery	Apache APISIX Ingress	Emissary-ingress
Kubernetes	✓	✓
DNS	✓	✓
Nacos	✓	✕
Eureka	✓	✕
Consul	✓	✓

在服務發現生態方面，APISIX Ingress 擁有着更高支持力度，用户可以非常方便的通過 Ingress Controller 集成到用户現有的微服務框架中。

可擴展性

當 Kubernetes Ingress Controller 的功能無法滿足特定的需求時，用户可以通過二次開發的方式來擴展其功能。通過開發自定義插件或者修改現有的代碼，可以滿足更加個性化的需求。擴展性強的 Ingress Controller 可以更加方便地開發和定製化功能，為特定場景提供更好的支持和解決方案。

Emissary-ingress

Emissary-ingress 可擴展性是比較差的，不支持通過自定義 Envoy Filter 的方式進行拓展。由於數據面和控制面作為一個整體，這就需要對整體進行二次開發，數據面 Envoy 的二開復雜度高，這給開發者帶來了很大的負擔。

除此之外，如果用户需要更強大的 Emissary-ingress，需要將其升級為 Ambassador 的商業產品 Edge Stack，一些專有功能需要付費以獲取支持。

APISIX Ingress

數據面 APISIX 主要通過插件的方式進行功能擴展，提供了 80+ 開箱即用的插件。APISIX Ingress 支持了 APISIX 提供的所有插件，可滿足大多數日常使用場景。

如果需要根據自身的業務場景進行功能定製，APISIX 提供了多種擴展方式，可以根據自身情況自由選擇、組合。 目前支持的擴展方式如下：

1. 使用 Lua 語言進行插件開發，這種方式相對簡單，並且幾乎沒有性能損耗。此外還可以通過 serverless 插件來直接編寫 Lua 代碼，快速的滿足業務需求。
2. 除了內置原生的 Lua 語言，還可以通過 Plugin Runner 或 WASM 插件來進行擴展，這種模式下支持 Java/Python/Go 等語言開發自定義插件。使用户能夠利用一些現有的業務邏輯，還可以根據公司已有技術棧或研發喜好自行選擇，而無需學習新語言。

以上擴展方式，APISIX Ingress 都能夠完整的支持，無需進行額外的開發。

性能

作為 Kubernetes 入口流量代理組件，接管了平台所有的入口流量，統一管理多種流量規則，這對代理的性能也有了更高的要求。

本文將在相同的實例（4C 8G）中，分別對 APISIX Ingress(APISIX:3.1.0) 和 Emissary-ingress 3.4.0 進行性能測試。

QPS

QPS（Queries-per-second），每秒查詢率：服務每秒處理的請求數量，數值越大性能越好。

• 單個 Ingress 資源 QPS

• 5000 Ingress 資源 QPS

Latency

響應延遲：服務器響應時間，延遲越小，性能越好

小結

從圖中可以發現，在面對不同的資源規模時，APISIX Ingress 的性能不會受到影響，表現十分均衡。而 Emissary-ingress 在資源規模較大時，匹配不同的路由對 QPS 和延時產生了嚴重的影響，其性能隨着資源數量的增加而不斷下降。由此可見，在實際生產環境中，隨着業務體量的不斷增長，APISIX 的高性能優勢更加凸顯。

總結

Emissary-ingress 的特點在於使用簡單易於接入，但是二次開發的難度較高。對於更多的功能需求，需要通過接入平台的相關組件來獲取支持。

相比之下，APISIX Ingress 在可擴展性和服務發現集成方面具有優勢，擴展性強且開發簡單。此外，APISIX Ingress 的性能表現出色，特別是在業務規模不斷增長的場景中具有明顯優勢。

關於 API7.ai 與 APISIX

API7.ai 是一家提供 API 處理和分析的開源基礎軟件公司，於 2019 年開源了新一代雲原生 API 網關 -- APISIX 並捐贈給 Apache 軟件基金會。此後，API7.ai 一直積極投入支持 Apache APISIX 的開發、維護和社區運營。與千萬貢獻者、使用者、支持者一起做出世界級的開源項目，是 API7.ai 努力的目標。