坑爹双十一零点秒杀背后的 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 小时的实时监控，能够通过云智慧的全球监测点对接口调用的可用性、正确性和响应时间进行实时监测，当有问题的时候第一时间获得短信或者电话语音的告警通知，经过分析快照快速定位和解决问题这一切只要在老板知道以前处理掉，今年的优秀员工就是我啦。 最后问一句，谁认识负责“减免计算接口”服务的运维同学？我想和他聊聊去。