线上应用的系统优化思路

蘑菇街

起源

但凡有点名气的电商公司，每年双十一都是一场硬仗。双十一意味着短时间内的高流量，所以也对相关的系统稳定性和性能提出了更高的要求。虽然现在的分布式服务架构可以很方便的通过扩容来撑高QPS，但对于技术人员来说，终归是有点需求的，因此会希望在先尽量优化系统的单机性能后，再扩容。

挑战

对于风控而言，一般意味着通过当前用户请求覆盖的各类信息进行综合判定，来抉择用户当前的请求是否正常。这里面，根据场景的不同，有些需要进行大量计算进行规则匹配，有些则需要依靠算法模型。而由于风控的特殊性，基本上接入风控的业务系统与风控的QPS都是1：1的关系，也即风控的系统压力是所有接入风控的业务系统总和。

实现思路

当时做系统优化，主要考虑了以下几个方面。尽可能的减少外部接口调用，尽可能的使用异步而非同步，尽可能的使用缓存以减轻数据库的单点压力。下面分别介绍在这几个方面的成果。
减少外部接口，意味着减少网络交互，虽说在公司内部，但网络交互的开销至少都是1-2ms起步，加上接口处理的时间，在一个请求链路上平均每多一个外部接口调用就会多耗费5-10ms的时间。通过缓存接口结果的方式避免重复调用，优化后，一次典型的请求链路外部接口的请求由8个减少为5个，这里面就减少了几十毫秒的时间。
使用异步而非同步的意义在于，一次请求链路上并非所有的处理过程都是依赖上下文的，将相互之间没有依赖关系的处理过程异步化，以一种类似多线程的方式并行的执行多个处理过程，相比串行而言，能减少的时间就是这些并行任务中耗时最长的请求的时长与所有并行任务累加的时长的差值。这种优化方式也带来了十来毫秒的进步。
使用缓存的重要性不言而喻，数据库一般都有单点压力，因此必须想办法分摊数据库的压力。如果担心缓存的稳定性，可以设计为缓存失效再去读数据库。在这个层面，这次优化做的更多的其实是把一个请求链路中多次请求缓存的请求合并为了一个的mget，测试下来，也减少了数毫秒。
最终，正常请求下的rt由50-60毫秒减至十几毫秒，相当于系统能支撑的QPS提高了数倍，值得欣慰。

总结

系统优化没有标准答案，也不可能只有两三种答案，只是对于我的系统场景，经过这些优化后已经超出预期的目标。但系统持续优化的道路，任重而道远。在不考虑投入产出比的情况下，甚至是无穷无尽的。