JAVA学习之路（八）—— SpringCloud

马院代表人

已于 2024-12-29 14:42:45 修改

阅读量1.1k

点赞数 20

文章标签： java 学习 spring cloud

于 2024-12-29 13:50:43 首次发布

本文链接：https://blog.youkuaiyun.com/m0_46747954/article/details/144804415

版权

说明

本文仅供本人学习，如果有不对的地方欢迎大家一起讨论

记录JAVA的学习路程 —— SpringCloud

微服务

什么是微服务？

微服务(Microservice Architecture) 是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。
究竟什么是微服务呢？在此引用ThoughtWorks 公司的首席科学家 Martin Fowler 于2014年提出的一段话：
原文：https://martinfowler.com/articles/microservices.html
汉化：https://www.cnblogs.com/liuning8023/p/4493156.html

就目前而言，对于微服务，业界并没有一个统一的，标准的定义。
但通常而言，微服务架构是一种架构模式，或者说是一种架构风格，它体长将单一的应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程内，服务之间互相协调，互相配置，为用户提供最终价值，服务之间采用轻量级的通信机制(HTTP)互相沟通，每个服务都围绕着具体的业务进行构建，并且能狗被独立的部署到生产环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应该根据业务上下文，选择合适的语言，工具(Maven)对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

再来从技术维度角度理解下：

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。

微服务与微服务架构

微服务

强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义的看，可以看作是IDEA中的一个个微服务工程，或者Moudel。IDEA 工具里面使用Maven开发的一个个独立的小Moudel，它具体是使用SpringBoot开发的一个小模块，专业的事情交给专业的模块来做，一个模块就做着一件事情。强调的是一个个的个体，每个个体完成一个具体的任务或者功能。

微服务架构

一种新的架构形式，Martin Fowler 于2014年提出。
微服务架构是一种架构模式，它体长将单一应用程序划分成一组小的服务，服务之间相互协调，互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制**(如HTTP)互相协作，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中，另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具(如Maven)**对其进行构建。

微服务优缺点

优点

单一职责原则；
每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求；
开发简单，开发效率高，一个服务可能就是专一的只干一件事；
微服务能够被小团队单独开发，这个团队只需2-5个开发人员组成；
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
微服务能使用不同的语言开发；
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins，Hudson，bamboo；
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值；
微服务允许利用和融合最新技术；
微服务只是业务逻辑的代码，不会和HTML，CSS，或其他的界面混合;
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统

缺点

开发人员要处理分布式系统的复杂性；
多服务运维难度，随着服务的增加，运维的压力也在增大；
系统部署依赖问题；
服务间通信成本问题；
数据一致性问题；
系统集成测试问题；
性能和监控问题；

微服务技术栈有那些？

微服务条目	技术	备注
服务开发	Springboot、Spring、SpringMVC
服务配置与管理	Netflix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Consul、Zookeeper等
服务调用	REST、RPC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用（客户端调用服务发简单工具）	Feign等
消息队列	kafka、RabbitMQ、ActiveMQ等
服务配置中心管理	SpringCloudConfig、Chef等
服务路由（API网关）	Zuul等
服务监控	Zabbix、Nagios、Metrics、Spectator等
全链路追踪	Zipkin、Brave、Dapper等
服务部署	Docker、OpenStack、Kubernetes等
数据流操作开发包	SpringCloud Stream（封装与Redis，Rabbit、Kafka等发送接收消息）
事件消息总线	SpringCloud Bus
…

为什么选择SpringCloud作为微服务架构

选型依据

- 整体解决方案和框架成熟度
- 社区热度
- 可维护性
- 学习曲线
当前各大IT公司用的微服务架构有那些？
- 阿里：dubbo+HFS
- 京东：JFS
- 新浪：Motan
- 当当网：DubboX
  
  …
各微服务框架对比

功能点/服务框架	Netflix/SpringCloud	Motan	gRPC	Thrift	Dubbo/DubboX
功能定位	完整的微服务框架	RPC框架，但整合了ZK或Consul，实现集群环境的基本服务注册/发现	RPC框架	RPC框架	服务框架
支持Rest	是，Ribbon支持多种可插拔的序列化选择	否	否	否	否
支持RPC	否	是（Hession2）	是	是	是
支持多语言	是（Rest形式）？	否	是	是	否
负载均衡	是（服务端zuul+客户端Ribbon），zuul-服务，动态路由，云端负载均衡Eureka（针对中间层服务器）	是（客户端）	否	否	是（客户端）
配置服务	Netfix Archaius，Spring Cloud Config Server集中配置	是（zookeeper提供）	否	否	否
服务调用链监控	是（zuul），zuul提供边缘服务，API网关	否	否	否	否
高可用/容错	是（服务端Hystrix+客户端Ribbon）	是（客户端）	否	否	是（客户端）
典型应用案例	Netflix	Sina	Google	Facebook
社区活跃程度	高	一般	高	一般	2017年后重新开始维护，之前中断了5年
学习难度	中等	低	高	高	低
文档丰富程度	高	一般	一般	一般	高
其他	Spring Cloud Bus为我们的应用程序带来了更多管理端点	支持降级	Netflix内部在开发集成gRPC	IDL定义	实践的公司比较多

SpringCloud

SpringCloud是什么？

springcloud官网： https://spring.io/projects/spring-cloud#learn

SpringCloud和SpringBoot的关系

SpringBoot专注于开苏方便的开发单个个体微服务；
SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务，整合并管理起来，为各个微服务之间提供：配置管理、服务发现、断路器、路由、为代理、事件总栈、全局锁、决策竞选、分布式会话等等集成服务；
SpringBoot可以离开SpringCloud独立使用，开发项目，但SpringCloud离不开SpringBoot，属于依赖关系；
SpringBoot专注于快速、方便的开发单个个体微服务，SpringCloud关注全局的服务治理框架；

Dubbo 和 SpringCloud技术选型

1. 分布式+服务治理Dubbo

目前成熟的互联网架构，应用服务化拆分 + 消息中间件

2. Dubbo 和 SpringCloud对比

可以看一下社区活跃度：

https://github.com/dubbo

https://github.com/spring-cloud

对比结果：

最大区别：Spring Cloud 抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式
严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这个优点在当下强调快速演化的微服务环境下，显得更加合适。

品牌机和组装机的区别

社区支持与更新力度的区别

**总结：**二者解决的问题域不一样：Dubbo的定位是一款RPC框架，而SpringCloud的目标是微服务架构下的一站式解决方案。

SpringCloud能干嘛？

Distributed/versioned configuration 分布式/版本控制配置
Service registration and discovery 服务注册与发现
Routing 路由Service-to-service calls 服务到服务的调用
Load balancing 负载均衡配置
Circuit Breakers 断路器
Distributed messaging 分布式消息管理
…

SpringCloud下载

官网：http://projects.spring.io/spring-cloud/

SpringCloud没有采用数字编号的方式命名版本号，而是采用了伦敦地铁站的名称，同时根据字母表的顺序来对应版本时间顺序，比如最早的Realse版本：Angel，第二个Realse版本：Brixton，然后是Camden、Dalston、Edgware，目前最新的是Hoxton SR4 CURRENT GA通用稳定版。

自学参考书：

SpringCloud Netflix 中文文档：https://springcloud.cc/spring-cloud-netflix.html
SpringCloud 中文API文档(官方文档翻译版)：https://springcloud.cc/spring-cloud-dalston.html
SpringCloud中国社区：http://springcloud.cn/
SpringCloud中文网：https://springcloud.cc

SpringCloud微服务组件

微服务常用的组件：

注册中心：注册中心是微服务架构最核心的组件。它起到的作用是对新节点的注册与状态维护，解决了「如何发现新节点以及检查各节点的运行状态的问题」。微服务节点在启动时会将自己的服务名称、IP、端口等信息在注册中心登记，注册中心会定时检查该节点的运行状态。注册中心通常会采用心跳机制最大程度保证已登记过的服务节点都是可用的。
负载均衡：负载均衡解决了「如何发现服务及负载均衡如何实现的问题」，通常微服务在互相调用时，并不是直接通过IP、端口进行访问调用。而是先通过服务名在注册中心查询该服务拥有哪些节点，注册中心将该服务可用节点列表返回给服务调用者，这个过程叫服务发现，因服务高可用的要求，服务调用者会接收到多个节点，必须要从中进行选择。因此服务调用者一端必须内置负载均衡器，通过负载均衡策略选择合适的节点发起实质性的通信请求。
服务通信：服务通信组件解决了「服务间如何进行消息通信的问题」，服务间通信采用轻量级协议，通常是HTTP RESTful风格。但因为RESTful风格过于灵活，必须加以约束，通常应用时对其封装。例如在SpringCloud中就提供了Feign和RestTemplate两种技术屏蔽底层的实现细节，所有开发者都是基于封装后统一的SDK进行开发，有利于团队间的相互合作。
配置中心：配置中心主要解决了「如何集中管理各节点配置文件的问题」，在微服务架构下，所有的微服务节点都包含自己的各种配置文件，如jdbc配置、自定义配置、环境配置、运行参数配置等。要知道有的微服务可能可能有几十个节点，如果将这些配置文件分散存储在节点上，发生配置更改就需要逐个节点调整，将给运维人员带来巨大的压力。配置中心便由此而生，通过部署配置中心服务器，将各节点配置文件从服务中剥离，集中转存到配置中心。一般配置中心都有UI界面，方便实现大规模集群配置调整。
集中式日志管理：集中式日志主要是解决了「如何收集各节点日志并统一管理的问题」。微服务架构默认将应用日志分别保存在部署节点上，当需要对日志数据和操作数据进行数据分析和数据统计时，必须收集所有节点的日志数据。那么怎么高效收集所有节点的日志数据呢？业内常见的方案有ELK、EFK。通过搭建独立的日志收集系统，定时抓取各节点增量日志形成有效的统计报表，为统计和分析提供数据支撑。
分布式链路追踪：分布式链路追踪解决了「如何直观的了解各节点间的调用链路的问题」。系统中一个复杂的业务流程，可能会出现连续调用多个微服务，我们需要了解完整的业务逻辑涉及的每个微服务的运行状态，通过可视化链路图展现，可以帮助开发人员快速分析系统瓶颈及出错的服务。
服务保护：服务保护主要是解决了「如何对系统进行链路保护，避免服务雪崩的问题」。在业务运行时，微服务间互相调用支撑，如果某个微服务出现高延迟导致线程池满载，或是业务处理失败。这里就需要引入服务保护组件来实现高延迟服务的快速降级，避免系统崩溃。

SpringCloud Alibaba实现的微服务架构：

SpringCloud Alibaba中使用Alibaba Nacos组件实现注册中心，Nacos提供了一组简单易用的特性集，可快速实现动态服务发现、服务配置、服务元数据及流量管理。
SpringCloud Alibaba 使用Nacos服务端均衡实现负载均衡，与Ribbon在调用端负载不同，Nacos是在服务发现的同时利用负载均衡返回服务节点数据。
SpringCloud Alibaba 使用Netflix Feign和Alibaba Dubbo组件来实现服务通行，前者与SpringCloud采用了相同的方案，后者则是对自家的RPC 框架Dubbo也给予支持，为服务间通信提供另一种选择。
SpringCloud Alibaba 在API服务网关组件中，使用与SpringCloud相同的组件，即：SpringCloud Gateway。
SpringCloud Alibaba在配置中心组件中使用Nacos内置配置中心，Nacos内置的配置中心，可将配置信息存储保存在指定数据库中
SpringCloud Alibaba在原有的ELK方案外，还可以使用阿里云日志服务（LOG）实现日志集中式管理。
SpringCloud Alibaba在分布式链路组件中采用与SpringCloud相同的方案，即：Sleuth/Zipkin Server。
SpringCloud Alibaba使用Alibaba Sentinel实现系统保护，Sentinel不仅功能更强大，实现系统保护比Hystrix更优雅，而且还拥有更好的UI界面。

SpringCloud核心组件

Eureka

Eureka 是Netflix 开发的服务注册发现框架，SpringCloud 将它集成在自己的子项目spring-cloud-netflix 中，实现SpringCLoud 的服务注册。

Eureka Client 是一个Java客户端，用于简化与Eureka Server 的交互。

Eureka Server 提供服务发现能力，各个微服务启动时，会通过Eureka Client 向Eureka Server 进行注册自己的信息，Eureka Server 会存储该服务的信息。

微服务启动后，会周期性地向Eureka Server 发送心跳（默认周期是30秒）以续约自己的信息。如果Eureka Server 在一定时间内没有收到某个微服务心跳节点，Eureka Server 将会注销该服务节点（默认为90秒）。

Eurek如何实现高可用？

通过集群的方式，每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的方式完成服务注册表的同步，从而确保节点中数据一致。

另外，Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者。

Eureka的自我保护模式

默认情况下，如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时本不应该注销这个微服务。

Eureka通过“自我保护模式”来解决这个问题——当Eureka Server节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，Eureka Server就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。

综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。

Eureka和ZooKeeper的区别

Eureka满足可用性，Zookeeper满足一致性：

Zookeeper要求各个服务之间同步完成之后才会返回给用户结果，如果服务出现网络波动导致监听不到心跳，会立即从服务列表中剔除，服务不可用。
Eureka如果遇到网络故障，基于Eureka的自我保护机制，不会立即剔除服务，虽然用户获取的服务不一定是可用的，但是至少可以获取到服务列表。用户访问服务列表后还可以利用重试机制，找到正确的服务。更符合分布式服务高可用的要求。

Eureka集群节点间相互平等，Zookeeper有主从之分：

如果Zookeeper集群中有服务宕机，会重新基于选举机制选出新的主节点，因此可能会导致整个集群因为选主而阻塞，服务不可用。
Eureka集群有服务宕机，因为各个节点之间是平等的，其他服务器不受影响。

Eureka中服务发现者是去主动地拉取服务，Zookeeper服务发现者是基于监听机制：

Eureka中获取服务列表后会缓存起来，每隔30秒重新拉取服务列表。
Zookeeper是监听节点的信息变化，当服务节点信息发生变化的时候，客户端立即收到通知。

Ribbon

Ribbon是Spring Cloud Netflix组件中一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。当多个服务提供者时，Ribbon可以根据负载均衡的算法，比如：简单轮询、随机连接等，自动地选择需要调用的服务地址。

Ribbon与Nginx的区别

Nginx是服务端的负载均衡，都是先发送请求，然后在服务器端再进行负载均衡算法分配。

Ribbon是客户端的负载均衡，负载均衡逻辑集成到消费方客户端。消费方从服务注册中心获取服务地址列表，在发送请求前通过负载均衡算法选择一个服务器，然后进行方访问。

Feign

Feign 是一个服务调用的组件，用来实现两个服务之间的相互调用。

Feign是一个声明式的Web服务客户端，让编写Web服务客户端变得非常容易，只需创建一个接口并在接口上申明注解，使用起来比传统的RestTemplate 更加简单。

Ribbon和Feign调用服务的区别

Ribbon：

Ribbon 是 Netflix开源的基于HTTP和TCP等协议负载均衡组件。
Ribbon 可以用来做客户端负载均衡，调用注册中心的服务。
Ribbon的使用需要代码里手动调用目标服务。

Feign：

Feign是Spring Cloud组件中的一个轻量级RESTful的HTTP服务客户端。
Feign内置了Ribbon，用来做客户端负载均衡，去调用服务注册中心的服务。
Feign的使用方式是：使用Feign的注解定义接口，调用这个接口，就可以调用服务注册中心的服务。

Hystrix

断路器

在微服务架构中，服务之间形成调用链路，链路中的任何一个服务提供者都可能面临着相应超时、宕机等不可用的情况，在高并发的情况下，这种情况会随着并发量的上升恶化，形成“雪崩效应”，而断路器正是用来解决这一个问题的组件。

断路器基本原理为：

正常情况下，断路器关闭，服务消费者正常请求微服务
一段事件内，失败率达到一定阈值（比如50%失败，或者失败了50次），断路器将断开，此时不再请求服务提供者，而是只是快速失败的方法（断路方法）
断路器打开一段时间，自动进入“半开”状态，此时，断路器可允许一个请求方法服务提供者，如果请求调用成功，则关闭断路器，否则继续保持断路器打开状态。

断路器保证了局部发生的错误，不会扩展到整个系统，从而保证系统的即使出现局部问题也不会造成系统雪崩。

什么是 Hystrix？

Hystrix是断路器的落地实现，防雪崩利器，具有服务降级，服务熔断，服务隔离，服务监控等功能。

服务降级：对于查询操作, 可以实现一个fallback方法, 当请求下游服务出现异常的时候, 使用fallback方法返回的值，fallback方法的返回值一般是设置的默认值或者来自缓存。

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

服务隔离：通过线程池（或信号量）来实现资源隔离，通常在使用的时候我们会根据调用的下游服务划分出多个线程池。例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池，这样做的主要优点是运行环境被隔离开了。这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响。

服务监控：将服务执行结果和运行指标，请求数量成功数量等等这些状态进行收集，然后即可看到实时的监控数据。

微服务雪崩效应

在微服务架构中，⼀个应⽤可能会有多个微服务组成，微服务之间的数据交互通过远程过程调⽤完成。

假设微服务A调⽤微服务B和微服务C，微服务B和微服务C⼜调⽤其它的微服务，如果在调用链路上某个微服务的调⽤响应时间过⻓或者不可⽤，对微服务A的调⽤就会占⽤越来越多的系统资源，进⽽引起系统崩溃，所谓的“雪崩效应”。

Zuul & Gateway

Zuul

Zuul微服务网关是为Spring Cloud Netflix提供认证鉴权、监控、动态路由、限流、压力测试等服务的框架，可以和Eureka、Ribbon、Hystrix等组件配合使用。

主要功能：

认证鉴权：识别每个资源的验证要求，并拒绝那些与要求不符的请求。
监控：追踪有意义的数据和统计结果，带来精确的生产视图。
动态路由：动态地将请求路由到不同的后端集群。
限流：为每一种负载类型分配对应容量，并弃用超出限定值的请求。
压力测试：逐渐增加指向集群的流量，以了解性能。

Spring Cloud Gateway 即Spring官方推出的一款API网关，该框架包含了Spring5.0、SpringBoot2.0、Project Reactor，其中底层通信框架用的Netty。

Gateway

Spring Cloud Gateway在推出之初的时候，Netflix公司已经推出了类似功能的API网关框架Zuul，但Zuul有一个缺点是通信方式是阻塞的，虽然后来升级到了非阻塞式的Zuul2，但是由于Spring Cloud Gateway已经推出一段时间，同时自身也面临资料少、维护性较差的因素没有被广泛应用。

在功能上，Spring Cloud Gateway与Zuul相差不大。

Config

Spring Cloud Config为分布式系统外部化配置提供了服务器端和客户端的支持，包括Config Server和Config Client两部分。Config Server是一个可横向扩展、集中式的配置服务器，它用于集中管理应用程序各个环境下的配置，默认使用Git存储配置内容，因此可以很方便地实现对配置的版本控制。

Config Client是Config Server的客户端，用于操作存储在Config Server中的配置属性。

负载均衡有哪些算法？

简单轮询：将请求按顺序分发给后端服务器上，不关心服务器当前的状态，比如后端服务器的性能、当前的负载。
加权轮询：根据服务器自身的性能给服务器设置不同的权重，将请求按顺序和权重分发给后端服务器，可以让性能高的机器处理更多的请求
简单随机：将请求随机分发给后端服务器上，请求越多，各个服务器接收到的请求越平均
加权随机：根据服务器自身的性能给服务器设置不同的权重，将请求按各个服务器的权重随机分发给后端服务器
一致性哈希：根据请求的客户端 ip、或请求参数通过哈希算法得到一个数值，利用该数值取模映射出对应的后端服务器，这样能保证同一个客户端或相同参数的请求每次都使用同一台服务器
最小活跃数：统计每台服务器上当前正在处理的请求数，也就是请求活跃数，将请求分发给活跃数最少的后台服务器

如何实现一直均衡给一个用户？

可以通过「一致性哈希算法」来实现，根据请求的客户端 ip、或请求参数通过哈希算法得到一个数值，利用该数值取模映射出对应的后端服务器，这样能保证同一个客户端或相同参数的请求每次都使用同一台服务器。

服务熔断

服务熔断是应对微服务雪崩效应的一种链路保护机制，类似股市、保险丝。

比如说，微服务之间的数据交互是通过远程调用来完成的。服务A调用服务，服务B调用服务c，某一时间链路上对服务C的调用响应时间过长或者服务C不可用，随着时间的增长，对服务C的调用也越来越多，然后服务C崩溃了，但是链路调用还在，对服务B的调用也在持续增多，然后服务B崩溃，随之A也崩溃，导致雪崩效应。

服务熔断是应对雪崩效应的一种微服务链路保护机制。例如在高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似的作用。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

所以，服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。

服务降级

服务降级一般是指在服务器压力剧增的时候，根据实际业务使用情况以及流量，对一些服务和页面有策略的不处理或者用一种简单的方式进行处理，从而释放服务器资源的资源以保证核心业务的正常高效运行。

服务器的资源是有限的，而请求是无限的。在用户使用即并发高峰期，会影响整体服务的性能，严重的话会导致宕机，以至于某些重要服务不可用。故高峰期为了保证核心功能服务的可用性，就需要对某些服务降级处理。可以理解为舍小保大

服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

微服务之间如何交互？

微服务架构是一种分布式软件设计模式，它将大型应用程序拆分为一组小型服务，每个服务都运行在自己的进程中，并使用轻量级通信机制（如HTTP API）进行通信。

微服务之间的交互通常通过以下几种方式进行：

RESTful API：

这是微服务之间最常见的交互方式。每个微服务都暴露一组RESTful API，供其他微服务调用。
HTTP（HyperText Transfer Protocol）或HTTPS是传输协议的首选，因为它基于开放的标准，可以在多种平台和编程语言中使用。
JSON（JavaScript Object Notation）或XML（eXtensible Markup Language）通常用作数据交换的格式。

gRPC：

gRPC是一个高性能、开源、通用的远程过程调用（RPC）框架，它面向移动和HTTP/2设计。
gRPC使用Protocol Buffers（protobuf）作为接口定义语言（IDL），允许开发者定义服务接口和消息类型，然后可以生成客户端和服务端的代码。
gRPC支持多种编程语言，并且具有比HTTP/REST更低的延迟和更高的吞吐量。

消息队列（如RabbitMQ, Apache Kafka等）：