从保证业务不中断，看网关的“前世今生”

​​​​摘要：现在大家在谈“分布式”、“微服务”、“云原生”这些概念时，更多在谈支撑“软件服务”的弹性伸缩与负载均衡。API Gateway 作为其第一道关卡以及其重要组成组件，我们来看看他的发展历程、现状及未来的方向。

API 网关作为现代分布式、微服务、云原生系统中的一个重要组成部分，也作为一项重要的讨论主题，咱也聊聊负载均衡及 API Gateway 的现状。

现在大家在谈“分布式”、“微服务”、“云原生”这些概念时，除了“软件服务”功能本身，更多的是在谈如何让服务可以更好的扩展来支持大规模的应用。负载均衡及 API 网关是作为其第一道关卡以及其重要组成组件，我们来看看他的发展历程、现状及未来的方向。

负载均衡

谈到网关，不得不谈负载均衡，通常负载均衡有服务器负载均衡和客户端负载均衡（例如 Spring CloudRibbon & Eureka）两种不同的方式。对于非 REST 且对实时性要求较高的服务来说，客户端负载均衡是一种常用的选择，比如王者荣耀、英雄联盟这种游戏来说，进入游戏的各种日常活动，都是基于 REST 服务的，而组队进行比赛时，通常都是非 REST 服务。还有在线协作的产品，如 Welink 的 IM/Presence 功能，其服务端是可以做成 REST 服务，而 Welink Meeting 这种实时音视频会议（real-time colloration），RESE 服务不能满足其实时性要求。大都是采用客户端负载均衡的方式，基本过程如下：

1、负载均衡网关与服务器之间的注册或发现机制。

2、客户端向网关请求会议服务器列表，这里服务器会有一些业务逻辑从而计算出一些服务器列表返回给客户端。

3、客户端拿到服务器列表会向服务器发送探测报文，根据探测报文的响应时间（客户端与服务器之间网络状况），以及服务器的负载等因素来决定选择哪一个服务器。

4、客户端与服务器通过约定的协议建立业务连接。

5、如果客户端或者服务器任何一段出现异常，客户端会重新走 2-4 的流程恢复业务连接。

从上述可以看出客户负载均衡的会有一个相对复杂的过程，但是一旦建立连接，其性能一定是最优的。不过客户端负载均衡无法保证服务器 REST 服务化，一旦服务器发生故障，会有短暂的服务中断。但是该方案适用于一些实时性要求较高的一些应用（如上述说到的一些应用）。而对于 REST 的服务来说，采用 L4 负载均衡（F5、LVS、nginx、haproxy 等）/L7 负载均衡（haproxy、nginx、apache、Mysql proxy 等）是通用的方法。这次 Arch Summit，部分厂商介绍其采用 4 层负载均衡方案。我们来大致看一下整个分布式系统负载均衡的整体架构及发展历程。

从负载均衡的发展来看，根据其应用规模其演进过程大致如下：

API Gateway 的现状

随着微服务的流行，API Getway 得到蓬勃的发展。对于 API Gateway 本职工作是承担消息分发任务，提供给客户统一的 API 入口。通常有 2 种方式：SingleAPI Gateway 和 Backend for Frontend API Gateway。有沒有第三种模式呢？我之前做的一个产品，其网关基本架构如下：

1、客户端有登录的要求，在登录认证的 response 里，包含了不同服务的 api 的 url 列表。

2、客户端在不同的 api 请求是，使用对应的 api url，这样客户端来实现了大部分 api 的分发工作。

3、这时候 API 网关的主要任务其实已经不是最初的 API 转发的功能了。而是为了简化后端服务，实现后端服务的一些公共功能。

4、甚至在这种场景下，可以没有 API 网关，API 可以直接面对应用服务，再由应用服务来调度微服务进行业务处理。

回到的 API gateway 本身，其最核心设计理念是保证数据面的业务不中断。由于对接 API 网关的服务是多样的，客户 API 跟应用的设计不可控，你很难能要求每个接入的服务以及客户端都具备容错能力。这就要求网关尽量保证能正常处理每个请求，且满足较高的 SLA，现在业界的 API 网关的主流使用 Nginx 系，主要考虑如下：

• 支持热重启

数据面的组件升级是一个高风险动作， 一旦出现异常就可能导致连接中断，系统异常， 除非你的前端 LB（负载均衡）能具备快速排水的能力，当然即使如此，还是可能导致正在处理的请求被强制中断。所以数据面的热重启非常关键。

• 支持订阅式动态路由

API 路由变化相对频繁，及时性也要求比较高，如果采用定期同步方案，一次性同步几万条的数据会拖慢你的系统，因此增加一个订阅式的路由服务中心非常关键，我们可以快速订阅 ETCD 中的路由数据并实时生效。而且只拿增量数据性能压力不会太大。

• 支持插件化管理

Nginx 在插件方面提供了丰富的生态。不同的 API，不同的用户所需要的处理流程不完全一致，如果每个请求过来都按照相同流程处理，必定带来相关的冗余操作。插件化管理可以在一定程度上提升性能，还能保障在升级过程中能快速添加处理链。

• 高性能的转发能力

API 网关一般工作在多后端 API 反向代理模式，很多自研的 API 网关在性能上容易出现瓶颈，因此 nginx 优异的性能和高效的流量吞吐是其核心竞争力。

• 无状态可横向扩展

API 网关承载的是整个系统所有请求的集合，需要根据业务规模进行弹性伸缩，采用服务中心配合 Nginx 配置管理可以快速增删已有的集群，并同步到 LVS，实现快速的横向扩展能力。

随着现在的系统的越来越复杂，很多服务模块除了处理自身业务之外，还有承担一些非业务的职责，如认证和授权，限流，缓存，日志，监控，重试，熔断等。这样涌现了一批开源的 API 网关实现。

• Tyk：Tyk 是一个开源的、轻量级的、快速可伸缩的 API 网关，支持配额和速度限制，支持认证和数据分析，支持多用户多组织，提供全 RESTful API（go 语言）。

• Kong：Kong 可以认为是一个 OpenResty 应用程序，而 OpenResty 运行在 Nginx 之上，使用 Lua 扩展了 Nginx。（Kong = OpenResty + Nginx + Lua）

• Orange：Orange 是一个基于 OpenResty 的 API Gateway，提供 API 及自定义规则的监控和管理，如访问统计、流量切分、API 重定向、API 鉴权、WEB 防火墙等功能。（腾讯在用）

• Netflix Zuul：Zuul 是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul 是 Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器。（Spring Cloud）

• Ambassador：Ambassador 是一个开源的微服务 API 网关，建立在 Envoy 代理之上，为用户的多个团队快速发布，监控和更新提供支持，支持处理 Kubernetes ingress controller 和负载均衡等功能，可以与 Istio 无缝集成。(Kubernetes-Native)

• 其他…(例如：apiaxle: Nodejs 实现的一个 API 网关； api-umbrella: Ruby 实现的一个 API 网关。)

除了上述功能，随着 API 网关服务承担了越来越多的职责，其性能瓶颈也越显突出。这次 ArchSummit 一些公司展示了一些自己的特色功能，还有在产品演化中，自己在架构上做了一些优化，主要有：

• 采用 C++来实现网关来提升性能 （*）

– 在本次会议中，有 2-3 家企业都在提用 C++实现来提升性能。这基本上与架构无关，更多的是编程语言自身的差异了。

• 私有协议加速 API 与服务的映射关系

– 这个好几家都在做，比如腾讯。

• 网关实现分层隔离不变与易变，实现网关的增值业务的架构演进（*）

– 这个就是架构层面的东西了，我的理解是更多架构演进及运维相关的考虑。把面向前端客户（稳定）与面向后端服务（不稳定）的部分再分层实现、分层部署，从而面向客户的网关服务基本上不变动。当后端服务在功能扩展或者重构后，系统升级对于客户影响最小（具体细节没介绍）。

• 网关实现限流，让后端服务更稳定，更简单。

– 这个比较容易理解，也是常规的做法。这样让后端的应用服务/微服务设计与实现更简单。当然不同的产品实现各不相同。其中腾讯介绍游戏 API 网关时，提到了服务启动静态创建最大化连接 Session，去除动态创建和回收机制，以达到性能最优。

• 网关实现认证，简化后端服务的业务流程（适合认证，不适合权限）

– 这个也是比较常规的做法，目的是也是让后端的应用服务/微服务设计与实现更简单。这种服务多适合认证，但是权限的管理在一些特殊的应用场景未必适用。比如某些应用里的某个功能，对于权限划分比较细，已经是针对内容级别的访问控制。网关一般不能代替服务来实现，还是需要通过服务本身来完成。

总结

从网关的发展来看，其经历了一代又一代的演进，从自身架构的演进，再到其功能上叠加，在促进其架构上的再此迭代演进。在现再这个万物皆云的时代，云原生这个概念已经被各个行业所接受并且提高一个很高的高度。连一些传统的网络设备业务也要上云。

对于产品的发展与演进，我们也会“抄、学、变”。

• 对于相同相识业务，成熟优秀的解决方案，我们要会“抄”，直接拿过来用，不要自己闭门造轮子。

• 对于不同的业务做转型演进，可以借鉴的经验不多，但是对于相关领域架构、知识。我们不能抄，而要“学”，学习其思想，其精髓。

• 最后是变，任何通用的解决方案和架构可以解决通用的问题，但是由于通用，也不可避免的有一些“通病”。

附录：Arch Summit API 网关一些架构图：

点击关注，第一时间了解华为云新鲜技术~