SpringCloud | 第一篇：基础知识介绍

---

SpringCloud简介

Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小的服务，每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）,每个服务都围绕着具体的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。另外，应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

SpringCloud和Spring Cloud Alibaba组件分类

Spring Cloud 是基于 Spring Framework 的生态系统，提供了一套完整的解决方案，用于构建分布式系统中的微服务架构。它包含了众多的子项目和组件，如服务注册与发现（Eureka、Consul、ZooKeeper）、负载均衡（Ribbon、LoadBalancer）、断路器（Hystrix）、网关（Zuul、Gateway）、配置中心（Config）、消息总线（Bus）等。Spring Cloud 使用 Spring Boot 来简化微服务的开发和部署，提供了对应的功能模块和集成方式。

Spring Cloud Alibaba 是在 Spring Cloud 的基础上，结合阿里巴巴的中间件技术，提供了更多的分布式解决方案。它包括了众多的子项目和组件，如服务注册与发现（Nacos）、分布式配置管理（Nacos Config）、消息驱动（RocketMQ）、分布式事务（Seata）、限流降级（Sentinel）等。

微服务远程调用：

• Dubbo
• Feign、Open Feign

服务注册与发现（注册中心）：

• Eureka
• Zookeeper
• Nacos
• Consul

配置中心：

• SpringcloudConfig
• Nacos

负载均衡：

• Ribbon

API网关：

• SpringCloudGateway
• Zuul

服务链路监控：

• Zipkin
• Sleuth

流量监控、熔断降级：

• Hystrix

分布式事务

• Seata

Eureka VS Nacos

Eureka和Nacos都能起到注册中心的作用，用法基本类似。但Nacos支持配置管理，而Eureka则不支持。

服务注册发现上，Eureka和Nacos的健康检测机制的原理如下：

• 微服务启动时注册信息到Eureka，这点与Nacos一致。
• 微服务每隔30秒向Eureka发送心跳请求，报告自己的健康状态。Nacos中默认是5秒一次。
• Eureka如果90秒未收到心跳，则认为服务疑似故障，可能被剔除。Nacos中则是15秒超时，30秒剔除。
• Eureka如果发现超过85%比例的服务都心跳异常，会认为是自己的网络异常，暂停剔除服务的功能。
• Eureka每隔60秒执行一次服务检测和清理任务；Nacos是每隔5秒执行一次。

综上，你会发现Eureka是尽量不剔除服务，避免“误杀”，宁可放过一千，也不错杀一个。这就导致当服务真的出现故障时，迟迟不会被剔除，给服务的调用者带来困扰。

不仅如此，当Eureka发现服务宕机并从服务列表中剔除以后，并不会将服务列表的变更消息推送给所有微服务。而是等待微服务自己来拉取时发现服务列表的变化。而微服务每隔30秒才会去Eureka更新一次服务列表，进一步推迟了服务宕机时被发现的时间。

而Nacos中微服务除了自己定时去Nacos中拉取服务列表以外，Nacos还会在服务列表变更时主动推送最新的服务列表给所有的订阅者。

Eureka VS Zookeeper

Zookeeper保证了CP（C：一致性，P：分区容错性），Eureka保证了AP（A：高可用）。

当向注册中心查询服务列表时，可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接down掉不可用。

因此，服务注册功能对高可用性要求比较高，但Zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集群都不可用，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。

Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生连接失败，则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么Eureka就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况：
① Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
② Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）
③ 当网络稳定时，当前实例新的注册信息会被同步到其他节点。

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个微服务瘫痪

CAP理论和BASE思想

CAP理论

• Consistency(一致性)
• Availability(可用性)
• Partition tolerance(分区容错性)

Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。

• 最终一致性

Availability （可用性）：用户访问分布式系统时，读或写操作总能成功。

• 高可用：
• 弱可用：只能读不能写，或者只能写不能读。
• 不可用：两者都不能执行。

Partition Tolerance（分区容错）：就是当分布式系统节点之间出现网络故障导致节点之间无法通信的情况，即便是系统出现网络分区，整个系统也要持续对外提供服务。

在分布式系统中，网络不能100%保证畅通，也就是说网络分区的情况一定会存在。而我们的系统必须要持续运行，对外提供服务。所以分区容错性（P）是硬性指标，所有分布式系统都要满足。而在设计分布式系统时要取舍的就是一致性（C）和可用性（A）了。

假如现在出现了网络分区，由于网络故障，当我们把数据写入node01时，可以与node02完成数据同步，但是无法同步给node03。

现在有两种选择：

• 允许用户任意读写，保证可用性。但由于node03无法完成同步，就会出现数据不一致的情况。满足AP
• 不允许用户写，可以读，直到网络恢复，分区消失。这样就确保了一致性，但牺牲了可用性。满足CP

可见，在分布式系统中，A和C之间只能满足一个。

BASE思想

• Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
• Soft State**（软状态）：**在一定时间内，允许出现中间状态，比如临时的不一致状态。
• Eventually Consistent**（最终一致性）**：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

简单来说，BASE理论就是一种取舍的方案，不再追求完美，而是最终达成目标。因此解决分布式事务的思想也是这样，有两个方向：

• AP思想：各个子事务分别执行和提交，无需锁定数据。允许出现结果不一致，然后采用弥补措施恢复，实现最终一致即可。例如AT模式就是如此
• CP思想：各个子事务执行后不要提交，而是等待彼此结果，然后同时提交或回滚。在这个过程中锁定资源，不允许其它人访问，数据处于不可用状态，但能保证一致性。例如XA模式