API网关-Apisix路由配置教程（数据编辑器方式）

大数据魔法师2024-03-31 19:52

文章目录

  • 前言
  • 一、端口修改
    • [1. apisix 端口修改](#1. apisix 端口修改)
    • [2. dashboard 端口修改](#2. dashboard 端口修改)
    • [3. 登录密码修改](#3. 登录密码修改)
  • 二、常用插件介绍
    • [1. 常用转换插件](#1. 常用转换插件)
      • [1.1 proxy-rewrite插件](#1.1 proxy-rewrite插件)
        • [1.1.1 属性字段](#1.1.1 属性字段)
        • [1.1.2 配置示例](#1.1.2 配置示例)
    • [2. 常用认证插件](#2. 常用认证插件)
      • [2.1 key-auth插件](#2.1 key-auth插件)
        • [2.1.1 消费者端字段](#2.1.1 消费者端字段)
        • [2.1.2 路由端字段](#2.1.2 路由端字段)
        • [2.1.3 配置示例](#2.1.3 配置示例)
      • [2.2 basic-auth插件](#2.2 basic-auth插件)
        • [2.2.1 消费者端字段](#2.2.1 消费者端字段)
        • [2.2.2 路由端字段](#2.2.2 路由端字段)
        • [2.2.3 配置示例](#2.2.3 配置示例)
    • [3. 常用安全插件](#3. 常用安全插件)
      • [3.1 consumer-restriction插件](#3.1 consumer-restriction插件)
        • [3.1.1 属性字段](#3.1.1 属性字段)
        • [3.1.2 配置示例](#3.1.2 配置示例)
  • 三、消费者配置（数据编辑器方式）
    • [1. UI页面对应字段说明](#1. UI页面对应字段说明)
    • [2. 配置示例](#2. 配置示例)
  • 四、上游配置
    • [1. UI页面对应字段说明](#1. UI页面对应字段说明)
    • [2. 配置示例](#2. 配置示例)
    • [3. 健康检查](#3. 健康检查)
      • [3.1 主动健康检查](#3.1 主动健康检查)
      • [3.2 被动健康检查](#3.2 被动健康检查)
  • 五、路由配置
    • [1. UI页面对应字段说明](#1. UI页面对应字段说明)
    • [2. 配置示例（绑定上游方式）](#2. 配置示例（绑定上游方式）)
  • 六、模拟异常情况
    • [1. 模拟节点不健康](#1. 模拟节点不健康)
      • [1.1 上游配置](#1.1 上游配置)
      • [1.2 路由配置如下](#1.2 路由配置如下)
      • [1.3 测试结果](#1.3 测试结果)
      • [1.4 日志查看](#1.4 日志查看)
      • [1.5 结果分析](#1.5 结果分析)
  • 总结

前言

本文介绍了在 API 网关中进行端口修改、常用插件配置、消费者配置、上游配置和路由配置的方法。通过对这些方面的详细说明，读者可以了解如何灵活地调整和定制自己的 API 网关环境，以满足不同场景下的需求。

一、端口修改

1. apisix 端口修改

添加多个代理监听端口，修改/usr/local/apisix/conf/config.yaml配置文件，添加如下配置，添加的配置将覆盖默认配置文件。

xml 复制代码 
 apisix:
   node_listen:
     - 9080
     - 9081
     - 9082

2. dashboard 端口修改

修改/usr/local/apisix/conf/conf.yaml配置文件，修改如下配置。

xml 复制代码 
conf:
  listen:
    port: 9000

3. 登录密码修改

可修改/usr/local/apisix/conf/conf.yaml配置文件中的用户认证配置。

xml 复制代码 
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 配置示例
yml 复制代码 
...
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 配置示例

消费者端：

yml 复制代码 
username: consumer_demo
desc: consumer_demo描述
plugins:
  key-auth:
    _meta:
      disable: false
    key: auth-one
  ...

路由端：

yml 复制代码 
...
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 配置示例

消费者端：

yml 复制代码 
username: consumer_demo
desc: consumer_demo描述
plugins:
  basic-auth:
    _meta:
      disable: false
    password: user
    username: user
  ...

路由端：

yml 复制代码 
...
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 配置示例
yml 复制代码 
...
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插件。

yml 复制代码 
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. 配置示例

yml 复制代码 
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. 配置示例（绑定上游方式）

yml 复制代码 
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 上游配置

yml 复制代码 
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 路由配置如下

yml 复制代码 
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网关系统，并提供更高效可靠且安全性强大的服务。

希望本教程对您有所帮助！如有任何疑问或问题，请随时在评论区留言。感谢阅读！

相关推荐
攸攸太上8 小时前
Spring Gateway学习
java·后端·学习·spring·微服务·gateway
Bulut09072 天前
SpringCloud 2023 Gateway的Predicate配置详解、自定义Route Predicate Factory
spring cloud·gateway·predicate配置详解·自定义路由断言factory·内置路由predicate
wangqiaowq4 天前
Egress Gateway 是一个重要的组件，用于管理从服务网格内部到外部服务的流量
网络·gateway
wangqiaowq5 天前
Ingress Gateway 它负责处理进入集群的 HTTP 和 TCP 流量
tcp/ip·http·gateway
鲨鱼辣椒ぅ6 天前
springboot集成nacos+gateway+feign
spring boot·后端·gateway
fanhaifeng666 天前
SpringCloud Gateway 打印请求响应日志、跨域全局配置
spring·spring cloud·gateway
大灰狼19138 天前
【基于spring-cloud-gateway实现自己的网关过滤器】
spring cloud·gateway
wangqiaowq8 天前
Gateway和VirtualService
gateway
世俗ˊ9 天前
微服务-- Gateway服务网关
java·微服务·gateway
她又在丛中笑10 天前
SpringBoot gateway如何支持跨域？
java·spring boot·gateway
热门推荐
01分享几个惊艳的 Three.js 个人站点02【经验分享】Ubuntu22.04安装微信(linux官方版)032024年高教社杯数学建模国赛C题超详细解题思路分析04组基轨迹建模 GBTM的介绍与实现（Stata 或 R）05安卓系列机型永久去除data分区加密 详细步骤解析06【2024数模国赛赛题思路公开】国赛B题思路丨附可运行代码丨无偿自提07springer 在线投稿编译踩坑08Ubuntu24.04安装中文输入法09【2024高教社杯全国大学生数学建模竞赛】B题 生产过程中的决策问题——解题思路 代码 论文10CTF网络安全大赛简单的web抓包题目：HEADache