精华内容
下载资源
问答
  • 采用Keepalived+Nginx解决方案实现高可用的API网关。 2.1 Nginx概述 nginx是一款自由的、开源的、高性能的HTTP服务器反向代理服务器;同时也是一个IMAP、POP3、SMTP代理服务器;nginx可以作为一个HTTP...

    一. 采用Keepalived+Nginx解决方案实现高可用的API网关。

     

    2.1 Nginx概述

    nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器;同时也是一个IMAPPOP3SMTP代理服务器nginx可以作为一个HTTP服务器进行网站的发布处理,另外nginx可以作为反向代理进行负载均衡的实现。这里主要通过反向代理和负载均衡两方面介绍nginx

    2.2反向代理

    反向代理应该是Nginx做的最多的一件事了,什么是反向代理,以下是百度百科的说法:反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器不能直接被外部网络访问,所以需要一台代理服务器,而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境,当然也可能是同一台服务器,端口不同而已。

     

    2.3负载均衡

     

    负载均衡也是Nginx常用的一个功能,负载均衡其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。简单而言就是当有2台或以上服务器时,根据规则随机的将请求分发到指定的服务器上处理,负载均衡配置一般都需要同时配置反向代理,通过反向代理跳转到负载均衡。Nginx支持的负载均衡调度算法方式如下:

     

    weight轮询(默认,常用):接收到的请求按照权重分配到不同的后端服务器,即使在使用过程中,某一台后端服务器宕机,Nginx会自动将该服务器剔除出队列,请求受理情况不会受到任何影响。 这种方式下,可以给不同的后端服务器设置一个权重值(weight),用于调整不同的服务器上请求的分配率。

     

    ip_hash(常用):每个请求按照发起客户端的ip的hash结果进行匹配,这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器,这也在一定程度上解决了集群部署环境下session共享的问题。

     

    fair:智能调整调度算法,动态的根据后端服务器的请求处理到响应的时间进行均衡分配,响应时间短处理效率高的服务器分配到请求的概率高,响应时间长处理效率低的服务器分配到的请求少。

     

    url_hash:按照访问的url的hash结果分配请求,每个请求的url会指向后端固定的某个服务器,可以在Nginx作为静态服务器的情况下提高缓存效率。

     

    2.4 nginx安装及配置

    2.4.1 nginx安装

    实验环境:

    [root@localhost ~]# cat /etc/redhat-release

    CentOS Linux release 7.6.1810 (Core)

    [root@localhost ~]# nginx -v

    nginx version: nginx/1.16.0

    nginx有两种安装方式,yum安装和编译安装,yum安装比编译安装简单很多,这里使用yum安装的方式(http://nginx.org/en/linux_packages.html#stable),首先安装以下依赖:

    [root@localhost ~]# yum install -y gcc gcc-c++ make automake autoconf libtool pcre pcre-devel zlib zlib-devel openssl openssl-devel

    /etc/yum.repo.d/新建nginx.repo文件,文件内容如下所示:

    [root@localhost ~]# vim /etc/yum.repos.d/nginx.repo
    [nginx]
    name=nginx repo
    baseurl=http://nginx.org/packages/centos/6/$basearch/
    gpgcheck=0
    enabled=1

     依次执行yum clean allyum list.

    安装nginx

    [root@localhost ~]# yum install -y nginx

    安装完成之后,nginx的相关文件位置如下:

    [root@localhost ~~]# find / -name nginx
    /etc/rc.d/init.d/nginx
    /etc/sysconfig/nginx
    /etc/logrotate.d/nginx
    /etc/nginx                                #主配置文件
    /usr/lib64/nginx
    /usr/sbin/nginx                        #启动文件
    /usr/share/nginx                      #默认的网页存放位置 
    /var/lib/yum/repos/x86_64/6/nginx
    /var/lock/subsys/nginx
    /var/log/nginx                         #日志位置
    /var/cache/nginx
    /var/cache/yum/x86_64/6/nginx

    安装完成之后,可以先启动下,看看能否访问:

    [root@localhost ~]# service nginx restart
    Stopping nginx:                                             [ OK ]
    Starting nginx:                                             [ OK ]

    [root@localhost ~]# elinks 192.168.30.130:80 --dump   #本机ip注意这里是两个横线
    Welcome to nginx !

    If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.

    For online documentation and support please refer to [1]nginx.org.
    Commercial support is available at [2]nginx.com.

    Thank you for using nginx.

    References

    Visible links
    1. http://nginx.org/
    2. http://nginx.com/

    出现这个,证明安装没问题。

     

    .4.3nginx反向代理测试

    首先在node上创建一个简单的http服务并启动,端口为4001

     

    配置nginx.confserver部分,服务名为localhost,侦听3999端口,代理配置为刚刚node创建的http地址:http://localhost:4001

     

    反向代理成功。

     

     

     

     

     

     

    反向代理成功。

    转载于:https://www.cnblogs.com/wjcoding/p/11299639.html

    展开全文
  • Nginx Nginx由内核模块组成: 内核:仅仅通过查询配置文件与客户端请求URL匹配,启动不同模块完成相应工作...Nginx配置负载均衡后,进入网关网关决定进到哪个真是的web服务器 负载均衡 负载均衡从upstream模块定义

    Nginx

    Nginx由内核和模块组成:

    • 内核:仅仅通过查询配置文件与客户端请求URL匹配,启动不同模块完成相应工作
    • 模块:启动nginx后,模块自动被加载。每个模块都有可能处理某个请求,但是同个请求只能有一个模块完成

    nginx启动后,会有一个Master进程和多个Worker进程。采用异步非阻塞的方式来处理请求。当Nginx上的进程数与CPU核数相同时,进程间切换代价时最小的
    在这里插入图片描述
    Nginx配置负载均衡后,进入网关,网关决定进到哪个真是的web服务器

    负载均衡

    负载均衡从upstream模块定义

        #动态服务器组
        upstream myServer {
            server localhost:8080;  
            server localhost:8081; 
            server localhost:8082; 
            server localhost:8083;  
        }
    

    upstream模块配置完成之后,在server模块中的location中指定反向代理到服务器列表,location的正则有多种规则

    配置网关
    		#所有的请求都跳转到myServer。
            location ~ .*$ {
                index index.jsp index.html;
                # 例如访问 location/test/1  请求会被转发到 myServer/test/1
                proxy_pass http://myServer;
            }
    
    负载均衡策略 描述
    轮询 默认方式
    weight 权重方式
    ip_hash 依据ip分配方式
    least_conn 最少连接方式
    fair(第三方) 响应时间方式
    url_hash(第三方) 依据URL分配方式

    缺省采用的就是轮询策略
    weight默认值是1;数值与访问比率成正比

        #动态服务器组
        upstream myServer {
            server localhost:8080   weight=2;  
            server localhost:8081;  
            server localhost:8082   backup;  
            server localhost:8083   max_fails=3 fail_timeout=20s;  
        }
    
    
        upstream dynamic_zuoyu {
            ip_hash;    #保证每个访客固定访问一个后端服务器
            server localhost:8080   weight=2;  
            server localhost:8081;  
            server localhost:8082; 
            server localhost:8083   max_fails=3 fail_timeout=20s; 
        }
    

    负载均衡调度的状态

    • dowm:当前的server暂时不参与负载均衡。
    • backup:预留的备份服务器。
    • max_fails:允许请求失败的次数。
    • fail_timeout:经过max_fails失败后,服务器暂停的时间。
    • max_conns:限制最大的接收连接数。

    zuul

    Zuul 的核心是一系列的过滤器。可以扩展很多功能,例如:

    • 动态路由:动态的将客户端请求路由到后端不同的不同服务
    • 请求监控:记录详细请求响应日志、访问量、监控状态等
    • 认证权限:对每一个访问的请求做认证,拒绝非法请求
    • 压力测试
    • 静态响应
    • 负载削减
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
    </dependency>
    
    #hhh是自定义名称,当访问路径是/test/**时,会把请求转发到demo项目中
    zuul.routes.hhh.path=/test/**
    zuul.routes.hhh.service-id=demo
    

    默认的转发规则就是“API 网关地址+访问的服务名称+接口 URI”
    不需要添加上边的配置。但是都要结合eureka使用。不然无法找到服务
    也可以直接定义url

    zuul.routes.hhh.path=/hhh/**
    zuul.routes.hhh.url=http://www.baidu.com  #访问/hhh/*** 会跳转到这个网址
    
    ZuulFilter

    ZuulFilter的四个方法:

    1. shouldFilter
      是否执行该过滤器,true 为执行,false 为不执行,这个也可以利用配置中心来实现,达到动态的开启和关闭过滤器。
    2. filterType
      过滤器类型,可选值有 pre、route、post、error。
    3. filterOrder
      过滤器的执行顺序,数值越小,优先级越高。
    4. run
      执行自己的业务逻辑。

    过滤器的四种类型:

    1. pre
      可以在请求被路由之前调用。适用于身份认证的场景,认证通过后再继续执行下面的流程。
    2. route
      在路由请求时被调用。适用于灰度发布场景,在将要路由的时候可以做一些自定义的逻辑。
    3. post
      在 route 和 error 过滤器之后被调用。这种过滤器将请求路由到达具体的服务之后执行。适用于需要添加响应头,记录响应日志等应用场景。
    4. error
      处理请求时发生错误时被调用。在执行过程中发送错误时会进入 error 过滤器,可以用来统一记录错误信息。

    自定义ip过滤器

    public class IpFilter extends ZuulFilter {
        // IP黑名单列表
        private List<String> blackIpList = Arrays.asList("127.0.0.1");
        public IpFilter() {
            super();
        }
        @Override
        public boolean shouldFilter() {
            return true
        }
        @Override
        public String filterType() {
            return "pre";
        }
        @Override
        public int filterOrder() {
            return 1;
        }
        @Override
        public Object run() {
            RequestContext ctx = RequestContext.getCurrentContext();
            String ip = IpUtils.getIpAddr(ctx.getRequest());
            // 在黑名单中禁用
            if (StringUtils.isNotBlank(ip) && blackIpList.contains(ip)) {
            	// false,zuul不会将请求转发到后台服务
                ctx.setSendZuulResponse(false);
                ResponseData data = ResponseData.fail("非法请求 ", ResponseCode.NO_AUTH_CODE.getCode());
                // 返回数据给客户端
                ctx.setResponseBody(JsonUtils.toJson(data));
                ctx.getResponse().setContentType("application/json; charset=utf-8");
                return null;
            }
            return null;
        }
    }
    

    启用自定义的ip过滤器

    @Configuration
    public class FilterConfig {
        @Bean
        public IpFilter ipFilter() {
            return new IpFilter();
        }
    }
    
    展开全文
  • 基于Openresty和NGINX的高性能API网关。 目录 地位 当前项目被认为可以投入生产。 快速开始 单机版 $ docker run --name= " apigateway " \ -p 80:80 \ -e " LOG_LEVEL=info " \ adobeapiplatform/apigateway:...
  • 基于nginxapi网关

    万次阅读 2015-12-21 17:41:23
    基于nginxAPI网关,主要功能有: 1、支持api自注册自注销 2、对api服务器具有负载均衡 3、对api服务器具有高可用 4、API网关本身支持横向扩展
    一、业务背景分析
    前一段时间,需要开发一套业务系统,此系统需要对外统一提供api服务,但这些服务在内部是由多个业务子系统分别提供。
    经过分析,此业务系统需要具有以下这么几个特性


    1、不同的api服务由不同的子系统负责
    2、每一个服务之间是相互独立的
    3、每一个服务都需要支持横向扩展和负载均衡
    4、每一个服务都需要高可用


    这么一分析,我们发现这里需要一个api网关,这个api网关需要具有以下几个特点:
    1、api服务器自注册,需要满足以下两个特点(当然也可以由运维在api网关管理平台上进行管理,此部分不影响本文的技术探讨,这里不进行详细的描述)
       1)新增一个服务时,api服务器可以将相应的服务自注册到api网关上
       2)某服务新增一个服务器或删除一个服务器时,api服务器可以在进行自注销或自注册
    2、api网关需要支持对同一个服务子系统的多个服务器进行负载均衡
    3、api网关需要支持对同一个服务子系统的多个服务器中的故障服务器进行检测和切换,也就是高可用
    4、api网关系统本身需要支持横向扩展


    二、方案的选择
    对于任何团队来讲,方案不一定是自己开发的就是最好的(牛A和牛C之间的技术团队除外),需要综合考虑各种因素,这个API网关也不例外,中间经历了一点曲折,过程如下:


    1、系统是部署在云上面的(具体的云这里就不透露了),原本想着看这个云服务端是否有提供此功能服务,不过遗憾的是此云未提供此服务(好像亚马逊云有提供,没有用过不知道怎么样)
    2、使用开源的方案,在开源方案上找到了一个叫kong的方案,此方案是基于nginx的反向代理开发的一套方案,经过调研,此套方案不支持负载均衡和高可用方案(当然不是很深入的调研),此方案本身是基于nginx的lua扩展模块进行开发的,对于api网关的配置是使用cassandra数据库进行存储,对于团队的技术背景来说,这个不是那么合适。(ps:团队本身还不是很强大,业务工作量比较多,整个团队对lua和cassandra没什么积累,在这个场合下除非此方案能直接用,并且有较多的资料,否则只能舍弃掉)

    3、自主开发一套,经过对各服务子系统的接口分析,发现直接使用nginx的反向代理和负载均衡来实现也不是那么复杂,所以这个方案这么诞生了


    三、使用nginx作为api网关的调研
    对于nginx的反向代理和负载均衡的资料网上已经有很多,这里就不废话了,直接看调研过程
    这里假设nginx的配置文件目录为/etc/nginx/
    1、配置的考虑
      考虑到nginx的配置文件大小有要求,所以在这里不把配置直接写入到nginx.conf,而是在nginx.conf里面去include其他目录,比如
      在/etc/nginx/目录下新建api_servers.d目录和api_rules.d目录,分别用来存放api服务器的相关配置和api服务代理规则的相关配置,在http配置项中增加一行配置include /etc/nginx/api_servers.d/*.conf;
      在提供网关服务的server中增加一行include /etc/nginx/api_rules.d/*.conf;


    2、配置负载均衡和反向代理
       在/etc/nginx/api_servers.d/目录下新增一个文件api_test_servers.conf,内容如下
       upstream api_testa_server {
           server 192.168.1.101:80 weight=1 max_fails=3 fail_timeout=20;
           server 192.168.1.102:80 weight=1 max_fails=3 fail_timeout=20;
           server 192.168.1.103:80 weight=2 max_fails=3 fail_timeout=20;
       }


       upstream api_testb_server {
           server 192.168.1.104:80 weight=1 max_fails=3 fail_timeout=20;
           server 192.168.1.105:80 weight=1 max_fails=3 fail_timeout=20;
       }


       在/etc/nginx/api_rules.d/目录下新增一个文件api_test_rule.conf(这里以简单的url匹配来举例)
       location ~(^\/ws\/apitesta)(.*) {
           proxy_set_header Host $host:$server_port;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_buffering off;#缓存在其他文章中会讨论,在这里暂只讨论基本的功能,所以直接使用off
           proxy_pass http://api_testa_server;
       }
       
       location ~(^\/ws\/apitestb)(.*) {
           proxy_set_header Host $host:$server_port;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_buffering off;
           proxy_pass http://api_testb_server;
       }
      nginx服务reload使配置生效


    3、测试过程
     nginx服务器的地址是192.168.1.100,服务的端口为80端口,测试过程如下
    1)、 执行wget http://192.168.1.100/ws/apitesta/phpinfo和wget http://192.168.1.100/ws/apitestb/phpinfo
    分别重复执行此命令20次,查看192.168.1.101-105这5台web服务器的web访问日志,发现101-103的/ws/apitesta/phpinfo访问量分别为5、5、10,104和105的web访问日志里面对/ws/apitestb/phpinfo的访问量都是10次
    2)、 关闭192.168.1.102和192.168.1.104,重复上述测试过程,发现两个url均可正常访问


    四、网关的搭建
    从上述的调研结果来看,使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用,那么我们需要解决的就是自注册的问题和网关本身的扩展性。
    对于自注册和自注销这个问题,对于我们的业务系统来说,业务的上线与下线本身不是一个特别频繁的事情,所以直接在api网关上搭建一个简单的web服务即可,我们称之为api网关系统,api网关系统基本功能如下:
    1、注册或注销时需要重新生成nginx的反向代理和负载均衡配置文件(也就是上述的api_rules.d和api_servers.d目录下的文件),并且网关服务器需要对nginx执行reload操作
    2、需要对api服务的相关信息做持久化存储
    除了上述两个基本功能还需要网关本身支持横向扩展,这个仔细分析一下无非就是需要以下两个问题
    1、在任一个网关服务器上注册或注销一个api服务或一个api服务的一个服务器时都需要通知到所有的网关服务器,所有的网关服务器都需要重新生成配置并且reload各自的nginx服务,显然的我们想到了消息队列里面的topic消息(消息队列的高可用等特性在这里不进行特别延伸),所有的api网关服务器共用同一个消息队列即可满足此要求
    2、所有的网关服务器需要共同同一个网关配置信息,这个无非是共用一个数据库(数据库的高可用等特性在这里不进行特别延伸)


    api服务器自注册至生效主要流程如下:


    所有的网关服务器共用一个消息队列,共用同一个存储数据库,各网关服务器上的网关信号处理进程向消息队列订阅相关的消息,当api服务器向网关服务器集群中的某一台服务器进行注册时,所有的网关服务器都会收到reload消息,会从同一个数据库中读取同一个配置,然后重新生成nginx反向代理和负载均衡的相关配置文件,接着reload各自的nginx服务,当然这里面的网关信号处理进程启动时也会重新生成相关的配置。

    至此一个基于nginx的API网关完成了,当然此文只介绍了一个实用性的主体思路,一些细节层面在这里暂不做过多描述,因为nginx的资料在网上其实已经很多了。

    展开全文
  • 到目前为止,我们一直在整体应用程序之前使用Nginx作为API网关,但是我们想在微服务转换的背景下重新评估我们的决定。我们关心性能,易扩展性附加功能,例如速率限制。第一步是评估替代方案在重负荷下的性能,以...

    3 月,跳不动了?>>> hot3.png

    0*DJgZyCP0LbCsyuhA.

    作为OpsGenie,我们在员工人数和产品功能方面都在积极发展。为了给您一些想法,我们的工程团队从去年的15人增加到了50人。为了扩大开发团队,我们遵循“ 两个比萨饼”团队的规则将工程能力划分为八人团队。

    如您所料,我们当前的产品有些单片。在团队的并行开发工作,CI / CD(连续集成/连续交付)流程等方面,开发和操作它具有挑战性。我们正在顺应当前趋势,并致力于从整体式架构过渡到微服务架构。你可以阅读更多关于微服务架构和Martin Fowler的它的好处文章。

    有一些建议的体系结构模式可用于应用微服务概念。这些模式之一是API网关。API网关是所有客户端的单个入口点。API网关以两种方式之一处理请求。某些请求仅被代理/路由到适当的服务。它通过扇出多个服务来处理其他请求。

    API网关模式是微服务架构的一个很好的起点,因为它可以将特定的请求路由到我们从整体中分离的不同服务。实际上,API网关对我们来说不是一个新概念。到目前为止,我们一直在整体应用程序之前使用Nginx作为API网关,但是我们想在微服务转换的背景下重新评估我们的决定。我们关心性能,易扩展性和附加功能,例如速率限制。第一步是评估替代方案在重负荷下的性能,以确保它们的规模足以满足我们的需求。

    在此博客文章中,我们解释了如何设置测试环境并比较替代API网关的性能:Zuul 1NginxSpring Cloud GatewayLinkerd。实际上,我们还有其他选择,例如Lyft的EnvoyUnderTow。我们将使用这些工具执行类似的测试,并在以后的博客文章中分享结果。

    Zuul 1对我们来说似乎很有希望,因为它是用Java开发的,并得到Spring框架的大力支持。已经有一些博客文章将Zuul与Nginx进行了比较,但是我们还想评估Spring Cloud Gateway和Linkerd的性能。此外,我们计划执行进一步的负载测试,因此我们决定设置自己的测试工作台。

    为了独立评估API网关的性能,我们创建了独立于OpsGenie产品的隔离测试环境。我们使用了Apache Http Server基准测试工具-ab作为基准测试。

    我们首先根据官方Nginx文档将Nginx安装到AWS EC2 t2.micro实例。该环境是我们的初始测试环境,我们在此环境中添加了Zuul和Spring Cloud Gateway安装。Nginx Web服务器托管静态资源,我们为Nginx,Zuul和Spring Cloud Gateway定义了Web服务器的反向代理。我们还启动了另一个t2.micro EC2来执行请求(客户端EC2)。

     
    1*7i5HJqjThG8HayxKMqOizQ.png

    初始测试环境

    图中的虚线箭头是我们的测试路径。其中有四个:

    • 直接访问
    • 通过Nginx反向代理访问
    • 通过Zuul访问
    • 通过Spring Cloud Gateway访问
    • 通过Linkerd访问

    我们知道您不耐烦看到结果,因此让我们先给出结果,然后再给出详细信息。

    绩效基准摘要

    测试策略

    我们使用了Apache HTTP Server Benchmarking工具。每次测试运行时,我们使用200个并发线程发出10,000个请求。

    ab -n 10000 -c 200 HTTP:// <服务器地址> / <资源路径>

    我们对三种不同的AWS EC2服务器配置进行了测试。我们在每个步骤中缩小了测试用例,以进一步阐明:

    • 我们仅在第一步中执行了其他直接访问测试,以查看代理的开销,但是由于直接访问不是我们的选择,因此我们没有在后续步骤中执行此测试。
    • 由于Spring Cloud Gateway仍未正式发布,因此我们仅在最后一步对其进行了评估。
    • Zuul在第一次通话后的后续通话中表现更好。我们认为这可能是由于在第一次调用时执行了JIT(及时)优化,因此我们将Zuul运行的第一个调用称为“预热”。下表汇总表中显示的值是预热性能之后的值。
    • 我们知道Linkerd是资源密集型代理,因此我们仅在最后一步将它与最高资源配置进行了比较。

    测试配置

    T2.Micro —单核CPU,1GB内存:我们对直接访问,Ngnix反向代理和Zuul(预热后)进行了测试。

    M4.Large —双核CPU,8GB内存:我们比较了Nginx反向代理和Zuul(预热后)的性能。

    M4.2xLarge — 8核心CPU,32GB内存:我们比较了Nginx反向代理,Zuul(预热后),Spring Cloud Gateway和Linkerd的性能。

    检测结果

    性能基准摘要如下:

     
    0*KUIIWlngbnDUDvLA.
     
    0*nBUn2N0zyQO1hxbB.

    测试细节

    直接访问请求

    首先,我们直接访问静态资源而没有任何代理。结果如下。每个请求的平均时间为30毫秒。

     
    0*qe6PHoRbu1cX5Bsz.

    直接访问静态资源

    通过Nginx反向代理访问

    在第二个测试中,我们通过Nginx反向代理访问资源。每个请求的平均时间为40毫秒。可以说Nginx反向代理与上一节中说明的直接访问相比平均增加了%33的开销。

     
    0*frGSL8d_ESeBdTa8.

    Ngnix反向代理的性能

    通过Zuul反向代理访问

    之后,我们使用主方法创建了一个Spring Boot Application:

     
    0*RPBkouP4tP2jmck6.

    Zuul的Spring Boot主要应用

    这是我们的application.yml文件:

    0*UAg8FJ-AA_AyHgXc.?q=20
    0*UAg8FJ-AA_AyHgXc.

    初始Zuul测试的结果如下:

     
    0*7BHgzDUqtEbWX2tF.

    Zuul反向代理首次运行性能

    对于Nginx,每个请求的直接访问时间和Nginx反向代理的时间分别为30ms和40ms。每次运行Zuul的每次请求时间为388ms。如其他博客文章所述,JVM预热可能会有所帮助。重新测试后,得到以下结果:

     
    0*AWVE0S7VCU-fRCQr.

    预热后的Zuul反向代理

    预热后,Zuul代理的性能更好(每个请求的时间为200毫秒),但与得分为40毫秒的Nginx反向代理相比,效果仍然不佳。

    如果我们将服务器升级到m4.large怎么办?

    如图1所示,服务器是t2.micro ec2,它具有单个内核和1GB内存。Nginx是本机C ++应用程序,而Zuul是基于Java的。我们知道Java应用程序有点:)要求更高。因此,我们将服务器更改为具有两个CPU核心和8GB内存的m4.large实例。

    我们再次运行了Nginx和Zuul反向代理测试,结果如下:

     
    0*0ydKXWS9NL3TJtcU.

    M4.large上的Nginx反向代理

     
    0*dyDjL-n5xpPD-bpJ.

    m4.large上的Zuul反向代理(预热后)

    如上图所示,Nginx和Zuul的每秒请求值分别为32ms和95ms。这些结果比t2.micro上的40ms和200ms测试结果要好得多。

    一个有效的批评是,我们通过Spring Boot应用程序使用Zuul引入了额外的开销。如果我们将Zuul作为独立的应用程序运行,则很有可能会更好地执行。

    如果将服务器升级到m4.2xlarge怎么办?

    我们还将评估具有八个内核和32GB内存的m4.2xlarge服务器。下图给出了Ngnix和Zuul的结果:

     
    0*GSueuDzrOfv8Crz0.

    M4.2xlarge服务器上的Nginx反向代理

     
    0*m-XCEhrth7DWbST5.

    M4.2xlarge服务器上的Zuul反向代理

    Zuul在m4.2xlarge服务器上的性能优于Ngnix。我们进行了一些研究,以找出Netflix用于托管Zuul实例的ec2实例类型,但是找不到任何有关它的信息。在一些博客文章中,人们抱怨Zuul的性能,并询问Netflix如何扩展它。我们认为这就是答案;据说,Zuul受CPU限制:)

    Linkerd的基准

    LinkerdCloud Native Computing Foundation的成员项目。它是在Scala中开发的服务网格应用程序。除了服务网格功能(例如服务发现)以外,它还提供反向代理功能。我们评估了Linkerd的性能,并在下面给出结果。Linkerd的表现与Zuul非常接近。

     
    0*Sbc2qSDOGt_zAA19.

    m4.2xlarge服务器上的Linkerd反向代理

    Spring Cloud Gateway基准

    Spring Cloud社区也在开发网关模块。尽管尚未正式发布,但我们认为值得将其与其他替代产品进行比较。因此,我们根据测试环境修改了网关应用程序的示例应用程序。

    我们使用Apache Http Server Benchmarking Tool进行了相同的性能测试,该工具使用200个并发线程发送10,000个请求。结果如下图所示:

     
    0*KxPk_3lmNkHsIm-t.

    m4.2xlarge服务器上的Spring Cloud Gateway

    如图所示,Spring Cloud Gateway每秒可以处理873个请求,每个请求的平均时间为229ms。根据我们的测试,Spring Cloud Gateway的性能无法达到Zuul,Linkerd和Nginx的水平,至少在当前基于Github的代码库中是如此。Nginx,Zuul,Linkerd和Spring Cloud Gateway的比较已在“基准摘要”部分末尾给出。

    下一步是什么?

    在此博客文章中,我们将Zuul,Nginx,Linkerd和Spring Cloud Gateway与Apache Http Server Benchmarking工具 ab的性能进行了比较。我们计划要遵循的下一步是:

    • 我们将评估特使。实际上,Envoy不仅仅是一个API网关;它是一个服务网格,但它也提供了可以在应用程序前端使用的API网关。
    • Undertow还具有反向代理功能,因此我们也将对其进行评估。
    • Netflix将Zuul重新设计为基于Netty的非阻塞应用程序。这个新版本称为“ Zuul 2”。每当正式发布新Zuul的开源版本时,我们将进行基准测试并分享结果。
    • Spring Cloud Gateway仍在开发中。它是用Java开发的基于Netty的非阻塞网关,因此对我们来说是一个不错的选择。我们将评估其正式版本的性能。
    • 一些API网关(Zuul 1,Ngnix)处于阻塞状态,而其他(Zuul 2,Linkerd,Envoy)处于非阻塞状态。阻塞体系结构有利于简单的开发和跟踪请求,但是阻塞性质会导致可伸缩性问题。非阻塞架构在开发和可跟踪性方面更为复杂,但在可伸缩性和弹性方面则更好。我们将决定稍后将使用阻塞还是非阻塞架构。
    • 我们将使用Gatling执行测试。我们将在下一篇博客文章中分享结果。

    我们将在后续的博客文章中分享每一步的结果,敬请期待!

    展开全文
  • 文中针对 Nginx、ZUUL、Spring Cloud、Linkerd 、kong等技术进行了对比(其实还有 Envoy UnderTow 也是属于可选的 API 网关,本文不予涉及),那我就分别进行介绍,当然,首先得介绍 API 网关API 网关 API ...
  • NGINX公司的目标是成为“值得信赖的顾问”,并为想要应用软件负载均衡器、摄取网关和服务网格的公司提供方便,因为这正巧符合他们公司当前的技术方向和目标。\\NGINX产品管理部门的VP Rabsatt表示,基于开源和商用...
  • 34、nginx模拟API网关

    2020-05-18 22:29:50
    正向代理,“它代理的是客户端,代客户端发出请求”,是一个位于客户端原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始...
  • 作者:李佶澳转载请保留:原文地址发布时间:2018-09-29 15:41:50 +0800 说明 Nginx Nginx配置文件,指令与变量 Nginx作为TCP/UDP负载均衡器 Nginx模块...
  • Nginx nginx的安装(windows为例)这里用的是稳定版本:nginx-1.20 官网下载,注意保存路径不要有中文 解压运行根目录下nginx.exe 访问localhost:80出现Nginx欢迎界面表示启动成功 修改配置文件:找到http下的...
  • 前言 Spring Cloud在云服务微服务中扮演很重要的角色,而Spring Cloud的组件ZUUL 网关API也发展使用很广。最近无意中了解ZUUL ,网上查了查资料,发现了这篇文章,这里转载一下。 原文 ...
  • API网关和注册中心API区别如何配合

    千次阅读 2020-03-05 12:16:53
    有些架构里加一层专门的网关,屏蔽内网地址,做负载均衡 注册中心地址对API采用别名管理也屏蔽,有什么区别,如何配合使用? nginx也能做网关,他们能混合使用么? ...
  • Orange是一个基于OpenResty的API网关。除Nginx的基本功能外,它还可用于API监控、访问控制(鉴权、WAF)、流量筛选、访问限速、AB测试、动态分流等。它有以下特性: 提供了一套默认的Dashboard用于动态管理各种功能...
  • OpenResty api 网关

    2018-05-31 20:46:00
    Orange是一个基于OpenResty的API网关。除Nginx的基本功能外,它还可用于API监控、访问控制(鉴权、WAF)、流量筛选、访问限速、AB测试、动态分流等。它有以下特性: 提供了一套默认的Dashboard用于动态管理各种功能...
  • API网关之Kong网关简介

    2020-07-31 16:26:11
    它是一个开源的API网关,或者你可以认为它是一个针对API的一个管理工具。你可以在那些上游service之上,额外去实现一些功能。Kong是开源的,所以你可以在Github找到它,你现在就可以下载使用。 Kong是一款基于...
  • APISIX是云原生的微服务API网关,可为所有API微服务提供最终的性能,安全性,开源可扩展平台。 APISIX基于Nginx和etcd。 与传统的API网关相比,APISIX具有动态路由插件热加载功能,特别适合微服务系统下的API...
  • 为您提供APIOAK分布式API网关下载,APIOAK 是基于 OpenResty 平台的高性能分布式API网关。APIOAK 提供API发布、管理、运维的全生命周期管理。辅助用户简单、快速、低成本、低风险的实现微服务聚合、前后端分离、系统...
  • 开源API网关Kong

    2020-06-05 19:37:04
    开源API网关Kong Kong 是一个在 Nginx 运行的 Lua 应用程序,由 lua-nginx-module 实现。Kong OpenResty 一起打包发行,其中已经包含了 lua-nginx-module。OpenResty 不是 Nginx 的分支,而是一组扩展其功能的...
  • API 网关并非一个新兴的概念,在十几年前就已经存在了,它的作用主要是作为流量的入口,统一的处理业务相关的请求,让请求更加安全、快速准确的得到处理。它有以下传统的功能: 反向代理负载均衡,这 ...

空空如也

空空如也

1 2 3 4 5 ... 16
收藏数 314
精华内容 125
关键字:

api网关和nginx