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