我们使用K6用100个并发跑1000次测试的结果如上图，我们看到直连的综合响应，每秒可以处理的请求数量大概是 1100+

Nginx

Nginx是异步框架的网页服务器，也可以用作反向代理、负载平衡器和HTTP缓存。该软件由伊戈尔·赛索耶夫创建并于2004年首次公开发布。2011年成立同名公司以提供支持。2019年3月11日，Nginx公司被F5 Networks以6.7亿美元收购。

Nginx有以下的特点

1. 由C编写，占用的资源和内存低，性能高。
2. 单进程多线程，当启动nginx服务器，会生成一个master进程，master进程会fork出多个worker进程，由worker线程处理客户端的请求。
3. 支持反向代理，支持7层负载均衡（拓展负载均衡的好处）。
4. 高并发，nginx是异步非阻塞型处理请求，采用的epollandqueue模式
5. 处理静态文件速度快
6. 高度模块化，配置简单。社区活跃，各种高性能模块出品迅速。

 

如上图所示，Nginx主要由Master，Worker和Proxy Cache三个部分组成。

• Master 主控：
  NGINX遵循主从架构。它将根据客户的要求为Worker分配工作。将工作分配给Worker后，Master将寻找客户的下一个请求，因为它不会等待Worker的响应。一旦响应来自Worker，Master就会将响应发送给客户端

• Worker 工作单元：
  Worker是NGINX架构中的Slave。每个工作单元可以单线程方式一次处理1000个以上的请求。一旦处理完成，响应将被发送到主服务器。单线程将通过在相同的内存空间而不是不同的内存空间上工作来节省RAM和ROM的大小。多线程将在不同的内存空间上工作。

• Cache 缓存：
  Nginx缓存用于通过从缓存而不是从服务器获取来非常快速地呈现页面。在第一个页面请求时，页面将被存储在高速缓存中。

为了实现API的路由转发，需要只需要对Nginx作出如下的配置：

server {
    listen 80 default_server; 

    location /goapi {
        rewrite ^/goapi(.*) $1 break;
        proxy_pass  http://goapi:8080;
    }

    location /nodeapi {
        rewrite ^/nodeapi(.*) $1 break;
        proxy_pass  http://nodeapi:8080;
    }

    location /flaskapi {
        rewrite ^/flaskapi(.*) $1 break;
        proxy_pass  http://flaskapi:8080;
    }

    location /springapi {
        rewrite ^/springapi(.*) $1 break;
        proxy_pass  http://springapi:8080;
    }
}

我们基于不同的服务goapi，nodeapi，flaskapi和springapi，分别配置一条路由，在转发之前，需要利用rewrite来去掉服务名，并发送给对应的服务。

使用容器把ngnix和后端的四个服务部署在同一个网络下，通过网关连接路由转发的。Nginx的部署如下：

version: "3.7"
services:
  web:
    container_name: nginx
    image: nginx
    volumes:
      - ./templates:/etc/nginx/templates
      - ./conf/default.conf:/etc/nginx/conf.d/default.conf
    ports:
      - "8080:80"
    environment:
      - NGINX_HOST=localhost
      - NGINX_PORT=80
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 256M
        reservations:
          memory: 256M

K6通过Nginx网关的测试结果如下：

 

每秒处理的请求数量是1093，和不通过网关转发相比非常接近。

从功能上看，Nginx可以满足用户对于API网关的大部分需求，可以通过配置和插件的方式来支持不同的功能，性能非常优秀，缺点是没有管理的UI和管理API，大部分的工作都需要手工配置config文件的方式来进行。商业版本的功能会更加完善。

Kong

Kong是基于NGINX和 OpenResty的开源API网关。

Kong的总体基础结构由三个主要部分组成：NGINX提供协议实现和工作进程管理，OpenResty提供Lua集成并挂钩到NGINX的请求处理阶段，而Kong本身利用这些挂钩来路由和转换请求。数据库支持Cassandra或Postgres存储所有配置。

 

Kong附带各种插件，提供访问控制，安全性，缓存和文档等功能。它还允许使用Lua语言编写和使用自定义插件。Kong也可以部署为Kubernetes Ingress并支持GRPC和WebSockets代理。

NGINX提供了强大的HTTP服务器基础结构。它处理HTTP请求处理，TLS加密，请求日志记录和操作系统资源分配（例如，侦听和管理客户端连接以及产生新进程）。

NGINX具有一个声明性配置文件，该文件位于其主机操作系统的文件系统中。虽然仅通过NGINX配置就可以实现某些Kong功能（例如，基于请求的URL确定上游请求路由），但修改该配置需要一定级别的操作系统访问权限，以编辑配置文件并要求NGINX重新加载它们，而Kong允许用户执行以下操作：通过RESTful HTTP API更新配置。Kong的NGINX配置是相当基本的：除了配置标准标头，侦听端口和日志路径外，大多数配置都委托给OpenResty。

在某些情况下，在Kong的旁边添加自己的NGINX配置非常有用，例如在API网关旁边提供静态网站。在这种情况下，您可以修改Kong使用的配置模板。

NGINX处理的请求经过一系列阶段。NGINX的许多功能（例如，使用C语言编写的模块）都提供了进入这些阶段的功能（例如，使用gzip压缩的功能）。虽然可以编写自己的模块，但是每次添加或更新模块时都必须重新编译NGINX。为了简化添加新功能的过程，Kong使用了OpenResty。

OpenResty是一个软件套件，捆绑了NGINX，一组模块，LuaJIT和一组Lua库。其中最主要的是ngx_http_lua_module一个NGINX模块，该模块嵌入Lua并为大多数NGINX请求阶段提供Lua等效项。这有效地允许在Lua中开发NGINX模块，同时保持高性能（LuaJIT相当快），并且Kong用它来提供其核心配置管理和插件管理基础结构。

Kong通过其插件体系结构提供了一个框架，可以挂接到上述请求阶段。从上面的示例开始，Key Auth和ACL插件都控制客户端（也称为使用者）是否应该能够发出请求。每个插件都在其处理程序中定义了自己的访问函数，并且该函数针对通过给定路由或服务启用的每个插件执行kong.access()。执行顺序由优先级值决定-如果Key Auth的优先级为1003，ACL的优先级为950，则Kong将首先执行Key Auth的访问功能，如果它不放弃请求，则将执行ACL，然后再通过将该ACL传递给上游proxy_pass。

由于Kong的请求路由和处理配置是通过其admin API控制的，因此可以在不编辑底层NGINX配置的情况下即时添加和删除插件配置，因为Kong本质上提供了一种在API中注入位置块（通过API定义）和配置的方法。它们（通过将插件，证书等分配给这些API）。

我们使用以下的配置部署Kong到容器中（省略四个微服务的部署）

version: '3.7'

volumes:
  kong_data: {}

networks:
  kong-net:
    external: false

services:
  kong:
    image: "${KONG_DOCKER_TAG:-kong:latest}"
    user: "${KONG_USER:-kong}"
    depends_on:
      - db
    environment:
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_ADMIN_LISTEN: '0.0.0.0:8001'
      KONG_CASSANDRA_CONTACT_POINTS: db
      KONG_DATABASE: postgres
      KONG_PG_DATABASE: ${KONG_PG_DATABASE:-kong}
      KONG_PG_HOST: db
      KONG_PG_USER: ${KONG_PG_USER:-kong}
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_PG_PASSWORD_FILE: /run/secrets/kong_postgres_password
    secrets:
      - kong_postgres_password
    networks:
      - kong-net
    ports:
      - "8080:8000/tcp"
      - "127.0.0.1:8001:8001/tcp"
      - "8443:8443/tcp"
      - "127.0.0.1:8444:8444/tcp"
    healthcheck:
      test: ["CMD", "kong", "health"]
      interval: 10s
      timeout: 10s
      retries: 10
    restart: on-failure
    deploy:
      restart_policy:
        condition: on-failure
    
  db:
    image: postgres:9.5
    environment:
      POSTGRES_DB: ${KONG_PG_DATABASE:-kong}
      POSTGRES_USER: ${KONG_PG_USER:-kong}
      POSTGRES_PASSWORD_FILE: /run/secrets/kong_postgres_password
    secrets:
      - kong_postgres_password
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "${KONG_PG_USER:-kong}"]
      interval: 30s
      timeout: 30s
      retries: 3
    restart: on-failure
    deploy:
      restart_policy:
        condition: on-failure
    stdin_open: true
    tty: true
    networks:
      - kong-net
    volumes:
      - kong_data:/var/lib/postgresql/data
secrets:
  kong_postgres_password:
    file: ./POSTGRES_PASSWORD

数据库选择了PostgreSQL

开源版本没有Dashboard，我们使用RestAPI创建所有的网关路由：

	curl -i -X POST http://localhost:8001/services 
  		--data name=goapi 
  		--data url='http://goapi:8080'
	curl -i -X POST http://localhost:8001/services/goapi/routes 
		--data 'paths[]=/goapi' 
  		--data name=goapi

需要先创建一个service，然后在该service下创建一条路由。

使用K6压力测试的结果如下：

 

每秒请求数705要明显弱于Nginx，所以所有的功能都是有成本的。

APISIX

Apache APISIX 是一个动态、实时、高性能的 API 网关， 提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。

APISIX于2019年4月由中国的支流科技创建，于6月开源，并于同年10月进入Apache孵化器。支流科技对应的商业化产品的名字叫API7 ：）。APISIX旨在处理大量请求，并具有较低的二次开发门槛。

APISIX的主要功能和特点有：

• 云原生设计，轻巧且易于容器化
• 集成了统计和监视组件，例如Prometheus，Apache Skywalking和Zipkin。
• 支持gRPC，Dubbo，WebSocket，MQTT等代理协议，以及从HTTP到gRPC的协议转码，以适应各种情况
• 担当OpenID依赖方的角色，与Auth0，Okta和其他身份验证提供程序的服务连接
• 通过在运行时动态执行用户功能来支持无服务器，从而使网关的边缘节点更加灵活
• 支持插件热加载
• 不锁定用户，支持混合云部署架构
• 网关节点无状态，可以灵活扩展

从这个角度来看，API网关可以替代Nginx来处理南北流量，也可以扮演Istio控制平面和Envoy数据平面的角色来处理东西向流量。

APISIX的架构如下图所示：

 

APISIX包含一个数据平面，用于动态控制请求流量；一个用于存储和同步网关数据配置的控制平面，一个用于协调插件的AI平面，以及对请求流量的实时分析和处理。

它构建在Nginx反向代理服务器和键值存储etcd的之上，以提供轻量级的网关。它主要用Lua编写，Lua是类似于Python的编程语言。它使用Radix树进行路由，并使用前缀树进行IP匹配。

使用etcd而不是关系数据库来存储配置可以使它更接近云原生，但是即使在任何服务器宕机的情况下，也可以确保整个网关系统的可用性。

所有组件都是作为插件编写的，因此其模块化设计意味着功能开发人员只需要关心自己的项目即可。

内置的插件包括流控和速度限制，身份认证，请求重写，URI重定向，开放式跟踪和无服务器。APISIX支持OpenResty和Tengine运行环境，并且可以在Kubernetes的裸机上运行。它同时支持X86和ARM64。

我们同样使用Docker Compose来部署APISIX

version: "3.7"

services:
  apisix-dashboard:
    image: apache/apisix-dashboard:2.4
    restart: always
    volumes:
    - ./dashboard_conf/conf.yaml:/usr/local/apisix-dashboard/conf/conf.yaml
    ports:
    - "9000:9000"
    networks:
      apisix:
        ipv4_address: 172.18.5.18

  apisix:
    image: apache/apisix:2.3-alpine
    restart: always
    volumes:
      - ./apisix_log:/usr/local/apisix/logs
      - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml:ro
    depends_on:
      - etcd
    ##network_mode: host
    ports:
      - "8080:9080/tcp"
      - "9443:9443/tcp"
    networks:
      apisix:
        ipv4_address: 172.18.5.11
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 256M
        reservations:
          memory: 256M

  etcd:
    image: bitnami/etcd:3.4.9
    user: root
    restart: always
    volumes:
      - ./etcd_data:/etcd_data
    environment:
      ETCD_DATA_DIR: /etcd_data
      ETCD_ENABLE_V2: "true"
      ALLOW_NONE_AUTHENTICATION: "yes"
      ETCD_ADVERTISE_CLIENT_URLS: "http://0.0.0.0:2379"
      ETCD_LISTEN_CLIENT_URLS: "http://0.0.0.0:2379"
    ports:
      - "2379:2379/tcp"
    networks:
      apisix:
        ipv4_address: 172.18.5.10

networks:
  apisix:
    driver: bridge
    ipam:
      config:
      - subnet: 172.18.0.0/16

开源的APISIX支持Dashboard的方式来管理路由，而不是像KONG把仪表盘功能限制在商业版本中。但是APISIX的仪表盘不支持对路由URI进行改写，所以我们只好使用RestAPI来创建路由。

创建一个服务的路由的命令如下：

curl --location --request PUT 'http://127.0.0.1:8080/apisix/admin/routes/1' 
--header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' 
--header 'Content-Type: text/plain' 
--data-raw '{
    "uri": "/goapi/*",
    "plugins": {
        "proxy-rewrite": {
            "regex_uri": ["^/goapi(.*)$","$1"]
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "goapi:8080": 1
        }
    }
}'

使用K6压力测试的结果如下：

 

APISix取得了1155的好成绩，表现出接近不经过网关的性能，可能缓存起到了很好的效果。

Tyk

Tyk是一款基于Golang和Redis构建的开源API网关。它于2014年创建，比AWS的API网关即服务功能早。Tyk用Golang编写，并使用Golang自己的HTTP服务器。

Tyk支持不同的运行方式：云，混合（在自己的基础架构中为GW）和本地。

 

Tyk由3个组件组成：

• 网关：处理所有应用流量的代理。
• 仪表板：可以从中管理Tyk，显示指标和组织API的界面。
• Pump：负责持久保存指标数据，并将其导出到MongoDB（内置），ElasticSearch或InfluxDB等。

我们同样使用Docker Compose来创建Tyk 网关来进行功能验证。

version: '3.7'
services:
  tyk-gateway:
    image: tykio/tyk-gateway:v3.1.1
    ports:
      - 8080:8080
    volumes:
      - ./tyk.standalone.conf:/opt/tyk-gateway/tyk.conf
      - ./apps:/opt/tyk-gateway/apps
      - ./middleware:/opt/tyk-gateway/middleware
      - ./certs:/opt/tyk-gateway/certs
    environment:
      - TYK_GW_SECRET=foo
    depends_on:
      - tyk-redis
  tyk-redis:
    image: redis:5.0-alpine
    ports:
      - 6379:6379

Tyk的Dashboard也是属于商业版本的范畴，所我们又一次需要借助API来创建路由，Tyk是通过app的概念来创建和管理路由的，你也可以直接写app文件。

curl --location --request POST 'http://localhost:8080/tyk/apis/' 
--header 'x-tyk-authorization: foo' 
--header 'Content-Type: application/json' 
--data-raw '{
    "name": "GO API",
    "slug": "go-api",
    "api_id": "goapi",
    "org_id": "goapi",
    "use_keyless": true,
    "auth": {
      "auth_header_name": "Authorization"
    },
    "definition": {
      "location": "header",
      "key": "x-api-version"
    },
    "version_data": {
      "not_versioned": true,
      "versions": {
        "Default": {
          "name": "Default",
          "use_extended_paths": true
        }
      }
    },
    "proxy": {
      "listen_path": "/goapi/",
      "target_url": "http://host.docker.internal:18000/",
      "strip_listen_path": true
    },
    "active": true
}'

使用K6压力测试的结果如下：

 

Tyk的结果在400-600左右，性能上和KONG接近。

Zuul

Zuul是Netflix开源的基于Java的API网关组件。

 

Zuul包含多个组件：

• zuul-core：该库包含编译和执行过滤器的核心功能。
• zuul-simple-webapp：该Webapp展示了一个简单的示例，说明如何使用zuul-core构建应用程序。
• zuul-netflix：将其他NetflixOSS组件添加到Zuul的库-例如，使用Ribbon路由请求。
• zuul-netflix-webapp： 将zuul-core和zuul-netflix打包到一个易于使用的程序包中的webapp。

Zuul提供了灵活性和弹性，部分是通过利用其他Netflix OSS组件进行的：

• Hystrix 用于流控。包装对始发地的呼叫，这使我们可以在发生问题时丢弃流量并确定流量的优先级。
• Ribbon 是来自Zuul的所有出站请求的客户，它提供有关网络性能和错误的详细信息，并处理软件负载平衡以实现均匀的负载分配。
• Turbine 实时汇总细粒度的指标，以便我们可以快速观察问题并做出反应。
• Archaius 处理配置并提供动态更改属性的能力。

Zuul的核心是一系列过滤器，它们能够在路由HTTP请求和响应期间执行一系列操作。以下是Zuul过滤器的主要特征：

• 类型：通常定义路由流程中应用过滤器的阶段（尽管它可以是任何自定义字符串）
• 执行顺序：在类型中应用，定义跨多个过滤器的执行顺序
• 准则：执行过滤器所需的条件
• 动作：如果符合条件，则要执行的动作

class DeviceDelayFilter extends ZuulFilter {

    def static Random rand = new Random()
    
    @Override
    String filterType() {
       return 'pre'
    }

    @Override
    int filterOrder() {
       return 5
    }

    @Override
    boolean shouldFilter() {
       return  RequestContext.getRequest().
       getParameter("deviceType")?equals("BrokenDevice"):false
    }

    @Override
    Object run() {
       sleep(rand.nextInt(20000)) // Sleep for a random number of
                                  // seconds between [0-20]
    }
}

Zuul提供了一个框架来动态读取，编译和运行这些过滤器。过滤器不直接相互通信-而是通过每个请求唯一的RequestContext共享状态。过滤器使用Groovy编写。

 

有几种与请求的典型生命周期相对应的标准过滤器类型：

• Pre过滤器在路由到原点之前执行。示例包括请求身份验证，选择原始服务器以及记录调试信息。
• Route路由过滤器处理将请求路由到源。这是使用Apache HttpClient或Netflix Ribbon构建和发送原始HTTP请求的地方。
• 在将请求路由到源之后，将执行Post过滤器。示例包括将标准HTTP标头添加到响应，收集统计信息和指标以及将响应从源流传输到客户端。
• 在其他阶段之一发生错误时，将执行Error过滤器。

Spring Cloud创建了一个嵌入式Zuul代理，以简化一个非常常见的用例的开发，在该用例中，UI应用程序希望代理对一个或多个后端服务的调用。此功能对于用户界面代理所需的后端服务很有用，从而避免了为所有后端独立管理CORS和身份验证问题的需求 。

要启用它，请使用@EnableZuulProxy注解一个Spring Boot主类，这会将本地调用转发到适当的服务。

Zuul是Java的一个库，他并不是一款开箱即用的API网关，所以需要用Zuul开发一个应用来对其功能进行测试。

对应的Java的POM如下：

project
    xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    modelVersion>4.0.0modelVersion>
    groupId>naughtytao.apigatewaygroupId>
    artifactId>demoartifactId>
    version>0.0.1-SNAPSHOTversion>
    parent>
        groupId>org.springframework.bootgroupId>
        artifactId>spring-boot-starter-parentartifactId>
        version>1.4.7.RELEASEversion>
        relativePath />
        
    parent>
    properties>
        project.build.sourceEncoding>UTF-8project.build.sourceEncoding>
        project.reporting.outputEncoding>UTF-8project.reporting.outputEncoding>
        java.version>1.8java.version>
        
        spring-cloud.version>Camden.SR7spring-cloud.version>
    properties>
    dependencyManagement>
        dependencies>
            dependency>
                groupId>org.springframework.cloudgroupId>
                artifactId>spring-cloud-dependenciesartifactId>
                version>${spring-cloud.version}version>
                type>pomtype>
                scope>importscope>
            dependency>
        dependencies>
    dependencyManagement>
    dependencies>
        dependency>
            groupId>org.springframework.cloudgroupId>
            artifactId>spring-cloud-starter-zuulartifactId>
        dependency>
        dependency>
            groupId>org.springframework.bootgroupId>
            artifactId>spring-boot-starter-actuatorartifactId>
            exclusions>
                exclusion>
                    groupId>org.springframework.bootgroupId>
                    artifactId>spring-boot-starter-loggingartifactId>
                exclusion>
            exclusions>
        dependency>
        dependency>
            groupId>org.springframework.bootgroupId>
            artifactId>spring-boot-starter-log4j2artifactId>
        dependency>

        
        
        dependency>
            groupId>org.springframework.bootgroupId>
            artifactId>spring-boot-starter-webartifactId>
        dependency>
        
        dependency>
            groupId>jakarta.xml.bindgroupId>
            artifactId>jakarta.xml.bind-apiartifactId>
            version>2.3.2version>
        dependency>

        
        dependency>
            groupId>org.glassfish.jaxbgroupId>
            artifactId>jaxb-runtimeartifactId>
            version>2.3.2version>
        dependency>
		dependency>
			groupId>org.springframework.bootgroupId>
			artifactId>spring-boot-starter-testartifactId>
			scope>testscope>
		dependency>
		dependency>
			groupId>org.junit.jupitergroupId>
			artifactId>junit-jupiter-apiartifactId>
			version>5.0.0-M5version>
			scope>testscope>
		dependency>
    dependencies>
    build>
        plugins>
            plugin>
				groupId>org.springframework.bootgroupId>
				artifactId>spring-boot-maven-pluginartifactId>
			plugin>
			plugin>
				groupId>org.apache.maven.pluginsgroupId>
				artifactId>maven-compiler-pluginartifactId>
				version>3.3version>
				configuration>
					source>1.8source>
					target>1.8target>
				configuration>
			plugin>