共计 3120 个字符，预计需要花费 8 分钟才能阅读完成。
本文从可扩展性和服务发现集成等多个维度比照了 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 语义的有余。
下文将从根本能力、服务发现、可扩展性等方面剖析两者之间的区别和劣势。
基本功能
| Feature | APISIX Ingress | Emissary-ingress | |
| Protocols | HTTP/HTTPS | ✓ | ✓ |
| gRPC | ✓ | ✓ | |
| TCP | ✓ | ✓ | |
| UDP | ✓ | ✕ | |
| Websockets | ✓ | ✓ | |
| Load balance | Round Robin | ✓ | ✓ |
| Ring Hash | ✓ | ✓ | |
| Least Connections | ✓ | ✓ | |
| Maglev | ✕ | ✓ | |
| Authentication | External Auth | ✓ | ✓ |
| Basic | ✓ | ✓ | |
| JWT | ✓ | ✕ | |
| OAuth | ✓ | ✕ | |
| OpenID | ✓ | ✕ | |
| Traffic Management | Circuit Breaker | ✓ | ✓ |
| Rate Limiting | ✓ | ✓ | |
| Canary | ✓ | ✓ | |
| Fault Injection | ✓ | ✕ | |
| Health Checks | ✓ | ✓ | |
常见的网关性能，包含流量治理、负载平衡、鉴权等。值得注意的是，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 提供了多种扩大形式，能够依据本身状况自由选择、组合。
目前反对的扩大形式如下：
- 应用 Lua 语言进行插件开发，这种形式绝对简略，并且简直没有性能损耗。此外还能够通过 serverless 插件来间接编写 Lua 代码，疾速的满足业务需要。
- 除了内置原生的 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 致力的指标。
