弹性措施

列出市面上常见的弹性框架，Sentinel、Hystrix、Resilience4j，最终选择Resilience4j

Sentinel：

整体较为庞大，配置相对复杂，与我网关的轻量理念不符

需要引入配置台和控制台，非Spring环境下引入成本大

Hystrix：

已停止维护，不适合用于新项目，Netfix官方推荐Resilience4j

Resilience4j：

轻量、模块化、lambda表达式编程、功能全面、使用简单、对环境没有要求，非Spring环境下也能很好继承

项目里的熔断用的是Resilience4j，为什么不选择Hystrix？

:::color4
这里可以吹一波

Hystrix熔断的问题：

默认机制是线程池代理，即有请求就有线程代理

hystrix是接口级别

一个接口一个线程池

用虚拟线程就可以解决这个问题

:::

熔断两种：

1.线程代理熔断

2.信号量，sentinel用的就是信号量，比较简单粗暴。但它只是一个开关，只能进或者不进或者知道进来多少。这时如果有一个请求的线程死循环了，也就只能让别的线程不要进来，但无法结束当前这个死循环的线程。而有了线程代理后就可以干很多事情了，只能说各有各的优缺点。如请求线程执行超过1s，浏览器已经timeout，但服务端的请求线程还没停，这时候最好的情况就是服务端你自个把自己给停了，但问题是你用信号量服务端怎么把自己给停了呢，这就是个问题，而线程代理就可以处理这个问题。还有一点，就是停请求一般停的是查询，写是不敢停的

大厂落地的时候不敢在网关上搞太多东西，因为出bug就gg了，一般不在api网关上熔断，虽然理论上可以

举例：

流量网关：nginx

api网关：vintage，api网关其实没啥神秘的，就是路由

rpc：motan

在api网关上做熔断的问题

1.单点故障

2.1个服务200个接口，就一个核心接口流量大。熔断颗粒度得做到接口

3.集群是变化的，得动态判断，比较费劲

熔断：挡流量。扛不住就减少请求呗

降级：是把一部分不重要的业务停了，活干不过来了，就不干不重要的

熔断起作用得看 熔断策略，一般两种，请求数量以及响应时间，请求数量及响应时间，如果是请求数量DDOS就会断，而响应时间得看接口性能

降级就是得有开关的，人来决定

限流