架构序列七：了解springcloudalibaba的组件：nacos注册中心吗？

​“架构序列五”、“架构序列六”中，作者已对springcloud如何使用zk和zkui作了详细解释，源码也已上传。

本篇文章旨在换注册中心(zk更换为alibaba的nacos)，市面上现在使用较高 的就是zookeeper，spring cloud config，consul，nacos。

是不是有朋友心里在犯嘀咕，为何作者不说eureka呢？

因为eureka在3月份已经停更了，作者不推荐使用。

spring cloud config更不建议使用，太繁琐了。

consul属于强一致性，可用性降低了，服务注册相对较慢，不推荐。

那为啥作者会推荐使用nacos呢？

具体使用之前，作者先介绍下zk和nacos的对比情况，以方便广大朋友做出正确的选择。

Zookeeper

其实明白一点Zookeeper的功能主要是它的树形节点来实现的。当有数据变化的时候或者节点过期的时候，会通过事件触发通知对应的客户端数据变化了，然后客户端再请求zk获取最新数据，采用push-pull来做数据更新。

ZK最重要的就是它的ZAB（消息广播和崩溃恢复）协议了。

消息广播：集群中zk在数据更新的时候，通过leader节点将将消息广播给其他follower节点，采用简单的两阶段提交模式，先request->ack->commit，当超过一半的follower节点响应可以提交就更新代码。

崩溃恢复：当leader挂了，或者超半数follower投票得出leader不可用，那么会重新选举，这段期间zk服务是不可用的。通过最新的 xid来选举出新的leader，选举出来后需要将新的leader中的数据更新给超过半数的follower节点才能对外提供服务。

Nacos

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

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

一句话概括就是Nacos = Spring Cloud注册中心 + Spring Cloud配置中心。

Nacos的配置中心和注册中心实现的是两套代码，和Zk不同，

1.配置中心

Nacos和Zookeeper都可以作为配置中心，做一些可以实时变化的配置数据存储，然后实时更新线上数据。

2.存储和数据更新

Nacos：依赖Mysql数据库做数据存储，当有数据更新的时候，直接更新数据库的数据，然后将数据更新的信息异步广播给Nacos集群中所有服务节点数据变更，在由Nacos服务节点更新本地缓存，然后将通知客户端节点数据变化。

Zookeeper:利用zk的树型结构做数据存储，当有数据更新的时候使用过半机制保证各个节点的数据一致性；然后通过zk的事件机制通知客户端。

这里可以明显发现差异：

服务器存储位置不同，分别采用mysql和zk本身存储

消息发送，一个有采用过半机制保持一致性，另外一个异步广播，通过后台线程重试保证。

3.注册中心

Nacos：nacos支持两种方式的注册中心，持久化和非持久化存储服务信息。

非持久直接存储在nacos服务节点的内存中，并且服务节点间采用去中心化的思想，服务节点采用hash分片存储注册信息

持久化使用Raft协议选举master节点，同样采用过半机制将数据存储在leader节点上

Zookeeper:利用zk的树型结构做数据存储，服务注册和消费信息直接存储在zk树形节点上，集群下同样采用过半机制保证服务节点间一致性

这里的差异：

nacos支持持久化和非持久化存储即有点 AP和CP 分布式一致性的概念，nacos的CP-持久化更像贴合zk的模式（过半机制），默认非持久化采用内存存储速度更快，而且分片存储，不利点就是某个服务节点挂掉，可能出现部分时间调用失败。因为服务调用本身就是实时的，持久化存储起来应该意义不大，及时变化才是真理。

nacos基本概念：

nacos原理：

Nacos注册中心分为server与client，server采用Java编写，为client提供注册发现服务与配置服务。而client可以用多语言实现，client与微服务嵌套在一起，nacos提供sdk和openApi，如果没有sdk也可以根据openApi手动写服务注册与发现和配置拉取的逻辑

注册中心原理

nacos服务注册方法：

    服务注册的策略的是每5秒向nacos server发送一次心跳，心跳带上了服务名，服务ip，服务端口等信息。同时 nacos server也会向client 主动发起健康检查，支持tcp/http检查。如果15秒内无心跳且健康检查失败则认为实例不健康(显示红色)，如果30秒内健康检查失败则剔除实例。

配置中心原理

Nacos 的关键特性包括:

• 服务发现和服务健康监测
  Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO或HTTP&API查找和发现服务。

  Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层(如 HTTP、MySQL、用户自定义）的健康检查。对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。

• 动态配置服务
  动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。

  动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。

  配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。

nacos优缺点：

    

优点：

1）开箱即用，适用于dubbo，spring cloud等
2）AP模型，数据最终一致性
3）注册中心，配置中心二合一，提供控制台管理
4）纯国产，各种有中文文档，久经双十一考验

缺点：

1）刚刚开源不久，社区热度不够，依然存在bug(实际根据不短的更新迭代，现在早已趋于稳定)

主流注册中心产品对比图

大家对nacos是否已经有个大致了解了？具体怎么使用呢？下一章节作者会详细介绍使用方法，同时提供源码，免费哦~

整套架构初步规划包含技能点:

    springcloud、springboot、mybatis、分环境打包、mybatis-plus、动态数据源、druid、增删改查一键生成、quartz集群、注册中心:zookeeper+zkui和nacos、gateway网关、feign的使用、熔断机制、如何防止雪崩、分布式+集群、一个项目如何进行zk和nacos同时使用、动态配置：一个配置，所有集群节点共同热点使用。

详细请关注作者公众号查看相关内容: