如何進行zuul的性能分析

如何進行zuul的性能分析，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

這里說的是zuul

服務(wù)過濾

自定義過濾器的實現(xiàn)，需要繼承ZuulFilter，需要重寫實現(xiàn)下面四個方法：

        四個具有4個基本特征：過濾類型、執(zhí)行順序、執(zhí)行條件、具體操作

• filterType：返回一個字符串代表過濾器的類型，在zuul中定義了四種不同生命周期的過濾器類型，具體如下：

• pre：可以在請求被路由之前調(diào)用

• routing：在路由請求時候被調(diào)用

• post：在routing和error過濾器之后被調(diào)用

• error：處理請求時發(fā)生錯誤時被調(diào)用

• filterOrder：通過int值來定義過濾器的執(zhí)行順序

• shouldFilter：返回一個boolean類型來判斷該過濾器是否要執(zhí)行，所以通過此函數(shù)可實現(xiàn)過濾器的開關(guān)。在上例中，我們直接返回true，所以該過濾器總是生效。

• run：過濾器的具體邏輯。需要注意，這里我們通過ctx.setSendZuulResponse(false)令zuul過濾該請求，不對其進行路由，然后通過ctx.setResponseStatusCode(401)設(shè)置了其返回的錯誤碼，當然我們也可以進一步優(yōu)化我們的返回，比如，通過ctx.setResponseBody(body)對返回body內(nèi)容進行編輯等。

最后，總結(jié)一下為什么服務(wù)網(wǎng)關(guān)是微服務(wù)架構(gòu)的重要部分，是我們必須要去做的原因：

• 不僅僅實現(xiàn)了路由功能來屏蔽諸多服務(wù)細節(jié)，更實現(xiàn)了服務(wù)級別、均衡負載的路由。

• 實現(xiàn)了接口權(quán)限校驗與微服務(wù)業(yè)務(wù)邏輯的解耦。通過服務(wù)網(wǎng)關(guān)中的過濾器，在各生命周期中去校驗請求的內(nèi)容，將原本在對外服務(wù)層做的校驗前移，保證了微服務(wù)的無狀態(tài)性，同時降低了微服務(wù)的測試難度，讓服務(wù)本身更集中關(guān)注業(yè)務(wù)邏輯的處理。

• 實現(xiàn)了斷路器，不會因為具體微服務(wù)的故障而導(dǎo)致服務(wù)網(wǎng)關(guān)的阻塞，依然可以對外服務(wù)。

Zuul 和 nginx的性能對比

結(jié)論：

Zuul的原始性能非常接近于Nginx。事實上，在啟動預(yù)熱之后，我的測試結(jié)果甚至略好一些（重申免責(zé)聲明-這并非一個嚴肅的基準性能測試）。Nginx顯示出更多的可預(yù)測性能（變化較?。?，可悲的是在Zuul預(yù)熱期間，我們經(jīng)歷了一些小故障（150000個請求中的2個，但是您的微服務(wù)應(yīng)該是容錯機制的，對吧？）。

Zuul處理Cookie和重定向

看完上述內(nèi)容，你們掌握如何進行zuul的性能分析的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！