中台反思：云原生下 API 网关的选择

之前的中台系列文章反思的都是宏观层面，接下来会有选择地拿几个重点内容，讨论中台技术落地层面的点滴。

从技术角度看网关必定是最核心的组件，本文我们就来聊聊 API（微服务）网关的选型。

如上图，最开始我们的网关大概会是这样的。请求由云端或自建的负载均衡（LB）服务进入打到微服务网关，微服务网关转发到具体的服务实例。

在这个过程中微服务网关的核心功能有：

1. 服务发现及路由

2. 认证 &鉴权

3. 限流、降级、黑白名单、链路跟踪等附加能力

微服务网关选型上多半会使用 Spring Cloud Gateway。

这是个很“和谐”的方案，但直到云原生架构的出现，微服务都以容器的形式运行，容器内外地址不同导致上述方案无法有效地支撑。

于是会出现第一种演进方案，如上图所示，LB 请求先打到 Ingress，然后再转到微服务网关，最后再到服务实例。这一方案将网关部署到了容器内，与服务实例在同一个网络下以实现服务发现及路由，但带来的问题有：性能及稳定性不佳、调用链路长。

调用链路长可以采用上述改进的方案，我们把容器外的 LB 去掉，直接使用 Ingress LB，目前主流的云服务都支持，自建的话可以考虑使用 Traefik。

但对性能及稳定性上的损失还是没有解决，这时我会回看微服务网关的作用：服务发现及路由完全可以由 k8s 的 service discovery 代替，限流、降级、黑白名单、链路跟踪等附加能力可以由 Nginx 扩展实现，唯有认证 &鉴权需要单独考虑。

所以我们可以演化出上图的方案，将认证 &鉴权下放到各个服务实例，通过内置认证 &鉴权 SDK 实现相应能力。这方案好处在于调用链路变短、由 K8s 自身的 service discovery 实现服务发现及路由更协调，并且额外的还支持了零信任架构。问题在于微服务本身过重、安全过滤不够前置。

解决微服务本身过重的问题，我们可以按上图优化。认证 &鉴权的能力我们打出独立的容器并将其与微服务的容器打到同一个 pod 中，这样一来在微服务开发过程中并不需要依赖认证 &鉴权功能，只在部署时注入，非常的方便。

如果我们做零信任架构，要服务内部访问都做鉴权的话这个方案应该是目前最合适的。

如果不需要考虑这么高级别的安全，那么我们可以使用 APISIX、Kong 等支持插件化能力的网关把认证 &鉴权写成插件形成如上图的方案。请求从 LB 到 Ingress，后者实现了网关的认证 &鉴权及附加能力，service discovery 实现服务发现及路由能力。这会是一种非常合适的选择。

上文我们介绍了几种 API（微服务）网关选型的方案，从大的层面说在云原生环境下微服务及网关都要做轻做薄，传统的 Spring Cloud 体系、Dubbo 体系并不一定是最佳的选择，充分用好 K8s 自身的能力，用最简单的开发技术实现事半功倍的成效。

关注我的公众号：中台反思：云原生下API网关的选择 (qq.com)