為什麼 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 努力的目標。