這是一篇翻譯，關于大家經常質疑的一個問題：API網關Zuul的性能。
原文：NETFLIX ZUUL VS NGINX PERFORMANCE
作者：STANISLAV MIKLIK
如今你可以聽到很多關于“微服務”的信息损俭。Spring Boot是一個用來構建單個微服務應用的理想選擇，但是你還需要以某種方式將它們互相聯系起來蕉毯。這就是Spring Cloud試圖解決的問題呆万，尤其是Spring Cloud Netflix。它提供了各種組件磺送，比如：Eureka服務發(fā)現與Ribbon客戶端負載均衡的結合驻子，為內部“微服務”提供通信支持。但是估灿，如果你想要與外界通信時（你提供外部API崇呵，或只是從你的頁面使用AJAX），將各種服務隱藏在一個代理之后是一個明智的選擇馅袁。
常規(guī)的選擇我們會使用Nginx作為代理域慷。但是Netflix帶來了它自己的解決方案——智能路由Zuul。它帶有許多有趣的功能，它可以用于身份驗證犹褒、服務遷移抵窒、分級卸載以及各種動態(tài)路由選項。同時叠骑，它是使用Java編寫的李皇。如果Netflix使用它，那么它與本地反向代理相比是否足夠快呢宙枷？或者當我們對靈活性（或其他功能）要求更高時疙赠，它是否適合與Nginx聯合使用。
免責聲明：不要認為這是一個嚴肅的基準朦拖。我只是想感受Nginx和Zuul的差異圃阳，因為我在互聯網上并沒有找到任何基準（也可能是我沒有搜索足夠長的時間）。它不遵循任何推薦的基準測試方法（預熱時間璧帝、測試次數……）捍岳，我只是使用3個在不同可用區(qū)域的EC2實例（這不是最佳的）。
測試
那我做了什么呢睬隶？測試是比較兩種解決方案的原始性能锣夹，沒有任何其他特殊的功能。我只是同時發(fā)起單個HTTP請求來獲取一個HTML頁面（大小約為26KB）苏潜。我使用ApacheBench來發(fā)起200個并發(fā)線程的測試（我也嘗試了httpperf银萍，但是它需要更高的CPU要求，所以還是選擇了要求更低的ab）恤左。
直接連接
首先贴唇，我感興趣的是不通過任何反向代理直接訪問HTTP服務器的性能。Ab在一臺機器上運行飞袋，直接訪問目標服務器戳气。
$ ab -n 10000 -c 200 http://target/sample.html
....
Document Path: /sample.html
Document Length: 26650 bytes
Total transferred: 268940000 bytes
HTML transferred: 266500000 bytes
Requests per second: 2928.45 [#/sec] (mean)
Time per request: 68.295 [ms] (mean)
Time per request: 0.341 [ms] (mean, across all concurrent requests)
Transfer rate: 76911.96 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 33 6.0 32 66
Processing: 20 35 7.5 35 392
Waiting: 20 35 6.4 34 266
Total: 24 68 7.8 66 423
Percentage of the requests served within a certain time (ms)
50% 66
66% 67
75% 69
80% 70
90% 74
95% 81
98% 91
99% 92
100% 423 (longest request)
很好，幾次測試都顯示了類似的值：2928巧鸭、2725瓶您、2834、2648 req/s纲仍。有一些偏差呀袱，但這些數字現在還不重要。
通過Nginx
現在我可以使用Nginx的代理服務郑叠。只需要將Nginx配置更新為代理到目標服務器夜赵，比如：
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
# Make site accessible from http://localhost/
server_name localhost;
# allow file upload
client_max_body_size 10M;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_pass http://target:80;
}
}
像之前一樣運行類型的測試：
$ ab -n 50000 -c 200 http://proxy/sample.html
...
Server Software: nginx/1.4.6
Server Hostname: proxy
Server Port: 80
Document Path: /sample.html
Document Length: 26650 bytes
Concurrency Level: 200
Time taken for tests: 52.366 seconds
Complete requests: 50000
Failed requests: 0
Total transferred: 1344700000 bytes
HTML transferred: 1332500000 bytes
Requests per second: 954.81 [#/sec] (mean)
Time per request: 209.465 [ms] (mean)
Time per request: 1.047 [ms] (mean, across all concurrent requests)
Transfer rate: 25076.93 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 3 50 11.7 48 114
Processing: 37 159 11.9 160 208
Waiting: 36 159 11.9 160 207
Total: 40 209 10.4 209 256
Percentage of the requests served within a certain time (ms)
50% 209
66% 212
75% 214
80% 216
90% 220
95% 224
98% 232
99% 238
100% 256 (longest request)
測試結果為954、954锻拘、941 req/s油吭。性能與延遲（如預期）變差了击蹲。
通過Zuul
現在我們在同一臺機器上安裝Zuul。它的應用本身很簡單：
@SpringBootApplication
@Controller
@EnableZuulProxy
public class DemoApplication {
public static void main(String[] args) {
new SpringApplicationBuilder(DemoApplication.class)
.web(true).run(args);
}
}
我們還需要在 application.yml中定義固定的路由規(guī)則：
zuul:
routes:
sodik:
path: /sodik/**
url: http://target
現在我們試試運行測試:
$ ab -n 50000 -c 200 http://proxy:8080/sodik/sample.html
Server Software: Apache-Coyote/1.1
Server Hostname: proxy
Server Port: 8080
Document Path: /sodik/sample.html
Document Length: 26650 bytes
Concurrency Level: 200
Time taken for tests: 136.164 seconds
Complete requests: 50000
Failed requests: 2
(Connect: 0, Receive: 0, Length: 2, Exceptions: 0)
Non-2xx responses: 2
Total transferred: 1343497042 bytes
HTML transferred: 1332447082 bytes
Requests per second: 367.20 [#/sec] (mean)
Time per request: 544.657 [ms] (mean)
Time per request: 2.723 [ms] (mean, across all concurrent requests)
Transfer rate: 9635.48 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 12 92.3 2 1010
Processing: 15 532 321.6 461 10250
Waiting: 10 505 297.2 441 9851
Total: 17 544 333.1 467 10270
Percentage of the requests served within a certain time (ms)
50% 467
66% 553
75% 626
80% 684
90% 896
95% 1163
98% 1531
99% 1864
100% 10270 (longest request)
結果比我（樂觀的）猜測更差婉宰。此外歌豺，我們還能看到兩次請求失敗（我們可以在Zuul的日志中看到有兩個相應的異常心包，這些異常引發(fā)了HTTP連接池超時）类咧。顯然默認情況下超時時間為10秒。
我們再進一步測試蟹腾，得到了更多的結果：
Document Path: /sodik/sample.html
Document Length: 26650 bytes
Concurrency Level: 200
Time taken for tests: 50.080 seconds
Complete requests: 50000
Failed requests: 0
Total transferred: 1343550000 bytes
HTML transferred: 1332500000 bytes
Requests per second: 998.39 [#/sec] (mean)
Time per request: 200.322 [ms] (mean)
Time per request: 1.002 [ms] (mean, across all concurrent requests)
Transfer rate: 26199.09 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 16 7.9 16 126
Processing: 15 184 108.1 203 1943
Waiting: 13 183 105.9 202 1934
Total: 18 200 107.8 218 1983
Percentage of the requests served within a certain time (ms)
50% 218
66% 228
75% 235
80% 239
90% 254
95% 287
98% 405
99% 450
100% 1983 (longest request)
哇痕惋，不錯的改善。我認為Java JIT編譯對于性能有一定的幫助娃殖，但是要驗證這是否只是一個巧合值戳，再嘗試一次：1010 req / sec。最終結果對我來說是一個驚喜炉爆。
結論
Zuul的原始性能非常接近于Nginx堕虹。事實上，在啟動預熱之后芬首，我的測試結果甚至略好一些(重申免責聲明-這并非一個嚴肅的基準性能測試)赴捞。Nginx顯示出更多的可預測性能(變化較小）郁稍，可悲的是在Zuul預熱期間赦政，我們經歷了一些小故障（150000個請求中的2個，但是您的微服務應該是容錯機制的耀怜，對吧恢着？）。
所以封寞，如果您考慮使用一些Zuul的額外功能然评，或者希望通過它與其他Netflix服務集成（比如Eureka）獲得更多的服務能力，Zuul看起來非常有希望作為簡單反向代理的替代產品狈究。也許這也是Netflix使用的原因，所以您也可以嘗試一下盏求。
&
&
&
作者：程序猿DD-翟永超
版權歸作者所有抖锥，轉載請注明出處
