1.Apache APISIX 是什么？
- Apache APISIX是 Apache 软件基金会下的云原生 API 网关，它兼具动态、实时、高性能等特点，提供了负载均衡、动态上游、灰度发布（金丝雀发布）、服务熔断、身份认证、可观测性等丰富的流量管理功能。
- 我们可以使用Apache APISIX来处理传统的南北向流量，也可以处理服务间的东西向流量。同时，它也支持作为 K8s Ingress Controller 来使用。
2.主要特性
- 多平台支持：APISIX 提供了多平台解决方案，它不但支持裸机运行，也支持在 Kubernetes 中使用，还支持与 AWS Lambda、Azure Function、Lua 函数和 Apache OpenWhisk 等云服务集成。
- 多协议支持：支持TCP/UDP 代理、Dubbo 代理、动态 MQTT 代理、gRPC 代理、Websocket 代理、HTTP(S) 反向代理及动态加载 SSL 证书等多种协议。
- 全动态能力：APISIX 支持热加载，这意味着你不需要重启服务就可以更新 APISIX 的配置。请访问为什么 Apache APISIX 选择 NGINX+Lua 技术栈？ | Apache APISIX? -- Cloud-Native API Gateway以了解实现原理。
- 精细化路由：APISIX 支持使用 NGINX 内置变量做为路由的匹配条件，你可以自定义匹配函数来过滤请求，匹配路由。
- 安全防护：丰富的认证、鉴权支持，支持外部的身份认证平台，比如 Auth0，Okta，Authing 等，内置策略，无需配置即可抵御 ReDoS。
- 运维友好：APISIX 支持与以下工具和平台集成，通过 APISIX Dashboard，运维人员可以通过友好且直观的 UI 配置 APISIX。
HashiCorp Vault
Zipkin
Apache SkyWalking
Consul
Nacos
Eureka
- 高度可扩展：支持自定义插件，插件可以用 Java/Go/Python 编写，支持自定义负载均衡算法和自定义路由。
- 多语言插件支持：APISIX 支持多种开发语言进行插件开发，开发人员可以选择擅长语言的 SDK 开发自定义插件。
- Serverless：
1.Lua functions：能在 APISIX 每个阶段调用 lua 函数。
2.Azure functions：能无缝整合进 Azure Serverless Function 中。作为动态上游，能将特定的 URI 请求全部代理到微软 Azure 云中。
3.Apache OpenWhisk：与 Apache OpenWhisk 集成。作为动态上游，能将特定的 URI 请求代理到你自己的 OpenWhisk 集群。
3.APISIX架构
3.1 总体架构
3.2 技术架构
3.3 部署架构
- 下图中的三种形态都允许用户去部署：Admin、Gateway、Gateway+Admin。
- APISIX的解决方案首先是 All In One，即只有一个 “Gateway+Admin” 的包，当用户需要将 Gateway 和 Admin 分别部署时，只需修改配置，是否启用 Admin 就可以实现。
4.APISIX安装
- 官方安装指南：https://apisix.apache.org/zh/docs/apisix/installation-guide/
5.APISIX对象
5.1 对象
- Route：通过路由定义规则来匹配客户端请求，根据匹配结果加载并执行相应的插件，最后把请求转发给到指定的上游应用。
- Service：是某类 API 的抽象（也可以理解为一组 Route 的抽象）。它通常与上游服务抽象是一一对应的，但与路由之间，通常是 1:N 即一对多的关系。
- Upstream：是对虚拟主机抽象，即应用层服务或节点的抽象。你可以通过 Upstream 对象对多个服务节点按照配置规则进行负载均衡。
- Consumer：是某类服务的消费者，需要与用户认证配合才可以使用。当不同的消费者请求同一个 API 时，APISIX 会根据当前请求的用户信息，对应不同的 Plugin 或 Upstream 配置。
- Global Rule：如果你需要一个能作用于所有请求的 Plugin，可以通过 Global Rules 启用一个全局的插件配置。
- Plugin：表示将在 HTTP 请求/响应生命周期期间执行的插件配置。Plugin 的配置信息可以直接绑定在 Route 上，也可以被绑定在 Service、Consumer 或 Plugin Config 上。
- Plugin Config：在很多情况下，我们在不同的路由中会使用相同的插件规则，此时就可以通过 Plugin Config 来设置这些规则。Plugin Config 属于一组通用插件配置的抽象。
5.2 数据模型
5.3 插件优先级
- 对于同一个插件的配置，只能有一个是有效的，其插件配置优先级为：
Consumer > Route > Plugin Config > Service
6.APISIX配置
1.永远不要手工修改conf/config-default.yaml文件，该文件是与 APISIX 源码强绑定。如果需要自定义任何配置，都应在config.yaml文件中完成。
2.当服务每次启动时，apisix 会根据conf/config.yaml配置和模板apisix/cli/ngx_tpl.lua自动生成新的conf/nginx.conf并自动启动服务。
- 动态配置：可在程序执行过程中动态加载，修改配置后不需要重启，可以热加载，分为："Stand-alone"管理模式和etcd配置中心管理模式
1.Stand-alone模式：即本地存储方式：conf/apisix.yaml
2.etcd配置中心管理模式：即路由配置通过Admin API持久化在etcd中
7.插件扩展
7.1 External Plugin
- APISIX 支持使用 Lua 语言编写插件，这种类型的插件在 APISIX 内部执行。
- lua插件扩展教程：https://apisix.apache.org/zh/docs/apisix/plugin-develop/
7.2 Plugin Runner
- 当你在 APISIX 中配置了一个 Plugin Runner ，APISIX 将以子进程的方式运行该 Plugin Runner 。
- 该子进程与 APISIX 进程从属相同用户。当重启或者重新加载 APISIX 时，该 Plugin Runner 也将被重启。
- 一旦你为指定路由配置了 ext-plugin-* 插件， 匹配该路由的请求将触发从 APISIX 到 Plugin Runner 的 RPC 调用。
- 支持的 Plugin Runner
1.Java: https://github.com/apache/apisix-java-plugin-runner
2.Go: https://github.com/apache/apisix-go-plugin-runner
3.Python: https://github.com/apache/apisix-python-plugin-runner
4.JavaScript: https://github.com/zenozeng/apisix-javascript-plugin-runner
8.APISIX基于etcd watch机制
8.1 watch机制流程
- Worker进程启动时初始化ngx_timer_at(0, _automatic_fetch, obj)
function _M.new(key, opts)
ngx_timer_at(0, _automatic_fetch, obj)
end
- _automatic_fetch用户回调将由Nginx核心自动调用，执行sync_data函数
local function _automatic_fetch(premature, self)
local ok, err = xpcall(function()
local ok, err = sync_data(self)
end, debug.traceback)
ngx_timer_at(0, _automatic_fetch, self)
end
- sync_data函数由lua-resty-etcd提供，底层调用etcd的http接口/v3/watch来同步配置
8.2 配置同步延迟分析
1.容器正常上线，由readinessProbe探针反馈就绪，经由控制器同步到etcd，k8s侧链路延时可以忽略不计，取决于同步到etcd的网络延迟
2.watch机制的延迟取决于apisix数据面到etcd服务之间请求/v3/watch接口的网络延迟
3.容器异常下线，延迟取决于livenessProbe探针配置的时间阈值和频次，目前配置的3s，频次3次
参考文档
