文章目录
- 前言
- 一、端口修改
- 1. apisix 端口修改
- 2. dashboard 端口修改
- 3. 登录密码修改
- 二、常用插件介绍
- 1. 常用转换插件
- 1.1 proxy-rewrite插件
- 1.1.1 属性字段
- 1.1.2 配置示例
- 2. 常用认证插件
- 2.1 key-auth插件
- 2.1.1 消费者端字段
- 2.1.2 路由端字段
- 2.1.3 配置示例
- 2.2 basic-auth插件
- 2.2.1 消费者端字段
- 2.2.2 路由端字段
- 2.2.3 配置示例
- 3. 常用安全插件
- 3.1 consumer-restriction插件
- 3.1.1 属性字段
- 3.1.2 配置示例
- 三、消费者配置(数据编辑器方式)
- 1. UI页面对应字段说明
- 2. 配置示例
- 四、上游配置
- 1. UI页面对应字段说明
- 2. 配置示例
- 3. 健康检查
- 3.1 主动健康检查
- 3.2 被动健康检查
- 五、路由配置
- 1. UI页面对应字段说明
- 2. 配置示例(绑定上游方式)
- 六、模拟异常情况
- 1. 模拟节点不健康
- 1.1 上游配置
- 1.2 路由配置如下
- 1.3 测试结果
- 1.4 日志查看
- 1.5 结果分析
- 总结
前言
本文介绍了在 API 网关中进行端口修改、常用插件配置、消费者配置、上游配置和路由配置的方法。通过对这些方面的详细说明,读者可以了解如何灵活地调整和定制自己的 API 网关环境,以满足不同场景下的需求。
一、端口修改
1. apisix 端口修改
添加多个代理监听端口,修改/usr/local/apisix/conf/config.yaml
配置文件,添加如下配置,添加的配置将覆盖默认配置文件。
apisix:
node_listen:
- 9080
- 9081
- 9082
2. dashboard 端口修改
修改/usr/local/apisix/conf/conf.yaml
配置文件,修改如下配置。
conf:
listen:
port: 9000
3. 登录密码修改
可修改/usr/local/apisix/conf/conf.yaml
配置文件中的用户认证配置。
authentication:
users:
- username: admin
password: admin
- username: user
password: user
二、常用插件介绍
使用插件需要配置 plugins 字段,不配置默认不使用插件。启用插件需要把 plugins 字段下 _meta.disable 的值设为 false。
1. 常用转换插件
1.1 proxy-rewrite插件
proxy-rewrite 是处理上游代理信息重写的插件,支持对 scheme、uri、host 等信息进行重写。
1.1.1 属性字段
名称 | 类型 | 是否必填 | 默认值 | 有效值 | 描述 |
---|---|---|---|---|---|
uri | string | 否 | 转发到上游的新 uri 地址 | ||
method | string | 否 | GET, POST, PUT, HEAD, DELETE, OPTIONS,MKCOL, COPY, MOVE, PROPFIND, PROPFIND,LOCK, UNLOCK, PATCH, TRACE | 将路由的请求方法代理为该请求方法 | |
regex_uri | array[string] | 否 | 使用正则表达式匹配来自客户端的 uri,如果匹配成功,则使用模板替换转发到上游的 uri,如果没有匹配成功,则将客户端请求的 uri 转发至上游。当同时配置 uri 和 regex_uri 属性时,优先使用 uri。当前支持多组正则表达式进行模式匹配,插件将逐一尝试匹配直至成功或全部失败。例如:[“^/iresty/(.*)/(.*)/(.*)”, “/$1-$2-$3”, ^/theothers/(.*)/(.*)", “/theothers/$1-$2”],奇数索引的元素代表匹配来自客户端请求的 uri 正则表达式,偶数索引的元素代表匹配成功后转发到上游的 uri 模板。请注意该值的长度必须为偶数值。 | ||
host | string | 否 | 转发到上游的新主机地址 | ||
headers | object | 否 | 转发到上游的新 uri 地址 | ||
headers.add | object | 否 | 添加新的请求头,如果请求头已存在,则追加到末尾。格式为 {“name”: “value”, …} | ||
headers.set | object | 否 | 改写请求头,如果请求头不存在,则会添加。格式为 {“name”: “value”, …} | ||
headers.remove | array | 否 | 移除请求头。格式为 [“name”, …] | ||
use_real_request_uri_unsafe | boolean | 否 | false | 使用 real_request_uri(nginx 中的原始 $request_uri)绕过 URI 规范化。启用它被认为是不安全的,因为它会绕过所有 URI 规范化步骤。 |
1.1.2 配置示例
...
plugins:
proxy-rewrite:
regex_uri:
- ^/postman/(.*)
- /$1
...
...
2. 常用认证插件
2.1 key-auth插件
key-auth插件是一种用于向路由或服务添加身份验证密钥的工具,它需要与消费者配合使用。通过将密钥添加到请求参数或请求头中,消费者可以验证其请求。
2.1.1 消费者端字段
名称 | 类型 | 是否必填 | 描述 |
---|---|---|---|
key | string | 是 | key 是唯一的,不同的消费者应设置不同的 key。如果多个消费者使用了相同的 key,将会出现请求匹配异常。 |
2.1.2 路由端字段
名称 | 类型 | 是否必填 | 默认值 | 描述 |
---|---|---|---|---|
header | string | 否 | apikey | 设置从哪个请求头获取 key |
query | string | 否 | apikey | 设置从哪个请求请求参数获取 key |
header | boolean | 否 | false | 当设置为 false 时,将含有认证信息的请求头或请求参数传递给上游。如果为 true 时,将删除对应的请求头或请求参数,具体删除哪一个取决于是从请求头获取 key 还是从请求参数获取 key。 |
2.1.3 配置示例
消费者端:
username: consumer_demo
desc: consumer_demo描述
plugins:
key-auth:
_meta:
disable: false
key: auth-one
...
路由端:
...
plugins:
key-auth:
_meta:
disable: false
header: apikey
...
...
2.2 basic-auth插件
basic-auth插件是一种用于向路由或服务添加基本访问身份验证的工具。它需要与消费者配合使用。API的消费者可以将他们的密钥添加到请求头中,以验证其请求。不同的消费设置该插件要设置不同的用户名,如果不同消费者使用该插件设置的用户名相同,可能会有异常。
2.2.1 消费者端字段
名称 | 类型 | 是否必填 | 描述 |
---|---|---|---|
username | string | 是 | 消费者的唯一用户名 |
password | string | 是 | 密码 |
2.2.2 路由端字段
名称 | 类型 | 是否必填 | 默认值 | 描述 |
---|---|---|---|---|
hide_credentials | boolean | 否 | false | 设置为 true 时,不会将认证请求头传递给上游 |
2.2.3 配置示例
消费者端:
username: consumer_demo
desc: consumer_demo描述
plugins:
basic-auth:
_meta:
disable: false
password: user
username: user
...
路由端:
...
plugins:
basic-auth:
_meta:
disable: false
hide_credentials: false
...
...
3. 常用安全插件
3.1 consumer-restriction插件
consumer-restriction 插件允许用户根据路由、服务或消费者来设置相应的访问限制。
3.1.1 属性字段
名称 | 类型 | 是否必填 | 默认值 | 有效值 | 描述 |
---|---|---|---|---|---|
type | string | 否 | consumer_name | consumer_name, consumer_group_id, service_id, route_id | 支持设置访问限制的对象类型。 consumer_name:把 Consumer 的 username 列入白名单或黑名单来限制 Consumer 对 Route 或 Service 的访问。 consumer_group_id: 把 Consumer Group 的 id 列入白名单或黑名单来限制 Consumer 对 Route 或 Service 的访问。 service_id:把 Service 的 id 列入白名单或黑名单来限制 Consumer 对 Service 的访问,需要结合授权插件一起使用。 route_id:把 Route 的 id 列入白名单或黑名单来限制 Consumer 对 Route 的访问。 |
whitelist | array[string] | 是 | 加入白名单的对象,优先级高于 allowed_by_methods | ||
blacklist | array[string] | 是 | 加入黑名单的对象,优先级高于 whitelist | ||
rejected_code | integer | 否 | 403 | [200,…] | 当请求被拒绝时,返回的 HTTP 状态码 |
rejected_msg | string | 否 | 当请求被拒绝时,返回的错误信息 | ||
allowed_by_methods | array[object] | 否 | 一组为消费者设置允许的配置,包括用户名和允许的 HTTP 方法列表 | ||
allowed_by_methods.user | 否 | 为消费者设置的用户名 | |||
allowed_by_methods.methods | array[string] | 否 | GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, CONNECT, TRACE, PURGE | 允许的 HTTP 方法列表 |
3.1.2 配置示例
...
plugins:
consumer-restriction:
_meta:
disable: false
allowed_by_methods:
- methods:
- GET
user: postmanget
- methods:
- GET
user: consumer_demo
blacklist:
- consumer_demo2
- consumer_demo3
rejected_code: 403
rejected_msg: 请求被拒绝
type: consumer_name
whitelist:
- postmanget
- consumer_demo
- consumer_demo1
- consumer_demo2
- consumer_demo3
...
...
三、消费者配置(数据编辑器方式)
消费者是路由的消费方,形式包括开发者、最终用户、API 调用等。
它具有最高优先级:Consumer > Route > Plugin Config > Service。
1. UI页面对应字段说明
UI页面字段名 | 数据编辑器字段 | 是否必填 |
---|---|---|
名称 | username | 是 |
描述 | desc | 否 |
插件 | plugins | 否 |
2. 配置示例
创建消费者consumer_demo,配置并启用basic-auth插件。
username: consumer_demo
desc: consumer_demo描述
plugins:
basic-auth:
_meta:
disable: false
password: user
username: user
key-auth:
_meta:
disable: true
key: auth-one
四、上游配置
在 API 网关中,“上游”(Upstream)是指向后端服务的请求转发目标。API Gateway 通过将客户端请求代理到上游服务器来处理和响应这些请求。
1. UI页面对应字段说明
UI页面字段名 | 数据编辑器字段 | 是否必填 | 默认值 | 说明 |
---|---|---|---|---|
名称 | name | 是 | 上游的名称 | |
描述 | desc | 否 | 上游的描述 | |
负载均衡算法 | type | 是 | roundrobin | 默认为带权轮询 |
主机名 | nodes.host | 是 | 目标节点的主机名 | |
端口 | nodes.port | 是 | 目标节点的端口 | |
权重 | nodes.weight | 是 | 目标节点的权重 | |
Host 请求头 | pass_host | 是 | pass | pass:保持与客户端请求一致的主机名 node:使用目标节点列表中的主机名或IP |
重试次数 | retries | 否 | 可用后端节点的数量 | 重试机制将请求发到下一个上游节点。值为 0 表示禁用重试机制,留空表示使用可用后端节点的数量。 |
重试超时时间 | retry_timeout | 否 | 之前的请求和重试请求花费太多时间就不再继续重试 | 限制是否继续重试的时间,若之前的请求和重试请求花费太多时间就不再继续重试。0 代表不启用重试超时机制。 |
协议 | scheme | 是 | HTTP | |
连接超时 | timeout.connect | 是 | 6 | 建立从请求到上游服务器的连接的超时时间 |
发送超时 | timeout.send | 是 | 6 | 发送数据到上游服务器的超时时间 |
接受超时 | timeout.read | 是 | 6 | 从上游服务器接收数据的超时时间 |
连接池容量 | keepalive_pool.size | 否 | 320 | 为 upstream 对象设置独立的连接池容量 |
连接池空闲超时时间 | keepalive_pool.idle_timeout | 否 | 60 | 为 upstream 对象设置独立的连接池空闲超时时间 |
连接池请求数量 | keepalive_pool.requests | 否 | 1000 | 为 upstream 对象设置独立的连接池请求数量 |
2. 配置示例
name: postman
desc: postman描述
type: roundrobin
nodes:
- host: postman-echo.com
port: 80
weight: 1
- host: postman-echo1.com
port: 80
weight: 1
- host: postman-echo2.com
port: 80
weight: 1
pass_host: pass
retries: 3
retry_timeout: 6
scheme: http
timeout:
connect: 6
send: 6
read: 6
keepalive_pool:
idle_timeout: 60
requests: 1000
size: 320
3. 健康检查
- 只有在 upstream 被请求时才会开始健康检查,如果 upstream 被配置但没有被请求,不会触发启动健康检查。
- 如果没有健康的节点,那么请求会继续发送给上游。
- 如果 upstream 中只有一个节点时不会触发启动健康检查,该唯一节点无论是否健康,请求都将转发给上游。
3.1 主动健康检查
主动健康检查指 APISIX 通过预设的探针类型(HTTP、HTTPS、TCP),主动探测上游节点的存活性。
当发向健康节点 A 的 N 个连续探针都失败时,该节点将被标记为不健康,不健康的节点将会被 APISIX 的负载均衡器忽略,无法收到请求;若某个不健康的节点,连续 M 个探针都成功时,该节点将被重新标记为健康,进而可以被代理。
3.2 被动健康检查
被动健康检查指通过判断从 APISIX 转发到上游节点的请求响应状态,来判断对应的上游节点是否健康。相对于主动健康检查,被动健康检查的方式无需发起额外的探针,但是也无法提前感知节点状态,可能会有一定量的失败请求。
若发向健康节点 A 的 N 个连续请求都被判定为失败,则该节点将被标记为不健康。
由于不健康的节点无法收到请求,仅使用被动健康检查无法重新将节点标记为健康,因此需要结合主动健康检查来使用。
五、路由配置
路由根据定义的规则匹配客户端的请求,加载并执行相应的插件,并将请求转发给指定的上游。
1. UI页面对应字段说明
UI页面字段名 | 数据编辑器字段 | 是否必填 | 默认值 | 说明 |
---|---|---|---|---|
名称 | name | 是 | 路由名称唯一的,最大长度为100 | |
标签 | labels | 否 | 为路由增加自定义标签,可用于路由分组。 | |
标签 | labels.tag_name | 否 | tag_name是自定义的标签名,标签名和标签值都要自定义,例如:tag_demo: postman_tag | |
描述 | desc | 否 | 路由的描述 | |
发布 | status | 是 | 1 | 设置路由状态是否启用,1表示启用,0表示禁用 |
匹配条件.路径 | uris | 是 | /* | 匹配 uri 的路径,可设置多个匹配路径 |
匹配条件.HTTP方法 | methods | 否 | 不填默认所有方法,在UI页面需要选择 ALL | |
匹配条件.优先级 | priority | 否 | 0 | 设置匹配条件的优先级 |
选择上游服务 | upstream_id | 是 | 需要绑定的上游服务的 ID,UI页面选择后会自动绑定上游对应的 ID |
2. 配置示例(绑定上游方式)
name: route_demo
labels:
API_VERSION: v1
tag_demo: postman_tag
desc: route_demo描述
status: 1
uris:
- /postman/*
- /postmanget/*
methods:
- GET
priority: 1
plugins:
proxy-rewrite:
regex_uri:
- ^/postman/(.*)
- /$1
upstream_id: '506489652354484505'
六、模拟异常情况
apisix主机为 192.168.145.103。使用公共接口 https://postman-echo.com/get?foo1=bar1&foo2=bar2 进行测试,该接口的返回数据如下:
1. 模拟节点不健康
这里准备了6个节点,分别为 postman-echo.com、postman-echo.com1、postman-echo.com2、postman-echo.com3、postman-echo.com4、postman-echo.com5,其中 postman-echo.com 节点是健康的,其他节点是不健康的。
1.1 上游配置
nodes:
- host: postman-echo.com
port: 80
weight: 1
- host: postman-echo1.com
port: 80
weight: 1
- host: postman-echo2.com
port: 80
weight: 1
- host: postman-echo3.com
port: 80
weight: 1
- host: postman-echo4.com
port: 80
weight: 1
- host: postman-echo5.com
port: 80
weight: 1
retries: 3
timeout:
connect: 6
send: 6
read: 6
type: roundrobin
scheme: http
pass_host: pass
name: postman
desc: postman描述
keepalive_pool:
idle_timeout: 60
requests: 1000
size: 320
retry_timeout: 6
1.2 路由配置如下
uris:
- /postman/*
- /postmanget/*
name: route_demo
desc: route_demo描述
priority: 1
methods:
- GET
plugins:
proxy-rewrite:
regex_uri:
- ^/postman/(.*)
- /$1
upstream_id: '506489652354484505'
labels:
API_VERSION: v1
route: rpute_demo
status: 1
1.3 测试结果
成功获取到数据,但是响应时间比较长,相对于前面1s的响应时间,这里用了1.70min。
1.4 日志查看
查看/usr/local/apisix/logs/error.log
文件,可以看到如下报错。
查看/usr/local/apisix/logs/access.log
文件,可以看到成功的一条记录。
1.5 结果分析
当有其他节点不健康时,响应速度会变慢。当所有节点不健康时,无法获取响应数据。
总结
本文从多个方面介绍了在 API 网关中进行各种配置操作的方法。无论是修改端口还是添加插件或设置消费者等,都能够帮助用户更好地管理和控制其API网关环境。通过理解并熟悉这些操作步骤,读者可以根据自身需求来优化和定制他们所使用的API网关系统,并提供更高效可靠且安全性强大的服务。
希望本教程对您有所帮助!如有任何疑问或问题,请随时在评论区留言。感谢阅读!