Spring Cloud常用组件简介

前言：
大家都知道Spring Cloud是一套微服务框架，既然是服务于微服务，其核心的组件也就是解决微服务的核心问题；

核心问题：

1. 服务很多，客户端怎么访问？（Zuul、Gateway）
2. 服务很多，怎么管理这些服务？（Eureka、Consul、Nacos）
3. 服务很多，服务之间怎么通信？（Feign、OpenFeign、Dubbo）
4. 服务挂掉怎么办？ （Hystrix、Sentinel）

其他问题：

• 服务很多，怎么管理配置？（Spring Cloud Config、Spring Cloud Bus、Nacos）
• 如何保障服务安全？（Spring Cloud Security）
• 如何与缓存（Redis）及中间件（MQ）通信？（Spring Cloud Stream）
• …

服务条目与技术：

微服务条目	落地技术
服务开发	SpringBoot，Spring MVC
服务配置与管理	Netflix公司的Archaius 、阿里的Diamond、Nacos等
服务注册与发现	Eureka、Consul、Zookeeper、Nacos等
服务调用	Rest、RPC、gRPC、Dubbo
服务限流熔断	Hystrix、Envvoy、Sentinel等
负载均衡	Ribbon、Nginx等
服务接口调用	Feign、OpenFeign、Consul等
消息队列	kafka、RabbitMQ、ActiveMQ、RocketMQ等
服务配置中心管理	SpringCloudConfig、Chef、Nacos等
服务路由（API网关）	Zuul、Gateway等
服务监控	Zabbix、Nagios、Metrics、Specatator等
全链路追踪	skywalking、Zipkin、Brave、Dapper等
服务部署	Docker、OpenStrack、Kubernetes等
数据流操作开发包	SpringCloud Stream（封装与Redis，Rabbit，kafka等发送接收消息）
时间消息总线	SpringCloud Bus

结构简图：

• 外部请求：
  来自移动端（Android、IOS…）、浏览器客户端等发起的HTTP请求。

• Zuul/Gateway：
  Zuul和Gateway都用作路由网关，但Gateway更简单、高效（毕竟是亲儿子）。
  作用是可以为外部请求提供统一的访问接口，减少耦合配置，外部不需要关注后台多种服务的类别划分及IP端口。

• Feign  查看笔记
  用于微服务之间的通信，集成了负载均衡（Ribbon）及熔断器（Hystrix）。从代码层面来说可以减少代码的冗余，一个功能接口开放出来，其他模块都调用就行了，也便于后期维护。

• Eureka_Server
  是服务的注册中心，注册表中会记录各个服务（Eureka_Client）的信息，负责管理所有的服务资源，Eureka_Server注册中心会根据Feign的请求信息及负载均衡规则确定具体的服务。

• Ribbon
  作用是负载均衡，在高可用的情况下某一类服务会部署多个，以达到高并发，高可用性的目的，默认以 轮询 的方式去为服务分配请求，比如有服务1、服务2、服务3都属于A类服务，陆陆续续来了6个A类服务的请求，那么就会依次分配给1、2、3、1、2、3，也可以自定义其他负载均衡策略，如 服务响应时长、自定义权重、随机、Hash等。

• Eureka_Client
  其本质就是一个个的Spring Boot项目，分布式的架构下会将项目中的独立功能模块解耦出来作为一个Spring Boot项目，Spring Boot项目启动后会根据配置将自己注册到指定的Eureka_Server服务注册中心（有集群需要，可注册到多个注册中心），这样在外部调用的时候找到具体的服务了。

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

底层原理是为每个类型的服务创建独立的线程池，前面有说到注册中心会根据外部请求规则筛选服务，那么是根据什么规则呢？其实最主要的是服务的可用性，服务无法响应或延时较高，则会调整熔断器的状态，需要注意的是当服务熔断后，注册中心并不会立即清除该服务，而是启动安全模式，保存该服务状态信息，等待服务正常后解除安全模式。

服务熔断和服务降级有什么区别？
服务熔断和服务降级都是为了在分布式系统中应对异常情况，保障系统的高可用性和稳定性。它们的主要区别在于触发原因、管理目标层次、实现方式以及触发后的处理方式。以下是详细介绍：
触发原因不同。服务熔断通常是由于某个服务（下游服务）出现故障或响应异常引起的，如错误率超出阈值或请求超时等；服务降级则更多是基于整体系统负载的考虑，主动进行资源优化和功能降级。
管理目标层次不同。服务熔断通常是一个框架级别的处理，每个微服务都需要，没有特定的层级；服务降级则一般需要对业务有层级之分，通常从最外围服务开始。
实现方式不同。服务熔断通过中断对故障服务的请求来保护系统稳定性，防止故障的传播；服务降级则是通过降低非核心功能的优先级或关闭一些服务来应对异常情况。
触发后的处理方式不同。服务熔断在触发后，会直接调用服务降级方法；服务降级则每次都会先调用原服务方法，如果失败才会执行降级方法。
总的来说，服务熔断更侧重于快速恢复和保护系统稳定性，而服务降级则侧重于资源优化和保障核心业务运行。在实际应用中，两者通常结合使用，以提高整个系统的稳定性和可用性。