NetflixԴ??

       大家好，我是栈长。

       今天给大家通报一则框架更新消息，时隔 .x 版本发布一年，Spring Cloud .0.0 最新版发布了，来看下最新的量控乾坤副图源码 Spring Cloud 版本情况：

       Spring Cloud 无疑是现在 Java 微服务事实上的标准，完全基于 Spring Boot 构建，依赖 Spring 生态体系，可以很好的与各种 Spring 生态项目无缝对接。

       Maven 依赖先给大家奉上：

       Spring Cloud 依赖管理采用的是 import 导入方式，里面管理了许多依赖，统一引入管理，使用时只需要引入对应依赖的坐标即可，不需要指定版本号。

       Spring Cloud 目前维护着 4 条版本主线：

       关于这些版本线的命名是不是很奇怪？

       另外，还有几天都要 年了，怎么现在才发布 版本？

       其实 Spring Cloud 最新的版本命名方式早已经变更了，以后就是YEAR.x 这种命名方式了，不清楚的可以看下栈长之前写的两篇文章：

       所以说，Spring Cloud .0.0 中的 是指 Spring Cloud .x 版本线，.0.0 则是指 这个版本线的第 1 个版本，而不是指某个年份发布的版本。

       新特性解读

       Spring Cloud .0.0 是一个大版本，更新了太多内容，栈长不打算全部解读，说几个有意思的更新吧。

       完整特性更新参考官方发布文档：

       1、系统环境

       Spring Cloud .0.0 基于以下环境进行构建：

       所以，这也是 Spring Cloud .0.0 的最低依赖要求，升级请小心。全球微赚源码

       2、模块升级

       3、Eureka 已经更新到 Eureka 2.0.0

       大家都知道 Eureka 2.x 早已经停止维护了，如该分支最新公告所示：

       github.com/Netflix/eure...

       虽然 Eureka 2.0.0 是 Eureka 的一个新分支，但这个分支与 7 年前的 2.x-archive 旧实验分支无关。

       创建 Eureka 2.x 新分支的目的是为了与 JakartaEE 兼容而已，让 Spring Cloud Netflix 可以兼容 Spring Framework 6.0 和 Spring Boot 3.0，仅此而已。

       4、Spring Cloud OpenFeign 功能完成公告

       由于 Spring 现在提供了自己的 HTTP 接口客户端解决方案，比如在最新的 Spring Boot 3.0 中实现接口调用可以有以下两种解决方案：

       所以，从 Spring Cloud .0.0 版本开始，Spring Cloud OpenFeign 模块已经视为功能完成状态了，这意味着 Spring Cloud 团队将不再向该模块添加新功能。

       虽然 OpenFeign 不会再添加新功能，但还是会继续修复错误和安全问题，并且也还会考虑和审查来自社区的小规模的 pull requests 请求。

       这是不是意味着，在不久的将来，OpenFeign 要退出历史舞台了？

       Spring Cloud 支持版本

       Spring Cloud 支持的版本情况，以及对应的 Spring Boot 版本如下表所示。

       需要注意的是： 正常维护中的版本中有 Spring Cloud + 了，其他的版本已经彻底结束生命周期了，官方不再提供维护支持了，非必要，尽量不要再使用了。

       目前最新的 Spring Cloud Alibaba .0.4.0 还是基于 Spring Cloud .0.4.0，尚未同步更新最新的 Spring Cloud .0.0 版本，这个在栈长的老blue引擎源码微服务课程中也有说明了，两者的版本不一定完全同步，也可能会跳过。

       总结

       Spring Cloud .0.0 是一个革命性的大版本，依赖的系统环境和模块都有大幅度的更新，特别是 JDK 、Spring 基础框架的最低要求，对于想升级的小伙伴来说无疑是一件难事，国内的应用也都还是以 JDK 8 为主，要迁移到 Spring Cloud 版本恐怕还需要不少的时日。

       Spring Boot 理论和实战源码仓库：

       github.com/javastacks/s...

       你们用的哪个 Spring Cloud 版本呢？欢迎留言分享～

       好了，今天的分享就到这里了，后面栈长我会更新更多好玩的 Java 技术文章和最新的技术资讯，关注Java技术栈第一时间推送，不要走开哦。

       版权声明： 本文系 "Java技术栈" 原创，原创实属不易，转载、引用本文内容请注明出处，抄袭者一律举报＋投诉，并保留追究其法律责任的权利。

Hystrix技术指南（7）故障切换的运作流程原理分析（含源码）

       目前对于一些非核心操作，如增减库存后保存操作日志发送异步消息时（具体业务流程），一旦出现MQ服务异常时，会导致接口响应超时，因此可以考虑对非核心操作引入服务降级、服务隔离。

       Hystrix说明

       Hystrix是Netflix开源的一个容灾框架，解决当外部依赖故障时拖垮业务系统、甚至引起雪崩的在线课程视频源码问题。

       为什么需要Hystrix?Hystrix设计理念

       想要知道如何使用，必须先明白其核心设计理念，Hystrix基于命令模式，通过UML图先直观的认识一下这一设计模式。

       Hystrix如何解决依赖隔离Hystrix流程结构解析

       流程说明:

       以下四种情况将触发getFallback调用：

       熔断器:Circuit Breaker

       每个熔断器默认维护个bucket，每秒一个bucket，每个bucket记录成功，失败,超时,拒绝的状态，默认错误超过%且秒内超过个请求进行中断短路。

       Hystrix隔离分析

       Hystrix隔离方式采用线程/信号的方式,通过隔离限制依赖的并发量和阻塞扩散.

       线程隔离实际案例：

       Netflix公司内部认为线程隔离开销足够小，不会造成重大的成本或性能的影响。Netflix 内部API 每天亿的HystrixCommand依赖请求使用线程隔，每个应用大约多个线程池，每个线程池大约5-个线程。

       信号隔离

       信号隔离也可以用于限制并发访问，防止阻塞扩散, 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程（该线程需要通过信号申请）,如果客户端是可信的且可以快速返回，可以使用信号隔离替换线程隔离,降低开销。 信号量的大小可以动态调整, 线程池大小不可以。

       线程隔离与信号隔离区别如下图:

       fallback故障切换降级机制

       有兴趣的小伙伴可以看看： 官方参考文档

       源码分析

       hystrix-core-1.5.-sources.jar!/com/netflix/hystrix/AbstractCommand.java

       executeCommandAndObserve

       使用Observable的onErrorResumeNext，里头调用了handleFallback，handleFallback中区分不同的异常来调用不同的fallback。

       applyHystrixSemanticsViaFallback方法

       hystrix-core-1.5.-sources.jar!/com/netflix/hystrix/AbstractCommand.java

       hystrix-core-1.5.-sources.jar!/com/netflix/hystrix/AbstractCommand.java

       针对每个commandKey获取或创建TryableSemaphoreActual

       fallback源码分析小结

       hystrix的fallback主要分为5种类型：

       获取以上资源请访问开源项目 点击跳转

spring cloud zuul 原理简介及使用

       Zuul是Netflix开源的一个API Gateway服务器，它本质上是一个Web Servlet应用，主要用于路由、过滤和增强微服务架构的API调用。

       其工作原理主要包括过滤器机制。Zuul通过定义四种标准过滤器类型，如路由（ROUTE）、前置（PRE）、定位附近约会源码后置（POST）和错误（ERROR），来管理请求的生命周期。内置的过滤器如StaticResponseFilter和SurgicalDebugFilter提供了特殊的功能，如静态响应和调试日志。同时，用户还可以自定义过滤器来定制特定的行为，如直接生成响应，无需转发到后端服务。

       Zuul的核心功能在于其动态过滤机制，通过在启动类上添加@EnableZuulProxy注解，能实现API网关的功能，如处理请求、路由规则配置、负载均衡、访问前缀设置等。例如，通过Eureka和Zuul的配合，可以自动配置路由，或者通过配置文件自定义路由规则。Ribbon和Hystrix的集成提供了内置的负载均衡和容错功能。

       实战中，你可以引入相关依赖，配置application.yml，启用Zuul的网关功能。通过操作如添加自定义过滤器、配置访问路径前缀，以及使用Spring Boot Actuator查看路由信息，深入了解Zuul的工作方式。相关源码和详细教程可以在gitee和微信公众号等平台找到。

ZookeeperApach Curator 框架源码分析：初始化过程（一）Ver 4.3.0

       Curator是由Netflix开源的一款用于简化Zookeeper客户端开发的工具，它提供了一套高级别API，使得开发者可以更简单易懂地实现分布式应用程序。Curator构建在Zookeeper原生客户端之上，提供了连接重试、异常处理、节点监听等常见功能，减轻了开发者的工作负担。Curator由多个模块组成，其中curator-framework和curator-recipes是最常用的部分，此外还提供了分布式锁等功能。

       Curator的最新版本为5.X系列，不再支持ZK 3.4.X及之前的版本。主要的改动在5.X系列中，原因包括代码重构、API调整等，导致不兼容之前的版本。

       Curator的下载地址可以通过Maven依赖管理或Apache官方网站获取。要开始使用Curator，需要搭建Zookeeper集群环境，详细部署过程可参考其他文章。

       引入Curator依赖后，开发者可以使用CuratorFrameworkFactory构建实例，通过此实例连接Zookeeper集群并执行分布式操作，如分布式锁等。Curator内部实现了重试策略、连接管理等，使得操作更为便捷且稳定。

       Curator提供了可重入锁（公平锁）的示例，开发者可以通过简单的代码实现分布式锁功能。初始化CuratorFramework实例的过程包括设置连接参数、构建实例、启动连接等步骤，内部会处理网络重连、异常处理等逻辑。

       在Curator的初始化过程中，CuratorFrameworkImpl是核心类，它负责构建与Zookeeper集群的连接，并封装了一系列关键组件，如连接管理、异常检测、负载均衡等。CuratorZookeeperClient类负责Zookeeper客户端的封装和调用。

       CuratorFrameworkImpl的启动过程涉及初始化连接状态管理器、启动客户端连接、执行后台操作等关键步骤。通过CAS操作确保线程安全，并在异常情况下自动重试连接。

       连接状态管理器（ConnectionStateManager）负责维护连接状态并处理状态变更通知，确保在状态改变时能够及时通知到监听器。通知机制包括注册一次性监听器、注册CuratorListener和ConnectionStateListener，以及处理未处理的错误。

       Curator的会话管理机制包括连接状态检查和重连策略，确保在连接断开后能够自动恢复连接。在状态变更时，连接状态管理器会通知所有注册的监听器，执行相应的回调逻辑。

       Curator还提供了缓存机制，用于保存节点数据并在数据发生变化时进行更新。此外，Curator支持多次注册监听器，确保在连接断开后能够重新注册监听器，以避免丢失监听事件。

       通过上述分析，Curator为开发者提供了高效、稳定的Zookeeper客户端实现，简化了分布式应用程序的开发过程。在实际应用中，开发者需要根据项目需求选择合适的版本和功能模块，以充分利用Curator提供的便利性。

netflix已经有了feign这个httpclient,为什么还要开发ribb

       Feign与Ribbon在设计上定位不同，Feign主打远程过程调用（RPC），虽然基于HTTP，但能屏蔽请求细节，用户只需声明接口，即可实现远程服务调用，无需关心HTTP请求细节或参数封装。而Ribbon则专注于负载均衡，RPC功能不是其强项，其主要优势在于从注册中心获取服务实例。二者互补，Feign无需Ribbon也能实现调用，只需指定服务IP和端口；Ribbon也无需Feign，但需实现HTTP请求参数封装。选择两者结合，源于解耦和单一职责原则。

       整合原理可参考相关文章。本文继续解析SpringCloud组件原理，重点剖析OpenFeign如何基于Ribbon实现负载均衡，以及二者如何协同工作。

       一、Feign动态代理调用实现RPC流程分析

       Feign客户端接口的动态代理生成基于JDK动态代理，通过FeignInvocationHandler实现方法调用。FeignInvocationHandler对invoke方法的实现避免了不需要RPC调用的方法（如equals、hashCode、toString）。通过dispatch获取要调用方法对应的MethodHandler，执行MethodHandler的invoke方法。MethodHandler在构建动态代理时生成，负责实现RPC调用。SynchronousMethodHandler处理RPC调用，其invoke方法构建RequestTemplate，封装HTTP请求参数。执行findOptions(argv)获取配置参数，使用重试组件，最后调用Client接口实现请求发送。

       二、LoadBalancerFeignClient

       Feign动态代理调用的关键在于Client，用于发送HTTP请求。通过分析可知，Feign客户端构建动态代理时，填充组件包括LoadBalancerFeignClient，实现Ribbon整合。FeignRibbonClientAutoConfiguration配置类导入相关组件并声明LoadBalancerFeignClient，注入Client实现、CachingSpringLoadBalancerFactory和SpringClientFactory，构建Feign.Builder的实现。

       LoadBalancerFeignClient实现整合过程，获取服务名，调用CachingSpringLoadBalancerFactory创建FeignLoadBalancer，实现负载均衡与请求发送。

       三、FeignLoadBalancer

       FeignLoadBalancer为核心组件，负责选择负载均衡并发送HTTP请求。执行executeWithLoadBalancer重构请求路径，调用execute方法，基于特定Client实现发送请求，最终返回RibbonResponse。

       四、总结

       本文全面解析了OpenFeign、Ribbon以及Nacos组件在微服务架构中的协同工作原理。OpenFeign实现RPC调用时，Ribbon从注册中心获取服务实例列表，实现负载均衡。Ribbon与Nacos（或其它注册中心）协同工作，确保服务发现和负载均衡的高效执行。通过本文，读者应能理解这三个组件在微服务架构中的作用，并对它们的源码有基本认识。