mirror of
https://gitee.com/iresty/apisix.git
synced 2024-12-02 12:07:35 +08:00
docs(style): fix non-standard spaces between letters (#5566)
This commit is contained in:
parent
db4ad744ea
commit
2a32f13824
@ -27,7 +27,7 @@ title: 常见问题
|
||||
|
||||
## APISIX 和其他的 API 网关有什么不同之处?
|
||||
|
||||
APISIX 基于 etcd 来完成配置的保存和同步,而不是 postgres 或者 MySQL 这类关系型数据库。
|
||||
APISIX 基于 etcd 来完成配置的保存和同步,而不是 PostgreSQL 或者 MySQL 这类关系型数据库。
|
||||
这样不仅去掉了轮询,让代码更加的简洁,配置同步也更加实时。同时系统也不会存在单点,可用性更高。
|
||||
|
||||
另外,APISIX 具备动态路由和插件热加载,特别适合微服务体系下的 API 管理。
|
||||
@ -46,7 +46,7 @@ APISIX 是当前性能最好的 API 网关,单核 QPS 达到 2.3 万,平均
|
||||
|
||||
当然可以,APISIX 提供了灵活的自定义插件,方便开发者和企业编写自己的逻辑。
|
||||
|
||||
[如何开发插件](plugin-develop.md)
|
||||
具体可参考:[如何开发插件](plugin-develop.md)
|
||||
|
||||
## 我们为什么选择 etcd 作为配置中心?
|
||||
|
||||
@ -170,7 +170,7 @@ curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f03433
|
||||
}'
|
||||
```
|
||||
|
||||
3. 使用`serverless`插件:
|
||||
3. 使用 `serverless` 插件:
|
||||
|
||||
```shell
|
||||
curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
@ -213,18 +213,18 @@ Server: APISIX web server
|
||||
|
||||
## 如何修改日志等级
|
||||
|
||||
默认的 APISIX 日志等级为`warn`,如果需要查看`core.log.info`的打印结果需要将日志等级调整为`info`。
|
||||
默认的 APISIX 日志等级为 `warn`,如果需要查看 `core.log.info` 的打印结果需要将日志等级调整为 `info`。
|
||||
|
||||
具体步骤:
|
||||
|
||||
1、修改 conf/config.yaml 中的 `nginx_config` 配置参数`error_log_level: "warn"` 为 `error_log_level: "info"`。
|
||||
1、修改 conf/config.yaml 中的 `nginx_config` 配置参数 `error_log_level: "warn"` 为 `error_log_level: "info"`。
|
||||
|
||||
```yaml
|
||||
nginx_config:
|
||||
error_log_level: "info"
|
||||
```
|
||||
|
||||
2、重启抑或 reload APISIX
|
||||
2、重启或 reload APISIX
|
||||
|
||||
之后便可以在 logs/error.log 中查看到 info 的日志了。
|
||||
|
||||
@ -238,7 +238,7 @@ Apache APISIX 的插件支持热加载。
|
||||
|
||||
默认情况下,APISIX 在处理 HTTP 请求时只监听 9080 端口。如果你想让 APISIX 监听多个端口,你需要修改配置文件中的相关参数,具体步骤如下:
|
||||
|
||||
1. 修改 `conf/config.yaml` 中 HTTP 端口监听的参数`node_listen`,示例:
|
||||
1. 修改 `conf/config.yaml` 中 HTTP 端口监听的参数 `node_listen`,示例:
|
||||
|
||||
```
|
||||
apisix:
|
||||
@ -248,7 +248,7 @@ Apache APISIX 的插件支持热加载。
|
||||
- 9082
|
||||
```
|
||||
|
||||
处理 HTTPS 请求也类似,修改`conf/config.yaml`中 HTTPS 端口监听的参数`ssl.listen_port`,示例:
|
||||
处理 HTTPS 请求也类似,修改 `conf/config.yaml` 中 HTTPS 端口监听的参数 `ssl.listen_port`,示例:
|
||||
|
||||
```
|
||||
apisix:
|
||||
@ -268,7 +268,7 @@ etcd 提供订阅接口用于监听指定关键字、目录是否发生变更(
|
||||
APISIX 主要使用 [etcd.watchdir](https://github.com/api7/lua-resty-etcd/blob/master/api_v3.md#watchdir) 监视目录内容变更:
|
||||
|
||||
* 如果监听目录没有数据更新:该调用会被阻塞,直到超时或其他错误返回。
|
||||
* 如果监听目录有数据更新:etcd 将立刻返回订阅(毫秒级)到的新数据,APISIX 将它更新到内存缓存。
|
||||
* 如果监听目录有数据更新:etcd 将立刻返回订阅(毫秒级)到的新数据,APISIX 将它更新到内存缓存。
|
||||
|
||||
借助 etcd 增量通知毫秒级特性,APISIX 也就完成了毫秒级的配置同步。
|
||||
|
||||
@ -407,7 +407,7 @@ HTTP/1.1 404 Not Found
|
||||
|
||||
## upstream 节点是否支持配置 [FQDN](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) 地址?
|
||||
|
||||
这是支持的,下面是一个 `FQDN` 为 `httpbin.default.svc.cluster.local`(一个 Kubernetes Service) 的示例:
|
||||
这是支持的,下面是一个 `FQDN` 为 `httpbin.default.svc.cluster.local`(一个 Kubernetes Service) 的示例:
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -32,7 +32,7 @@ basic:
|
||||
|
||||
注意:在 APISIX 2.10 之前,开启基本调试模式曾经是设置 `conf/config.yaml` 中的 `apisix.enable_debug` 为 `true`。
|
||||
|
||||
比如对 `/hello` 开启了 `limit-conn`和`limit-count`插件,这时候应答头中会有 `Apisix-Plugins: limit-conn, limit-count`。
|
||||
比如对 `/hello` 开启了 `limit-conn` 和 `limit-count` 插件,这时候应答头中会有 `Apisix-Plugins: limit-conn, limit-count`。
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:1984/hello -i
|
||||
|
@ -24,7 +24,7 @@ title: Route
|
||||
Route 字面意思就是路由,通过定义一些规则来匹配客户端的请求,然后根据匹配结果加载并执行相应的
|
||||
插件,并把请求转发给到指定 Upstream。
|
||||
|
||||
Route 中主要包含三部分内容:匹配规则(比如 uri、host、remote_addr 等),插件配置(限流限速等)和上游信息。
|
||||
Route 中主要包含三部分内容:匹配规则(比如 uri、host、remote_addr 等),插件配(限流限速等)和上游信息。
|
||||
请看下图示例,是一些 Route 规则的实例,当某些属性值相同时,图中用相同颜色标识。
|
||||
|
||||
![路由示例](../../../assets/images/routes-example.png)
|
||||
|
@ -32,7 +32,7 @@ Upstream 的配置可以被直接绑定在指定 `Route` 中,也可以被绑
|
||||
|
||||
### 配置参数
|
||||
|
||||
APISIX 的 Upstream 除了基本的负载均衡算法选择外,还支持对上游做主被动健康检查、重试等逻辑,具体看这个[链接](../admin-api.md#upstream)。
|
||||
APISIX 的 Upstream 除了基本的负载均衡算法选择外,还支持对上游做主被动健康检查、重试等逻辑,具体看这个 [链接](../admin-api.md#upstream)。
|
||||
|
||||
创建上游对象用例:
|
||||
|
||||
@ -119,9 +119,9 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
更多细节可以参考[健康检查的文档](../health-check.md)。
|
||||
更多细节可以参考 [健康检查的文档](../health-check.md)。
|
||||
|
||||
下面是几个使用不同`hash_on`类型的配置示例:
|
||||
下面是几个使用不同 `hash_on` 类型的配置示例:
|
||||
|
||||
#### Consumer
|
||||
|
||||
@ -139,7 +139,7 @@ curl http://127.0.0.1:9080/apisix/admin/consumers -H 'X-API-KEY: edd1c9f034335f1
|
||||
}'
|
||||
```
|
||||
|
||||
新建路由,打开`key-auth`插件认证,`upstream`的`hash_on`类型为`consumer`:
|
||||
新建路由,打开 `key-auth` 插件认证,`upstream` 的 `hash_on` 类型为 `consumer`:
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
@ -159,7 +159,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
测试请求,认证通过后的`consumer_name`将作为负载均衡哈希算法的哈希值:
|
||||
测试请求,认证通过后的 `consumer_name` 将作为负载均衡哈希算法的哈希值:
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/server_port -H "apikey: auth-jack"
|
||||
@ -167,7 +167,7 @@ curl http://127.0.0.1:9080/server_port -H "apikey: auth-jack"
|
||||
|
||||
##### Cookie
|
||||
|
||||
新建路由和`Upstream`,`hash_on`类型为`cookie`:
|
||||
新建路由和 `Upstream`,`hash_on` 类型为 `cookie`:
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
@ -185,7 +185,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
客户端请求携带`Cookie`:
|
||||
客户端请求携带 `Cookie`:
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/hash_on_cookie -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -H "Cookie: sid=3c183a30cffcda1408daf1c61d47b274"
|
||||
@ -193,7 +193,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
|
||||
##### Header
|
||||
|
||||
新建路由和`Upstream`,`hash_on`类型为`header`, `key`为`content-type`:
|
||||
新建路由和 `Upstream`,`hash_on` 类型为 `header`,`key` 为 `content-type`:
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
@ -211,7 +211,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
客户端请求携带`content-type`的`header`:
|
||||
客户端请求携带 `content-type` 的 `header`:
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/hash_on_header -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -H "Content-Type: application/json"
|
||||
|
@ -23,7 +23,7 @@ title: 证书
|
||||
|
||||
`APISIX` 支持通过 TLS 扩展 SNI 实现加载特定的 SSL 证书以实现对 https 的支持。
|
||||
|
||||
SNI(Server Name Indication)是用来改善 SSL 和 TLS 的一项特性,它允许客户端在服务器端向其发送证书之前向服务器端发送请求的域名,服务器端根据客户端请求的域名选择合适的SSL证书发送给客户端。
|
||||
SNI(Server Name Indication)是用来改善 SSL 和 TLS 的一项特性,它允许客户端在服务器端向其发送证书之前向服务器端发送请求的域名,服务器端根据客户端请求的域名选择合适的 SSL 证书发送给客户端。
|
||||
|
||||
### 单一域名指定
|
||||
|
||||
@ -105,8 +105,8 @@ curl --resolve 'test.com:9443:127.0.0.1' https://test.com:9443/hello -vvv
|
||||
|
||||
### 泛域名
|
||||
|
||||
一个 SSL 证书的域名也可能包含泛域名,如`*.test.com`,它代表所有以`test.com`结尾的域名都可以使用该证书。
|
||||
比如`*.test.com`,可以匹配 `www.test.com`、`mail.test.com`。
|
||||
一个 SSL 证书的域名也可能包含泛域名,如 `*.test.com`,它代表所有以 `test.com` 结尾的域名都可以使用该证书。
|
||||
比如 `*.test.com`,可以匹配 `www.test.com`、`mail.test.com`。
|
||||
|
||||
看下面这个例子,请注意我们把 `*.test.com` 作为 sni 传递进来:
|
||||
|
||||
@ -150,7 +150,7 @@ curl --resolve 'www.test.com:9443:127.0.0.1' https://www.test.com:9443/hello -v
|
||||
|
||||
### 多域名的情况
|
||||
|
||||
如果一个 SSL 证书包含多个独立域名,比如`www.test.com`和`mail.test.com`,
|
||||
如果一个 SSL 证书包含多个独立域名,比如 `www.test.com` 和 `mail.test.com`,
|
||||
你可以把它们都放入 `snis` 数组中,就像这样:
|
||||
|
||||
```json
|
||||
|
@ -154,7 +154,7 @@ APISIX 中一些插件添加了自己的 control API。如果你对他们感兴
|
||||
每个 entry 包含以下字段:
|
||||
|
||||
* src_type:表示 health checker 的来源。值是 `[routes,services,upstreams]` 其中之一
|
||||
* src_id:表示创建 health checker 的对象的id。例如,假设 id 为 1 的 Upstream 对象创建了一个 health checker,那么 `src_type` 就是 `upstreams`,`src_id` 就是 1
|
||||
* src_id:表示创建 health checker 的对象的 id。例如,假设 id 为 1 的 Upstream 对象创建了一个 health checker,那么 `src_type` 就是 `upstreams`,`src_id` 就是 1
|
||||
* name: 表示 health checker 的名称
|
||||
* nodes: health checker 的目标节点
|
||||
* healthy_nodes: 表示 health checker 检测到的健康节点
|
||||
|
@ -23,7 +23,7 @@ title: 调试功能
|
||||
|
||||
## `5xx` 响应状态码
|
||||
|
||||
500、502、503等类似的 `5xx` 状态码,是由于服务器错误而响应的状态码,当一个请求出现 `5xx` 状态码时;它可能来源于 `APISIX` 或 `Upstream` 。如何识别这些响应状态码的来源,是一件很有意义的事,它能够快速的帮助我们确定问题的所在。
|
||||
500、502、503 等类似的 `5xx` 状态码,是由于服务器错误而响应的状态码,当一个请求出现 `5xx` 状态码时;它可能来源于 `APISIX` 或 `Upstream` 。如何识别这些响应状态码的来源,是一件很有意义的事,它能够快速的帮助我们确定问题的所在。
|
||||
|
||||
## 如何识别 `5xx` 响应状态码的来源
|
||||
|
||||
@ -31,7 +31,7 @@ title: 调试功能
|
||||
|
||||
## 示例
|
||||
|
||||
示例1:`502` 响应状态码来源于 `Upstream` (IP地址不可用)
|
||||
示例1:`502` 响应状态码来源于 `Upstream` (IP 地址不可用)
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -206,7 +206,7 @@ discovery:
|
||||
|
||||
## upstream 配置
|
||||
|
||||
APISIX 是通过 `upstream.discovery_type`选择使用的服务发现, `upstream.service_name` 与注册中心的服务名进行关联。下面是将 URL 为 "/user/\*" 的请求路由到注册中心名为 "USER-SERVICE" 的服务上例子:
|
||||
APISIX 是通过 `upstream.discovery_type` 选择使用的服务发现,`upstream.service_name` 与注册中心的服务名进行关联。下面是将 URL 为 "/user/\*" 的请求路由到注册中心名为 "USER-SERVICE" 的服务上例子:
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
|
||||
|
@ -31,7 +31,7 @@ Nacos 服务发现模块目前是实验性的。
|
||||
|
||||
### Nacos 配置
|
||||
|
||||
在文件 `conf/config.yaml` 中添加以下配置到:
|
||||
在文件 `conf/config.yaml` 中添加以下配置到:
|
||||
|
||||
```yaml
|
||||
discovery:
|
||||
|
@ -40,8 +40,8 @@ title: 快速入门指南
|
||||
- Protocol:即网络传输协议,示例中使用的是最常见的 `HTTP` 协议。
|
||||
- Port:即端口,示例中使用的 `80` 端口。
|
||||
- Host:即宿主机,示例中的主机是 `httpbin.org`。
|
||||
- Path:即路径,示例中的路径是`/get`。
|
||||
- Query Parameters:即查询字符串,这里有两个字符串,分别是`foo1`和`foo2`。
|
||||
- Path:即路径,示例中的路径是 `/get`。
|
||||
- Query Parameters:即查询字符串,这里有两个字符串,分别是 `foo1` 和 `foo2`。
|
||||
|
||||
运行以下命令,发送请求:
|
||||
|
||||
@ -70,9 +70,9 @@ curl --location --request GET "http://httpbin.org/get?foo1=bar1&foo2=bar2"
|
||||
|
||||
## 前提条件
|
||||
|
||||
- 已安装[Docker Compose 组件](https://docs.docker.com/compose/)。
|
||||
- 已安装 [Docker Compose 组件](https://docs.docker.com/compose/)。
|
||||
|
||||
- 本文使用 [curl](https://curl.se/docs/manpage.html) 命令行进行 API 测试。您也可以使用其他工具例如 [Postman](https://www.postman.com/)等,进行测试。
|
||||
- 本文使用 [curl](https://curl.se/docs/manpage.html) 命令行进行 API 测试。您也可以使用其他工具例如 [Postman](https://www.postman.com/) 等,进行测试。
|
||||
|
||||
<!--
|
||||
#
|
||||
@ -105,14 +105,14 @@ docker-compose -p docker-apisix up -d
|
||||
|
||||
下载所需的所有文件将花费一些时间,这取决于您的网络,请耐心等待。
|
||||
|
||||
下载完成后,在运行 Docker 的宿主机上执行`curl`命令访问 Admin API,根据返回数据判断 Apache APISIX 是否成功启动。
|
||||
下载完成后,在运行 Docker 的宿主机上执行 `curl` 命令访问 Admin API,根据返回数据判断 Apache APISIX 是否成功启动。
|
||||
|
||||
```bash
|
||||
# 注意:请在运行 Docker 的宿主机上执行 curl 命令。
|
||||
curl "http://127.0.0.1:9080/apisix/admin/services/" -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1'
|
||||
```
|
||||
|
||||
返回数据如下所示,表示Apache APISIX 成功启动:
|
||||
返回数据如下所示,表示 Apache APISIX 成功启动:
|
||||
|
||||
```json
|
||||
{
|
||||
@ -134,7 +134,7 @@ curl "http://127.0.0.1:9080/apisix/admin/services/" -H 'X-API-KEY: edd1c9f034335
|
||||
|
||||
Apache APISIX 提供了强大的 [Admin API](./admin-api.md) 和 [Dashboard](https://github.com/apache/apisix-dashboard) 可供我们使用。在本文中,我们使用 Admin API 来做演示。
|
||||
|
||||
我们可以创建一个 [Route](./architecture-design/route.md) 并与上游服务(通常也被称为[Upstream](./architecture-design/upstream.md)或后端服务)绑定,当一个 `请求(Request)` 到达 Apache APISIX 时,Apache APISIX 就会明白这个请求应该转发到哪个上游服务中。
|
||||
我们可以创建一个 [Route](./architecture-design/route.md) 并与上游服务(通常也被称为 [Upstream](./architecture-design/upstream.md) 或后端服务)绑定,当一个 `请求(Request)` 到达 Apache APISIX 时,Apache APISIX 就会明白这个请求应该转发到哪个上游服务中。
|
||||
|
||||
因为我们为 Route 对象配置了匹配规则,所以 Apache APISIX 可以将请求转发到对应的上游服务。以下代码是一个 Route 配置示例:
|
||||
|
||||
@ -227,7 +227,7 @@ curl -i -X GET "http://127.0.0.1:9080/get?foo1=bar1&foo2=bar2" -H "Host: httpbin
|
||||
|
||||
我们在第二步中创建的路由是公共的,只要知道 Apache APISIX 对外暴露的地址,**任何人** 都可以访问这个上游服务,这种访问方式没有保护措施,存在一定的安全隐患。在实际应用场景中,我们需要为路由添加身份验证。
|
||||
|
||||
现在我们希望只有特定的用户 `John` 可以访问这个上游服务,需要使用[消费者(Consumer)](./architecture-design/consumer.md) 和 [插件(Plugin)](./architecture-design/plugin.md) 来实现身份验证。
|
||||
现在我们希望只有特定的用户 `John` 可以访问这个上游服务,需要使用 [消费者(Consumer)](./architecture-design/consumer.md) 和 [插件(Plugin)](./architecture-design/plugin.md) 来实现身份验证。
|
||||
|
||||
首先,让我们用 [key-auth](./plugins/key-auth.md) 插件创建一个 [消费者(Consumer)](./architecture-design/consumer.md) `John`,我们需要提供一个指定的密钥:
|
||||
|
||||
|
@ -23,7 +23,7 @@ title: 如何构建 Apache APISIX
|
||||
|
||||
## 步骤1:安装依赖
|
||||
|
||||
Apache APISIX 的运行环境需要依赖 NGINX 和 etcd,所以在安装 Apache APISIX 前,请根据您使用的操作系统安装对应的依赖。我们提供了 **CentOS7** 、**Fedora 31 & 32** 、**Ubuntu 16.04 & 18.04** 、 **Debian 9 & 10** 和 **MacOS** 上的依赖安装操作步骤,详情请参考[安装依赖](install-dependencies.md)。
|
||||
Apache APISIX 的运行环境需要依赖 NGINX 和 etcd,所以在安装 Apache APISIX 前,请根据您使用的操作系统安装对应的依赖。我们提供了 **CentOS7** 、**Fedora 31 & 32** 、**Ubuntu 16.04 & 18.04** 、 **Debian 9 & 10** 和 **MacOS** 上的依赖安装操作步骤,详情请参考 [安装依赖](install-dependencies.md)。
|
||||
|
||||
通过 Docker 或 Helm Chart 安装 Apache APISIX 时,已经包含了所需的 NGINX 和 etcd,请参照各自对应的文档。
|
||||
|
||||
@ -83,7 +83,7 @@ sudo yum install -y https://repos.apiseven.com/packages/centos/7/x86_64/apisix-2
|
||||
wget https://downloads.apache.org/apisix/2.10.2/apache-apisix-2.10.2-src.tgz
|
||||
```
|
||||
|
||||
您也可以通过 Apache APISIX 官网下载 Apache APISIX Release 源码包。 Apache APISIX 官网也提供了 Apache APISIX、APISIX Dashboard 和 APISIX Ingress Controller 的源码包,详情请参考[Apache APISIX 官网-下载页](https://apisix.apache.org/zh/downloads)。
|
||||
您也可以通过 Apache APISIX 官网下载 Apache APISIX Release 源码包。 Apache APISIX 官网也提供了 Apache APISIX、APISIX Dashboard 和 APISIX Ingress Controller 的源码包,详情请参考 [Apache APISIX 官网-下载页](https://apisix.apache.org/zh/downloads)。
|
||||
|
||||
3. 解压 Apache APISIX Release 源码包:
|
||||
|
||||
@ -117,7 +117,7 @@ apisix init
|
||||
|
||||
### 测试配置文件
|
||||
|
||||
运行以下命令测试配置文件。 APISIX 将根据 `config.yaml` 生成 `nginx.conf` ,并检查 `nginx.conf` 的语法是否正确。
|
||||
运行以下命令测试配置文件。 APISIX 将根据 `config.yaml` 生成 `nginx.conf`,并检查 `nginx.conf` 的语法是否正确。
|
||||
|
||||
```shell
|
||||
# generate `nginx.conf` from `config.yaml` and test it
|
||||
@ -135,7 +135,7 @@ apisix start
|
||||
|
||||
### 停止运行 Apache APISIX
|
||||
|
||||
优雅停机 `apisix quit` 和强制停机 `apisix stop`都可以停止运行 Apache APISIX。建议您优先选择优雅停机的方式停止 Apache APISIX,因为这种停止方式能够保证 Apache APISIX 完成了已经接受到的请求之后再停止;而强制停机则是立即停止 Apache APISIX,在这种情况下,Apache APISIX 接收到但未完成的请求会随着强制停机一并停止。
|
||||
优雅停机 `apisix quit` 和强制停机 `apisix stop` 都可以停止运行 Apache APISIX。建议您优先选择优雅停机的方式停止 Apache APISIX,因为这种停止方式能够保证 Apache APISIX 完成了已经接受到的请求之后再停止;而强制停机则是立即停止 Apache APISIX,在这种情况下,Apache APISIX 接收到但未完成的请求会随着强制停机一并停止。
|
||||
|
||||
执行优雅停机的命令如下所示:
|
||||
|
||||
@ -200,7 +200,7 @@ apisix help
|
||||
|
||||
**配置 NGINX 路径**
|
||||
|
||||
出现`Error unknown directive "lua_package_path" in /API_ASPIX/apisix/t/servroot/conf/nginx.conf` 报错的解决方法如下:
|
||||
出现 `Error unknown directive "lua_package_path" in /API_ASPIX/apisix/t/servroot/conf/nginx.conf` 报错的解决方法如下:
|
||||
|
||||
确保将 OpenResty 设置为默认的 NGINX,并按如下所示导出路径:
|
||||
|
||||
@ -218,7 +218,7 @@ apisix help
|
||||
prove -Itest-nginx/lib -r t/plugin/openid-connect.t
|
||||
```
|
||||
|
||||
关于测试用例的更多细节,参见[测试框架](https://github.com/apache/apisix/blob/master/docs/en/latest/internal/testing-framework.md)
|
||||
关于测试用例的更多细节,参见 [测试框架](https://github.com/apache/apisix/blob/master/docs/en/latest/internal/testing-framework.md)
|
||||
|
||||
## 步骤5:修改 Admin API key
|
||||
|
||||
@ -272,7 +272,7 @@ Content-Type: text/html
|
||||
|
||||
有些功能需要引入额外的 NGINX 模块到 OpenResty 当中。
|
||||
如果您需要这些功能,您可以构建 APISIX OpenResty。
|
||||
您可以根据[api7/apisix-build-tools](https://github.com/api7/apisix-build-tools)里面的代码,配置自己的构建环境,并完成 APISIX OpenResty 的构建。
|
||||
您可以根据 [api7/apisix-build-tools](https://github.com/api7/apisix-build-tools) 里面的代码,配置自己的构建环境,并完成 APISIX OpenResty 的构建。
|
||||
|
||||
## 步骤7:为 Apache APISIX 添加 systemd 配置文件
|
||||
|
||||
@ -283,4 +283,4 @@ systemctl start apisix
|
||||
systemctl stop apisix
|
||||
```
|
||||
|
||||
如果通过其他方法安装,可以参考[配置文件模板](https://github.com/api7/apisix-build-tools/blob/master/usr/lib/systemd/system/apisix.service)进行修改,并将其放置在 `/usr/lib/systemd/system/apisix.service` 路径下。
|
||||
如果通过其他方法安装,可以参考 [配置文件模板](https://github.com/api7/apisix-build-tools/blob/master/usr/lib/systemd/system/apisix.service) 进行修改,并将其放置在 `/usr/lib/systemd/system/apisix.service` 路径下。
|
||||
|
@ -156,7 +156,7 @@ curl --resolve 'mtls.test.com:<APISIX_HTTPS_PORT>:<APISIX_URL>' "https://<APISIX
|
||||
|
||||
该功能需要 APISIX 运行在 [APISIX-OpenResty](./how-to-build.md#步骤6:为-Apache-APISIX-构建-OpenResty) 上。
|
||||
|
||||
下面是一个与配置 SSL 时相似的 Python 脚本,可为一个已存在的 upstream 资源配置双向认证。如果需要,可修改 API 地址和API Key。
|
||||
下面是一个与配置 SSL 时相似的 Python 脚本,可为一个已存在的 upstream 资源配置双向认证。如果需要,可修改 API 地址和 API Key。
|
||||
|
||||
```python
|
||||
#!/usr/bin/env python
|
||||
|
@ -38,7 +38,7 @@ title: 插件开发
|
||||
|
||||
## 检查外部依赖
|
||||
|
||||
如果你的插件,涉及到一些外部的依赖和三方库,请首先检查一下依赖项的内容。 如果插件需要用到共享内存,需要在[自定义 Nginx 配置](./customize-nginx-configuration.md),例如:
|
||||
如果你的插件,涉及到一些外部的依赖和三方库,请首先检查一下依赖项的内容。 如果插件需要用到共享内存,需要在 [自定义 Nginx 配置](./customize-nginx-configuration.md),例如:
|
||||
|
||||
```yaml
|
||||
# put this in config.yaml:
|
||||
@ -73,7 +73,7 @@ local _M = {
|
||||
}
|
||||
```
|
||||
|
||||
注:新插件的优先级( priority 属性 )不能与现有插件的优先级相同,您可以使用 [control API](./control-api.md#get-v1schema) 的 `/v1/schema` 方法查看所有插件的优先级。另外,同一个阶段里面,优先级( priority )值大的插件,会优先执行,比如 `example-plugin` 的优先级是 0 ,`ip-restriction` 的优先级是 3000 ,所以在每个阶段,会先执行 `ip-restriction` 插件,再去执行 `example-plugin` 插件。这里的“阶段”的定义,参见后续的[确定执行阶段](#确定执行阶段)这一节。对于你的插件,建议采用 1 到 99 之间的优先级。
|
||||
注:新插件的优先级( priority 属性 )不能与现有插件的优先级相同,您可以使用 [control API](./control-api.md#get-v1schema) 的 `/v1/schema` 方法查看所有插件的优先级。另外,同一个阶段里面,优先级( priority )值大的插件,会优先执行,比如 `example-plugin` 的优先级是 0 ,`ip-restriction` 的优先级是 3000 ,所以在每个阶段,会先执行 `ip-restriction` 插件,再去执行 `example-plugin` 插件。这里的“阶段”的定义,参见后续的 [确定执行阶段](#确定执行阶段) 这一节。对于你的插件,建议采用 1 到 99 之间的优先级。
|
||||
|
||||
在 __conf/config-default.yaml__ 配置文件中,列出了启用的插件(都是以插件名指定的):
|
||||
|
||||
|
@ -37,15 +37,15 @@ title: api-breaker
|
||||
|
||||
由代码逻辑自动按**触发不健康状态**的次数递增运算:
|
||||
|
||||
每当上游服务返回`unhealthy.http_statuses`配置中的状态码(比如:500),达到`unhealthy.failures`次时(比如:3 次),认为上游服务处于不健康状态。
|
||||
每当上游服务返回 `unhealthy.http_statuses` 配置中的状态码(比如:500),达到 `unhealthy.failures` 次时(比如:3 次),认为上游服务处于不健康状态。
|
||||
|
||||
第一次触发不健康状态,**熔断 2 秒**。
|
||||
|
||||
然后,2 秒过后重新开始转发请求到上游服务,如果继续返回`unhealthy.http_statuses`状态码,记数再次达到`unhealthy.failures`次时,**熔断 4 秒**(倍数方式)。
|
||||
然后,2 秒过后重新开始转发请求到上游服务,如果继续返回 `unhealthy.http_statuses` 状态码,记数再次达到 `unhealthy.failures` 次时,**熔断 4 秒**(倍数方式)。
|
||||
|
||||
依次类推,2, 4, 8, 16, 32, 64, ..., 256, 最大到 300。 300 是 `max_breaker_sec` 的最大值,允许自定义修改。
|
||||
|
||||
在不健康状态时,当转发请求到上游服务并返回`healthy.http_statuses`配置中的状态码(比如:200),达到`healthy.successes`次时(比如:3 次),认为上游服务恢复健康状态。
|
||||
在不健康状态时,当转发请求到上游服务并返回 `healthy.http_statuses` 配置中的状态码(比如:200),达到 `healthy.successes` 次时(比如:3 次),认为上游服务恢复健康状态。
|
||||
|
||||
## 属性列表
|
||||
|
||||
@ -60,7 +60,7 @@ title: api-breaker
|
||||
|
||||
## 启用方式
|
||||
|
||||
这是一个示例,在指定的路由上启用`api-breaker`插件。
|
||||
这是一个示例,在指定的路由上启用 `api-breaker` 插件。
|
||||
应答 500 或 503 连续 3 次,触发熔断。应答 200 连续 1 次,恢复健康。
|
||||
|
||||
```shell
|
||||
@ -100,7 +100,7 @@ Server: APISIX/1.5
|
||||
|
||||
## 禁用插件
|
||||
|
||||
当想禁用`api-breaker`插件时,非常简单,只需要在插件配置中删除相应的 json 配置,无需重启服务,即可立即生效:
|
||||
当想禁用 `api-breaker` 插件时,非常简单,只需要在插件配置中删除相应的 json 配置,无需重启服务,即可立即生效:
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -46,7 +46,7 @@ title: consumer-restriction
|
||||
对于 `type` 字段是个枚举类型,它可以是 `consumer_name` 或 `service_id` 。分别代表以下含义:
|
||||
|
||||
* **consumer_name**:把 `consumer` 的 `username` 列入白名单或黑名单(支持单个或多个 consumer)来限制对服务或路线的访问。
|
||||
* **service_id**:把 `service` 的 `id` 列入白名单或黑名单(支持一个或多个 service)来限制service的访问,需要结合授权插件一起使用。
|
||||
* **service_id**:把 `service` 的 `id` 列入白名单或黑名单(支持一个或多个 service)来限制 service 的访问,需要结合授权插件一起使用。
|
||||
|
||||
## 示例
|
||||
|
||||
@ -118,7 +118,7 @@ HTTP/1.1 403 Forbidden
|
||||
|
||||
### 如何限制 `service_id`
|
||||
|
||||
`service_id`方式需要与授权插件一起配合使用,这里以key-auth授权插件为例。
|
||||
`service_id` 方式需要与授权插件一起配合使用,这里以 key-auth 授权插件为例。
|
||||
|
||||
1、创建两个 service
|
||||
|
||||
@ -167,7 +167,7 @@ curl http://127.0.0.1:9080/apisix/admin/consumers -H 'X-API-KEY: edd1c9f034335f1
|
||||
}'
|
||||
```
|
||||
|
||||
3、在 route 上开启 `key-auth` 插件并绑定 `service_id` 为`1`
|
||||
3、在 route 上开启 `key-auth` 插件并绑定 `service_id` 为 `1`
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -72,7 +72,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
|
||||
## 测试插件
|
||||
|
||||
请求下接口,发现接口已经返回了`CORS`相关的header,代表插件生效
|
||||
请求下接口,发现接口已经返回了 `CORS` 相关的header,代表插件生效
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/hello -v
|
||||
|
@ -38,7 +38,7 @@ title: dubbo-proxy
|
||||
## 要求
|
||||
|
||||
如果你正在使用 `OpenResty`, 你需要编译它来支持 `dubbo`, 参考 [如何编译](../how-to-build.md#步骤6:为-Apache-APISIX-构建-OpenResty)。
|
||||
在 `APISIX` 中为了实现使从 `http` 代理到 `dubbo`,我们在`Tengine` 的 `mod_dubbo` 基础上对 `dubbo` 模块做了改进。 所有的修改已经提交给 `Tengine`,但是还未合并到最新的 `release` 版本中(Tengine-2.3.2) 。所以目前 `Tengine` 自身是不支持此特性的。
|
||||
在 `APISIX` 中为了实现使从 `http` 代理到 `dubbo`,我们在 `Tengine` 的 `mod_dubbo` 基础上对 `dubbo` 模块做了改进。 所有的修改已经提交给 `Tengine`,但是还未合并到最新的 `release` 版本中(Tengine-2.3.2) 。所以目前 `Tengine` 自身是不支持此特性的。
|
||||
|
||||
## 运行时属性
|
||||
|
||||
@ -100,7 +100,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f1
|
||||
|
||||
将会有同样的结果。
|
||||
|
||||
从上游 `dubbo` 服务返回的数据一定是`Map<String, String>` 类型。
|
||||
从上游 `dubbo` 服务返回的数据一定是 `Map<String, String>` 类型。
|
||||
|
||||
如果返回的数据如下
|
||||
|
||||
|
@ -83,7 +83,7 @@ before the body modification hello world
|
||||
|
||||
## 禁用插件
|
||||
|
||||
当您要禁用`echo`插件时,这很简单,您可以在插件配置中删除相应的 json 配置,无需重新启动服务,它将立即生效:
|
||||
当您要禁用 `echo` 插件时,这很简单,您可以在插件配置中删除相应的 json 配置,无需重新启动服务,它将立即生效:
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -70,7 +70,7 @@ title: error-log-logger
|
||||
### 开启插件
|
||||
|
||||
在 `conf/config.yaml` 中启用插件 `error-log-logger` 即可,不需要在任何 route 或 service 中绑定。
|
||||
下面是一个在`conf/config.yaml` 中添加插件信息的例子:
|
||||
下面是一个在 `conf/config.yaml` 中添加插件信息的例子:
|
||||
|
||||
```yaml
|
||||
plugins: # plugin list
|
||||
@ -83,7 +83,7 @@ plugins: # plugin list
|
||||
|
||||
### 禁用插件
|
||||
|
||||
在 `conf/config.yaml` 中删除或注释掉插件 `error-log-logger`即可。
|
||||
在 `conf/config.yaml` 中删除或注释掉插件 `error-log-logger` 即可。
|
||||
|
||||
```yaml
|
||||
plugins: # plugin list
|
||||
|
@ -94,7 +94,7 @@ Server: APISIX web server
|
||||
Fault Injection!
|
||||
```
|
||||
|
||||
> http status 返回`200`并且响应`body`为`Fault Injection!`,表示该插件已启用。
|
||||
> http status 返回 `200` 并且响应 `body` 为 `Fault Injection!`,表示该插件已启用。
|
||||
|
||||
示例2:为特定路由启用 `fault-injection` 插件,并指定 `delay` 参数:
|
||||
|
||||
|
@ -124,7 +124,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
> signed_headers_string 生成步骤如下:
|
||||
|
||||
* 从请求头中获取指定加入计算的 headers ,具体请参考下节 `使用生成好的签名进行请求尝试` 中的 `SIGNED_HEADERS` 放置的位置。
|
||||
* 从请求头中按顺序取出 `SIGNED_HEADERS` 指定的 headers ,并按顺序用`name:value`方式拼接起来,拼接完后就生成了 `signed_headers_string` 。
|
||||
* 从请求头中按顺序取出 `SIGNED_HEADERS` 指定的 headers ,并按顺序用 `name:value` 方式拼接起来,拼接完后就生成了 `signed_headers_string`。
|
||||
|
||||
```plain
|
||||
HeaderKey1 + ":" + HeaderValue1 + "\n"\+
|
||||
@ -144,7 +144,7 @@ $ curl -i http://127.0.0.1:9080/index.html?name=james&age=36 \
|
||||
-H "User-Agent: curl/7.29.0"
|
||||
```
|
||||
|
||||
根据`签名生成公式`生成的 `signing_string` 为:
|
||||
根据 `签名生成公式` 生成的 `signing_string` 为:
|
||||
|
||||
```plain
|
||||
"GET
|
||||
|
@ -42,7 +42,7 @@ title: ip-restriction
|
||||
| message | string | 可选 | Your IP address is not allowed. | [1, 1024] | 在未允许的IP访问的情况下返回的信息 |
|
||||
|
||||
只能单独启用白名单或黑名单,两个不能一起使用。
|
||||
`message`可以由用户自定义。
|
||||
`message` 可以由用户自定义。
|
||||
|
||||
## 如何启用
|
||||
|
||||
@ -69,7 +69,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
当未允许的IP访问时,默认返回`{"message":"Your IP address is not allowed"}`。如果你想使用自定义的`message`,可以在插件部分进行配置:
|
||||
当未允许的IP访问时,默认返回 `{"message":"Your IP address is not allowed"}`。如果你想使用自定义的 `message`,可以在插件部分进行配置:
|
||||
|
||||
```json
|
||||
"plugins": {
|
||||
|
@ -124,7 +124,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
|
||||
#### 首先进行登录获取 `jwt-auth` token:
|
||||
|
||||
* 没有额外的payload:
|
||||
* 没有额外的 payload:
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/apisix/plugin/jwt/sign?key=user-key -i
|
||||
@ -138,7 +138,7 @@ Server: APISIX web server
|
||||
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJrZXkiOiJ1c2VyLWtleSIsImV4cCI6MTU2NDA1MDgxMX0.Us8zh_4VjJXF-TmR5f8cif8mBU7SuefPlpxhH0jbPVI
|
||||
```
|
||||
|
||||
* 有额外的payload:
|
||||
* 有额外的 payload:
|
||||
|
||||
```shell
|
||||
$ curl -G --data-urlencode 'payload={"uid":10000,"uname":"test"}' http://127.0.0.1:9080/apisix/plugin/jwt/sign?key=user-key -i
|
||||
|
@ -119,8 +119,8 @@ title: kafka-logger
|
||||
## 工作原理
|
||||
|
||||
消息将首先写入缓冲区。
|
||||
当缓冲区超过`batch_max_size`时,它将发送到 kafka 服务器,
|
||||
或每个`buffer_duration`刷新缓冲区。
|
||||
当缓冲区超过 `batch_max_size` 时,它将发送到 kafka 服务器,
|
||||
或每个 `buffer_duration` 刷新缓冲区。
|
||||
|
||||
如果成功,则返回 `true`。
|
||||
如果出现错误,则返回 `nil`,并带有描述错误的字符串(`buffer overflow`)。
|
||||
@ -212,7 +212,7 @@ curl http://127.0.0.1:9080/apisix/admin/plugin_metadata/kafka-logger -H 'X-API-K
|
||||
|
||||
## 禁用插件
|
||||
|
||||
当您要禁用`kafka-logger`插件时,这很简单,您可以在插件配置中删除相应的 json 配置,无需重新启动服务,它将立即生效:
|
||||
当您要禁用 `kafka-logger` 插件时,这很简单,您可以在插件配置中删除相应的 json 配置,无需重新启动服务,它将立即生效:
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -41,7 +41,7 @@ consumer 端配置:
|
||||
|
||||
| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
|
||||
| ---- | ------ | ------ | ------ | ------ | ------------------------------------------------------------------------------------------------------------- |
|
||||
| key | string | 必需 | | | 不同的 `consumer` 对象应有不同的值,它应当是唯一的。不同 consumer 使用了相同的 `key` ,将会出现请求匹配异常。 |
|
||||
| key | string | 必需 | | | 不同的 `consumer` 对象应有不同的值,它应当是唯一的。不同 consumer 使用了相同的 `key`,将会出现请求匹配异常。 |
|
||||
|
||||
router 端配置:
|
||||
|
||||
@ -112,7 +112,7 @@ HTTP/1.1 200 OK
|
||||
...
|
||||
```
|
||||
|
||||
如果当前请求没有正确设置 `apikey` ,将得到一个 `401` 的应答。
|
||||
如果当前请求没有正确设置 `apikey`,将得到一个 `401` 的应答。
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.2:9080/index.html -i
|
||||
|
@ -33,7 +33,7 @@ title: limit-count
|
||||
|
||||
## 简介
|
||||
|
||||
和 [GitHub API 的限速](https://docs.github.com/en/rest/reference/rate-limit)类似,
|
||||
和 [GitHub API 的限速](https://docs.github.com/en/rest/reference/rate-limit) 类似,
|
||||
在指定的时间范围内,限制总的请求个数。并且在 HTTP 响应头中返回剩余可以请求的个数。
|
||||
|
||||
## 参数
|
||||
@ -53,7 +53,7 @@ title: limit-count
|
||||
| redis_port | integer | 可选 | 6379 | [1,...] | 当使用 `redis` 限速策略时,该属性是 Redis 服务节点的端口 |
|
||||
| redis_password | string | 可选 | | | 当使用 `redis` 或者 `redis-cluster` 限速策略时,该属性是 Redis 服务节点的密码。 |
|
||||
| redis_database | integer | 可选 | 0 | redis_database >= 0 | 当使用 `redis` 限速策略时,该属性是 Redis 服务节点中使用的 database,并且只针对非 Redis 集群模式(单实例模式或者提供单入口的 Redis 公有云服务)生效。 |
|
||||
| redis_timeout | integer | 可选 | 1000 | [1,...] | 当使用 `redis` 或者 `redis-cluster` 限速策略时,该属性是 Redis 服务节点以毫秒为单位的超时时间 |
|
||||
| redis_timeout | integer | 可选 | 1000 | [1,...] | 当使用 `redis` 或者 `redis-cluster` 限速策略时,该属性是 Redis 服务节点以毫秒为单位的超时时间 |
|
||||
| redis_cluster_nodes | array | 当 policy 为 `redis-cluster` 时必填| | | 当使用 `redis-cluster` 限速策略时,该属性是 Redis 集群服务节点的地址列表(至少需要两个地址)。 |
|
||||
| redis_cluster_name | string | 当 policy 为 `redis-cluster` 时必填 | | | 当使用 `redis-cluster` 限速策略时,该属性是 Redis 集群服务节点的名称。 |
|
||||
|
||||
@ -85,7 +85,7 @@ curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335
|
||||
}'
|
||||
```
|
||||
|
||||
下面是一个示例,在指定的 `route` 上开启了 `limit count` 插件,并设置 `key_type` 为 `var_combination`:
|
||||
下面是一个示例,在指定的 `route` 上开启了 `limit count` 插件,并设置 `key_type` 为 `var_combination`:
|
||||
|
||||
```shell
|
||||
curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -75,7 +75,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
这里以`route`为例(`service`的使用是同样的方法),在指定的 `route` 上启用 `limit-req` 插件,并设置 `key_type` 为 `var_combination`。
|
||||
这里以 `route` 为例(`service` 的使用是同样的方法),在指定的 `route` 上启用 `limit-req` 插件,并设置 `key_type` 为 `var_combination`。
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
@ -130,7 +130,7 @@ Server: APISIX web server
|
||||
</html>
|
||||
```
|
||||
|
||||
同时,如果你设置了属性 `rejected_msg` 的值为 `"Requests are too frequent, please try again later."` ,当你超过,就会收到如下的响应体:
|
||||
同时,如果你设置了属性 `rejected_msg` 的值为 `"Requests are too frequent, please try again later."`,当你超过,就会收到如下的响应体:
|
||||
|
||||
```shell
|
||||
HTTP/1.1 503 Service Temporarily Unavailable
|
||||
@ -144,11 +144,11 @@ Server: APISIX web server
|
||||
|
||||
这就表示 limit req 插件生效了。
|
||||
|
||||
### 如何在`consumer`上使用
|
||||
### 如何在 `consumer`上使用
|
||||
|
||||
consumer上开启`limit-req`插件,需要与授权插件一起配合使用,这里以key-auth授权插件为例。
|
||||
consumer上开启 `limit-req` 插件,需要与授权插件一起配合使用,这里以 key-auth 授权插件为例。
|
||||
|
||||
1、将`limit-req`插件绑定到consumer上
|
||||
1、将 `limit-req` 插件绑定到consumer上
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/consumers -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
@ -168,7 +168,7 @@ curl http://127.0.0.1:9080/apisix/admin/consumers -H 'X-API-KEY: edd1c9f034335f1
|
||||
}'
|
||||
```
|
||||
|
||||
2、创建`route`并开启`key-auth`插件
|
||||
2、创建 `route` 并开启 `key-auth` 插件
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
@ -191,7 +191,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
|
||||
**测试插件**
|
||||
|
||||
未超过`rate + burst` 的值
|
||||
未超过 `rate + burst` 的值
|
||||
|
||||
```shell
|
||||
curl -i http://127.0.0.1:9080/index.html -H 'apikey: auth-jack'
|
||||
@ -199,7 +199,7 @@ HTTP/1.1 200 OK
|
||||
......
|
||||
```
|
||||
|
||||
当超过`rate + burst` 的值
|
||||
当超过 `rate + burst` 的值
|
||||
|
||||
```shell
|
||||
curl -i http://127.0.0.1:9080/index.html -H 'apikey: auth-jack'
|
||||
@ -214,7 +214,7 @@ HTTP/1.1 403 Forbidden
|
||||
</html>
|
||||
```
|
||||
|
||||
说明绑在`consumer`上的 `limit-req`插件生效了
|
||||
说明绑在 `consumer`上的 `limit-req` 插件生效了
|
||||
|
||||
## 移除插件
|
||||
|
||||
@ -234,7 +234,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
移除`consumer`上的 `limit-req` 插件
|
||||
移除 `consumer`上的 `limit-req` 插件
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/consumers -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -32,7 +32,7 @@ title: mqtt-proxy
|
||||
|
||||
`mqtt-proxy` 只工作在流模式,它可以帮助你根据 MQTT 的 `client_id` 实现动态负载均衡。
|
||||
|
||||
这个插件支持 MQTT [3.1.*](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html) 及[5.0]( https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html )两个协议。
|
||||
这个插件支持 MQTT [3.1.*](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html) 及 [5.0]( https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html ) 两个协议。
|
||||
|
||||
## 属性
|
||||
|
||||
|
@ -43,7 +43,7 @@ OAuth 2 / Open ID Connect(OIDC)插件为 APISIX 提供身份验证和自省
|
||||
| discovery | string | 必须 | | | 身份服务器的发现端点的 URL |
|
||||
| scope | string | 可选 | "openid" | | 用于认证 |
|
||||
| realm | string | 可选 | "apisix" | | 用于认证 |
|
||||
| bearer_only | boolean | 可选 | false | | 设置为`true`将检查请求中带有承载令牌的授权标头 |
|
||||
| bearer_only | boolean | 可选 | false | | 设置为 `true` 将检查请求中带有承载令牌的授权标头 |
|
||||
| logout_path | string | 可选 | "/logout" | | |
|
||||
| redirect_uri | string | 可选 | "ngx.var.request_uri" | | |
|
||||
| timeout | integer | 可选 | 3 | [1,...] | 超时时间,单位为秒 |
|
||||
@ -105,11 +105,11 @@ curl -i -X GET http://127.0.0.1:9080/get -H "Host: httpbin.org" -H "Authorizatio
|
||||
具体细节参见:
|
||||
|
||||
1. [lua-resty-openidc](https://github.com/zmartzone/lua-resty-openidc) 的文档和代码。
|
||||
2. `exp` 字段的定义: [Introspection Response](https://tools.ietf.org/html/rfc7662#section-2.2)。
|
||||
2. `exp` 字段的定义:[Introspection Response](https://tools.ietf.org/html/rfc7662#section-2.2)。
|
||||
|
||||
### 公钥自省
|
||||
|
||||
您还可以提供 JWT 令牌的公钥来验证令牌。 如果您提供了公共密钥和令牌自省端点,则将执行公共密钥工作流,而不是通过身份服务器进行验证。如果要减少额外的网络呼叫并加快过程,可以使用此方法。
|
||||
您还可以提供 JWT 令牌的公钥来验证令牌。如果您提供了公共密钥和令牌自省端点,则将执行公共密钥工作流,而不是通过身份服务器进行验证。如果要减少额外的网络呼叫并加快过程,可以使用此方法。
|
||||
|
||||
以下配置显示了如何向路由添加公钥自省。
|
||||
|
||||
@ -148,7 +148,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/5 -H 'X-API-KEY: edd1c9f034335f13
|
||||
插件可以充当 OIDC 依赖方并重定向到身份提供者的授权端点以通过 OIDC 授权代码流程;
|
||||
请参阅 https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth 。
|
||||
一旦用户通过身份提供者进行身份验证,插件将代表用户从身份提供者获取和管理访问令牌和更多信息。
|
||||
该信息当前存储在会话 cookie 中,该插件将识别 cookie 并使用其中的信息,以避免再次执行认证流程。
|
||||
该信息当前存储在会话 Cookie 中,该插件将识别 Cookie 并使用其中的信息,以避免再次执行认证流程。
|
||||
|
||||
以下命令将此操作模式添加到路由:
|
||||
|
||||
@ -181,4 +181,4 @@ curl http://127.0.0.1:9080/apisix/admin/routes/5 -H 'X-API-KEY: edd1c9f034335f13
|
||||
|
||||
## 故障排除
|
||||
|
||||
如果 APISIX 无法解析/连接到身份提供者,请检查/修改 DNS 设置(`conf / config.yaml`)。
|
||||
如果 APISIX 无法解析/连接到身份提供者,请检查/修改 DNS 设置(`conf/config.yaml`)。
|
||||
|
@ -163,7 +163,7 @@ plugin_attr:
|
||||
| consumer | 与请求匹配的 consumer 的 `consumer_name`。未匹配,则默认为空字符串。 |
|
||||
| node | 命中的 upstream 节点 `ip`。|
|
||||
|
||||
* `Bandwidth`: 流经 APISIX 的总带宽(可分出口带宽和入口带宽),可以统计到每个服务的带宽总和。具有的维度:
|
||||
* `Bandwidth`: 流经 APISIX 的总带宽(可分出口带宽和入口带宽),可以统计到每个服务的带宽总和。具有的维度:
|
||||
|
||||
| 名称 | 描述 |
|
||||
| -------------| ------------- |
|
||||
@ -180,7 +180,7 @@ plugin_attr:
|
||||
|
||||
| 名称 | 描述 |
|
||||
| -------------| ------------- |
|
||||
| type | 该值可以为`apisix`, `upstream` 和 `request`,分别表示耗时的来源为 APISIX、上游及其总和。 |
|
||||
| type | 该值可以为 `apisix`、`upstream` 和 `request`,分别表示耗时的来源为 APISIX、上游及其总和。 |
|
||||
| service | 与请求匹配的 route 的 `service_id`。当路由缺少 service_id 时,则默认为 `$host`。 |
|
||||
| consumer | 与请求匹配的 consumer 的 `consumer_name`。未匹配,则默认为空字符串。 |
|
||||
| node | 命中的 upstream 节点 `ip`。 |
|
||||
|
@ -25,8 +25,8 @@ title: proxy-cache
|
||||
|
||||
基于磁盘的缓存需要注意:
|
||||
|
||||
1. 不能动态配置缓存的过期时间,只能通过后端服务响应头 Expires 或 Cache-Control 来设置过期时间,如果后端响应头中没有 Expires 或 Cache-Control,那么 APISIX 将默认只缓存10秒钟
|
||||
2. 如果后端服务不可用, APISIX 将返回502或504,那么502或504将被缓存10秒钟
|
||||
1. 不能动态配置缓存的过期时间,只能通过后端服务响应头 Expires 或 Cache-Control 来设置过期时间,如果后端响应头中没有 Expires 或 Cache-Control,那么 APISIX 将默认只缓存 10 秒钟
|
||||
2. 如果后端服务不可用, APISIX 将返回 502 或 504,那么 502 或 504 将被缓存 10 秒钟
|
||||
|
||||
### 参数
|
||||
|
||||
@ -105,7 +105,7 @@ Apisix-Cache-Status: MISS
|
||||
hello
|
||||
```
|
||||
|
||||
> http status 返回`200`并且响应头中包含 `Apisix-Cache-Status`,表示该插件已启用。
|
||||
> http status 返回 `200` 并且响应头中包含 `Apisix-Cache-Status`,表示该插件已启用。
|
||||
|
||||
2、验证数据是否被缓存,再次请求上边的地址:
|
||||
|
||||
@ -182,7 +182,7 @@ Apisix-Cache-Status: MISS
|
||||
hello
|
||||
```
|
||||
|
||||
> http status 返回`200`并且响应头中包含 `Apisix-Cache-Status`,表示该插件已启用。
|
||||
> http status 返回 `200` 并且响应头中包含 `Apisix-Cache-Status`,表示该插件已启用。
|
||||
|
||||
3、验证数据是否被缓存,再次请求上面的地址:
|
||||
|
||||
@ -250,9 +250,9 @@ Connection: keep-alive
|
||||
Server: APISIX web server
|
||||
```
|
||||
|
||||
> 响应码为200即表示删除成功,如果缓存的数据未找到将返回404。
|
||||
> 响应码为 200 即表示删除成功,如果缓存的数据未找到将返回 404。
|
||||
|
||||
再次请求,缓存数据未找到返回404:
|
||||
再次请求,缓存数据未找到返回 404:
|
||||
|
||||
```shell
|
||||
$ curl -i http://127.0.0.1:9080/hello -X PURGE
|
||||
|
@ -71,7 +71,7 @@ Last-Modified: Thu, 20 Feb 2020 14:21:41 GMT
|
||||
hello world
|
||||
```
|
||||
|
||||
> 由于指定的 mirror 地址是127.0.0.1:9797,所以验证此插件是否已经正常工作需要在端口为9797的服务上确认,例如,我们可以通过 python 启动一个简单的 server: python -m SimpleHTTPServer 9797。
|
||||
> 由于指定的 mirror 地址是 127.0.0.1:9797,所以验证此插件是否已经正常工作需要在端口为 9797 的服务上确认,例如,我们可以通过 python 启动一个简单的 server: python -m SimpleHTTPServer 9797。
|
||||
|
||||
#### 禁用插件
|
||||
|
||||
|
@ -40,9 +40,9 @@ proxy-rewrite 是上游代理信息重写插件,支持对 `scheme`、`uri`、`
|
||||
| scheme | string | 可选 | "http" | ["http", "https"] | 不推荐使用。应该在 Upstream 的 scheme 字段设置上游的 scheme。
|
||||
| uri | string | 可选 | | | 转发到上游的新 `uri` 地址。 |
|
||||
| method | string | 可选 | | ["GET", "POST", "PUT", "HEAD", "DELETE", "OPTIONS","MKCOL", "COPY", "MOVE", "PROPFIND", "PROPFIND","LOCK", "UNLOCK", "PATCH", "TRACE"] | 将route的请求方法代理为该请求方法。 |
|
||||
| regex_uri | array[string] | 可选 | | | 转发到上游的新 `uri` 地址, 使用正则表达式匹配来自客户端的uri,当匹配成功后使用模板替换转发到上游的uri, 未匹配成功时将客户端请求的uri转发至上游。当`uri`和`regex_uri`同时存在时,`uri`优先被使用。例如:["^/iresty/(.*)/(.*)/(.*)","/$1-$2-$3"] 第一个元素代表匹配来自客户端请求的uri正则表达式,第二个元素代表匹配成功后转发到上游的uri模板。 |
|
||||
| regex_uri | array[string] | 可选 | | | 转发到上游的新 `uri` 地址, 使用正则表达式匹配来自客户端的uri,当匹配成功后使用模板替换转发到上游的uri, 未匹配成功时将客户端请求的uri转发至上游。当 `uri` 和 `regex_uri` 同时存在时,`uri` 优先被使用。例如:["^/iresty/(.*)/(.*)/(.*)","/$1-$2-$3"] 第一个元素代表匹配来自客户端请求的uri正则表达式,第二个元素代表匹配成功后转发到上游的uri模板。 |
|
||||
| host | string | 可选 | | | 转发到上游的新 `host` 地址,例如:`iresty.com` 。 |
|
||||
| headers | object | 可选 | | | 转发到上游的新`headers`,可以设置多个。头信息如果存在将重写,不存在则添加。想要删除某个 header 的话,把对应的值设置为空字符串即可。支持使用 Nginx 的变量,需要以 `$` 开头,如 `client_addr: $remote_addr` :表示请求头 `client_addr` 为客户端IP。 |
|
||||
| headers | object | 可选 | | | 转发到上游的新 `headers`,可以设置多个。头信息如果存在将重写,不存在则添加。想要删除某个 header 的话,把对应的值设置为空字符串即可。支持使用 Nginx 的变量,需要以 `$` 开头,如 `client_addr: $remote_addr` :表示请求头 `client_addr` 为客户端IP。 |
|
||||
|
||||
## 如何启用
|
||||
|
||||
@ -82,7 +82,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f1
|
||||
curl -X GET http://127.0.0.1:9080/test/index.html
|
||||
```
|
||||
|
||||
发送请求,查看上游服务`access.log`,如果输出信息与配置一致:
|
||||
发送请求,查看上游服务 `access.log`,如果输出信息与配置一致:
|
||||
|
||||
```
|
||||
127.0.0.1 - [26/Sep/2019:10:52:20 +0800] iresty.com GET /test/home.html HTTP/1.1 200 38 - curl/7.29.0 - 0.000 199 107
|
||||
|
@ -32,7 +32,7 @@ URI 重定向插件。
|
||||
| regex_uri | array[string] | 可选 | | | 转发到上游的新 `uri` 地址, 使用正则表达式匹配来自客户端的 `uri`,当匹配成功后使用模板替换发送重定向到客户端, 未匹配成功时将客户端请求的 `uri` 转发至上游。`uri` 和 `regex_uri` 不可以同时存在。例如:["^/iresty/(.*)/(.*)/(.*)","/$1-$2-$3"] 第一个元素代表匹配来自客户端请求的 `uri` 正则表达式,第二个元素代表匹配成功后发送重定向到客户端的 `uri` 模板。 |
|
||||
| ret_code | integer | 可选 | 302 | [200, ...] | 请求响应码 |
|
||||
| encode_uri | boolean | 可选 | false | | 当设置为 `true` 时,对返回的 `Location` header进行编码,编码格式参考 [RFC3986](https://datatracker.ietf.org/doc/html/rfc3986) |
|
||||
| append_query_string | boolean | optional | false | | 当设置为`true`时,将请求url的query部分添加到Location里。如果在`uri`或`regex_uri`中配置了query, 那么请求的query会被追加在这个query后,以`&`分隔。 注意:如果已经处理了query,比如使用了nginx变量`$request_uri`,那么启用此功能会造成query重复 |
|
||||
| append_query_string | boolean | optional | false | | 当设置为 `true` 时,将请求url的query部分添加到Location里。如果在 `uri` 或 `regex_uri` 中配置了query, 那么请求的query会被追加在这个query后,以 `&` 分隔。 注意:如果已经处理了query,比如使用了nginx变量 `$request_uri`,那么启用此功能会造成query重复 |
|
||||
|
||||
`http_to_https`,`uri` 或 `regex_uri` 三个中只能配置一个。
|
||||
|
||||
|
@ -75,7 +75,7 @@ X-Request-Id: fe32076a-d0a5-49a6-a361-6c244c1df956
|
||||
### 使用 snowflake 算法生成ID
|
||||
|
||||
> 支持使用 snowflake 算法来生成ID。
|
||||
> 在决定使用snowflake时,请优先阅读一下文档。因为一旦启用配置信息则不可随意调整配置信息。否则可能会导致生成重复ID。
|
||||
> 在决定使用 snowflake 时,请优先阅读一下文档。因为一旦启用配置信息则不可随意调整配置信息。否则可能会导致生成重复ID。
|
||||
|
||||
snowflake 算法默认是不启用的,需要在 `conf/config.yaml` 中开启配置。
|
||||
|
||||
|
@ -105,7 +105,7 @@ X-Server-balancer_addr: 127.0.0.1:80
|
||||
|
||||
### 禁用插件
|
||||
|
||||
禁用`response-rewrite`插件很简单。你不需要重新启动服务,只需要在插件配置中删除相应的 json 配置,它将立即生效。
|
||||
禁用 `response-rewrite` 插件很简单。你不需要重新启动服务,只需要在插件配置中删除相应的 json 配置,它将立即生效。
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
@ -123,8 +123,8 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f1
|
||||
|
||||
## 注意事项
|
||||
|
||||
`ngx.exit`将中断当前请求的执行,并返回状态码给 Nginx。
|
||||
`ngx.exit` 将中断当前请求的执行,并返回状态码给 Nginx。
|
||||
|
||||
![ngx.edit tabular overview](https://cdn.jsdelivr.net/gh/Miss-you/img/picgo/20201113010623.png)
|
||||
|
||||
但是很多人可能会对`ngx.exit`理解出现偏差,即如果你在`access`阶段执行`ngx.exit`,只是中断了请求处理阶段,响应阶段仍然会处理。比如,如果你配置了`response-rewrite`插件,它会强制覆盖你的响应信息(如响应代码)。
|
||||
但是很多人可能会对 `ngx.exit` 理解出现偏差,即如果你在 `access` 阶段执行 `ngx.exit`,只是中断了请求处理阶段,响应阶段仍然会处理。比如,如果你配置了 `response-rewrite` 插件,它会强制覆盖你的响应信息(如响应代码)。
|
||||
|
@ -32,7 +32,7 @@ title: skywalking-logger
|
||||
|
||||
## 定义
|
||||
|
||||
`http-logger` 是一个插件,可将Access Log数据通过`HTTP`推送到 SkyWalking OAP 服务器。如果上下文中存在`tracing context`,插件会自动建立`trace`与日志的关联,并依赖于 [SkyWalking Cross Process Propagation Headers Protocol](https://skywalking.apache.org/docs/main/latest/en/protocols/skywalking-cross-process-propagation-headers-protocol-v3/) 。
|
||||
`http-logger` 是一个插件,可将 Access Log 数据通过 `HTTP` 推送到 SkyWalking OAP 服务器。如果上下文中存在 `tracing context`,插件会自动建立 `trace` 与日志的关联,并依赖于 [SkyWalking Cross Process Propagation Headers Protocol](https://skywalking.apache.org/docs/main/latest/en/protocols/skywalking-cross-process-propagation-headers-protocol-v3/) 。
|
||||
|
||||
这将提供将 Access Log 数据作为JSON对象发送到 SkyWalking OAP 服务器的功能。
|
||||
|
||||
|
@ -31,24 +31,24 @@ title: sls-logger
|
||||
|
||||
## 定义
|
||||
|
||||
`sls-logger` 是使用[RF5424](https://tools.ietf.org/html/rfc5424)标准将日志数据以JSON格式发送到[阿里云日志服务](https://help.aliyun.com/document_detail/112903.html?spm=a2c4g.11186623.6.763.21321b47wcwt1u)。
|
||||
`sls-logger` 是使用 [RF5424](https://tools.ietf.org/html/rfc5424) 标准将日志数据以JSON格式发送到 [阿里云日志服务](https://help.aliyun.com/document_detail/112903.html?spm=a2c4g.11186623.6.763.21321b47wcwt1u)。
|
||||
|
||||
该插件提供了将Log Data作为批处理推送到阿里云日志服务器的功能。如果您没有收到日志数据,请放心一些时间,它会在我们的批处理处理器中的计时器功能到期后自动发送日志。
|
||||
该插件提供了将 Log Data 作为批处理推送到阿里云日志服务器的功能。如果您没有收到日志数据,请放心一些时间,它会在我们的批处理处理器中的计时器功能到期后自动发送日志。
|
||||
|
||||
有关Apache APISIX中Batch-Processor的更多信息,请参考:
|
||||
有关 Apache APISIX 中 Batch-Processor 的更多信息,请参考:
|
||||
[Batch-Processor](../batch-processor.md)
|
||||
|
||||
## 属性列表
|
||||
|
||||
|属性名称 |必选项 |描述|
|
||||
|--------- |--------|-----------|
|
||||
| host |必要的| TCP 服务的IP地址或主机名,请参考:[阿里云日志服务列表](https://help.aliyun.com/document_detail/29008.html?spm=a2c4g.11186623.2.14.49301b4793uX0z#reference-wgx-pwq-zdb),建议配置 IP 取代配置域名。|
|
||||
| host |必要的| TCP 服务的 IP 地址或主机名,请参考:[阿里云日志服务列表](https://help.aliyun.com/document_detail/29008.html?spm=a2c4g.11186623.2.14.49301b4793uX0z#reference-wgx-pwq-zdb),建议配置 IP 取代配置域名。|
|
||||
| port |必要的| 目标端口,阿里云日志服务默认端口为 10009。|
|
||||
| timeout |可选的|发送数据超时间。|
|
||||
| project |必要的|日志服务Project名称,请提前在阿里云日志服务中创建 Project。|
|
||||
| logstore | 必须的 |日志服务Logstore名称,请提前在阿里云日志服务中创建 Logstore。|
|
||||
| access_key_id | 必须的 | AccessKey ID。建议使用阿里云子账号AK,详情请参见[授权](https://help.aliyun.com/document_detail/47664.html?spm=a2c4g.11186623.2.15.49301b47lfvxXP#task-xsk-ttc-ry)。|
|
||||
| access_key_secret | 必须的 | AccessKey Secret。建议使用阿里云子账号AK,详情请参见[授权](https://help.aliyun.com/document_detail/47664.html?spm=a2c4g.11186623.2.15.49301b47lfvxXP#task-xsk-ttc-ry)。|
|
||||
| project |必要的|日志服务 Project 名称,请提前在阿里云日志服务中创建 Project。|
|
||||
| logstore | 必须的 |日志服务 Logstore 名称,请提前在阿里云日志服务中创建 Logstore。|
|
||||
| access_key_id | 必须的 | AccessKey ID。建议使用阿里云子账号 AK,详情请参见 [授权](https://help.aliyun.com/document_detail/47664.html?spm=a2c4g.11186623.2.15.49301b47lfvxXP#task-xsk-ttc-ry)。|
|
||||
| access_key_secret | 必须的 | AccessKey Secret。建议使用阿里云子账号 AK,详情请参见 [授权](https://help.aliyun.com/document_detail/47664.html?spm=a2c4g.11186623.2.15.49301b47lfvxXP#task-xsk-ttc-ry)。|
|
||||
| include_req_body | 可选的| 是否包含请求体。|
|
||||
|name| 可选的|批处理名字。|
|
||||
|batch_max_size |可选的 |每批的最大大小。|
|
||||
@ -86,7 +86,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/5 -H 'X-API-KEY: edd1c9f034335f13
|
||||
```
|
||||
|
||||
```
|
||||
注释:这里的 100.100.99.135 是阿里云华北3内外地址。
|
||||
注释:这里的 100.100.99.135 是阿里云华北 3 内外地址。
|
||||
```
|
||||
|
||||
## 测试插件
|
||||
@ -105,7 +105,7 @@ hello, world
|
||||
|
||||
## 禁用插件
|
||||
|
||||
想要禁用“sls-logger”插件,是非常简单的,将对应的插件配置从json配置删除,就会立即生效,不需要重新启动服务:
|
||||
想要禁用“sls-logger”插件,是非常简单的,将对应的插件配置从 json 配置删除,就会立即生效,不需要重新启动服务:
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -31,9 +31,9 @@ title: syslog
|
||||
|
||||
## 定义
|
||||
|
||||
`sys` 是一个将Log data请求推送到Syslog的插件。
|
||||
`sys` 是一个将 Log data 请求推送到 Syslog 的插件。
|
||||
|
||||
这将提供将Log数据请求作为JSON对象发送的功能。
|
||||
这将提供将 Log 数据请求作为 JSON 对象发送的功能。
|
||||
|
||||
## 属性列表
|
||||
|
||||
@ -46,10 +46,10 @@ title: syslog
|
||||
| tls | boolean | 可选 | false | | 用于控制是否执行SSL验证 |
|
||||
| flush_limit | integer | 可选 | 4096 | [1, ...] | 如果缓冲的消息的大小加上当前消息的大小达到(> =)此限制(以字节为单位),则缓冲的日志消息将被写入日志服务器。默认为4096(4KB) |
|
||||
| drop_limit | integer | 可选 | 1048576 | | 如果缓冲的消息的大小加上当前消息的大小大于此限制(以字节为单位),则由于缓冲区大小有限,当前的日志消息将被丢弃。默认为1048576(1MB) |
|
||||
| sock_type | string | 可选 | "tcp" | ["tcp","udp"] | 用于传输层的IP协议类型。 |
|
||||
| sock_type | string | 可选 | "tcp" | ["tcp","udp"] | 用于传输层的 IP 协议类型。 |
|
||||
| max_retry_times | integer | 可选 | 1 | [1, ...] | 连接到日志服务器失败或将日志消息发送到日志服务器失败后的最大重试次数。 |
|
||||
| retry_interval | integer | 可选 | 1 | [0, ...] | 重试连接到日志服务器或重试向日志服务器发送日志消息之前的时间延迟(以毫秒为单位)。 |
|
||||
| pool_size | integer | 可选 | 5 | [5, ...] | sock:keepalive使用的Keepalive池大小。 |
|
||||
| pool_size | integer | 可选 | 5 | [5, ...] | sock:keepalive 使用的 Keepalive 池大小。 |
|
||||
| batch_max_size | integer | 可选 | 1000 | [1, ...] | 每批的最大大小 |
|
||||
| buffer_duration | integer | 可选 | 60 | [1, ...] | 必须先处理批次中最旧条目的最大期限(以秒为单位) |
|
||||
| include_req_body | boolean | 可选 | false | | 是否包括请求 body |
|
||||
@ -91,7 +91,7 @@ hello, world
|
||||
|
||||
## 禁用插件
|
||||
|
||||
想要禁用“sys-logger”插件,是非常简单的,将对应的插件配置从json配置删除,就会立即生效,不需要重新启动服务:
|
||||
想要禁用“sys-logger”插件,是非常简单的,将对应的插件配置从 json 配置删除,就会立即生效,不需要重新启动服务:
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -31,23 +31,23 @@ title: tcp-logger
|
||||
|
||||
## 定义
|
||||
|
||||
`tcp-logger` 是用于将日志数据发送到TCP服务的插件。
|
||||
`tcp-logger` 是用于将日志数据发送到 TCP 服务的插件。
|
||||
|
||||
以实现将日志数据以JSON格式发送到监控工具或其它TCP服务的能力。
|
||||
以实现将日志数据以 JSON 格式发送到监控工具或其它 TCP 服务的能力。
|
||||
|
||||
该插件提供了将Log Data作为批处理推送到外部TCP服务器的功能。如果您没有收到日志数据,请放心一些时间,它会在我们的批处理处理器中的计时器功能到期后自动发送日志。
|
||||
该插件提供了将 Log Data 作为批处理推送到外部 TCP 服务器的功能。如果您没有收到日志数据,请放心一些时间,它会在我们的批处理处理器中的计时器功能到期后自动发送日志。
|
||||
|
||||
有关Apache APISIX中Batch-Processor的更多信息,请参考。
|
||||
有关 Apache APISIX 中 Batch-Processor 的更多信息,请参考:
|
||||
[Batch-Processor](../batch-processor.md)
|
||||
|
||||
## 属性列表
|
||||
|
||||
| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
|
||||
| ---------------- | ------- | ------ | ------ | ------- | ------------------------------------------------ |
|
||||
| host | string | 必须 | | | TCP 服务的IP地址或主机名 |
|
||||
| host | string | 必须 | | | TCP 服务的 IP 地址或主机名 |
|
||||
| port | integer | 必须 | | [0,...] | 目标端口 |
|
||||
| timeout | integer | 可选 | 1000 | [1,...] | 发送数据超时间 |
|
||||
| tls | boolean | 可选 | false | | 用于控制是否执行SSL验证 |
|
||||
| tls | boolean | 可选 | false | | 用于控制是否执行 SSL 验证 |
|
||||
| tls_options | string | 可选 | | | TLS 选项 |
|
||||
| batch_max_size | integer | 可选 | 1000 | [1,...] | 每批的最大大小 |
|
||||
| inactive_timeout | integer | 可选 | 5 | [1,...] | 刷新缓冲区的最大时间(以秒为单位) |
|
||||
@ -95,7 +95,7 @@ hello, world
|
||||
|
||||
## 禁用插件
|
||||
|
||||
想要禁用“tcp-logger”插件,是非常简单的,将对应的插件配置从json配置删除,就会立即生效,不需要重新启动服务:
|
||||
想要禁用“tcp-logger”插件,是非常简单的,将对应的插件配置从 json 配置删除,就会立即生效,不需要重新启动服务:
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -37,7 +37,7 @@ title: traffic-split
|
||||
|
||||
traffic-split 插件使用户可以逐步引导各个上游之间的流量百分比。
|
||||
|
||||
注:由于加权循环算法(特别是在重置wrr状态时)的缺点,因此每个上游之间的比率可能不太准确。
|
||||
注:由于加权循环算法(特别是在重置 wrr 状态时)的缺点,因此每个上游之间的比率可能不太准确。
|
||||
|
||||
## 属性
|
||||
|
||||
@ -51,7 +51,7 @@ traffic-split 插件使用户可以逐步引导各个上游之间的流量百分
|
||||
| upstream.type | enum | 可选 | roundrobin | [roundrobin, chash] | roundrobin 支持权重的负载,chash 一致性哈希,两者是二选一。 |
|
||||
| upstream.hash_on | enum | 可选 | vars | | `hash_on` 支持的类型有 `vars`(Nginx 内置变量),`header`(自定义 header),`cookie`,`consumer`,`vars_combinations`,默认值为 `vars`。更多详细信息请参考 [upstream](../admin-api.md#upstream) 用法。|
|
||||
| upstream.key | string | 可选 | | | 该选项只有类型是 `chash` 才有效。根据 `key` 来查找对应的 node `id`,相同的 `key` 在同一个对象中,永远返回相同 id。更多详细信息请参考 [upstream](../admin-api.md#upstream) 用法。 |
|
||||
| upstream.nodes | object | 可选 | | | 哈希表,内部元素的 key 是上游机器地址 列表,格式为地址 + Port,其中地址部 分可以是 IP 也可以是域名,⽐如 192.168.1.100:80、foo.com:80等。 value 则是节点的权重,特别的,当权重 值为 0 有特殊含义,通常代表该上游节点 失效,永远不希望被选中。 |
|
||||
| upstream.nodes | object | 可选 | | | 哈希表,内部元素的 key 是上游机器地址 列表,格式为地址 + Port,其中地址部 分可以是 IP 也可以是域名,⽐如 192.168.1.100:80、foo.com:80 等。 value 则是节点的权重,特别的,当权重 值为 0 有特殊含义,通常代表该上游节点 失效,永远不希望被选中。 |
|
||||
| upstream.timeout | object | 可选 | 15 | | 设置连接、发送消息、接收消息的超时时间(时间单位:秒,都默认为 15 秒)。 |
|
||||
| upstream.pass_host | enum | 可选 | "pass" | ["pass", "node", "rewrite"] | `pass`: 将客户端的 host 透传给上游; `node`: 使用 `upstream` node 中配置的 host; `rewrite`: 使用配置项 `upstream_host` 的值 |
|
||||
| upstream.name | string | 可选 | | | 标识上游服务名称、使⽤场景等。 |
|
||||
@ -204,7 +204,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
|
||||
**插件测试:**
|
||||
|
||||
请求5次,3次请求命中插件1981端口的 upstream, 2次请求命中 `route` 的1980端口 upstream。
|
||||
请求 5 次,3 次请求命中插件 1981 端口的 upstream, 2 次请求命中 `route` 的 1980 端口 upstream。
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/index.html -i
|
||||
@ -267,7 +267,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
|
||||
**插件测试:**
|
||||
|
||||
`match` 规则匹配通过,所有请求都命中插件配置的1981端口 upstream :
|
||||
`match` 规则匹配通过,所有请求都命中插件配置的 1981 端口 upstream :
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/index.html -H 'release: new_release' -i
|
||||
@ -278,7 +278,7 @@ Content-Type: text/html; charset=utf-8
|
||||
world 1981
|
||||
```
|
||||
|
||||
`match` 规则匹配失败,所有请求都命中 `route` 上配置的 1980端口 upstream :
|
||||
`match` 规则匹配失败,所有请求都命中 `route` 上配置的 1980 端口 upstream :
|
||||
|
||||
```shell
|
||||
$ curl http://127.0.0.1:9080/index.html -H 'release: old_release' -i
|
||||
@ -340,13 +340,13 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
插件设置了请求的 `match` 规则及端口为`1981`的 upstream,route 上具有端口为`1980`的 upstream。
|
||||
插件设置了请求的 `match` 规则及端口为 `1981` 的 upstream,route 上具有端口为 `1980` 的 upstream。
|
||||
|
||||
**插件测试:**
|
||||
|
||||
>1、在 `match` 规则校验通过后, 60% 的请求命中到插件的1981端口的 upstream, 40% 的请求命中到 `route` 的1980端口的 upstream。
|
||||
>1、在 `match` 规则校验通过后, 60% 的请求命中到插件的 1981 端口的 upstream, 40% 的请求命中到 `route` 的 1980 端口的 upstream。
|
||||
|
||||
match 规则校验成功, 命中端口为`1981`的 upstream。
|
||||
match 规则校验成功, 命中端口为 `1981` 的 upstream。
|
||||
|
||||
```shell
|
||||
$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'apisix-key: hello' -i
|
||||
@ -357,7 +357,7 @@ Content-Type: text/html; charset=utf-8
|
||||
world 1981
|
||||
```
|
||||
|
||||
match 规则校验失败,,命中默认端口为`1980`的 upstream。
|
||||
match 规则校验失败,命中默认端口为 `1980` 的 upstream。
|
||||
|
||||
```shell
|
||||
$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'apisix-key: hello' -i
|
||||
@ -368,7 +368,7 @@ Content-Type: text/html; charset=utf-8
|
||||
hello 1980
|
||||
```
|
||||
|
||||
在请求5次后,3次命中 `1981` 端口的服务,2次命中 `1980` 端口的服务。
|
||||
在请求 5 次后,3 次命中 `1981` 端口的服务,2 次命中 `1980` 端口的服务。
|
||||
|
||||
>2、`match` 规则校验失败(缺少请求头 `apisix-key` ), 响应都为默认 upstream 的数据 `hello 1980`。
|
||||
|
||||
@ -435,7 +435,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
插件设置了请求的 `match` 规则及端口为`1981`的 upstream,route 上具有端口为`1980`的 upstream 。
|
||||
插件设置了请求的 `match` 规则及端口为 `1981` 的 upstream,route 上具有端口为 `1980` 的 upstream 。
|
||||
|
||||
**测试插件:**
|
||||
|
||||
@ -459,9 +459,9 @@ Content-Type: text/html; charset=utf-8
|
||||
hello 1980
|
||||
```
|
||||
|
||||
在请求5次后,3次命中 `1981` 端口的服务,2次命中 `1980` 端口的服务。
|
||||
在请求 5 次后,3 次命中 `1981` 端口的服务,2 次命中 `1980` 端口的服务。
|
||||
|
||||
>2、第二个 `vars` 的表达式匹配失败(缺少 `name2` 请求参数),`match` 规则校验通过后, 60% 的请求命中到插件的1981端口 upstream, 40% 的请求流量命中到 `route` 的1980端口 upstream。
|
||||
>2、第二个 `vars` 的表达式匹配失败(缺少 `name2` 请求参数),`match` 规则校验通过后, 60% 的请求命中到插件的 1981 端口 upstream, 40% 的请求流量命中到 `route` 的 1980 端口 upstream。
|
||||
|
||||
```shell
|
||||
$ curl 'http://127.0.0.1:9080/index.html?name=jack' -H 'user-id:30' -H 'user-id2:22' -H 'apisix-key: hello' -H 'apisix-key2: world' -i
|
||||
@ -481,7 +481,7 @@ Content-Type: text/html; charset=utf-8
|
||||
hello 1980
|
||||
```
|
||||
|
||||
在请求5次后,3次命中 `1981` 端口的服务,2次命中 `1980` 端口的服务。
|
||||
在请求 5 次后,3 次命中 `1981` 端口的服务,2 次命中 `1980` 端口的服务。
|
||||
|
||||
>3、两个 `vars` 的表达式校验失败(缺少 `name` 和 `name2` 请求参数),`match` 规则校验失败, 响应都为默认 `route` 的 upstream 数据 `hello 1980`。
|
||||
|
||||
|
@ -42,7 +42,7 @@ title: ua-restriction
|
||||
| denylist | array[string] | 可选 | | | 加入黑名单的 User-Agent |
|
||||
| message | string | 可选 | Not allowed. | 长度限制:[1, 1024] | 在未允许的 User-Agent 访问的情况下返回的信息 |
|
||||
|
||||
白名单或黑名单可以同时启用,此插件对 User-Agent 的检查先后顺序依次如下:白名单、黑名单。`message`可以由用户自定义。
|
||||
白名单或黑名单可以同时启用,此插件对 User-Agent 的检查先后顺序依次如下:白名单、黑名单。`message` 可以由用户自定义。
|
||||
|
||||
## 如何启用
|
||||
|
||||
@ -74,7 +74,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f13
|
||||
}'
|
||||
```
|
||||
|
||||
当未允许的 User-Agent 访问时,默认返回`{"message":"Not allowed"}`。如果你想使用自定义的`message`,可以在插件部分进行配置:
|
||||
当未允许的 User-Agent 访问时,默认返回 `{"message":"Not allowed"}`。如果你想使用自定义的 `message`,可以在插件部分进行配置:
|
||||
|
||||
```json
|
||||
"plugins": {
|
||||
|
@ -38,7 +38,7 @@ title: udp-logger
|
||||
|
||||
此插件提供了将批处理数据批量推送到外部 UDP 服务器的功能。如果您没有收到日志数据,请放心一些时间,它会在我们的批处理处理器中的计时器功能到期后自动发送日志
|
||||
|
||||
有关 Apache APISIX 中 Batch-Processor 的更多信息,请参考。
|
||||
有关 Apache APISIX 中 Batch-Processor 的更多信息,请参考:
|
||||
[Batch-Processor](../batch-processor.md)
|
||||
|
||||
## 属性列表
|
||||
|
@ -31,20 +31,20 @@ title: uri-blocker
|
||||
|
||||
## 定义
|
||||
|
||||
该插件可帮助我们拦截用户请求,只需要指定`block_rules`即可。
|
||||
该插件可帮助我们拦截用户请求,只需要指定 `block_rules` 即可。
|
||||
|
||||
## 属性列表
|
||||
|
||||
| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
|
||||
| ------------- | ------------- | ------ | ------ | ---------- | ------------------------------------------------------------------- |
|
||||
| block_rules | array[string] | 必须 | | | 正则过滤数组。它们都是正则规则,如果当前请求 URI 命中任何一个,请将响应代码设置为 rejected_code 以退出当前用户请求。例如: `["root.exe", "root.m+"]`。 |
|
||||
| rejected_code | integer | 可选 | 403 | [200, ...] | 当请求 URI 命中`block_rules`中的任何一个时,将返回的 HTTP 状态代码。 |
|
||||
| rejected_msg | string | 可选 | | 非空 | 当请求 URI 命中`block_rules`中的任何一个时,将返回的 HTTP 响应体。 |
|
||||
| rejected_code | integer | 可选 | 403 | [200, ...] | 当请求 URI 命中 `block_rules` 中的任何一个时,将返回的 HTTP 状态代码。 |
|
||||
| rejected_msg | string | 可选 | | 非空 | 当请求 URI 命中 `block_rules` 中的任何一个时,将返回的 HTTP 响应体。 |
|
||||
| case_insensitive | boolean | 可选 | false | | 是否忽略大小写。当值为 true 时,在匹配请求 URI 时将忽略大小写。默认值是 false 。 |
|
||||
|
||||
## 启用方式
|
||||
|
||||
这是一个示例,在指定的路由上启用`uri blocker`插件:
|
||||
这是一个示例,在指定的路由上启用 `uri blocker` 插件:
|
||||
|
||||
```shell
|
||||
curl -i http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
@ -94,7 +94,7 @@ Server: APISIX web server
|
||||
|
||||
## 禁用插件
|
||||
|
||||
当想禁用`uri blocker`插件时,非常简单,只需要在插件配置中删除相应的 json 配置,无需重启服务,即可立即生效:
|
||||
当想禁用 `uri blocker` 插件时,非常简单,只需要在插件配置中删除相应的 json 配置,无需重启服务,即可立即生效:
|
||||
|
||||
```shell
|
||||
curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
|
||||
|
@ -33,7 +33,7 @@ title: wolf-rbac
|
||||
## 名字
|
||||
|
||||
`wolf-rbac` 是一个认证及授权(rbac)插件,它需要与 `consumer` 一起配合才能工作。同时需要添加 `wolf-rbac` 到一个 `service` 或 `route` 中。
|
||||
rbac 功能由[wolf](https://github.com/iGeeky/wolf)提供, 有关 `wolf` 的更多信息, 请参考[wolf 文档](https://github.com/iGeeky/wolf)。
|
||||
rbac 功能由 [wolf](https://github.com/iGeeky/wolf) 提供, 有关 `wolf` 的更多信息, 请参考 [wolf 文档](https://github.com/iGeeky/wolf)。
|
||||
|
||||
## 属性
|
||||
|
||||
|
@ -42,7 +42,7 @@ title: zipkin
|
||||
| endpoint | string | 必须 | | | Zipkin 的 http 节点,例如`http://127.0.0.1:9411/api/v2/spans`。 |
|
||||
| sample_ratio | number | 必须 | | [0.00001, 1] | 监听的比例 |
|
||||
| service_name | string | 可选 | "APISIX" | | 标记当前服务的名称 |
|
||||
| server_addr | string | 可选 | | | 标记当前 APISIX 实例的IP地址,默认值是 nginx 的内置变量`server_addr` |
|
||||
| server_addr | string | 可选 | | | 标记当前 APISIX 实例的 IP 地址,默认值是 nginx 的内置变量`server_addr` |
|
||||
| span_version | integer| 可选 | 2 | [1, 2] | span 类型版本 |
|
||||
|
||||
目前每个被跟踪的请求会创建下面的 span:
|
||||
@ -101,7 +101,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f1
|
||||
|
||||
### 运行 Zipkin 实例
|
||||
|
||||
e.g. 用docker:
|
||||
e.g. 用 docker:
|
||||
|
||||
```
|
||||
sudo docker run -d -p 9411:9411 openzipkin/zipkin
|
||||
|
@ -27,16 +27,16 @@ title: 基于环境变量进行配置文件切换
|
||||
|
||||
上述问题的解决办法就是通过环境变量来区分当前运行环境,并通过环境变量来切换不同配置文件。APISIX 中对应的环境变量就是:`APISIX_PROFILE`。
|
||||
|
||||
在没有设置`APISIX_PROFILE` 时,默认使用以下三个配置文件:
|
||||
在没有设置 `APISIX_PROFILE` 时,默认使用以下三个配置文件:
|
||||
|
||||
* conf/config.yaml
|
||||
* conf/apisix.yaml
|
||||
* conf/debug.yaml
|
||||
|
||||
如果设置了`APISIX_PROFILE`的值为`prod`,则使用以下三个配置文件:
|
||||
如果设置了 `APISIX_PROFILE` 的值为 `prod`,则使用以下三个配置文件:
|
||||
|
||||
* conf/config-prod.yaml
|
||||
* conf/apisix-prod.yaml
|
||||
* conf/debug-prod.yaml
|
||||
|
||||
通过这种方式虽然会增加配置文件的数量,但可以独立管理,再配置git等版本管理工具,还能更好实现版本管理。
|
||||
通过这种方式虽然会增加配置文件的数量,但可以独立管理,再配置 git 等版本管理工具,还能更好实现版本管理。
|
||||
|
@ -168,7 +168,7 @@ $ curl http://127.0.0.1:9080/hello
|
||||
{"error_msg":"404 Route Not Found"}
|
||||
```
|
||||
|
||||
`host` 规则匹配,请求命中对应的上游, `host` 不匹配,请求返回404消息。
|
||||
`host` 规则匹配,请求命中对应的上游,`host` 不匹配,请求返回404消息。
|
||||
|
||||
#### 5. 参数匹配
|
||||
|
||||
@ -188,7 +188,7 @@ apisix:
|
||||
/blog/:name
|
||||
```
|
||||
|
||||
此时将匹配 `/blog/dog` 和 `/blog/cat` 。
|
||||
此时将匹配 `/blog/dog` 和 `/blog/cat`。
|
||||
|
||||
更多使用方式请参考:[lua-resty-radixtree#parameters-in-path](https://github.com/api7/lua-resty-radixtree/#parameters-in-path)
|
||||
|
||||
@ -217,7 +217,7 @@ $ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f
|
||||
}'
|
||||
```
|
||||
|
||||
这个路由需要请求头 `host` 等于 `iresty.com` ,
|
||||
这个路由需要请求头 `host` 等于 `iresty.com`,
|
||||
请求 cookie `_device_id` 等于 `a66f0cdc4ba2df8c096f74c9110163a9` 等。
|
||||
|
||||
### 如何通过 POST 表单属性过滤路由
|
||||
|
@ -64,7 +64,7 @@ routes:
|
||||
#END
|
||||
```
|
||||
|
||||
*注意*:如果`conf/apisix.yaml`末尾不能找到 `#END`,那么 APISIX 将不会加载这个文件规则到内存。
|
||||
*注意*:如果 `conf/apisix.yaml` 末尾不能找到 `#END`,那么 APISIX 将不会加载这个文件规则到内存。
|
||||
|
||||
### 配置 Router
|
||||
|
||||
|
@ -68,11 +68,11 @@ curl http://127.0.0.1:9080/apisix/admin/stream_routes/1 -H 'X-API-KEY: edd1c9f03
|
||||
```
|
||||
|
||||
例子中 APISIX 对客户端 IP 为 `127.0.0.1` 的请求代理转发到上游主机 `127.0.0.1:1995`。
|
||||
更多用例,请参照 [test case](../../../t/stream-node/sanity.t).
|
||||
更多用例,请参照 [test case](../../../t/stream-node/sanity.t)。
|
||||
|
||||
## 更多 route 匹配选项
|
||||
|
||||
我们可以添加更多的选项来匹配 route 。
|
||||
我们可以添加更多的选项来匹配 route。
|
||||
|
||||
例如
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user