微服务-网关

在微服务架构中，每个服务都是一个可以独立开发和运行的组件，而一个完整的微服务架构由一系列独立运行的微服务组成。其中每个服务都只会完成特定领域的功能，比如订单服务提供与订单业务场景有关的功能、商品服务提供商品展示功能等。各个微服务之间通过轻量级通信机制REST API或者RPC完成通信。

实现微服务之后在某些层面会带来一定的影响，比如，一个用户查看一个商品的详情，对于客户端来说，可能需要调用商品服务、评论服务、库存服务、营销服务等多个服务来完成数据的渲染。如图10-1所示，在这个场景中，客户端虽然能通过调用多个服务实现数据的获取，但是会存在一些问题，比如:

客户端需要发起多次请求，增加了网络通信的成本及客户端处理的复杂性。
服务的鉴权会分布在每个微服务中处理，客户端对于每个服务的调用都需要重复鉴权。
在后端的微服务架构中，可能不同的服务采用的协议不同，比如有HTTP、RPC等。客户端如果需要调用多个服务，需要对不同协议进行适配。

在这里插入图片描述

一 API网关的作用

网关可以用来解决这个问题，如图10-2所示，在客户端与服务端之间增加了一个API网关。整体来看，网关有点类似于门面，所有的外部请求都会先经过网关这一层。
对于商品详情展示的场景来说，增加了API网关之后，在API网关层可以把后端的多个服务进行整合，然后提供唯一的业务接口，客户端只需要调用这个接口即可完成数据的获取及展示。在网关中会再消费后端的多个微服务，进行统一的整合，给客户端返回唯一的响应。

在这里插入图片描述
网关不仅只是做一个请求的转发及服务的整合，有了网关这个统一的入口之后，它还能提供以下功能。

针对所有请求进行统一鉴权、限流、熔断、日志。
协议转化。针对后端多种不同的协议，在网关层统一处理后以HTTP对外提供服务。用过Dubbo框架的读者应该知道，针对Dubbo服务还需要提供一个Web应用来进行协议转化。
统一错误码处理。
请求转发，并且可以基于网关实现内、外网隔离

下面针对上述网关作用的分析，选择几种常见的方案进行详细说明。

二、网关场景说明

2.1 统一认证鉴权

统一认证鉴权包含如下两部分。

客户端身份认证:主要用于判断当前用户是否为合法用户，一般的做法是使用账号和密码进行验证。当然，对于一些复杂的认证场景会采用加密算法来实现，比如公、私钥。
访问权限控制:身份认证和访问权限一般是相互联系的，当身份认证通过后，就需要判断该用户是否有权限访问该资源，或者该用户的访问权限是否被限制了。

在单体应用中，客户端身份认证及访问权限的控制比较简单，只需要在服务端通过session保存该用户信息即可。但是在微服务架构下，单体应用被拆分成多个微服务，鉴权的过程就会变得很复杂。

首先要解决的问题是，原来单体应用中的session方式已经无法用于微服务场景。
其次就是如何实现对每个微服务进行鉴权。

当然，对于第一个问题，目前已经有非常多的成熟解决方案了，比如AccessToken、Oauth(开放API)等。对于第二个问题，我们可以把鉴权的功能抽离出一个统一认证服务，所有的微服务在被访问之前，先访问该认证服务进行鉴权。这种解决方案看似合理，但是在实际应用中，一个业务场景中可能会调用多个微服务，就会造成一次请求需要进行多次鉴权操作，增加了网络通信开销。

如图10-3所示，增加API网关之后，在网关层进行请求拦截，获取请求中附带的用户身份信息，调用统一认证中心对请求进行身份认证，在确认了身份之后再检查是否有资源的访问权限。

在这里插入图片描述

2.2 灰度发布

互联网公司的产品有一个特点，就是迭代非常快，很多公司会采用一周发布一个版本的选代模式。在这种高频率的迭代模式下，往往会伴随着一些风险，比如:

新发布的代码出现兼容性问题。
新的功能发布后，用户是否能够接受，如果不能，会造成用户流失。
代码中存在隐藏的Bug，导致线上故障。

为了规避这些问题，对于有较大的功能性改动的版本一般都会采取灰度发布(又名金丝雀发布)的方式来实现平滑过渡。

所谓灰度发布，就是指将要发布的功能先开放给一小部分用户使用，把影响范围控制在一个非常小的范围比如A/B Test就是一种灰度发布方式，即一部分用户继续使用A功能，另外一小部分用户使用新的B功能。通过对使用B功能的用户进行满意度调查，以及对新发布的代码的性能和稳定性指标进行评测，逐步放大该新版本的投放，直到全量或者回滚该版本。

对于应用系统来说，无非就是将新的功能发布在特定的灰度机器上，然后根据设定的规则将部分请求路由到灰度服务器上。

网关是所有客户端请求的入口，因此在网关层可以通过灰度规则进行部分流量的路由，从而实现灰度发布。
如图10-4所示，网关对请求进行拦截之后，会根据分流引擎配置的分流规则进行请求的路由。

在这里插入图片描述

三、网关的本质及技术选型

通过前面的分析可以发现，网关的本质应该是对请求进行路由转发，以及对请求进行前置和后置的过滤。

请求的转发和路由:接收客户端的所有请求，并将请求转发到后端的微服务中。因为微服务的粒度比较细，所以API网关又类似于门面模式，对多个微服务进行功能整合，提供唯一的业务接口给客户端。
过滤:网关会拦截所有的请求来完成一系列的横切工作，比如鉴权、限流。

常见的开源API网关实现方案有很多，比如OpenResty、Zuu、GateWay、Orange、Kong、Tyk等，下面

3.1 openResty

OpenResty实际上是由Nginx与Lua集成的一个高性能Web应用服务器，它的内部集成了大量优秀的Lua库、第三方模块。并且OpenResty团队自己研发了很多优秀的Nginx模块，开发人员可以使用Lua脚本来调用Nginx支持的C模块及Lua模块。
简单来说**，OpenResty本质上就是将Lua嵌入Nginx中，在每一个Nginx的进程中都嵌入了一个LuaJIT虚拟机来执行Lua脚本**。
对于OpenResty来说，它本质上仍然是Nginx服务器，可以实现反向代理和负载均衡。但是OpenResty为什么能够实现网关功能呢?

前面我们提到过，网关的本质是对请求进行路由转发及过滤，这意味着OpenResty在接收到客户端的请求时，同样可以拦截请求进行前置和后置的处理。事实上，OpenResty确实支持这种操作，它可以在不同的阶段来挂载Lua脚本实现不同阶段的自定义行为。如图10-5所示，可以看到init_by_lua、init_worker by_lua、setby_ua等11个指令，OpenResty实现网关功能的核心就是在这11个步骤中挂载Lua脚本来实现功能的扩展。

在这里插入图片描述
一个请求进入OpenResty之后，会根据请求所在的不同阶段按照如图10-5所示的流程执行不同的指令，每个指令的作用如下。

init_by_lua:当Nginx Master进程加载Nginx配置文件时会运行这段Lua脚本。
init_worker_by_lua:每个Nginx worker进程启动时会执行的Lua脚本，可以用来做健康检查
ssl_certificate_by_lua:当Nginx开始对下游进行SSL(HTTPS)握手连接时，该指令执行用

3.2 Spring Cloud Zuul

Zuul是Netflix开源的微服务网关，它的主要功能是路由转发和过滤。大部分读者接触到Zuul应该是在SpringCloud Netflix生态中，它被整合到Spring Cloud中为微服务架构提供API网关的功能。
如图10-6所示，Zuul的核心由一系列过滤器组成，它定义了4种标准类型的过滤器，这些会对应请求的整个生命周期。

在这里插入图片描述

Pre Filters:前置过滤器,请求被路由之前调用，可以用于处理鉴权、限流等。
Routing Filters:路由过滤器，将请求路由到后端的微服务。
Post Filters:后置过滤器，路由过滤器中远程调用结束后执行。可以用于做统计、监控、日志等。
Error Filters:错误过滤器，任意一个过滤器出现异常或者远程服务调用超时会被调用。

3.3 Spring Cloud Gateway

Spring Cloud Gateway是Spring官方团队研发的API网关技术，它的目的是取代Zuul为微服务提供一种简单高效的API网关。
一般来说，Spring团队不会重复造轮子，为什么又研发出一个Spring Cloud Gateway呢?有以下几方面原因。

Zuul 1.x采用的是传统的thread per connection方式来处理请求，也就是针对每一个请求，会为这个请求专门分配一个线程来进行处理，直到这个请求完成之后才会释放线程，一旦后台服务器响应较慢，就会使得该线程被阻塞，所以它的性能不是很好。
Zuul本身存在的一些性能问题不适合于高并发的场景，虽然后来Netfix决定开发高性能版Zuul2.x，但是Zuu 2.x的发布时间一直不确定。虽然Zuul 2.x后来已经发布并且开源了，但是Spring Cloud并没有打算集成进来。
Spring Cloud Gateway是依赖于Spring Boot 2.0、Spring Webflux和Project Reactor等技术开发的网关，它不仅提供了统一的路由请求的方式，还基于过滤链的方式提供了网关最基本的功能。下面通过一些案例来了解Spring Cloud Gateway。

四、Reactor 技术特点

Reactor 是一个用于JVM的完全非阻塞的响应式编程框架，具备高效的需求管理（即对 “背压（backpressure）”的控制）能力。它与 Java 8 函数式 API 直接集成Reactor 是一个用于JVM的完全非阻塞的响应式编程框架，具备高效的需求管理（即对 “背压（backpressure）”的控制）能力。它与 Java 8 函数式 API 直接集成，比如 CompletableFuture， Stream，以及 Duration。它提供了异步序列 API Flux（用于[N]个元素）和 Mono（用于 [0|1]个元素），并完全遵循和实现了“响应式扩展规范”（Reactive Extensions Specification）。

Reactor 的 reactor-ipc 组件还支持非阻塞的进程间通信（inter-process communication, IPC）。 Reactor IPC 为 HTTP（包括 Websockets）、TCP 和 UDP 提供了支持背压的网络引擎，从而适合应用于微服务架构。并且完整支持响应式编解码（reactive encoding and decoding）。

<dependencyManagement> <dependencies><dependency><groupId>io.projectreactor</groupId><artifactId>reactor-bom</artifactId><version>2023.0.0</version><type>pom</type><scope>import</scope></dependency></dependencies>
</dependencyManagement><dependencies><dependency><groupId>io.projectreactor</groupId><artifactId>reactor-core</artifactId> </dependency><dependency><groupId>io.projectreactor</groupId><artifactId>reactor-test</artifactId> <scope>test</scope></dependency>
</dependencies>

4.2、响应式编程

响应式编程是一种关注于数据流（data streams）和变化传递（propagation of change）的异步编程方式。这意味着它可以用既有的编程语言表达静态（如数组）或动态（如事件源）的数据流。
参考：https://blog.csdn.net/qq_63438013/article/details/136461257