APM工具由之前的pinpoint切換為sw了，主要還是開發者是國內的，交流起來比較方便，並且社區也比較活躍。少說廢話，下面直接開始。
切換sw后，發現某個實例性能不太好
1、復制一下慢接口的接口名稱，到追蹤里面查詢慢接口的情況
在這里可以清楚看到基本上都需要好幾秒，每次請求。在這個接口里面，做了好幾次數據庫的查詢，其中第一次查詢就3秒以上，用explain SQL語句，看看執行計划，發現了問題
沒有走索引，盡管建立了聯合索引，但是實際在執行查詢的時候，沒有走索引，而這個表的數據有好幾百萬。最簡單的做法就是建一個索引，或者是修改查詢語句，增加FORCE INDEX（索引），讓這個語句強制走這個索引，針對條件建索引后，再看看執行計划，發現已經有了明顯改變。
小科普：mysql的type效率差異順序
type顯示連接使用了何種類型。從最好到最差的連接類型為:
const、eq_reg、ref、range、indexhe和ALL
這里是顯示range， range：這個連接類型使用索引返回一個范圍中的行，比如使用>或<查找東西時發生的情況。
優化后，可以看到執行時間由之前的9秒左右下降到2秒左右
全鏈路的問題診斷和優化
我們知道，現在大部分都是微服務的架構了，但是微服務的問題排查簡直是要人命，特別是在一些服務調用，還是調用的是其他產品線的服務，需要別人幫忙排查的時候，簡直是求爺爺告奶奶的～～～～～。所以全鏈路的問題診斷和分析在微服務的治理中非常重要。這里也是以skywalking為例，看看如何分析和優化
在這里，我們可以看到某個服務基本上都是需要5秒以上（😓），這類請求會拖慢全站，關鍵的時候會導致雪崩效應，使得連接數爆了，所以這類服務必須消滅。
我們打開追蹤的界面，看具體的連接情況
發現這里一共跨了2個應用，里面包含了51個事情（我的天呀，一個又長又臭的事務），紫色的是接口的入口網關層，我們可以看到網關大概是消耗3ms左右，剩下的5秒都是到具體的應用消耗的，網關層面上沒有任何問題。而在業務應用層，可以看到51個事情基本上都是在做redis的處理，get，set和expire，而這些操作基本上都是1ms不到，redis層面是沒有問題的（暫時不管set和expire的不合理問題，起碼性能是好的），我們再觀察一下右邊的圖形，你發現了啥？
哈哈，就是這里了，你發現在做完redis的一個get后，到下一個redis的操作set之間，差不多用了5秒，中間大量的真空。
打開具體的操作，看看是在獲取哪個key里面的內容，方便查找問題
根據這個key，找到具體的代碼，發現獲取到內容后，里面有一個for循環去調用外部服務（汗ing）導致耗時過長，接下來就是具體的邏輯優化了，因為這里主要是講如何利用工具跨應用去全鏈路分析具體問題在哪里。這里只是舉例，只涉及到網關和一個業務應用，實際中會有跨多個應用的調用，主要都接入了skywalking，就可以用這個方法快速定位到是具體哪個應用，哪個邏輯慢或者出問題了。
作者：倫文聚
鏈接：https://www.jianshu.com/p/afc9d3d7eb6e
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。