本文转载于本人的微信公众号中的文章。
目录
背景与挑战
何为系统稳定性
影响系统稳定性因素
如何保障系统稳定性
总结
3月3日凌晨,阿里云宕机故障 --- 惊魂三小时的故障,让华北地区不少公司的APP、网站和内部系统纷纷瘫痪。消息瞬间占领的社交、媒体的头条。有网友调侃道到,“一大波程序员、运营和运维从被窝爬起来去公司干活了”、“ 阿里云一年一宕机,今年特别早”。
拥有雄厚资金、技术和大量的人才的阿里云尚且如此,那么我们中小公司又要如何见招拆招?
在《微服务架构实践》文章中提到,我们面对的业务主要满足两大类业务需求:面向餐饮企业在餐饮新零售下的经营需求、运营需求和面向产品及运营团队。可以理解为我们就是为餐饮企业提供信息化解决方案的ISV。没错就你大脑中浮现的,类似给三大运营商、电力企业等承接做信息化系统的公司。
公司的SaaS平台中,有一条产品线 --- 外卖(此外卖非彼美团、饿了么外卖)姑且称之为“云平台外卖”,我们在哪些方面做了稳定性、又是如何落地的?我们从一个用户视角的订单全生命周期流程中,来看下我们“云平台外卖”处在什么环节:
以普通用户的视角来看,一个外卖订单从下单后,会经历支付、商家接单、配送、用户收货、售后及订单完成多个阶段。
以技术的视角来看,每个阶段依赖于多个子服务紧密配合,确保订单顺利完成。
流程较长且实时性要求高
外卖订单业务是一个需要即时送的业务,对实时性要求很高。从用户订餐到最终送达用户,一般在1小时内。如果最终送达用户时间变长,会带来槽糕的用户体验。
订单量高且集中
一天内订单量会规律变化,订单会集中在中午、晚上两个“饭点”附近,而其它时间的订单量较少。这样,饭点附近系统压力会相对较大。
我们的“云平台外卖”是处在商家接单的环节;商家接单,也是一个非常复杂的处理流程,我们抽象成简单的流程:
我们面临的挑战:
“实时”接单无延迟
“实时”接单无丢单
任何一种情况发生,客户都会面临着营业额减少甚至客户门店被外卖平台关闭的风险。
软件系统的稳定性,很难有一个恰当的模型表述。如果采用数字量化的话,我们也可以采用SLA服务协议说明系统的稳定性。
正所谓“千里之堤,溃于蚁穴”,看似无关紧要的代码片段可能会带来整体软件系统的崩溃。
软件系统稳定性影响因素比较多,我们从软件工程开发过程中,梳理出常见的因素:
我们要在软件设计的阶段,要充分考虑系统稳定性因素;一旦考虑不周,当线上系统面临快速增长的业务时,噩梦就会连连。
负反馈调节法
确定目标,并加入控制条件;根据反馈结果不断调整,朝着可能性空间缩小的方向发展,使目标差在一次次控制中慢慢减少
规范流程
自己不作死
不被队友搞死
多部门间的协作联动
我们从多个方面通过严谨的流程、架构、技术、测试以及运维保障系统等手段来保障系统的稳定性。但是,要保障系统的持续健康运行,还需要多部门间的积极的协助联动。
上述梳理,我们知道线上系统故障主要是:
自身系统的问题
外部系统的问题
基础设施的问题
所有的软件系统问题,最终症结在于架构、产品质量和技术工程方面的问题。需求千万条,质量第一条。架构不合理,开发运维两行泪。
联系客服