NetflixZuul与Nginx的性能对比

如今你可以听到很多关于“微服务”的信息。Spring Boot是一个用来构建单个微服务应用的理想选择，但是你还需要以某种方式将它们互相联系起来。这就是Spring Cloud试图解决的问题，尤其是Spring Cloud Netflix。它提供了各种组件，比如：Eureka服务发现与Ribbon客户端负载均衡的结合，为内部“微服务”提供通信支持。但是，如果你想要与外界通信时(你提供外部API，或只是从你的页面使用AJAX)，将各种服务隐藏在一个代理之后是一个明智的选择。

西峰ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：13518219792（备注：SSL证书合作）期待与您的合作！

常规的选择我们会使用Nginx作为代理。但是Netflix带来了它自己的解决方案——智能路由Zuul。它带有许多有趣的功能，它可以用于身份验证、服务迁移、分级卸载以及各种动态路由选项。同时，它是使用Java编写的。如果Netflix使用它，那么它与本地反向代理相比是否足够快呢?或者当我们对灵活性(或其他功能)要求更高时，它是否适合与Nginx联合使用。

免责声明：不要认为这是一个严肃的基准。我只是想感受Nginx和Zuul的差异，因为我在互联网上并没有找到任何基准(也可能是我没有搜索足够长的时间)。它不遵循任何推荐的基准测试方法(预热时间、测试次数……)，我只是使用3个在不同可用区域的EC2实例(这不是***的)。

测试

那我做了什么呢?测试是比较两种解决方案的原始性能，没有任何其他特殊的功能。我只是同时发起单个HTTP请求来获取一个HTML页面(大小约为26KB)。我使用ApacheBench来发起200个并发线程的测试(我也尝试了httpperf，但是它需要更高的CPU要求，所以还是选择了要求更低的ab)。

直接连接

首先，我感兴趣的是不通过任何反向代理直接访问HTTP服务器的性能。Ab在一台机器上运行，直接访问目标服务器。

 
 
 
    
  
  
  
  1. $ ab -n 10000 -c 200 http://target/sample.html 
    2.   
  
  
  2. .... 
    3.   
  
  
  3. Document Path: /sample.html 
    4.   
  
  
  4. Document Length: 26650 bytes 
    5.   
  
  
  5. Total transferred: 268940000 bytes 
    6.   
  
  
  6. HTML transferred: 266500000 bytes 
    7.   
  
  
  7. Requests per second: 2928.45 [#/sec] (mean) 
    8.   
  
  
  8. Time per request: 68.295 [ms] (mean) 
    9.   
  
  
  9. Time per request: 0.341 [ms] (mean, across all concurrent requests) 
    10.   
  
  
  10. Transfer rate: 76911.96 [Kbytes/sec] received 
    11.   
  
  
  11. Connection Times (ms) 
    12.   
  
  
  12.  min mean[+/-sd] median max 
    13.   
  
  
  13. Connect: 4 33 6.0 32 66 
    14.   
  
  
  14. Processing: 20 35 7.5 35 392 
    15.   
  
  
  15. Waiting: 20 35 6.4 34 266 
    16.   
  
  
  16. Total: 24 68 7.8 66 423 
    17.   
  
  
  17. Percentage of the requests served within a certain time (ms) 
    18.   
  
  
  18.  50% 66 
    19.   
  
  
  19.  66% 67 
    20.   
  
  
  20.  75% 69 
    21.   
  
  
  21.  80% 70 
    22.   
  
  
  22.  90% 74 
    23.   
  
  
  23.  95% 81 
    24.   
  
  
  24.  98% 91 
    25.   
  
  
  25.  99% 92 
    26.   
  
  
  26.  100% 423 (longest request) 
    27.

很好，几次测试都显示了类似的值：2928、2725、2834、2648 req/s。有一些偏差，但这些数字现在还不重要。

通过Nginx

现在我可以使用Nginx的代理服务。只需要将Nginx配置更新为代理到目标服务器，比如：

 
 
 
    
  
  
  
  1. server { 
    2.   
  
  
  2.    listen 80 default_server; 
    3.   
  
  
  3.    listen [::]:80 default_server ipv6only=on; 
    4.   
  
  
  4.    # Make site accessible from http://localhost/ 
    5.   
  
  
  5.    server_name localhost; 
    6.   
  
  
  6.    # allow file upload 
    7.   
  
  
  7.    client_max_body_size 10M; 
    8.   
  
  
  8.    location / { 
    9.   
  
  
  9.       proxy_set_header X-Real-IP $remote_addr; 
    10.   
  
  
  10.       proxy_set_header X-Forwarded-For $remote_addr; 
    11.   
  
  
  11.       proxy_set_header Host $host; 
    12.   
  
  
  12.       proxy_pass http://target:80; 
    13.   
  
  
  13.    } 
    14.   
  
  
  14. } 
    15.

像之前一样运行类型的测试：

 
 
 
    
  
  
  
  1. $ ab -n 50000 -c 200 http://proxy/sample.html 
    2.   
  
  
  2. ... 
    3.   
  
  
  3. Server Software: nginx/1.4.6 
    4.   
  
  
  4. Server Hostname: proxy 
    5.   
  
  
  5. Server Port: 80 
    6.   
  
  
  6. Document Path: /sample.html 
    7.   
  
  
  7. Document Length: 26650 bytes 
    8.   
  
  
  8. Concurrency Level: 200 
    9.   
  
  
  9. Time taken for tests: 52.366 seconds 
    10.   
  
  
  10. Complete requests: 50000 
    11.   
  
  
  11. Failed requests: 0 
    12.   
  
  
  12. Total transferred: 1344700000 bytes 
    13.   
  
  
  13. HTML transferred: 1332500000 bytes 
    14.   
  
  
  14. Requests per second: 954.81 [#/sec] (mean) 
    15.   
  
  
  15. Time per request: 209.465 [ms] (mean) 
    16.   
  
  
  16. Time per request: 1.047 [ms] (mean, across all concurrent requests) 
    17.   
  
  
  17. Transfer rate: 25076.93 [Kbytes/sec] received 
    18.   
  
  
  18. Connection Times (ms) 
    19.   
  
  
  19.  min mean[+/-sd] median max 
    20.   
  
  
  20. Connect: 3 50 11.7 48 114 
    21.   
  
  
  21. Processing: 37 159 11.9 160 208 
    22.   
  
  
  22. Waiting: 36 159 11.9 160 207 
    23.   
  
  
  23. Total: 40 209 10.4 209 256 
    24.   
  
  
  24. Percentage of the requests served within a certain time (ms) 
    25.   
  
  
  25.  50% 209 
    26.   
  
  
  26.  66% 212 
    27.   
  
  
  27.  75% 214 
    28.   
  
  
  28.  80% 216 
    29.   
  
  
  29.  90% 220 
    30.   
  
  
  30.  95% 224 
    31.   
  
  
  31.  98% 232 
    32.   
  
  
  32.  99% 238 
    33.   
  
  
  33.  100% 256 (longest request) 
    34.

测试结果为954、954、941 req/s。性能与延迟(如预期)变差了。

通过Zuul

现在我们在同一台机器上安装Zuul。它的应用本身很简单：

 
 
 
    
  
  
  
  1. @SpringBootApplication 
    2.   
  
  
  2. @Controller 
    3.   
  
  
  3. @EnableZuulProxy 
    4.   
  
  
  4. public class DemoApplication { 
    5.   
  
  
  5.     public static void main(String[] args) { 
    6.   
  
  
  6.         new SpringApplicationBuilder(DemoApplication.class) 
    7.   
  
  
  7.             .web(true).run(args); 
    8.   
  
  
  8.     } 
    9.   
  
  
  9. } 
    10.

我们还需要在 application.yml中定义固定的路由规则：

 
 
 
    
  
  
  
  1. zuul: 
    2.   
  
  
  2.   routes: 
    3.   
  
  
  3.     sodik: 
    4.   
  
  
  4.       path: /sodik/** 
    5.   
  
  
  5.       url: http://target 
    6.

现在我们试试运行测试：

 
 
 
    
  
  
  
  1. $ ab -n 50000 -c 200 http://proxy:8080/sodik/sample.html 
    2.   
  
  
  2. Server Software: Apache-Coyote/1.1 
    3.   
  
  
  3. Server Hostname: proxy 
    4.   
  
  
  4. Server Port: 8080 
    5.   
  
  
  5. Document Path: /sodik/sample.html 
    6.   
  
  
  6. Document Length: 26650 bytes 
    7.   
  
  
  7. Concurrency Level: 200 
    8.   
  
  
  8. Time taken for tests: 136.164 seconds 
    9.   
  
  
  9. Complete requests: 50000 
    10.   
  
  
  10. Failed requests: 2 
    11.   
  
  
  11. (Connect: 0, Receive: 0, Length: 2, Exceptions: 0) 
    12.   
  
  
  12. Non-2xx responses: 2 
    13.   
  
  
  13. Total transferred: 1343497042 bytes 
    14.   
  
  
  14. HTML transferred: 1332447082 bytes 
    15.   
  
  
  15. Requests per second: 367.20 [#/sec] (mean) 
    16.   
  
  
  16. Time per request: 544.657 [ms] (mean) 
    17.   
  
  
  17. Time per request: 2.723 [ms] (mean, across all concurrent requests) 
    18.   
  
  
  18. Transfer rate: 9635.48 [Kbytes/sec] received 
    19.   
  
  
  19. Connection Times (ms) 
    20.   
  
  
  20. min mean[+/-sd] median max 
    21.   
  
  
  21. Connect: 2 12 92.3 2 1010 
    22.   
  
  
  22. Processing: 15 532 321.6 461 10250 
    23.   
  
  
  23. Waiting: 10 505 297.2 441 9851 
    24.   
  
  
  24. Total: 17 544 333.1 467 10270 
    25.   
  
  
  25. Percentage of the requests served within a certain time (ms) 
    26.   
  
  
  26. 50% 467 
    27.   
  
  
  27. 66% 553 
    28.   
  
  
  28. 75% 626 
    29.   
  
  
  29. 80% 684 
    30.   
  
  
  30. 90% 896 
    31.   
  
  
  31. 95% 1163 
    32.   
  
  
  32. 98% 1531 
    33.   
  
  
  33. 99% 1864 
    34.   
  
  
  34. 100% 10270 (longest request) 
    35.

结果比我(乐观的)猜测更差。此外，我们还能看到两次请求失败(我们可以在Zuul的日志中看到有两个相应的异常，这些异常引发了HTTP连接池超时)。显然默认情况下超时时间为10秒。

我们再进一步测试，得到了更多的结果：

 
 
 
    
  
  
  
  1. Document Path: /sodik/sample.html 
    2.   
  
  
  2. Document Length: 26650 bytes 
    3.   
  
  
  3. Concurrency Level: 200 
    4.   
  
  
  4. Time taken for tests: 50.080 seconds 
    5.   
  
  
  5. Complete requests: 50000 
    6.   
  
  
  6. Failed requests: 0 
    7.   
  
  
  7. Total transferred: 1343550000 bytes 
    8.   
  
  
  8. HTML transferred: 1332500000 bytes 
    9.   
  
  
  9. Requests per second: 998.39 [#/sec] (mean) 
    10.   
  
  
  10. Time per request: 200.322 [ms] (mean) 
    11.   
  
  
  11. Time per request: 1.002 [ms] (mean, across all concurrent requests) 
    12.   
  
  
  12. Transfer rate: 26199.09 [Kbytes/sec] received 
    13.   
  
  
  13. Connection Times (ms) 
    14.   
  
  
  14. min mean[+/-sd] median max 
    15.   
  
  
  15. Connect: 2 16 7.9 16 126 
    16.   
  
  
  16. Processing: 15 184 108.1 203 1943 
    17.   
  
  
  17. Waiting: 13 183 105.9 202 1934 
    18.   
  
  
  18. Total: 18 200 107.8 218 1983 
    19.   
  
  
  19. Percentage of the requests served within a certain time (ms) 
    20.   
  
  
  20. 50% 218 
    21.   
  
  
  21. 66% 228 
    22.   
  
  
  22. 75% 235 
    23.   
  
  
  23. 80% 239 
    24.   
  
  
  24. 90% 254 
    25.   
  
  
  25. 95% 287 
    26.   
  
  
  26. 98% 405 
    27.   
  
  
  27. 99% 450 
    28.   
  
  
  28. 100% 1983 (longest request) 
    29.

哇，不错的改善。我认为Java JIT编译对于性能有一定的帮助，但是要验证这是否只是一个巧合，再尝试一次：1010 req / sec。最终结果对我来说是一个惊喜。

结论

Zuul的原始性能非常接近于Nginx。事实上，在启动预热之后，我的测试结果甚至略好一些(重申免责声明-这并非一个严肃的基准性能测试)。Nginx显示出更多的可预测性能(变化较小)，可悲的是在Zuul预热期间，我们经历了一些小故障(150000个请求中的2个，但是您的微服务应该是容错机制的，对吧?)。

所以，如果您考虑使用一些Zuul的额外功能，或者希望通过它与其他Netflix服务集成(比如Eureka)获得更多的服务能力，Zuul看起来非常有希望作为简单反向代理的替代产品。也许这也是Netflix使用的原因，所以您也可以尝试一下。

【本文为专栏作者“翟永超”的原创稿件，转载请通过联系作者获取授权】

文章名称：NetflixZuul与Nginx的性能对比
标题链接：http://www.shufengxianlan.com/qtweb/news40/245040.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

响应式网站知识

同城分类信息

成都网站制作　　 　成都模版网站建设　　 　成都网络推广　　 　广安搬家公司　　 　成都网站代运营　　 　成都雨棚定制　　 　成都网站建设　　 　成都App定制　　 　成都网页设计　　 　成都网站排名　　 　标志设计　　 　德阳电信机房　　 　快照排名　　 　成都ssl证书申请　　 　邛崃做网站　　 　成都免费做网站公司　　 　德阳东方电机技改　　 　雅安服务器托管　　 　成都塑料加工　　 　官网SEO排名