对于API网关，已经介绍过Kong网关和Goku网关，今天谈在国人开源的APISIX网关，这个网关实际和Kong网关都是基于OpenResty Lua脚本语言实现，同样是基于插件化的API接口服务管控方式。

APISIX网关简介

APISIX 是一个云原生、高性能、可扩展的微服务 API 网关。它是基于 Nginx 和 etcd 来实现，和传统 API 网关相比，APISIX 具备动态路由和插件热加载功能，特别适合微服务体系下的 API 管理和服务治理管控。

整体架构

• 动态负载均衡：支持 round-robin 轮询和一致性哈希算法。
• 身份验证：支持 key-auth、JWT、basic-auth、wolf-rbac 等多种认证方式。
• 限流限速：可以基于速率、请求数、并发等维度限制。

并且 APISIX 还支持 A/B 测试、金丝雀发布(灰度发布)、蓝绿部署、监控报警、服务可观测性、服务治理等等高级功能，这在作为微服务 API 网络是非常重要的特性。

APISIX提供丰富的插件功能，具体插件可以热加载并动态扩展，当前从配置文件看APISIX已经提供的插件列表如下：

plugins:                          # plugin list
  - example-plugin
  - limit-req
  - limit-count
  - limit-conn
  - key-auth
  - basic-auth
  - prometheus
  - node-status
  - jwt-auth
  - zipkin
  - ip-restriction
  - grpc-transcode
  - serverless-pre-function
  - serverless-post-function
  - openid-connect
  - proxy-rewrite
  - redirect
  - response-rewrite
  - fault-injection
  - udp-logger
  - wolf-rbac
  - proxy-cache
  - tcp-logger
  - proxy-mirror
  - kafka-logger
  - cors
  - syslog
  - batch-requests

可以看到对于限流熔断，认证，安全，grpc，日志，状态监控等均提供了完整的插件支持能力。支持和zipkin服务链监控的集成，支持和prometheus的集成。

基于Etcd实现集群高可用和分布式配置

在前面已经谈到了APISIX的高可用是通过Etcd来实现集群的心跳监控，关键元数据配置信息的存储和分发等。而对于Kong网关则是采用的Postgres数据库来进行。

在集群部署的时候任何一个节点都需要包含 adminAPI 或 APISIX 内核，使用时可以只启用其中一部分或都启用。admin API 主要用于接收管理员的提交信息，通过 json schema 完成参数的校验，防止非法参数落到存储的配置中心。APISIX 内部部分处理外部请求，根据请求特征，匹配到具体路由规则，执行插件，然后把流量转发到指定上游服务。

APISIX网关和Kong网关对比和性能测试

对于两个网关由于采用相似的架构可以看到基本的API网关核心功能本身都具备。对于网关作者也发布过要给两者功能对比表如下：

作者也给出了一个两者性能测试对比：

通过性能测试可以看到，在不开启插件的情况下，Apache APISIX 的性能（QPS 和延迟）是 Kong 的2倍，但开启了两个常用插件后，性能就是 Kong 的十倍了。

大家可能最大的疑问还是架构差不多的情况下为何在开启插件情况下存在如此大的性能差异。由于对比测试的Kong版本是1.4的而不是2.0以上版本，实际可以再进行一次和Kong新版本的对比性能测试。当然作者给出过一个回复可以参考。

Kong 的路由实现是遍历算法的，Apache APISIX 的路由是基数树，相差几个数量级；kong 的存储是 postgres，需要节点去轮询，Apache APISIX 是 etcd 的 watch；kong 的 schema 校验是自己定义的标准，Apache APISIX 是 json schema，性能是它的几百倍。其他细节实现就更多了。

详细的对比和性能测试可以参考：

https://zhuanlan.zhihu.com/p/103236688

APISIX网关的安装

当前Github上最新的2.1版本安装有些问题没有成功。因此这里安装1.3版本进行安装和功能验证。对于整个安装基于Centos7虚拟机基础镜像进行，并安装验证通过。

①提前解决依赖问题
# 安装epel源, luarocks 需要使用到.
wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -ivh epel-release-latest-7.noarch.rpm
# 添加OpenResty 的镜像源
yum install yum-utils
yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo
# 安装 OpenResty, etcd 和一些依赖工具
yum install -y etcd openresty curl git gcc luarocks lua-devel
# 启动 etcd 服务端
systemctl start etcd
# 防火墙关闭
systemctl stop firewalld.service
systemctl disable firewalld.service

②安装apisix--注意安装1.3版本
yum install -y https://github.com/apache/incubator-apisix/releases/download/1.3/apisix-1.3-0.el7.noarch.rpm

③启动apisix
apisix start

④查看服务是否启动, 查看进程或者监听端口9080
ps aux|grep apisix
netstat -lntp|grep 9080

安装完成后目录和服务状态如下：

注意1.3版本已经自带Dashboard，不用再单独安装Dashboard

http://ip:9080/apisix/dashboard/

当访问上面的地址的时候，会出现403 Forbidden的错误，也就是当前主机IP没有允许访问安装在虚拟机里面的管控台。

这个时候就需要对 /usr/local/apisix/conf/config.yaml 文件进行修改，具体修改内容是放开allow_admin的ip控制。具体修改如下图：

修改完成后管控台可以正常访问和进入。默认账号admin/123456

功能简单验证

下面我们对APISIX提供的功能做简单验证。在验证场景前先看下APISIX里面提到的关键实体对象和关系。

Upstream：即后端业务服务，在APISIX实现里面不是简单的后端业务服务，而是一个后端业务服务入口的抽象，因此如果接入多个后端业务负载均衡，那么负载均衡在这里配置。

Service：这里的服务可以理解为经过APISIX封装一层后的服务抽象，在这里可以进行插件配置和定制，同时在前端Routes里面可以统一引用。

Routes：即通常说的暴露出去的代理服务，这里用了路由的概念，即核心的路由代理转发在这里实现。同时代理服务既可以直接对接Upstream，也可以直接对接Service。如果直接对接的是Upstream，那么相关的插件可以在这里进行配置。

Cusotmer: 对消费方的要给抽象，在配置消费方的时候同样可以单独配置插件信息。一方面在进行服务管控的时候既可以控制到单个服务，也可以控制到单个消费方。

整个服务请求访问过程如下图：

1 反向代理测试

确认本机的Openresty当前可以正常访问。

创建Upstream

创建Routes配置具体的URI，并绑定到Upsream

完成可以测试http://ip:9080/index.html，已经可以正常代理。

2 单纯的服务代理接入

可以找一个公网可以免费访问的API接口进行接口服务注册和接入，具体地址为：

https://www.binstd.com/api/area.html

即查询行政区域信息接口服务。在使用接口前需要先注册一个免费账号并获取appkey值，然后即可以免费访问服务。比如获取行政区域接口服务如下：

https://api.binstd.com/area/province?appkey=******

通过该接口即可返回我国的行政区域信息。通过网站提供的调式页面进行接口测试，可以正常返回具体的数据，当然直接通过浏览器访问上面地址也可以正常返回结果。

在这里创建Upstream，然后创建Routes，注意路由规则填写。

完成后即可以对封装后的地址进行访问。

对于路由规则，实际存在两种匹配方式。

一种是完全匹配，比如/blog/foo，则访问请求按该路径完全匹配。

还有一种是通配符匹配，比如/blog/foo*， 在这种场景下/blog/foo/a , /blog/foo/b , /blog/foo/a/b等均可以进行正常路由。

当我网上有一个详细的1.5版本的架构设计，开发和接入指南文档，可以参考。

https://iquanku.com/read/apache-apisix-1.4-zh/README.md

具体的一些问题

整个使用下来感觉和Kong网关还是有些差异，特别是对于Upsteam的定义，只能够是定义到具体德额后端Server和端口，而无法定义具体的路径。

也就是说当前的整体方式上对于要按Rest API接口服务，一个个的独立接入和封装的话并不是支持的特别好，这种网关更类似于微服务网关，更多是对整个微服务模块进行管理，而不是到详细的API的粒度。

当然也可能是一些设置还没有完全理解清楚导致。

先不说性能，就从当前本身的服务接入方式，操作和易用性方面来说，Kong网关更加符合实际的API接口注册和接入的习惯。