Nacos（替代Eureka）注册中心

Nacos初步学习

Nacos 是一个开源的服务注册和配置中心，它允许您注册、注销和发现服务实例，并提供了配置管理的功能。下面是Nacos的最基础用法：

1. 服务注册和发现：

首先，您需要将您的应用程序或服务注册到Nacos中。这可以通过配置应用程序的Nacos客户端来完成。通常，您需要提供服务的名称、主机名和端口等信息，以便其他应用程序可以发现并访问您的服务。

# Nacos注册配置示例
spring:
  application:
    name: my-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848

然后，其他应用程序可以使用Nacos的客户端来发现并访问您的服务。这允许了动态的、基于服务的通信

@Service
public class MyService {
    @Autowired
    private DiscoveryClient discoveryClient;

    public String discoverService() {
        List<ServiceInstance> instances = discoveryClient.getInstances("my-service");
        if (instances.isEmpty()) {
            return "No service instances available.";
        }
        // 选择一个服务实例并进行通信
        ServiceInstance serviceInstance = instances.get(0);
        String serviceUrl = serviceInstance.getUri().toString();
        // 发送请求到服务
        // ...
        return "Response from service: " + serviceUrl;
    }
}

2. 配置管理：

Nacos还允许您将配置信息存储在其配置中心中，以便动态管理和更新配置。您可以将配置信息存储在Nacos中，并在需要时在应用程序中获取和使用它。

# Nacos配置示例
spring:
  cloud:
    nacos:
      config:
        server-addr: localhost:8848
        namespace: your-namespace
        group: your-group

然后，您可以使用Nacos的配置客户端来获取配置信息。

@RefreshScope
@RestController
public class MyController {
    @Value("${my.property}")
    private String myProperty;

    @GetMapping("/getMyProperty")
    public String getMyProperty() {
        return "My Property: " + myProperty;
    }
}

3.分级存储模型

与Eureka区别

在生产者-消费者-注册中心模型中，nacos对生产者的非临时实例会主动询问，对消费者的主动推送消息，
采用临时实例时，nacos和Eureka都是遵循AP原则；采用非临时实例时，nacos遵循CP原则

CAP原则

CAP 原则，又称 CAP 定理，是分布式计算领域的一个重要原则，它描述了在分布式系统中三个核心特性之间的权衡关系。这三个特性分别是一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance）。CAP 原则指出，在一个分布式系统中，不能同时满足这三个特性，只能在它们之间进行权衡选择。以下是对 CAP 原则各个部分的详细解释：

一致性（Consistency）：

一致性要求在分布式系统的所有节点上，对于同一个数据操作的结果必须是一致的。也就是说，如果一个节点在某个时刻对数据进行了修改，那么其他节点在后续读取该数据时应该看到修改后的值。
一致性强调数据的强一致性，即任何时间点都能读取到最新的数据，但这可能需要在分布式系统中增加通信和延迟。
可用性（Availability）：

可用性要求分布式系统在任何时刻都应该对客户端请求做出响应，即系统能够提供服务。
可用性强调系统的可靠性和可访问性，不管是否有节点出现故障或网络问题，系统都应该继续提供服务。
分区容忍性（Partition Tolerance）：

分区容忍性要求分布式系统能够在网络分区或通信故障的情况下继续运行。分区指的是将网络划分为多个不连通的子网络，其中一些子网络之间可能出现通信故障。
分区容忍性强调系统能够处理网络故障和节点之间的通信问题，确保系统的稳定性。
根据 CAP 原则，分布式系统只能在一致性、可用性和分区容忍性中选择两个，无法同时满足所有三个。这被称为 CAP 原则的三角权衡。具体来说：

如果系统追求强一致性和可用性，那么在分区发生时，系统可能会停止响应请求。这种情况下，系统会牺牲分区容忍性。
如果系统追求分区容忍性和可用性，那么系统可能会在某些情况下返回不一致的数据，即牺牲了一致性。
如果系统追求一致性和分区容忍性，那么在分区发生时，系统可能会牺牲可用性，即暂时停止对请求的响应，直到分区问题解决。

分区容忍性（Partition Tolerance）和可用性（Availability）确实都涉及系统在面对问题时继续提供服务，但它们关注的方面略有不同，可以通过以下方式进行区分：

分区容忍性：

**分区容忍性关注的是系统在面对网络分区（Partition）或通信故障时的能力。**分区指的是将网络划分为多个不连通的子网络，其中一些子网络之间可能出现通信故障。
分区容忍性强调系统能够在分区发生时继续运行，即使部分节点无法与其他节点通信。它确保了系统在分区情况下不会因为通信问题而完全停止工作。
分区容忍性通常考虑了分布式系统中的网络延迟、丢包以及节点之间的通信失败。
可用性：

可用性关注的是系统在任何时刻都能够对客户端请求做出响应，即系统能够提供服务。
可用性强调系统的可靠性和可访问性，确保即使没有发生网络分区，系统仍然能够正常运行，不会出现长时间的不可用情况。
可用性通常考虑了系统的健康状况、硬件故障、软件错误以及其他可能导致系统停止响应的问题。