上一任留下的 Eureka,我该如何提升她的性能和稳定性(含数据比对)?

2024-01-25 21:52

本文主要是介绍上一任留下的 Eureka,我该如何提升她的性能和稳定性(含数据比对)?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

作者:聪言

开篇:一次小小的技术讨论

周末的时候,和一位在国内某互联网公司负责运维的朋友聊天,由于工作相关,刚好聊到了公司项目中微服务架构这块的一些问题,他们公司的微服务架构使用的是业界比较常用的 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 contains however 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 专业版的数据平滑迁移。

** 迁移方案可以参考这篇最佳实践帮助文档:https://help.aliyun.com/zh/mse/use-cases/migrate-the-user-created-euraka-registry-to-mse-nacos图片

另外这里需要补充的是,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 日正式商用!

这篇关于上一任留下的 Eureka,我该如何提升她的性能和稳定性(含数据比对)?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/644730

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

性能测试介绍

性能测试是一种测试方法,旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试,可以确定系统是否能够满足预期的性能要求,找出性能瓶颈和潜在的问题,并进行优化和调整。 发现性能瓶颈:性能测试可以帮助发现系统的性能瓶颈,即系统在高负载或高并发情况下可能出现的问题

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi