生产环境全链路压测建设历程4:技术体系的发力

Posted 德华Talk

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了生产环境全链路压测建设历程4:技术体系的发力相关的知识,希望对你有一定的参考价值。

本文写于:2020 年 12 月 09 日


上面第三篇,提到淘宝网09年的痛。

针对上述的痛点,技术体系这块,也从以下五个点进行了发力。

(1)针对监控告警难的问题,做传感式的告警:

1.参考zabbix做了阈值告警,以及连续告警

2.从系统层面去做监控,如核心API的监控,比如当前的调用量是多少,响应时间是多少,报错率是多少。

3.最重要一点,是基于业务指标进行精细监控。如订单创建量曲线图,订单创建金额。商品加入购物车的趋势图。当时候这块,还是基于Oracle来做SQL统计的,在那个阶段,DBA的话语权还是很大的。当年淘宝网有很多Oracle ACE,一个原因是因为淘宝网花了很多钱买Oracle,第二个原因是淘宝网的业务场景太丰富了,要支撑好业务,得对Oracle底层的很多参数了如指掌如数家珍。



(2)针对资源共有引发的很多问题,做好资源隔离:



1.首先是区分核心和非核心的业务。

2.核心里面还可以再分一级核心和二级核心。比如订单中心的应用,可以再细分创建订单的应用分组,订单详情的应用分组,订单列表的应用分组。在极端情况下,是可以降级订单详情和订单列表的。



(3)针对流量不受控的痛点,主要是做好限流降级保护的措施:



1.限流,是参考国家高速公路的管理办法,节假日如果高速流量太大,会关闭一部分入口来确保高速公路正常运行

2.降级,在上一段有提及到,比如订单中心的服务,创建订单、订单列表、订单详情这3个服务,创建订单是最重要的,极端情况下可以关掉订单列表和订单详情的服务。



(4)针对外部环境不受控制的痛点,只能参考银行和运营商的做法,往异地灾备多活的方向去发展:

但在2013年以前,淘宝网做的最多的,还仅仅是异地灾备机房,如数据库做个备库到青岛机房,几乎不承担业务流量的。在2013年的时候,淘宝网开始做真正的异地多活,内部代号是单元化项目。



(5)针对应用关系复杂的痛点,主要还是制定一些架构规范:

1.核心业务,只允许单SQL单表的形式。别看这样一个简单的规则,但起到的作用是非常大的,避免了很多性能事故

2.在2009年的时候,Google的Dapper论文还没发布。那时候还只能是靠Excel来进行梳理。大概是在2011年左右的时候,淘宝网中间件团队就参考Dapper论文,实现了自己的链路追踪。也为后续的双十一链路梳理,以及做单元化埋下了铺垫。


以上是关于生产环境全链路压测建设历程4:技术体系的发力的主要内容,如果未能解决你的问题,请参考以下文章

生产环境上 “全链路压测体系” 建设方案的思考与实践

生产环境全链路压测建设历程1:下了决心持续28天不间断更新

全链路压测体系建设方案的思考与实践

全链路压测体系建设方案的思考与实践

全链路压测体系建设方案的思考与实践

全链路压测体系建设方案的思考与实践