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

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

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

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

负载均衡

谈到网关，不得不谈负载均衡，通常负载均衡有服务器负载均衡和客户端负载均衡（例如Spring Cloud Ribbon & 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种方式：Single API 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，去除动态创建和回收机制，以达到性能最优。
网关实现认证，简化后端服务的业务流程（适合认证，不适合权限）
– 这个也是比较常规的做法，目的是也是让后端的应用服务/微服务设计与实现更简单。这种服务多适合认证，但是权限的管理在一些特殊的应用场景未必适用。比如某些应用里的某个功能，对于权限划分比较细，已经是针对内容级别的访问控制。网关一般不能代替服务来实现，还是需要通过服务本身来完成。