基于云原生的微服务网关-Apache APISIX
2021-08-08 22:30:04 
阿炯
APISIX 是一个基于云原生、高速可扩展的开源微服务网关节点实现，其自身主要优势是高性能和强大的扩展性。系国人基于OpenResty与etcd实现的云原生、高性能、可扩展的微服务 API 网关。
APISIX 从 etcd 中订阅获取所需的配置并以热更新的方式来更改自身行为，更改 etcd 中的配置即可完成对 APISIX 网关节点的控制，比如：动态上游、请求限速等，它还具有动态路由和热插件加载的特点。系统本身自带前端，可以手动配置路由、负载均衡、限速限流、身份验证等插件，操作方便。APISIX是用Lua语言开发在ApacheV2协议下授权，语言相对简单，容易上手，同时可以按需求进行系统的二次开发以及开发自己的插件。
A Real-Time Cloud-Native API Gateway
Provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more. Based on the Nginx library and etcd.
OpenResty：通过 Lua 扩展 Nginx 实现的可伸缩的 Web 平台。
etcd：Key/Value 存储系统。
APISIX 通过插件机制，提供了动态负载平衡、身份验证、限流限速等等功能，当然我们也可以自己开发插件进行拓展。
整体架构
动态负载均衡：跨多个上游服务的动态负载均衡，目前已支持 round-robin 轮询和一致性哈希算法。
身份验证：支持 key-auth、JWT、basic-auth、wolf-rbac 等多种认证方式。
限流限速：可以基于速率、请求数、并发等维度限制。
并且 APISIX 还支持 A/B 测试、金丝雀发布(灰度发布)、蓝绿部署、监控报警、服务可观测性、服务治理等等高级功能，这在作为微服务 API 网关非常重要的特性。
APISIX功能
它的功能有很多，包括动态路由、Url重写、动态上游、IP黑白名单、A/B测试、灰度发布、限速限流、监控报警、健康检查等等，本文只介绍几个比较常用的功能，其他功能具体可以查看APISIX的官方文档说明。
1.服务热启动功能
使用过Nginx的同学都会遇到过这种情况，在修改nginx.conf后需要重启nginx服务修改才会生效，重启时间虽然短暂，但难免会有一段服务不可用时间。当然，可以通过其他方式进行规避服务不可用。APISIX的服务热启动通过在路由、Service、Upstreams等插件中动态的修改配置即可，并不需要再重启APISIX服务来使修改生效。
2.热插件功能
不再需要在nginx.conf文件中编写复杂的规则代码来实现需求，通过使用自带的路由、Upstreams等插件，在前端页面中添加所需要的规则即可实现。下文应用会详细介绍。目前通过插件可以实现uri重写、根据请求信息中的内容实现路由跳转等等。也可以根据自己的需求开发符合自己需求的插件。
3.动态负载均衡
通过Upstreams插件，可以实现基于权重的roundrobin和chash负载均衡。
4.数据集群
APISIX支持etcd集群，通过etcd集群增强了系统的可用性，大大减小了故障损失。
5.监控
APISIX外接第三方prometheus监控系统，提供符合prometheus数据格式的监控指标数据。Prometheus 是由 SoundCloud 开源监控告警解决方案，已经比较成熟完善。
快速上手
有源码包、RPM 包、Luarocks、Docker 四种安装方式。
启动 APISIX：apisix start
测试限流插件
为了方便测试，下面的示例中设置的是 60 秒最多只能有 2 个请求，如果超过就返回 503：
curl http://127.0.0.1:2379/v2/keys/apisix/routes/1 -X PUT -d value='
{
"methods": ["GET"],
"uri": "/index.html",
"id": 1,
"plugin_config": {
"limit-count": {
"count": 2,
"time_window": 60,
"rejected_code": 503,
"key": "remote_addr"
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"39.97.63.215:80": 1
}
}
}'
$ curl -i http://127.0.0.1:9080/index.html
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 13175
Connection: keep-alive
X-RateLimit-Limit: 2
X-RateLimit-Remaining: 1
Server: APISIX web server
Date: Mon, 03 Jun 2021 09:38:32 GMT
Last-Modified: Wed, 24 Apr 2021 00:14:17 GMT
ETag: "5cbfaa59-3737"
Accept-Ranges: bytes
APISIX 控制台
APISIX 内置控制台功能，以方便我们进行 APISIX 的 Route、Consumer、Service、SSL、Upstream 的查看与维护。目前dashboard还存在一些不完善的地方，一些插件的函数配置等不可直接编辑，还是得通过apisix api进行。不过基本的一些配置直接可视化配置、查看很直观，也够用。控制台页面基于VUE开发，需要通过yarn编译生成，需要基础编译环境：node、npm、yarn，需要经历解压部署、配置环境变量、环境测试、编译dashboard组件生成静态页面等步骤。
安装控制台
确保你的运行环境中的 Node 版本 >= 8.12.0：node --version && npm --version
下载 Dashboard源码：
git clone https://github.com/apache/incubator-apisix-dashboard.git
安装依赖并构建
git checkout <v1.0> #这里的tag版本和你使用的apisix版本一致
yarn && yarn build:prod
与 APISIX 集成
把编译后的在 /dist 目录下的所有文件，复制到 apisix/dashboard 目录下，使用浏览器打开 http://127.0.0.1:9080/apisix/dashboard/ 即可使用。在/usr/local/apisix/conf/nginx.conf配置文件中，设置了 APISIX 控制台的访问路径为/apisix/dashboard。如下文所示：
location /apisix/dashboard {
allow 127.0.0.0/24;
deny all;
alias dashboard/;
try_files $uri $uri/index.html /index.html;
}
考虑到安全性，APISIX 控制台只允许本机访问，因此需要修改/usr/local/apisix/conf/config.yaml配置文件，增加允许访问的远程 IP 地址。如下所示：
allow_admin: # http://nginx.org/en/docs/http/ngx_http_access_module.html#allow
- 127.0.0.0/24 # If we don't set any IP list, then any IP access is allowed by default.
- 12.34.56.0/24 # 新增加的远程IP地址段。
修改完配置后，使用 apisix restart 命令，重启 APISIX 来生效配置。然后使用浏览器访问http://12.34.56.78:9080/apisix/dashboard地址，进入 APISIX 控制台。使用默认的“admin/123456”账号，登录 APISIX 控制台。
APISIX应用
使用前先配置一个可用的链路。微服务可以通过 APISIX 的路由、服务、上游和插件等多个实体之间的关系进行配置。 Route(路由)与客户端请求匹配，并指定它们到达 APISIX 后如何发送到 Upstream(上游，后端 API 服务)。 Service(服务)为上游服务提供了抽象。因此可以创建单个 Service 并在多个 Route 中引用它。
1、配置Upstream
创建Upstream界面中有Desc、Type、Key、Node。Type中根据需要选择roundrobin、chash两种方式，如果选择chash方式需要从下拉列表中选择合适的Key。Node节点根据实际需求可以添加多个。这是虚拟主机抽象，对给定的多个服务节点按照配置规则进行负载均衡，它根据配置规则在给定的一组服务节点上执行负载平衡。因此，单个上游配置可以由提供相同服务的多个服务器组成。每个节点将包括一个 key(地址/ip:port)和一个 value (节点的权重)。 服务可以通过轮询或一致哈希(cHash)机制进行负载平衡。
配置路由时，可以直接设置 Upstream 信息，也可以使用服务抽象来引用 Upstream 信息。
2、配置Routes
APISIX Route，字面意思就是路由，通过定义一些规则来匹配客户端的请求，然后根据匹配结果加载并执行相应的 插件，并把请求转发给到指定 Upstream。
创建Route界面中有Desc、URIs、Hosts、AddURI、Remote Address、Methods、Upstream、Service。在URIs中添加接收的请求uri，支持正则表达，例如请求地址有http://ip:port/hello/world.jsp、http://ip:port/hello/apisix.do，这里的URIs可以添加/hello/*来匹配处理这类请求。在Upstream中选择刚才创建的upstream，其他选择可以默认不填。
限流限速
APISIX 内置了三个限流限速插件：
limit-count：基于“固定窗口”的限速实现。
limit-req：基于漏桶原理的请求限速实现。
limit-conn：限制并发请求(或并发连接)。
limit-req 插件
本小节，我们来演示使用 limit-req 插件，毕竟基于漏桶的限流算法，是目前较为常用的限流方式：
漏桶算法(Leaky Bucket)是网络世界中流量整形(Traffic Shaping)或速率限制(Rate Limiting)时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。
漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。
给该 Route 配置下 limit-req 限流插件属性说明：
rate：指定的请求速率(以秒为单位)，请求速率超过 rate 但没有超过 (rate + brust)的请求会被加上延时
burst：请求速率超过 (rate + brust)的请求会被直接拒绝
rejected_code：当请求超过阈值被拒绝时，返回的 HTTP 状态码
key：是用来做请求计数的依据，当前接受的 key 有："remote_addr"(客户端 IP 地址)，"server_addr"(服务端 IP 地址)，请求头中的"X-Forwarded-For" 或 "X-Real-IP"。
当rate与burst皆为1时的配置含义：限制了每秒请求速率为 1，大于 1 小于 3的会被加上延时，速率超过 3就会被拒绝。
快速访问返回包含 503 返回码的响应头：
HTTP/1.1 503 Service Temporarily Unavailable
Content-Type: text/html
Content-Length: 194
Connection: keep-alive
Server: APISIX web server
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>openresty</center>
</body>
</html>
limit-conn 插件
Apisix 的限制并发请求(或并发连接)插件属性：
conn: 允许的最大并发请求数。 超过这个比率的请求(低于“ conn” + “ burst”)将被延迟以符合这个阈值。
burst: 允许延迟的过多并发请求(或连接)的数量。
default_conn_delay: 默认的典型连接(或请求)的处理延迟时间。
key: 用户指定的限制并发级别的关键字，可以是客户端IP或服务端IP。
例如:可以使用主机名(或服务器区域)作为关键字，以便限制每个主机名的并发性。另外，我们也可以使用客户端地址作为关键字，这样我们就可以避免单个客户端用太多的并行连接或请求淹没我们的服务。
现在接受以下关键字: “remote_addr”(客户端的 IP)，“server_addr”(服务器的 IP)，请* 求头中的“ X-Forwarded-For/X-Real-IP”。
rejected_code: 当请求超过阈值时返回的 HTTP状态码， 默认值是503。
在 route 页面中添加 limit-conn 插件
限制并发配置
上面启用的插件的参数表示只允许一个并发请求。 当收到多个并发请求时，将直接返回 503 拒绝请求。
测试
为了区别limit-req返回的503错误，可以返回码临时改成504。访问不同的url模拟并发：
https://12.34.56.78:9443/v2/vue/api/programLanguage/getAll
和
https://12.34.56.78:9443/v2/vue/api/programLanguage/getAll?param=value
返回：
504 Gateway Time-out
身份验证
APISIX 内置了四个身份验证插件：
key-auth：基于 Key Authentication 的用户认证。
JWT-auth：基于 JWT (JSON Web Tokens) Authentication 的用户认证。
basic-auth：基于 basic auth 的用户认证。
wolf-rbac：基于 RBAC 的用户认证及授权。需要额外搭建 wolf 服务，提供用户、角色、资源等信息。
配置 JWT-auth 插件
在 APISIX 控制台的「Consumer」菜单中，创建一个 APISIX Consumer，Consumer 是某类服务的消费者，需与用户认证体系配合才能使用。添加 JWT Authentication 到一个 service 或 route。 然后 consumer 将其密钥添加到查询字符串参数、请求头或 cookie 中以验证其请求。相关属性有：
key: 不同的 consumer 对象应有不同的值，它应当是唯一的。不同 consumer 使用了相同的 key ，将会出现请求匹配异常。
secret: 可选字段，加密秘钥。如果您未指定，后台将会自动生成。
algorithm：可选字段，加密算法。目前支持 HS256, HS384, HS512, RS256 和 ES256，如果未指定，则默认使用 HS256。
exp: 可选字段，token 的超时时间，以秒为单位的计时。比如有效期是 5 分钟，那么就应设置为 5 * 60 = 300。
健康检查
支持对上游节点的主动和被动健康检查，在负载均衡时自动过滤掉不健康的节点。
由于控制台dashboard没有健康检查的配置项，所以需要通过APISIX api方式在服务端执行如下语句。使用 REST Admin API 来控制 Apache APISIX，默认只允许 127.0.0.1 访问，可以修改 conf/config.yaml 中的 allow_admin 字段，指定允许调用 Admin API 的 IP 列表。同时需要注意的是，Admin API 使用 key auth 来校验调用者身份，在部署前需要修改 conf/config.yaml 中的 admin_key 字段，来保证安全。
X-API-KEY: xxx是admin账号的key，可以在conf\config.yaml的找到对应的值。
使配置热部署执行
curl http://127.0.0.1:9080/apisix/admin/plugins/reload -H 'X-API-KEY: xxx' -X PUT
返回：done
状态查看
http://ip:9080/apisix/status
参考来源
再谈 APISIX 高性能实践
Apache APISIX 诞生的目的之一就是解决 Nginx 的动态配置问题，LuaJIT 的高灵活性、高性能和超低内存占用带来了这种可能性。 以最具普遍性的路由为例，Apache APISIX 通过在 NGINX 配置文件中只配置单个 location 作为主入口，而后续的路由分发则由 APISIX 的路由分发模块完成，以此实现了路由的动态配置。
为了实现足够高的性能，Apache APISIX 使用 C 编写了基于前缀树的匹配路由算法，并在此基础上使用 LuaJIT 提供的 FFI 编写了适用于 Lua 的接口。而 Lua 的灵活性，也使得 Apache APISIX 的路由分发模块，可以轻易地支持通过特定的表达式等方法，对同一前缀的下级路由进行匹配。最终在替代 NGINX 原生路由分发功能的前提下，实现了兼具高性能、高灵活性的动态配置功能。有关这部分功能的详细实现，可以查看 lua-resty-radixtree 和 route.lua。另外不只是路由，从负载均衡、健康检查，到上游节点配置、服务端证书，以及扩展 APISIX 能力的插件本身，都能在 APISIX 不重启的情况下重新加载。同时，除了在使用 LuaJIT 进行插件等功能的开发，Apache APISIX 还支持了 Java、Go、Node、Python 以及 WASM 等多种方式开发插件，也让 Apache APISIX 的二次开发门槛大大降低，使 Apache APISIX 获得了丰富的插件生态和活跃的开源社区。
Apache APISIX 的插件原理和生态
APISIX 已经来到了全新的 3.x 版本，并带来了更多的开源项目集成、云供应商集成，原生的 gRPC 支持，更多的插件开发方式选择，以及服务网格支持等功能。
最新版本：2.8
Apache APISIX 2.8 版本于2021年8月初正式发布，该版本有 30+ 开发者参与，共提交了 100+ PR，支持了 1 个新功能、1 个新体验、2 个新插件、2 个新玩法。
新功能：独立的 Keepalive 连接池
从2.7 版本开始添加 Apache APISIX 自己的补丁和 Nginx C 模块，增强原生 Nginx 的功能，希望能够动态设置越来越多的 Nginx 配置。在发布的最新版本中，Apache APISIX 已经支持在 Upstream 级别上配置独立的 Keepalive 连接池。目前包含了以下功能：
动态设置 mTLS
动态设置 client_max_body_size
Upstream 的 keepalive(2.8 新功能)
gzip (2.8 新插件) 在 Apache APISIX 后续版本中，我们也会陆续允许下面的 Nginx 配置能够被动态设置：
real_ip
proxy_max_temp_file_size
……
Upstream 的配置举例：
{
"id": "backend",
"nodes": {"host:80": 100},
"type":"roundrobin",
"keepalive_pool": {
"size": 4,
"idle_timeout": 8,
"requests": 16
}
}
新体验：stream 代理功能增强
在 2.8 版本中，把 ip-restriction 和 limit-conn 两个插件从 HTTP 部分的移植到了 stream 部分，这么做的好处是丰富网关在 stream 代理的功能，增加对上游服务的安全性保障。ip-restriction 可以用来做 IP 黑白名单过滤，保证只有来自特定 IP 的请求才能访问到后端服务。limit-conn 可以用来限制特定路由上同时存在的连接个数，限制客户端的并发访问量。
新插件：gzip 插件
2.8 版本中新增了 gzip 插件，使用 gzip 插件可以动态设置路由级别的 gzip 参数，gzip 配置举例：
{
"plugins": {
"gzip": {
"min_length": 20,
"http_version": 1.1,
"buffers": {
"number": 32,
"size": 4096
},
"types": [
"text/html"
],
"comp_level": 1,
"vary": false
}
}
}
新插件：ua-restriction
ua-restriction 插件用于校验 User-Agent 是否处于黑白名单中，黑白名单是一个非常常见的需求，现在可以通过插件的方式启用了。ua-restriction 配置举例：
{
"plugins": {
"ua-restriction": {
"denylist": [
"my-bot1",
"(Baiduspider)/(\\d+)\\.(\\d+)"
]
}
}
}
新玩法：支持通过插件的方式执行特定逻辑
得益于 Apache APISIX 架构，许多功能都是通过插件的方式实现的。从 2.8 版本开始，插件又添加了新玩法。现在 Apache APISIX 支持在选择上游节点之后，通过插件的方式执行特定逻辑。只需要在插件里定义下面的方法：
function _M.balancer(conf, ctx)
core.log.notice("IP: ", ctx.balancer_ip, ", Port: ", ctx.balancer_port)
end
在这个示例里，日志会输出上游的 IP 和 Port。
什么场景下会运行上述方法？
选择上游节点之后，访问上游之前
每次重试之前
出于性能考虑，上述方法首次运行在 OpenResty 的 access 阶段(实际上 APISIX 在 access 阶段就选好了上游节点)，该方法并不与 OpenResty 的同名阶段重合。
新玩法：支持自定义 balancer
从 2.8 版本开始，用户可以自定义 balancer。这里的 balancer，是指最少连接数、轮询、一致性哈希等负载均衡器。虽然 Apache APISIX 已经提供了丰富的 balancer，但是用户可能需要用的 balancer 是和业务紧密相关的 balancer，比如：需要考虑机房、可用区等等。支持自定义 balancer，用户可以编写自己的 balancer，并通过 require("apisix.balancer.your_balancer") 加载到程序中。通常自定义的 balancer 需要 node 提供 host/port 以外的数据，可以把数据放到 metadata 里面，示例如下：
{
"nodes": [
{ "host": "0.0.0.0", "port": 1980, "weight": 1, "metadata": {"b": 1} }
]
}
最新版本：2.10
Apache APISIX 2.10 版本于2021年10月上旬正式发布！这是Apache APISIX 首个 LTS 版本，同时支持 10+ 个新功能和新插件，里程碑：第一个 LTS 版本，对于 Apache APISIX 来说，本次发布的 2.10.0 是一个具有里程碑意义的版本，因为 Apache APISIX 2.10.0 是我们的第一个 LTS （Long Time Support）的版本。我们会在 Apache APISIX 2.10.0 的基础上发布后续的 patch 版本，也就是 2.10.1、2.10.2 等版本。这些版本会从主分支上 backport bugfix。按计划，10 月份我们会发布首个 LTS 版本的首个 patch 版本，也就是 Apache APISIX 2.10.1。之后我们会交替发布 2.10.x（例如 2.10.2 ） 和 2.x（例如 2.11.0）两个版本线，保持功能迭代的同时，确保 LTS 版本能够得到较新的 bugfix。值得一提的是，Apache APISIX 2.10.0 的 docker 镜像将会内置 APISIX OpenResty，无需自行编译就能用到 Apache APISIX 的全部功能。
新功能：service 增加 hosts 属性
在 Apache APISIX 2.10.0 版本里面，我们给 service 加上了 hosts 属性。就像 service 里面其他字段一样，route 可以从 service 中继承 hosts 属性。
新功能：支持设置镜像请求的比例
proxy-mirror 插件支持设置镜像请求的比例，是用户们一直在期待的功能，我们在 Apache APISIX 2.10.0 上支持了这个功能。通过设置 sample_ratio，可以控制被镜像到测试服务的请求数量。
新组件：APISIX Python Plugin Runner
继 Java Plugin Runner 和 Go Plugin Runner 之后，Apache APISIX 又迎来了新的 Plugin Runner。Apache APISIX Python Plugin Runner 已于 9 月 6 日发布了 0.1.0 版本。
最新版本：3.0
APISIX 正式于2022年11月中旬发布了 3.0 版本：
新增了 Consumer Group，可以更方便地管理消费者；
支持配置 DNS 解析域名类型的顺序；
新增 AI 平面，更智能化地对配置与流量进行分析与呈现；
对多个现有生态插件进行更细致的优化。
除了以上技术层面的细节改动外，还有很多新的功能特性与生态扩展细节均在下文中为大家呈现。可以说这次的版本迭代，真正做到了 “性能更强更智能，生态更广更多样”。如果想立刻体验 APISIX 3.0 正式版本，可以即刻前往官网进行下载与使用。新增亮点汇总：
1. 全面支持 ARM64
目前 ARM64 对于云厂商来说，已成为一个非常主流的服务器架构选型。从 AWS Graviton、GCP Tau T2A 再到华为鲲鹏等系列产品，可以看到各家云厂商都开始推出了基于 ARM 架构的服务器。目前从数据来看，Arm 架构的服务器在性价比层面的表现略优于 X86。为了顺应时代技术潮流，APISIX 也在 ARM64 上做了全面的 CI 回归。保证用户在 ARM 架构中运行 APISIX 时，依旧可以顺畅运行各种功能。
2. 新增 gRPC 客户端
在 3.0 版本中，将新增一个 core.grpc 模块。如果你熟悉 NGINX 和 OpenResty 的话，就知道这两者对于 gRPC 的支持相当有限，仅停留在执行反向代理或负载均衡这样的基础功能上。 而 APISIX 在目前 2.x 版本中就已经实现了 gRPC 和 HTTP 协议的转换。在 3.0 版本中，将通过新增 gRPC 客户端的方式，允许开发者直接调⽤第三⽅的 gRPC 服务，⽆需引⼊额外的组件或要求服务提供⽅额外使⽤ HTTP 接口，将使用过程大大简捷化。
3. 重新设计 Admin API
目前在使用 APISIX 时，你可能会发现 APISIX 的响应体中掺杂了很多没有意义的数据，比如一些 etcd 的返回值，没有进行任何剪裁就直接传送给了客户端。同时目前整个响应体的架构设计也并不完善，存在一些冗余字段。在 APISIX 3.0 版本中，重新设计了响应体结构，新的格式可以让整个请求格式和返回体都更加的 Restful 化，从而让用户更加方便地使用新版本的 Admin API。当然该过程也允许通过参数来控制使用哪个版本的 Admin API，不用害怕升级后兼容不了之前的版本。
4. DP 和 CP 分离
APISIX 在最近一两年内出现了多个安全相关的漏洞，大多数漏洞的根本原因都是因为 APISIX 在默认部署模式下，将数据面与控制面部署在一起了。一旦数据面上存在安全漏洞，攻击者就可以通过数据面直接侵入控制面，从而影响到其他所有的数据面。因此在 3.0 版本中，新增了部署模式配置 deployment，默认属性为 traditional，也就是数据面与控制面部署在一起。当然，新配置模式还是更建议大家将属性设置为 data_plane 或 control_plane，从而实现数据面与控制面的完全分离。在完全分离后，不仅能解决上述安全隐患，还能更好地在数据面和控制面中分别进行功能的迭代而互不影响。
5. 新增 AI 平面
在数据平面和控制平面之外，Apache APISIX 新增了 AI 平面。 通过对于 API 流量和配置的学习与分析，减轻开发者和维护者的使用和运维压力。比如以下两个场景就可以通过 AI 平面进行自动优化：
发现没有身份认证的 API，并给出风险提示；
对于只配置了身份认证等 Access 阶段插件的 API，自动跳过 log 等不必要阶段，加快处理速度。
AI 平面给流量处理带来了新的可能性，在后续使用过程中，类似上游服务自动热身、安全威胁发现等都可以通过 AI 平面来进行处理。
6. 更完善的服务发现支持
APISIX 在现版本中，已支持集成了很多服务发现组件，比如 Zookeeper、Consul、Nacos 等。但目前这些集成都是在数据面上完成的，一旦你的数据面节点非常多，这对于后续的服务发现组件压力也是非常大的。尤其是像 ETCD 和 ZooKeeper 这一类提供强一致性的组件，通常无法承受太大量的连接数；此外，用户还需要为 Apache APISIX 数据面配置服务发现组件的认证，如果你在使用虚拟机部署 Apache APISIX，那么你需要将认证配置同步到每一个实例。
同时在用户实际生产环境中，他们想要的不仅仅是一个简单的类似于像 Consul KV 的集成或者是 DNS 的集成，而是更希望能做到类似健康检查等更多完整功能的集成。因此在 APISIX 3.0 中，我们通过新增一个子项目 APISIX-SEED 进行了一层抽象，实现了控制层面的服务发现支持，降低了对服务发现组件的压力。后端服务的节点将由 APISIX-SEED 组件进行更新然后同步到 ETCD，最终被 Apache APISIX 所使用。
7. 新增 xRPC 框架
APISIX 在现版本中支持代理 TCP 协议，但是有些时候，纯粹的 TCP 协议代理是不够的。用户需要的是特定应用协议的代理，比如 Redis Proxy、Kafka Proxy 等。因为有些功能必须在对该协议进行编解码之后才能实现。因此，APISIX 在 3.0 版本中实现了一个名为 xRPC 的四层协议拓展框架，允许开发者在上面自定义特定的应用协议。基于 xRPC，开发者可以通过 Lua 代码对请求和响应进行编解码，进而在了解协议内容的基础上完成故障注入、日志上报、动态路由等功能的实现。
基于 xRPC 框架，APISIX 可以提供对若干主流应用协议的代理实现。同时用户也可以基于该框架来支持自己私有的基于 TCP 的应用协议，使其具备类似 HTTP 协议代理的 精准颗粒度 的和 更高阶的七层控制 。而在不同的协议之上，又可以去抽象一些共性因素，实现相关插件能力，让不同的协议可以共享这些能力。
8. 支持更多四层可观测性
APISIX 在可观测性的功能支持上一直都投入很多，几乎支持了所有的可观测性组件，比如 Zipkin、Apache SkyWalking、Datadog 等等。同时还支持了各种各样的日志组件，但这些大多都是在七层（应用层）进行的。在 APISIX 3.0 版本中将会增加更多基于四层（传输层）的可观测性支持。比如增加了四层上对于 Prometheus 和各种日志的支持，不仅可以让用户非常轻松地观测到七层流量中哪里出了问题，也可以去发现四层的流量运作状况。
9. 集成 OpenAPI 规范
API 其实是一个涉及从开发、测试、上线到整个全生命周期的元素。在 APISIX 3.0 版本中，将支持标准的 OpenAPI 3.0 规范。因此，如果你是在一些 API 设计和测试的软件上进行管理 API 的话，就可以非常方便地通过数据导出和导入，将其放置在 APISIX 中进行管理和维护。同时 APISIX 中的各种 API 也可以通过 OpenAPI 3.0 规范进行导出，然后再导入到其他系统中使用。除此之外，在 3.0 版本中 APISIX 也支持了针对 Postman 相关自定义格式的支持（Postman Collection Format v2），实现两者之间的数据传输，从而更方便地进行集成。
10. Gateway API 的全面支持和服务网格
在 APISIX Ingress 的版本迭代中，已开始对 Gateway API 进行支持，最新的 1.5 版本中已基本支持了所有的 Gateway API 配置。由于 Kubernetes Ingress 资源本身的限制，南北向场景中很多的流量管理能力无法被很好的表达出来，因此市场上大量的 Ingress Controller 解决方案都提供了自定义的 CRD，虽然这样能很好地帮助用户管理流量，但是却间接提高了迁移的成本，几乎导致用户被某个 Ingress Controller 选型锁定。因此 Kubernetes 社区在前两年开始着手制定 Gateway API 这一标准。
Gateway API 是一个面向角色分层的协议，通常像 AWS、GCP 这样的云厂商会充当基础设施提供者，他们会提供若干种不同可选的网关选型（GatewayClass）；而网关管理员，通常会创建不同的网关实例（Gateway）；更上层的开发者则只聚焦于如何创建路由来暴露自己的 API，而不关心底层的网关细节。这种情况下就可以通过 APISIX Ingress 去使用 Gateway API 的方式进行各种配置，也就意味着你能够在各个不同的数据面进行切换。在今年年底，APISIX Ingress 将更加完整地支持 Gateway API 以及支持在四层和七层的更多能力。
与大多数服务网格方案不同，APISIX 的服务网格方案更有优势的地方是数据面（得益于 APISIX 本身的高性能），因此在控制面的选择上，更希望去兼容一些社区上已有的主流方案。最终采取了通过使用 xDS 协议与 Istio 进行交互，并将获取到的配置写入到 APISIX 的 xDS 配置中心的方式，来配合 APISIX 生成具体的路由规则，完成对应请求的路由。这种方案不仅可以让整个服务网格更加轻量，同时借助于 APISIX 的高拓展性，也可以进行更方便地二次开发与迁移。
11. 集成更多生态
除了上文提到的 OpenAPI 标准之外，3.0 版本中也会新增非常多的生态插件，比如 OpenFunction、ClickHouse、Elasticsearch、SAML 和 CAS 等，去集成更对关于认证鉴权、安全或者可观测性等。其中一个有趣的插件 workflow 是关于流量调度的， 通过该插件就可以在流量控制层面进行一些更细粒度的处理。比如当条件 A 成立时执行某个行为，条件 B 成立时执行另一个行为等。通过这种更加清晰的方式，让用户更加方便地调度各种业务流量。
小结
不管是 APISIX 从零开始发展到现在，还是已经推出的 3.0 正式版本，你会发现 APISIX 其实并没有在架构层面进行太多的调整与改动，更多的是进行生态、兼容性和产品应用层面的改变。一个开源项目的评判标准，或许并不只有性能和功能，而是需要更多站在用户、开发者和企业的角度，去考虑他们使用这个产品是否可以快速有效地解决当下的痛点。而上文中提到的亮点或者新特性，其实都是通过开源社区的大环境，接收了来自不同开发者或者企业用户的反馈而打造出来的，是他们让开源产品更加实用和充满活力。最后也欢迎大家对 APISIX 3.0.0 正式版进行体验和反馈，期待技术与社区所迸发的技术魅力。
项目主页：
https://apisix.apache.org/
https://github.com/apache/apisix
APISIX 从 etcd 中订阅获取所需的配置并以热更新的方式来更改自身行为，更改 etcd 中的配置即可完成对 APISIX 网关节点的控制，比如：动态上游、请求限速等，它还具有动态路由和热插件加载的特点。系统本身自带前端，可以手动配置路由、负载均衡、限速限流、身份验证等插件，操作方便。APISIX是用Lua语言开发在ApacheV2协议下授权，语言相对简单，容易上手，同时可以按需求进行系统的二次开发以及开发自己的插件。
A Real-Time Cloud-Native API Gateway
Provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more. Based on the Nginx library and etcd.
OpenResty：通过 Lua 扩展 Nginx 实现的可伸缩的 Web 平台。
etcd：Key/Value 存储系统。
APISIX 通过插件机制，提供了动态负载平衡、身份验证、限流限速等等功能，当然我们也可以自己开发插件进行拓展。
整体架构
动态负载均衡：跨多个上游服务的动态负载均衡，目前已支持 round-robin 轮询和一致性哈希算法。
身份验证：支持 key-auth、JWT、basic-auth、wolf-rbac 等多种认证方式。
限流限速：可以基于速率、请求数、并发等维度限制。
并且 APISIX 还支持 A/B 测试、金丝雀发布(灰度发布)、蓝绿部署、监控报警、服务可观测性、服务治理等等高级功能，这在作为微服务 API 网关非常重要的特性。
APISIX功能
它的功能有很多，包括动态路由、Url重写、动态上游、IP黑白名单、A/B测试、灰度发布、限速限流、监控报警、健康检查等等，本文只介绍几个比较常用的功能，其他功能具体可以查看APISIX的官方文档说明。
1.服务热启动功能
使用过Nginx的同学都会遇到过这种情况，在修改nginx.conf后需要重启nginx服务修改才会生效，重启时间虽然短暂，但难免会有一段服务不可用时间。当然，可以通过其他方式进行规避服务不可用。APISIX的服务热启动通过在路由、Service、Upstreams等插件中动态的修改配置即可，并不需要再重启APISIX服务来使修改生效。
2.热插件功能
不再需要在nginx.conf文件中编写复杂的规则代码来实现需求，通过使用自带的路由、Upstreams等插件，在前端页面中添加所需要的规则即可实现。下文应用会详细介绍。目前通过插件可以实现uri重写、根据请求信息中的内容实现路由跳转等等。也可以根据自己的需求开发符合自己需求的插件。
3.动态负载均衡
通过Upstreams插件，可以实现基于权重的roundrobin和chash负载均衡。
4.数据集群
APISIX支持etcd集群，通过etcd集群增强了系统的可用性，大大减小了故障损失。
5.监控
APISIX外接第三方prometheus监控系统，提供符合prometheus数据格式的监控指标数据。Prometheus 是由 SoundCloud 开源监控告警解决方案，已经比较成熟完善。
快速上手
有源码包、RPM 包、Luarocks、Docker 四种安装方式。
启动 APISIX：apisix start
测试限流插件
为了方便测试，下面的示例中设置的是 60 秒最多只能有 2 个请求，如果超过就返回 503：
curl http://127.0.0.1:2379/v2/keys/apisix/routes/1 -X PUT -d value='
{
"methods": ["GET"],
"uri": "/index.html",
"id": 1,
"plugin_config": {
"limit-count": {
"count": 2,
"time_window": 60,
"rejected_code": 503,
"key": "remote_addr"
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"39.97.63.215:80": 1
}
}
}'
$ curl -i http://127.0.0.1:9080/index.html
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 13175
Connection: keep-alive
X-RateLimit-Limit: 2
X-RateLimit-Remaining: 1
Server: APISIX web server
Date: Mon, 03 Jun 2021 09:38:32 GMT
Last-Modified: Wed, 24 Apr 2021 00:14:17 GMT
ETag: "5cbfaa59-3737"
Accept-Ranges: bytes
APISIX 控制台
APISIX 内置控制台功能，以方便我们进行 APISIX 的 Route、Consumer、Service、SSL、Upstream 的查看与维护。目前dashboard还存在一些不完善的地方，一些插件的函数配置等不可直接编辑，还是得通过apisix api进行。不过基本的一些配置直接可视化配置、查看很直观，也够用。控制台页面基于VUE开发，需要通过yarn编译生成，需要基础编译环境：node、npm、yarn，需要经历解压部署、配置环境变量、环境测试、编译dashboard组件生成静态页面等步骤。
安装控制台
确保你的运行环境中的 Node 版本 >= 8.12.0：node --version && npm --version
下载 Dashboard源码：
git clone https://github.com/apache/incubator-apisix-dashboard.git
安装依赖并构建
git checkout <v1.0> #这里的tag版本和你使用的apisix版本一致
yarn && yarn build:prod
与 APISIX 集成
把编译后的在 /dist 目录下的所有文件，复制到 apisix/dashboard 目录下，使用浏览器打开 http://127.0.0.1:9080/apisix/dashboard/ 即可使用。在/usr/local/apisix/conf/nginx.conf配置文件中，设置了 APISIX 控制台的访问路径为/apisix/dashboard。如下文所示：
location /apisix/dashboard {
allow 127.0.0.0/24;
deny all;
alias dashboard/;
try_files $uri $uri/index.html /index.html;
}
考虑到安全性，APISIX 控制台只允许本机访问，因此需要修改/usr/local/apisix/conf/config.yaml配置文件，增加允许访问的远程 IP 地址。如下所示：
allow_admin: # http://nginx.org/en/docs/http/ngx_http_access_module.html#allow
- 127.0.0.0/24 # If we don't set any IP list, then any IP access is allowed by default.
- 12.34.56.0/24 # 新增加的远程IP地址段。
修改完配置后，使用 apisix restart 命令，重启 APISIX 来生效配置。然后使用浏览器访问http://12.34.56.78:9080/apisix/dashboard地址，进入 APISIX 控制台。使用默认的“admin/123456”账号，登录 APISIX 控制台。
APISIX应用
使用前先配置一个可用的链路。微服务可以通过 APISIX 的路由、服务、上游和插件等多个实体之间的关系进行配置。 Route(路由)与客户端请求匹配，并指定它们到达 APISIX 后如何发送到 Upstream(上游，后端 API 服务)。 Service(服务)为上游服务提供了抽象。因此可以创建单个 Service 并在多个 Route 中引用它。
1、配置Upstream
创建Upstream界面中有Desc、Type、Key、Node。Type中根据需要选择roundrobin、chash两种方式，如果选择chash方式需要从下拉列表中选择合适的Key。Node节点根据实际需求可以添加多个。这是虚拟主机抽象，对给定的多个服务节点按照配置规则进行负载均衡，它根据配置规则在给定的一组服务节点上执行负载平衡。因此，单个上游配置可以由提供相同服务的多个服务器组成。每个节点将包括一个 key(地址/ip:port)和一个 value (节点的权重)。 服务可以通过轮询或一致哈希(cHash)机制进行负载平衡。
配置路由时，可以直接设置 Upstream 信息，也可以使用服务抽象来引用 Upstream 信息。
2、配置Routes
APISIX Route，字面意思就是路由，通过定义一些规则来匹配客户端的请求，然后根据匹配结果加载并执行相应的 插件，并把请求转发给到指定 Upstream。
创建Route界面中有Desc、URIs、Hosts、AddURI、Remote Address、Methods、Upstream、Service。在URIs中添加接收的请求uri，支持正则表达，例如请求地址有http://ip:port/hello/world.jsp、http://ip:port/hello/apisix.do，这里的URIs可以添加/hello/*来匹配处理这类请求。在Upstream中选择刚才创建的upstream，其他选择可以默认不填。
限流限速
APISIX 内置了三个限流限速插件：
limit-count：基于“固定窗口”的限速实现。
limit-req：基于漏桶原理的请求限速实现。
limit-conn：限制并发请求(或并发连接)。
limit-req 插件
本小节，我们来演示使用 limit-req 插件，毕竟基于漏桶的限流算法，是目前较为常用的限流方式：
漏桶算法(Leaky Bucket)是网络世界中流量整形(Traffic Shaping)或速率限制(Rate Limiting)时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。
漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。
给该 Route 配置下 limit-req 限流插件属性说明：
rate：指定的请求速率(以秒为单位)，请求速率超过 rate 但没有超过 (rate + brust)的请求会被加上延时
burst：请求速率超过 (rate + brust)的请求会被直接拒绝
rejected_code：当请求超过阈值被拒绝时，返回的 HTTP 状态码
key：是用来做请求计数的依据，当前接受的 key 有："remote_addr"(客户端 IP 地址)，"server_addr"(服务端 IP 地址)，请求头中的"X-Forwarded-For" 或 "X-Real-IP"。
当rate与burst皆为1时的配置含义：限制了每秒请求速率为 1，大于 1 小于 3的会被加上延时，速率超过 3就会被拒绝。
快速访问返回包含 503 返回码的响应头：
HTTP/1.1 503 Service Temporarily Unavailable
Content-Type: text/html
Content-Length: 194
Connection: keep-alive
Server: APISIX web server
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>openresty</center>
</body>
</html>
limit-conn 插件
Apisix 的限制并发请求(或并发连接)插件属性：
conn: 允许的最大并发请求数。 超过这个比率的请求(低于“ conn” + “ burst”)将被延迟以符合这个阈值。
burst: 允许延迟的过多并发请求(或连接)的数量。
default_conn_delay: 默认的典型连接(或请求)的处理延迟时间。
key: 用户指定的限制并发级别的关键字，可以是客户端IP或服务端IP。
例如:可以使用主机名(或服务器区域)作为关键字，以便限制每个主机名的并发性。另外，我们也可以使用客户端地址作为关键字，这样我们就可以避免单个客户端用太多的并行连接或请求淹没我们的服务。
现在接受以下关键字: “remote_addr”(客户端的 IP)，“server_addr”(服务器的 IP)，请* 求头中的“ X-Forwarded-For/X-Real-IP”。
rejected_code: 当请求超过阈值时返回的 HTTP状态码， 默认值是503。
在 route 页面中添加 limit-conn 插件
限制并发配置
上面启用的插件的参数表示只允许一个并发请求。 当收到多个并发请求时，将直接返回 503 拒绝请求。
测试
为了区别limit-req返回的503错误，可以返回码临时改成504。访问不同的url模拟并发：
https://12.34.56.78:9443/v2/vue/api/programLanguage/getAll
和
https://12.34.56.78:9443/v2/vue/api/programLanguage/getAll?param=value
返回：
504 Gateway Time-out
身份验证
APISIX 内置了四个身份验证插件：
key-auth：基于 Key Authentication 的用户认证。
JWT-auth：基于 JWT (JSON Web Tokens) Authentication 的用户认证。
basic-auth：基于 basic auth 的用户认证。
wolf-rbac：基于 RBAC 的用户认证及授权。需要额外搭建 wolf 服务，提供用户、角色、资源等信息。
配置 JWT-auth 插件
在 APISIX 控制台的「Consumer」菜单中，创建一个 APISIX Consumer，Consumer 是某类服务的消费者，需与用户认证体系配合才能使用。添加 JWT Authentication 到一个 service 或 route。 然后 consumer 将其密钥添加到查询字符串参数、请求头或 cookie 中以验证其请求。相关属性有：
key: 不同的 consumer 对象应有不同的值，它应当是唯一的。不同 consumer 使用了相同的 key ，将会出现请求匹配异常。
secret: 可选字段，加密秘钥。如果您未指定，后台将会自动生成。
algorithm：可选字段，加密算法。目前支持 HS256, HS384, HS512, RS256 和 ES256，如果未指定，则默认使用 HS256。
exp: 可选字段，token 的超时时间，以秒为单位的计时。比如有效期是 5 分钟，那么就应设置为 5 * 60 = 300。
健康检查
支持对上游节点的主动和被动健康检查，在负载均衡时自动过滤掉不健康的节点。
由于控制台dashboard没有健康检查的配置项，所以需要通过APISIX api方式在服务端执行如下语句。使用 REST Admin API 来控制 Apache APISIX，默认只允许 127.0.0.1 访问，可以修改 conf/config.yaml 中的 allow_admin 字段，指定允许调用 Admin API 的 IP 列表。同时需要注意的是，Admin API 使用 key auth 来校验调用者身份，在部署前需要修改 conf/config.yaml 中的 admin_key 字段，来保证安全。
X-API-KEY: xxx是admin账号的key，可以在conf\config.yaml的找到对应的值。
使配置热部署执行
curl http://127.0.0.1:9080/apisix/admin/plugins/reload -H 'X-API-KEY: xxx' -X PUT
返回：done
状态查看
http://ip:9080/apisix/status
参考来源
再谈 APISIX 高性能实践
Apache APISIX 诞生的目的之一就是解决 Nginx 的动态配置问题，LuaJIT 的高灵活性、高性能和超低内存占用带来了这种可能性。 以最具普遍性的路由为例，Apache APISIX 通过在 NGINX 配置文件中只配置单个 location 作为主入口，而后续的路由分发则由 APISIX 的路由分发模块完成，以此实现了路由的动态配置。
为了实现足够高的性能，Apache APISIX 使用 C 编写了基于前缀树的匹配路由算法，并在此基础上使用 LuaJIT 提供的 FFI 编写了适用于 Lua 的接口。而 Lua 的灵活性，也使得 Apache APISIX 的路由分发模块，可以轻易地支持通过特定的表达式等方法，对同一前缀的下级路由进行匹配。最终在替代 NGINX 原生路由分发功能的前提下，实现了兼具高性能、高灵活性的动态配置功能。有关这部分功能的详细实现，可以查看 lua-resty-radixtree 和 route.lua。另外不只是路由，从负载均衡、健康检查，到上游节点配置、服务端证书，以及扩展 APISIX 能力的插件本身，都能在 APISIX 不重启的情况下重新加载。同时，除了在使用 LuaJIT 进行插件等功能的开发，Apache APISIX 还支持了 Java、Go、Node、Python 以及 WASM 等多种方式开发插件，也让 Apache APISIX 的二次开发门槛大大降低，使 Apache APISIX 获得了丰富的插件生态和活跃的开源社区。
Apache APISIX 的插件原理和生态
APISIX 已经来到了全新的 3.x 版本，并带来了更多的开源项目集成、云供应商集成，原生的 gRPC 支持，更多的插件开发方式选择，以及服务网格支持等功能。
最新版本：2.8
Apache APISIX 2.8 版本于2021年8月初正式发布，该版本有 30+ 开发者参与，共提交了 100+ PR，支持了 1 个新功能、1 个新体验、2 个新插件、2 个新玩法。
新功能：独立的 Keepalive 连接池
从2.7 版本开始添加 Apache APISIX 自己的补丁和 Nginx C 模块，增强原生 Nginx 的功能，希望能够动态设置越来越多的 Nginx 配置。在发布的最新版本中，Apache APISIX 已经支持在 Upstream 级别上配置独立的 Keepalive 连接池。目前包含了以下功能：
动态设置 mTLS
动态设置 client_max_body_size
Upstream 的 keepalive(2.8 新功能)
gzip (2.8 新插件) 在 Apache APISIX 后续版本中，我们也会陆续允许下面的 Nginx 配置能够被动态设置：
real_ip
proxy_max_temp_file_size
……
Upstream 的配置举例：
{
"id": "backend",
"nodes": {"host:80": 100},
"type":"roundrobin",
"keepalive_pool": {
"size": 4,
"idle_timeout": 8,
"requests": 16
}
}
新体验：stream 代理功能增强
在 2.8 版本中，把 ip-restriction 和 limit-conn 两个插件从 HTTP 部分的移植到了 stream 部分，这么做的好处是丰富网关在 stream 代理的功能，增加对上游服务的安全性保障。ip-restriction 可以用来做 IP 黑白名单过滤，保证只有来自特定 IP 的请求才能访问到后端服务。limit-conn 可以用来限制特定路由上同时存在的连接个数，限制客户端的并发访问量。
新插件：gzip 插件
2.8 版本中新增了 gzip 插件，使用 gzip 插件可以动态设置路由级别的 gzip 参数，gzip 配置举例：
{
"plugins": {
"gzip": {
"min_length": 20,
"http_version": 1.1,
"buffers": {
"number": 32,
"size": 4096
},
"types": [
"text/html"
],
"comp_level": 1,
"vary": false
}
}
}
新插件：ua-restriction
ua-restriction 插件用于校验 User-Agent 是否处于黑白名单中，黑白名单是一个非常常见的需求，现在可以通过插件的方式启用了。ua-restriction 配置举例：
{
"plugins": {
"ua-restriction": {
"denylist": [
"my-bot1",
"(Baiduspider)/(\\d+)\\.(\\d+)"
]
}
}
}
新玩法：支持通过插件的方式执行特定逻辑
得益于 Apache APISIX 架构，许多功能都是通过插件的方式实现的。从 2.8 版本开始，插件又添加了新玩法。现在 Apache APISIX 支持在选择上游节点之后，通过插件的方式执行特定逻辑。只需要在插件里定义下面的方法：
function _M.balancer(conf, ctx)
core.log.notice("IP: ", ctx.balancer_ip, ", Port: ", ctx.balancer_port)
end
在这个示例里，日志会输出上游的 IP 和 Port。
什么场景下会运行上述方法？
选择上游节点之后，访问上游之前
每次重试之前
出于性能考虑，上述方法首次运行在 OpenResty 的 access 阶段(实际上 APISIX 在 access 阶段就选好了上游节点)，该方法并不与 OpenResty 的同名阶段重合。
新玩法：支持自定义 balancer
从 2.8 版本开始，用户可以自定义 balancer。这里的 balancer，是指最少连接数、轮询、一致性哈希等负载均衡器。虽然 Apache APISIX 已经提供了丰富的 balancer，但是用户可能需要用的 balancer 是和业务紧密相关的 balancer，比如：需要考虑机房、可用区等等。支持自定义 balancer，用户可以编写自己的 balancer，并通过 require("apisix.balancer.your_balancer") 加载到程序中。通常自定义的 balancer 需要 node 提供 host/port 以外的数据，可以把数据放到 metadata 里面，示例如下：
{
"nodes": [
{ "host": "0.0.0.0", "port": 1980, "weight": 1, "metadata": {"b": 1} }
]
}
最新版本：2.10
Apache APISIX 2.10 版本于2021年10月上旬正式发布！这是Apache APISIX 首个 LTS 版本，同时支持 10+ 个新功能和新插件，里程碑：第一个 LTS 版本，对于 Apache APISIX 来说，本次发布的 2.10.0 是一个具有里程碑意义的版本，因为 Apache APISIX 2.10.0 是我们的第一个 LTS （Long Time Support）的版本。我们会在 Apache APISIX 2.10.0 的基础上发布后续的 patch 版本，也就是 2.10.1、2.10.2 等版本。这些版本会从主分支上 backport bugfix。按计划，10 月份我们会发布首个 LTS 版本的首个 patch 版本，也就是 Apache APISIX 2.10.1。之后我们会交替发布 2.10.x（例如 2.10.2 ） 和 2.x（例如 2.11.0）两个版本线，保持功能迭代的同时，确保 LTS 版本能够得到较新的 bugfix。值得一提的是，Apache APISIX 2.10.0 的 docker 镜像将会内置 APISIX OpenResty，无需自行编译就能用到 Apache APISIX 的全部功能。
新功能：service 增加 hosts 属性
在 Apache APISIX 2.10.0 版本里面，我们给 service 加上了 hosts 属性。就像 service 里面其他字段一样，route 可以从 service 中继承 hosts 属性。
新功能：支持设置镜像请求的比例
proxy-mirror 插件支持设置镜像请求的比例，是用户们一直在期待的功能，我们在 Apache APISIX 2.10.0 上支持了这个功能。通过设置 sample_ratio，可以控制被镜像到测试服务的请求数量。
新组件：APISIX Python Plugin Runner
继 Java Plugin Runner 和 Go Plugin Runner 之后，Apache APISIX 又迎来了新的 Plugin Runner。Apache APISIX Python Plugin Runner 已于 9 月 6 日发布了 0.1.0 版本。
最新版本：3.0
APISIX 正式于2022年11月中旬发布了 3.0 版本：
新增了 Consumer Group，可以更方便地管理消费者；
支持配置 DNS 解析域名类型的顺序；
新增 AI 平面，更智能化地对配置与流量进行分析与呈现；
对多个现有生态插件进行更细致的优化。
除了以上技术层面的细节改动外，还有很多新的功能特性与生态扩展细节均在下文中为大家呈现。可以说这次的版本迭代，真正做到了 “性能更强更智能，生态更广更多样”。如果想立刻体验 APISIX 3.0 正式版本，可以即刻前往官网进行下载与使用。新增亮点汇总：
1. 全面支持 ARM64
目前 ARM64 对于云厂商来说，已成为一个非常主流的服务器架构选型。从 AWS Graviton、GCP Tau T2A 再到华为鲲鹏等系列产品，可以看到各家云厂商都开始推出了基于 ARM 架构的服务器。目前从数据来看，Arm 架构的服务器在性价比层面的表现略优于 X86。为了顺应时代技术潮流，APISIX 也在 ARM64 上做了全面的 CI 回归。保证用户在 ARM 架构中运行 APISIX 时，依旧可以顺畅运行各种功能。
2. 新增 gRPC 客户端
在 3.0 版本中，将新增一个 core.grpc 模块。如果你熟悉 NGINX 和 OpenResty 的话，就知道这两者对于 gRPC 的支持相当有限，仅停留在执行反向代理或负载均衡这样的基础功能上。 而 APISIX 在目前 2.x 版本中就已经实现了 gRPC 和 HTTP 协议的转换。在 3.0 版本中，将通过新增 gRPC 客户端的方式，允许开发者直接调⽤第三⽅的 gRPC 服务，⽆需引⼊额外的组件或要求服务提供⽅额外使⽤ HTTP 接口，将使用过程大大简捷化。
3. 重新设计 Admin API
目前在使用 APISIX 时，你可能会发现 APISIX 的响应体中掺杂了很多没有意义的数据，比如一些 etcd 的返回值，没有进行任何剪裁就直接传送给了客户端。同时目前整个响应体的架构设计也并不完善，存在一些冗余字段。在 APISIX 3.0 版本中，重新设计了响应体结构，新的格式可以让整个请求格式和返回体都更加的 Restful 化，从而让用户更加方便地使用新版本的 Admin API。当然该过程也允许通过参数来控制使用哪个版本的 Admin API，不用害怕升级后兼容不了之前的版本。
4. DP 和 CP 分离
APISIX 在最近一两年内出现了多个安全相关的漏洞，大多数漏洞的根本原因都是因为 APISIX 在默认部署模式下，将数据面与控制面部署在一起了。一旦数据面上存在安全漏洞，攻击者就可以通过数据面直接侵入控制面，从而影响到其他所有的数据面。因此在 3.0 版本中，新增了部署模式配置 deployment，默认属性为 traditional，也就是数据面与控制面部署在一起。当然，新配置模式还是更建议大家将属性设置为 data_plane 或 control_plane，从而实现数据面与控制面的完全分离。在完全分离后，不仅能解决上述安全隐患，还能更好地在数据面和控制面中分别进行功能的迭代而互不影响。
5. 新增 AI 平面
在数据平面和控制平面之外，Apache APISIX 新增了 AI 平面。 通过对于 API 流量和配置的学习与分析，减轻开发者和维护者的使用和运维压力。比如以下两个场景就可以通过 AI 平面进行自动优化：
发现没有身份认证的 API，并给出风险提示；
对于只配置了身份认证等 Access 阶段插件的 API，自动跳过 log 等不必要阶段，加快处理速度。
AI 平面给流量处理带来了新的可能性，在后续使用过程中，类似上游服务自动热身、安全威胁发现等都可以通过 AI 平面来进行处理。
6. 更完善的服务发现支持
APISIX 在现版本中，已支持集成了很多服务发现组件，比如 Zookeeper、Consul、Nacos 等。但目前这些集成都是在数据面上完成的，一旦你的数据面节点非常多，这对于后续的服务发现组件压力也是非常大的。尤其是像 ETCD 和 ZooKeeper 这一类提供强一致性的组件，通常无法承受太大量的连接数；此外，用户还需要为 Apache APISIX 数据面配置服务发现组件的认证，如果你在使用虚拟机部署 Apache APISIX，那么你需要将认证配置同步到每一个实例。
同时在用户实际生产环境中，他们想要的不仅仅是一个简单的类似于像 Consul KV 的集成或者是 DNS 的集成，而是更希望能做到类似健康检查等更多完整功能的集成。因此在 APISIX 3.0 中，我们通过新增一个子项目 APISIX-SEED 进行了一层抽象，实现了控制层面的服务发现支持，降低了对服务发现组件的压力。后端服务的节点将由 APISIX-SEED 组件进行更新然后同步到 ETCD，最终被 Apache APISIX 所使用。
7. 新增 xRPC 框架
APISIX 在现版本中支持代理 TCP 协议，但是有些时候，纯粹的 TCP 协议代理是不够的。用户需要的是特定应用协议的代理，比如 Redis Proxy、Kafka Proxy 等。因为有些功能必须在对该协议进行编解码之后才能实现。因此，APISIX 在 3.0 版本中实现了一个名为 xRPC 的四层协议拓展框架，允许开发者在上面自定义特定的应用协议。基于 xRPC，开发者可以通过 Lua 代码对请求和响应进行编解码，进而在了解协议内容的基础上完成故障注入、日志上报、动态路由等功能的实现。
基于 xRPC 框架，APISIX 可以提供对若干主流应用协议的代理实现。同时用户也可以基于该框架来支持自己私有的基于 TCP 的应用协议，使其具备类似 HTTP 协议代理的 精准颗粒度 的和 更高阶的七层控制 。而在不同的协议之上，又可以去抽象一些共性因素，实现相关插件能力，让不同的协议可以共享这些能力。
8. 支持更多四层可观测性
APISIX 在可观测性的功能支持上一直都投入很多，几乎支持了所有的可观测性组件，比如 Zipkin、Apache SkyWalking、Datadog 等等。同时还支持了各种各样的日志组件，但这些大多都是在七层（应用层）进行的。在 APISIX 3.0 版本中将会增加更多基于四层（传输层）的可观测性支持。比如增加了四层上对于 Prometheus 和各种日志的支持，不仅可以让用户非常轻松地观测到七层流量中哪里出了问题，也可以去发现四层的流量运作状况。
9. 集成 OpenAPI 规范
API 其实是一个涉及从开发、测试、上线到整个全生命周期的元素。在 APISIX 3.0 版本中，将支持标准的 OpenAPI 3.0 规范。因此，如果你是在一些 API 设计和测试的软件上进行管理 API 的话，就可以非常方便地通过数据导出和导入，将其放置在 APISIX 中进行管理和维护。同时 APISIX 中的各种 API 也可以通过 OpenAPI 3.0 规范进行导出，然后再导入到其他系统中使用。除此之外，在 3.0 版本中 APISIX 也支持了针对 Postman 相关自定义格式的支持（Postman Collection Format v2），实现两者之间的数据传输，从而更方便地进行集成。
10. Gateway API 的全面支持和服务网格
在 APISIX Ingress 的版本迭代中，已开始对 Gateway API 进行支持，最新的 1.5 版本中已基本支持了所有的 Gateway API 配置。由于 Kubernetes Ingress 资源本身的限制，南北向场景中很多的流量管理能力无法被很好的表达出来，因此市场上大量的 Ingress Controller 解决方案都提供了自定义的 CRD，虽然这样能很好地帮助用户管理流量，但是却间接提高了迁移的成本，几乎导致用户被某个 Ingress Controller 选型锁定。因此 Kubernetes 社区在前两年开始着手制定 Gateway API 这一标准。
Gateway API 是一个面向角色分层的协议，通常像 AWS、GCP 这样的云厂商会充当基础设施提供者，他们会提供若干种不同可选的网关选型（GatewayClass）；而网关管理员，通常会创建不同的网关实例（Gateway）；更上层的开发者则只聚焦于如何创建路由来暴露自己的 API，而不关心底层的网关细节。这种情况下就可以通过 APISIX Ingress 去使用 Gateway API 的方式进行各种配置，也就意味着你能够在各个不同的数据面进行切换。在今年年底，APISIX Ingress 将更加完整地支持 Gateway API 以及支持在四层和七层的更多能力。
与大多数服务网格方案不同，APISIX 的服务网格方案更有优势的地方是数据面（得益于 APISIX 本身的高性能），因此在控制面的选择上，更希望去兼容一些社区上已有的主流方案。最终采取了通过使用 xDS 协议与 Istio 进行交互，并将获取到的配置写入到 APISIX 的 xDS 配置中心的方式，来配合 APISIX 生成具体的路由规则，完成对应请求的路由。这种方案不仅可以让整个服务网格更加轻量，同时借助于 APISIX 的高拓展性，也可以进行更方便地二次开发与迁移。
11. 集成更多生态
除了上文提到的 OpenAPI 标准之外，3.0 版本中也会新增非常多的生态插件，比如 OpenFunction、ClickHouse、Elasticsearch、SAML 和 CAS 等，去集成更对关于认证鉴权、安全或者可观测性等。其中一个有趣的插件 workflow 是关于流量调度的， 通过该插件就可以在流量控制层面进行一些更细粒度的处理。比如当条件 A 成立时执行某个行为，条件 B 成立时执行另一个行为等。通过这种更加清晰的方式，让用户更加方便地调度各种业务流量。
小结
不管是 APISIX 从零开始发展到现在，还是已经推出的 3.0 正式版本，你会发现 APISIX 其实并没有在架构层面进行太多的调整与改动，更多的是进行生态、兼容性和产品应用层面的改变。一个开源项目的评判标准，或许并不只有性能和功能，而是需要更多站在用户、开发者和企业的角度，去考虑他们使用这个产品是否可以快速有效地解决当下的痛点。而上文中提到的亮点或者新特性，其实都是通过开源社区的大环境，接收了来自不同开发者或者企业用户的反馈而打造出来的，是他们让开源产品更加实用和充满活力。最后也欢迎大家对 APISIX 3.0.0 正式版进行体验和反馈，期待技术与社区所迸发的技术魅力。
项目主页：
https://apisix.apache.org/
https://github.com/apache/apisix