坑爹双十一零点秒杀背后的 API 性能问题初探

我很喜欢吃苹果，尤其是新疆阿克苏的冰糖心，这不，快到双十一了，有个店家的优惠力度很很大： 1 份 5 斤才 79 元，第 2 份 1 元，折合 8 块钱 1 斤。所以我早早的就把苹果放进了购物车里，想着香甜的大苹果，定了闹钟，就等着凌晨支付了，。

盼望着盼望着，终于可以支付了，我愉快地拿起手机打开应用支付订单，等支付确认之后，我才发现，貌似店家没有给我优惠哦！怎么两份苹果要了 79*2=158 元呢？真郁闷，这不简直是赤果果的消费欺诈不成？所以我选择退款！必须退！结果更让人崩溃，点击退款之后系统的提示是这样的！

不得不佩服这个店家的服务，一会短信就过来了，店家抱歉说是因为系统因为访问量太大出现了故障，所以可以支付完成之后找店家补差价。哦，原来是这样！本来还以为是店家欺诈呢。

郁闷地打开朋友圈，想发发牢骚，结果看见朋友圈里中招的小伙伴相当多呢。

看了这些顿时精神一震，好歹我也是个高级运维工程师呀，还懂代码开发，就是传说中的 DevOps ，爬起来我开始分析：一般这种商品两件优惠大致有几种策略（可能还有，我买的比较少，没有看到）： 1 ）第 2 份 0 元，就是所谓的五折嘛！ 2 ）第 2 份 1 元，比五折那么一点点； 3 ）第 2 份每斤 1 元； 那么在加入购物车选择结账的时候，系统发生了什么？我猜想是这样的：

按照这个流程来讲的话，就是万恶的“减免计算接口”出现了问题！估计是对应的后端服务宕机了，或者我所在的北京地区的网络出现了问题，导致在调用这个接口的时候出现了异常，不过真心佩服电商平台技术，做了很多的异常判断，明显是当“减免计算接口”出现异常的时候，系统能够继续正常执行，当然此时就第 2 份就不会优惠了。 接口很重要！接口很重要！接口很重要！ 所以在系统上线前有必要对接口进行大规模并发下的压力测试，首先要保障提供接口服务的程序不掉链子，能够抗住那么多流量，其实这样还不够，因为仅仅关注后端是不够的，现在的应用架构太复杂了，网络、 CDN 等都是影响接口正常质量的很重要的因素，所以必须能够在全链路的真实环境下对系统进行压测，这样就能判断哪些地区，哪些运营商可能导致的用户不爽。 正在这时，上海同学告诉我他在凌晨正常下单支付了！好吧，这说明上海并没有受到类似不良接口的影响。 仅仅是全链路压测够不够呢？其实还不够，因为在真实环境下，各种状况层出不穷，瞬息万变，测试做的再好也只能尽可能真实的模拟未来发生的情况，但是实际上还是会有不可预想的事情发生，所以我们还需要监控！比如我就用监控宝的 API 监控把公司应用里的那么多关键接口进行了 7X24 小时的实时监控，能够通过云智慧的全球监测点对接口调用的可用性、正确性和响应时间进行实时监测，当有问题的时候第一时间获得短信或者电话语音的告警通知，经过分析快照快速定位和解决问题——这一切只要在老板知道以前处理掉，今年的优秀员工就是我啦。 最后问一句，谁认识负责“减免计算接口”服务的运维同学？我想和他聊聊去。