掌门教育微服务体系 Solar | 阿里巴巴 Nacos 企业级落地中篇

联席作者：吴毅挺 任浩军 童子龙 

郑重鸣谢：Nacos - 彦林，Spring Cloud Alibaba - 小马哥、洛夜，Nacos 社区 - 张龙（pader）、春少（chuntaojun）

前言

---

在高速发展的时候，公司规模越来越大，老师人数越来越多，这时候公司不能铺太多人去做运营与服务，必须提高每个人效，这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司，如果被迫成为一家靠资金驱动的公司就活不下去了。-- 张翼（掌门教育创始人兼CEO）

掌门教育自 2014 年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门教育新的机遇。

随着业务规模进一步扩大，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采用的注册中心 Eureka 不堪重负，同时 Spring Cloud 体系已经演进到第二代，第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模，同时它目前被 Spring Cloud 官方置于维护模式，将不再向前发展。如何选择一个更为优秀和适用的注册中心，这个课题就摆在了掌门人的面前。经过对 Alibaba Nacos 、HashiCorp Consul等开源注册中心做了深入的调研和比较，最终选定 Alibaba Nacos 做微服务体系 Solar 中的新注册中心。

第一篇：《掌门教育微服务体系 Solar | 阿里巴巴 Nacos 企业级落地上篇》

背景故事

---

两次 Eureka 引起业务服务大面积崩溃后，虽然通过升级硬件和优化配置参数的方式得以解决，Eureka 服务器目前运行平稳，但我们依旧担心此类事故在未来会再次发生，最终选择落地 Alibaba Nacos 作为掌门教育的新注册中心。

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 业务服务名列表定时更新优化方案