springcloud有哪些组件,「SpringCloud原理」Ribbon核心组件以及运行原理万字源码剖析

springcloud有哪些组件,「SpringCloud原理」Ribbon核心组件以及运行原理万字源码剖析详细介绍

本文目录一览： Spring Cloud 常用组件梳理

业务场景:

创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付”

扣减相应的商品库存

通知仓储中心，进行发货

给用户的这次购物增加相应的积分

针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下：

用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态

订单服务调用库存服务，完成相应功能

订单服务调用仓储服务，完成相应功能

订单服务调用积分服务，完成相应功能

至此，整个支付订单的业务流程结束

一、Spring cloud组件

1、Spring Cloud核心组件：Eureka 注册中心

2、Spring Cloud核心组件：Feign ?调用

3、Spring Cloud核心组件：Ribbon 负载均衡

4、Spring Cloud核心组件：Hystrix 熔断器 错误降级 防止雪崩

5、Spring Cloud核心组件：Zuul 网关 各端请求 统一处理

你所理解的SpringCloud是什么？

1、SpringCloud是Pivotal提供的用于简化分布式系统构建的工具集。SpringCloud引入了云平台连接器（CloudConnector）和服务连接器（ServiceConnector）的概念。
2、SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。
3、SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。
4、SpringCloud是一系列框架的有序集合（框架集），他利用SpringBoot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
5、SpringCloud是基于SpringBoot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。

SpringCloud Alibaba组件

一.组件组成
二. 各个组件的介绍
2.1. Gateway
GateWay是在spring生态系统上构建的API网关服务,它是基于springboot2,spring5,和project Reactor等技术
2.1.2 作用:
2.1.3优势 性能方面比zuul要好,因为gateway是基于webFlux框架实现(底层是Reactor模式的netty)
2.1.4 特点
2.1.5 为什么选择gateway?
3.三大核心概念 路由: 是构建网关的基本模块,他由id,目标url,一系列的断言和过滤器组成,如果断言为true则匹配该路由. 断言: 过滤: 过滤请求用的
4.工作流程 路由转发+ 过滤器链
二: config 分布式配置中心 1. 产生背景: 微服务项目中会根据业务来拆分成一个个子服务,而每个服务都会有自己的配置文件为了统一管理,所以configserver应运而生了. 2.概念: springcloud config 为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为 各个不同的微服务 应用的所有环境提供一个 中心化的外部配置 .
3.作用: 1. 为了集中式和动态的管理配置信息 2.运行期间动态调整配置不在需要在每个服务器上部署的机器上编写配置文件,服务会向配置中心统一拉取配置信息 3.动态加载配置信息,服务不用重启就可以感知配置的变化并应用配置 4.把配置信息以rs风格接口的形式暴露(post或curl命令) ps: 其实就相当于项目里的公共模块,一个意思
那我们如何使用它呢? 一. 首先config分为客户端和服务端. 二. 服务端其实就是我们常说的 分布式配置中心 ,它是一个独立的微服务应用, 可以用来连接配置服务器并为客户端提供获取配置信息,加密,解密信息等接口. 三. 而客户端是通过指定的配置中心来管理应用资源,这样有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理来访问配置内容. 四.分布式配置动态刷新问题 实现步骤: 1.pom里添加actuator监控 2.yml 暴露监控端点 3. 启动类上加 @RefreshScope 4.curl -X POST " http://ip:port/actuator/refresh "(每次修改后必须执行这个,否则客户端还是读取不到最新的配置信息) 五. 如果有多个客户端,难道每个微服务都要执行一次post命令? 可不可以只改一处,让其他的地方都生效 三. Bus 消息总线 1.概念 springcloud Bus 是用来将分布式系统的节点与轻量级消息系统链接起来的框架,它整合了java的时间处理机制和消息中间件的功能
五. Nacos 1. 概念 nacos是一个更易于构建云原生应用的动态服务发现, 配置管理和服务管理平台. 2. 各个配置中心对比
六 . Sentinel 1.概念 把流量作为切入点,从流量控制,熔断降级,系统负载保护等多个维度保护服务的稳定性. 七. Seata 1. 概念 阿里巴巴开源产品,一个易于使用的高性能微服务分布式事务解决方案.

SpringCloud微服务组件介绍

Spring Cloud是一系列框架的有序集合（框架集），他利用Spring Boot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
SpringCloud利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等，它们都可以用SpringBoot的开发风格做到一键启动和部署。
SpringCloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包
下面是Spring Cloud的整体架构图：
注册中心可以说是微服务架构中的“通讯录”，他记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其他服务时，就在这里找到对应服务的地址，进行调用。
注册中心的主要作用
Ribbon是Netflix发布的一个负载均衡，有助于控制HTTP和TCP客户端行为。在Spring Cloud中，Eureka一般配合Ribbon进行使用，Ribbon提供了客户端负载均衡的功能，Ribbon利用从Eureka中读取到的服务信息，在调用服务节点提供的服务时，会合理的进行负载。
在Spring Cloud中可以将注册中心和Ribbon配合使用，Ribbon自动的从注册中心中获取服务提供者的列表信息，并基于内置的负载均衡算法，请求服务。
Ribbon原理
几种负载均衡策略：
Hystrix是Netflix开源的一款容错框架，包含常用的容错方法。在高并发访问下，系统所依赖的服务的稳定性对系统的影响非常大，依赖有很多不可控的因素，比如网络连接变慢，资源突然繁忙，暂时不可用，服务脱机等。Hystrix利用熔断、线程池隔离、信号量隔离、降级回退等方法来处理依赖隔离，使系统变得高可用。
Hystrix主要提供了以下几种容错方法：
Spring Cloud Gateway是Spring官方推出的服务网关的实现框架，相对于服务网关的概念有点类似于传统的反向代理服务器（如nginx），但反向代理一般都只是做业务无关的转发请求，而服务网关与服务的整合程度更高，可以看作也是整个服务体系的组成部分，通过过滤器等组件可以在网关中集成一些业务处理的操作（比如权限认证等）。
核心功能：
Spring Cloud Stream是一个用来为微服务应用构建消息驱动能力的框架。
特点： 屏蔽底层 MQ 实现细节，Spring Cloud Stream 的 API 是统一的。如果从 Kafka 切到 RocketMQ，可以直接修改配置。 与 Spring 生态整合更加方便。Spring Cloud Data Flow的流计算都是基于 Spring Cloud Stream；Spring Cloud Bus 消息总线内部也是用的 Spring Cloud Stream。
配置中心功能：
分布式链路追踪，就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时，请求具体到达哪台机器上、每个服务节点的请求状态等等。
分布式链路追踪方案：

18.SpringCloud有哪些组件？

SpringCloud的组件非常繁杂
SpringCloud的组件非常繁杂，拥有相当多的子项目，包括为人熟知的阿里开源的生态也融入其中，称之为SpringCloudAlibaba；
在SpringCloud中，最为人熟知的当属SpringCloud Netflix了，它是由Netflix公司开源的，主要涵盖Eureka，Hystrix，Zuul，Ribbon等组件~
除了SpringCloudNetflix，还有Spring开发团队自研的，比如Feign、Config，Gateway，Bus~
不过，最近1年，Netflix宣布要将自家技术闭源，不过不用担心，国产的微服务技术栈已经崛起，阿里的Nacos，Sentinel，Dubbo~有逐步替代之势，由于SpringCloud的背后支撑，微服务技能栈，互相彼此切换非常容易；
如果你想掌握时下热门微服务技术栈，跟上时代技术步伐，欢迎关注黑马程序员

「SpringCloud原理」Ribbon核心组件以及运行原理万字源码剖析

大家好，本文我将继续来剖析SpringCloud中负载均衡组件Ribbon的源码。本来我是打算接着OpenFeign动态代理生成文章直接讲Feign是如何整合Ribbon的，但是文章写了一半发现，如果不把Ribbon好好讲清楚，那么有些Ribbon的细节理解起来就很困难，所以我还是打算单独写一篇文章来剖析Ribbon的源码，这样在讲Feign整合Ribbon的时候，我就不再赘述这些细节了。好了，话不多说，直接进入主题。

这是个很简单的东西，就是服务实例数据的封装，里面封装了服务实例的ip和端口之类的，一个服务有很多台机器，那就有很多个Server对象。

ServerList是个接口，泛型是Server，提供了两个方法，都是获取服务实例列表的，这两个方法其实在很多实现类中实现是一样的，没什么区别。这个接口很重要，因为这个接口就是Ribbon获取服务数据的来源接口，Ribbon进行负载均衡的服务列表就是通过这个接口来的，那么可以想一想是不是只要实现这个接口就可以给Ribbon提供服务数据了？事实的确如此，在SpringCloud中，eureka、nacos等注册中心都实现了这个接口，都将注册中心的服务实例数据提供给Ribbon，供Ribbon来进行负载均衡。

通过名字也可以知道，是用来更新服务注册表的数据，他有唯一的实现，就是PollingServerListUpdater，这个类有一个核心的方法，就是start，我们来看一下start的实现。

通过这段方法我们可以看出，首先通过isActive.compareAndSet(false, true)来保证这个方法只会被调用一下，然后封装了一个Runnable，这个Runnable干了一件核心的事，就是调用传入的updateAction的doUpdate方法，然后将Runnable扔到了带定时调度功能的线程池，经过initialDelayMs（默认1s）时间后，会调用一次，之后都是每隔refreshIntervalMs（默认30s）调用一次Runnable的run方法，也就是调用updateAction的doUpdate方法。

所以这个类的核心作用就是每隔30s会调用一次传入的updateAction的doUpdate方法的实现，记住这个结论。

IRule是负责负载均衡的算法的，也就是真正实现负载均衡获取一个服务实例就是这个接口的实现。比如说实现类RandomRule，就是从一堆服务实例中随机选取一个服务实例。

就是一个配置接口，有个默认的实现DefaultClientConfigImpl，通过这个可以获取到一些配置Ribbon的一些配置。

这个接口的作用，对外主要提供了获取服务实例列表和选择服务实例的功能。虽然对外主要提供获取服务的功能，但是在实现的时候，主要是用来协调上面提到的各个核心组件的，使得他们能够协调工作，从而实现对外提供获取服务实例的功能。

这个接口的实现有好几个实现类，但是我讲两个比较重要的。

BaseLoadBalancer

核心属性

allServerList：缓存了所有的服务实例数据

upServerList：缓存了能够使用的服务实例数据。

rule：负载均衡算法组件，默认是RoundRobinRule

核心方法

setRule：这个方法是设置负载均衡算法的，并将当前这个ILoadBalancer对象设置给IRule，从这可以得出一个结论，IRule进行负载均衡的服务实例列表是通过ILoadBalancer获取的，也就是 IRule 和 ILoadBalancer相互引用。setRule(rule)一般是在构造对象的时候会调用。

chooseServer：就是选择一个服务实例，是委派给IRule的choose方法来实现服务实例的选择。

BaseLoadBalancer这个实现类总体来说，已经实现了ILoadBalancer的功能的，所以这个已经基本满足使用了。

说完BaseLoadBalancer这个实现类，接下来说一下DynamicServerListLoadBalancer实现类。DynamicServerListLoadBalancer继承自BaseLoadBalancer，DynamicServerListLoadBalancer主要是对BaseLoadBalancer功能进行扩展。

DynamicServerListLoadBalancer

成员变量

serverListImpl：上面说过，通过这个接口获取服务列表

filter:起到过滤的作用，一般不care

updateAction：是个匿名内部类，实现了doUpdate方法，会调用updateListOfServers方法

serverListUpdater：上面说到过，默认就是唯一的实现类PollingServerListUpdater，也就是每个30s就会调用传入的updateAction的doUpdate方法。

这不是巧了么，serverListUpdater的start方法需要一个updateAction，刚刚好成员变量有个updateAction的匿名内部类的实现，所以serverListUpdater的start方法传入的updateAction的实现其实就是这个匿名内部类。

那么哪里调用了serverListUpdater的start方法传入了updateAction呢？是在构造的时候调用的，具体的调用链路是调用 restOfInit -> enableAndInitLearnNewServersFeature()，这里就不贴源码了

所以，其实DynamicServerListLoadBalancer在构造完成之后，默认每隔30s中，就会调用updateAction的匿名内部类的doUpdate方法，从而会调用updateListOfServers。所以我们来看一看 updateListOfServers 方法干了什么。

这个方法实现很简单，就是通过调用 ServerList 的getUpdatedListOfServers获取到一批服务实例数据，然后过滤一下，最后调用updateAllServerList方法，进入updateAllServerList方法。

其实很简单，就是调用每个服务实例的setAlive方法，将isAliveFlag设置成true，然后调用setServersList。setServersList这个方法的主要作用是将服务实例更新到内部的缓存中，也就是上面提到的allServerList和upServerList，这里就不贴源码了。

其实分析完updateListOfServers方法之后，再结合上面源码的分析，我们可以清楚的得出一个结论，那就是默认每隔30s都会重新通过ServerList组件获取到服务实例数据，然后更新到BaseLoadBalancer缓存中，IRule的负载均衡所需的服务实例数据，就是这个内部缓存。

从DynamicServerListLoadBalancer的命名也可以看出，他相对于父类BaseLoadBalancer而言，提供了动态更新内部服务实例列表的功能。

为了便于大家记忆，我画一张图来描述这些组件的关系以及是如何运作的。

说完一些核心的组件，以及他们跟ILoadBalancer的关系之后，接下来就来分析一下，ILoadBalancer是在ribbon中是如何使用的。

ILoadBalancer是一个可以获取到服务实例数据的组件，那么服务实例跟什么有关，那么肯定是跟请求有关，所以在Ribbon中有这么一个抽象类，AbstractLoadBalancerAwareClient，这个是用来执行请求的，我们来看一下这个类的构造。

通过上面可以看出，在构造的时候需要传入一个ILoadBalancer。

AbstractLoadBalancerAwareClient中有一个方法executeWithLoadBalancer，这个是用来执行传入的请求，以负载均衡的方式。

这个方法构建了一个LoadBalancerCommand，随后调用了submit方法，传入了一个匿名内部类，这个匿名内部类中有这么一行代码很重要。

这行代码是根据给定的一个Server重构了URI，这是什么意思呢？举个例子，在OpenFeign那一篇文章我说过，会根据服务名拼接出类似 http:// ServerA 的地址，那时是没有服务器的ip地址的，只有服务名，假设请求的地址是 http:// ServerA/api/sayHello ，那么reconstructURIWithServer干的一件事就是将ServerA服务名替换成真正的服务所在的机器的ip和端口，假设ServerA所在的一台机器（Server里面封装了某台机器的ip和端口）是192.168.1.101:8088，那么重构后的地址就变成 http:// 192.168.1.101:8088/api/ sayHello ，这样就能发送http请求到ServerA服务所对应的一台服务器了。

之后根据新的地址，调用这个类中的execute方法来执行请求，execute方法是个抽象方法，也就是交给子类实现，子类就可以通过实现这个方法，来发送http请求，实现rpc调用。

那么这台Server是从获取的呢？其实猜猜也知道，肯定是通过ILoadBalancer获取的，因为submit方法比较长，这里我直接贴出submit方法中核心的一部分代码

就是通过selectServer来选择一个Server的，selectServer我就不翻源码了，其实最终还是调用ILoadBalancer的方法chooseServer方法来获取一个服务，之后就会调用上面的说的匿名内部类的方法，重构URI，然后再交由子类的execut方法来实现发送http请求。

所以，通过对AbstractLoadBalancerAwareClient的executeWithLoadBalancer方法，我们可以知道，这个抽象类的主要作用就是通过负载均衡算法，找到一个合适的Server，然后将你传入的请求路径 http:// ServerA/api/sayHello 重新构建成类似 http:// 192.168.1.101:8088/api/ sayHello 这样，之后调用子类实现的execut方法，来发送http请求，就是这么简单。

到这里其实Ribbon核心组件和执行原理我就已经说的差不多了，再来画一张图总结一下

说完了Ribbon的一些核心组件和执行原理之后，我们再来看一下在SpringCloud环境下，这些组件到底是用的哪些实现，毕竟有写时接口，有的是抽象类。

Ribbon的自动装配类：RibbonAutoConfiguration，我拎出了核心的源码

RibbonAutoConfiguration配置类上有个@RibbonClients注解，接下来讲解一下这个注解的作用

SpringClientFactory是不是感觉跟OpenFeign中的FeignContext很像，其实两个的作用是一样的，SpringClientFactory也继承了NamedContextFactory，实现了配置隔离，同时也在构造方法中传入了每个容器默认的配置类RibbonClientConfiguration。至于什么是配置隔离，我在OpenFeign那篇文章说过，不清楚的小伙伴可以后台回复feign01即可获得文章链接。

配置优先级问题

优先级最低的就是FeignContext和SpringClientFactory构造时传入的配置类

至于优先级怎么来的，其实是在NamedContextFactory中createContext方法中构建AnnotationConfigApplicationContext时按照配置的优先级一个一个传进去的。

RibbonClientConfiguration提供的默认的bean

接下来我们看一下RibbonClientConfiguration都提供了哪些默认的bean

配置类对应的bean，这里设置了ConnectTimeout和ReadTimeout都是1s中。

IRule，默认是ZoneAvoidanceRule，这个Rule带有过滤的功能，过滤哪些不可用的分区的服务（这个过滤可以不用care），过滤成功之后，继续采用线性轮询的方式从过滤结果中选择一个出来。至于这个propertiesFactory，可以不用管，这个是默认读配置文件的中的配置，一般不设置，后面看到都不用care。

至于为什么容器选择NacosServerList而不是ConfigurationBasedServerList，主要是因为NacosRibbonClientConfiguration这个配置类是通过@RibbonClients导入的，也就是比SpringClientFactory导入的RibbonClientConfiguration配置类优先级高。

ServerListUpdater，就是我们剖析的PollingServerListUpdater，默认30s更新一次BaseLoadBalancer内部服务的缓存。

那么在springcloud中，上图就可以加上注册中心。

三、总结

本文剖析了Ribbon这个负载均衡组件中的一些核心组件的源码，并且将这些组件之间的关系一一描述清楚，同时也剖析了在发送请求的时候是如何通过ILoadBalancer获取到一个服务实例，重构URI的过程。希望本篇文章能够让你知道Ribbon是如何工作的。

关于Spring Cloud Alibaba，看这篇文章就够了！（附教程资料）

首先我们需要了解一下Spring Cloud，然后再来了解Spring Cloud Alibaba；
源自官方描述：
Spring Cloud为开发人员提供了一些工具用来快速构建分布式系统中的一些常见模式和解决一些常见问题（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、群集状态）。分布式系统的协调导致了很多样板式的代码（很多固定套路的代码），使用Spring Cloud开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很好地运行，包括开发人员自己的笔记本电脑、裸机数据中心和云计算等托管平台；
Spring Cloud为分布式系统开发的典型应用场景提供良好的开箱即用的功能:
Spring Cloud Alibaba是Spring Cloud下的一个子项目，Spring Cloud Alibaba为分布式应用程序开发提供了一站式解决方案，它包含开发分布式应用程序所需的所有组件，使您可以轻松地使用Spring Cloud开发应用程序，使用Spring Cloud Alibaba，您只需要添加一些注解和少量配置即可将Spring Cloud应用程序连接到Alibaba的分布式解决方案，并使用Alibaba中间件构建分布式应用程序系统；
Spring Cloud Alibaba 是阿里巴巴开源中间件跟 Spring Cloud 体系的融合:
动力节点的Spring Cloud Alibaba学习教程，将带你深入掌握基于Spring Cloud Alibaba技术栈的微服务开发技术，包括nacos、sentinel、seata、gateway、skywalking等，培养独立进行企业微服务项目架构的能力;
Spring Cloud Alibaba视频教程
https://www.bilibili.com/video/BV1nK4y
Spring Cloud Alibaba资料下载
http://www.bjpowernode.com/?toutiao
?001.视频导读
?002.Spring家族产品梳理
?003.What is Spring-Cloud-Alibaba？
?004.Nacos运行环境部署
?005.向Nacos注册中心注册服务
?006.从Nacos发现服务并负载均衡调用
?007.从Nacos发现服务并负载均衡调用
?008.Nacos客户端信息缓存
?009.Nacos客户端信息缓存
?010.Nacos Config配置中心启动读取外部配置
?011.Nacos Config配置中心自动刷新
?012.Nacos Config配置中心yaml配置
?013.Nacos Config配置中心多环境配置
?014.问答交流
?015.内容回顾-配置中心数据模型
?016.配置中心三层结构数据配置隔离
?017.配置中心三层结构数据配置隔离
?018.配置版本回滚-服务注册分组
?019.Nacos管控台用户权限管理
?020.Nacos数据持久化
?021.Nacos数据持久化
?022.Nacos集群环境部署
?023.Nacos集群环境测试
?024.Nacos集群统一入口Nginx
?025.快速回顾
?026.RestTemplate无参数Get调用返回String
?027.RestTemplate无参数Get调用返回User
?028.RestTemplate有参数Get调用返回User
?029.RestTemplate有参数Get调用返回User
?030.RestTemplate有参数Post调用返回User
?031.RestTemplate有参数Post调用返回User
?032.RestTemplate传输User对象参数Post调用返回User
?033.RestTemplate传输JSON参数Post调用返回User
?034.RestTemplate有参数Put调用
?035.RestTemplate有参数Delete调用
?036.RestTemplate方法调用梳理总结
?037.RestTemplate结合Ribbon实现负载均衡
?038.RestTemplate结合Ribbon实现负载均衡
?039.Ribbon负载均衡实现策略
?040.自定义Ribbon负载均衡实现策略
?041.更改Ribbon负载均衡实现策略
?042.Ribbon的核心接口组成
?043.Ribbon负载均衡策略个性化配置
?044.Ribbon结合Nacos实现权重负载均衡策略
?045.Ribbon结合Nacos负载均衡策优先调用同名集群
?046.Ribbon结合Nacos基于版本负载均衡策略
?047.Ribbon结合Nacos基于命名空间负载均衡策略
?048.What is Feign？
?049.Spring Cloud Alibaba基于Feign的远程调用
?050.Spring Cloud Alibaba基于Feign+Ribbon负载均衡远程调用
?051.Spring Cloud Alibaba基于Feign的相关配置
?052.脱离Ribbon的Feign的远程调用
?054.微服务的级联故障服务雪崩
?055.Spring Cloud Alibaba集成Sentinel
?056.Spring Cloud Alibaba基于Sentinel管理后台数据测试
?057.Spring Cloud Alibaba基于Sentinel实现限流
?058.Spring Cloud Alibaba基于Sentinel实现限流自定义返回结果
?059.Spring Cloud Alibaba基于Sentinel实现限流自定义跳转页面
?060.Spring Cloud Alibaba基于Sentinel线程数限流
?061.Spring Cloud Alibaba基于Sentinel资源关联限流
?062.Spring Cloud Alibaba基于Sentinel流控规则和流控效果
?063.问答交流
?064.快速回顾和演示环境预备
?065.Spring Cloud Alibaba Sentinel 服务降级RT
?066.Spring Cloud Alibaba Sentinel 服务降级异常比例和异常数
?067.Spring Cloud Alibaba Sentinel 热点参数规则
?068.Spring Cloud Alibaba Sentinel 热点参数规则小细节
?069.Spring Cloud Alibaba Sentinel 系统保护规则
?070.Spring Cloud Alibaba Sentinel 授权规则
?071.Spring Cloud Alibaba Sentinel Dashboard控制台通信原理
?072.Spring Cloud Alibaba Sentinel 对Controller请求url埋点
?073.Spring Cloud Alibaba Sentinel 手写代码实现埋点
?074.Spring Cloud Alibaba Sentinel 采用注解实现埋点
?075.Spring Cloud Alibaba Sentinel 对RestTemplate流控和熔断
?076.Spring Cloud Alibaba Sentinel 对Feign流控和熔断
?077.问答交流
?078.Sentinel规则持久化-拉模式持久化到本地文件
?079.Sentinel规则持久化-拉模式持久化到本地文件
?080.Sentinel规则持久化-推模式持久化到Nacos
?081.Sentinel规则持久化-推模式持久化到Nacos
?082.Spring Cloud Gateway 网关功能特性
?083.Spring Cloud Gateway 网关搭建
?084.Spring Cloud Gateway 网关服务调用
?085.Spring Cloud Gateway 网关谓词
?086.Spring Cloud Gateway 网关谓词
?087.Spring Cloud Gateway 网关谓词
?088.Spring Cloud Gateway 网关过滤器
?089.Spring Cloud Gateway 问答交流
?090.Spring Cloud Gateway自定义谓词
?091.Spring Cloud Gateway自定义谓词
?092.Spring Cloud Gateway自定义谓词不匹配404页面
?093.Spring Cloud Gateway自定义过滤器
?094.Spring Cloud Gateway全局过滤器
?095.Spring Cloud Gateway自定义全局过滤器
?096.Spring Cloud Gateway集成Ribbon实现负载均衡
?097.Spring Cloud Gateway集成Sentinel限流
?098.Spring Cloud Gateway集成Sentinel限流自定义错误页
?099.Spring Cloud Gateway集成Sentinel规则持久化到文件
?100.Spring Cloud Gateway集成Sentinel规则持久化到Nacos
?101.Spring Cloud Gateway内部执行流程源码分析
?102.Spring Cloud Gateway小结
?103.快速回顾
?104.Spring Cloud Gateway跨域CORS请求
?105.Spring Cloud Gateway跨域CORS请求
?106.What is SkyWalking？
?107.Skywalking运行环境部署
?108.SkyWalking Agent对微服务的链路追踪
?109.SkyWalking Agent对微服务链路追踪
?110.SkyWalking Agent加入IDEA中对微服务链路追踪
?111.SkyWalking 监控告警通知
?112.SkyWalking 监控告警通知
?113.SkyWalking 微服务链路追踪数据持久化MySQL
?114.SkyWalking 问答交流
?115.Skywalking持久化跟踪数据elasticsearch
?116.Skywalking持久化跟踪数据elasticsearch
?117.Skywalking对多个跨服务的链路跟踪
?118.Skywalking对多个跨服务的链路跟踪
?119.Skywalking自定义链路跟踪
?120.Skywalking集成logback输出traceId日志
?121.Skywalking UI界面-仪表盘
?122.Skywalking UI界面-拓扑图-追踪-性能剖析-告警
?123.Skywalking 基于nacos集群
?124.Skywalking 基于nacos集群
?125.Skywalking 基于nacos集群
?126.Skywalking 问答交流
?127.What is Seata？
?128.Seata分布式事务生命周期
?129.Seata TC Server运行环境部署
?130.Seata基于AT事务模式单体应用多数据源分布式事务
?131.Seata基于AT事务模式单体应用多数据源分布式事务
?132.Seata基于AT事务模式单体应用多数据源分布式事务
?133.Seata基于AT事务模式多个微服务分布式事务
?134.Seata基于AT事务模式多个微服务分布式事务
?135.Seata基于AT事务模式多个微服务分布式事务
?136.Seata基于AT事务模式执行机制
?137.Seata AT事务模式
?138.Seata AT事务模式写数据隔离
?139.Seata AT事务模式写数据隔离
?140.Seata AT事务模式读数据隔离
?141.Seata AT事务模式读数据隔离
?142.Seata TC Server集群环境部署
?143.Seata TC Server集群环境部署
?144.Seata TC Server集群环境集成测试
?145.Seata TC Server集群环境集成测试
?146.Seata TCC事务模式的运行机制
?147.Seata TCC事务模式SpringBoot单体应用案例
?148.Seata TCC事务模式SpringBoot单体应用案例
?149.Seata TCC事务模式SpringCloudAlibab微服务应用案例
?150.Seata TCC事务模式SpringCloudAlibab微服务应用案例
?151.What is Spring Cloud Stream
?152.Spring Cloud Stream的核心概念
?153.Spring Cloud Stream集成RocketMQ配置
?154.Spring Cloud Stream集成RocketMQ发送消息
?155.Spring Cloud Stream集成RocketMQ接收消息
?156.Spring Cloud Stream集成RocketMQ监听接收消息
?157.Spring Cloud Stream集成RocketMQ多种发送消息方式
?158.Spring Cloud Stream Starter代码分析
?159.Spring Cloud Stream集成RocketMQ发送事务消息
?160.Spring Cloud Stream集成RocketMQ对象标签消息
?161.Spring Cloud Stream问答交流

SpringCloud组件之Ribbon深入

在上一节 SpringCloud组件之Ribbon 中，实现了一个Ribbon的Helloword,使用的是Spring Eureka 和Spring Ribbon结合使用，并且使用Ribbon的默认轮询注册清单的负载均衡策略。
Ribbon参数配置通常有两种方式：全局配置和知道客户端配置
通用格式：ribbon.

=

key：表示参数名称 value：表示参数值 例如：全局配置Ribbon创建连接的超时时间

针对指定的服务进行配置 通用格式

.ribbon.

=

key：表示参数名称 value：表示参数值 client：表示客户端服务的名称 例如：我们调用的Rest请求时是 http://hello-service/hello/hello ，现在我们来为服务hello-service服务指定他的实例清单（和注册中心中的服务清单一样）

下面将单独使用Spring Ribbon组件来介绍几种Ribbon负载均衡策略，单独使用Ribbon组件，不结合Eureka组件的不同之处在于，不能根据服务名称自动从Eureka的注册中心获取一个服务的实例清单，必须手动在配置文件中添加服务实例清单。

RandomRule策略：该策略实现了从服务实例清单中 随机选择 一个服务实例，作为请求服务对象。

首先创建一个SpringBoot的服务。 pom.xml

application.yaml

LoadBalanceController类

LoadBalanceMain类

启动main，在浏览器中输入 http://localhost:8015/loadbalance/hello ，多次请求，可以看到页面呈现不同的请求路径。而且这些请求都是随机出现，查看后台打印

RoundRobinRule：该策略实现了按照 线性轮询 的方式一次轮询服务清单上的每个服务实例。

结合上面的例子，修改两个部分，一个是application.yaml中 NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule

一个是LoadBalanceMain 中 修改ribbonRule()的返回值

RetryRule：该策略具备重试机制的实例选择功能，在给定时间内能够得到选择到具体的服务实例就返回，当超过时间还有没选到就返回null，参数maxRetryMillis控制这个超时时间。

WeightedResponseTimeRule：该策略是对RoundRobinRule的扩展，增加了根据实例的响应时间来计算权重，并从权重中选择对应的实例。该策略实现主要有三个核心内容

定时任务

WeightedResponseTimeRule策略在初始化的时候会启动一个定时任务，默认每隔30秒计算一次每个服务实例的权重

权重计算 累计所有实例的响应时间，得到总的totalResponseTime，然后为实例清单中的每个实例逐个计算权重，计算公式为 weightSoFar = weightSoFar + totalResponseTime - 该实例的平均响应时间 weightSoFar 起始为零 例子 有A，B，C，D四个实例，他们的平均响应时间是10,40,80,100， 计算总的响应时间10+40+80+100 =230 计算各个实例的权重 A: 230-10=220 B:220+(230-40)=410 C:410+(230-80)=560 D:560+(230-100)=690; 计算各个实例的权重区间 A:[0,220] B:(220,410] C:(410,560] D:(560,690)

实例选择 WeightedResponseTimeRule策略会在[0,最大权重值)之间随机选取一个数，然后在看这个数落在哪个实例的权重区间内，接着WeightedResponseTimeRule就会去选择该实例。

ClientConfigEnableRoundRobinRule：该策略一般不直接使用，有些高级的策略会继承该类，完成一些高级的策略，ClientConfigEnableRoundRobinRule策略默认使用 RoundRibinRule的线性轮询机制

BestAvailableRule策略继承ClientConfigEnableRoundRobinRule，通过遍历负载均衡中维护的所有服务实例，会过滤掉故障实例，并找出并发数请求数最小的实例，所以该策略的特性就是选出最空闲的实例

PredicateBasedRule策略继承ClientConfigEnableRoundRobinRule，该策略主要特性是“先过滤，在轮询”，也就是先过滤掉一些实例，得到过滤后的实例清单，然后轮询该实例清单，PredicateBasedRule中“过滤”功能没有实现，需要继承它的类完成，也就是说不同继承PredicateBasedRule的类有不同的“过滤特性”

AvailabilityFilteringRule策略继承PredicateBasedRule策略的“先过滤，在轮询”特性， AvailabilityFilteringRule策略的过滤特性是 1：是否故障，即断路器是否生效已断开 2：实例的并发请求数大于阈值，默认2的32次方减一，该阈值可以通过

.

.ActiveConnectionsLimit来设置，只要满足其中一个那么就会过滤掉