微服务——注册中心

常见的注册中心：eureka、nacos、zookeeper

服务注册和发现是什么意思？Spring Cloud是如何实现服务注册发现？

服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、IP、端口等

服务发现：消费者向eureka拉取服务列表信息，如果服务者有集群，则消费者会利用负载均衡算法，选择一个发起调用

服务监控：服务提供者会每隔30秒向eureka发送心跳，如果eureka服务90秒没接收到心跳，从eureka中剔除

Nacos、Eureka和Zookeeper的区别

设计哲学与 CAP 取舍：

• Eureka是AP的极致体现，为了可用性可以容忍数据不一致，非常适合构建弹性、可扩展的微服务系统
• Zookeeper是CP的代表，提供强一致性保证，是分布式协调领域的基石，但在某些网络分区场景下可能会牺牲可用性
• Nacos是兼具AP和CP的能力，允许用户根据业务场景(通过选择临时/非临时实例)灵活切换，是更通用更强大的解决方案

功能范畴：

• Eureka更为功能纯粹，就是服务发现
• ZooKeeper功能更底层，服务发现只是其分布式协调能力的一个应用
• Nacos的功能更全面，集成了服务发现 + 配置中心，并提供了丰富的服务治理能力，一站式解决了微服务架构中的多个核心问题

服务健康检查与列表判断

• Eureka是用客户心跳 + 客户端定时拉取的模式，简单但是存在延迟
• ZooKeeper采用客户端Session机制+Watcher推模式，实时性高，但Watcher频繁触发会导致性能压力
• Nacos结合了推(主动推送)和拉(定时拉取)的优点，并提供了更灵活的健康检查方式(心跳/主动探测)，在实时性和可靠性之间取得了很好的平衡

特性	Nacos	Eureka	ZooKeeper
核心定位	动态服务发现、配置管理和服务管理平台	专为 AWS 设计的服务发现组件	分布式协调服务（分布式锁、配置管理等）
CAP 理论	默认 AP（高可用优先）当集群中存在非临时实例时，自动切换为 CP（一致性优先）	AP（高可用优先）强调可用性和分区容错性，牺牲部分一致性	CP（一致性优先）强调强一致性和分区容错性，牺牲部分可用性
服务健康检测	1. 临时实例：客户端心跳上报（默认）。2. 非临时实例：服务端主动探测。	客户端心跳上报。服务端定时检查心跳，超时未上报则剔除服务。	1. 客户端定时发送 PING 包。2. 服务端检测到客户端失联（Session 超时），会主动剔除该服务。
服务列表更新机制	1. 推模式为主：服务状态变化时，服务端主动推送变更给客户端。2. 客户端也可定时拉取，更新更及时。	拉模式：客户端定时（默认 30 秒）从服务端拉取服务列表。存在一定的更新延迟。	推模式：服务状态变化时，通过 Watcher 机制主动通知客户端。更新及时。
服务剔除策略	1. 临时实例：心跳超时后剔除。2. 非临时实例：不会被剔除，需手动下线。	心跳超时后，服务端将服务标记为 DOWN，并在一定时间后剔除。	客户端 Session 超时后，服务端立即剔除该服务。
其他核心功能	配置中心：支持动态配置管理。服务路由、负载均衡、服务限流等。	仅提供服务发现功能，生态依赖 Spring Cloud 其他组件（如 Ribbon 做负载均衡）。	分布式锁、选举机制、数据发布 / 订阅等。
适用场景	1. 微服务架构中既要服务发现，又要配置管理的场景。2. 对可用性和一致性都有要求，希望灵活切换的场景。	1. 纯服务发现场景，对配置管理无需求。2. 对可用性要求极高，可接受短期数据不一致的场景。	1. 需要强一致性的分布式协调场景（如分布式事务、主从选举）。2. 对服务发现的实时性和一致性要求极高的场景。
典型生态	Spring Cloud Alibaba	Spring Cloud Netflix	Dubbo、Hadoop、Kafka 等

CAP理论

在一个分布式系统中，一致性（Consistency）、可用性（Availability） 和分区容错性（Partition Tolerance） 这三个特性无法同时被完全满足，最多只能同时满足其中两个。

特性	一致性 (C)	可用性 (A)	分区容错性 (P)
核心关注点	数据的正确性和统一性	系统的正常运行和响应能力	系统在网络故障下的生存能力
通俗说法	大家看到的数据都一样	系统随时都能正常工作	网络断了系统也不能崩
典型应用	银行转账、股票交易	社交软件、电商网站	所有分布式系统都必须考虑

三者之间的权衡

CAP 理论的核心在于 “权衡”。在实际的分布式系统设计中，由于网络故障是不可避免的，因此分区容错性（P）通常是必须要保证的。在这种情况下，我们就需要在一致性（C）和可用性（A） 之间做出选择：

• 选择 CP（一致性 + 分区容错性）
  • 适用场景：对数据一致性要求极高的场景，例如金融交易、分布式数据库等。
  • 特点：当网络分区发生时，为了保证数据的一致性，系统可能会暂时牺牲部分可用性。例如，在上面的银行转账例子中，如果北京和上海的网络中断了，为了防止出现 “重复转账” 或 “余额不一致” 的情况，系统可能会暂时冻结涉及跨地域的转账业务，直到网络恢复。
  • 代表技术：ZooKeeper、Consul（默认 CP 模式）。
• 选择 AP（可用性 + 分区容错性）
  • 适用场景：对系统可用性要求极高，而数据一致性可以接受短暂延迟的场景，例如社交网络、电商网站、微服务注册中心等。
  • 特点：当网络分区发生时，系统会优先保证可用性，允许不同分区的数据暂时不一致，但会在网络恢复后，通过一定的机制（如异步复制）将数据同步到一致状态。例如，在社交网络上，你发布了一条朋友圈，可能你的好友不会立即看到，但过了几秒钟或一分钟后，他们肯定能看到。
  • 代表技术：Eureka、Nacos（默认 AP 模式）。

BASE理论

是对CAP的一种解决思路，包含三个思想：

Basically Available(基本可用)：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用

Soft stats(软状态)：在一定时间内，允许出现中间状态，比如临时的不一致状态

Eventually Consistsnt(最终一致性)：虽然无法保证强一致性，但是在软状态后，最终达成一致性

解决分布式事务的思想和模型：

最终一致性：各分支事务分别提交，如果有不一致的情况，再想办法恢复数据(AP)

强一致性：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚(CP)