接口耗时10秒如何优化为1秒

2022年7月21日倾城 Comments 0条评论 128 人阅读

技术面试中，一定会被问到性能优化有关的问题。这一类问题大多数都是开放性的，考察求职者的知识储备和逻辑思维。我们的脑洞可以开大一点，多说一些解决方案，充分展示自己的能力。

比如这个题：一个接口耗时10秒，如何优化为1秒？ 这个问题脱离实际生产情况，属于八股文。如果生产环境中出现性能低下的接口，通常怎么应对？

根据接口重要性确定是否优化

过早优化是万恶之源。性能优化的目标是，在最合适的性价比下达到理想的性能提升。过度优化会增加系统复杂度和维护成本，使得开发和测试周期变长。如果接口承接着非核心业务，调用方也能忍受目前的耗时，优化工作可以暂缓，比这重要的活儿多得是。

无法精准预测优化后的耗时

优化方案再好，也只能保证优化方向的正确。压测报告出来之前，谁都不能保证采用某方案耗时一定在1秒以内，精确预测结果是不科学的。

确定接口要优化的话，实际开展的步骤是：

接口调研：根据日志确定耗时高是常态，不是偶发性。结合监控系统、链路跟踪系统等工具定位性能瓶颈。
制定方案：结合调用方的需求和开发人员的经验确定优化方案，比如调用方希望耗时在3秒内或者接受异步通知。
实施方案：通过代码重构、引入中间件等方式改造接口，最好包含灰度方案或者动态切换新老逻辑的开关。

回到面试题本身，如何回答这个问题，能让面试官满意呢？这个题目的重点是“优化”和“1秒”，必须说出几种可能的性能瓶颈以及对应优化方案，方案为什么可以降低耗时。

常规业务系统譬如电商、物流都属于数据密集型系统，即数据是系统成败的决定性因素，包括数据的规模、数据的复杂度、数据产生与变化的速率。这类系统对IO的操作频率远远高于CPU，减少IO操作、提高CPU利用率是性能优化的大方向。排除掉网络质量问题，导致接口性能问题的原因很多，下面聊聊性能瓶颈与优化方案。

1.业务逻辑复杂

随着业务的发展，接口逻辑变复杂是难免的，重点是做好复杂度的管理。代码层面上，要充分的模块化，理清核心逻辑与辅助逻辑。如果在接口上叠加新需求，要全盘考虑合理性和扩展性。

接口异步调用

接口异步调用是最直接的方案，耗时都在网络请求和RPC连接上，耗时肯定在1秒内。由于无法同步返回数据，调用方要异步处理结果，增加了系统复杂性。

以常用的RPC框架Dubbo为例，在消费端引用服务时增加async配置即可实现异步调用。如下所示，name为需要异步调用的方法名，async=true表示是否启用：

<dubbo:reference id="asyncOrderService" check="false" interface="com.alibaba.dubbo.demo.AsyncOrderService">
    <dubbo:method name="createOrder" async="true" />
</dubbo:reference>

配置了异步调用，直接调用将返回null：

Order order = asyncOrderService.createOrder(createOrderDto);

通过RpcContext获取Future对象，调用get方法时阻塞获取返回结果：

asyncOrderService.createOrder(createOrderDto);
Future<String> future = RpcContext.getContext().getFuture();
Order order = future.get();

业务异步处理

如果不能接受整个接口异步调用，考虑将部分非核心流程异步执行。比如下单接口包含查库存、生成订单、发送短信三个步骤，发送短信不是核心流程，可以改为发送MQ消息触发短信，能省下一点耗时。

    /**
     * 创建订单
     * @return
     */
    public Order createOrder()
    {
        //查询库存
        ProductStore productStore = productStoreService.queryProductStore(productSkuDto);
        //TODO 判断库存
        //生成订单
        Order order = orderService.createUserOrder(createOrderDto);
        if(order == null) {
            throw new Exception("创建订单失败");
        }
        //TODO 组装短信消息
        //发送订单成功短信MQ
        mqProducer.sendMessage(orderSuccessMsg);
        retrun order;
    }

并行处理

在满足业务逻辑的前提下，将没有关联的步骤由串行改为并行执行。比如有A和B两个步骤，分别耗时200ms和100ms，并行执行后最大耗时就是A的200ms。以下代码演示了Java语言的并行处理，将“查询满100减10信息”和“查询可用优惠券信息”的结果汇总返回给接口。

/**
* 查询购物车优惠活动标签
*/
public void getDiscountActivityTag(CartItemDTO cartItemDTO) {
        ExecutorService executorService = Executors.newCachedThreadPool();
        List<Callable<String>> tasks = Lists.newArrayList();
        tasks.add(new Callable<String>() {
            @Override
            public String call() throws Exception {
                //查询满100减10信息
                 return null;
            }
        });
        tasks.add(new Callable<String>() {
            @Override
            public String call() throws Exception {
                //查询可用优惠券信息
                return null;
            }
        });
        try {
            List<Future<String>> futureList = executorService.invokeAll(tasks, 3000, TimeUnit.MILLISECONDS);
            if(CollectionUtils.isEmpty(futureList) {
                return STR_BLANK;
            }
            //组装优惠活动标签
            return StringUtils.join(futureList,STR_SPLIT);
        } catch (InterruptedException e) {
            logger.info("查询购物车优惠活动标签发生错误",e);
        }
        executorService.shutdown();

        return STR_BLANK;
    }

调整业务流程

从10秒优化到1秒是个不小的挑战，如果没有好的技术方案能够实现，可以尝试调整业务流程。将一个接口做完的事情，拆成两三个接口来做，每个接口的耗时自然就减少了。通过校验业务数据，保证拆分后的接口的顺序调用。

2.数据库读写性能差

系统发展到一定的阶段，单实例的数据库一定无法支撑高并发的读写，优先考虑的应该是索引优化和冷数据归档，分库分表是最后的大招。

冷数据归档：将用户不太关注的历史数据从单表中迁移走，前端提示用户只提供最近N个月数据。保证每个表的数据在一千万左右，查询耗时在0.5秒以内。
索引优化：索引可以大大提高数据的查询速度。索引优化需要重点关注索引失效的原因。如果单表的数据量过大，优化索引也无法改善性能。
数据缓存：读多写少、弱实时性的场景，尝试缓存数据。缓存的介质常常是内存，查询速度远高于数据库的磁盘，提升性能的效果非常明显。常用分布式缓存组件是Redis，二级缓存组件有Guava Cache、Caffeine、Encache，Spring Cache可以集成使用这三者。

参考

https://zhuanlan.zhihu.com/p/464671514
https://blog.csdn.net/itguangit/article/details/113399096

本文链接：https://www.codingbrick.com/archives/834.html
特别声明：除特别标注，本站文章均为原创，转载请注明作者和出处倾城架构，请勿用于任何商业用途。

倾城架构

分享编程与架构知识，探索前沿创新技术

发表评论取消回复

1.业务逻辑复杂

2.数据库读写性能差

发表评论 取消回复

发表评论取消回复