上一篇提到淘宝网近十年的稳定性变化历程

其实为了保障核心链路的高稳定性，生产压测是最有效的一个检验手段。

同时仍然需要在从系统透明化、降低强依赖、隔离、降级这些手段来下手

系统透明化

为什么要进行透明可见

1. 如果想做监控告警，就需要暴露出来这个系统哪些接口是重要的，哪些需要告警；

2. 在出现问题的时候，如果系统足够透明，在做问题快速定位分析，是能起到大的帮助的。

3. 在对系统做容量规划的时候，是需要对系统足够了解，才能做好规划。

4. 在考虑能否做降级处理的时候，只有对系统足够了解，才能判断这个系统可否被降级。

如何进行系统透明化

涉及到以下几点

1. 对依赖关系进行梳理，即被谁依赖、依赖谁、内部依赖。

2.线上运行状况监控，包括系统指标、业务指标；比如做秒级、分钟级的性能采集；可以是基于业务接口的日志来做统计分析，也可以是基于数据库的事务日志来做分析，如 Oracle 通过 OGG for kafka 来进行收集，MySQL 可以通过 binlog 来做实时统计分析，结合场景来进行告警。

降低对核心服务的强依赖

读容灾

避免对核心 DB 读的强依赖，可以考虑使用缓存、利用备库。

写容灾，避免对核心 DB 写的强依赖

对于淘宝网来说，影响交易量的，是最核心的链路：

用户登录->浏览商品->加入购物车->保证创建 -> 订单有效 -> 创建支付宝 -> 支付宝付款成功流程成功。

在当时候的设计里面，的确考虑了交易数据库写入异常的情况，但也做了一些预案，如

利用 Notify 做数据恢复、利用本地日志做数据恢复、利用和支付宝对账做数据恢复。

核心应用服务隔离

比如一个订单中心，需要给购物车，已购买订单列表，订单详情等提供服务，在提供服务的时候，是需要依赖缓存、数据库这些下游服务的。

最优雅的方式，是把服务不同场景的服务单独部署。

这三个功能做个排序，购物车是最核心的功能，在出现如数据库访问量过大扛不住的特殊情况，可以通过对已购买和订单详情的应用服务进行降级，来达成确保购物车的正常运转目标。

降级预案改造

淘宝网的下单确认页面，看着简单的一个页面，其实隐含了众多功能（商品库存、积分信息、校验码、确认收货等）。

这个页面，最核心的是下单功能，如果库存信息、积分信息、校验码等有一些异常行为，可能会影响到用户下单。为了确保下单正常服务，非核心功能，都是可以进行临时关闭的。。