注册中心nacos与Eureka 选型

1.Nacos 的功能

1.1 服务注册及健康检查

       Nacos支持基于DNS和基于RPC的服务发现，服务端可以通过SDK或者Api进行服务注册，相应的服务消费者可以使用DNS或者Http查找的方式获取服务列表。 Nacos同时提供对服务的实时健康检查，阻止想不健康的主机或服务发送请求，有友好的控制台页面。

1.2 动态配置服务

       此功能类似于springcloud Config 功能，管理配置文件。Nacos支持动态的配置管理，将服务的配置信息分环境分类别外部管理，并且支持热更新。不过与Config不同Nacos的配置信息存储与数据库中，支持配置信息的监听和版本回滚。

1.3 动态DNS 服务

       支持权重路由，更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。

       不过目前nacos的 服务调用更多的采用Feign方式，而Feign整合的是Ribbon实现的客户端负载均衡，Ribbon内置的负载均衡策略暂不支持nacos的权重来实现负载均衡，需要自定义负载均衡策略。

2. Nacos整合springboot 配置中心及服务注册中心

     详见链接：springboot 整合nacos 配置及注册中心完整版_策码狂奔的博客-CSDN博客

  2.1 关于配置中心的环境隔离

             Nacos 有两个 属性是用于管理区分不同环境的配置文件的，分别是 namespace 和 Group

       个人理解，即是采用namespace和Group的排列组合来区分不同环境的配置

       项目bootstrap 配置文件中需添加如下配置项：

     #nacos 配置中心

     spring.cloud.nacos.config.namespace=${namespaceId}

     spring.cloud.nacos.config.group=${groupName}

     #nacos 注册中心

     spring.cloud.nacos.discovery.namespace=${namespaceId}

     spring.cloud.nacos.discovery.group=${groupName}

   注意： 当前nacos仍不支持服务注册的Group分组服务，只可用namespace区分注册服务

    

2.2  关于服务注册中心服务调用的Ribbon负载均衡策略

          详见链接  springCloud alibaba nacos服务中心使用Ribbon 作为负载均衡详解_策码狂奔的博客-CSDN博客_nacos 配置ribbon.connecttimeout

   

       Ribbon 还可自定义支持Nacos实例权重的负载均衡策略，Nacos控制台页面可设置多实例的权重，权重值越大，越高概率调用到该实例服务

3. Nacos 与springcloud Eureka 对比

      4.1 CAP 原则简介：

            CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分 区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

     

     一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

     可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

     分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

    3.2 Raft 算法概念：

      raft是一个共识算法（consensus algorithm），所谓共识，就是多个节点对某个事情达成一致的看法，即使是在部分节点故障、网络延时、网络分割的情况下。这些年最为火热的加密货币（比特币、区块链）就需要共识算法，而在分布式系统中，共识算法更多用于提高系统的容错性

      3.3 Nacos与Eureka 对比

   Tips:  Nacos 默认满足的原则是AP原则，如需切换：

curl -X PUT '$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

相比与Eureka：

(1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。

(2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护

(3)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。

(4)Nacos 集群有主从节点之分，通过心跳机制进行同步；Eureka 集群没有主从之分，服务注册有延时

(5)Nacos 官方是宣布秒级上下线的，而Eureka是有注册延迟的

当Nacos使用Feign 调用服务，即使服务下线，可能仍可调用：

由于Feign整合了Ribbon，Ribbon的服务列表加载机制是定时的，所有服务下线也可能会导致更新不及时，仍可以用被调用。

阿里nacos异常情况 leader挂了：

   1.不影响服务之间互相调用

    2.不影响服务注册

    3.不影响服务正常启动拉取配置文件

    4.选举新leader差不多4,5秒钟

     5.Nacos 临时服务实例健康检查方式(client)

        Nacos AP 模式仅支持服务注册临时实例，使用心跳上报方式维持活性，发送心跳的周期默认是 5 秒，Nacos 服务端会在 15 秒没收到心跳后将实例设置为不健康，在 30 秒没收到心跳时将这个临时实例摘除。