生产环境全链路压测建设历程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论文，实现了自己的链路追踪。也为后续的双十一链路梳理，以及做单元化埋下了铺垫。