Spring Cloud面试题

什么是Spring Cloud

Spring Cloud是目前最常用的微服务开发框架（微服务的特点就是"模块化、功能化"，微服务架构的本质是将原来的整体项目划分成多个功能模块，每个功能模块都可以独立运行提供服务），它利用Spring Boot的开发便利性简化了分布式系统的开发，如服务发现注册、配置中心、智能路由、负载均衡、断路器等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud其实是一系列框架的有序集合，Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发框架。

为什么会出现微服务开发？

Spring Cloud是目前最常用的微服务开发框架，微服务的特点就是"模块化、功能化"，微服务架构的本质是将原来的整体项目划分成多个功能模块，每个功能模块都可以独立运行提供服务，随着业务逐渐发展，单体应用也会越来越复杂。这就会给应用带来很多问题

• 代码结构混乱，业务复杂，导致代码量很大，管理会越来越困难。
• 开发效率变低，开发人员同时开发一套代码，很难避免代码冲突。开发过程会伴随着不断解决冲突的过程，这会严重的影响开发效率；
• 排查解决问题成本高，线上业务发现 bug，修复 bug 的过程可能很简单。但是，由于只有一套代码，需要重新编译、打包、上线，成本很高
• 单体应用可能因为某个模块的故障导致整个系统瘫痪不可用

这些问题都在表明单体应用已经吃不消了，然后就有了微服务

上面问题的第三点解析

一旦出现了整个服务中的某一个模块需要升级改造，后果就是整个项目的所有服务停机，一般看到的就是"我们需要停机维护XXX的时间"，在这个期间，公司的服务器是停止向用户提供服务的，这对于用户体量很大，或者说国际化的公司来说是不能忍受的，因为停止服务就会出现客户流失的风险；除此之外还有很多其他的原因，比如可能我只需要这个项目中某一个模块的功能，但是为了正常运行我需要部署整个项目等

Spring Cloud设计目标与优缺点

设计目标

协调各个微服务，简化分布式系统开发。

优缺点

微服务的框架那么多比如：dubbo、Kubernetes，为什么就要使用Spring Cloud的呢？

优点

• 耦合度比较低。不会影响其他模块的开发。
• 可以并行开发，提高开发效率。
• 配置比较简单，基本用注解就能实现，不用使用过多的配置文件。
• 微服务跨平台的，可以用任何一种语言开发。
• 每个微服务可以有自己的独立的数据库也有用公共的数据库。
• 直接写后端的代码，不用关注前端怎么开发，直接写自己的后端代码即可，然后暴露接口，通过组件进行服务通信。

缺点

• 部署比较麻烦，给运维工程师带来一定的麻烦。
• 针对数据的管理比麻烦，因为微服务可以每个微服务使用一个数据库。
• 系统集成测试比较麻烦
• 性能的监控比较麻烦。【最好开发一个大屏监控系统】

总的来说优点大过于缺点，目前看来Spring Cloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习Spring Cloud是一个不错的选择。

Spring Cloud发展前景

Spring Cloud对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。同时， 随着近几年微服务架构和Docker容器概念的火爆，也会让Spring Cloud在未来越来越“云”化的软件开发风格中立有一席之地，尤其是在五花八门的分布式解决方案中提供了标准化的、全站式的技术方案，意义可能会堪比当年Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

Spring Cloud整体架构（子项目）

组件有服务治理（Eureka/哟睿渴）、配置中心（config）、动态刷新配置（bus）、服务调用（Feign/愤n）、服务容错（Hystrix/h亿4 s脆ks）、服务网关（Gateway）、负载均衡（Ribbon/睿苯）、链路追踪（Sleuth/s 路s）、消息驱动（Stream）

服务治理---Eureka

服务治理组件Eureka，包括服务端的注册中心和客户端的服务发现机制；在Spring Cloud的架构中，服务治理是其中不可或缺的核心环节，服务治理确保了调用方可以准确的向可用的服务节点发起调用。就是把各个微服务注册到Eureka上面，然后可以通过发现机制发现哪些微服务是可用的，哪些是不可用的，避免把请求发送到那些不可用的微服务上面

负载均衡---Ribbon

对于整个的WEB端的构架（SpringBoot实现）可以轻松方便的进行WEB程序的编写，而后利用Nginx或Apache实现负载均衡处理，但是你WEB端出现了负载均衡，那么业务端呢？可以用Ribbon来对多个业务端进行负载均衡

Ribbon是Spring Cloud中负责负载均衡的组件，具有多种负载均衡调用策略；Ribbon的一大优势是它能够和各个Spring Cloud组件无缝集成，而且十分灵巧轻便又具备高可扩展性。负载均衡框架是起到分散服务器压力的作用，可以这么说，没有负载均衡技术的服务器集群就不能叫做集群，只有借助负载均衡技术，集群才能够借助服务节点的规模效应发挥出优势。

服务调用---Feign

考虑到Spring Cloud的服务治理组件也是基于HTTP的，因此特别需要一款简化服务调用的组件。Feign的出现就是为了解决这个问题，我们可以借助Feign的代理机制，像调用一个接口方法一样发起远程HTTP调用。

服务容错---Hystrix

Hystrix是目前Spring Cloud中应用最广泛的服务容错组件，服务容错从宏观上来解释，就是尽可能降低服务异常所带来的影响。我们经常听到两个词叫做“降级”和“熔断”，降级很好理解，现在大家都会打趣的说“消费降级”，就是说降低咱自己的消费水平，在服务容错这里其实是一个道理，降级就是退而求其次，在异常发生之后选一种备选方案继续提供服务。而熔断则是指在异常达到某个临界值以后，直接切断服务通路，将用户请求统统导向降级逻辑中。

配置中心---Config

Spring Cloud借助Config组件来集中管理集群中所有服务节点的配置，它是一个中心化的配置管理中心，可以采用包括Github、Database等多种持久化方案来保存配置信息，将你的微服务从繁重的配置工作中解脱出来。利用Config组件我们可以轻松实现环境隔离、配置推送和配置项动态刷新。

动态刷新配置---Spring Cloud Bus

用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新集群中的服务配置。它承担了批量通知和推送配置变更的工作，而且我们可以通过扩展Bus的事件，实现“消息广播”的应用场景。

服务网关---Gateway

服务网关是微服务的第一道关卡，Spring Cloud则为广大的Java技术人员提供了更加“编程友好”的方式来构建网关层，那就是Gateway组件，可以对请求提供路由及过滤功能，我们可以通过Java代码或者是yml配置文件的方式编写自己的路由规则，并通过内置过滤器或自定义过滤器来实现复杂的业务需求（比如在网关层做令牌验证）。Gateway本身也集成了强大的限流功能，结合使用Redis+SpEL表达式，可以对业务系统进行精准限流。

调用链路追踪---Sleuth

微服务的一大特点就是完成一个业务场景所需要调用的上下游链路非常长，比如说一个下单操作，后台就要调用商品、订单、营销优惠、履约、消息推送、支付等等一大家子微服务，任何一个环节出错可能都会导致下单失败。那如何在一个调用链路中定位到出问题的环节呢？生产环境可不是我们的开发机器，不能为所欲为的做线上debug，那我们只能依靠日志线索。

Sleuth是Spring Cloud提供的调用链路追踪组件，它进行线上问题排查必不可少的关键环节，单就Sleuth来说，它就是在一整条调用链路中打上某个标记，将一个api请求所调用的所有上下游链路串联起来。如果从宏观的角度来说，调用链追踪还涉及到日志打标、调用链分析、日志收集、构建搜索Index等等流程，Sleuth还支持使用Zipkin、HTrace和基于日志（例如ELK）的跟踪。

消息驱动---Stream

Kafka和RabbitMQ是目前应用最广泛的消息中间件，很多异步调用场景底层都依赖于消息组件，比如说电商场景中的商品批量发布，或者下单成功后的邮件通知系统等等。

Stream是Spring Cloud为我们提供的消息驱动组件，它是轻量级事件驱动微服务框架，可以使用简单的声明式模型来发送及接收消息，主要实现为Apache Kafka及RabbitMQ。它代理了业务层和底层的物理中间件的交互，至于底层中间件是Kafka还是RabbitMQ，对业务层几乎是无感知的。借助Stream我们不仅可以轻松实现组播（组内单播）和广播场景，同时Stream还提供了对异常处理的丰富支持。

简单介绍

1）默默无闻服务

融合在每个微服务中、依赖其它组件并为其提供服务。

① Ribbon：客户端负载均衡，特性有区域亲和、重试机制。

② Hystrix：客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。

③ Feign：声明式服务调用，本质上就是Ribbon+Hystrix。

④ Stream：消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。

⑤ Bus：消息总线，配合Config仓库修改的一种Stream实现。

⑥ Sleuth：分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。

2）独挑大梁

独自启动不需要依赖其它组件，单枪匹马都能干。

① Eureka：服务注册中心，特性有失效剔除、服务保护。

② Dashboard：Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。

③ Zuul：API服务网关，功能有路由分发和过滤。

④ Config：分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式。

3）各司其职

每个组件都不是平白无故的产生的，是为了解决某一特定的问题而存在。

① Eureka和Ribbon，是最基础的组件，一个注册服务，一个消费服务。

② Hystrix为了优化Ribbon、防止整个微服务架构因为某个服务节点的问题导致崩溃，是个保险丝的作用。

③ Dashboard给Hystrix统计和展示用的，而且监控服务节点的整体压力和健康情况。

④ Turbine是集群收集器，服务于Dashboard的。 Feign是方便我们程序员些更优美的代码的。

⑤ Zuul是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，加强安全保护的。

⑥ Config是为了解决所有微服务各自维护各自的配置，设置一个同意的配置中心，方便修改配置的。

⑦ Bus是因为config修改完配置后各个结点都要refresh才能生效实在太麻烦，所以交给bus来通知服务节点刷新配置的。

⑧ Stream是为了简化研发人员对MQ使用的复杂度，弱化MQ的差异性，达到程序和MQ松耦合。

⑨ Sleuth是因为单次请求在微服务节点中跳转无法追溯，解决任务链日志追踪问题的。

Spring Cloud的版本关系

Spring Cloud是一个由许多子项目组成的综合项目，各子项目有不同的发布节奏。 为了管理Spring Cloud与各子项目的版本依赖关系，发布了一个清单，其中包括了某个Spring Cloud版本对应的子项目版本。

为了避免Spring Cloud版本号与子项目版本号混淆，Spring Cloud版本采用了名称而非版本号的命名， 这些版本的名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序，例如Angel是第一个版本，Brixton是第二个版本。 当Spring Cloud的发布内容积累到临界点或者一个重大BUG被解决后，会发布一个"servicereleases"版本，简称SRX版本，比如Greenwich.SR2就是Spring Cloud发布的Greenwich版本的第2个SRX版本。

Spring Cloud和SpringBoot版本对应关系

Spring Cloud和各子项目版本对应关系

注意：Hoxton版本是基于SpringBoot2.2.x版本构建的，不适用于1.5.x版本。随着2019年8月SpringBoot 1.5.x版本停止维护，Edgware版本也将停止维护。

SpringBoot和SpringCloud的区别和联系？

• SpringBoot只是一个快速开发框架，简化了xml配置，SpringCloud是一系列框架的集合，包含SpringBoot，为了给微服务提供一个综合管理框架
• SpringBoot可以单独使用；springcloud必须在springboot使用的前提下才能使用。
• springboot的设计目的是为了在微服务开发过程中可以简化配置文件，提高工作效率，而springcloud的设计目的是为了管理同一项目中的各个微服务

SpringBoot和SpringCloud的联系？

SpringBoot+SpringCloud实现微服务开发。具体就是SpringCloud具备微服务开发的核心技术：RPC远程调用技术；SpringBoot的web组件默认集成了SpringMVC，可以实现HTTP+JSON（Restfull）的轻量级传输，编写微服务接口，所以SpringCloud是依赖SpringBoot框架实现微服务开发。

使用 Spring Boot 开发分布式微服务时，我们面临什么问题？

在使用Spring Boot 开发分布式微服务时，我们面临的问题由Spring Cloud解决。

• 与分布式系统相关的复杂性– 包括网络问题，延迟开销，带宽问题，安全问题。
• 服务发现的问题– 服务发现允许集群中的进程和服务找到彼此并进行通信。
• 冗余问题– 冗余问题经常发生在分布式系统中。
• 负载平衡– 改进跨多个计算资源（例如计算机集群，网络链接，中央处理单元）的工作负载分布。
• 性能问题– 减少因各种操作开销导致的性能问题。

服务注册和发现是什么意思？Spring Cloud 如何实现？

服务注册

就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到一个公共的组件上去（比如: zookeeper\consul）。

服务发现

注册的服务都能够及时的被其他服务（调用者）发现，一个服务新增和删除其他服务都能够发现的了，例如A服务调用B服务，B服务噶了，A服务就能立马发现B服务噶了，就不会把再调用B服务了

Spring Cloud 如何实现？

Spring Cloud 通过Eureka 服务注册和发现。所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找。

服务治理---Eureka

服务治理组件Eureka，包括服务端的注册中心和客户端的服务发现机制；在Spring Cloud的架构中，服务治理是其中不可或缺的核心环节，服务治理确保了调用方可以准确的向可用的服务节点发起调用。就是把各个微服务注册到Eureka上面，然后可以通过发现机制发现哪些微服务是可用的，哪些是不可用的，避免把请求发送到那些不可用的微服务上面

Spring Cloud 和dubbo区别?

• 定位：Dubbo 专注 RPC 和服务治理；Spirng Cloud 是一个微服务架构生态
• 性能：Dubbo 强于 SpringCloud(主要是通信协议的影响)
• 功能范围：Dubbo 诞生于面向服务架构时代，是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案；Spring Cloud 诞生于微服务架构时代，基于 Spring、SpringBoot，关注微服务的方方面面，提供整套的组件支持
• 通信协议：Dubbo 使用 Netty（讷体），基于 TCP 协议传输，用 Hessian 序列化完成 RPC 通信；SpringCloud 是基于 Http 协议 + Rest 风格接口通信。Http 请求报文更大，占用带宽更多；Rest 比 RPC 灵活
• 调用方式：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。
• 组件差异比较多，例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper（醋 k以3 ber）
• 两者的生态对比

Dubbo 构建的微服务架构像组装电脑，组件选择自由度高、玩不好容易出问题；Spring Cloud 的像品牌机，提供一整套稳定的组件。

上面的Netty是啥？

Netty 是由 JBOSS 提供的一个 Java 开源框架。Netty 提供异步的、基于事件驱动的网络应用程序框架，用以快速开发高性能、高可靠性的网络 IO 程序,是目前最流行的 NIO 框架，Netty 在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用，知名的 Elasticsearch 、Dubbo 框架内部都采用了 Netty。

深入了解：什么是netty--通俗易懂 - 简书

上面的RPC是啥？

RPC（Remote Procedure Call）远程过程调用协议，一种通过网络从远程计算机上请求服务，而不需要了解底层网络技术的协议。RPC它假定某些协议的存在，例如TPC/UDP等，为通信程序之间携带信息数据。在OSI网络七层模型中，RPC跨越了传输层和应用层，RPC使得开发，包括网络分布式多程序在内的应用程序更加容易。

深入了解：什么是RPC？ - 简书

上面的Rest风格是啥？

URL中只使用名词来定位资源，用HTTP协议里的动词（GET、POST、PUT、DELETE）来实现资源的增删改查操作。

深入了解：什么是REST风格? 什么是RESTFUL?（一篇全读懂）_seniorShen的博客-CSDN博客_rest风格和restful风格

负载平衡的意义什么？

负载平衡的意义什么？

负载均衡的意义是是用来避免单一应用由于并发等原因，导致应用宕机从而让系统整体无法使用，使用负载均衡能够实现服务的高可用、高并发，还可以提高数据处理能力和增加吞吐量

什么是负载平衡？

负载均衡，英文名称为Load Balance，其含义就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如现在有大量请求进来，如果没有负载均衡那就都由一个应用服务来处理这些请求，可能因为请求量太大导致服务崩溃，通过负载均衡就可以把这些请求分发给各个服务来进行处理，从而协同完成工作任务。

项目中的使用？

负载均衡很出色的就是nginx，在我们项目中，服务的接入层由nginx管理，用户请求经过nginx之后，根据相应的域名，转发到对应的服务器去，由于nginx只负责请求转发，没有业务逻辑处理，所以效率上非常高。

nginx的负载均衡策略

nginx支持的负载均衡策略有很多，我们在nginx.conf中配置upstream模块即可。

• 轮训，默认的就是这种方式，就是一个个来，每个服务器轮流处理一个请求
• 权重的方式，就是根据服务器的性能，配置较大的权重，nginx就会分配更多的请求
• iphash的方式，nginx会根据请求的ip地址，经过那个hash运算得到一个hash值，然后分配相应的服务器
• 最少连接数，把请求转发给连接数较少的后端服务器

微服务中的体现

在微服务架构中，feign和zuul都集成了ribbon的的功能，它是负责在微服务之间相互调用的时候，帮我们实现负载均衡的功能，我们在将微服务注册到注册中心时，如果服务名称一致，就默认为一个集群，在进行远程调用或者路由转发的时候，都可以均衡的访问响应的服务器，ribbon的负载均衡机制有轮训和随机，默认是轮训，当然也可以自定义负载均衡的策略。

什么是 Hystrix？它如何实现容错？

提到Hystrix就不得不提一个东西叫“雪崩效应”

什么是“雪崩效应”？

服务雪崩效应是一种因“服务提供者的不可用”（原因）导致“服务调用者不可用”（结果），并将不可用逐渐放大的现象

上图中, A为服务提供者, B为A的服务调用者, C和D是B的服务调用者. 当A的不可用,引起B的不可用,并将不可用逐渐放大C和D时, 服务雪崩就形成了。这时候就出现了Hystrix，他的作用就是：避免了单个调用的微服务导致全局”雪崩”。

什么是Hystrix断路器？

Hystrix是由Netflix开源的一个服务隔离组件，通过服务隔离来避免由于依赖延迟、异常，引起资源耗尽导致系统不可用的解决方案，在分布式系统，各个服务相互调用相互依赖，必然会有部分系统的调用会失败，这就很容易引起服务雪崩，而Hystrix 通过分离服务的调用点，阻止错误在各个服务的传播，并且提供了错误回调机制，这一系列的措施提高了系统的整体服务弹性。

Hystrix断路器就像我们家庭电路中的断容器，当家庭电压过大时就好自己烧断保险丝，而断路器就是一旦后端服务不可用，断路器会直接切断请求链，避免发送大量无效请求影晌系统吞吐量，并且断路器有自我检测并恢复的能力。

Hystrix断路器有三种状态

• 断路器有完全打开状态:一段时间内达到一定的次数无法调用 并且多次监测没有恢复的迹象断路器完全打开那么下次所有请求就不会请求到该服务
• 半开:短时间内有恢复迹象断路器会将部分请求发给该服务
• 关闭：当服务一直处于正常状态能正常调用

为什么需要Hystrix断路器功能

在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用。为了保证其高可用，单个服务又必须集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用， 如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络请求涌入，会形成任务累积，导致服务瘫痪，甚至导致服务“雪崩”。为了解决这个问题，就出现断路器模型。

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等， Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

Hystrix断路器机制

当Hystrix Command请求后端服务失败数量超过一 定比例(默认50%)，断路器会切换到完全打开状态(Open)。这时所有请求会直接失败而不会发送到后端服务。断路器保持在完全打开状态一段时间后(默认5秒)，自动切换到半开状态(HALF-OPEN)。这时会判断下一次请求的返回情况，如果请求成功，断路器切到关闭状态 (CLOSED)，否则重新切换到完全打开状态(OPEN)。

Fallback（回退机制的逻辑）： Fallback相当于是降级操作。对于查询操作，我们可以实现一个fallback方法，当请求后端服务出现异常的时候，可以使用fallback方法返回的值。fallback方法的返回值一般是设置的默认值或者来自缓存。

它如何实现容错？

Hystrix主要通过以下几点实现延迟和容错。

• 包裹请求：使用HystrixCommand包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。（这里的依赖是指的一个服务调用其他服务，那这个服务就依赖其他的服务）
• 跳闸机制：当某服务的错误率超过一定的阈值时，Hystrix就会跳闸，停止请求该服务一段时间。
• 资源隔离：Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等待，从而加速失败判定。
• 监控：Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。
• 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑由开发人员自行提供，例如返回一个缺省值。
• 自我修复：断路器打开一段时间后，会自动进入“半开”状态。

骚戴理解：说白了就是当其中的某个服务出错了，那么如果还有大量的请求进来就会直接被拒绝，也就是不会调用这个出错了的服务，然后直接返回一个默认的错误值，告诉调用这个服务的服务这个服务出了问题，现在不可用，而不是让大量的请求一直在等待这个出错了的服务来处理这些请求，因为如果一直等待的话就很容易出现服务雪崩

什么是 Netflix Feign？它的优点是什么？

什么是 Netflix Feign？

考虑到Spring Cloud的服务治理组件也是基于HTTP的，因此特别需要一款简化服务调用的组件。Feign的出现就是为了解决这个问题，我们可以借助Feign的代理机制，像调用一个接口方法一样发起远程HTTP调用来进行服务之间的通信。简单来说就是用来实现各个微服务直接的通信的，说白了就是各个微服务之间的调用要通过Feign来实现

它的优点是什么？

• feign采用的是基于接口的注解
• feign整合了ribbon，具有负载均衡的能力
• 整合了Hystrix，具有熔断的能力

什么是 Spring Cloud Bus？我们需要它吗？

什么是 Spring Cloud Bus？

用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新集群中的服务配置。它承担了批量通知和推送配置变更的工作，而且我们可以通过扩展Bus的事件，实现“消息广播”的应用场景。

我们需要它吗？

Spring Cloud Bus 提供了跨多个实例刷新配置的功能。只要我们修改了某个模块的配置，则会自动刷新所有其他必需的模块。如果我们有多个微服务启动并运行，这特别有用。这是通过将所有微服务连接到单个消息代理来实现的。无论何时刷新实例，此事件都会订阅到侦听此代理的所有微服务，并且它们也会刷新。可以通过使用端点/总线/刷新来实现对任何单个实例的刷新。

简单来说就是可以动态的刷新配置内容，只要修改了某个配置文件，其他的所依赖它的配置文件就都会动态刷新

深入了解：Spring Cloud Bus-用法和意义_ssehs的博客-CSDN博客

了解分布式系统吗？说说你的理解

1、什么是分布式？

在讲什么是分布式之前应该知道什么是微服务？微服务就是将一个大的服务拆分成几十个甚至上百个微小的服务，每个服务都可以独立运行。分布式不是一种技术，分布式是一种方案，分布式就是在微服务的基础上，可以允许把这些拆分的微服务放到不同的电脑上去运行，分布在不同的地方的电脑上运行都可以，微服务是分布式系统的一种具体落地方案。

2、优点

• 系统可用性提升

传统的集中式计算或集中式存储在遇见单点故障时很容易造成整个服务不可用，分布式下的服务体系，单台机器有故障，不致于造成整个服务不可用。

• 系统并发能力提升

请求通过 Nginx 负载均衡被分发到不同的服务器上，运行同样代码的服务器可以有 1 台或 N 台，通常情况下会根据实际用户访问量随时增加机器，无论是数据库或者服务，都可以做到随时水平扩展。

比如双 11 活动，平时订单少 50 台机器就够了，到了 11 订单量剧增，服务器增加到 100 台，每台机器之间相互独立，互不影响。

• 系统容错能力提升

同一组服务分别部署在北京上海杭州，杭州的机房突发断电或者火灾，杭州机房的流量会被自动分发到北京和上海的机房，不影响用户使用。

• 低延迟

参考上一个图，北京的用户请求自动分发到北京，上海的用户请求被分发到上海，服务器会根据用户的 IP 选择距离自己最近的机房，降低网络延迟。

3、缺点

• 分布式服务依赖网络

服务器间通讯依赖网络，不可靠网络包括网络延时，丢包、中断、异步，一个完整的服务请求依赖一连串服务调用，任意一个服务节点网络出现问题，都可能造成本次请求失败。

• 维护成本高

传统单体式服务只需要维护一个站点就可以。

分布式服务系统被拆分成若干个小服务，服务从 1 变为几十个上百个服务后，增加运维成本。

• 一致性，可用性，分区容错性无法同时满足

这个是最主要的，这三种特性就是平时说的 CAP 定理，在分布式系统中，这三种特性最多只能满足两种，无法同时满足，需要根据实际情况去调整牺牲掉其中哪个。

CAP 定理

CAP 理论告诉我们，一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。

选项	描述
C（Consistence）一致性	指数据在多个副本之间能够保持一致的特性（严格的一致性）。
A（Availability）可用性	指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。
P（Network partitioning）分区容错性	分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

假设有一个系统如下：

整个系统由两个节点配合组成，之间通过网络通信，当节点 A 进行更新数据库操作的时候，需要同时更新节点 B 的数据库（这是一个原子的操作）。

上面这个系统怎么满足 CAP 呢？C：当节点A更新的时候，节点B也要更新，A：必须保证两个节点都是可用的，P：当节点 A,B 出现了网络分区，必须保证对外可用。

可见，根本完成不了，只要出现了网络分区，A 就无法满足，因为节点 A 根本连接不上节点 B。如果强行满足 C 原子性，就必须停止服务运行，从而放弃可用性 C。

所以，最多满足两个条件：