1.使用Gateway作为SpringCloud网关
2.Spring Boot 项目配合Hystrix 实现全局RestController超时熔断（api超过30秒返回timeout)
3.Sentinel 是熔断熔断如何做限流的
4.Hystrix介绍
5.Elasticsearch 源码探究 ——故障探测和恢复机制

使用Gateway作为SpringCloud网关

       本着能用原生就用原生的原则，我们这里使用SpringGateway来作为云服务的源码网关

       配置

       从官网的介绍来看，spring网关拥有的代码功能有，路由（配置，熔断熔断过滤，源码重写等），代码自媒体整站源码熔断以及流量控制

       首先引入包

       动态路由

       路由的熔断熔断配置比较简单，有两种方法：使用配置文件和代码注入，源码我们这里简单展示下两种方法

       或者使用

       路由配置中id、代码uri、熔断熔断order、源码predicates.path/host没什么好说的代码，根据需求配置即可，熔断熔断filters相关参数，源码这里最好还是代码参考源码相关部分或者Spring Cloud Gateway比较全面，比如常用的前缀切割

       这里我们以常用的两种filter，流量控制和熔断降级举例

       流量控制

       通常我们需要限流来保证服务的可用性，保护一些不太稳定的服务不会因为高并发的请求而挂掉，这里我们一般在网关层做流量控制，减少实际进入的请求达到平波峰的目的

       计数器算法

       如果某个服务会在请求中数量达到时候挂掉，请求平均时间为2s，我们给一段时间一个请求量的限制，比如2秒次，每次请求进入就减少计数，每2s开始时重新计数，这样就能保证服务请求中数量在以内。但是对于抢购类接口，可能前ms请求数量就用完了，后面所有请求都被拒绝，即请求突刺现象，这样的用户体验是非常差的所以我们需要尽可能在所有的时间内保证接口的可用性（计数器算法就像DRAM中的集中式刷新一样不太能被接受），而且短时间内大量请求运行在相同代码段是非常危险的，在设计不好的hc05蓝牙源码情况很可能会出现数据库死锁等等问题

       漏桶算法

       我们需要让请求尽可能地能进行来，就需要平波峰填波谷，就上例而言，2s内最大请求为，也就是每个请求占用的时间比例为ms，我们设计一个容量为的桶（队列）每ms向接口发一个请求，可以让服务中请求数量不超过的情况下，每ms都能接受一个新的请求，这样就缓解了请求突刺现象。但是这里还有一个问题，对于抢购类接口，个容量可能ms就用完了，在第ms可能还会有个请求抢1个位置，个请求会被取消，这样也是相对来说不能被接受的

       令牌桶算法

       令牌桶算法就是目前spring cloud gateway采用的算法，这里采用的用户时间换用户失败的策略，假设我们认为用户的平均忍耐时间为8秒，接口超过8秒一些用户就要骂街了，减去实际执行的2秒，也就是说我们的可以利用6秒的时间容纳更多的请求。依上文而言每ms去调用这个端口，那么也就是说桶的设计可以更大，在桶里放上令牌，每个请求需要在桶里面拿到令牌才能调用，这里的桶容量就是6s/ms为个。但是我们的执行速度是不变的，也就是结果是，在请求多的情况下用户的执行时间在8秒左右，而在请求少的情况下执行速度在2s左右，这样就缓解了短时间内大量请求导致大量失败的问题了。这里比较重要的参数有两个，第一个是桶请求容量 defaultBurstCapacity，第二个是咪咕阅读android源码每秒执行的请求速度（也就是桶的填充速率）defaultReplenishRate

       在这个例子中defaultBurstCapacity=而defaultReplenishRate=，这两个参数我们会在下方配置

       这里我们需要引用redis包，再说明一下，本站使用的是jdk的版本，其他版本的配置和引用可能会稍有变化，需要调整

       覆写KeyResolver的实现类

       流量控制，这里同样有代码实现和配置文件实现，由于目前idea对于复杂配置文件的支持不太好，如果使用配置文件方式会疯狂报红，但是如果全部使用代码的话会不方便实现动态路由，因为gateway是先加载配置再处理代码的。所以这里我们路由使用配置，filter之类复杂的使用代码实现，下面是简单示例

       这样全服务层面的接口流量控制就完成了，具体的哪些服务使用流量控制，具体控制参数的配置，自行稍作修改即可

       测试流量控制的话，可以将令牌回复量和令牌总容量调至比较低的水平，然后再浏览器直接curl接口，比如令牌回复量和容量为1，则单秒内curl即可触发浏览器提示，线上大令牌容量测试能需要多线程curl了，这里参考官方文档给的lua脚本

       ip限流

       如果我们需要对某个ip进行限流，比如防止脚本抢货，我们这里需要KeyResolver的实现不再使用exchange.getRequest().getURI().getPath() ，而是使用 exchange.getRequest().getRemoteAddress() 。但是这里还有一个问题，我们请求是经过层层转发的，nginx，docker等，所以我们可能并不能拿到原始的请求地址，所以这里我们需要在最外层，比如nginx中将原始地址存到header或者cookie当中，绝密expma附图指标源码这里给出简单示例

       当然还有其他类似X-Forwarded-For的字段不再本文主要探讨范围就不多拓展了，在nginx中配置记录初始远程地址到header后，我们这里需要在程序中取出来，如果你这里使用的标准的X-Real-IP的字段去存储，那么只需要

       即可获取真实地址，如果你这里自定义了一个header的key那么需要在exchange.getRequest().getHeaders()里面自己找出来了

       最后我们这里给出对同一个接口同时配置两种限流的示例

       我在ip限流这里修改了返回的code由改为了，方便测试，这里我们将ip的限流参数设置为（2，2），将path的限流参数设置为（1，）然后不断请求接口就发现一开始返回错误，后续path令牌桶用完后返回错误，即设置成功

       补充

       如果这里你不希望返回，并且要求返回一个用户可读的带有json信息结果，那么比较好的业务处理方式是前端完成。如果是对外接口的话，那么我们这里就只能重写RateLimiter的实现了，不再使用RedisRateLimiter的类，而是自己去继承RateLimiter接口去实现，

       参考 SpringCloudGateway限流后，默认返回的改造：改跳转或增加响应body，这篇文章已经很详细，这里就不赘述了

       熔断降级

       熔断降级，即某个接口调用失败时使用其他接口代替，来保证整体服务对外的可用性

       首先需要引入熔断包

       circuitbreaker-reactor-resilience4j 熔断的相关配置分为两个部分，熔断逻辑本身的配置以及在集成到gateway中时候，网关的配置，熔断的重要的配置有，触发熔断的接口，代替接口，熔断超时时间（当然还有其他的，比如自定义熔断HttpStatus等等，异步发送消息源码rocketmq详细参数参考 Spring Cloud Circuit Breaker以及resilience4j官网）

       这里熔断触发接口和代替接口配置位于gateway中，这里我们使用代码实现，位置参考前述

       这里setName的目的是和熔断包中的配置产生对应关系，下方为熔断包的配置，这里定义默认超时时间（也就是没有匹配到name的超时时间）为s，your_breaker_id的超时时间为3s

       最后

       到这里网关的基本功能就差不多了，自定义的一些业务功能配置，比如header，cookie，以及调用方ip的处理逻辑等等其实都是在网关层处理的，可以参考 Spring Cloud Gateway WebFilter Factories以及Writing Custom Spring Cloud Gateway Filters，但是这种配置基本都没什么坑，这里就不谈了

       网关由于不经常作为业务逻辑被重构，所以网络上的资料相对比较少，我这里使用的又是最新的版本还是蛮多和前版本不一样的地方，尤其是webflux的一些东西，很多问题需要看源码才能解决，非常的消耗意志力。这里建议小伙伴们如果是业务使用的这种资料相对较少的架构，最好还是不要使用最新版本的比较好，毕竟万一遇到坑，踩个一两天是很正常的事情，而这种在业务场景可能就没那么容易接受了

Spring Boot 项目配合Hystrix 实现全局RestController超时熔断（api超过秒返回timeout)

       为了在Spring Boot项目中实现全局RestController的超时熔断，当API调用超过秒时返回timeout，我们需要寻找一种更高效的方法，避免手动为上百个控制器添加@HystrixCommand注解，这将是一项繁重的任务。起初，我尝试使用切面编程（AspectJ）包裹RestController，配置@HystrixCommand，但这似乎与HystrixCommand的特性产生了冲突。通过深入Hystrix源码分析和实例化HystrixCommand，我成功实现了全局的超时熔断策略，无需每个API都单独标注。

       实现的关键在于在pom文件中添加适当的Hystrix依赖，并确保返回值使用ResponseEntity以控制响应码。对于非ResponseEntity类型的返回值，通过优化处理，可以避免超时后返回的意外情况。这个过程虽然注解方式简洁，但控制不当可能引发问题。在遇到注解失效或效果不佳时，通过创建私有实例进行管理通常更易于调试和问题定位。

       Spring Boot的starter虽然提供了快速搭建项目的便利，但在精细化控制上可能面临挑战。因此，对于这类场景，注解的便利性和实例化管理的灵活性是需要权衡的。

Sentinel 是如何做限流的

       限流作为保障服务高可用的重要手段，在微服务架构中尤为重要，通过限制接口或资源访问，有效提升服务可用性和稳定性。对比传统的限流工具如Guava的RateLimiter，阿里提供的Sentinel在功能上更为丰富、强大。

       Guava的RateLimiter基于令牌桶算法，操作简单，但功能相对单一。相比之下，Sentinel作为阿里巴巴推出的一种限流、熔断中间件，不仅支持复杂规则的配置，还能提供集群范围内的限流功能，并将服务调用情况可视化，满足更广泛的使用场景。

       目前，Sentinel已在多个项目中得到应用，本文将深入剖析其限流机制，主要围绕限流的总体流程、源码解析、Context、Node、Entry等核心概念，以及责任链机制的实现过程，详细介绍Sentinel是如何通过责任链模式，结合滑动窗口算法，实现高效、灵活的限流功能。

       在Sentinel中，限流、熔断逻辑主要在SphU.entry方法中实现。该方法会在请求进入Sentinel时，对资源进行限流和熔断的逻辑处理。如果触发熔断或限流，会抛出BlockException，开发者可以自定义处理逻辑。对于业务异常，也有相应的fallback方法处理。

       限流流程如下：首先获取资源的Context，构建Node调用树，聚合相同资源不同Context的Node，然后进行资源调用统计和限流判断。限流机制基于滑动窗口算法，动态调整QPS限制，确保服务在高负载下依然稳定运行。

       在阅读源码过程中，我们首先关注了Context、Node、Entry等关键概念，理解它们在Sentinel中的角色和作用。Context封装了当前线程的调用链上下文信息，Node作为资源调用的统计包装，Entry则作为限流凭证，记录了资源的责任链和当前Context，实现资源调用链的构建和管理。

       责任链中的每个节点（如NodeSelectorSlot、ClusterBuilderSlot、StatisticSlot、FlowSlot等）都有特定的功能，如获取资源对应的Node、聚合相同资源不同Context的Node、资源调用统计、限流判断等。这些节点通过责任链模式紧密协作，共同完成限流逻辑的执行。

       在责任链的执行过程中，NodeSelectorSlot负责获取资源对应的Node，ClusterBuilderSlot聚合相同资源不同Context的Node，StatisticSlot负责资源调用的统计信息更新，而FlowSlot则根据Node的统计信息进行限流判断。这个过程不仅高效地实现了限流功能，还保证了系统的稳定性和性能。

       在责任链执行完毕后，无论请求是否成功或被限流，都会执行Entry.exit()方法，进行最终的收尾工作。至此，Sentinel的限流机制实现了从请求处理到资源调用统计，再到限流判断和执行，最后的收尾操作的完整流程。

       总体来看，Sentinel通过其丰富的功能、灵活的配置和高效的实现机制，在微服务架构中为限流提供了强有力的支持，不仅保障了服务的高可用性，还提升了系统的整体性能和稳定性。

Hystrix介绍

        对Hystrix耳闻已久，最近刚好想在项目中使用这个神器就顺带研究了一把，很多细节来不及深入研究只能把宏观上的各个概念讲解一下，这个介绍的素材大都来自github上的Hystrix官网。

         所谓一图胜千言，但凡能够用图片来表示而且能够表示清楚的，就不多用文字描述了，看图肯定比看文字要让人来的更爽一些。当然我还是非常建议去github上的Hystrix官方wiki去看原汁原味的文档，在参考文献部分已经给出了链接。

         最后提一点，就是在Hystrix的实现当中大量使用了RxJava的开源包的技术，这个技术之前没怎么研究过，所以后面的很多源码的分析更多侧重过程分析而不会深入细节，有兴趣的可以自己深入研究下，我就准备哪天得空好好去研究一下，毕竟RxJava这个东西号称是一个通过使用可观察序列来编写异步和基于事件的程序的库。

        hystrix的出现即为解决雪崩效应，它通过四个方面的机制来解决这个问题

        Hystrix的隔离主要是为每个依赖组件提供一个隔离的线程环境，提供两种模式的隔离：

        Hystrix的熔断器其实可以理解为就是一个统计中心，统计一定时间窗口内访问次数，成功次数，失败次数等数值判定是否发生熔断。发生电路熔断的过程如下：

       hystrix工作原理-英文版

        hystrix工作原理-中文版

        关于RxJava的详解

Elasticsearch 源码探究 ——故障探测和恢复机制

       Elasticsearch 故障探测及熔断机制的深入探讨

       在Elasticsearch的7..2版本中，节点间的故障探测及熔断机制是确保系统稳定运行的关键。故障监测主要聚焦于服务端如何应对不同场景，包括但不限于主节点和从节点的故障，以及数据节点的离线。

       在集群故障探测中，Elasticsearch通过leader check和follower check机制来监控节点状态。这两个检查通过名为same线程池的线程执行，该线程池具有特殊属性，即在调用者线程中执行任务，且用户无法直接访问。在配置中，Elasticsearch允许检查偶尔失败或超时，但只有在连续多次检查失败后才认为节点出现故障。

       选举认知涉及主节点的选举机制，当主节点出现故障时，会触发选举过程。通过分析相关选举配置，可以理解主节点与备节点之间的切换机制。

       分片主从切换在节点离线时自动执行，该过程涉及状态更新任务和特定线程池的执行。在完成路由变更后，master节点同步集群状态，实现主从分片切换，整个过程在资源良好的情况下基本为秒级。

       客户端重试机制在Java客户端中体现为轮询存活节点，确保所有节点均等机会处理请求，避免单点过载。当节点故障时，其加入黑名单，客户端在发送请求时会过滤出活跃节点进行选择。

       故障梳理部分包括主master挂掉、备master挂掉、单个datanode挂掉、活跃master节点和一个datanode同时挂掉、服务端熔断五种故障场景，以及故障恢复流程图。每种场景的处理时间、集群状态变化、对客户端的影响各有不同。

       最佳实践思考总结部分包括客户端和服务器端实践的复盘，旨在提供故障预防和快速恢复策略的建议。通过深入理解Elasticsearch的故障探测及熔断机制，可以优化系统设计，提高生产环境的稳定性。