亿级流量架构之网关设计思路、常见网关对比

时间 2021-02-27

标签 html 前端 nginx git github web spring 数据库编程后端栏目系统架构繁體版

原文原文链接

本文准备围绕七个点来说网关,分别是网关的基本概念、网关设计思路、网关设计重点、流量网关、业务网关、常见网关对比,对基础概念熟悉的朋友能够根据目录查看本身感兴趣的部分。html

什么是网关

网关,不少地方将网关好比成门, 没什么问题, 可是须要区分网关与网桥的区别,前端

网桥工做在数据链路层，在不一样或相同类型的LAN之间存储并转发数据帧，必要时进行链路层上的协议转换。可链接两个或多个网络，在其中传送信息包。nginx

网关是一个大概念，不具体特指一类产品，只要链接两个不一样的网络均可以叫网关,网桥通常只转发信息,而网关可能进行包装。git

网关通俗理解

根据网关的特性,举个例子:github

假如你要去找集团老板(这儿只是举个例子), 你们都知道老板确定不是谁想见就能见的, 也怕坏人嘛, 那么你去老板所在的办公楼,假如是集团总部, 大楼这个门就充当了网关的角色, 大门通常都有看门员 ,看门员会作哪些事情呢?web

首先全部想见老板的人确定都得从这个门进(统一入口), 这个门至关于将办公室和外界隔离了,主要为了保护里面的安全以及正常工做, 来到这个门以后, 门卫确定会让你出示相关证件(鉴权检验), 意思就是判断你要见老板这个请求是否合理, 若是不合理直接就拒绝了, 让你回家等消息 , 若是鉴权以后, 发现你找老板其实只是为了和他谈谈两元店的生意, 门卫会跟你说这个用不着找老板, 你去集团投资部就好了(动态路由, 将请求路由到不一样的后端集群中), 此时会对你进行一些包装,例如给你出具一个访问证相似的,而后告诉你路该怎么走,等等。spring

你看看,网关的做用是否是就是这三个, 最终目的就是减小你与集团的耦合,具体到计算机上就是减小客户端与服务端的耦合,若是没有网关意味着全部请求都会直接调用服务器上的资源,这样耦合太强了,服务器出了问题,客户端会直接报错, 例如老板换工做的地方了,若是没有网关你直接去原来的地方找, 确定会被告知老板不在这儿。数据库

为何须要网关

当使用单体应用程序架构时，客户端（Web 或移动端）经过向后端应用程序发起一次 REST 调用来获取数据。负载均衡器将请求路由给 N 个相同的应用程序实例中的一个。而后应用程序会查询各类数据库表，并将响应返回给客户端。微服务架构下，单体应用被切割成多个微服务，若是将全部的微服务直接对外暴露，势必会出现安全方面的各类问题,另外内外耦合严重。编程

客户端能够直接向每一个微服务发送请求，其问题主要以下：后端

客户端需求和每一个微服务暴露的细粒度 API 不匹配。
部分服务使用的协议不是Web友好协议。可能使用 Thrift 二进制 RPC，也可能使用 AMQP 消息传递协议。
微服务难以重构。若是合并两个服务，或者将一个服务拆分红两个或更多服务，这类重构就很是困难了。

服务端的各个服务直接暴露给客户端调用势必会引发各类问题。同时，服务端的各个服务可扩展和伸缩性不好。API 网关是微服务架构中的基础组件，位于接入层之下和业务服务层之上，如前所述的这些功能适合在 API 网关实现。

网关与服务器集群

回到咱们服务器上,下面图介绍了网关(Gateway)做用,可知 Gateway 方式下的架构，能够细到为每个服务的实例配置一个本身的 Gateway，也能够粗到为一组服务配置一个，甚至能够粗到为整个架构配置一个接入的 Gateway。因而，整个系统架构的复杂度就会变得简单可控起来。

这张图展现了一个多层 Gateway 架构，其中有一个总的 Gateway 接入全部的流量(流量网关)，并分发给不一样的子系统，还有第二级 Gateway 用于作各个子系统的接入 Gateway(业务网关)。能够看到，网关所管理的服务粒度可粗可细。经过网关，咱们能够把分布式架构组织成一个星型架构，由网络对服务的请求进行路由和分发。下面来聊聊好的网关应该具有哪些功能,也就是网关设计模式。

网关设计思路

一个网关须要有如下的功能:

请求路由

网关必定要有请求路由的功能。这样一来，对于调用端来讲，也是一件很是方便的事情。由于调用端不须要知道本身须要用到的其它服务的地址，所有统一地交给 Gateway 来处理。

服务注册

为了可以代理后面的服务，并把请求路由到正确的位置上，网关应该有服务注册功能，也就是后端的服务实例能够把其提供服务的地址注册、取消注册。通常来讲，注册也就是注册一些 API 接口。好比，HTTP 的 Restful 请求，能够注册相应 API 的 URI、方法、HTTP 头。这样，Gateway 就能够根据接收到的请求中的信息来决定路由到哪个后端的服务上。

负载均衡

由于一个网关能够接收多个服务实例，因此网关还须要在各个对等的服务实例上作负载均衡策略。简单点就是直接 Round-Robin 轮询，复杂点的能够设置上权重进行分发，再复杂一点还能够作到 session 粘连。

弹力设计

网关还能够把弹力设计中的那些异步、重试、幂等、流控、熔断、监视等均可以实现进去。这样，一样能够像 Service Mesh 那样，让应用服务只关心本身的业务逻辑（或是说数据面上的事）而不是控制逻辑（控制面）。

安全方面

SSL 加密及证书管理、Session 验证、受权、数据校验，以及对请求源进行恶意攻击的防范。错误处理越靠前的位置就是越好，因此，网关能够作到一个全站的接入组件来对后端的服务进行保护。固然，网关还能够作更多更有趣的事情，好比：灰度发布、API聚合、API编排。

灰度发布

网关彻底能够作到对相同服务不一样版本的实例进行导流，还能够收集相关的数据。这样对于软件质量的提高，甚至产品试错都有很是积极的意义。

API 聚合

使用网关能够将多个单独请求聚合成一个请求。在微服务体系的架构中，由于服务变小了，因此一个明显的问题是，客户端可能须要屡次请求才能获得全部的数据。这样一来，客户端与后端之间的频繁通讯会对应用程序的性能和规模产生很是不利的影响。因而，咱们可让网关来帮客户端请求多个后端的服务（有些场景下彻底能够并发请求），而后把后端服务的响应结果拼装起来，回传给客户端（固然，这个过程也能够作成异步的，但这须要客户端的配合）。

API 编排

一样在微服务的架构下，要走完一个完整的业务流程，咱们须要调用一系列 API，就像一种工做流同样，这个事彻底能够经过网页来编排这个业务流程。咱们可能经过一个 DSL 来定义和编排不一样的 API，也能够经过像 AWS Lambda 服务那样的方式来串联不一样的 API。

网关设计重点

网关设计重点主要是三个, 高性能、高可用、高扩展:

高性能

在技术设计上，网关不该该也不能成为性能的瓶颈。对于高性能，最好使用高性能的编程语言来实现，如 C、C++、Go 和 Java。网关对后端的请求，以及对前端的请求的服务必定要使用异步非阻塞的 I/O 来确保后端延迟不会致使应用程序中出现性能问题。C 和 C++ 能够参看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的异步 IO 模型，Java 下如 Netty、Spring Reactor 的 NIO 框架。

高可用

由于全部的流量或调用通过网关，因此网关必须成为一个高可用的技术组件，它的稳定直接关系到了全部服务的稳定。网关若是没有设计，就会成变一个单点故障。所以，一个好的网关至少要作到如下几点。

集群化。网关要成为一个集群，其最好能够本身组成一个集群，并能够本身同步集群数据，而不须要依赖于一个第三方系统来同步数据。
服务化。网关还须要作到在不间断的状况下修改配置，一种是像 Nginx reload 配置那样，能够作到不停服务，另外一种是最好作到服务化。也就是说，得要有本身的 Admin API 来在运行时修改本身的配置。
持续化。好比重启，就是像 Nginx 那样优雅地重启。有一个主管请求分发的主进程。当咱们须要重启时，新的请求被分配到新的进程中，而老的进程处理完正在处理的请求后就退出。

高扩展

由于网关须要承接全部的业务流量和请求，因此必定会有或多或少的业务逻辑。而咱们都知道，业务逻辑是多变和不肯定的。好比，须要在网关上加入一些和业务相关的东西。所以，一个好的 Gateway 还须要是能够扩展的，并能进行二次开发的。固然，像 Nginx 那样经过 Module 进行二次开发的当然能够。

另外，在运维方面，网关应该有如下几个设计原则。

业务松耦合，协议紧耦合。在业务设计上，网关不该与后面的服务之间造成服务耦合，也不该该有业务逻辑。网关应该是在网络应用层上的组件，不该该处理通信协议体，只应该解析和处理通信协议头。另外，除了服务发现外，网关不该该有第三方服务的依赖。
应用监视，提供分析数据。网关上须要考虑应用性能的监控，除了有相应后端服务的高可用的统计以外，还须要使用 Tracing ID 实施分布式链路跟踪，并统计好必定时间内每一个 API 的吞吐量、响应时间和返回码，以便启动弹力设计中的相应策略。
用弹力设计保护后端服务。网关上必定要实现熔断、限流、重试和超时等弹力设计。若是一个或多个服务调用花费的时间过长，那么可接受超时并返回一部分数据，或是返回一个网关里的缓存的上一次成功请求的数据。你能够考虑一下这样的设计。
DevOps。由于网关这个组件太关键了，因此须要 DevOps 这样的东西，将其发生故障的几率降到最低。这个软件须要通过精良的测试，包括功能和性能的测试，还有浸泡测试。还须要有一系列自动化运维的管控工具。

网关设计注意事项

不要在网关中的代码里内置聚合后端服务的功能，而应考虑将聚合服务放在网关核心代码以外。可使用 Plugin 的方式，也能够放在网关后面造成一个 Serverless 服务。
网关应该靠近后端服务，并和后端服务使用同一个内网，这样能够保证网关和后端服务调用的低延迟，并能够减小不少网络上的问题。这里多说一句，网关处理的静态内容应该靠近用户（应该放到 CDN 上），而网关和此时的动态服务应该靠近后端服务。
网关也须要作容量扩展，因此须要成为一个集群来分担前端带来的流量。这一点，要么经过 DNS 轮询的方式实现，要么经过 CDN 来作流量调度，或者经过更为底层的性能更高的负载均衡设备。
对于服务发现，能够作一个时间不长的缓存，这样不须要每次请求都去查一下相关的服务所在的地方。固然，若是你的系统不复杂，能够考虑把服务发现的功能直接集成进网关中。
为网关考虑 bulkhead 设计方式。用不一样的网关服务不一样的后端服务，或是用不一样的网关服务前端不一样的客户。

另外，由于网关是为用户请求和后端服务的桥接装置，因此须要考虑一些安全方面的事宜。具体以下：

加密数据。能够把 SSL 相关的证书放到网关上，由网关作统一的 SSL 传输管理。
校验用户的请求。一些基本的用户验证能够放在网关上来作，好比用户是否已登陆，用户请求中的 token 是否合法等。可是，咱们须要权衡一下，网关是否须要校验用户的输入。由于这样一来，网关就须要从只关心协议头，到须要关心协议体。而协议体中的东西一方面不像协议头是标准的，另外一方面解析协议体还要耗费大量的运行时间，从而下降网关的性能。对此，我想说的是，看具体需求，一方面若是协议体是标准的，那么能够干；另外一方面，对于解析协议所带来的性能问题，须要作相应的隔离。
检测异常访问。网关须要检测一些异常访问，好比，在一段比较短的时间内请求次数超过必定数值；还好比，同一客户端的 4xx 请求出错率过高……对于这样的一些请求访问，网关一方面要把这样的请求屏蔽掉，另外一方面须要发出警告，有可能会是一些比较重大的安全问题，如被黑客攻击。

流量网关

流量网关,顾名思义就是控制流量进入集群的网关,有不少工做须要在这一步作,对于一个服务集群,势必有不少非法的请求或者无效的请求,这时候要将请求拒之门外,下降集群的流量压力。

定义全局性的、跟具体的后端业务应用和服务彻底无关的策略网关就是上图所示的架构模型——流量网关。流量网关一般只专一于全局的Api管理策略，好比全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等，有点相似防火墙。Kong 就是典型的流量网关。

下面是kong的架构图,来自官网:

这里须要补充一点的是，业务网关通常部署在流量网关以后、业务系统以前，比流量网关更靠近业务系统。一般API网指的是业务网关。有时候咱们也会模糊流量网关和业务网关，让一个网关承担全部的工做,因此这二者之间并无严格的界线。

业务网关

当一个单体应用被拆分红许许多多的微服务应用后，也带来了一些问题。一些与业务非强相关的功能，好比权限控制、日志输出、数据加密、熔断限流等，每一个微服务应用都须要，所以存在着大量重复的代码实现。并且因为系统的迭代、人员的更替，各个微服务中这些功能的实现细节出现了较大的差别，致使维护成本变高。另外一方面，原先单体应用下很是容易作的接口管理，在服务拆分后没有了一个集中管理的地方，没法统计已存在哪些接口、接口定义是什么、运行状态如何。

网关就是为了解决上述问题。做为微服务体系中的核心基础设施，通常须要具有接口管理、协议适配、熔断限流、安全防御等功能，各类开源的网关产品（好比 zuul）都提供了优秀高可扩展性的架构、能够很方便的实现咱们须要的一些功能、好比鉴权、日志监控、熔断限流等。

与流量网关相对应的就是业务网关,业务网关更靠近咱们的业务,也就是与服务器应用层打交道,那么有不少应用层须要考虑的事情就能够依托业务网关,例如在线程模型、协议适配、熔断限流，服务编排等。下面看看业务网关体系结构:

图片来自:业务网关的落地实践

从这个途中能够看出业务网关主要职责以及所作的事情, 目前业务网关比较成熟的 API 网关框架产品有三个分别是:Zuul一、Zuul2 和 SpringCloud Gateway, 后面再进行对比。

常见网关对比

既然对比,就先宏观上对各类网关有一个了解,后面再挑一些经常使用的或者说应用普遍的详细了解。

目前常见的开源网关大体上按照语言分类有以下几类：

Nginx+lua：OpenResty、Kong、Orange、Abtesting gateway 等
Java：Zuul/Zuul二、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等
Go：Janus、fagongzi、Grpc-gateway
Dotnet：Ocelot
NodeJS：Express Gateway、Micro Gateway

按照使用数量、成熟度等来划分，主流的有 4 个：

OpenResty
Kong
Zuul/Zuul2
Spring Cloud Gateway

OpenResty

Kong

Zuul1.0

Zuul是全部从设备和web站点到Netflix流媒体应用程序后端请求的前门。做为一个边缘服务应用程序，Zuul被构建来支持动态路由、监视、弹性和安全性。它还能够根据须要将请求路由到多个Amazon自动伸缩组。

Zuul使用了一系列不一样类型的过滤器，使咱们可以快速灵活地将功能应用到服务中。

过滤器

过滤器是Zuul的核心功能。它们负责应用程序的业务逻辑，能够执行各类任务。

Type ：一般定义过滤器应用在哪一个阶段
Async ：定义过滤器是同步仍是异步
Execution Order ：执行顺序
Criteria ：过滤器执行的条件
Action ：若是条件知足，过滤器执行的动做

Zuul提供了一个动态读取、编译和运行这些过滤器的框架。过滤器之间不直接通讯，而是经过每一个请求特有的RequestContext共享状态。

下面是Zuul的一些过滤器:

Incoming

Incoming过滤器在请求被代理到Origin以前执行。这一般是执行大部分业务逻辑的地方。例如:认证、动态路由、速率限制、DDoS保护、指标。

Endpoint

Endpoint过滤器负责基于incoming过滤器的执行来处理请求。Zuul有一个内置的过滤器（ProxyEndpoint），用于将请求代理到后端服务器，所以这些过滤器的典型用途是用于静态端点。例如:健康检查响应，静态错误响应，404响应。

Outgoing

Outgoing过滤器在从后端接收到响应之后执行处理操做。一般状况下，它们更多地用于造成响应和添加指标，而不是用于任何繁重的工做。例如:存储统计信息、添加/剥离标准标题、向实时流发送事件、gziping响应。

过滤器类型

下面是与一个请求典型的生命周期对应的标准的过滤器类型：

PRE ：路由到Origin以前执行
ROUTING ：路由到Origin期间执行
POST ：请求被路由到Origin以后执行
ERROR ：发生错误的时候执行

这些过滤器帮助咱们执行如下功能：

身份验证和安全性 ：识别每一个资源的身份验证需求，并拒毫不知足它们的请求
监控：在边缘跟踪有意义的数据和统计数据，以便给咱们一个准确的生产视图
动态路由 ：动态路由请求到不一样的后端集群
压力测试 ：逐渐增长集群的流量，以评估性能
限流：为每种请求类型分配容量，并丢弃超过限制的请求
静态响应处理 ：直接在边缘构建一些响应，而不是将它们转发到内部集群

Zuul 1.0 请求生命周期

Netflix宣布了通用API网关Zuul的架构转型。Zuul本来采用同步阻塞架构，转型后叫做Zuul2，采用异步非阻塞架构。Zuul2和Zuul1在架构方面的主要区别在于，Zuul2运行在异步非阻塞的框架上，好比Netty。Zuul1依赖多线程来支持吞吐量的增加，而Zuul 2使用的Netty框架依赖事件循环和回调函数。

Zuul2.0

Zuul 2.0 架构图

上图是Zuul2的架构，和Zuul1没有本质区别，两点变化：

前端用Netty Server代替Servlet，目的是支持前端异步。后端用Netty Client代替Http Client，目的是支持后端异步。
过滤器换了一下名字，用Inbound Filters代替Pre-routing Filters，用Endpoint Filter代替Routing Filter，用Outbound Filters代替Post-routing Filters。

Inbound Filters ：路由到 Origin 以前执行，能够用于身份验证、路由和装饰请求

Endpoint Filters ：可用于返回静态响应，不然内置的ProxyEndpoint过滤器将请求路由到Origin

Outbound Filters ：从Origin那里获取响应后执行，能够用于度量、装饰用户的响应或添加自定义header

有两种类型的过滤器：sync 和 async。由于Zuul是运行在一个事件循环之上的，所以历来不要在过滤中阻塞。若是你非要阻塞，能够在一个异步过滤器中这样作，而且在一个单独的线程池上运行，不然可使用同步过滤器。

上文提到过Zuul2开始采用了异步模型

优点是异步非阻塞模式启动的线程不多，基本上一个CPU core上只需启一个事件环处理线程，它使用的线程资源就不多，上下文切换(Context Switch)开销也少。非阻塞模式能够接受的链接数大大增长，能够简单理解为请求来了只须要进队列，这个队列的容量能够设得很大，只要不超时，队列中的请求都会被依次处理。

不足,异步模式让编程模型变得复杂。一方面Zuul2自己的代码要比Zuul1复杂不少，Zuul1的代码比较容易看懂，Zuul2的代码看起来就比较费劲。另外一方面异步模型没有一个明确清晰的请求->处理->响应执行流程(call flow)，它的流程是经过事件触发的，请求处理的流程随时可能被切换断开，内部实现要经过一些关联id机制才能把整个执行流再串联起来，这就给开发调试运维引入了不少复杂性，好比你在IDE里头调试异步请求流就很是困难。另外ThreadLocal机制在这种异步模式下就不能简单工做，由于只有一个事件环线程，不是每一个请求一个线程，也就没有线程局部的概念，因此对于CAT这种依赖于ThreadLocal才能工做的监控工具，调用链埋点就很差搞(实际能够工做但须要进行特殊处理)。

整体上，异步非阻塞模式比较适用于IO密集型(IO bound)场景，这种场景下系统大部分时间在处理IO，CPU计算比较轻，少许事件环线程就能处理。

Zuul 与 Zuul 2 性能对比

图片来源:Zuul's Journey to Non-Blocking

Netflix给出了一个比较模糊的数据，大体Zuul2的性能比Zuul1好20%左右，这里的性能主要指每节点每秒处理的请求数。为何说模糊呢？由于这个数据受实际测试环境，流量场景模式等众多因素影响，你很难复现这个测试数据。即使这个20%的性能提高是确实的，其实这个性能提高也并不大，和异步引入的复杂性相比，这20%的提高是否值得是个问题。Netflix自己在其博文\(^2\)和ppt\(^1\)中也是有点含糊其词，甚至自身都有一些疑问的。

Spring Cloud Gateway

相关连接:官网、中文官方文档

SpringCloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

SpringCloud Gateway 做为 Spring Cloud 生态系统中的网关，目标是替代 Zuul，在Spring Cloud 2.0以上版本中，没有对新版本的Zuul 2.0以上最新高性能版本进行集成，仍然仍是使用的Zuul 2.0以前的非Reactor模式的老版本。而为了提高网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通讯框架Netty。

Spring Cloud Gateway 的目标，不只提供统一的路由方式，而且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。

Spring Cloud Gateway 底层使用了高性能的通讯框架Netty。

SpringCloud Gateway 特征

SpringCloud官方，对SpringCloud Gateway 特征介绍以下：

（1）基于 Spring Framework 5，Project Reactor 和 Spring Boot 2.0

（2）集成 Hystrix 断路器

（3）集成 Spring Cloud DiscoveryClient

（4）Predicates 和 Filters 做用于特定路由，易于编写的 Predicates 和 Filters

（5）具有一些网关的高级功能：动态路由、限流、路径重写

从以上的特征来讲，和Zuul的特征差异不大。SpringCloud Gateway和Zuul主要的区别，仍是在底层的通讯框架上。

简单说明一下上文中的三个术语：

Filter（过滤器）

和Zuul的过滤器在概念上相似，可使用它拦截和修改请求，而且对上游的响应，进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。

Route（路由）

网关配置的基本组成模块，和Zuul的路由配置模块相似。一个Route模块由一个 ID，一个目标 URI，一组断言和一组过滤器定义。若是断言为真，则路由匹配，目标URI会被访问。

Predicate（断言）：

这是一个 Java 8 的 Predicate，可使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。

几种网关的对比

网关	限流	鉴权	监控	易用性	可维护性	成熟度
Spring Cloud Gateway	能够经过IP，用户，集群限流，提供了相应的接口进行扩展	普通鉴权、auth2.0	Gateway Metrics Filter	简单易用	spring系列可扩展强，易配置可维护性好	spring社区成熟，但gateway资源较少
Zuul2	能够经过配置文件配置集群限流和单服务器限流亦可经过filter实现限流扩展	filter中实现	filter中实现	参考资料较少	可维护性较差	开源不久，资料少
OpenResty	须要lua开发	须要lua开发	须要开发	简单易用，可是须要进行的lua开发不少	可维护性较差，未来须要维护大量lua脚本	很成熟资料不少
Kong	根据秒，分，时，天，月，年，根据用户进行限流。可在原码的基础上进行开发	普通鉴权，Key Auth鉴权，HMAC，auth2.0	可上报datadog，记录请求数量，请求数据量，应答数据量，接收于发送的时间间隔，状态码数量，kong内运行时间	简单易用，api转发经过管理员接口配置，开发须要lua脚本	"可维护性较差，未来须要维护大量lua库	相对成熟，用户问题汇总，社区，插件开源

站在巨人的肩膀上

一、Zuul's Journey to Non-Blocking

二、Zuul 2 : The Netflix Journey to Asynchronous, Non-Blocking Systems