99 大促来袭,利用 MSE 服务自治体系为业务保驾护航

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 业务大促备战是企业必做功课之一,今天趁着 99 大促来袭前,谈一谈如何利用 MSE 的服务自治能力提前发现潜在风险,通过可观测能力了解引擎内部运行状态,并提供自建 Nacos/ZooKeeper 一键迁移上云服务,帮助业务顺利应对大促。

作者:草谷


前言


业务大促备战是企业必做功课之一,今天趁着 99 大促来袭前,谈一谈如何利用 MSE 的服务自治能力提前发现潜在风险,通过可观测能力了解引擎内部运行状态,并提供自建 Nacos/ZooKeeper 一键迁移上云服务,帮助业务顺利应对大促。


点击查看直播回放:

https://yqh.aliyun.com/live/detail/29401


微服务的挑战


单体到微服务的变化


随着互联网的业务快速增长,进而导致系统的架构也在不断的发生着变化,由最初的单体形态演变到现在最流行的微服务架构;软件架构设计里面没有银弹,享受着微服务带来的扩展性和性能提升,必然要承受它带来的一些副作用,总的来说,主要有以下几点的变化:


  • 调用链路增加了多跳 


单体应用的业务逻辑在一个节点进程里面闭环执行完成,微服务架构改造后,不同功能属性的逻辑拆分成一个个服务部署在独立的节点之上,要完成一段完整的业务逻辑,需要每个独立节点互相配合,A->B 变成了 A->B1->B2->B3。


  • 增加了复杂中间件的依赖 


微服务架构里面,RPC 是最基本的技术引入,它包含了:RPC 客户端(Dubbo/Spring Cloud),注册中心(Nacos/ZooKeeper/Eureka),如果有事务要求的,还需要依赖一些分布式事务组件如 Seata。


  • 从单兵作战到多团队协作 


微服务架构的升级,除了应用系统层面的变化,生产关系也可能产生了变化,以前一个系统由一个人负责,变成了多个服务团队协作开发,互相支持。


1.png


带来的挑战

面对微服务架构带来的变化,给开发者和运维同学带来了不少挑战:


2.png


在日常开发和运维过程中,经常会遇到一些如下的典型问题:


  • 场景一:服务调用失败,Consumer 日志显示没有可用服务,可明明 Provider 进程正常运行着,是服务没注册上去呢?还是注册中心没把地址推送到客户端呢? 


  • 场景二:Nacos 客户端在某种极端场景下,出现了异常,排查了半天,是 Nacos 客户端已知 Bug 导致,需要升级到 xx 稳定版本,但是作为开发/运维的你,每天业务需求那么多,如何搞定对客户端版本迭代保持着时刻的关注呢? 


  • 场景三:业务大促即将来临,客户端热火朝天的扩容以应对激增的流量,突然间注册配置中心不工作了,原来是达到注册配置中心额定容量了,需要扩容了,每次都是出现问题才后知后觉,然后提前做好容量规划呢? 


  • 场景四:线上注册配置中心出现 FullGC,重启又缓解一下,每隔一段时间又出现,排查同学反馈是可能是有客户端错用,大量的读写数据导致内存吃不消,但是又苦于难以找出到底是谁在“捣乱”?


服务自治能力


云原生微服务仍然是目前最热门的技术架构(《40%的云原生开发者专注于微服务领域》),因此解决这部分群体的痛点,能够给企业带来最大的价值,这也是 MSE 的初衷。


阿里巴巴从 08 年开始单体架构演进走到现在,有着十几年的踩坑经验,也总结出了一套打法;MSE 的服务自治能力 ,目标是帮助用户快速发现问题,定位问题,解决问题,它主要围绕以下 3 个方面提供一系列的功能和工具:


3.png


可观测性


可观测性(Observability)是帮助微服务稳健运行的重要一环:


  • “系统是否还是正常的?”
  • “终端用户的体验是否符合预期?”
  • “如何在系统快要出问题之前主动发现系统的风险?” 


如果说监控可以告诉我们系统出问题了,那么可观测就可以告诉我们系统哪里出问题了,什么原因导致的问题。可观测不但可以判断系统是否正常,还可以在系统出现问题之前,主动发现系统风险。


4.png


  • 监控大盘
     

MSE 提供了丰富的监控大盘,无缝集成 ARMS,免费为大家提供了丰富的可观测能力,可以借助这些指标,窥探容量情况,尽早发现问题,定位问题:


5.png


1. 基础大盘


提供了基础设施的一些核心指标,主要如下:


  • JVM 监控
  • 内存/CPU
  • 网络流量 


针对这些基础核心指标,建议至少要把内存/CPU 的预警给加上,阀值设置到 60%。


如果你的应用是时延敏感的,需要重点关注下 JVM 监控中的 FullGC 指标,这个会导致进程响应变慢。


网络流量指标,可以用来观测 SLB 的网络问题,例如流量突然涨到某个点,然后一直横盘,这时你的客户端也相应出现链接失败异常,这个就可能是达到了流量阀值。


6.png


2. 概览大盘


概览大盘的指标,主要的目的是给大家快速展示一些核心的指标,能够有一个全局的视角:


  • 客户端分布
  • 当前配置/服务水位
  • 链接数
  • 配置/服务数 


其中,客户端分布指标,可以帮助你看到系统中各种客户端版本的分布情况,结合 Nacos 的版本使用限制,找到高危版本,推动解决掉客户端带来的稳定性风险。


例如:近期 Nacos 发布了最新的版本使用约束,Nacos 1.4.1 版本有严重的 DNS 解析异常问题,可以通过客户端分布指标,找到该客户端分布的情况,通知对应的业务进行升级。


7.png


3. 业务大盘-Nacos 服务/配置大盘


MSE 提供的业务大盘里面的指标,都是精挑细选出来具有代表性的,能够帮助你全面了解注册配置中心的内部业务规模;大促来临,公司要求你评估注册配置中心当前容量规模,你可以通过这些指标数据进行一个全面的分析。Nacos 的使用场景分为注册中心和配置中心,MSE 根据这 2 个场景单独设置了大盘:


配置中心指标:


  • 配置数量
  • 配置监听数量
  • 配置的 TPS/QPS
  • 读写 RT 


8.png


注册中心服务指标:


  • 服务提供者/订阅者数量
  • 注册中心 QPS/TPS
  • 注册中心读写 RT
  • 推送成功率/耗时/TPS 


9.png


4. ZooKeeper TopN 大盘


TopN 大盘,对外部因素导致了服务端出现异常类的问题定位是非常高效的:


  • Znode 的大小 Top N 排序
  • 客户端对 ZooKeeper 的读写 TPS/QPS Top N
  • 热点数据的 TPS/QPS Top N
  • 热点数据的监听数 Top N 


在日常开发中,你大概率遇到过 ZooKeeper FullGC 的场景,但是又不知道是具体什么原因引起的 GC,可能是 ZooKeeper 在推送大量数据导致,又不确定是哪个热点数据被订阅导致的,也可能是有客户端往 ZooKeeper 里面写大数据,又找不到是哪个客户端写的?


我们看下 2 个客户端典型错用的场景:


1. 户端错用写入了大数据,订阅者非常多,导致 ZooKeeper 推送大量数据引起了 FullGC:


往/99testWriteBig 路径下面写入了大数据,可以通过 Znode 大小 TopN 发现大数据节点


10.png


2. 客户端错用频繁读某 ZK,导致集群性能压力增加,响应延时,需要找到这个客户端:


一个 SessionId 为:0x1030871c8ed0004 的客户端,频繁读取/99testRead 节点,通过客户端 QPS TopN 大盘,可以找到它,同时也能看到这个当前 Server 中最频繁读取的是哪个数据


11.png


  • 指标预警
     

MSE 给注册配置中心提供了核心指标的预警能力,建议把如下的指标都配置上:


  • Nacos 建议配置:
  • 服务读写平均耗时:可以发现性能问题
  • 配置长轮训链接数:可以发现容量问题
  • 服务数/配置数:可以发现容量问题/客户端错用 


  • ZooKeeper 建议配置:
  • Znode 数:可以发现客户端错用
  • 连接数变化率:突降的话服务端节点可能出现了故障
  • 单服务端链接数:可以发现容量问题/客户端错用 


12.png

13.png


链路追踪


  • 推送轨迹
     

推送轨迹,是指注册配置中心从 server 端到 client 端的一次推送链路上的相关信息展示。推送轨迹可以让用户非常方便的查询到,当开发过程中,出现如下问题,都可以通过推送轨迹快速定位到,极大的提高问题的排查效率:


  • 客户端未收到服务推送
  • 服务间调用出现异常
  • 配置发布异常了
  • 配置修改完发现某台机器不生效
  • 需要查看配置中心变更及推送事件 


14.png

MSE - Nacos 注册中心推送轨迹查询页


15.png

MSE - Nacos 配置中心推送轨迹配置维度查询页面


集群诊断


  • 一键诊断
     

如果说 MSE 提供的各种监控大盘,是辅助你去发现,定位问题,那么 MSE 即将提供的一键诊断功能,就是自动帮你去扫描发现风险,2 者互相配合辅助,它目前主要从下面 3 个方面去做评估:


16.png


下图是一键诊断的功能页面,从上面可以看到目前你当前购买的引擎存在的风险,这些都是根据内置规则给自动扫描出来的,你不用再去人肉进行排查了,并且提供了合理的建议给到你进行改进:


17.png


平滑迁移 MSE


上面给大家介绍的 MSE 服务自治功能,后续将继续完善打磨,提供更多的自治能力,包括事件统计、健康审计等功能,降低注册和配置中心的问题排查难度、提升可用性。


如果你现在还是自建的注册配置中心,建议尽快迁移上云,享受这些企业级服务,MSE 提供了高效的迁移工具 MSE Sync,提供双向同、自动服务获取、一键同步全部服务等能力,帮助用户更好的完成 Nacos、Zookeeper 注册配置中心的迁移。


18.png


MSE 的官网文档,提供了详细的 Step by Step 的迁移操作文档:


《自建 Dubbo ZooKeeper 迁移到 MSE ZooKeeper》

https://help.aliyun.com/document_detail/444943.html


《自建 Dubbo ZooKeeper 注册中心迁移到 MSE Nacos》

https://help.aliyun.com/document_detail/446904.html


《自建 Dubbo Nacos 注册中心迁移到 MSE Nacos》

https://help.aliyun.com/document_detail/445140.html


如果迁移过程遇到问题或者需要定制,可以联系我们提供专家一对一的迁移支持。


购买 MSE 享受企业级服务


MSE 提供了 高可用、高性能、安全易用等核心竞争力!


19.png

20.png

相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
相关文章
|
14天前
|
监控 负载均衡 Cloud Native
ZooKeeper分布式协调服务详解:面试经验与必备知识点解析
【4月更文挑战第9天】本文深入剖析ZooKeeper分布式协调服务原理,涵盖核心概念如Server、Client、ZNode、ACL、Watcher,以及ZAB协议在一致性、会话管理、Leader选举中的作用。讨论ZooKeeper数据模型、操作、会话管理、集群部署与管理、性能调优和监控。同时,文章探讨了ZooKeeper在分布式锁、队列、服务注册与发现等场景的应用,并在面试方面分析了与其它服务的区别、实战挑战及解决方案。附带Java客户端实现分布式锁的代码示例,助力提升面试表现。
30 2
|
2月前
|
Java Linux Spring
Zookeeper实现分布式服务配置中心
Zookeeper实现分布式服务配置中心
48 0
|
3月前
|
Dubbo Java 应用服务中间件
Dubbo 3.x结合Zookeeper实现远程服务基本调用
ZooKeeper和Dubbo是两个在分布式系统中常用的开源框架,它们可以协同工作,提供服务注册与发现、分布式协调等功能。
|
3月前
|
存储 API
Zookeeper分布式协调服务
Zookeeper分布式协调服务
|
4月前
|
消息中间件 Kafka Shell
Linux【脚本 02】shell脚本离线安装配置Zookeeper及Kafka并添加service服务和开机启动(脚本分析)
Linux【脚本 02】shell脚本离线安装配置Zookeeper及Kafka并添加service服务和开机启动(脚本分析)
47 0
|
4月前
|
存储 Shell Linux
ZooKeeper【部署 01】单机版安装+配置+添加到service服务+开机启动配置+验证+chkconfig配置+shell自动部署脚本(一篇入门zookeeper)
ZooKeeper【部署 01】单机版安装+配置+添加到service服务+开机启动配置+验证+chkconfig配置+shell自动部署脚本(一篇入门zookeeper)
120 0
|
6月前
|
监控 安全 大数据
阿里服务的ASM、MSE和ARMS都有其各自的应用场景
阿里服务的ASM、MSE和ARMS都有其各自的应用场景
191 39
|
6月前
|
canal 缓存 Dubbo
zookeeper恢复了,线上微服务却全部掉线了,怎么回事?
zookeeper恢复了,线上微服务却全部掉线了,怎么回事?
65 0
|
6月前
|
Java API Nacos
在MSE微服务引擎中,如果你使用的是Java,你可以通过以下步骤使服务下线
在MSE微服务引擎中,如果你使用的是Java,你可以通过以下步骤使服务下线
41 1
|
6月前
|
消息中间件 分布式计算 网络协议
服务搭建篇(六) 搭建基于Kafka + Zookeeper的集群
用来解决分布式集群中应用系统的一致性问题。Zookeeper 的设计目标是将那些复杂且容 易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的 接口提供给用户使用。
100 0

相关产品

  • 微服务引擎