Nacos 开发篇Nacos Eureka Sync 方案演进

Sync 官方方案
经过研究，我们采取了官方的Nacos Eureka Sync 方案，在小范围试用了⼀下，效果良好，但⼀部署到FAT 环境后，发现根本不行，⼀台同步服务器无法抗住将近660 个服务（非实例数）的频繁心跳，同时该方案不具备高可用特点。
Sync ⾼可⽤⼀致性Hash + Zookeeper 方案
既然⼀台不行，那么就多几台，但如何做高可用呢？
我们率先想到的是⼀致性Hash 方式。当⼀台或者几台同步服务器挂掉后，采用Zookeeper 临时节点的Watch 机制监听同步服务器挂掉情况，通知剩余同步服务器执行reHash ，挂掉服务的工作由剩余的同步服务器来承担。通过⼀致性Hash 实现被同步的业务服务列表的平均分配，基于对业务服务名的二进制转换作为Hash 的Key 实现⼀致性Hash 的算法。我们自研了这套算法，发现平均配的很不理想，第⼀时间怀疑是否算法有问题，于是找来Kafka 自带的算法（见Utils.murmur2 ），发现效果依旧不理想，原因还是业务服务名的本身分布就是不平均的，于是又回到自研算法上进行了优化，基本达到预期，下文会具体讲到。但说实话，直到现在依旧无法做到非常良好的绝对平均。
Sync ⾼可⽤主备+ Zookeeper 方案
这个方案是个小插曲，当⼀台同步服务器挂掉后，由它的“备”顶上，当然主备切换也是基于Zookeeper 临时节点的Watch 机制来实现的。后面讨论下来，主备方案，机器的成本很高，实现不如⼀致性Hash 优雅，最后没采用。
Sync ⾼可⽤⼀致性Hash + Etcd 方案
折腾了这么几次后，发现同步业务服务列表是持久化在数据库，同步服务器挂掉后reHash 通知机制是由Zookeeper 来负责，两者能否可以合并到⼀个中间件上以降低成本？于是我们想到了Etcd方案，即通过它实现同步业务服务列表持久化+ 业务服务列表增减的通知+ 同步服务器挂掉后reHash 通知。至此方案最终确定，即两个注册中心（ Eureka 和Nacos ）的双向同步方案，通过第三个注册中心（ Etcd ）来做桥梁。Sync 业务服务名列表定时更新优化方案解决了⼀致性Hash 的问题后，还有⼀个潜在风险，即官方方案每次定时同步业务服务的时候，都会去读取全量业务服务名列表，对于业务服务数较少的场景应该没问题，但对于我们这种场景下，这么频繁的全量去拉业务服务列表，会不会对Nacos 服务器的性能有所冲击呢？接下去我们对此做了优化，取消全量定时读取业务服务名列表，通过DevOps 的发布系统平台实施判断，如果是迁移过来的业务服务或者新上Nacos 的业务服务，由发布平台统⼀调用Nacos 接口来增加新的待同步业务服务Job，当该业务服务全部迁移完毕后，在官方同步界面上删除该同步业务服务Job 即可。

Sync 服务器两次扩容
方案实现后，上了FAT 环境上后没发现问题（此环境，很多业务服务只部署⼀个实例），而在PROD 环境上发现存在双向同步丢心跳的问题，原因是同步服务器来不及执行排队的心跳线程，
致Nacos 服务器无法及时收到心跳而把业务服务踢下来。我们从8 台4C 8G 同步服务器扩容到12 台，情况好了很多，但观察下来，还是存在⼀天内⼀些业务服务丢失心跳的情况，于是我们再次从12 台4C 8G 同步服务器扩容到20 台，情况得到了大幅改善，但依旧存在某个同步服务器上个位数丢失心跳的情况，观察下来，那台同步服务器承受的某几个业务服务的实例数特别多的情况，我们在那台同步服务器调整了最大同步线程数，该问题得到了修复。我们将继续观察，如果该问题仍旧复现，不排除升级机器配置到8C16G 来确保PROD 环境的绝对安全。
至此，经过2 个月左右的努力付出，Eureka 和Nacos 同步运行稳定， PROD 环境上同步将近660 个服务（非实例数），情况良好。