混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

京东云开发者
• 阅读 460

1. 背景

当前微服务架构下,各个服务间依赖高,调用关系复杂,业务场景很少可以通过一个系统来实现,常见的业务场景实现基本涉及多个上下游系统,要保证整体链路的稳定性,需要尽量减少系统之间的耦合性,避免因为单点失效引起整个链路的故障。

2. 目标

通过混沌演练验证链路中部分系统发生故障时候的整体链路的表现,对链路保持正常运作的能力进行校验和评估,提前识别未知隐患并进行修复,进而保障整个链路更好地抵御生产环境中的失控条件,提升整体场景功能的稳定性。

3. 演练链路

对真实的业务场景进行混沌演练,就需要对业务场景的相关服务和调用关系进行链路梳理,一般需要根据实际业务场景,画出系统交互图,通过链路串联、数据追踪、和上下游确认等方式整理链路图。

4. 演练计划

混沌演练之前,一定要好可行性评估,评估可以演练的服务部署环境、演练工具的成熟度、演练场景的爆炸半径等,然后决策演练场景,进行实践操作。

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

5. 内容加载演练实践

5.1 链路梳理

内容加载链路演练,通过内容加载的系统交互梳理出加载链路:摹略引擎执行-AB分流-CMS资源获取-鹰眼内容发送

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

5.2 接口梳理

根据调链路调用关系用梳理出具体的接口:

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

5.3 制定演练计划

演练时间:2023.03.28 14:00-22:00

演练攻击人员:孙X英、陈X然; 演练防守人员:张X雷、付X军、刘X、韩X

针对链路接口设计演练场景,一般根据系统特色来设计更容易发生的故障,比如应用偏计算比较消耗CPU的话,故障设计包含CPU满载,应用对于响应的时效有严格的要求的话一般包含方法延迟故障设计。

本次链路故障场景设计如下:

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

具体演练场景设计可参考:混沌实战演练(一)

5.4 演练执行

目前借助天权自动化运维平台进行混沌攻防演练,进入工具市场—演练类,选择不同的故障方案,点击“立即执行”;

如选择Java进程满载场景演练,选择满载率100%,满载核数为演练应用部署服务的CPU核数,演练时长是执行满载的持续时间,选择演练的具体应用和指定IP,执行演练计划。

演练示例,根据演练的场景配置好故障参数,如下图为精准触达系统-消息触达方法延迟增加30ms参数设定:

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

演练执行结果检查,下图为分流服务-JAVA进程满载,指定分流进程CPU满载,故障执行结果:

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

5.5 演练监控

使用监控工具实时收集服务器在混沌演练运行期间的性能状态,如系统层面的 CPU、内存等使用情况,观察方法的响应时间、成功率等指标,一方面验证在混沌场景执行期间系统状态是否达到预期的效果,同时记录演练期间发生的问题,记录现场,另一方面通过监控发现有风险问题进行人工干预,立刻终止演练。

场景一:精准触达系统-消息触达方法延迟增加30ms

演练监控方法执行的成功率和 TP 999:

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

场景二:分流服务-JAVA进程满载,指定分流进程CPU满载

监控平台实时观测系统的CPU使用率:

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

5.6 演练反馈

检查系统故障发生时候监控手段是否完善,研发人员是否可以根据系统告警,快速的定位并解决问题。检查团队的响应、协同效率。

邮件事故告警:

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

事故恢复告警:

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

5.7 环境恢复

场景演练可等待演练时长结束后自行中止,也可根据手工取消、终止演练场景。

演练完成后建议需要重启容器,保证服务恢复正常状态。

5.8 演练复盘

演练结束之后,我们需要对演练进行复盘。不同的故障下,系统的表现以及整体业务场景所受到的影响,演练过程中所发现的问题,需要在复盘报告中呈现出来。

混沌演练实践(二)-支付加挂链路演练 | 京东云技术团队

6.总结

链路演练通过提前主动注入故障,发现系统之间的强弱依赖,对链路进行检验,降低生产环境中故障发生的概率。

“居安思危,思则有备,有备无患。”

作者:京东科技 孙民英

内容来源:京东云开发者社区

点赞
收藏
评论区
推荐文章
Stella981 Stella981
3年前
Nepxion Discovery Agent
前言基于SpringCloud的全链路灰度蓝绿发布功能,其中一个场景是,基于Header传递的全链路灰度路由,采用配置中心配置路由策略映射在网关或者服务上,支持根据用户自定义Header跟路由策略整合,最终转化为路由Header信息而实现,路由策略传递到全链路服务中。这是一个非常普遍的需求,但如果业务方用了服务之间异步调用的方式,会导致存储在Th
Stella981 Stella981
3年前
Spring Boot + Spring Cloud 构建微服务系统(八):分布式链路追踪(Sleuth、Zipkin)
技术背景在微服务架构中,随着业务发展,系统拆分导致系统调用链路愈发复杂,一个看似简单的前端请求可能最终需要调用很多次后端服务才能完成,那么当整个请求出现问题时,我们很难得知到底是哪个服务出了问题导致的,这时就需要解决一个问题,如何快速定位服务故障点,于是,分布式系统调用链追踪技术就此诞生了。ZipKinZipkin是一个
Stella981 Stella981
3年前
Spring Cloud Sleuth 分布式服务追踪
随着业务的发展,系统规模也会变得越来越大,各微服务间的调用关系也变得越来越错综复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生最后的请求结果,在复杂的微服务架构系统中,几乎每一个前端请求都会形成一条复杂的分布式服务调用链路,在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。这时
大数据实时链路备战——数据双流高保真压测 | 京东云技术团队
大数据时代,越来越多的业务依赖实时数据用于决策,比如促销调整,点击率预估、广告分佣等。为了保障业务的顺利开展,也为了保证整体大数据链路的高可用性,越来越多的0级系统建设双流,以保证日常及大促期间数据流的稳定性。
大数据平台红蓝对抗 - 磨利刃,淬精兵! | 京东云技术团队
一、背景目前大促备战常见备战工作:专项压测(全链路压测、内部压测)、灾备演练、降级演练、限流、巡检(监控、应用健康度)、混沌演练(红蓝对抗),如下图所示。随着平台业务越来越复杂,红蓝对抗的作用愈来愈明显,下面将详细介绍大数据平台在本次双十一大促备战工作中是
京东云开发者 京东云开发者
11个月前
2024了,我不想再用AOP收集业务操作日志了 | 京东云技术团队
0.背景在近期的项目中,系统涉及到针对系统的业务操作日志统计功能,由于本系统位于业务链路的中心环节,负责接收上游系统的数据,并将基于用户操作产生的数据传递至下游系统,鉴于业务链路的复杂性和操作场景的多样性,我们计划通过对核心业务数据进行全生命周期的日志记录
分布式系统中的分布式链路追踪与分布式调用链路
在分布式系统中,由于服务间的调用关系复杂,需要实现分布式链路追踪来跟踪请求在各个服务中的调用路径和时间消耗。这对问题排查和性能监控都很重要。常用的分布式链路追踪实现有基于日志的和基于分布式追踪系统的两种方式:
京东云开发者 京东云开发者
5个月前
供应链大屏设计实践
概述在物流系统相关的大屏中,供应链大屏复杂度较高,数据链路较长,稳定性要求较高,当前大屏已经经过2年时间的打磨,整体表现已经相对比较成熟稳定。本文描述了物流供应链业务较复杂的业务场景下,结合了大数据计算相关技术,总结了实时监控大屏指标建设和服务构建的框架和
京东云开发者 京东云开发者
4个月前
当系统闹脾气:用「因果推断」哄稳技术的心
背景系统稳定性问题往往涉及复杂的因果关系。例如,一个系统的崩溃可能由多个因素引起,包括硬件故障、软件bug、业务配置、外部攻击或其他操作不当等。理解这些因素之间的因果关系对于系统稳定性建设至关重要。举个例子:服务雪崩A服务调用B服务之间发生了雪崩效应,原本
京东云开发者 京东云开发者
2个月前
大数据实时链路备战——数据双流高保真压测
作者:京东零售京东零售一、大数据双流建设1.1数据双流大数据时代,越来越多的业务依赖实时数据用于决策,比如促销调整,点击率预估、广告分佣等。为了保障业务的顺利开展,也为了保证整体大数据链路的高可用性,越来越多的0级系统建设双流,以保证日常及大促期间数据流的