微服务网关的优点：

  1. 安全，只有网关系统对外暴露，微服务隐藏在内网，通过防火墙保护
  2. 易于监控，可以在网关收集监控数据并将其推送到外部系统进行分析
  3. 易于认证。可以在网关上进行认证，然后再将请求转发到后端的微服务，而无须在每个微服务中进行认证。
  4. 减少了客户端与各个微服务之间的交互次数
  5. 易于统一授权。

为什么要用微服务网关

不同微服务一般有不同的网络地址，而外部客户端可能需要调用多个服务接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，可能会有以下问题：

  1. 客户端多次请求不同的微服务，增加了客户端的复杂性
  2. 存在跨域请求，一定场景下处理相对复杂
  3. 认证比较复杂，每个服务都需要独立认证
  4. 难以重构，如果每个微服务都面向客户端，如果以后有将一个服务拆分成几个服务或者将几个服务合成一个服务的需求的时候，重构将会比较困难

  5. 某些微服务如果用了防火墙/浏览器不友好的协议，直接访问会有困难。

    项目中微服务网关都做了什么：

  6. 路由过滤，做到对外只暴露网关微服务一个端口号

  7. 网关限流：因为所有请求都要先通过网关才能到微服务中，所以在网关限流就可以实现在微服务限流
    1. 项目中共有两层限流
      1. nginx网关，主要是针对大量请求的第一层抵御，有限流，但是限制的流量属于总流量比较大，这个经过限流的总流量如果都冲击到某个微服务还是比较大的。
      2. 第二层网关是用springcloud gateway实现的，是对于各个微服务请求的限流，这回限制的流量比较小，用来保护微服务，防止雪崩效应

  8. 拦截器鉴权：放开用户注册地址，其他地址都要拦截

    微服务网关限流算法

  9. 令牌桶算法：所有请求处理之前都需要拿到一个可用的令牌才能被处理，用令牌桶添加令牌的速度来限流。特点是一段时间内可以超并发，比如令牌发放速度是100个/s，桶容量是300，当桶内有剩余令牌的时候，可以满足每秒超过100的并发，桶内没有令牌则只能满足100/s的并发。

    1. 项目中做的是将令牌生成后存放到redis中，请求需要先获得redis的令牌才行（通过添加依赖，有固定的实现方式）
  10. 计数器算法：维护一个单位时间内得计数器。单位时间内，每次通过一个请求计数器+1，如果单位时间内计数器计数超过预先设定阈值，则在此刻到单位时间的最后一刻范围内的所有请求都被拒绝
  11. 漏桶算法：用一个请求队列来收集请求，用出队列的速度来限流，如果桶内队列满了，多余进来的请求将被舍弃。