微服务架构下网关的技能选型

藏宝库编辑 · 2024-10-4 10:04:04

1 简介

当利用单体应用步伐架构时，客户端（Web 或移动端）通过向后端应用步伐发起一次 REST 调用来获取数据。负载平衡器将哀求路由给 N 个雷同的应用步伐实例中的一个。然后应用步伐会查询各种数据库表，并将相应返回给客户端。微服务架构下，单体应用被切割成多个微服务，如果将全部的微服务直接对外袒露，势必会出现安全方面的各种标题，另外表里耦合严重。
客户端可以直接向每个微服务发送哀求，其标题重要如下：

客户端需求和每个微服务袒露的细粒度 API 不匹配。
部分服务利用的协议不是Web友爱协议。大概利用 Thrift 二进制 RPC，也大概利用 AMQP 消息转达协议。
微服务难以重构。如果归并两个服务，或者将一个服务拆分成两个或更多服务，这类重构就非常困难了。

服务端的各个服务直接袒露给客户端调用势必会引起各种标题。同时，服务端的各个服务可扩展和伸缩性很差。API 网关是微服务架构中的根本组件，位于接入层之下和业务服务层之上，如前所述的这些功能得当在 API 网关实现。
1.1 什么是网关？

网关的角色是作为一个API架构，用来保护、增强和控制对于API服务的访问。它是一个处于应用步伐或服务（提供REST API接口服务）之前的体系，用来管理授权、访问控制和流量限定等。这样REST API接口服务就被网关保护起来，对全部的调用者透明。因此，潜伏在API网关反面的业务体系就可以专注于创建和管理服务，无需关心这些战略性的哀求。
1.2 API网关的四大职能

哀求接入：作为全部API接口服务哀求的接入点，管理全部的接入哀求。
业务聚合：作为全部后端业务服务的聚合点，全部的业务服务都可以在这里被调用。
中介战略：实现安全、验证、路由、过滤、流控、缓存等战略，举行一些须要的中介处理。
同一管理：提供设置管理工具，对全部API服务的调用生命周期和相应的中介战略举行同一管理。

1.3 微服务下网关作用

下面图先容了网关(Gateway)作用，可知 Gateway 方式下的架构，可以细到为每一个服务的实例设置一个自己的 Gateway，也可以粗到为一组服务设置一个，以致可以粗到为整个架构设置一个接入的 Gateway。于是，整个体系架构的复杂度就会变得简朴可控起来。
这张图展示了一个多层 Gateway 架构，此中有一个总的 Gateway 接入全部的流量(流量网关 )，并分发给不同的子体系，尚有第二级 Gateway 用于做各个子体系的接入 Gateway(业务网关 )。可以看到，网关所管理的服务粒度可粗可细。通过网关，我们可以把分布式架构组织成一个星型架构，由网络对服务的哀求举行路由和分发。下面来聊聊好的网关应该具备哪些功能，也就是网关筹划模式。
2 网关筹划思路

API网关并不是一个范例的业务体系，而是一个为了让业务体系更专注于业务自己，给API服务提供更多附加本领的一个中央层。一个网关必要有以下的功能:

哀求路由
网关肯定要有哀求路由的功能。这样一来，对于调用端来说，也是一件非常方便的变乱。因为调用端不必要知道自己必要用到的别的服务的地点，全部同一地交给 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。

3 网关筹划重点

网关筹划重点重要是三个，高性能、高可用、高扩展:
3.1 高性能

在技能筹划上，网关不应该也不能成为性能的瓶颈。对于高性能，最好利用高性能的编程语言来实现，如 C、C++、Go 和 Java。网关对后端的哀求，以及对前端的哀求的服务肯定要利用异步非壅闭的 I/O 来确保后端延长不会导致应用步伐中出现性能标题。C 和 C++ 可以参看 Linux 下的 epoll 和 Windows 的 I/O Completion Port 的异步 IO 模子，Java 下如 Netty、Spring Reactor 的 NIO 框架。
3.2 高可用

因为全部的流量或调用颠末网关，以是网关必须成为一个高可用的技能组件，它的稳固直接关系到了全部服务的稳固。网关如果没有筹划，就会成变一个单点故障。因此，一个好的网关至少要做到以下几点。

集群化 。网关要成为一个集群，其最好可以自己构成一个集群，并可以自己同步集群数据，而不必要依赖于一个第三方体系来同步数据。
服务化 。网关还必要做到在不中断的情况下修改设置，一种是像 Nginx reload 设置那样，可以做到不绝服务，另一种是最好做到服务化。也就是说，得要有自己的 Admin API 来在运行时修改自己的设置。
一连化 。好比重启，就是像 Nginx 那样优雅地重启。有一个主管哀求分发的主历程。当我们必要重启时，新的哀求被分配到新的历程中，而老的历程处理完正在处理的哀求后就退出。

3.3 高扩展

因为网关必要承接全部的业务流量和哀求，以是肯定会有或多或少的业务逻辑。而我们都知道，业务逻辑是多变和不确定的。好比，必要在网关上加入一些和业务干系的东西。因此，一个好的 Gateway 还必要是可以扩展的，并能举行二次开发的。固然，像 Nginx 那样通过 Module 举行二次开发的固然可以。
另外，在运维方面，网关应该有以下几个筹划原则。

业务松耦合，协议紧耦合。在业务筹划上，网关不应与反面的服务之间形成服务耦合，也不应该有业务逻辑。网关应该是在网络应用层上的组件，不应该处理通讯协议体，只应该分析和处理通讯协议头。另外，除了服务发现外，网关不应该有第三方服务的依赖。
应用监视，提供分析数据。网关上必要思量应用性能的监控，除了有相应后端服务的高可用的统计之外，还必要利用 Tracing ID 实行分布式链路跟踪，并统计好肯定时间内每个 API 的吞吐量、相应时间和返回码，以便启动弹力筹划中的相应战略。
用弹力筹划保护后端服务。网关上肯定要实现熔断、限流、重试和超时等弹力筹划。如果一个或多个服务调用花费的时间过长，那么可继承超时并返回一部分数据，或是返回一个网关里的缓存的上一次乐成哀求的数据。你可以思量一下这样的筹划。
DevOps 。因为网关这个组件太关键了，以是必要 DevOps 这样的东西，将其发生故障的概率降到最低。这个软件必要颠末良好的测试，包罗功能和性能的测试，尚有浸泡测试。还必要有一系列自动化运维的管控工具。

4 网关筹划注意事项

不要在网关中的代码里内置聚合后端服务的功能，而应思量将聚合服务放在网关焦点代码之外。可以利用 Plugin 的方式，也可以放在网关反面形成一个 Serverless 服务。
网关应该靠近后端服务，并和后端服务利用同一个内网，这样可以包管网关和后端服务调用的低延长，并可以镌汰很多网络上的标题。这里多说一句，网关处理的静态内容应该靠近用户（应该放到 CDN 上），而网关和此时的动态服务应该靠近后端服务。
网关也必要做容量扩展，以是必要成为一个集群来分担前端带来的流量。这一点，要么通过 DNS 轮询的方式实现，要么通过 CDN 来做流量调治，或者通过更为底层的性能更高的负载平衡装备。
对于服务发现，可以做一个时间不长的缓存，这样不必要每次哀求都去查一下干系的服务地点的地方。固然，如果你的体系不复杂，可以思量把服务发现的功能直接集成进网关中。
为网关思量 bulkhead 筹划方式。用不同的网关服务不同的后端服务，或是用不同的网关服务前端不同的客户。
保持大规模的inbound哀求接入本领（黑白链接），好比基于Netty实现。
最大限度地复用outbound的HTTP毗连本领，好比基于httpClietn4的异步实现。
方便机动地实现安全、验证、过滤、聚合、限流、监控等各种战略。

另外，因为网关是为用户哀求和后端服务的桥接装置，以是必要思量一些安全方面的变乱。详细如下：

加密数据 。可以把 SSL 干系的证书放到网关上，由网关做同一的 SSL 传输管理。
校验用户的哀求 。一些根本的用户验证可以放在网关上来做，好比用户是否已登录，用户哀求中的 token 是否正当等。但是，我们必要权衡一下，网关是否必要校验用户的输入。因为这样一来，网关就必要从只关心协议头，到必要关心协议体。而协议体中的东西一方面不像协议头是标准的，另一方面分析协议体还要泯灭大量的运行时间，从而降低网关的性能。对此，我想说的是，看详细需求，一方面如果协议体是标准的，那么可以干；另一方面，对于分析协议所带来的性能标题，必要做相应的隔离。
检测非常访问 。网关必要检测一些非常访问，好比，在一段比力短的时间内哀求次数凌驾肯定命值；还好比，同一客户端的 4xx 哀求堕落率太高……对于这样的一些哀求访问，网关一方面要把这样的哀求屏蔽掉，另一方面必要发出告诫，有大概会是一些比力庞大的安全标题，如被黑客攻击。

5 流量网关

流量网关，顾名思义就是控制流量进入集群的网关，有很多工作必要在这一步做，对于一个服务集群，势必有很多非法的哀求或者无效的哀求，这时间要将哀求拒之门外，降低集群的流量压力。

界说全局性的、跟详细的后端业务应用和服务完全无关的战略网关就是上图所示的架构模子——流量网关。流量网关通常只专注于全局的Api管理战略，好比全局流量监控、日志纪录、全范围流、优劣名单控制、接入哀求到业务体系的负载平衡等，有点雷同防火墙。Kong 就是范例的流量网关。
下面是kong的架构图，来自官网：

这里必要增补一点的是，业务网关一样平常摆设在流量网关之后、业务体系之前，比流量网关更靠近业务体系。通常API网指的是业务网关。偶然间我们也会暗昧流量网关和业务网关，让一个网关负担全部的工作，以是这两者之间并没有严酷的界限。
6 业务网关

当一个单体应用被拆分成许很多多的微服务应用后，也带来了一些标题。一些与业务非强干系的功能，好比权限控制、日志输出、数据加密、熔断限流等，每个微服务应用都必要，因此存在着大量重复的代码实现。而且由于体系的迭代、职员的更替，各个微服务中这些功能的实现细节出现了较大的差异，导致维护成本变高。另一方面，原先单体应用下非常容易做的接口管理，在服务拆分后没有了一个会合管理的地方，无法统计已存在哪些接口、接口界说是什么、运行状态如何。
网关就是为相识决上述标题。作为微服务体系中的焦点根本办法，一样平常必要具备接口管理、协议适配、熔断限流、安全防护等功能，各种开源的网关产物（好比 zuul）都提供了良好高可扩展性的架构、可以很方便的实现我们必要的一些功能、好比鉴权、日志监控、熔断限流等。
与流量网关相对应的就是业务网关，业务网关更靠近我们的业务，也就是与服务器应用层打交道，那么有很多应用层必要思量的变乱就可以依托业务网关，比方在线程模子、协议适配、熔断限流，服务编排等。下面看看业务网关体系结构:
从这个图中可以看出业务网关重要职责以及所做的变乱，现在业务网关比力成熟的 API 网关框架产物有三个分别是:Zuul1、Zuul2 和 SpringCloud Gateway，反面再举行对比。
7 常见网关对比

现在常见的开源网关大抵上按照语言分类有如下几类：

Nginx+lua ：OpenResty、Kong、Orange、Abtesting gateway 等
Java ：Zuul/Zuul2、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

7.1 OpenResty

OpenResty是一个流量网关，根据前面临流量网关的先容就可以知道流量网关的职责。
OpenResty基于 Nginx与 Lua 的高性能 Web 平台，其内部集成了大量良好的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。
通过揉和浩繁筹划良好的 Nginx 模块，OpenResty 有效地把 Nginx 服务器转变为一个强盛的 Web 应用服务器，基于它开发职员可以利用 Lua 编程语言对 Nginx 焦点以及现有的各种 Nginx C 模块举行脚本编程，构建出可以处理一万以上并发哀求的非常高性能的 Web 应用
OpenResty 最早是顺应 OpenAPI 的潮流做的，以是 Open 取自“开放”之意，而Resty便是 REST 风格的意思。虽然厥后也可以基于 ngx_openresty 实现任何情势的 web service 或者传统的 web 应用。
也就是说 Nginx 不再是一个简朴的静态网页服务器，也不再是一个简朴的反向署理了。第二代的 openresty 致力于通过一系列 nginx 模块，把nginx扩展为全功能的 web 应用服务器。
ngx_openresty 是用户驱动的项目，厥后也有不少国内用户的参与，从 openresty.org 的点击量分布上看，国内和国外的点击量根本持平。
ngx_openresty 现在有两大应用目的：

通用目的的 web 应用服务器。在这个目的下，现有的 web 应用技能都可以算是和 OpenResty 或多或少有些雷同，好比 Nodejs， PHP 等等。ngx_openresty 的性能（包罗内存利用和 CPU 服从）算是最大的卖点之一。
Nginx 的脚本扩展编程，用于构建机动的 Web 应用网关和 Web 应用防火墙。有些雷同的是 NetScaler。其上风在于 Lua 编程带来的巨大机动性。

7.2 Kong

Kong基于OpenResty开发，也是流量层网关，是一个云原生、快速、可扩展、分布式的Api 网关。继承了OpenResty的高性能、易扩展性等特点。Kong通过简朴的增长呆板节点，可以很容易的程度扩展。同时功能插件化，可通过插件来扩展其本领。而且在任何根本架构上都可以运行。具有以下特性：

提供了多样化的认证层来保护Api。
可对收支流量举行管制。
提供了可视化的流量查抄、监视分析Api。
能够及时的转换哀求和相应。
提供log办理方案
可通过api调用Serverless 函数。

Kong办理了什么标题

当我们决定对应用举行微服务改造时，应用客户端如何与微服务交互的标题也随之而来，毕竟服务数量的增长会直接导致摆设授权、负载平衡、通讯管理、分析和改变的难度增长。
面临以上标题，API GATEWAY是一个不错的办理方案，其所提供的访问限定、安全、流量控制、分析监控、日志、哀求转发、合成和协议转换功能，可以解放开发者去把精神会合在详细逻辑的代码，而不是把时间花费在思量如何办理应用和其他微服务链接的标题上。
从下图可以看到Kong办理的标题。专注于全局的Api管理战略，全局流量监控、日志纪录、全范围流、优劣名单控制、接入哀求到业务体系的负载平衡等。
Kong的优点以及性能

在浩繁 API GATEWAY 框架中，Mashape 开源的高性能高可用API网关和API服务管理层——KONG（基于 NGINX+Lua）特点尤为突出，它可以通过插件扩展已有功能，这些插件（利用 lua 编写）在API哀求相应循环的生命周期中被实行。于此同时，KONG自己提供包罗 HTTP 根本认证、密钥认证、CORS、TCP、UDP、文件日志、API哀求限流、哀求转发及 NGINX 监控等根本功能。现在，Kong 在 Mashape 管理了凌驾 15，000 个 API，为 200，000 开发者提供了每月数十亿的哀求支持。
Kong架构

起首最底层是基于Nginx， Nginx是高性能的根本层，一个良好的负载平衡、反向署理器，然后在此根本上增长Lua脚本库，形成了OpenResty，拦截哀求，相应生命周期，可以通过Lua编写脚本，以是插件比力丰富。
7.3 Zuul2.0

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

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

Zuul2接纳了异步模子
上风：：是异步非壅闭模式启动的线程很少，根本上一个CPU core上只需启一个变乱环处理线程，它利用的线程资源就很少，上下文切换(Context Switch)开销也少。非壅闭模式可以继承的毗连数大大增长，可以简朴明白为哀求来了只必要进队列，这个队列的容量可以设得很大，只要不超时，队列中的哀求都会被依次处理。
不敷： 异步模式让编程模子变得复杂。一方面Zuul2自己的代码要比Zuul1复杂很多，Zuul1的代码比力容易看懂，Zuul2的代码看起来就比力费劲。另一方面异步模子没有一个明白清晰的哀求->处理->相应实行流程(call flow)，它的流程是通过变乱触发的，哀求处理的流程随时大概被切换断开，内部实现要通过一些关联id机制才气把整个实行流再串联起来，这就给开发调试运维引入了很多复杂性，好比你在IDE里头调试异步哀求流就非常困难。另外ThreadLocal机制在这种异步模式下就不能简朴工作，因为只有一个变乱环线程，不是每个哀求一个线程，也就没有线程局部的概念，以是对于CAT这种依赖于ThreadLocal才气工作的监控工具，调用链埋点就不好搞(现实可以工作但必要举行特殊处理)。
总体上，异步非壅闭模式比力实用于IO麋集型(IO bound)场景，这种场景下体系大部分时间在处理IO，CPU盘算比力轻，少量变乱环线程就能处理。
7.4 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）具备一些网关的高级功能：动态路由、限流、路径重写
8 几种网关的对比

基于不同的业务场景，选择不同的API网关组件，应对不同的体系流量和并发数。不同的业务场景，在技能选型上也是及其告急的一环。比方：Kong的性能虽然非常不错，得当做流量网关，但是对于复杂的业务体系不发起用Kong，因为会给体系的性能带来缺陷。再如SpringCloud GateWay/Zuul2对于Java技能栈来说比力方便，但是对于lua开发语言不方便。

微服务架构下网关的技能选型

所属分类: 问答交流

新帖推荐: 30日

推荐作品