智能路由心酸调优路——看推广代码简洁之道的重要性

甜橙金融作为一个日均订单量过千万的面向C端的互联网金融科技公司，525爆点活动订单量更是平时的好几倍，随着公司业务的高速发展，原有的系统架构，对于业务的支持，越来越力不从心，在公司领导层的大力支持和投入下，基于微服务下的第三代业务架构，经过了很长时间的建设，目前已经全面商用，整体三代架构概要架构如下。

整体架构的优越性在最近一次的525爆点活动中展现的淋漓尽致，但是基于目前生产现状，翼支付大部分客户的消费习惯在于使用翼支付余额，而对于银行卡类交易，生产消费的峰值并不特别显眼，也因此，银行卡消费链路成为了架构升级后大家性能提前感知的一个盲区，对于这一链路的性能，并没有太过关注。
业务是检验系统高可用的最好手段，甜橙金融无线事业群在2018年5月推出了每周一九点工行信用卡满20-10元的爆点活动，随着活动的持续进行，客户感知度越来越高，生产陆续出现了“远程调用异常”的错误，排查下来，发现银行卡交易链路的核心系统，智能路由，成为了整体链路的性能瓶颈，因此引发了接下来为期两周的心酸调优路。

智能路由的心酸调优路

常规套路，第一步一定是拿着生产版本在性能测试环境跑一把，让我们看看我们生产版本在性能环境下的表现，简直是，惨不忍睹！
        分析目前系统代码设计情况，发现代码中存在一个同步接口中，出现了开完的线程池中再开一次线程池，具体情况类似如下：

        离下一个周一只有五天时间了，而重构这个设计并在五天内上线会有相当大的风险，而作为一个大流量金融和支付业务为主的底层平台，我们承担不了一点点可能的业务风险而给用户带来不好的客户体验，所以出于系统稳定考虑，下一个紧急版本暂时不做重构方面的考虑，只在小改动，调整配置的情况下尽量提高系统能力，同步我们会对这种设计进行重构，以从根本上解决该问题，此处暂时不说重构设计的事情，我们先聊聊我们后续的调优路：
        一：因为这个设计，我们结合业务场景考虑，对于两个线程池配置进行评估，在反复调整线程池配置后，我们的压测结果有了一定的进步；
        二：但是结果还没有达到我们的心理预期，继续观察日志和监控，结合代码发现，我们的一些前期理想化的设计并不适用生产，在设计阶段我们将规则库做成了插拔式，随时可以调整和关闭，但是实际上生产上的效果，大部分规则的实现类，单独处理的时间远远小于我们在获取一个线程的时间，所以，我们同步尝试了一些规则库的逻辑合并，效果有进一步的改善；
        三：另外一个耗时的地方在于日志打印，我们发现就算是现在异步打印日志的情况下，日志打印还是过于多了，而由于决策类接口的快速响应要求，我们将部分不合理的日志进行了去除，将部分可以合并的日志改到了一次打印，对于系统性能方面和日志协查方面，有了一定的改善；
        四：同步发现系统过于依赖redis操作，因为此处逻辑改动复杂，这一个版本暂时未做改动。
        结合以上四点中前三点的性能调优，我们的系统并发能力提升了一倍，准备上线该版本，再结合同步加机器的方式，准备迎接下一个周一九点钟的到来。
        优化前的压测数据情况：

        优化后的压测数据情况：

        满怀期待的心情，又到了一个周一的九点钟，结果，还是有超时的情况发生，结合生成系统监控神器pinpoint 观察，我们发现性能瓶颈果然在我们预期中的redis上面，下面，我们开始聊聊我们第二周的调优之路。
        如前文所述，我们前期设计中对于线程池的使用不太合理，这次我们从根本上重新设计了业务流程，将两个线程池缩减成了一个，从源头上解决该问题。另外再谈谈设计中对于redis使用的不合理之处，最开始的设计是，一个key里面以set形式存储了大量的数据，在操作时，使用redis取交集的方式将set中需要的业务数据返回出来，这种设计导致redis成为了我们的瓶颈，并且redis连换成集群的计划都胎死腹中，让程序调优中最low的花钱换能力都变得不可行，基于以上，我们首先重新设计了redis的key的设计规则，将路由过程中用到的大量过滤规则进行整理和合并，减小了每次从redis取出的value的大小，保证每个key对应的value值的大小可控，减少传输过程中对于网络带宽的过度损耗。然后将取交集的操作改到应用中通过特定的算法进行处理，在保证计算效率提高的基础上减小了redis的计算压力和交互次数，最后根据业务场景重新梳理路由逻辑，针对除过滤规则外的特性化规则中查询redis的逻辑进行优化，进一步减少与redis的交互次数；随着持续的加班码代码，压测，我们的系统能力又提升了一倍，并且从根本上解决了单点能力的依赖（redis）。
        在后续的周一爆点活动中，智能路由终于没有再次成为瓶颈，系统调优完成了预定目标，而在十一这一个既是月初又是周一的日子里，银行支付流量在打爆网联专线的情况下，智能路由系统运行情况良好，也从侧面证实了此次调优的效果，而我们整个银行交易能力随着我们不断推进网联专线扩容的进行而逐渐提升，新的架构，新的面貌，不断进步的甜橙金融，在持续做着哪怕一点点的优化，希望能够给我们的用户，带来更加科学、更加友好、更加便捷的交互体验和使用感受。

论推广代码简洁之道的重要性

在此次整个项目的调优过程中，我们发现最大的问题在于我们平时提倡的代码规范没有很好的落地和改进，系统各模块工作职能不清晰，代码注释不到位。虽然有一定的客观原因，但是也不能否定整个排查问题过程中因为代码不够简洁而导致排查问题过慢的客观事实，在这里，我们说一下甜橙技术在2018年7月23号正式发布的《天翼电子商务有限公司 JAVA 版研发规范文档（试行）》（以下简称规范）中的代码分层部分：

        从以上代码分层中可以看出，如果是正常落地的应用，每个模块职能非常清晰，结合合适的注释规范，我们在排查问题的时候将会方便的多，智能路由，在后面的几个常规版本中，花费了很大的力气，将整个应用的代码完全按照代码规范进行了落地，按照学过一个月java的人都能看得懂的标准，进行了彻底的整顿，重构后的智能路由代码，完全符合甜橙技术《规范》要求，在随后几个月的生产问题排查中，已经完全体现了改版后的优势。
        合理即高端，简洁即专业。不是我在业务代码中使用了一个ArrayBlockQueue就代表了我对并发有很深刻的理解，不是我用了什么设计模式就代表了我掌握了java设计模式，很多很多的性能问题，都是我们在不合适的场景用了不合适的技术，所以，我真诚的认为，合理就好，简洁才是王道。
        我们甜橙人，总是在默默的探索最合适我们的技术，推进我们的技术创新，以技术推进业务发展，以技术推进客户体验友好提升。