Spring Cloud原理详解

目录

 

业务场景介绍

Spring Cloud组件：Eureka

Spring Cloud组件：Feign

 Spring Cloud组件：Ribbon

 Spring Cloud组件：Hystrix

 Spring Cloud组件：Zuul

总结

---

业务场景介绍

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

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

• 扣减相应的商品库存

• 通知仓储中心，进行发货

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

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

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

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

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

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

• 整个支付订单的业务流程结束

下图这张图，清晰表明了各服务间的调用过程：

---

Spring Cloud组件：Eureka

订单服务想要调用库存服务、仓储服务，或者积分服务，怎么调用？

• 订单服务压根儿就不知道人家库存服务在哪台机器上啊！他就算想要发起一个请求，都不知道发送给谁，有心无力！

• 这时候，就轮到Spring Cloud Eureka出场了。Eureka是微服务架构中的注册中心，专门负责服务的注册与发现。

咱们来看看下面的这张图，结合图来仔细剖析一下整个流程：

• 库存服务、仓储服务、积分服务中都有一个Eureka Client组件，这个组件专门负责将这个服务的信息注册到Eureka Server中。即告诉Eureka Server，自己在哪台机器上，监听着哪个端口。

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

• 订单服务里也有一个Eureka Client组件，这个Eureka Client组件会找Eureka Server问一下：库存服务在哪台机器啊？监听着哪个端口啊？仓储服务呢？积分服务呢？然后就可以把这些相关信息从Eureka Server的注册表中拉取到自己本地缓存起来。

• 如果订单服务想要调用库存服务，不就可以找自己本地的Eureka Client问一下库存服务在哪台机器？监听哪个端口吗？收到响应后，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口！同理，如果订单服务要调用仓储服务、积分服务，也是如法炮制。

总结：

• Eureka Client：负责将这个服务的信息注册到Eureka Server中。

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

---

Spring Cloud组件：Feign

概念：

• Feign关键机制：动态代理

• Feign默认集成RestTemplate和Ribbon。

• 支持Hystrix，不过默认是关闭的。

作用：

• 简化微服务之间的调用。

Feign结合业务场景原理图：

• 对某个接口定义@FeignClient注解，指定服务名，Feign就会针对这个接口创建一个动态代理。

• 调用被定义了@Feign注解的接口，本质上会调用Feign创建的动态代理。

• Feign的动态代理会根据接口中，方法上的@RequestMapping等注解，动态构造请求的服务地址。

• 针对构造出来的请求地址，发送请求，解析响应。

---

 Spring Cloud组件：Ribbon

作用：

• 负载均衡

Ribbon结合业务场景原理图：

• Ribbon从Eureka Client中获取对应的服务注册地址列表，知道所有的服务部署位置，再监听端口号。

• Ribbon可以使用默认的轮询算法，从中选择一台机器。

• Feign针对被选择的机器，构造并发起请求 。

---

 Spring Cloud组件：Hystrix

作用：

• 熔断降级、防止服务雪崩。

业务场景：

• 在微服务架构里，一个系统会有很多的服务。

• 以本文的业务场景为例：订单服务在一个业务流程里需要调用三个服务。现在假设订单服务自己最多只有100个线程可以处理请求，然后呢，积分服务不幸的挂了，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。

服务雪崩问题：

1. 如果系统处于高并发的场景下，大量请求涌过来的时候，订单服务的100个线程都会卡在请求积分服务这块，导致订单服务没有一个线程可以处理请求。

2. 然后就会导致别人请求订单服务的时候，发现订单服务也挂了，不响应任何请求了。

服务雪崩问题图：

• 多服务相互调用，要是不做任何保护的话，某一个服务挂了，就会引起连锁反应，导致别的服务也挂。

• 比如积分服务挂了，会导致订单服务的线程全部卡在请求积分服务这里，没有一个线程可以工作，瞬间导致订单服务也挂了，别人请求订单服务全部会卡住，无法响应。

Hystrix隔离、熔断、降级的流程图：

• Hystrix是隔离、熔断、降级的一个框架。

• Hystrix会创建很多小的线程池，例如订单服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池，每个线程池里的线程就仅仅用于请求那个服务。

• 如果积分服务挂了，出现以下现象：

  • 导致订单服务中用来调用积分服务的线程都卡死不能工作，但由于订单服务调用库存服务、仓储服务的这两个线程池都是正常工作的，所以这两个服务不会受到任何影响。

  • 这个时候如果别人请求订单服务，订单服务还是可以正常调用库存服务扣减库存，调用仓储服务通知发货。只不过调用积分服务的时候，每次都会报错。

• 熔断：

  • 如果积分服务已经宕机，每次调用都要去卡住几秒钟，没有意义。

  • 直接对积分服务熔断。

  • 例如：在5分钟内请求积分服务直接就返回了，不要去走网络请求卡住几秒钟，这个过程就是所谓的熔断！

• 降级：

  • 积分服务宕机就直接熔断，不合理。

  • 每次调用积分服务，就在数据库里记录一条消息，说给某某用户增加了多少积分，因为积分服务宕机，导致没增加成功！

  • 等积分服务恢复了，可以根据这些记录手工加一下积分，这个过程就是所谓的降级。

---

 Spring Cloud组件：Zuul

概念：

• Zuul：微服务网关，负责网络路由。

• 有一个网关之后，可以做统一的降级、限流、认证授权、安全等。

---

总结

1. Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client可以从Eureka Server中拉取注册表，获取其他服务的地址和端口号。

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

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

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

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

6.