python nacos注册中心_Nacos作为注册中心，配置中心部署方案

作者:程老师，从事java开发领域5年，对spring开发框架，中间件，数据库优化都有很深的造诣。现今打破了传统模式的限制，专注于PYTHON自动化领域，并献上一篇文章供大家欣赏。座右铭：“不要局限于自身，只有你想不到的，没有你做不到的。如果做不到，那就换个思路一定能做到！！！”。

摘要:Nacos是以服务为主要服务对象的中间件，Nacos支持所有主流的服务发现、配置和管理。

Nacos主要提供服务发现与服务健康检查,动态配置管理,动态DNS服务,服务和元数据管理四大功能。

一、前言

服务注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务的分布式属性决定的。更进一步，为了支持弹性扩缩容特性，一个微服务的提供者的数量和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用已经不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。

二、CAP理论

CAP理论是分布式架构中重要理论

l一致性(Consistency) (所有节点在同一时间具有相同的数据)

l可用性(Availability) (保证每个请求不管成功或者失败都有响应)

l分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

三、注册中心产品

1.Zookeeper -> CP

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。

从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用(例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了)，那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。

2.Spring Cloud Eureka  -> AP

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则(尽管现在2.0发布了，但是由于其闭源的原因 ，但是目前 Ereka 1.x 任然是比较活跃的)。

Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制(replicate To Peer)操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。

当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。

默认情况下，如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳(默认周期为30秒)，Eureka Server 将会注销该实例(默认为90秒， eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置)。

当 Eureka Server 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。

Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1)Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；

2)Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)；

3)当网络稳定时，当前实例新注册的信息会被同步到其它节点中；

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

3.Nacos

Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。在Spring Cloud中使用Nacos，只需要先下载 Nacos 并启动 Nacos server，Nacos只需要简单的配置就可以完成服务的注册发现。

Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

Nacos主要提供以下四大功能：

服务发现与服务健康检查：Nacos使服务更容易注册自己并通过DNS或HTTP接口发现其他服务。Nacos还提供服务的实时健康检查，以防止向不健康的主机或服务实例发送请求。

动态配置管理：动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新部署应用程序和服务的需要，这使配置更改更加高效和灵活。

动态DNS服务：Nacos支持加权路由，使您可以更轻松地在数据中心的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务。它可以帮助您轻松实现基于DNS的服务发现，并防止应用程序耦合到特定于供应商的服务发现API。

服务和元数据管理：Nacos提供易于使用的服务仪表板，可帮助您管理服务元数据，配置，kubernetes DNS，服务运行状况和指标统计。

Nacos = Spring Cloud注册中心 + Spring Cloud配置中心。

4.注册中心对比

1)Nacos相对于zookeeper 与Eureka 同时支持AP和CP模式,他根据服务注册选择临时和永久来决定走AP模式还是CP模式；

2)Nacos不单一的是注册中心也是配置中心。

3)相对于zookeeper集群中的leader宕机场景下，虽然不影响服务使用，但是需要重新选举leader耗时30s-120s，在这期间无法进行服务注册，但是nacos集群leader宕机并不会影响服务注册，重新选举leader只需要4s-5s。

4)Nacos既可以与SpringCloud集成，也可以与Dubbo集成，解决了以往的zookeeper只能与Dubbo集成，Eureka 只能与SpringCloud集成问题。

5)Nacos可以与K8S集成，这一点Eureka 与zookeeper暂时还无法做到。

四、Nacos集群部署

由于资源问题本人使用的伪集群模式，一个虚拟机三个端口配置

Ø下载服务

Ø配置服务

[weblogic@cde04199-130 nacos0]$ cd /nacos/nacos0/conf/

[weblogic@cde04199-130 conf]$ vi cluster.conf

Ø启动

cd  /nacos/nacos0/bin

./startup.sh -m cluser

启动成功：

其他服务同样方式启动

Ø服务注册

curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=nacos.naming.serviceName&ip=20.18.7.10&port=8080'

Ø服务发现

curl -X GET 'http://127.0.0.1:8848/nacos/v1/ns/instance/list?serviceName=nacos.naming.serviceName'

1.Nacos替代与Dubbo集成示例

配置原有applicationContext-dubbo.xml文件

将注册中心调整成nacos中心

启动服务注册：

消费服务：