目录
nacos的高可用是如何做的？
1、全局高可用
2、同城容灾
3、数据多级容灾
nacos的一致性是如何保证的？
注册中心
配置管理
SDK与server端的一致性
Server之间的一致性
nacos的健康检查机制是什么？
注册中心的健康检查机制
nacos的健康检查机制
临时实例
永久实例: 主动探活
集群模式下的健康检查机制
nacos注册中心的设计原理是什么？
nacos的高可用是如何做的？
1、全局高可用
Nacos 部署架构上是单 Region 封闭，Region 间独立，跨 Region 通过网关或者 Nacos-sync 完 成服务互通。从而降低 Region 间网络故障风险。
2、同城容灾
Nacos 本身是采用 AP 的⼀致性模式，同 Region 多个可用区部署，任何⼀个可用区出问题，剩下 部分继续工作。
3、数据多级容灾
Nacos 持久化存储做了主备容灾，而且底层存储数据多副本高可用保障。
Nacos Server 有全量缓存数据，即使存储挂或者不可用，只影响写，核心的读服务不受影响。
Nacos SDK 有所需服务和配置缓存，Server 即使全挂，走本地缓存，保证核心业务调用不受影响。
nacos的一致性是如何保证的？
注册中心
数据⼀致性: 支持AP和CP两种一致性协议
⼀个是基于简化的 Raft 的 CP ⼀致性；
⼀个是基于自研协议 Distro 的 AP ⼀致性；
配置管理
SDK与server端的一致性
核心是通过MD5值的比较来实现的，如果不一样就更新
Nacos 1.X： 采用 Http 1.1 短链接模拟长链接，每 30s 发⼀个心跳跟 Server 对比 SDK
配置 MD 5 值是否跟 Server 保持⼀致，如果⼀致就 hold 住链接，如果有不⼀致配置，
就把不⼀致的配置 返回，然后 SDK 获取最新配置值。
Nacos 2.x ：相比上面 30s ⼀次的长轮训，升级成长链接模式，配置变更，启动建立长
链接，配置变 更服务端推送变更配置列表，然后 SDK 拉取配置更新，因此通信效率大
幅提升。
Server之间的一致性
有DB模式: 先保存数据到DB成功后，然后异步通知各server拉取最新配置
无DB模式: 采用raft协议保证数据的一致性
nacos的健康检查机制是什么？
注册中心的健康检查机制
主动上报 和 服务探测
nacos的健康检查机制
临时实例
注册方式：open API 或者 SDK
OpenAPI： 的注册方式实际是用户根据自身需求调用 Http 接口对服务进行注册，然后通过 Http 接 口发送心跳到注册中心。在注册服务的同时会注册⼀个全局的客户端心跳检测的任务。在服务⼀段 时间没有收到来自客户端的心跳后，该任务会将其标记为不健康，如果在间隔的时间内还未收到心跳，那么该任务会将其剔除。
SDK： 的注册方式实际是通过 RPC 与注册中心保持连接（Nacos 2.x 版本中，旧版的还是仍然通过 OpenAPI 的方式），客户端会定时的通过 RPC 连接向 Nacos注册中心发送心跳，保持连接的存 活。如果客户端和注册中心的连接断开，那么注册中心会主动剔除该 client 所注册的服务，达到下 线的效果。同时Nacos 注册中心还会在注册中心启动时，注册⼀个过期客户端清除的定时任务，用于删除那些健康状态超过⼀段时间的客户端。
永久实例: 主动探活
Nacos 中使用 SDK 对于永久实例的注册实际也是使用 OpenAPI 的方式进行注册，这样可以保证，即使是客户端下线后也不会影响永久实例的健康检查。
探测机制：
Nacos 采用的是注册中心探测机制，注册中心会在永久服务初始化时 根据客户端选择的协议类型注册探活的定时任务。Nacos 现在内置提供了三种探测的协议，即 Http、TCP 以及 MySQL 。⼀般而言 Http 和 TCP 已经可以涵盖绝大多数的健康检查场景。MySQL 主要用于特殊的业务场景，例如数据库的主备需要通过服务名对外提供访问，需要确定当前 访问数据库是否为主库时，那么我们此时的健康检查接口，是⼀个检查数据库是否为主库的 MySQL 命令。
集群模式下的健康检查机制
对于集群下的服务，Nacos ⼀个服务只会被 Nacos 集群中的⼀个注册中心所负责，其余节点的服务信息只是集群副本，用于订阅者在查询服务列表时，始终可以获取到全部的服务列表。临时实例 只会对其被负责的注册中心节点发送心跳信息，注册中心服务节点会对其负责的永久实例进行健康 探测，在获取到健康状态后由当前负责的注册中心节点将健康信息同步到集群中的其他的注册中心。
在 Nacos 中，服务的注册我们从注册方式维度实际可以分为两大类。
第⼀类通过 SDK RPC 连接进 行注册，客户端会和注册中心保持链接。
第二类，通过 OpenAPI 进行 IP 和端口注册。
对于第⼀类，如何寻找到对其负责的注册中心节点呢？聪明的你肯定想到了，只需要和注册中心集 群中的任意⼀台节点建立联系，那么由这个节点负责这个客户端就可以了。注册中心会在启动时注 册⼀个全局的同步任务，用于将其当前负责的所有节点信息同步到集群中的其他节点，其他非负责 的节点也会创建该客户端的信息，在非负责的节点上，连接类型的客户端，会有⼀个续约时间的概 念，在收到其他节点的同步信息时，更新续约时间为当前时间，如果在集群中的其他节点在⼀段时 间内没有收到不是自己的负责的节点的同步信息，那么认为此节点已经不健康，从而达到对不是自 己负责的节点健康状态检查。
对于第二类，方式其实也基本和第⼀类⼀致，OpenAPI 注册的临时实例也是通过同步自身负责的节 点到其他节点来更新其他节点的对应的临时实例的心跳时间，保证其他节点不会删除或者修改此实 例的健康状态。前面我们特别指明了是临时实例而没有说所有实例，你应该也可能会想到这种方式 对于持久化节点会显得多余，永久实例会在被主动删除前⼀直存在于注册中心，那么我们健康检查 并不会去删除实例，所以我们只需要在负责的节点永久实例健康状态变更的时候通知到其余的节点 即可。
nacos注册中心的设计原理是什么？
数据模型: 四层数据逻辑隔离模型，company - namespace - group - service
数据⼀致性: 支持AP和CP两种一致性协议
⼀个是基于简化的 Raft 的 CP ⼀致性；
⼀个是基于自研协议 Distro 的 AP ⼀致性；
负载均衡:
Eureka是使用ribbon做客户端负载均衡
Consul则是由Fabio做负载均衡
健康检查: Nacos 也支持这种 TTL 机制
Nacos 目前支持临时实 例使用心跳上报方式维持活性，发送心跳的周期默认是 5 秒，
Nacos 服务端会在 15 秒没收到心 跳后将实例设置为不健康，
在 30 秒没收到心跳时将这个临时实例摘除。
性能与容量:
易用性: 提供了客户端操作界面
多语言SDK接入方便
集群扩展性:
用户扩展性:
暑期编程PK赛 得CSDN机械键盘等精美礼品！
