微服务网关

网关在任何系统架构中都是一个很重要的组件，它位于客户端与服务端之间，可以将其想象成一道闸门，所有的客户端请求都要从此门经过。因此，网关就具有很大的权利，可以对这些请求进行各种限制。例如，控制访问流量、身份验证、日志记录、负载分流等。

网关与Nginx、LVS等负载软件有类似之处，但是本质却不相同。

下面对网关的原理、功能、架构方式进行详细讲解。

3.7.1 网关的原理

微服务本身是一个网状调用结构，节点众多，但是每个服务都有对外（互联网）服务和对内（内网）服务的接口，如何将对外服务的接口开放出去呢？首先可以想到的就是把需要开放的服务部署到外网访问。

微服务直接开放到外网的架构如图3-24所示，将服务A、B直接开放到外网，App端、Web端通过域名直接访问这两个微服务，对于一些不需要对外开放的服务也被开放出去了，十分危险。

图3-24 微服务直接开放到外网的架构

传统的做法是通过Nginx等反向代理设备将内网微服务的部分接口开放到外网，如图3-25所示，那么在Nginx上就需要对所有需要开放的微服务进行配置，并且当微服务节点上线、下线无法动态调整时，必须通过人为手动修改刷新，无法让整个微服务自治，不符合微服务自治原则。

图3-25 通过Nginx等负载设备将微服务开放到外网的架构

微服务的网关服务也属于一个微服务，只是它并不处理具体的业务逻辑，而是只负责反向代理其他微服务，网关和其他所有微服务一样都注册到注册中心上，所以它能感知到其他微服务的变化，并且支持客户端负载均衡，其架构如图3-26所示。例如，将服务A、B的部分接口配置在网关上，再将网关开放到外网即可。

图3-26 微服务网关架构

Spring Cloud微服务中主要使用Zuul和Spring Cloud Gateway两种网关，Zuul为第一代网关， Spring Cloud Gateway为第二代网关。

3.7.2 网关的功能

网关具有接口限流、负载、缓存、加解密、请求和应答、日志记录、交易统计分析、安全认证等非业务功能。同时，网关具有路由能力，可以根据路由规则选择服务的转发路径，十分灵活，这也是

Nginx、LVS等软件无法做到的，它们只能起到缓存、限流、反向代理的部分作用。网关的8个功能详细说明如下。

（1）     身份验证和安全：识别每个资源的身份验证要求，并拒绝不满足身份认证的请求，提高系统的安全性，可以与认证中心、JWT、

SSO等技术联合使用。

（2）     洞察和监测：网关可以获取到详细的请求和应答数据，以及响应时长等情况，因此可以更好地洞察服务状态，监测服务异常。（3）动态路由：可以根据需要将请求动态路由到不同的后端集群上，可以定制不同的路由规则。例如，某个服务10点到20点之间可以访问，其他时间关闭。

（4）     压力测试：可以利用网关调节客户端请求的数量，并逐渐增加后端集群的流量进行压力测试，以衡量服务性能。

（5）     服务限流：可以根据不同类型的请求，如按照目标服务、用户、IP地址等作为Key，进行流量分配，删除或拒绝超出限制的请求。详细的限流技术可参见2.1.11小节。

（6）     负载分配：网关可以根据负载策略进行客户端负载，将请求转发到不同的后端服务上。

（7）     静态资源代理：可以直接将静态资源放置在网关服务中，加快静态资源的访问速度，减轻后端服务的压力，同时可以对静态资源进行相应的权限控制。

（8）     多区域弹性：当有多个数据中心时，可以根据需要通过网关将请求发送至不同的区域中。

3.7.3 微服务网关与Nginx对比

微服务网关与Nginx存在部分功能重合，Nginx也可以作为网关使用，同样具有反向代理、负载均衡、访问限流、静态资源代理等能

力，两者都可以进行编程以增强基本功能（Nginx可以使用Lua脚本进行编程）。但是，两者又存在很多的区别，应用场景也有所不同，主要总结为以下5点。（1）两者的负载方式不同，Nginx为服务端负载，微服务网关为客户端负载。

（2）     当增加或减少服务节点，变动IP地址或端口时，微服务网关不需要做出任何代码调整，因为这些信息可以从注册中心获取，而

Nginx需要修改配置文件并重新加载。

（3）     Nginx的应用场景更广，主要侧重点为反向代理、动静分离、负载均衡，可以在单体架构、集群架构、SOA架构、微服务架构中使用，而微服务网关只能在微服务架构中使用，因为网关要借助注册中心的能力。

（4）     虽然Nginx可以借助Lua脚本进行扩展，但是微服务网关可以进行更加深度的自定义开发。

（5）     Nginx可以在四层和七层网络上进行负载，而微服务网关只能在七层网络上进行负载。

在微服务架构中，Nginx和微服务网关可以同时使用，形成多级负载架构，如图3-27所示。Nginx对微服务网关进行反向代理，使微服务网关可以水平扩展。还可以在Nginx之前增加VIP、硬负载、LVS、

HAProxy形成更为复杂的多级负载架构，用来支撑更高的并发请求。多级负载架构设计可参见2.1.3小节。

图3-27 Nginx+微服务网关

Nginx除了可以与微服务网关联合使用，还可以反向代理注册中心、配置中心服务，提高系统的可用性。

3.7.4 正确的网关架构

工作中十分容易出现的错误，就是将网关作为ESB使用，使其成为整个微服务的交互中心，成为一个中心化的ESB系统，如图3-28所示。

图3-28 将网关作为交互的中心

为了让所有服务之间的交互都经过加解密、日志记录、安全认证等环节，所有的服务请求都经过了网关过滤。因此，A→B→C这样的一个交易链路就会变为A→网关→B→网关→C，这样虽然能够简化开发，但是无形之中将微服务架构变为了ESB架构，去中心化架构变为了中心化架构。一旦网关出现故障将导致整个服务异常。网关的引入也使得交易链路变长，响应时效降低，因此一定要避免这个误区。对于中小型的项目，为了方便利用网关的检测洞察、身份校验、限流等能力，也可以将网关作为ESB使用，但是在大型的互联网项目中会严重影响系统的可用性和响应速度。

推荐的网关架构如图3-29所示，为外网客户端调用设立单独的外网网关，为内网客户端调用设立单独的内网网关。形成内外网隔离架构，外网网关只提供能够暴露到互联网上的接口，内网网关只提供能够在内网调用的接口。

图3-29 推荐的网关架构

这样做的好处有以下两点。

（1）安全性更高：暴露在外网的接口比较容易受到各种不法攻击，如果将内网的接口也暴露到互联网上是十分危险的。因此，外网网关要严格区分所代理的接口是否能够开放到互联网上。（2）隔离性更好：如果内外网共用同一个网关就会产生相互影响，外网请求量过大就会影响内网的服务调用，反之亦然。如果网关出现故障就会同时影响内外网服务，而两个网关可以对故障进行有效的隔离。