如今你可以聽到很多關於“微服務”的信息。Spring Boot是一個用來構建單個微服務應用的理想選擇，但是你還需要以某種方式將它們互相聯繫起來。這就是Spring Cloud試圖解決的問題，尤其是Spring Cloud Netflix。它提供了各種組件，比如：Eureka服務發現與Ribbon客戶端負載均衡的結合，為內部“微服務”提供通信支持。但是，如果你想要與外界通信時（你提供外部API，或只是從你的頁面使用AJAX），將各種服務隱藏在一個代理之後是一個明智的選擇。
常規的選擇我們會使用Nginx作為代理。但是Netflix帶來了它自己的解決方案——智能路由Zuul。它帶有許多有趣的功能，它可以用於身份驗證、服務遷移、分級卸載以及各種動態路由選項。同時，它是使用Java編寫的。如果Netflix使用它，那麼它與本地反向代理相比是否足夠快呢？或者當我們對靈活性（或其他功能）要求更高時，它是否適合與Nginx聯合使用。
免責聲明：不要認為這是一個嚴肅的基準。我只是想感受Nginx和Zuul的差異，因為我在互聯網上並沒有找到任何基準（也可能是我沒有搜索足夠長的時間）。它不遵循任何推薦的基準測試方法（預熱時間、測試次數……），我只是使用3個在不同可用區域的EC2實例（這不是最佳的）。
測試
那我做了什麼呢？測試是比較兩種解決方案的原始性能，沒有任何其他特殊的功能。我只是同時發起單個HTTP請求來獲取一個HTML頁面（大小約為26KB）。我使用ApacheBench來發起200個併發線程的測試（我也嘗試了httpperf，但是它需要更高的CPU要求，所以還是選擇了要求更低的ab）。
直接連接
首先，我感興趣的是不通過任何反向代理直接訪問HTTP服務器的性能。Ab在一臺機器上運行，直接訪問目標服務器。
很好，幾次測試都顯示了類似的值：2928、2725、2834、2648 req/s。有一些偏差，但這些數字現在還不重要。
通過Nginx
現在我可以使用Nginx的代理服務。只需要將Nginx配置更新為代理到目標服務器，比如：
像之前一樣運行類型的測試：
測試結果為954、954、941 req/s。性能與延遲（如預期）變差了。
通過Zuul
現在我們在同一臺機器上安裝Zuul。它的應用本身很簡單：
我們還需要在 application.yml中定義固定的路由規則：
現在我們試試運行測試：
結果比我（樂觀的）猜測更差。此外，我們還能看到兩次請求失敗（我們可以在Zuul的日誌中看到有兩個相應的異常，這些異常引發了HTTP連接池超時）。顯然默認情況下超時時間為10秒。
我們再進一步測試，得到了更多的結果：
哇，不錯的改善。我認為Java JIT編譯對於性能有一定的幫助，但是要驗證這是否只是一個巧合，再嘗試一次：1010 req / sec。最終結果對我來說是一個驚喜。
結論
Zuul的原始性能非常接近於Nginx。事實上，在啟動預熱之後，我的測試結果甚至略好一些(重申免責聲明-這並非一個嚴肅的基準性能測試)。Nginx顯示出更多的可預測性能(變化較小），可悲的是在Zuul預熱期間，我們經歷了一些小故障（150000個請求中的2個，但是您的微服務應該是容錯機制的，對吧？）。
所以，如果您考慮使用一些Zuul的額外功能，或者希望通過它與其他Netflix服務集成（比如Eureka）獲得更多的服務能力，Zuul看起來非常有希望作為簡單反向代理的替代產品。也許這也是Netflix使用的原因，所以您也可以嘗試一下。
關注我們：
1.官網：1ke.co
2.公眾平臺：在通訊錄添加，查找公眾號：“wow1ke”，關注我們推送的一系列文章，在公眾號後臺回覆“入會”，小編拉你進入微信學習群
3.個人賬號：在通訊錄添加，搜號碼：“wow1kezhushou”，隨時向我們提問，並關注我們的活動信息和狀態更新