乐趣区

关于后端:为什么-APISIX-Ingress-是比-Emissaryingress-更好的选择

本文从可扩展性和服务发现集成等多个维度比照了 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 提供了多种扩大形式,能够依据本身状况自由选择、组合。
目前反对的扩大形式如下:

  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 致力的指标。

退出移动版