接口性能优化思路

雨点打透心脏的1/2处 2022-10-24 13:16 218阅读 0赞

## 接口性能优化思路 ##

## 背景 ##

HIS 这边有一个扫码取药的接口，涉及到整个就诊流程：预约–》签到–》开始就诊–》添加处方及药品–》确认处方–》确认账单–》创建交易及订单 --》付款 --》 结束就诊 --》 签退。

整个流程业务非常复杂，涉及接口和远程服务也非常多，因此接口响应很慢，耗时很长。

类似的涉及到整个就诊流程的操作还有很多，比如：核销，也是要走一遍上面的流程，只是在【诊中】的操作不同，可能是添加药品，也可能是添加检查，体检，诊次套餐之类。这类操作每个步骤都非常明确，常常以一个 Pipeline 的形式封装起来，使用了内部自研的一个类似于流程引擎的框架，就叫 pipeline 。总之这类的操作遇到问题都是一样的：就是涉及到流程很复杂很长，接口响应很慢，而且一旦失败还涉及到分布式事物的问题。

目前，分布式事物是依靠自研的 Pipeline 来解决的，每个 Step 相当于一个原子操作，每一步都有一个单独的 rollback 方法进行异常回滚。不涉及长事物，理论上来说分布式事物这块带来的耗时影响是可以忽略的。

那面对这样一个耗时很长的接口应该从哪些方面进行优化呢？

这里拿【扫码取药】接口来举例说明。想知道一个 接口在各个地方的耗时详情，有一个非常方便的地方就是分布式链路追踪系统，我们公司使用的是 Skywalking ，打开 Skywalking 的后台，点击 追踪 搜索该接口，切换 表格 视图，就能看到该次接口请求的所有执行过程以及消耗时间：

![image-20210128144137843][]

有了这个图我们就可以做到有的放矢，针对不同的情况做出相应的处理方式。

## 优化思路 ##

### 1. 同步改异步 ###

这种方法操作起来很简单，效果也很明显，但是并不是所有的耗时操作都能够进行异步处理的，常见的异步场景就是，发送 MQ 通知，发短信等等。如下面 MQ 消费耗时 1254 ms。

![image-20210128145443139][]

如果项目使用 SpringBoot 框架开发，同步改异步将非常简单，只需要加个简单的 `@Async` 注解即可，如下：

@Async
        public void sendOrderMq() { 
        // ...
        }

### 2. SQL 慢查询优化 ###

在 Skywalking 面板中，我们能清晰的看到 每一步 SQL 语句的执行耗时，下面这个接口涉及到一次条用，耗时 1244 ms

![image-20210128161216653][]

查看 SQL 简化如下：

select * from `income` where (`source_no` in (?) and `source_type` = ?)

通过分析 SQL 语句，不用看解释执行计划，就可以猜到，where 查询条件用到了两个条件，但是耗时却有 1240 ms，大概率应该是没有为这两个条件建立索引导致，再去查看该表的 DDL 语句，发现果然只有一个 source\_no 索引，此时为了提升查询效率我们可以为 source\_no 和 source\_type 建立联合索引。建立联合索引的查询耗时为： 42 ms

![image-20210129150043871][]

按照这种思路，一一找出所有的慢查询 SQL 进行优化，能极大的提升性能。

### 3. 避免无谓的模型转换 ###

有这样一种情况，比如 service 层调用 XXXModuleService 层代码，返回了 XXXInfo 模型，比如 PrescriptionOrderInfo 这个处方单模型，里面可能有包含的一些药品以及供应商信息，这些信息是调用了远程服务查询拼装的一个 PrescriptionOrderInfo 模型，但是 service 层的方法可能只需要 处方状态，药品 ID 之类的，这些字段本身处方表就可以获取到，如果再经过一层模型转换显然增加了耗时。解决方案就是 增加一个返回简单模型的接口，比如数据库表对应的 处方模型 Prescription ，这样就能避免模型转换带来的时间损耗。

![image-20210129155047227][]

这也提醒我们，在调用 其它接口时，要做到按需索取，如果遇到查询返回一个非常复杂的模型，而自己只需要用到其中几个关键字段，就要思考是否有更简单的更适合的模型来实现。

### 4. 查询缓存 ###

由于扫码取药涉及多个 pipeline ，流程又很复杂，所以会出现一种情况。就是有一些接口在一次扫码取药操作中会被调用十几次，尤其是那些比较耗时的远程服务，每次耗时高达一两百毫秒，十几次下来性能堪忧。

![image-20210129163952487][]

遇到这种情况，一种可行的方法就是增加缓存，根据入参缓存远程查询结果。需要注意的是，对缓存的接口有较高的要求：比如 不能有易变的状态变量，像处方状态，库存数量这些不要去缓存，一旦缓存失效不及时，会对业务造成严重的 BUG 。并且还要注意，缓存的时间要深思熟虑，一般来说，缓存时间不应大于接口的最大耗时。比如一次扫码取药的操作耗时 10s，那么缓存的时间就设置为 10s 是最适合的。

![image-20210129165000966][]

如上图，缓存key 可以是方法的入参，缓存时间就取整个接口的响应耗时。在 SpringBoot 项目中，实现上面的缓存方案非常容易。我们可以借助 `@Cacheable` 注解，可以作用域方法上，它的作用就是把方法入参当做 key ，把方法返回值作为缓存结果，缓存到 内存数据库如 Redis 中。这个注解有一个参数 cacheNames，就是缓存的 key，我们可以对指定的 key 设置缓存时间。

// 缓存合同的查询结果
        @Cacheable(value = CACHE_FIND_CONTRACT)
        public List<ContractInfo> findCacheableContract(ContractQuery query) { 
           //...
        }

上面的代码对 findCacheableContract 方法进行了缓存，缓存的名称是 `CACHE_FIND_CONTRACT`,key 的值默认是 query。tostring() 方法的结果，缓存 value 是 返回值 List 列表。

现在如果想对 缓存 `CACHE_FIND_CONTRACT`设置缓存时间该怎么做呢？可以参考下面的配置：

private Map<String, RedisCacheConfiguration> _getRedisCacheConfigurationMap(
            RedisTemplate template) { 
            Map<String, RedisCacheConfiguration> redisCacheConfigurationMap = Maps.newHashMap();
    
            // 查询合同的缓存配置
            // @see com.xingren.clinic.member.services.contract.ContractQueryService.findContract
            redisCacheConfigurationMap.put(CACHE_FIND_CONTRACT, this.getRedisCacheConfigurationWithTtl(template, 10));
    
            // 查询药品的缓存配置
            // @see MedicineRemoteService.*
            redisCacheConfigurationMap.put(CACHE_GET_MEDICINE, this.getRedisCacheConfigurationWithTtl(template, 15));
            return redisCacheConfigurationMap;
        }
    
        private RedisCacheConfiguration _getRedisCacheConfigurationWithTtl(RedisTemplate template,
            Integer seconds) { 
            return RedisCacheConfiguration.defaultCacheConfig()
                .serializeValuesWith(
                    RedisSerializationContext.SerializationPair.fromSerializer(template.getValueSerializer()))
                .serializeKeysWith(RedisSerializationContext.SerializationPair
                    .fromSerializer((RedisSerializer<String>) template.getKeySerializer()))
                .entryTtl(Duration.ofSeconds(seconds));
        }

如上代码，分别对 `CACHE_FIND_CONTRACT` 和 `CACHE_GET_MEDICINE` 两个缓存进行了 10s 和 15s 的缓存配置。

至此，经过上面的配置，我们就很容易的实现了对查询结果进行缓存，这种方法对性能的提高也有很大的帮助，尤其是使用本地内存进行缓存的时候。但对缓存的对象有较高的要求，使用时需要慎重。

### 5. 从产品角度出发：改变操作流程 ###

如果以上方法做完后，接口性能还是堪忧，那就说明这个接口确实复杂，耗时不可避免，不放转变下解决思路。

拿扫码取药举例，可以从产品角度改变一下操作流程，用户点击扫码取药之后，后端直接返回，并提供一个单独的查询扫码取药结果的接口，让前端去轮询。这也不失为一个办法。

## 总结 ##

以上就是在优化扫码取药接口时总结的一些优化思路，经过上面的层层优化，测试环境测试，接口性能提升三分之二左右，效果还是很明显的。

最后，个人水平有限，本文仅抛砖引玉，如果你也有好的性能优化思路，可以在评论区留言，一起探讨一下。

[image-20210128144137843]: /images/20221024/04306dc3ac2c49f1a9213f05908b3ace.png
[image-20210128145443139]: /images/20221024/3099ba48f39146bf8c451c1cd67d4bdc.png
[image-20210128161216653]: /images/20221024/8f1717f257ff4e4cba1d7a1790aa2518.png
[image-20210129150043871]: /images/20221024/d828de76a2ff474db54319eca263bef3.png
[image-20210129155047227]: /images/20221024/3ab63fc140ae4fbbbd80825429842233.png
[image-20210129163952487]: /images/20221024/09610f3f323c4c0793db0976f6bfe202.png
[image-20210129165000966]: /images/20221024/19c18be7305846998122e857fec7c6c0.png