微盟交易中台系统稳定性建设之路_TakinTalks稳定性技术交流平台

一、前言

交易中台，作为微盟新商业操作系统 WOS 的核心中台之一，前承消费者选择商品，后接消费者下单支付，是消费者线上购物通道中，搭配优惠，计算价格，配送履约，支付下单的必须环节。整个交易场景涉及到跟大量的其他业务域进行系统交互，比如商品，库存，履约，资产，订单，支付，商家，用户，促销，营销等；系统的稳定性面临非常大的挑战，交易中台如何确保能及时的发现上下游系统的问题，并确保自己不受影响，我们进行了全方位立体化的稳定性建设。

二、稳定性思考

1.1、稳定性多维度特性

1.2、稳定性多阶段特性

架构设计原则：
1、封闭修改，欢迎新增，尤其是对外对公的接口等。
2、尽可能通用，减少个性化。
3、能不耦合就不耦合，通过开关等方式做好业务逻辑隔离。
4、业务异常阻断要小心，能阻断就不兼容。
除非兼容逻辑得到业务产品的确认，否则绝对不允许技术自己做业务逻辑兼容。
5、限流，降级，熔断一个都不能少。能熔断就不限流，能限流就不降级，能降级就不回滚。

三、稳定性大盘

四、交易稳定性建设

1、防护策略

第一层：限流策略（超过限流阀值，请求快速失败，流量被拦截在dobbu服务之外）

1）结算：确认下单 & 提交订单都有针对自己实际情况的限流配置
2）购物车：购物车列表，加购，修改购物车也都设置了自己的限流阀值

第二层：熔断策略（1s内出现多少次，N秒内不在调用，针对单个服务做预测保护）

1）结算（确认订单&提交订单）没有配置；（原因，结算是交易最后一步，涉及到金额计算，所有对促销，商品，履约，资产都是不可降级的，不可降级的不配置熔断）
2）购物车（针对下游可降级的接口）有配置；

第三层：超时策略（dubbo接口超时，单次快速失败）

1）结算（确认订单&提交订单），
2）购物车所有涉及到下游接口都有配置，范围在1s～3s之间。

第四层：降级（下游服务不可用，通过开关切断流量，对下游保护，对自己保护）

为了做好这4层防护策略，我们做了以下事情：

1、系统链路强弱依赖梳理，跟产品
2、业务模块降级梳理，跟产品（是否可降级，降级后对系统的影响）
3、业务应急/提前预案梳理，提前预案适合大促活动高峰前降级，应急预案适合在出现问题时使用

2、发现策略

2.1 运行时发现【秒级业务感知上报告警系统】

交易系统是依赖外部业务最多的模块，大概统计了下依赖【依赖应用：40+，依赖接口：100+】。
如此之多的接口依赖，我们必须得有一双能立刻发现问题的眼睛，基于此交易这边做了一个秒级业务监控报警系统。

1、系统硬件的运行情况，CPU，IO，网络这些，通用监控平台可以搞定。
2、业务内部运行情况。
1）通用代码异常，npe，oom 等，通用监控平台可以搞定。
2）业务异常情况，商品无库存，冻结资源失败，通用监控平台无法触及（正常的业务逻辑，产生出不符合预期的结果，这种情况需要及时感知，往往更有价值）。

秒级业务监控报警系统的特色