那么 group 的目的是什么呢？假设我们用过 dubbo 就知道这个概念了，对效劳停止分组。有时分我们一个效劳刚末尾是一个大效劳，但随着业务扩展，有时分需求拆成几个小效劳，这样就可以设置为一个 group。
这些都是基于 可扩展性 来思索设计的。我们看看官方文档的数据模型：
图片来源： nac os 官方文档
② 怎样避免读写抵触呢？
中心点：读写别离，采用了写时复制形式，提升了高并发。 就是写的时分，拷贝一份旧的实例，对这份拷贝数据修正，修正完后，再复制过去，读直接读旧实例。
读写别离这种形式，避免了加锁抵触，提升了高并发才能。读过 Eureka 源码的了解，它的完成是基于多级缓存来完成的，然后缓存之间同步数据。时效性显然没有 Nacos 的好。
这里还要思索一个点，这里复制，复制的是什么？假设写时复制，把一切的数据都复制，显然内存吃不消的。这里研讨下官网的效劳模型，效劳下面封装的是一个个集群，集群下面是实例。
为什么有集群这个概念呢？ 假设公司规模大一点的同窗会知道，为了容灾高可用，一个效劳，能够是多机房部署的。比如一个效劳能够在亦庄机房部署一个集群，兆维机房下也有一个集群。这里可以看到 nacos 模型设计的是十分巧妙的，基本上很多点都思索到。
我们看源代码也可以验证，可以看到 Service 下面，封装了一个 clusterMap。
而 cluster 下面又封装了详细的实例集合，画横线的部分。
所以，这里的写时复制，它复制的是这个实例所属的集群结构，我把中心代码截图出来，
先复制旧的实例，放到一个 oldmap 外面。
对旧的 map 做一系列运算操作，比如下线一个实例 , 然后把结果放到 ips 。
最后把新的效劳虚例集合赋值回去。
可以看到这外面有很多技巧，这些都可以学习，以后本人设计中间件或许写代码的时分，都是可以直接用的。
（3）效劳心跳是如何保活的？
客户端每 5s 发送心跳给效劳端，经过 http 央求调用发送给效劳端。 效劳端开启安康反省义务，每隔 5s 反省一次，假设发现超过 15s 没有收到心跳，设置安康形状为 false. 假设超过 30s 没有收到心跳，直接剔除实例。
这里我们想一个成绩，效劳端开启安康反省义务，假设集群形式下，每个效劳端都要判别吗？这个会不会很耗功用？
我们看到安康反省义务里有这样一段代码 , 它会依据效劳称号经过 hash 运算后对机器结点数取模，判别能否要执行安康反省代码。也就是说，集群形式下，不管启动了多个效劳虚例，任何一个效劳，正常状况下只要一个结点来执行安康反省代码。但能够以为时效性，假设其他节点多执行一次，也没什么大影响对吧。当然这外面还有一些细节，都可以深扣，效劳发现，时效性是多大？
（4）效劳是如何下线的？
超过 30s 未收到心跳，就会剔除，这个下面我们知道了，剔除调用的其实是本人的 deregister 办法：
跟出来看一下，我们发现删除办法对 service 也是加了锁的，也就是说对同一个效劳的修正，是做了防并发的。
最后删除，本质也是基于异步的，这个和注册逻辑相似。
（5）客户端如何发现效劳的，效劳修正是如何感知的？
① 客户端先从本地缓存获取效劳虚例，假设为空，则从效劳端拉取。
并启动一个定时义务，活期更新效劳端最新实例信息。
② 效劳端修正后，经过 udp 协议推送
一方面基于 udp 推送提升了实时性，另一方面， udp 虽然能够丢包，但客户端定时拉取可以作为兜底。这个设计真的很巧妙。
(责任编辑：admin)