Springcloud底层原理

Spring Cloud 是一个基于 Spring Boot 的‌分布式系统开发工具包‌，是一套分布式微服务技术解决方案，它通过封装成熟的分布式服务框架（如 Netflix 和 Alibaba 的开源组件），提供了一套简单易用的微服务架构解决方案，显著降低了构建分布式系统的复杂度。其核心思想是‌“微服务全家桶”‌ ，涵盖服务治理、通信、容错等关键领域，使开发者能专注于业务逻辑。

Spring Cloud提供了快速构建分布式系统常用的一些组件，如配置管理、服务注册与发现、服务调用的负载均衡、资源隔离、熔断降级等。不过 Spring Cloud 只是 Spring 官方提供的一套微服务标准定义，而真正地实现目前有两套体系用得比较多。一个是 Spring Cloud Netflix ，另一个是 Spring Cloud Alibaba。

Spring Cloud Netflix 是基于 Netflix 公司的开源组件集成的一套微服务解决方案，其中的组件有：1.Eureka——服务注册与发现，2.Feign——服务调用，3.Ribbon——负载均衡，4.Hystrix——服务熔断，5.Zuul——网关。

Spring Cloud Alibaba 是基于阿里巴巴开源组件集成的一套微服务解决方案，其中包括：1.Nacos——服务注册与发现，2.Dubbo——消息通讯，3.Seata——事务隔离，4. Sentinel——熔断降级。

有了 Spring Cloud 这样的技术生态，使得微服务架构落地时，不用去考虑第三方技术集成带来的额外成本，只要通过配置组件来完成架构下的技术问题，从而可以让开发者更加专注于业务逻辑。

‌

一、核心组件与作用‌

1. ‌服务注册与发现‌

• ‌组件‌：
  • Eureka（Netflix）
  • Nacos（Alibaba，推荐）
• ‌作用‌：
  • 服务提供者启动时向注册中心注册自身信息（IP、端口、服务名）；
  • 服务消费者动态获取服务列表，实现服务自动发现与调用；
  • 支持心跳检测，自动剔除失效节点。
• ‌对比‌：
  • Eureka 采用 AP 模型（高可用优先），适合对一致性要求不高的场景；
  • Nacos 支持 AP/CP 模式切换，兼具服务发现与配置中心功能，是当前主流。

2. ‌客户端负载均衡‌

• ‌组件‌：
  • Ribbon（Netflix）
  • Spring Cloud LoadBalancer（官方替代）
• ‌作用‌：
  • 从服务列表中按策略（轮询、随机、响应时间加权等）选择实例；
  • 集成于服务消费者内部，与 RestTemplate 或 Feign 协同工作。

3. ‌声明式服务调用‌

• ‌组件‌：Feign
• ‌作用‌：
  • 通过注解定义接口，自动封装 HTTP 请求；
  • 内置 Ribbon 负载均衡，简化服务间调用代码。
  • 示例：订单服务调用用户服务时，只需声明 @FeignClient("user-service") 接口。

4. ‌熔断与容错‌

• ‌组件‌：Hystrix（Netflix）
• ‌作用‌：
  • 熔断‌：当服务调用失败率超过阈值时，暂停请求避免级联故障；
  • 降级‌：返回预设的备选结果（如默认值），保证系统部分可用。
  • 场景：用户服务不可用时，订单服务自动返回缓存的基本用户信息。

5. ‌服务网关‌

• ‌组件‌：
  • Zuul（Netflix）
  • Spring Cloud Gateway（官方新一代）
• ‌作用‌：
  • 路由转发‌：将外部请求分发到内部微服务；
  • 过滤拦截‌：实现身份验证、日志记录、流量控制等。
  • 示例：/api/orders 请求被路由至订单服务，/api/users 路由至用户服务。

6. ‌分布式配置管理‌

• ‌组件‌：Spring Cloud Config
• ‌作用‌：
  • 将配置文件集中存储（Git/SVN），服务启动时拉取配置；
  • 支持动态刷新配置（需配合 Spring Cloud Bus 消息总线）。

7. ‌消息总线‌

• ‌组件‌：Spring Cloud Bus
• ‌作用‌：
  • 通过消息中间件（如 Kafka、RabbitMQ）广播配置更新事件；
  • 实现所有服务实例的配置动态刷新。

二、Spring Cloud 的核心价值‌

• ‌简化开发‌：通过 Spring Boot 风格封装，一键启动复杂功能（如服务注册、熔断）；
• ‌标准化治理‌：提供微服务通用模式（配置中心、网关、负载均衡）的统一实现；
• ‌生态兼容‌：适配 Netflix、Alibaba 等方案，支持混合技术栈；
• ‌成本优化‌：帮助中小企业快速构建分布式系统，避免重复造轮子。

‌

发展趋势‌：Netflix 组件（如 Eureka、Hystrix）已进入维护模式，Spring Cloud Alibaba（Nacos、Sentinel）成为新一代主流选择。

1、业务场景介绍

假设现在开发一个电商网站，要实现支付订单的功能，流程如下：

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

2、扣减相应的商品库存

3、通知仓储中心，进行发货

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

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

1、用户完成支付之后，就需要订单服务去更新订单状态

2、订单服务调用库存服务，扣减商品库存

3、订单服务调用仓储服务，通知仓库发货

4、订单服务调用积分服务，为用户增加积分

至此，整个支付订单的业务流程结束。下图清晰表明了各服务间的调用过程：

有了业务场景之后，下面来看看Spring Cloud微服务架构中，这几个组件如何相互协作，各自发挥的作用及其背后的原理。

2、Springcloud-Eureka

考虑第一个问题：订单服务想要调用库存服务、仓储服务，或者是积分服务，怎么调用？

订单服务根本不知道库存服务在哪台机器上！这时候就轮到SpringCloud Eureka出场了。Eureka是微服务架构中的注册中心，专门负责服务的注册与发现。

 结合下图来仔细剖析一下整个流程：

如上图所示，订单服务、库存服务、仓储服务、积分服务中都有一个Eureka Client组件，这个组件专门负责将这个服务的信息注册到Eureka Server中。就是告诉Eureka Server，自己在哪台机器上，监听着哪个端口。Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。另外，每个服务的Eureka Client组件还会从Eureka Server中拉取注册表缓存到自己本地。

这时如果订单服务想要调用库存服务，就可以从自己本地的Eureka Client查找库存服务的地址信息，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口！同理，如果订单服务要调用仓储服务、积分服务，也是如此。

总结一下：

Eureka Client：负责将这个服务的信息注册到Eureka Server中，同时从Eureka Server中拉取注册表缓存到自己本地。

Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号。

3、Springcloud-Feign

现在订单服务确实知道库存服务、积分服务、仓库服务在哪里了，但是新问题又来了：难道订单服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗？

下面这段是根据上述流程编写的代码片段，体会一下这种绝望而无助的感受！

进行服务间调用时如果每次都手写代码，代码量比上面这段要多至少几倍，所以这个事儿压根儿就不是地球人能干的。既然如此，那怎么办呢？ Feign早已提供了优雅的解决方案。来看看如果用Feign的话，订单服务调用库存服务的代码会变成啥样？

没有底层的建立连接、构造请求、解析响应的代码，直接就是用注解定义一个 FeignClient接口，然后调用那个接口就可以了。Feign Client会在底层根据提供的@RequestMapping等注解，与被调用的服务建立连接、构造请求、发起请求、获取响应、解析响应等等。

Feign是如何做到这么神奇的呢？ Feign的一个关键机制就是使用了动态代理。结合下图来简单分析一下：

首先，如果对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理。其次，若要调用这个接口，本质就是会调用 Feign创建的动态代理。然后，Feign的动态代理会根据接口上的@RequestMapping等注解，来动态构造出要请求的服务地址。最后，针对这个地址，发起请求、解析响应。

4、Springcloud-Ribbon

如果库存服务部署在了5台机器上，如下所示：

192.168.169:9000

192.168.170:9000

192.168.171:9000

192.168.172:9000

192.168.173:9000

这下麻烦了！Feign怎么知道该请求哪台机器呢？

这时Spring Cloud Ribbon就派上用场了。Ribbon就是专门解决这个问题的。它的作用是负载均衡，会在每次请求时选择一台机器，均匀的把请求分发到各个机器上。

Ribbon的负载均衡默认使用经典的Round Robin轮询算法。简单来说，就是如果订单服务对库存服务发起10次请求，那就先请求第1台机器、然后是第2台机器、第3台机器、第4台机器、第5台机器，接着再来—个循环，第1台机器、第2台机器……以此类推。

 此外，Ribbon是和Feign以及Eureka紧密协作，完成工作的，具体如下：

首先Ribbon会从 Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器，Feign就会针对这台机器，构造并发起请求。

5、Springcloud-Hystrix

在微服务架构里，一个系统会有很多的服务。以本文的业务场景为例：订单服务在一个业务流程里需要调用三个服务。现在假设订单服务自己最多只有100个线程可以处理请求，积分服务不幸的挂了，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。如果系统处于高并发的场景下，大量请求涌过来的时候，订单服务的100个线程都会卡在请求积分服务这块，导致订单服务没有一个线程可以处理请求。然后就会导致别人请求订单服务的时候，发现订单服务也挂了，不响应任何请求了。

上面这个就是微服务架构中恐怖的服务雪崩问题，如下图所示：

如上图所示，这么多服务互相调用，要是不做任何保护的话，某一个服务挂了，就会引起连锁反应，导致别的服务也挂。比如积分服务挂了，会导致订单服务的线程全部卡在请求积分服务这里，没有一个线程可以工作，瞬间导致订单服务也挂了，别人请求订单服务全部会卡住，无法响应。

结合业务来看：支付订单的时候，只要把库存扣减了，然后通知仓库发货就OK了。如果积分服务挂了，大不了等他恢复之后，慢慢手工恢复数据！为啥一定要因为一个积分服务挂了，就直接导致订单服务也挂了呢？不可以接受！积分服务挂了，不应该导致订单服务不可用。

这时就轮到Hystrix闪亮登场了。Hystrix是隔离、熔断以及降级的一个框架。因为Hystrix会搞很多个小小的线程池，比如订单服务请求库存服务是一个线程池，请求仓储服务是另一个线程池，请求积分服务又是一个线程池。每个线程池里的线程就仅仅用于请求那个服务。

现在再看一下上面那个问题，假设积分服务挂了，当然会导致订单服务里的那个用来调用积分服务的线程都卡死不能工作了！但是由于订单服务调用库存服务、仓储服务的这两个线程池都是正常工作的，所以这两个服务不会受到任何影响。这个时候如果别人请求订单服务，订单服务还是可以正常调用库存服务扣减库存，调用仓储服务通知发货。只不过调用积分服务的时候，每次都会报错。但是如果积分服务都挂了，每次调用都要去卡住几秒钟没有意义！所以直接对积分服务熔断就可以了，比如在5秒钟内请求积分服务直接就返回了，不要去走网络请求卡住几秒钟，这个过程，就是所谓的熔断！

另外，如果积分服务挂了直接熔断不太友好，那就来个服务降级：每次调用积分服务，就在数据库里记录一条消息，说给某某用户增加了多少积分，因为积分服务挂了，导致没增加成功！这样等积分服务恢复了，可以根据这些记录手工加一下积分。这个过程，就是所谓的降级。

如下图所示梳理一下Hystrix隔离、熔断和降级的全流程：

6、Springcloud-Zuul

Zuul组件就是微服务网关，这个组件是负责网络路由的。如果没有Zuul的日常工作会怎样？

假设后台部署了几十个服务，前端通过浏览器向库存服务发起请求，首先前端需要知道库存服务的名称以及部署在哪台机器上，几十个服务的地址都要在前端代码中记录不太现实。所以一般微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用关心后端有多少个服务，只需要知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。而且有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。

最后再来总结一下，上述几个Spring Cloud核心组件，在微服务架构中，分别扮演的角色：

Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以从Eureka Server拉取注册表，从而知道其他服务在哪里。

Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台。

Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求。

Hystrix：发起请求是通过Hystrix的线程池来进行的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。

Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务。

以上就是通过一个电商业务场景，阐述了Spring Cloud微服务架构几个核心组件的底层原理。

将Spring Cloud的5个核心组件通过一张图串联起来，直观的感受一下其底层的架构原理：