前言
API接口響應慢？
SLA一直提不上去？
其實這是后端程序員想進階必須要跨過去的坎：就是把它優化掉。
那么這其中到底有沒有套路呢？答案是：有的。
本文將介紹目前正在用並且十分“無腦”有效的這個套路。
正文
埋點追蹤分析，找出真凶
首先呢，第一部肯定是在關鍵函數(有db、文件、復雜計算等操作)的前后，進行時間的記錄。
此時去找log就可以找到每一步跑的時間。根據實際可以一眼看出是哪一步跑慢了。那么這一步就是主要優化的方向了。
ps:此類對線上接口產生的耗時基本可以忽略，所以放心用。
根據上下文，找到解決方案
既然找到了跑得慢的函數。那么就開始優化吧。
先說前提：前端已有lvs負載均衡、nginx反向代理轉發請求。
首先需要分析為何跑慢了？
1.是不是資源層面的瓶頸？
2.是不是緩存沒添加，如果加了，是不是熱點數據導致負載不均衡？
3.是不是有依賴於第三方接口？
4.是不是接口涉及業務太多，導致程序跑很久？
5.是不是sql層面的問題導致的等待時機加長，進而拖慢接口？
6.網絡層面的原因？帶寬？DNS解析？
7.代碼確實差？？？
8.未知？
暫時就想到這么多，有補充歡迎留言，謝謝。
對症下葯
1.資源緊張，加機器，干上去，負載均衡搞起來
2.加緩存可以解決的問題都不是什么大問題，存在熱點數據可以將某幾個熱點單獨出來用專門的機器進行處理，不要因為局部影響整體
3.一方面與第三方溝通接口響應問題，另一方面超時時間注意把控，如果可以非核心業務能異步久異步掉。
4.把非核心的業務進行異步化操作。記住如果代碼層面是非核心業務，但是會影響用戶感知，需要慎重決定是否異步。
5.如果是代碼不良導致加鎖了，盡量優化索引或sql語句，讓鎖的級別最小（到行），一般來說到行差不多了。如果是單個sql跑慢了，需要分析是不是索引沒加或者sql選的索引錯了，索引該加的就加了，該force index也加了。
6.網路原因，需要聯系運營商一起商量下怎么解決，單方面比較難有大的優化。
7.代碼確實差，那也無葯可救了。我選擇狗帶。