API网关：Apache APISIX

我们先了解一下 网关 (Gateway) 的作用和价值。

网关是什么

传统架构的通用功能
在传统的架构中，没有网关，那么通用功能该怎么复用起来呢？这里的通用功能指业务无关的一些特性，比如：

安全性：身份验证、授权、防重放、防篡改、对抗 DDos 等

可靠性：服务降级、熔断、限流等

这些功能在传统架构下，最常见的处理方法就是将其放入服务框架当中，通过 AOP 的方式去实现，类似下图：

模块：

Backend: 后端服务

AOP: 框架携带的 AOP 分层

SD: 服务中心，用于服务间发现，此组件在云原生环境下经常用 Service 替代

LB: 负载均衡器，放置于网络边界上，作为外部流量的入口

这种架构在早些年的设计中非常常见，由此诞生了很多大而全的服务框架，比如 Dubbo, SpringCloud 等。如果我们去认真去研究它们的功能介绍，我们会发现这些功能点它们大多都有。

这种架构的优点在于上下游关系简单，网络传输中也少了一次转发。但是她们的缺点也很明显：

通用功能的迭代会迫使业务服务更新：由于采用的是代码引用，因此需要业务服务重新编译才能使功能生效。对一些没有实现平滑发布的团队，由于服务会中断，因此还得挑业务的空闲期发布。

版本难以管理：由于我们不可能每次发布都让所有业务服务升级最新版，长此以往，各个服务的版本将会不一致。

那么我们是否可以将这些通用功能下沉到一个独立的服务，它可以单独迭代且业务无关？

从上图中，我们可以看到传统架构的大部分内容都没有变化，只是在后端服务与 LB（负载均衡器） 之间多出了一个角色：网关。

（这里需要澄清的是，本文讨论的网关特指 ApiGateway ，即针对后台服务以 API 提供服务的场景。）

在上面的这个图中，有时 LB 同时也起到网关的作用，比如 k8s 的 Ingress 组件。

有了网关这个组件后，我们就可以将传统架构的通用功能下沉到网关，这样一来我们获得了很多的好处：

1、网关可以独立迭代，不再需要业务服务配合

2、与语言无关，可以配置专门的团队维护

网关模式的缺点：

1、多了一次转发，延迟变高，排查问题复杂度变高

2、网关如果不能正常工作，可能会成为整个平台的瓶颈

API网关：Apache APISIX

Apache APISIX是一个动态、实时、高性能的API网关。提供了丰富的流量管理功能，如负载均衡、动态上游、canary释放、断路、认证、可观察性等。您可以使用Apache APISIX来处理传统的南北向流量，以及服务之间的东西向流量。它也可以用作k8s的ingress控制器。

Apache APISIX架构图

可以使用Apache APISIX作为流量入口来处理所有业务数据，包括动态路由、动态上游、动态证书、A/B测试、金丝雀发布、蓝绿色部署、限速、恶意攻击防御、指标、监控告警、服务可观测性、服务治理等。

所有平台可用

• 原生云：平台无关，没有厂商锁定，APISIX可以运行从裸机到Kubernetes。
• 运行环境：支持OpenResty和tenengine。
• 支持ARM64：不要担心基础技术的锁定。

多协议支持

• TCP/UDP Proxy：动态TCP/UDP代理。
• Dubbo代理：动态HTTP到Dubbo代理。
• 动态MQTT代理：支持通过client_id负载均衡MQTT，支持MQTT 3.1.* 5.0。
• gRPC代理：代理gRPC流量。
• gRPC转码：支持协议转码，客户端可以通过HTTP/JSON访问gRPC API。
• 代理Websocket
• Dubbo代理：基于Tengine的Dubbo代理。
• HTTP (S)转发代理
• SSL:动态加载SSL证书。

参考资料：

• https://github.com/apache/apisix
• https://apisix.apache.org/