探索Apache APISIX：动态高性能API网关

探索Apache APISIX：动态高性能API网关 - 实践

news/2025/11/11 12:01:56/文章来源:https://www.cnblogs.com/yxysuanfa/p/19209669

Apisix是什么？

Apache APISIX 是一个基于 OpenResty 和 Etcd 实现的动态、实时、高性能的 API 网关，目前已经是 Apache 顶级项目。提供了丰富的流量管理功能，如负载均衡、动态路由、动态 upstream、A/B 测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等。可以使用 APISIX 来处理传统的南北流量以及服务之间的东西向流量。

APISIX 基于 Nginx 和 etcd，与传统 API 网关相比，APISIX 具有动态路由和热加载插件功能，避免了部署之后的 reload 操作，同时 APISIX 协助 HTTP(S)、HTTP2、Dubbo、QUIC、MQTT、TCP/UDP 等更多的协议。而且还内置了 Dashboard，提供强大而灵活的界面。同样也给予了丰富的插件支持功能，而且还可以让用户自定义插件

Apisix架构图

上图是 APISIX 的架构图，整体上分成信息面和控制面两个部分，控制面用来管理路由，关键通过 etcd 来实现设置中心，内容面用来处理客户端请求，通过 APISIX 自身来构建，会不断去 watch etcd 中的 route、upstream 等数据。

APISIX Ingress 工作原理

同样作为一个 API 网关，APISIX 也支持作为 Kubernetes 的一个 Ingress 控制器进行利用。APISIX Ingress 在架构上分成了两部分，一部分是 APISIX Ingress Controller，作为控制面它将做完配置管理与分发。另一部分 APISIX(代理) 负责承载业务流量。

通过进行变更、扩缩容或者迁移处理等，都不会影响到用户和业务流量。就是当 Client 发起请求，到达 Apache APISIX 后，会直接把相应的业务流量传输到后端（如 Service Pod），从而搞定转发过程。此过程不需要经过 Ingress Controller，这样做能够保证一旦有问题出现，或者

同时在配置端，用户通过 kubectl apply 创建资源，可将自定义 CRD 配置应用到 K8s 集群，Ingress Controller 会持续 watch 这些资源变更，来将相应配置应用到 Apache APISIX（通过 admin api）。

从上图可以看出 APISIX Ingress 采用了数据面与控制面的分离架构，所以用户可以选择将数据面部署在 K8s 集群内部或外部。但 Ingress Nginx 是将控制面和数据面放在了同一个 Pod 中，如果 Pod 或控制面出现一点闪失，整个 Pod 就会挂掉，进而影响到业务流量。这种架构分离，给用户献出了比较方便的部署选择，同时在业务架构调整场景下，也方便进行相关数据的迁移与使用。

APISIX Ingress controller Resources

控制器目前拥护的核心特性包括：

全动态，拥护高级路由匹配规则，可与 Apache APISIX 官方 50 多个插件 & 客户自定义插件进行扩展启用
支持 CRD，更容易理解声明式配备
兼容原生 Ingress 资源对象和 Gateway API
支持流量切分
服务自动注册发现，无惧扩缩容
更灵活的负载均衡策略，自带健康检查功能
拥护 gRPC plaintext 与 TCP 4 层代理

service

在 Kubernetes 中，Service 是一种将一组 Pod 上运行的网络应用程序公开为网络服务的方法。

当代理入口流量时，APISIX Gateway 默认将流量直接引导至 Pod，而不是通过 kube-proxy。

EndpointSlice

EndpointSlice 对象表示服务的后端网络端点的子集（切片）。

APISIX Ingress Controller 持续跟踪匹配的 EndpointSlice 对象，每当 Service 中的 Pod 集合发生变化时，APISIX Gateway 代理的 Pod 集合也会相应更新。

ingress

HTTP 和 HTTPS 流量。它提供了一种定义将外部流量路由到内部服务的规则的方法。就是Ingress 是一种 Kubernetes 资源，用于管理集群内服务的外部访问，通常

APISIX Ingress Controller CRDs API

APISIX Ingress Controller 定义了几个自定义资源定义 (CRD) 来声明性地管理路由、上游、TLS 和集群设置。

Gateway API （kubernetes 原生网关）

启用标准 Kubernetes Gateway API 中未包含的附加功能，这些功能由 Gateway API 实施者开发和维护，以安全可靠地扩展功能。

GatewayProxy：定义 APISIX Ingress Controller 与 APISIX 之间的连接设置，包括 auth、endpoint 和全局插件。通过 Gateway、GatewayClass 或 IngressClass 中的 parametersRef 引用。
BackendTrafficPolicy：定义后端服务的流量管理设置，包括 APISIX Ingress Controller 中的负载平衡、超时、重试和主机头处理。
消费者：定义 API 消费者及其凭证，启用身份验证和插件配置来控制对 API 端点的访问。
PluginConfig：定义可重复使用的插件配置，可以被 HTTPRoute 等其他资源引用，从而构建路由逻辑和插件设置的分离，从而搭建更好的可重用性和可管理性。
HTTPRoutePolicy：为HTTPRoute或Ingress资源配置高级流量管理和路由策略，在不修改原有资源的情况下增强功能。

APISix Ingress CRD

APISIX Ingress Controller CRD 扩展了 Kubernetes 能力，为 Apache APISIX 网关提供声明式配置管理，支持高级路由、流量管理和安全策略。

ApisixRoute：定义 HTTP/TCP/UDP 的路由规则，支持路径匹配、主机名、手段过滤和后端服务配置。可以引用 ApisixUpstream 和 ApisixPluginConfig 资源。
ApisixUpstream：依据负载平衡、健康检查、重试、超时和服务子集选择等高级配置扩展 Kubernetes 服务。
ApisixConsumer：定义 API 消费者及其身份验证凭证，支持 basicAuth、keyAuth、jwtAuth、hmacAuth、wolfRBAC 和 ldapAuth 等方法。
ApisixPluginConfig：通过 plugin_config_name 字段定义 ApisixRoute 引用的可重用插件配置，促进路由逻辑和插件设置的分离。
ApisixTls：管理 SSL/TLS 证书，帮助 SNI 绑定和相互 TLS，以构建安全的 APISIX 网关连接

四种途径创建apisix 资源

dashbaord （实际也是admin api）
调用admin api
kubectl 创建ingress 为apisix的ingress-controller
kubectl crd 创建apisix 资源

官方推荐依据

APISIX 官方文档明确区分了两种利用场景：

场景	推荐方式	理由
Kubernetes 部署（使用 apisix-ingress-controller）	✅ CRD（Custom Resource Definition）	通过 ApisixRoute、ApisixConsumer、ApisixUpstream 等 CRD，将配置与 K8s 原生对象绑定，方便 GitOps、声明式配置、自动同步。
独立部署（裸机 / VM / Docker / 云实例）	✅ Admin API	没有 K8s 控制器时，Admin API 是唯一方式。动态、灵活，但应该显式调用或编写脚本。

详细对比：CRD vs Admin API

对比项	使用 CRD	应用 Admin API
部署场景	K8s 内	任意环境
操作方式	声明式（YAML + kubectl apply）	命令式（curl / SDK）
变更检测	由 apisix-ingress-controller 自动 watch 同步	需手动调用 Admin API
自动化能力	✅ GitOps / CI/CD 原生支持	❌ 需额外封装或脚本
可见性	资源状态存储在 etcd + k8s	仅 APISIX etcd 内
风险控制	权限由 K8s RBAC 管理	需保护 Admin API 密钥
灵活性	由 CRD schema 限制，稳定但保守	可用全量 APISIX 功能（插件、路由、流量控制等）
一致性管理	Controller 自动保证	自行维护版本与回滚