目录
1.Nacos介绍
1.1四大功能
（1）服务发现和健康监测：
支持基于DNS和基于RPC的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。
Nacos提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。
（2）动态配置服务：
以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
提供了一个简洁易用的UI (控制台样例 Demo) 帮助管理所有的服务和应用的配置。
Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，能更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
（3）动态DNS服务：
动态 DNS 服务支持权重路由，更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能更容易地实现以 DNS 协议为基础的服务发现，消除耦合到厂商私有服务发现 API 上的风险。
Nacos 提供了一些简单的 DNS APIs TODO ，管理服务的关联域名和可用的 IP:PORT 列表
（4）服务及其元数据管理：
从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
1.2微服务中配置文件的问题
在我们的微服务的运行环境中，每一个微服务往往不会只有一套环境，在企业中往往存在至少三套运行环境：开发、测试、生产。
在这套微服务系统中，会存在三个问题：
·配置文件的数量会随着服务的增加持续递增
·单个配置文件无法区分多个运行环境
·配置文件内容无法动态更新，需要重启服务
1.3配置中心解决了什么
·统一配置文件管理。
·提供统一标准接口，服务根据标准接口，也就是常见pull/push模型
·自行拉取配支持动态更新的到所有服务。
1.4业界常见的配置中心
·携程开源 Apollp（阿波罗）
·阿里 Diamond
·百度 DisConfig
·Spring Cloud Config
·Nacos
1.5解决不同环境相同配置的问题
在实际的开发过程中，工程项目所用到的配置参数大多数并不需要根据不同的环境进行区分，生产、测试、开发环境所用到的参数值是相同的。Nacos Config也提供了同一服务在多环境中，引用相同的配置的解决方案。即在Nacos config中添加配置：data_id为configdemo.yaml
如果同一个配置项在三个配置文件中都存在且值不同，如果配置了spring.profile.active则优先获取configdemo-${spring.profile.active}.yaml中的值。
1.6不同微服务之间相同配置的共享
在nacos config中增加配置redis.yaml，添加配置“配置名”: “值”如图所示：
（1）通过shared-configs方式：
修改configdemo的bootstrap.yaml的配置文件，增加配置shared-configs[0]（单个），添加多个shard-configs就是增加shared-configs[下标]：
修改Controller ，增加url 获取配置的值并返回。代码如下：
（2）通过extension-configs的方式
修改bootstrap.yaml文件，删除shard-configs相关配置，增加extension-configs[0]和extension-configs[1]如下：
2.Nacos Config 动态刷新原理
2.1推拉（pull/push）模型
（1）Push
表示服务端主动将数据变更推送更新到客户端。
如下图所示，如果有多个客户端时，服务端和客户端需要保持长链接，并且需要存放多个客户端的连接映射地址，还需要保持客户端与服务端的心跳机制。
（2）Pull
客户端主动去服务端拉取数据。
由于为了保证数据的时效性，客户端需要频繁去拉去服务端的数据，而在服务端长时间未更新的情况下，存在许多无效的Pull。
2.2Nacos Config动态刷新机制
Nacos做配置中心的时候，配置数据的交互模式是客户端主动拉取的，通长轮询的方式（Long Polling）的方式来获取配置数据。
Nacos客户端发送一个请求连接到服务端，然后服务端中会有一个29.5+0.5s的一个hold期，然后服务端会将此次请求放入到allSubs队列中等待，触发服务端返回结果的情况只有两种，第一种是时间等待了29.5秒，配置未发生改变，则返回未发生改变的配置；第二种是操作Nacos 仪表盘或者API对配置文件发生一次变更，此时会触发配置变更的事件，发送一条LocalDataEvent消息，此时服务端监听到消息，然后遍历allSubs队列，根据对应的groupId找到配置变更的这条ClientLongPolling任务，并且通过连接返回给客户端
优点：
Nacos动态刷新避免了服务端对客户端进行push操作时需要保持双方的心跳连接，同样也避免了客户端对服务端进行pull操作时数据的时效性问题，不必频繁去拉去服务端的数据
短轮询：
不管服务端的配置是否发生变化，不停发起请求去获取配置。
坏处：由于配置并不会频繁发生变更，如果是一直发请求，一定会对服务端造成很大的压力。还会造成数据推送的延迟，比如每10秒请求一次配置，如果在第11秒的时候配置更新，那么推送将会延迟9秒，等待下一次请求。
长轮询：
由服务端控制响应客户端请求结果的返回时间，来减少客户端无效请求的一种优化手段。
客户端发起请求后，服务端不会立即返回请求结果，而是将请求hold挂起一段时间，如果此时间段内配置数据发生变更，则立即响应客户端，若一直无变更则等到指定超时时间后响应给客户端结果，客户端重新发起长链接。
Nacos Config动态刷新流程图：
3.Nacos领域模型解析
3.1Nacos Config数据模型
3.2Nacos服务的分级存储模型
3.3Nacos服务领域模型
·Namespace：实现环境隔离，默认值public
·Group：不同的service可以组成一个Group，默认值Default-Group
·Service：服务名称
·Cluster：对指定的微服务虚拟划分，默认值Default
·Instance：某个服务的具体实例
4.Nacos服务注册与发现
4.1注册中心原理
4.2Nacos架构图
·Provider APP：服务提供者
·Consumer APP：服务消费者
·Name Server：通过VIP或DNS的方式实现Nacos高可用集群的服务路由
·Nacos Server： Nacos服务的提供者，包括了图中的OpenAPI，Config Service、Naming Service都是Nacos提供的配置和名字服务模块，Conststency Protocol是一个一致性协议，作用是用来实现Nacos集群节点的数据同步这里使用的Raft算法(很火的一种算法，Redis的主从选举就用了这个算法)
·Nacos Console：Nacos控制台
4.3Nacos服务注册原理
4.4Nacos高并发支撑异步任务与内存队列
4.5CAP理论
P：分区容错性 (Partition tolerance): 能容忍网络分区，在网络断开的情况下，被分隔的节点仍能正常对外提供服务(分布式系统必备)。
A：对数据更新具备高可用性，请求能够及时处理，不会一直等待，即使出现节点失效。
C：一致性 (Consistency): 一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据。所有节点访问同一份最新的数据。
C、A、P三者不能同时满足，最多只能满足其中两个，即“三选二特性”：
5.Raft协议
5.1分布式共识问题（一致性问题）
分布式环境下系统集群存在很多节点，每个节点都可提出议案。
解决方案：
·对多个节点提出的议案作裁决并得到一个一致的结论；
·让每个节点都感知到最终结论，从而使集群整体状态保持一致；
·允许故障一部分节点宕机后集群仍可正常工作，先前通过的议案仍可访问，集群状态仍维持一致。
5.2Raft协议核心
一种实现分布式共识（一致性）的协议，即多个节点达成一致的协议。
Raft算法所解决的核心问题是分布式共识问题。
分布式存储系统的核心问题之一：维护多个副本的数据一致性。
Raft将一致性算法分为：
·领导选取（leader selection）
·日志复制（log replication）
·安全性（safety）
·成员变更
5.3三种角色
一个Node任一时刻必处于以下3种状态之一，其中正常工作期间只有Leader和Followers：
Leader（领导者）：leader用来和客户端交互，然后leader将接收到的数据，通知给其他Node。接受客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后告诉Follower提交日志。任意时刻最多只有一个Leader
Follower（跟随者）：接受并持久化Leader同步的日志，在Leader通知日志可以提交之后，提交日志。
Candidate（候选人）：Leader选举过程中的临时角色。
5.4term任期
任期（term）：一个时间周期，每一个term的开始都是Leader选举。
在成功选举Leader之后，Leader会在整个term内管理整个集群并进行正常操作，执行他的当前任期。
如果Leader选举失败，该term就会因为没有Leader而任期结束。
然后过了一个term就开始下一轮选举，新leader执行他的操作。
5.5RPC
Raft 算法中服务器节点之间通信使用了三种远程过程调用（RPC）：
RequestVote RPC：候选人在选举期间发起。
AppendEntries RPC：领导人发起的一种心跳机制，复制日志也在该命令中完成。
InstallSnapshot RPC: 领导者使用该RPC来发送快照给太落后的追随者。
5.6领导选举
一、两个时间：
1.选举计时器机制
每个node有一个计时器，是一个随机的值（150ms and 300ms），也叫选举时间，表示的是follower等待成为leader的时间。选举时间超时，则该follower开启选举。
2.心跳机制
leader会定期发送心跳给follower，心跳时间比选举时间要短，每次心跳从leader发送给follower时，follower就重新进行选举时间计时，所以当选举时间超时时那么说明心跳时间肯定超时了，这时重新进行选举。
二、选举过程：
（1）服务器启动时，所有节点最初都是follower，follower听不到leader的心跳消息时，选举时间超时（心跳肯定超时），说明当前没有leader（或者leader挂了）。
（2）此时开始选举阶段：谁的选举计时先完成，则此follower先成为candidate。Follower将其当前term加一，因为这是开启了一个新的任期。
（3）candidate争取选票，它首先给自己投票并且给集群中的其他服务器发送 RequestVote RPC。
（4）此时可能出现以下三种情况：
1）如果争取到超过半数的选票，那么该candidate成为leader；
2）收到了Leader的消息，表示有其它服务器已经抢先当选了Leader；
3）没有服务器赢得多数的选票：比如说两个candidate同时发起选举，Leader选举失败，等待选举时间超时后发起下一次选举。
（5）当选举完成：新Leader会立刻给所有节点发消息，避免其他节点触发新的选举。当候选人被告知Leader已产生，则自行切换为Follower，后面leader会定期发送心跳给follower
5.6日志复制（同步）
日志复制的目的：保证数据一致性（将数据复制到所有节点）
Leader选出后，就开始接收客户端的请求，所有的请求都需要通过leader然后到达follower，并将日志传递给follower然后保证follower和leader的一致性。
Leader使用Append Entries消息，这个消息是使用在心跳中的。
状态机：通常指的是一个输入输出程序或应用，负责执行日志中记录的操作。
已提交：Raft保证已提交的日志条目是持久化的，并且最终会被所有可用的状态机执行。
规则：leader只接收并发送日志，不删日志。follower只接收日志发送的信息。
日志格式：日志索引，任期，条目，已提交标志
日志复制步骤：
（1）Leader接收到指令后写入到本地日志，在随后的心跳中（AppendEntries）向其他follower发送该指令
（2）每个follower收到指令会，存储日志，并向leader立即返回确认
（3）leader等待收到过半follower响应确认后，将该条目标志位已提交状态（也就是当日志复制到大多数机器上的时候，就认为该跳命令可以提交了），并发往leader状态机执行该指令，执行完成后返回结果给客户端；
（4）leader在后续心跳包（AppendEntries）中通知所有追随者该条目为已提交状态。follower就也会更新该条目为已提交状态并且在各自状态机中执行该指令。
日志一致性：
通过日志复制的步骤，就可以让follower和leader保持一致。
当 leader 和 follower 日志冲突的时候，leader 将校验 follower 最后一条日志是否和 leader 匹配，如果不匹配，将递减查询，直到匹配，匹配后，删除冲突的日志。这样就实现了主从日志的一致性。
5.7安全性
存在的问题：
在Raft协议中，所有的日志条目都只会从Leader节点往Follower节点写入，且Leader节点上的日志只会增加，绝对不会删除或者覆盖。
这意味着Leader节点必须包含所有已经提交的日志，即能被选举为Leader的节点一定需要包含所有的已经提交的日志。因为日志只会从Leader向Follower传输，所以如果被选举出的Leader缺少已经Commit的日志，那么这些已经提交的日志就会丢失。
Leader选举的限制：能被选举成为Leader的节点，一定包含了所有已经提交的日志条目。
Raft增加了2条限制以保证安全性：
（1）拥有最新的已提交的log entry的Follower才有资格成为leader。能被选举成为Leader的节点，一定包含了所有已经提交的日志条目。
（2）Leader只能推进commit index来提交当前term的已经复制到大多数服务器上的日志，旧term日志的提交要等到提交当前term的日志来间接提交（log index 小于 commit index的日志被间接提交）。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
