目录 🌻🌻
- 一、 Apache APISIX介绍
- 1.1 什么是Apache APISIX
- 1.2 APISIX架构
- 1.3 Apache APISIX 的技术优势
- 1.4 APISIX应用场景
- 二、APISIX快速开始
- 2.1 centos7/centos8安装APISIX
一、 Apache APISIX介绍
1.1 什么是Apache APISIX
Apache APISIX 是一个动态、实时、高性能的云原生 API 网关，提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。可以使用Apache APISIX 处理传统的南北向流量，也可以处理服务间的东西向流量。同时，它也支持作为 K8s Ingress Controller 来使用。- Apache APlSlX 官网: https://apisix.apache.org
APISIX主要特性
- 多平台支持:APISIX提供了多平台解决方案，它不但支持裸机运行，也支持在Kubernetes 中使用，还支持与 AWS Lambda、Azure Function、Lua 的数和Apache OpenWhisk 等云服务集成。
全动态能力:APISIX 支持热加载，这意味着你不需要重启服务就可以更新APISIX 的配置。精细化路由:APISIX 支持使用 NGINX 内置变量做为路由的匹配条件，你可以自定义匹配函数来过滤请求，匹配路由。运维友好:APISIX支持与以下工具和平台集成:HashiCorp Vault、Zipkin、Apache SkyWalking、Consu、Nacos、Eureka。通过APISIX Dashboard， 运维人员可以通过友好且直观的 UI 配置 APISIX。- 多语言插件支持:APISIX支持多种开发语言进行插件开发，开发人员可以选择擅长语言的 SDK 开发自定义插件。
1.2 APISIX架构
APISIX 的架构主要分成两部分:
- 第一部分叫做数据面，它是真正去处理来自客户端请求的一个组件，去处理用户的真实流量，包括像身份验证、证书卸载、日志分析和可观测性等功能。
数据面本身并不会存储任何数据，所以它是一个无状态结构。- 第二部分叫做控制面。APISIX 在底层架构上和其它 API网关的一个很大不同就在于控制面。APISIX在控制面上并没有使用传统的类似于像MySQL去做配置存储，而是选择使用 etcd。这样做的好处主要有以下几点:
- 与产品架构的云原生技术体系更统一
- 更贴合 API 网关存放的数据类型
- 能更好地体现高可用特性
- 拥有低于毫秒级别的变化通知
使用 etcd 后，对于数据面而言只需监听 etcd 的变化即可。如果轮询数据库的话，可能需要 5-10 秒才能获取取到最新的配置;但如果监听 etcd 的配置变更，就可以将时间控制在毫秒级别之内，达到实时生效的效果。
APISIX 的主要概念和组件
| 概念/组件 | 描述 |
|---|---|
| Route | 通过路由定义规则来匹配客户端请求，根据匹配结果加载并执行相应的插件，最后把请求转发给到指定的上游应用。 |
| Upstream | 上游的作用是按照配否规则对服务节点进行负载均衡，它的地址信息可以直接配到路由或服务上。 |
| Admin APl | 用户可以通过 Admin APi 控制 APISIX 实例. |
1.3 Apache APISIX 的技术优势
NGINX 与 Kong 的痛点
- 在单体服务时代，使用 NGINX 可以应对大多数的场景，而到了云原生时代，NGINX因为其自身架构的原因则会出现两个问题:
- 首先是 NGINX 不支持集群管理。几乎每家互联网厂商都有自己的 NGINX 配置管理系统，系统虽然大同小异但是一直没有统一的方案。
- 其次是 NGINX 不支持配置的
热加载。很多公司一旦修改了配置，重新加载NGINX 的时间可能需要半个小时以上。并且在 Kubernetes 体系下，上游会经常发生变化，如果使用 NGINX 来处理就需要频繁重启服务，这对于企业是不可接受的。而 Kubernetes 的出现则解决了 NGINX 的痛点，但是又带来了新的问题:
- Kong 需要依赖于 PostgreSQL 或 Cassandra 数据库，这使 Kong 的整个架构非常臃肿，并且会给企业带来高可用的问题。如果数据库故障了，那么整个 API网关都会出现故障。
Kong 的路由使用的是遍历查找，当网关内有超过上千个路由时，它的性能就会出现比较急剧的下降。
无数据库依赖
APISIX 在设计之初，就从底层架构上避免了宕机、丢失数据等情况的发生。因为在控制面上，APISIX 使用了 etcd 存储配置信息，而不是使用关系型数据库，这样做的好处主要有以下几点:
- 与产品架构的云原生技术体系更统一
- 更贴合 API 网关存放的数据类型;
- 能更好地体现高可用特性;
- 拥有低于毫秒级别的变化通知。
使用 etcd 存储配置信息后，对于数据面而言只需监听 etcd 的变化即可。如果采用轮询数据库的方式，可能需要 5-10 秒才能获取到最新的配置信息;
如果监听 etcd 的配置信息变更，APISIX 就可以将获取最新配置的时间控制在毫秒级别之内，达到实时生效。
插件热加载
APISIX 和 NGINX 相比，有两处非常大的变化:APISIX 支持集群管理和动态加载
思考: APISIX是如何实现热加载的
NGINX 热加载的原理
执行 nginx -s reload 热加载命令，就等同于向 NGINX 的 master 进程发送 HUP 信号。在 master 进程收到 HUP 信号后，会依次打开新的监听端口，然后启动新的 worker 进程。此时会存在新旧两套 worker 进程，在新的 worker 进程起来后，master 会向老的worker 进程发送 QUIT 信号进行优雅关闭。老的 worker 进程收到 QUIT 信号后，会首先关闭监听句柄，此时新的连接就只会流进到新的 worker 进程中，老的 worker 进程处理完当前连接后就会结束进程。
NGINX 热加载的缺陷
- 首先，NGINX 频繁热加载会造成连接不稳定，增加丢失业务的可能性。NGINX 在执行 reload 指令时，会在旧的 worker 进程上处理已经存在的连接，处理完连接上的当前请求后，会主动断开连接。此时如果客户端没处理好，就可能会丢失业务这对于客户端来说明显就不是无感知的了。
- 其次，在某些场景下，旧进程回收时间长，进而影响正常业务，比如代理 WebSocket 协议时，由于 NGINX 不解析通讯帧，所以无法知道该请求是否为已处理完毕状态。即使 worker 进程收到来自 master 的退出指令，它也无法立刻退出而是需要等到这些连接出现异常、超时或者某一端主动断开后，才能正常退出。再比如NGINX 做 TCP 层和 UDP 层的反向代理时，它也没法知道一个请求究竟要经过多少次请求才算真正地结束。
- 这就导致旧日 worker 进程的回收时间特别长，尤其是在直播、新闻媒体活语音识别等行业。旧日 worker 进程的回收时间通常能达到半小时甚至更长，这时如果再频繁reload，将会导致 shutting down 进程持续增加，最终甚至会导致 NGINX OOM，严重影响业务.
通过上述架构图可以看到，之所以 APISIX 能摆脱 NGINX 的限制是因为它把上游等配置全部放到 APISIX Core 和 Plugin Runtime 中动态指定。以路由为例，NGINX 需要在配置文件内进行配置，每次更改都需要reload 之后才能生效。而为了实现路由动态配置，Apache APISIX 在 NGINX 配置文件内配置了单个server，这个 server 中只有一个 location。我们把这个 location 作为主入口，所有的请求都会经过这个 location，再由 APISIX Core 动态指定具体上游。因此 Apache APISIX的路由模块支持在运行时增减、修改和删除路由，实现了动态加载。所有的这些变化，对客户端都零感知，没有任何影响。
比如增加某个新域名的反向代理，在 APISIX 中只需创建上游，并添加新的路由即可，整个过程中不需要 NGINX 进程有任何重启。再比如插件系统，APISIX 可以通过 ip-restriction 插件实现 IP 黑白名单功能，这些能力的更新也是动态方式，同样不需要重启服务。借助架构内的 etcd，配置策略以增量方式实时推送，最终让所有规则实时、动态的生效，为用户带来极致体验。
高性能路由匹配算法
- API网关需要从每个请求的 Host、URI、HTTP 方法等特征中匹配到目标规则，以决定如何对该请求进行处理，因此一个优秀的匹配算法是必不可少的。
Apache APISIX 使用的是 RadixTree，它提供了 KV 存储查找的数据结构并对只有一个子节点的中间节点进行了压缩，因此它又被称为压缩前缀树。此外，在已知 API网关产品中 Apache APISIX 首次将 RadixTree 应用到了路由匹配中，支持一个前缀下有多个不同路由的场景,
当对某个请求进行匹配时，RadixTree 将采用层层递进的方式进行匹配，其复杂度为O(K)(K是路由中 URI的长度，与 API数量多少无关)，该算法非常适合公有云、CDN以及路由数量比较多的场景，可以很好地满足路由数量快速增长的需求。
高性能 IP 匹配算法
- 假设现在有一个包含 500 条 IPv4 记录的 IP 库，APISIX 会将 500 条 IPv4 的记录缓存在Hash 表中，
当进行 IP 匹配时使用 Hash 的方式进行査找，时间复杂度为 O(1)。而其他 API 网关则是通过遍历的方式完成 IP 匹配，发送到网关每个请求将逐个遍历最多500 次是否相等后才能知道计算结果。所以APISIX 的高精度 IP 匹配算法大大提高了需要进行海量 IP 黑白名单匹配场景的效率。
当对某个请求进行匹配时，RadixTree 将采用层层递进的方式进行匹配，其复杂度为O(K)(K 是路由中 URI 的长度，与 API数量多少无关)，该算法非常适合公有云、CDN以及路由数量比较多的场景，可以很好地满足路由数量快速增长的需求。
精细化路由
- API 网关通过请求中的流量特征完成预设规则的匹配，常见特征包含了请求中的 Host、URI 路径、URI查询参数、URI路径参数、HTTP 请求方法、请求头等，这些特征是大部分 API 网关产品所支持的。相较于其它产品，Apache APISIX 支持了更多特征以解决复杂多变的使用场景。
首先，Apache APISIX 支持 NGINX 内置变量意味着我们可以将诸如 uri、server name、 server addr,request uri, remote port,remote addr、 query string、 host.hostname、hostname、arg name 等数十种 NGINX 内置变量作为匹配参数，以支持更复杂多变的匹配场景。
其次，Apache APISIX 支持将条件表达式作为匹配规则，其结构是[var，operator，….]]，其中:val,- var 值可使用 NGINX 内置变量:
- operator 支持相等、不等、大于、小于、正则、包含等操作符。
假设表达式为["arg_name”，“fox”]，它意味着当前请求的 URI 查询参数中，是否有”==”。
一个为 name 的参数值等于 fox。
此外，Apache APISIX 支持设置路由 tt1 存活时间
curl http://127.0.0.1:9080/apisix/admin/routes/2?tt1=60
-H'X-API-KEY:edd1c9f034335f136f87ad84b625c8f1'-X PUT -i -d
{"uri":"/aa/index.html""upstream":{"type":"roundrobin""nodes":{"39.97.63.215:80":1}}
}
以上配置表示，在 60s后 APISIX 会自动删除该路由配置，非常适合一些临时验证的场景，比如金丝雀发布、监控输出等。对于线上的流量分流非常方便，是其它网关产品所不具备的能力。
1.4 APISIX应用场景
APISIX是一个动态、实时、高性能的云原生API网关，具有丰富的流量管理功能，适用于多种应用场景。以下是APISIX的主要应用场景：
微服务网关：在微服务架构中，APISIX可以用作微服务网关，管理和转发请求到不同的微服务。它提供路由、负载均衡、流量控制、认证授权等功能，使得微服务之间的通信更加简单和可靠12。
-
API管理：APISIX可以用于管理和控制API的访问。它提供API注册、版本管理、访问控制、限流、监控等功能，帮助开发人员更好地管理和保护API1。
-
服务发现：APISIX可以与服务注册与发现组件（如Consul、Etcd）集成，实现动态服务发现和自动负载均衡。它可以监控服务的健康状态，并根据配置自动调整请求的转发策略1。
微服务治理：APISIX提供微服务治理功能，如限流、熔断、降级和重试等。这些功能有助于提高系统的稳定性和可靠性1。
边缘计算：由于APISIX的高性能和低延迟，它适合在边缘计算场景中使用。它可以在边缘节点上部署，为移动应用、物联网设备等提供高效的API访问和管理1。
-
与其他API网关集成：APISIX可以与其他常见的API网关（如Kong）进行集成，扩展其功能和性能。它可以作为一个插件或模块，与现有的网关架构进行整合，提供更强大的功能和灵活性1。
这些应用场景展示了APISIX在云原生环境中的多样性和灵活性，使其成为现代微服务架构和API管理中的关键组件。
二、APISIX快速开始
2.1 centos7/centos8安装APISIX
安装etcd
APISIX 使用 etcd 作为配置中心进行保存和同步配置。在安装 APISIX 之前，需要在你的主机上安装 etcd。
ETCD_VERSION='3.5.4'
wget https://github.com/etcd-io/etcd/releases/download/V${ETCD_VERSION}/etcd
tar -xvf etcd-V${ETCD_VERSION}-linux-amd64.tar.gz &&\
cd etcd-V${ETCD_VERSION}-linux-amd64 &&\
sudo cp -a etcd etcdctl /usr/bin/
nohup etcd >/tmp/etcd.log 2>&1 &
安装APISIX
通过 RPM 仓库安装
如果当前系统没有安装 OpenResty，请使用以下命令来安装 OpenResty 和 APISIX 仓库
sudo yum install -y https://repos.apiseven.com/packages/centos/apache-apisix-rep
如果已安装 OpenResty 的官方 RPM 仓库，请使用以下命令安装 APISIX 的 RPM 仓库
sudo yum-config-manager --add-repo https://repos.apiseven.com/packages/centos
完成上述操作后使用以下命令安装 APISIX:
sudo yum install apisix
#安装指定版本的 APISIX
sudo yum install apisix-3.0.0
