本文目录
- Spring cloud简介及Netflix组件介绍
- 「SpringCloud原理」Ribbon核心组件以及运行原理万字源码剖析
- 18.SpringCloud有哪些组件
- SpringCloud简介
- SpringCloud整体构架设计介绍
- SpringCloud Alibaba组件
- spring cloud有哪些组件
- Spring Cloud 常用组件梳理
- 微服务框架之Spring Cloud简介
- SpringCloudAlibaba(一)：概述与重要组件
Spring cloud简介及Netflix组件介绍
Spring Cloud是基于Spring Boot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。最重要的是，跟spring boot框架一起使用的话，会让你开发微服务架构的云服务非常好的方便。 Spring Cloud包含了非常多的子框架，其中，Spring Cloud Netflix是其中一套框架，由Netflix开发后来又并入Spring Cloud大家庭，它主要提供的模块包括：服务发现、断路器和监控、智能路由、客户端负载均衡等。 以下为Spring Cloud的核心功能： Spring Cloud Netflix组件介绍 Spring Cloud Netflix框架刚好就满足了上面的核心功能，而且最重要的是，使用起来非常的简单。Spring Cloud Netflix包含的组件及其主要功能大致如下： Eureka，服务注册和发现，它提供了一个服务注册中心、服务发现的客户端，还有一个方便的查看所有注册的服务的界面。 所有的服务使用Eureka的服务发现客户端来将自己注册到Eureka的服务器上。 Zuul，网关，所有的客户端请求通过这个网关访问后台的服务。他可以使用一定的路由配置来判断某一个URL由哪个服务来处理。并从Eureka获取注册的服务来转发请求。 Ribbon，即负载均衡，Zuul网关将一个请求发送给某一个服务的应用的时候，如果一个服务启动了多个实例，就会通过Ribbon来通过一定的负载均衡策略来发送给某一个服务实例。 Feign，服务客户端，服务之间如果需要相互访问，可以使用RestTemplate，也可以使用Feign客户端访问。它默认会使用Ribbon来实现负载均衡。 Hystrix，监控和熔断器。我们只需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。 Hystrix Dashboard，监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。 Turbine，监控聚合，使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。
「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是从获取的呢？其实猜猜也知道，肯定是通过ILoadBalancer获取的，因为submit方法比较长，这里我直接贴出submit方法中核心的一部分代码 ***隐藏网址*** ***隐藏网址*** 到这里其实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是如何工作的。
18.SpringCloud有哪些组件
SpringCloud的组件非常繁杂，拥有相当多的子项目，包括为人熟知的阿里开源的生态也融入其中，称之为SpringCloudAlibaba；在SpringCloud中，最为人熟知的当属SpringCloud Netflix了，它是由Netflix公司开源的，主要涵盖Eureka，Hystrix，Zuul，Ribbon等组件~除了SpringCloudNetflix，还有Spring开发团队自研的，比如Feign、Config，Gateway，Bus~不过，最近1年，Netflix宣布要将自家技术闭源，不过不用担心，国产的微服务技术栈已经崛起，阿里的Nacos，Sentinel，Dubbo~有逐步替代之势，由于SpringCloud的背后支撑，微服务技能栈，互相彼此切换非常容易；如果你想掌握时下热门微服务技术栈，跟上时代技术步伐，欢迎关注黑马程序员
SpringCloud简介
SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。 SpringCloud包含众多的子项目 SpringCloud config 分布式配置中心 SpringCloud netflix 核心组件： Eureka:服务治理 注册中心 Hystrix:服务保护框架 Ribbon:客户端负载均衡器 Feign：基于ribbon和hystrix的声明式服务调用组件 Zuul: 网关组件,提供智能路由、访问过滤等功能。 上海每特教育科技有限公司|苏州特每信息科技有限公司版权所有***隐藏网址***
SpringCloud整体构架设计介绍
SpringClound整体核心架构只有一点：Rest服务，也就是说在整个SpringCloud配置过程之中，所有的配置处理都是围绕着Rest完成的，在这个Rest处理之中，一定要有两个端：服务的提供者（Provider）、服务的消费者（Consumer）。SpringClound整体核心架构只有一点：Rest服务，也就是说在整个SpringCloud配置过程之中，所有的配置处理都是围绕着Rest完成的，在这个Rest处理之中，一定要有两个端：服务的提供者（Provider）、服务的消费者（Consumer），所以对于整个SpringCloud基础的结构就如下所示：既然SpringCloud的核心是Restful结构，那么如果要想更好的去使用Rest这些微服务还需要考虑如下几个问题。1、所有的微服务地址一定会非常的多，所以为了统一管理这些地址信息，也为了可以及时的告诉用户哪些服务不可用，所以应该准备一个分布式的注册中心，并且该注册中心应该支持有HA机制，为了高速并且方便进行所有服务的注册操作，在SpringCloud里面提供有一个Eureka的注册中心。对于整个的WEB端的构架（SpringBoot实现）可以轻松方便的进行WEB程序的编写，而后利用Nginx或Apache实现负载均衡处理，但是你WEB端出现了负载均衡，那么业务端呢？应该也提供有多个业务端进行负载均衡。那么这个时候就需要将所有需要参与到负载均衡的业务端在Eureka之中进行注册。在进行客户端使用Rest架构调用的时候，往往都需要一个调用地址，即使现在使用了Eureka作为注册中心，那么它也需要有一个明确的调用地址，可是所有的操作如果都利用调用地址的方式来处理，程序的开发者最方便应用的工具是接口，所以现在就希望可以将所有的Rest服务的内容以接口的方式出现调用，所以它又提供了一个Feign技术，利用此技术可以伪造接口实现。在进行整体的微架构设计的时候由于牵扯的问题还是属于RPC，所以必须考虑熔断处理机制，实际上所有的熔断就好比生活之中使用保险丝一样，有了保险丝在一些设备出现了故障之后依然可以保护家庭的电器可以正常使用，如果说现在有若干的微服务，并且这些微服务之间可以相互调用，例如A微服务调用了B微服务，B微服务调用了C微服务。如果在实际的项目设计过程之中没有处理好熔断机制，那么就会产生雪崩效应，所以为了防止这样的问题出现，SpringCloud里面提供有一个Hystrix熔断处理机制，以保证某一个微服务即使出现了问题之后依然可以正常使用。通过Zuul的代理用户只需要知道指定的路由的路径就可以访问指定的微服务的信息，这样更好的提现了java中的“key=value”的设计思想，而且所有的微服务通过zuul进行代理之后也更加合理的进行名称隐藏。、在SpringBoot学习的时候一直强调过一个问题：在SpringBoot里面强调的是一个“零配置”的概念，本质在于不需要配置任何的配置文件，但是事实上这一点并没有完全的实现，因为在整个在整体的实际里面，依然会提供有application.yml配置文件，那么如果在微服务的创建之中，那么一定会有成百上千个微服务的信息出现，于是这些配置文件的管理就成为了问题。例如：现在你突然有一天你的主机要进行机房的变更，所有的服务的IP地址都可能发生改变，这样对于程序的维护是非常不方便的，为了解决这样的问题，在SpringCloud设计的时候提供有一个SpringCloudConfig的程序组件，利用这个组件就可以直接基于GIT或者SVN来进行配置文件的管理。在整体设计上SpringCloud更好的实现了RPC的架构设计，而且使用Rest作为通讯的基础，这一点是他的成功之处，由于大量的使用了netflix公司的产品技术，所以这些技术也有可靠的保证。
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***隐藏网址*** 五. 如果有多个客户端,难道每个微服务都要执行一次post命令? 可不可以只改一处,让其他的地方都生效 三. Bus 消息总线 1.概念 springcloud Bus 是用来将分布式系统的节点与轻量级消息系统链接起来的框架,它整合了java的时间处理机制和消息中间件的功能
五. Nacos 1. 概念 nacos是一个更易于构建云原生应用的动态服务发现, 配置管理和服务管理平台. 2. 各个配置中心对比
六 . Sentinel 1.概念 把流量作为切入点,从流量控制,熔断降级,系统负载保护等多个维度保护服务的稳定性. 七. Seata 1. 概念 阿里巴巴开源产品,一个易于使用的高性能微服务分布式事务解决方案.
spring cloud有哪些组件
Spring MVC的组件主要包括：1. 前端控制器组件（DispatcherServlet）2. 处理器组件（Controller）3. 处理器映射器组件（HandlerMapping）4. 处理器适配器组件（HandlerAdapter）5. 拦截器组件（HandlerInterceptor）6. 视图解析器组件（ViewResolver）7. 视图组件（View）8. 数据转换组件（DataBinder）9. 消息转换器组件（HttpMessageConverter）
Spring Cloud 常用组件梳理
业务场景: 创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下： 用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态 订单服务调用库存服务，完成相应功能 订单服务调用仓储服务，完成相应功能 订单服务调用积分服务，完成相应功能 至此，整个支付订单的业务流程结束 一、Spring cloud组件 1、Spring Cloud核心组件：Eureka 注册中心 2、Spring Cloud核心组件：Feign 调用 3、Spring Cloud核心组件：Ribbon 负载均衡 4、Spring Cloud核心组件：Hystrix 熔断器 错误降级 防止雪崩 5、Spring Cloud核心组件：Zuul 网关 各端请求 统一处理
微服务框架之Spring Cloud简介
在了解 Spring Cloud 之前先了解一下微服务架构需要考量的核心关键点，如下图：
对于以上等核心关键点的处理，不需要我们重复造车轮， Spring Cloud 已经帮我们集成了，它使用 Spring Boot 风格将一些比较成熟的微服务框架组合起来，屏蔽掉了复杂的配置和实现原理，为快速构建微服务架构的应用提供了一套基础设施工具和开发支持。
Spring Cloud 所提供的核心功能包含：
Spring Cloud架构图
Spring Cloud子项目
Spring Cloud 旗下的子项目大致可以分为两类：
如下：
1. Spring Cloud 与 Spring Boot
Spring Boot 可以说是微服务架构的核心技术之一。通过在 Spring Boot 应用中添加 Spring MVC 依赖，就可以快速实现基于 REST 架构的服务接口，并且可以提供对 HTTP 标准动作的支持。而且 Spring Boot 默认提供 JackJson 序列化支持，可以让服务接口输入、输出支持 JSON 等。因此，当使用 Spring Cloud 进行微服务架构开发时，使用 Spring Boot 是一条必经之路。
2. Spring Cloud 与服务治理( Eureka )
服务治理是 Spring Cloud 的核心，在实现上其提供了两个选择，即 Consul 和 Netflix 的 Eureka 。
Eureka 提供了服务注册中心、服务发现客户端，以及注册服务的 UI 界面应用。
在 Eureka 的实现中，节点之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个节点存活，也可以正常地治理服务。即使所有服务注册节点都宕机， Eureka 客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。
3. Spring Cloud 与客户端负载均衡( Ribbon )
Ribbon 默认与 Eureak 进行无缝整合，当客户端启动的时候，从 Eureka 服务器中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时， Ribbon 就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。
Spring Cloud 通过集成 Netflix 的 Feign 项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认 Feign 项目集成了 Ribbon ，使得声明式调用也支持客户端负载均衡功能。
4. Spring Cloud 与微服务容错、降级( Hystrix )
为了给微服务架构提供更大的弹性，在 Spring Cloud 中，通过集成 Netflix 下子项目 Hystrix ，通过所提供的 @HystrixCommand 注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外， Hystrix 也默认集成到 Feign 子项目中。
Hystrix 是根据“断路器”模式而创建。当 Hystrix 监控到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（ fallback ），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。
而 Hystrix 的仪表盘项目（ Dashboard ）可以监控各个服务调用所消耗的时间、请求数、成功率等，通过这种近乎实时的监控和告警，可以及时发现系统中潜在问题并进行处理。
5. Spring Cloud 与服务网关( Zuul )
Spring Cloud 通过集成 Netflix 中的 Zuul 实现 API 服务网关功能，提供对请求的路由和过滤两个功能
路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。
过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。
通过 Zuul ，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个 API 接口，屏蔽了服务端的实现细节。通过 Zuul 的反向代理功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。此外， Zuul 默认会与 Eureka 服务器进行整合，自动从 Eureka 服务器中获取所有注册的服务并进行路由映射，实现 API 服务网关自动配置。
6. Spring Cloud 与消息中间件( Stream )
Spring Cloud 为简化基于消息的开发，提供了 Stream 子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与 Kafka 和 RabbitMQ 等消息中间件进行集成。
Spring Cloud Bus 基于 Stream 进行扩展，可以作为微服务之间的事件、消息总线，用于服务集群中状态变化的传播。
比如 Spring Cloud Config 借助 Bus ，可以实现配置的动态刷新处理。
7. Spring Cloud 与分布式配置中心( Config )
针对微服务架构下的配置文件管理需求， Spring Cloud 提供了一个 Config 子项目。 Spring Cloud Config 具有中心化、版本控制、支持动态更新和语言独立等特性。
在 Config 子项目中将微服务应用分为两种角色：配置服务器（ Config Server ）和配置客户端（ Config Client ）。使用配置服务器集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到 Git 、 SVN 等具有版本管理仓库中，也可以存放在文件系统中。默认采用 Git 的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。
8. Spring Cloud 与微服务链路追踪( Sleuth )
Spring Cloud 中的 Sleuth 子项目为开发者提供了微服务之间调用的链路追踪。
Sleuth 核心思想就是通过一个全局的 ID 将分布在各微服务服务节点上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。
因此，通过 Sleuth 可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。此外，通过将采集的数据发送给 Zipkin 进行存储、统计和分析，从而可以实现可视化的分析和展示，帮助开发者对微服务实施优化处理。
9. Spring Cloud 与微服务安全( Security )
Spring Cloud Security 为我们提供了一个认证和鉴权的安全框架，实现了资源授权、令牌管理等功能，同时结合 Zuul 可以将认证信息在微服务调用过程中直接传递，简化了我们进行安全管控的开发。
Spring Cloud Security 默认支持 OAuth 2.0 认证协议，因此单点登录也可以非常容易实现，并且 OAuth3.0 所生成的令牌可以使用 JWT 的方式，进一步简化了微服务中的安全管理。
10. Spring Cloud 的其他子项目
SpringCloudAlibaba(一)：概述与重要组件
前一篇提到了我们为什么要替换PHP语言采用Java语言。而Java语言的框架选型上来说有太多的选择，常见的有Dubbo，SpringCloud等。我们选择了SpringCloudAlibaba。替换PHP语言到SpringCloudAlibaba是个大工程，主要是业务迁移部分。讨论之初我也确认过是否迁移原有的业务，得到的明确答复是 迁移 。 那么这么来说也就简单了，复杂的就是工期问题了。
SpringCloud Alibaba是Alibaba结合自身的微服务实践开源的一套微服务全家桶 ，在SpringCloud项目中进行孵化并且毕业。既然是SpringCloud的项目那么阿里云其实包含其商业化的产品。 例如Nacos在阿里云就有其商业化的版本 MSE 。 同时SpringCloud Alibaba的相关组件是经历过双十一大促考验的产品。稳定性较高。
SpringCloud Alibaba是SpringCloud的子项目，其实很多相关的文章都提到了SpringCloud Alibaba与SpringCloud的关系，其中有很多的论点都比较有意思。大家可以去搜索一下。 SpringCloud Alibaba是依赖SpringCloud相关的标准实现的一套微服务的架构。结合阿里巴巴的相关实践与阿里云的相关服务实现的一些组件得以更快的实现相关产品业务。
***隐藏网址***
Sentinel是面向分布式微服务架构的轻量级高可用的流控组件，以流量作为切入点，从流量控制，熔断降级，系统负载保护等维度帮助用户保证服务的稳定性。常用与实现限流、熔断降级等策略。
RocketMQ基于Java的高性能、高吞吐量的消息队列，在SpringCloud Alibaba生态用于实现消息驱动的业务开发，常见的消息队列有Kafka、RocketMQ、RabbitMQ等，相关的比较文档可以自行去翻阅。
既然是微服务的产品，那么肯定会用到分布式事物。Seata就是阿里巴巴开源的一个高性能分布式事物的解决方案。
Dubbo已经在圈内很火了,SpringCloud Alibaba基于上面提到的Nacos服务注册中心也同样整合了Dubbo。
SpringCloud Alibaba还有一些其他的组件选择，例如schedulerX、SMS、OSS等。但是由于其主要是阿里云的商业化产品就不再过多的进行介绍。集成其商业化产品时才能用到。
SpringCloud Alibaba是基于SpringCloud标准由阿里巴巴实现的微服务全家桶，可插拔的方式实现组件的替换，在某些场景中我们需要的组件可以自由进行选择。例如需要分布式链路跟踪我们可以增加sleuth组件用于实现分布式链路跟踪业务等。 很多人提到SpringCloudAlibaba的商业问题，记得当年SpringCloudAlibaba推出第一版的时候我也评论了...卖产品全家桶。不可否认是有那么一些，但是其实它本身的很多组件又不一定非要选择商业版本。这个可以自由进行选择。
