Nacos整体概况

从个人观点来讲，要学习一款产品，先要了解这个产品能干什么，然后尝试去使用它，接着在深入分析；建议先使用下在看相关原理；目前我们使用到的就两个功能(也是公司目前在用的)，一个是配置中心，一个是注册中心。

来自于官网概念：Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理

1.官网的基础架构图

nacos.jpeg

其实看上面的图感觉不太强烈，基本上就是服务端通过OpenAPI对外提供接口调用，内部有CofigService,NamingService连个服务，底层有核心Core作为基础设施构建等；控制台有基于用户，管理员还有定制化的的界面可以使用，看起来也是相对简单

2.源码结构

nacos1.1.3-code-source.png

这是从官网下载的源码，版本是1.1.3，图中我标示了一些比较重要的模块，也是我后续源码分析的主要模块：

• 配置中心
• 服务发现
• 集群选举
• 待续

2.1 配置中心总体配置情况

一般我们做配置中心会考虑到如下情况：

1.服务器端的配置保存（持久化）
      数据库/文件。。。
2.服务器端提供访问api
      rpc、http（openapi）
3.数据变化之后如何通知到客户端
     zookeeper（session manager）
     push（服务端主动推送到客户端）、pull(客户端主动拉去数据）? -> 长轮训( pull数据量很大会怎么办)
4.客户端如何去获得远程服务的数据（）
5.安全性（）
6.刷盘（本地缓存）->

而我们的nacos的配置中心的处理方式有：

• 1.服务端采用derby/mysql做配置中心持久化，对于非单机或者在使用mysql情况下会在本地磁盘还会缓存一个文件，在这种情况下客户端获取配置信息也是直接读取该磁盘文件；集群使用mysql做配置持久化
• 2.服务器配置中心数据更改
  nacos采用pull和'push结合方式获取配置信息，采用长连接方式（超时）获取数据；
  • 2.1客户端长轮询:
         服务器如果配置数据没有更改会hang住这个请求29.5s;如果期间数据发生变化会直接返回数据，并触发客户端的监听逻辑(长轮训的条件也只是客户端有监听器的时候才会有长轮训)
  • 2.2服务器端处理逻辑
         1）数据发送时，先保存持久化的mysql数据，然后通过触发ConfigDataChangeEvent事件- 广播信息给所有其他节点有数据变化
         2）服务器拿到数据后会更新每一个服务器的本地日志缓存，以及内存中每一个dataId对应的md5值；最后还会触发LocalDataChangeEvent事件，通过hang住的客户端请求返回数据
• 3.服务端的api都是基于RESTFUL请求的
• 4.客户端可以通过开启本地缓存在本地文件做缓存
• 5.集群情况下服务端全量将数据库文件dump到本地

集群一致性问题：
     nacos配置中心使用去中心化思想做的，没有主从节点概念，配置变化更新mysql数据库，然后广播给所有节点以及客户端；如果某个节点出现某种情况更新失败，服务端也有策略，会在6h执行一次数据库全量更新服务器本地磁盘文件

2.2 服务发现

服务发现相比配置中心稍微复杂一点，分析了部分功能。

客户端

• 客户端注册实例后还会通过定时器检查实例是否失败，保证自己的实例注册到服务上
• 客户端故障转移会定时将本地缓存的服务实例做磁盘缓存
• 客户端通过udp监听远端服务实例变化

服务节点数据同步

• 非持久（默认）处理-AP
  • 服务端一致性：数据更新后先缓存在本地内存中，然后遍历发给给其他节点，不分是否是主从发送数据
  • 节点采用分片处理，每一个节点存储的部分数据都有定时心跳做数据同步
  • 推送客户端：通过udp推送给客户端数据更新
• 持久化处理-CP
  • 服务端一致性：Raft实现；转发给leader 缓存在内存中，存储进磁盘，待超过一半follower处理成功返回成功。
  • 服务采用leader发送心跳包给follower节点做数据同步
  • 推送客户端：通过udp推送给客户端数据更新

2.3 集群

nacos的集群选举算法是自己实现的Raft算法，主要是对于naming服务，动态配置服务是没有用到这个raft集群心跳和数据更新的功能的；

功能点主要有三点：

• leader选举：使用Raft的leaderdue时间，到期后发起选举，投票过半为leader
• 心跳：leader定时发送心跳给follower，心跳还可能打包datum(可以关闭)信息给follower节点；follower节点收到心跳重置选举leaderdue避免发生选举，并且如果发现datum数据有变化会更新内存和本地文件缓存，数据变化term会增加100，会删除dead的datum
• 数据更新：每次数据更新的时候，如果请求发送到follower节点会转发给leader处理数据，由leader先更新本地数据，然后分别异步发送给其他follower，如果超过半数的follower更新成功那么数据就更新成功了。

注：
    1）datum指的的对于注册的服务和实例抽象包装
     2）term类似于zookeeper的zxid；term投票时会添加1，数据更新会增加100；zk的是分为前 32位和后32位分别累计选举年代和数据更新递增，这里不赘述。

参考官网：https://nacos.io