作者：聪言
开篇：一次小小的技能讨论
周末的时分，和一位在国内某互联网公司担任运维的朋友聊天，由于作业相关，刚好聊到了公司项目中微服务架构这块的一些问题，他们公司的微服务架构运用的是业界比较常用的 Spring Cloud Netflix 那一套作为底座，有专门的同学担任运维一套自建的 Eureka 集群来作为微服务注册中心。服务注册中心作为微服务范畴的核心组件，承载着公司核心事务的高频服务，一旦遇到可用性问题，就会大面积影响线上事务。
朋友说自从他接手担任这块之后，现已渐渐在事务开展过程中感到对这个 Eureka 集群运维上的有心无力，被拖住了人力暂且不说，日常故障频发的状况也搞的整个人心力交瘁。谈到好几个作业中碰到的问题，梳理了下发现基本上都是围绕着 Eureka 集群功用、运维才能、维护本钱相关的。聊了很久在一起交流了下方案，当提议他要不考虑用 MSE Nacos 吧，朋友两手一摊，现在公司有那么多研制小组再去全部推进晋级一遍哪有那么简单的。我又问他，那假如什么代码都不需求你们改呢，0 本钱，心动吗？
见招拆招
Round 1 – 突破功用瓶颈
第一个碰到的痛点是当时朋友公司的 Eureka 集群里注册的服务实例数现已过万了，集群水位一向居高不下，CPU 占用率、负载都很高，时不时还会产生 Full GC 导致事务颤动。其实这是由于 Eureka Server 是传统的对等星型同步 AP 模型导致的，各 Server 节点角色持平彻底对等，在这种多实例场景下，关于每次改变(注册/反注册/心跳续约/服务状况改变等)都会生成相应的同步使命来用于一切实例数据的同步，这样一来同步作业量随着集群规划、实例数正相关同步上涨。
再加上 Eureka 的二级行列发布模型机制和限流延迟战略，极易造成同步使命积压从而导致服务端的高负载影响功用。假如这个时分再不凑巧，碰上网络颤动的状况，引发了同步使命的重试风暴则会进一步加剧集群功用问题，从而终究影响正常事务的稳定性，这一点 Eureka 官方文档也有提及。开源 Eureka 的这种广播复制模型，不只会导致它本身的架构脆弱性，也影响了集群全体的横向扩展性。
Replication algorithm limits scalability: Eureka follows a broadcast replication model i.e.all the servers replicate data and heartbeats to all the peers. This is simple and effective for the data set that eureka containshowever replication is implemented by relaying all the HTTP calls that a server receives as is to all the peers. This limits scalability as every node has to withstand the entire write load on eureka.
口说无凭，特意用功用分析利器 Arthas 从线上出产环境的 Eureka Server 集群采集了一份新鲜的 Profiler 火焰图，能够看到紫色部分便是在处理心跳续约逻辑，抛开 Jersey 写 IO 的部分不谈，这部分的 CPU 调用栈处理占比那是相当的高。
那么 MSE Nacos 是怎么处理这个问题呢，这就要说到自研的 AP 模型 Distro 协议了，在保留了星型同步模型的基础上，Nacos 对一切服务注册实例数据进行了 Hash 散列、逻辑数据分片，为每一条服务实例数据分配一个集群职责节点，每一个 Server 节点仅担任自己 own 的那一部分数据的同步和续约逻辑，一起集群间数据同步的粒度相关于 Eureka 也更小。
这样带来的优点是即便在大规划布置、服务实例数据许多的状况下，集群间同步的使命量也能确保相对可控，而且集群规划越大，这样的模式带来的功用提高也益发显着。
别的 MSE Nacos 在阿里云内部也在进行不断产品的打磨，对读写功用网络吞吐、实例索引存储容量进行了大幅优化，依据实验室压测数据，MSE Nacos 专业版支撑的 Eureka 注册中心的写功用、容量均提高达一倍以上，相同的集群机器配置下，集群 CPU 开支、负载显着优于开源 Eureka。
Round 2 – 简化运维
第二点便是运维本钱的问题了，咱们知道运用 Eureka 的很大一部分用户群体是运维同学，可是 Eureka 供给的运维才能、东西实在是太简陋了，彻底无法满足日常作业中的运维需求。运维同学手上没有趁手的武器，可不就只能辛苦加班加点来顶上了么。就像经常被吐槽的 Eureka 的操控台，上面只要一些很简单的服务注册列表、集群基础信息查看功用，想方便做一些高阶操作只能自己投入人力本钱来定制开发。
可是相反在 MSE Nacos 的操控台上能够看到许多丰厚易用的运维功用，比方实例权重配置管理，能够很方便的依据不同实例的功用分配权重，某个实例反常的时分也能够直接操作一键下线；除此之外还有服务健康状况查看、集群指标监控报警可对集群状况、服务数、TPS、请求耗时等指标进行监控，而且供给自定义告警规则及钉钉、电话、短信等告警途径，便于排查反常。
还有一个运维同学关注比较多也是比较头疼的问题，是关于 Eureka 集群容量评价的，究竟什么样的集群机器配置才能够保障事务的稳定运行，别的是否还能够从容的应对事务上一些突发的扩容场景需求。通常比较省劲的解法就只能是提早预估好事务量，留够满足的资源池 buffer，那带来的问题便是显着的资源本钱糟蹋，没办法完结降本增效的意图。
别的这些事务集群的扩缩容往往触及人工运维操作，也极简单由于操作不规范而引发线上故障。为了处理这个问题，MSE Nacos 近期刚刚上线了 Serverless 版别并开始公测， Serverless 版别完结了对集群事务资源的精细化管理和超卖弹性调度。区别于传统实例的标准变配需求手动操作，Serverless 版别支撑根据事务资源量自动扩缩容，从此不再需求提早做杂乱的容量规划，关于中小规划事务及潮汐式场景又省劲又省力。
Round 3 – 无缝搬迁、安全接收
其实在考虑转型 MSE Nacos 作为微服务注册发现中心的时分，不光是我朋友，大家都很简单有一个担忧的问题，便是假如让整个公司一切事务研制团队都要为了适配 MSE Nacos 晋级改造一遍的话，不单单是代码改造量的问题，还需求有配套的集成测验、功用压力测验需求一起跟进，这些加起来需求投入的本钱实在是太高了。
然而实际上这个问题其实是最不用担心的，由于 MSE Nacos 完结了对开源 Eureka 原生协议的彻底兼容，事务模型层面把 Eureka 中的 InstanceInfo 数据模型和Nacos 的数据模型(Service 和 Instance)进行了对应的一一映射，关于 Eureka Client 的改变仅仅是需求更换一下服务端实例 Endpoint 配置的修正即可完结切换。在日常事务运用中，既能够运用原生的 Eureka 协议把 MSE Nacos 实例当成一个 Eureka 集群来用，也能够支撑 Nacos、Eureka 客户端双协议并存，不同协议的服务注册信息之间支撑互相转换，从而确保事务微服务调用的连通性。
但这时肯定有人要问了，我在老的自建 Eureka 集群上那些已有的线上服务注册存量数据怎么办，怎么平迁到 Nacos 上而且还能不影响到现在的事务调用。为了处理这个问题，MSE Nacos 推荐运用官方的 MSE-Sync 处理方案， MSE-Sync 是根据开源 Nacos-Sync 优化后的搬迁配套数据同步东西，支撑双向同步、自动拉取服务和一键同步的功用，**能够轻松完结自建 Eureka 集群到 MSE Nacos 专业版的数据平滑搬迁。
** 搬迁方案能够参考这篇最佳实践协助文档：*help.aliyun.com/zh/mse/use-…](p3-juejin.byteimg.com/tos-cn-i-k3…)
别的这儿需求补充的是，Eureka 1.X 版别现已停止更新了，社区 2.0 版别的开源作业现已停止，而且 Eureka 2.0.0 Java 客户端 API 不向后兼容 1.x，看到官方下面的告诉就问你慌不慌。从长远考虑继续运用自建 Eureka 作为服务注册中心，明显不是一个很好的挑选。
数据比照
为了比照两者产品才能上的差异，接下来咱们来一起做一个很有意思的压力测验，这次开源 Eureka(选用闭源前次新 1.X 版别 v1.10.17)和 MSE Nacos 咱们都运用了相同的 8C16G 标准容器来建立 3 节点高可用集群。别的施压脚本咱们统一选用 Golang 完结的模拟多 client 来并发注册，施压机器均是云上普通的 ECS 机器，一切的模拟的 Eureka client 实例行为跟实际出产环境行为均坚持一致，包括注册、心跳续约、守时全量/增量拉取 Registry 数据等功用，其间 client 心跳上报时刻距离 3s，过期时刻 10s，守时全量/增量注册数据拉取的距离为 30s。
施压程序会分若干批，均匀不断的往集群里注册新的服务数据并经过心跳坚持住，直到集群呈现功用瓶颈或者是达成预期压测方针(服务数 100，每个服务实例数 500)，压测过程中经过实时监控大盘来观测集群各项系统指标数据来做一个比照。
开源 Eureka 的体现
结论： 开源 Eureka 集群在服务注册增长到挨近 2W 邻近的时分，能够看到 CPU 负载现已有飙高痕迹，后边继续攀升的压力终究导致集群 CPU 被彻底打满，而且集群开始频繁呈现服务实例续约失利的错误，终究集群容量也只能稳定在 1.6W 左右，不满足压测预期。
MSE Nacos 专业版的体现
结论： 能够看到 MSE Nacos 专业版随着注册规划的不断攀升，CPU 利用率仅仅稳步上升，并没有呈现 CPU 负载突然飙高的状况。当到达开源 Eureka 2W 邻近功用瓶颈的时分，此刻 MSE Nacos 集群的 CPU 只要 40% 不到，这就意味着相同的集群容量要求，运用 MSE Nacos 专业版需求的机器标准能够更低，性价比更高。当终究稳定在本次压测方针 5W 的时分，此刻集群进入稳态不再改变，全体 CPU 利用率稳定在了 50%，内存占用、读写 RT 均体现优异。
更多的差异化技能竞争力
经过上述事例、压测数据的展现，再回到本文标题讨论的内容，自建 Eureka 明显不是一个最优的挑选，深度结合云原生技能的 MSE Nacos 在本钱、功用、弹性等多项指标上都现已彻底超越了开源 Eureka， 别的像 MSE Nacos 经过支撑 MCP 协议和 XDS 协议，服务网格生态范畴已彻底兼容专业版的 Eureka 协议，这样搭配上 MSE 云原生网关、微服务管理的才能，就能够建立一套面向业界主流微服务生态的一站式微服务平台，具有一系列的高功用、高可用的企业级云服务才能，节省自建网关、注册配置中心、微服务管理体系的人力本钱。
写在最终
MSE Nacos Serverless 版别已于 2023 年 11 月 17 日正式商用！
