11-Spring Cloud Alibaba实战-Nacos核心原理_nacos/data/protocol/raft

专栏目录

1. 1-Spring Cloud Alibaba实战-系统架构演变与微服务常见问题
2. 2-Spring Cloud Alibaba实战-简介与组件说明
3. 3-Spring Cloud Alibaba实战-全组件项目搭建手册
4. 4-Spring Cloud Alibaba实战-服务治理
5. 5-Spring Cloud Alibaba实战-Nacos Config–配置中心
6. 6-Spring Cloud Alibaba实战-Gateway网关核心架构
7. 7-Spring Cloud Alibaba实战-Gateway网关核心原理
8. 8-Spring Cloud Alibaba实战-分布式服务治理机制
9. 9-Spring Cloud Alibaba实战-Sentinel原理
10. 10-Spring Cloud Alibaba实战-Sleuth–链路追踪
11. 11-Spring Cloud Alibaba实战-Nacos核心原理

Nacos原理篇

关键词udp raft mysql

项目整体结构

NacosConfigService

注册与发现

· 服务通过nacos server内部的open api进行服务注册，nacos server内部有一个sevice服务的概念，里面有多个instance实例的概念，同时对不同的service服务可以划归到不同的namespace命名空间下去

· 注册的时候就是在注册表里维护好每个服务的每个实例的服务器地址，包括ip地址和端口号

· 一旦注册成功之后，服务就会跟nacos server进行定时的心跳，保持心跳是很关键的，nacos server会定时检查服务各个实例的心跳，如果一定时间没心跳，就认为这个服务实例宕机了，就从注册表里摘除了

· 其他服务会从nacos server通过open api查询要调用的服务实例列表，而且nacos客户端会启动一个定时任务，每隔10s就重新拉取一次服务实例列表，这样如果调用的服务有上线或者下线，就能很快感知到了

· 还可以对要调用的服务进行监听，如果有异常变动会由nacos server反向通知他

· nacos本身的话，其实是完全可以脱离spring cloud自己独立运作的，但是他目前是集成到spring cloud alibaba里去的，也就是在spring cloud的标准之下实现了一些东西，spring cloud自己是有一个接口，叫做ServiceRegistry，也就是服务注册中心的概念

服务的分级模型

Nacos在经过内部多年生产经验后提炼出的数据模型，则是一种服务-集群-实例的三层模型

寻址模式

寻址模式详细

接下来介绍除了单机模式下的寻址模式的其他两种寻址模式

FileConfigMemberLookup

该寻址模式是基于cluster.conf文件进行管理的，每个节点会读取各自{nacos.home}/conf下的cluster.conf文件内的成员节点列表，然后组成一个集群。并且在首次读取完{nacos.home}/conf下的cluster.conf文件后，会自动向操作系统的_inotify_机制注册一个目录监听器，监听{nacos.home}/conf目录下的所有文件变动（注意，这里只会监听文件，对于子目录下的文件变动无法监听）

当需要进行集群节点扩缩容时，需要手动去修改每个节点各自{nacos.home}/conf下的cluster.conf的成员节点列表内容。

首次启动时直接读取cluster.conf文件内的节点列表信息，然后向WatchFileCenter注册一个目录监听器，当cluster.conf文件发生变动时自动触发_readClusterConfFromDisk()_重新读取cluster.conf文件

AddressServerMemberLookup

该寻址模式是基于一个额外的web服务器来管理cluster.conf，每个节点定期向该web服务器请求cluster.conf的文件内容，然后实现集群节点间的寻址，以及扩缩容。
当需要进行集群扩缩容时，只需要修改cluster.conf文件即可，然后每个节点向地址服务器请求时会自动的得到最新的cluster.conf文件内容。

在初始化时，会主动去向地址服务器同步当前的集群成员列表信息，如果失败则进行重试，其最大重试次数可通过设置_nacos.core.address-server.retry_来控制，默认是5次，然后成功之后，将创建定时任务去向地址服务器同步集群成员节点信息

节点管理和寻址模式如何结合的

MemberLookup在启动之后，会根据不同的寻址模式，执行寻址任务，将收集到集群节点列表信息，调用memberChange，触发集群节点变动，然后发布节点变更事件

数据一致性

Raft-分布式一致性协议

在线演示中文版 http://www.kailing.pub/raft/index.html

在线演示英文版 http://thesecretlivesofdata.com/raft/

目前来看基本可以归为两家：一种是基于Leader 的非对等部署的单点写一致性，一种是对等部署的多写一致性。

· 当我们选用服务注册中心的时候，并没有一种协议能够覆盖所有场景

· Nacos 因为要支持多种服务类型的注册，并能够具有机房容灾、集群扩展等必不可少的能力，在1.0.0 正式支持AP 和CP 两种一致性协议并存。

· 目前的一致性协议实现，一个是基于简化的Raft 的CP 一致性，一个是基于自研协议Distro 的AP 一致性。

一致性协议层工作流程

Nacos一致性协议层之CP协议的实现选择——JRaft

JRaftProtocol是当JRaft作为CP协议的Backend时的一个ConsistencyProtocol的具体实现，其内部有一个JRaftServer成员属性，JRaftServer分装了JRaft的各种API操作，比如数据操作的提交，数据的查询，成员节点的变更，Leader节点的查询等等。

注意事项：JRaft 运行期间产生的数据在${nacos.home}/data/protocol/raft 文件目录下。不同的业务模块有不同的文件分组，如果当节点出现crash 或者异常关闭时，清空该目录下的文件，重启节点即可

由于JRaft实现了raft group的概念，因此，完全可以利用raft group的设计，为每个功能模块单独创建一个raft group。这里给出部分代码，该代码体现了如何将LogProcessor嵌入到状态机中并为每个LogPrcessor创建一个Raft Group

负载均衡

负载均衡严格的来说，并不算是传统注册中心的功能。一般来说服务发现的完整流程应该是先从注册中心获取到服务的实例列表，然后再根据自身的需求，来选择其中的部分实例或者按照一定的流量分配机制来访问不同的服务提供者，因此注册中心本身一般不限定服务消费者的访问策略