您好,登錄后才能下訂單哦!
如何進行zuul的性能分析,相信很多沒有經驗的人對此束手無策,為此本文總結了問題出現的原因和解決方法,通過這篇文章希望你能解決這個問題。
服務過濾
自定義過濾器的實現,需要繼承ZuulFilter,需要重寫實現下面四個方法:
四個具有4個基本特征:過濾類型、執行順序、執行條件、具體操作
filterType:返回一個字符串代表過濾器的類型,在zuul中定義了四種不同生命周期的過濾器類型,具體如下:
pre:可以在請求被路由之前調用
routing:在路由請求時候被調用
post:在routing和error過濾器之后被調用
error:處理請求時發生錯誤時被調用
filterOrder:通過int值來定義過濾器的執行順序
shouldFilter:返回一個boolean類型來判斷該過濾器是否要執行,所以通過此函數可實現過濾器的開關。在上例中,我們直接返回true,所以該過濾器總是生效。
run:過濾器的具體邏輯。需要注意,這里我們通過ctx.setSendZuulResponse(false)令zuul過濾該請求,不對其進行路由,然后通過ctx.setResponseStatusCode(401)設置了其返回的錯誤碼,當然我們也可以進一步優化我們的返回,比如,通過ctx.setResponseBody(body)對返回body內容進行編輯等。
最后,總結一下為什么服務網關是微服務架構的重要部分,是我們必須要去做的原因:
不僅僅實現了路由功能來屏蔽諸多服務細節,更實現了服務級別、均衡負載的路由。
實現了接口權限校驗與微服務業務邏輯的解耦。通過服務網關中的過濾器,在各生命周期中去校驗請求的內容,將原本在對外服務層做的校驗前移,保證了微服務的無狀態性,同時降低了微服務的測試難度,讓服務本身更集中關注業務邏輯的處理。
實現了斷路器,不會因為具體微服務的故障而導致服務網關的阻塞,依然可以對外服務。
Zuul 和 nginx的性能對比
結論:
Zuul的原始性能非常接近于Nginx。事實上,在啟動預熱之后,我的測試結果甚至略好一些(重申免責聲明-這并非一個嚴肅的基準性能測試)。Nginx顯示出更多的可預測性能(變化較小),可悲的是在Zuul預熱期間,我們經歷了一些小故障(150000個請求中的2個,但是您的微服務應該是容錯機制的,對吧?)。
看完上述內容,你們掌握如何進行zuul的性能分析的方法了嗎?如果還想學到更多技能或想了解更多相關內容,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。