SpringCloud的基本组件（Gateway）

一、服务网关

1、服务网关是什么？

      API Gateway (APIGW/API网关)，顾名思义，是出现在系统边界上的一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，可以理解为企业级应用防火墙，主要起到隔离外部访问与内部系统的作用。在微服务概念的流行之前，API网关就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换，访问统计等问题的。

      API网关的流行，源于近几年来移动应用与企业间互联需求的兴起。移动应用企业互联，使得后台服务支持的对象从以前单一的Web应用扩展到多种使用场景，且每种便用场暴对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量，还增加了后台服务的复杂性。随着微服务架构概念的提出，API网关成为了微服务架构的一个标配组件。

      API网关是一个服务器，是系统对外的唯一入口。 API 网关封装了系统内部架构，为每个客户端提供定制的API，所有的客户端和消费端部通过统一的网关接入微服务，在网关层处理所有非业务功能。API 网关并不是微服务场景中必须的组件，如下图，不管有没有API网关，后端微服务都可以通过API很好地支持着户端的访问。

2、服务网关的作用是什么？

如果让客户端直接与各个微服务交互：

• 客户端会多次请求不同的微服务，增加了客户端的复杂性
• 存在跨域清求，在一定场景下处理相对复杂
• 身份认证问题，每个微服务需要独立身份认证
• 难以重构，随着项目的迭代，可能需要重新划分微服务
• 某些微服务可能使用了防火墙/浏览器不发好的协议，直接访问会有一定的图难

二、Gateway实现服务网关

1、概念

2、原理

如上图所示，客户端向Spring Cloud Gateway 发出请求，由网关处理程序Gateway Handler Mapping 映射确定与请求相匹配的路由，将其发送到网关web处理程序Gateway web Handler，该处理程序通过指定的过滤器链将请求发送到我们实际的服务执行业务逻辑，然后返回。过滤器由虚线分隔的原因是过滤器可以在发送代理请求之前和之后运行逻辑，所有pre过滤器逻辑均被执行，然后发出代理请求。发出代理请求后，将运行post 过滤器逻辑。

3、路由规则（动态路由）

（1）动态获取uri

以Path为例，输入http://172.16.26.83:9001/product/list，符合path的路由规则会跳转到注册中心的service-provider-product的服务地址。

（2）服务名称转发

以Path为例，输入http://172.16.26.83:9001/service-provider-product/product/list，符合path的路由规则会跳转到注册中心的service-provider-product的服务地址。

 4、Filter 的使用

Spring Cloud Gateway有“pre”和“post”两种方式的filter。客户端的请求先经过“pre”类型的filter，然后将请求转发到具体的业务服务，比如下图中的user-service，收到业务服务的响应之后，再经过“post”类型的filter处理，最后返回响应到客户端。

在Spring Cloud Gateway中，filter从作用范围可分为另外两种，一种是针对于单个路由的GatewayFilter，它在配置文件中的写法同predict类似；另外一种是针对于所有路由的GlobalFiler。现在从作用范围划分的维度来讲解这两种filter。

（1）网关过滤器GatewayFilter

需要通过spring.cloud.routes.filters配置在具体路由下，只作用在当前路由上或者通过spring.cloud.default-filters配置在全局，作用于所有路由上。

以Path路径过滤器为例，输入http://172.16.26.83:9001/gateway/product/list，由于不存在gateway这个路径，所以要配置过滤器，将其重写为 http://172.16.26.83:9001/product/list。

  （2）全局过滤器GlobalFiler

不需要在配置文件中配置，作用在所有路由上，最终通过GatewayFilterAdapter包装成GatewayFilterChain可识别的过滤器，它为请求业务以及路由的url转换为真实业务服务请求地址的核心过滤器，不需要配置系统初始化时加载，并作用在每个路由上。

5、网关限流

限流就是限制流量，通过限流，可以很好地控制系统的QRS，从而达到保护系统的目的。对于web服务、对外api这种类型的服务有以下几种可能导致机器被拖垮：

• 用户增长过快
• 热点事件（微博热搜）
• 竞争对象爬虫
• 恶意请求

常见的限流算法有：

（1）计数器算法

计数器算法是最简单的限流算法。比如规定，对于A接口来说，1分钟的访问次数不能超过100。那么可以这么做：在一开始的时候，设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个请求的间隔时间还在1分钟之内，触发限流；如果该请求与第一个请求的间隔时间大于1分钟，重置counter重新计数，具体算法的示意图如下：

（2）漏桶（Leaky Bucket）算法

漏桶算法就是注水漏水的过程，往桶中以任意速度流入水，以一定速度流出水，当水超过桶流量就丢弃，因为桶的容量是不变的，保证了整体的速度。漏桶算法是使用队列机制实现的。

（3）令牌桶（Token Bucket）算法

令牌桶算法是对漏桶算法的一种改进，漏桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌，才有机会继续执行，否则选择选择等待可用的令牌，或者直接拒绝。放令牌这个动作是持续不断的进行，如果桶中令牌数达到上限，就丢弃令牌。

 场景大概是这样的：桶中一直有大量的可用令牌，这时进来的请求可以直接拿到令牌执行，比如设置QPS为100/s，那么限流器初始化完成一秒后，桶中就已经有100个令牌了，等服务启动完成对外提供服务时，该限流器可以抵挡瞬时的100个请求。当桶中没有令牌时，请求会进行等待，最后相当于以一定的速率执行。

Spring Cloud Gateway内部使用的就是该算法。大慨描述如下:

• 所有的请求在处理之前都需要拿到一个可用的令牌才会被处理；
• 根据限流大小，设置按照一定的速率往桶里添加令牌；
• 桶设置最大的放置令牌限制，当桶满时、新添加的令牌就被丢弃或者拒绝；
• 请求到达后首先要获取令牌桶中的令牌，拿著令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除；
• 令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流。