如果自己写代码，熟悉业务场景，很容易知道性能瓶颈。但是如果你上来优化别人的代码，甚至其他产品线的代码，还是有一些挑战的。最近一直在做这个，接手了优化公司一个业务引擎接口的任务。这里我总结一些优化方法。界面优化分为两步，一是寻找性能热点，二是解决热点。不熟悉代码的时候，发现热点是最难的，找到之后对症下药就容易多了。先说说如何寻找性能热点。1.排查调用链微服务，调用链跟踪可以轻松定位到链路上是哪个环节出现了问题。以确定是别人的界面拖慢了你的速度，还是你自己的界面中的代码有问题；并且调用链反映了线上的真实数据，比跑线下测试数据更有说服力。这里以A->B->C为例，简单说一下调用链中常用的几个参数：TraceID：一个完整??链接的唯一ID。本例中A、B、C分别传入TraceID，ABC中记录的链接日志都使用这个唯一的TraceID，不会改变。BindingID：线程内的ID。本例中，A记录的链接日志中有一个唯一的BindingIDA，BindingIDB和BindingIDCConversationID：分别为B和C中的sessionID。本例中，A调用B，A生成ConversationID传给B，B在返回结果前记下日志，A收到结果后记下日志。这两个日志具有唯一的ConversationID。VirtualPath：用于标识微服务路径Component：用于标识组件，或者微服务的名称CostInMilsecond：记录一次会话花费的时间。客户端启动前开始计时，接收后记录在日志中，服务端返回前记录在日志中。了解了这些参数之后，我们再来看看具体的使用。我们公司使用Kibana作为查询统计工具。那么，我的分析步骤如下：1.判断请求的最长耗时（针对key优化）和中值耗时（针对整体优化）：需要使用Kibana的Visualize功能，指定一个Metric为中值，一个metric是Max，然后根据服务路径进行聚合。在线程中，每个子链接被调用的次数和总耗时。然后看在主链接上花费的时间比例。如果比值比较大，说明链路有问题。比如我最近优化了几个接口。在链接上看到数据库存储过程执行次数多，速度慢，肯定能定位到数据访问的问题。如果比例不多，则继续分析方法内部。二、本地分析1、使用Dottrace方法的内部分析，最重要的是使用合理的参数来驱动被测方法。这里我会选择最耗时的参数来覆盖被测方法的大部分分支，充分暴露问题。还需要注意的是，在正式采样前，先对程序进行预热，即运行一次被测方法，让缓存缓存起来。这更能反映网上的一般情况。2.结果解读Dottrace可以说是非常强大了。它列出了一个方法被调用的次数，耗时，集合操作耗时，系统函数耗时，用户函数耗时。基本上看这张图就知道热点在哪了。3.优化方法总结一旦发现热点，下一步就是对症下药的优化。总结一下优化方法就是：1、循环体中的IO和远程调用改为循环外去重后批量执行，避免重复调用。2.慢数据库查询，优化SQL和索引3.基本、频繁的查询方式，可以将执行结果放在缓存中4.串行远程调用可以改为并行。（谨慎使用，请求高峰期会导致内存暴涨，还可能导致上下文丢失）5.非主进程方法，如发送消息通知、增删会员积分等，改成将消息发送到队列，然后异步消费。
