在BSS3.0产品“守成”之策的上篇，我们介绍了BSS3.0在系统架构上做的优化调整工作，但是系统优化不仅仅体现在架构上，在业务流程及系统性能上的持续优化，亦是我们产品“守成”道路上不可或缺的一部分。

性能优化的本质是为了解决良好的用户体验和有限的资源之间的矛盾。系统是为应用提供了运行时环境，性能问题的本质就是系统资源达到了使用的上限，反映在应用层，应用/组件的各项指标开始下降，直接影响到用户体验；而应用/组件的不合理使用和设计，也会加速系统资源的耗尽。因此，在分析瓶颈点时，需要我们结合从不同角度分析出的结果，抽出共性，得到最终的解决办法。

一个系统应用，它不仅包含了应用代码本身，还和容器（虚拟机）、存储、网络、操作系统、文件系统等紧密相关，线上应用一旦出现了性能问题，需要我们从多方面去考虑。

本篇将详细地介绍BSS3.0产品在业务流程及性能优化方面进行的调优策略。

1 串行改并行

命令的传输形式有两种：串行，并行。串行是指一条命令发送下去，得到了应答才继续发送下一条。并行是指有几条命令，不管有没有收到应答，一律转下去，处理器把所有的命令存储起来，然后一条条处理。串行的缺点是用户等待时间长，并行则可能导致某些命令会被丢掉，但用户的命令很快就发送到处理器了，处理效率会比串行有更大的提升。

在业务受理过程中，通常来说复杂的融合业务会比单产品或者单套餐受理更繁琐，无论是操作方面，还是系统后台处理逻辑方面，都有比较大的优化空间。比如我们新推出的礼包受理模式，虽然礼包受理业务是通过打包方式整体售卖，但在操作简单的背后是复杂的后台逻辑支撑，因此对于此类复杂业务还是存在很多优化改造点：

约束多：礼包规格数据多，配置的销售品过多，必然会导致销售品之间的相互约束关系变得更复杂；

规则重复执行：礼包与礼包下的销售品配置的规则会存在重复执行的情况；

跨中心处理逻辑多：礼包实例化过程中存在很多跨中心的逻辑处理。

如果通过传统实例加载方式串行实例化数据，后台逻辑处理需要消耗很长时间，很容易出现加载超时。规格数据的初始化串行执行也是极其消耗系统性能的。因此，梳理并改造可并行执行的业务逻辑成了此项专题工作的重中之重。我们也将受理逻辑做了以下优化：

销售品购买约束校验进行前置：将礼包受理涉及区域、客户、营业厅、营业员、积分、信用度、角色、渠道、工号等约束校验前置到销售品受理实例化之前；

对礼包权限校验进行清理：梳理业务逻辑，将实例化过程中已经校验过购买约束的规则清理；对实例化过程中冗余且无业务意义的规则进行清理；

对获取工号权限登录信息进行优化并缓存：对对象管理器和规则里面存在多次定义登录信息对象处，修改为缓存获取。

剔除重复执行的规则：对于较为复杂配置的大礼包实例化时，监测到实例化过程中规则触发了4000多次。明细变更联动触发链路如图：

在受理操作时，每一个明细增加均会触发一次产品属性。一个较为复杂的礼包，明细的配置比普通销售品要多得多，属性联动处理的规则也是成倍的增加。为此需要增加统一的处理联动处理类，将散落在不同时机的规则触发集中到同一个时机处理。减少了1000次左右的规则调用。

对规格数据进行预加载：礼包销售品实例化一次后，在进行同样的场景受理时耗时会快很多。原因在于规格数据加载缓存机制是按需加载，在第一次受理过程中，每个明细数据的加载都要耗时500ms以上。在进行礼包融合换融合的场景下，循环初始化耗时是非常大的。因此，对于缓存数据的加载，修改成应用启动时，通过多线程加载销售品和产品规格到缓存中，减少了前台第一次受理营业员的等待时间，提升用户感知；

跨中心数据查询结果放入二级缓存：礼包实例化过程中存在跨中心交互，接口查询客户信息和账户信息等，受理过程实则是对同一个客户或者账户ID进行取数，进行了多次重复查询，查一次都耗时在500毫秒以上。跨中心交互数据可以抽象成公共方法，同时把查询结果放入二级缓存（redis和本地缓存），规则里面调用公共查询方法，先从缓存获取，缓存获取不到再调用接口。这样可以减少跨中心接口调用次数，减少耗时；

开发校验类规则并发执行机制：我们将系统中处理类、校验类规则进行了区分，因业务校验规则不存在关联关系，对校验类规则优化成了多线程并发执行校验机制。

通过串行改并行，剔除冗余规则校验，既保留了礼包受理的亮点功能，简化了营业员前台的操作，又减少了营业员的等待时间，性能提升产生了质的飞跃。

2 同步转异步

业务受理场景中，对于涉及到有手机产品的业务，在订单保存前需要调用电信集团上行接口进行业务校验，只有校验通过后才允许进行下一步操作。但是在调用集团上行接口时，汇总了各省份提出的几个痛点：

省内与集团交互是串行处理模式，处理效率较低

各省上行接口触发时机不同，导致生成标准报文的逻辑不统一

各省上行套餐配置较凌乱，需要提供适配层进行数据转换

接口协议较老，还是采用传统的旧协议，而集团现在需要适配新的openAPI 3.0，因此集团在下行接口做解析时需要进行额外改造

各省通过受理中心的大内存对象进行报文分装，比较笨重，封装效率低

各省关于手机产品的规则不统一

BO端到端上传逻辑不统一

处理集团返回费用不统一

基于上述痛点问题，我们在考虑优化方案时，提出了同步改异步模式，同时优化部分协议内容，优化方案主要有：

统一集团上行接口的触发时机，加入异步处理机制；

订单保存过程中，省内保存逻辑和集团调用改为异步模式，省份调用集团接口后，不需要等待集团接口，直接保存订单并跳转到收银台。在收费确认环节再根据集团反馈接口进行拦截，如果集团返回不允许办理，则直接取消订单，如果允许则直接收费确认。在这个过程中，将集团处理的时间和省内的时间并行，大幅减少了系统等待和处理时间；

增加集团上行的接口转换中间层，在转换层通过数据配置映射实现不同省份的省份编码、主数据等内容转换；

统一集团上行接口的触发时机,加入异步处理机制；

废除2.8协议 ，采用集团最新的openapi3.0协议；

统一各省4G上行接口的规则路径和数据封装方法，保证后续新增规则在一处聚拢。

通过此次优化改造后，对比异步前后模式，性能提升51.7% - 83.1%左右！

优化成果展示：

3 系统处理流程优化

部分新产品在研发过程中，还需要承担项目快速交付使用的使命。在这个过程中，多方面的因素会导致部分功能上线方案并未采取最优解，而只是采用了临时迅速的解决方案。虽满足大部分业务场景的使用，但还面临着业务剧增的情况下问题修修补补、层出不穷的现象。因此在系统上线后，需要对一些关键的功能，优化精简代码。为此我们将极简转单、大客户受理等专题，进行了代码重构和调优的工作。

极简受理转单流程重构

极简转单是指营业员在完成订单受理，生成销售订单并收费成功后，需要转成正式的生产实例订单的过程。对于这个关键环节，第一个版本的转单流程直接调用受理中心的接口进行订单保存，因受理能力接口程序复杂，不同场景对受理报文的格式要求不一，导致上线后全省每天基本都还是会有40-60张转单失败订单。为彻底解决这类问题，我们直接将订单保存逻辑进行重构。

１、转单不再调用受理中心的接口，直接重写一套订单入库模块，支持订单的合并分解逻辑。

转单主流程涉及：订单数据准备、客户订单处理、修正业务处理、业务初始化、实例对象构造、订单对象构造、订单确认处理、订单保存前校验及处理、订单提交、返回结果处理等。在改造完成后，我们实现了业务流程可配置化，可根据不同的业务配置相应的流程处理类，对不需要的流程也可以实时下架。

２、整个订单保存逻辑模块作为插件可以独立嵌入。重构后订单保存逻辑更加独立，可灵活配置使用。

３、为了降低改造的影响面，转单失败的单先分流到改造后的流程来实现，稳定后再全部接入到新的改造流程中，让生产系统平滑过度。

大客户受理专题流程优化

大客户受理是指一个集团客户下有几百上千个用户，在大客户受理过户业务、销售品成员变更业务时，由于用户实例数据过多，处理流程过长，会存在受理时间超长的问题，最终导致业务无法办理。针对此类业务，我们设计了一套轻量级受理流程，同时剔除不必要的规则校验。轻量级的受理流程包括：数据处理->过户业务逻辑处理、成员修改逻辑处理->订单保存->订单确认->订单提交->处理结果返回。根据业务侧需要，精简掉部分耗时且不必要的流程代码，极大程度地提升了该场景下的业务性能。

例如销售品修改、过户业务订单录入页面会将每个用户实例属性、可选包、功能产品等信息展示出来，如果大客户所有用户都展示以上信息，页面排列必然变得很长，营业员很难定位到精准的用户实例对其进行成员的变更、添加或者删除操作；通用的页面实例化时，也需要将每个成员的明细信息加载出来，这个过程的耗时必将因为大客户下销售品明细的数量增长遇到超时的问题。

针对此专题，我们重新设计轻量级的受理页面及流程，办理销售品修改、过户业务时，提供两种方式进行业务变更的操作，“前台手工选择”和“批量文件导入”，前者在初始化时，只加载用户的关键几个属性（号码、产权客户等），营业员可以快速定位到需要变更的成员，对其进行删除或修改操作。后者则采用文件导入的方式，批量的增加成员、删除成员或是对其进行过户。

大客户受理专题模块调优后，营业员只需要进行简单的选择、导入等操作，由于本身业务对时效性的要求不是太高，录入信息后，后台自动触发定时任务进行订单提交、订单保存、竣工的处理，同时还提供了处理结果查询页面，营业员只需要定期去查看处理结果，针对失败的业务补全相关信息重新办理即可。

4 SQL调优

针对SQL调优处理，我们约定了涉及到SQL语句的优化或是需求新增的SQL语句，在任务单提交过程中，都必须遵循以下原则：

评估当前SQL语句性能，运用文档记录下来；

与创建查询人沟通编写初衷，制定出合理的性能预期；

建立合理的查询业务目标；

对于来自生产系统的查询，获得了一个 Explain 计划；

如果可行的话，在测试系统上重建环境，并重新运行查询；

对于与查询相关的所有表，确信最近在这些表上执行了 Runstats 或与之等价的远程命令；

确保各个表的重组，以匹配它们的集群索引；

查找 WHERE 子句中索引列上的 SQL 函数，这些函数可能导致优化器忽略了索引；

确保在 WHERE 子句中尽可能使用索引列；

跟踪每一项更改的效果，每次跟踪一项。

上述举措只是列举了SQL调优中常用的策略，出了遵循SQL语句编写规范。很多情况下，对SQL的调优也需要结合业务进行调整。SQL 优化在提升系统性能中是成本最低和优化效果最明显的途径，在SQL调优的路上，需定期地获取系统中的慢sql，结合业务分析sql的不合理性，依照相应的原则对系统中的SQL进行了调优。

5 小结

代码质量一般、业务发展太快、应用架构设计不合理等都将导致性能问题，而性能问题处理起来一般耗时较长、分析链路复杂。仿若医生治病诊断过程中的疑难杂症，也如慢性疾病一般侵蚀着整个系统。虽然“诊治慢性疾病”的策略看似简单，但却如血液一般渗透到系统的每个角落，使得我们的产品一天比一天健康，一天比一天精壮。

在产品进行业务流程和性能优化的工作中，我们也发现系统变慢变复杂的很大部分原因是我们对业务理解和方案设计上的偏差以及部分研发规范未贯彻执行导致的恶果。因此在治标的同时，我们更应该考虑从根本上去考虑，强化业务的理解、系统逻辑的梳理、研发及交付规范的执行等工作都是我们必须要强力去执行的要求。