敬畏线上环境

“对线上环境要敬畏起来， 不能随随便便地修改啊”。

听到我们要改线上环境的RPC调用的超时时间值时， Boss这样劝阻。

和同事系统运维， 针对一个超时订单处理时，引发出一些有意思的运维知识点，觉得有必要记录下来， 作为运维工作的v0版本， 后续再持续迭代、丰满起来。

业务背景介绍

事情是这样的。

部门维护的系统是， 电商履约中的“京九线”，负责平台99%订单下发给生产终端，今年11.11大促时， 平时下发订单量超过一千万。

大多数的订单下， 很少有超过10个商品的情况。现在随着业务形式越来越多样，会出现某一个订单下上千行商品。

订单履约过程中， 业务上需要对商品上的属性做特殊处理，现在因超时的少量卡单就是这样的超多商品行的订单在遍历处理时耗时过多造成的。

问题处理中的几个层次

回想下， 针对线上超时处理订单的处理上， 有这么几个层次：

1. 修改流程标识，分流订单到一个特殊集群， 让订单快速下发给生产系统。这是为了不影响订单履约时效而采取的紧急处理方式，也是属于先解决线上数据层面。 这个处理过程中， 需要人工参与。 首先是收到报警后， 先分析，确定是因为商品行多超时后，再分流到特殊集群上来。视值班习惯，这样的处理一般需要十分钟左右，也正因为这个人工参与，一方面增大影响用户配送时效风险，另一方面也加大的运维成本。

2. 修改线上正式环境，让对应RPC调用的超时时间跟特殊集群中的设置一样， 足够超多商品的处理用时。这个解决方向， 主要是针对上面第一层解决时，需要人工参与的问题。这样修改后， 订单不会卡单，正常下发给生产终端。但引起了另外的问题，这个大订单处理超时的问题， 没有正面解决， 而是绕过去了。这样的处理方式，平时时系统没有问题，但给大促工作带来的性能隐患，且这样的隐患，因大促离现在时间长， 细节还原起来费时，花的时间会更多。这也是被Boss狠狠Diss的根本原因。

3. 加缓存。具体是， 订单处理后结果写缓存，RPC因超时重试时直接查缓存，如果缓存命中的话， 直接返回。这样考虑的前提是，处理系统已接收大订单，但数据反序列化和业务处理过程中，客户端因超时直接断掉了。于是， 针对这样的场景，加一层缓存，相当于第一次调用时对处理系统下了一个处理任务，虽然RPC调用超时了，但这些的处理任务继续进行着，紧接着RPC的重试时，大概率地看，这个异步任务已处理完成，从缓存中查出快速返回。 应该说， 这是一个还算正面解决的方案。 短期内，也可以接受， 但离真正的解决还有些距离。

4. 完全正面解决。顺着这个方向， 需要静下心来，全面收集数据、仔细分析造成性能问题的具体点，设计各个击破的整体方案，最终从根本上化解掉。当然，这个解决方式也最耗时，又受到数据收集不全、造成问题的因素相互制约等更多方面的原因，中间看不到希望；讨论方案时， 又因各自经验不一、各执一端，难达成一致性方案，让问题的最终解决难上加难。

以上结合业务背景，简要地分析解决性能问题的几个层次， 即快速解决线上问题不影响用户体验、减少人工运维但带来问题的长期隐患、利用缓存快速修复但不彻底、正面解决。这四个层次上，成本依次越来越高，团队的经验和处理问题能力也随着打磨越来越精深，长期来看， 是大大的好事。

另一方面，从问题处理递进关系上看，也是一个服务scalability的具体例子， 关于服务的scalability， 可参见 软件架构师必备的几个思维套路（二） 中“ 服务伸缩性 ”一节的描述。

纸上得来终觉浅，绝知此事要躬行。如果没有这个大订单的性能问题，也不会引发这篇文章的梳理和汇总。

敬畏问题，感谢问题，感谢问题带来的思考与成长~