SpringCloud笔记

什么是降级熔断？为什么要进行熔断？

熔断降级是一种分布式系统的保护机制，用于应对服务不稳定或不可用的情况。
熔断是指当某个服务的调用失败次数或异常比例达到一定阈值时，自动切断对该服务的调用，让请求快速失败，避免影响其他服务而导致雪崩效应。熔断后，一段时间内不再调用该服务，直到服务恢复正常或者超过最大等待时间。
降级是指当某个服务不可用或响应缓慢时，提供一个备用的处理逻辑，例如返回默认值、缓存值、错误提示等，以保证服务的可用性和容错性。降级可以在熔断时触发，也可以在其他情况下触发，例如系统负载过高、资源紧张等。
熔断降级的目的是为了保护系统的稳定性和可用性，防止故障扩散和蔓延，提高用户体验和信任度。

什么是Seata？谈谈你对Seata的理解

Seata是一款开源的分布式事务解决方案，它主要用于解决在分布式系统中全局事务的一致性问题。
在分布式系统中，由于一次业务操作需要跨多个数据源或进行远程调用，往往会产生分布式事务问题。例如，在一个电商微服务系统中，订单服务和库存服务需要协同工作，如果订单服务已经创建成功，但库存服务因为某些原因失败了，就会导致数据不一致的问题。Seata就是为解决这个问题而产生的。
Seata的主要特点是无侵入以及高性能。它对业务无侵入，可以减少技术架构上的微服务化所带来的分布式事务问题对业务的侵入，同时高性能则是减少分布式事务解决方案所带来的性能消耗。
在Seata的事务处理中主要有三个重要的角色：事务的协调者（TC）、事务的管理者（TM）和事务的作业管理器（RM）。
●事务协调者（TC）主要负责管理全局的分支事务的状态，用于全局性事务的提交和回滚。它会对所有的分支事务进行注册，然后根据各个分支事务的状态来决定是否提交或者回滚全局事务。
●事务管理者（TM）用于开启、提交或回滚事务。它会根据业务逻辑来决定何时开启一个新的事务，并在适当的时候提交或回滚该事务。
●资源管理器（RM）用于分支事务上的资源管理，向TC注册分支事务，上报分支事务的状态，接收TC的命令来提交或者回滚分支事务。

Nacos、Eureka、Zookeeper注册中心的区别

Nacos、Eureka和Zookeeper都是常用的注册中心，它们在功能和实现方式上存在一些不同。
●Nacos除了作为注册中心外，还提供了配置管理、服务发现和事件通知等功能。Nacos默认情况下采用AP架构保证服务可用性，CP架构底层采用Raft协议保证数据的一致性。Nacos适合作为微服务注册中心和配置管理中心，支持快速发现、配置管理和服务治理等功能。
●Eureka是只提供注册中心功能的工具，它的设计理念是AP，即保证服务的可用性，不保证一致性。Eureka的各个节点之间相互注册，只要有一台Eureka节点存在，整个微服务就可以通讯。
●而Zookeeper相比前两者，除了注册中心的功能，还提供了分布式协调服务，比如通知、公告、配置管理等。Zookeeper采用CP设计，可以保证数据的一致性，但是牺牲了一部分服务的可用性。Zookeeper适用于需要分布式协调服务的场景，如配置管理、命名服务等。

说下Hystrix与Sentinel的区别

Hystrix和Sentinel都是服务熔断器，用于提高分布式系统的弹性。它们的主要区别在于实现方式、适用场景和资源模型设计。
Hystrix基于命令模式设计，将外部资源的调用封装在命令对象中，通过线程池或信号量来实现隔离。它提供了丰富的配置选项，如线程池大小、超时时间等，以实现对系统资源的有力控制。Hystrix更适用于需要高并发、快速响应的场景，因为它可以快速隔离和恢复故障。
Sentinel则基于流量控制和熔断降级的思想，可以与Spring Cloud、gRPC、Dubbo等框架集成。它通过定义资源规则和应用策略来实现对系统资源的控制。Sentinel更适用于需要流量控制和熔断降级的场景，它可以根据系统负载和响应时间来实现自动熔断和降级操作。
总之，Hystrix和Sentinel都是服务熔断器，用于提高系统的弹性。它们在实现方式、适用场景和资源模型设计等方面存在一些不同。具体选择哪个工具取决于系统的具体需求和场景。

单体应用、SOA 和微服务架构有什么区别

单体应用、SOA和微服务架构都是不同的架构风格，适用于不同的情况。
单体应用像一个整体，所有的功能都打包在一个应用中。这种架构风格容易部署和测试，但随着系统规模的扩大，它的灵活性和可维护性会降低。
SOA是一种面向服务的架构风格，将系统划分为多个独立的服务。这些服务可以通过网络调用，并且可以跨平台、跨语言进行交互。SOA的优点是提供了跨系统的服务复用和松散耦合的交互方式，但实现SOA需要投入大量的工作，包括服务的定义、接口的选择、协议的制定等。
微服务架构进一步将系统划分为多个小型、独立的服务，每个服务都是一个单独的应用程序，可以独立部署、运行和扩展。微服务架构具有更高的灵活性和可维护性，适用于复杂的大型系统，强调服务的自治和独立性。但是，实施微服务架构也需要投入大量的工作，包括服务的定义、通信机制的选择、服务的管理等。