的排序是在很前面的，按道理这种响应处理的类应该是在靠后才对，这里的设计比较巧妙。大家可以看到chain.filter(exchange).then()，意思就是执行到我的时候直接跳过下一个，等后面的过滤器都执行完后才执行这段逻辑。：从请求中获取body缓存到网关上下文，这样就可以直接从网关上下文中拿到请求参数，而不会出现从request中拿到之后还要回填到请求体的问题。：根据 lb:// 前缀过滤

综上所述，来总结下@RefreshScope 实现流程1.需要动态刷新的类标注@RefreshScope 注解2.@RefreshScope 注解标注了@Scope 注解，并默认了ScopedProxyMode.TARGET_CLASS;属性，此属性的功能就是在创建一个代理，在每次调用的时候都用它来调用GenericScope get 方法来获取对象。

相当于定义一个消费者，定义了消费者的一些属性实现接口来处理具体消费逻辑每个消费者初始化了一个对象，该对象中包含消费实例和消费者的属性服务启动的时候开启一个线程轮训队列中的消息，如果没有就一直阻塞，拿到消息后，最终会调用自己实现的onMessage方法。

Eureka保护方式：当在短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。默认模式是：客户端心跳上报Nacos实例健康状态，默认间隔5秒，Nacos在15秒内未收到该实例的心跳，则会设置为不健康状态，超过30秒则将实例删除。对于永久实例的的监看检查，Nacos 采用的是注册中心探测机

大体的意思就是说，事件的发布者发布事件，事件的监听这对对应的事件进行监听，当监听到对应的事件时，就会触发调用相关的方法。因此，在事件处理中，事件是核心，是事件发布者和事件监听者的桥梁。回顾前几节的内容，我们的路由配置是在服务启动之后通过各个渠道（配置文件、注册中心、缓存等）加载进来的，那么如果我们想要改变路由的配置，不得不重启服务，这样一来就十分麻烦，所以就引申出了。两种不同的方法，有兴趣的同学可