做电商业务开发这几年,我学到的系统稳定性建设方法

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
RDS DuckDB + QuickBI 企业套餐,8核32GB + QuickBI 专业版
简介: 文章总结了电商业务开发中保障系统稳定性的关键方法,包括代码健壮性、安全变更、系统链路梳理、接口降级与限流、定期降级演练、预案准备、系统压测、日常巡检、中间件巡检、值班制度和告警机制,强调了稳定性建设是一个长期任务,需要持续迭代优化,并保持对生产系统的敬畏之心。

一、背景

作为开发人员,系统稳定性是一个绕不开的话题,特别是做电商业务系统这几年,几乎天天都要关注稳定性,一旦出现故障对于公司来说都是一场灾难,因此保障系统稳定是最关键的要求,本文将根据最近几年负责电商系统涉及到的稳定性建设常用方法做一次总结。

二、什么是系统稳定性?

对于业务系统来说,不管有什么因素对我们的系统干扰,都要尽可能的提供高可用性不影响系统功能用户体验

影响稳定性有哪些因素呢?

1、人为操作

比如不合理的系统变更,外部的攻击,访问流量突增

2、自然灾害

比如网线光纤被挖

3、硬件故障

比如自然硬盘损坏,内存网络

从以往经验来看,其实影响系统稳定性最多的原因是人为因素造成的。

二、这些年学到的稳定性方法

1、注重代码健壮性,注重codereview

代码开发需要考虑可观测,可降级,考虑异常容错性,合理使用缓存,线程池等,对于外部依赖需要超时机制

2、安全变更,遵守sop

任何生产环境的变更都要按公司规范操作,做到可灰度可监控可回滚

3、系统链路梳理,强弱依赖梳理

把系统核心链路流程梳理,分析系统的出强弱依赖,分析是否有损降级

4、接口降级,限流,熔断,超时设置

需要对下游依赖设置可降级,可熔断超时,避免外部系统性能或者故障拖垮服务

对本服务接口设置必要的限流,一般有网关层总限流单机限流,防止突发流程冲击系统

5、定期业务系统降级演练

需要定期对系统的业务功能进行降级演练,只有真实演练过了,线上有问题的时候才可以临危不乱。

6、系统预案准备充分

业务功能上线前都需要做好降级预案,包括技术和业务层面的准备,这样出现问题可以快速恢复止血

7、系统或全链路压测

新功能上线需要做压测摸高,日常也需要常态化压测,通过压测用于合理评估系统资源是否合理,可以及时消除容量和性能瓶颈隐患

8、业务系统日常巡检

  • 业务指标巡检

对于业务系统这点是非常重要的,我们需要观察业务指标趋势,业务指标一般有一定的规律,如果变化比较大可能业务有调整,可以评估是否正常的业务。

  • 业务流量qps巡检

巡检qps的环比变化,发现异常的流量,防止业务或者流量突增对系统冲击

  • 接口响应时间rt巡检

发现系统响应时间的变化,主动发现问题

  • 系统异常巡检

自动发现系统的错误,提早评估业务影响

9、中间件巡检

  • Mysql巡检

mysql慢查询

mysql的cpu繁忙度

mysql磁盘空间大小与增长情况

mysql的主键或者分布式id是否将达到阈值

上面这些是需要重点关注的部分,通过巡检提前发现系统隐患,降低故障发生概率,提高可用性。

  • redis巡检

redis的cpu繁忙度

redis热点key的变化

redis大key的变化

redis的数据分布均衡情况

上面几个点是关注多的,如果使用的云上的产品,都有比较好的可视化监控能力,我们通过监控面板发现问题。

10、系统值班

针对重要节假日,预估会有流量高峰的时间,安排相关人员值守,重点关注系统水位,比如流量qps,cpu有无异常等,还关注客服响应群,保障有问题时可以及时响应

11、告警

配置核心告警群,把系统核心告警统一到群里,系统相关人需要在群里,需要将重要的业务情况同步播报在群里,系统异常情况告警出来,方便快速发现问题

三、总结

本文结合作者工作中稳定性建设相关的经验做了总结,存在不足欢迎补充或者指正,欢迎大家在评论区分享下自己是如何落地稳定性建设的。

稳定性建设是一个长期的任务,不可能一朝一夕就把稳定性做好,而是需要持续不断的迭代优化。

作为开发人员,我们应该始终对生产系统保持敬畏之心

关注我们一起学习技术吧,坚持相信有输入一定要有输出,希望我们的技术能力越来越强大。

相关文章
|
消息中间件 缓存 监控
系统稳定性建设实践总结
2020年,注定是个不平凡的一年。疫情的蔓延打乱了大家既定的原有的计划,同时也催生了一些在线业务办理能力的应用诉求,作为技术同学,需要在短时间内快速支持建设系统能力并保障其运行系统稳定性。恰逢年终月份,正好梳理总结下自己的系统稳定性建设经验和思考。
系统稳定性建设实践总结
|
运维 监控 算法
稳定性保障6步走:高可用系统大促作战指南!
年年有大促,大家对于大促稳定性保障这个词都不陌生,业务场景尽管各不相同,“套路”往往殊路同归,全链路压测、容量评估、限流、紧急预案等,来来去去总少不了那么几板斧。跳出这些“套路”,回到问题的本质,我们为什么要按照这些策略来做?除了口口相传的历史经验,我们还能做些什么?又有什么理论依据?
稳定性保障6步走:高可用系统大促作战指南!
|
安全
CodeReview:我曾经担任的角色是CodeReviewer
作为开发,在技术领域中,想必大家对CodeReview并不陌生,而且CodeReview被视为保障代码质量的重要环节。那么本文就来简单讨论分享一下CodeReview在代码质量方面的作用,并分享我在担任对应角色时的经历和心得。在开始正题之前,先分享一下关于《一文浅谈CodeReview中的一些思考》的读后感,分享一下仅此而已。
356 3
CodeReview:我曾经担任的角色是CodeReviewer
|
缓存 自动驾驶 物联网
C-RAN——无线接入网架构优化 | 带你读《5G时代的承载网》之十八
C-RAN 是根据现网条件和技术进步的趋势,提出的新型无线接入网构架, 是基于集中化处理(Centralized Processing)、协作式无线电(Collaborative Radio)和实时云计算构架(Real-time Cloud Infrastructure)的绿色无线接 入网构架(Clean System)。其本质是通过实现减少基站机房数量,减少能耗, 采用协作化、虚拟化技术,实现资源共享和动态调度,提高频谱效率,以达到 低成本、高带宽和灵活度的运营。
C-RAN——无线接入网架构优化 | 带你读《5G时代的承载网》之十八
|
canal 关系型数据库 中间件
开源数据同步神器——canal
作为使用最广泛的数据库,如何将mysql的数据与中间件的数据进行同步,既能确保数据的一致性、及时性,也能做到代码无侵入的方式呢?如果有这样的一个需求,数据修改后,需要及时的将mysql中的数据更新到elasticsearch,我们会怎么进行实现呢?
18376 1
|
存储 NoSQL Redis
redis set底层数据结构
set底层存储  redis的集合对象set的底层存储结构特别神奇,我估计一般人想象不到,底层使用了intset和hashtable两种数据结构存储的,intset我们可以理解为数组,hashtable就是普通的哈希表(key为set的值,value为null)。
7449 0
|
5月前
|
canal 缓存 关系型数据库
微服务原理篇(Canal-Redis)
本文介绍了ES索引同步的常见方案,重点讲解Canal+MQ数据同步机制。通过解析MySQL的binlog日志,Canal模拟slave伪装接入主库,实现增量数据捕获,并结合RabbitMQ保证消息顺序性地同步至Elasticsearch。同时探讨了缓存一致性问题,提出使用分布式锁(如Redis)控制并发写操作,避免双写不一致。还涵盖Redis持久化、集群模式、过期淘汰策略及缓存三剑客(穿透、雪崩、击穿)的解决方案,系统梳理了高并发场景下的数据同步与缓存保障技术体系。
415 0
 微服务原理篇(Canal-Redis)
|
设计模式 Java 微服务
你一定要知道业务开发最常用的两种设计模式
文章介绍了业务开发中最常用的两种设计模式:策略模式和异步形式的责任链模式,通过具体案例展示了它们在代码解耦、扩展性增强以及提升响应速度方面的应用,并强调了设计模式在提升代码质量和开发效率中的重要性。
|
存储 运维 监控
运维(24)-运维技能知识图谱
运维(24)-运维技能知识图谱
2555 1