接口优化小思

      

         未雨绸缪

        再有经验的开发者也无法全面对接口性能评估，难免或有疏漏，良好的监控工具，客观的可以查看接口的各个性能。

        公司最近用的是听云第三方的性能管理监控平台来监控各个http接口和dubbo接口，包括web应用过程、数据库、noSQL、外部应用等，可以清晰的看到各个接口调用耗时百分比，响应时间及平均响应时间，吞吐率，错误率，Apdex等，可以直观的看到接口调用情况，及时的优化慢接口。如下图所示

接口优化过程

         一个自己开发的接口或者别人开发的接口，该如何去优化呢？

        往往是带着各种怀疑和疑问开始的

        从代码层次上，是否有重复的调用情况，某些类的某些方法使用是否得当，当时用两个不同的方法都可以的时候，哪个使用会快一些，for语句循环量是否太大，是否可以把for循环里的一些代码抽取出来，是否可能会报空指针异常，是否catch住Exception，返回给客户端的一些字段，哪些是扩展的部分，且消耗时间，可暂时注释掉的等。

        从数据库层次上

        这个接口所涉及到的数据库查询，是否有连接查询，数据库表中的数据是否过大，where查询字段是否添加了索引，索引是否生效，explain查看sql执行效率，是否sql太过复杂，一些业务逻辑应该放到java中，为了减轻db压力是否添加缓存，缓存使用是否合适，对于同时消失的缓存会不会一时间会穿透db。

        从业务逻辑层次上

        代码是否耦合和一个方法中是否业务逻辑过于复杂，一种业务逻辑实现方式，是否可以换另一种思路，产品设计是否有疏漏，是否可以向产品提出，修改一部分已达到最好的用户体验效果。

        能力有限，还有很多没想到的，望提出更多建议，以便在优化代码的时候，考虑的全面些