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 arraystring 否 使用正则表达式匹配来自客户端的 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 arraystring 是 加入白名单的对象，优先级高于 allowed_by_methods
blacklist arraystring 是 加入黑名单的对象，优先级高于 whitelist
rejected_code integer 否 403 200,... 当请求被拒绝时，返回的 HTTP 状态码
rejected_msg string 否 当请求被拒绝时，返回的错误信息
allowed_by_methods arrayobject 否 一组为消费者设置允许的配置，包括用户名和允许的 HTTP 方法列表
allowed_by_methods.user 否 为消费者设置的用户名
allowed_by_methods.methods arraystring 否 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网关系统，并提供更高效可靠且安全性强大的服务。

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

相关推荐
Raas1003 天前
AI网关部署方案？从部署到上线全流程
java·开发语言·人工智能·gateway·ai网关·企业级ai网关·企业级ai产品
Raas1004 天前
AI网关怎么部署？MAI Gateway部署实操教程
人工智能·开源·gateway·mai gateway·企业级ai产品
Raas1005 天前
MAI Gateway实战部署：AI网关怎么部署？从0到1上手指南
人工智能·gateway·ai网关·企业级ai网关·企业级产品·ai技术交流
4SAPI6 天前
会议智能处理大模型 API 生产选型指南：4SAPI、硅基流动与 OpenRouter 的架构权衡
人工智能·架构·自动化·gateway·php
JJJennie7776 天前
MAI Gateway实战部署：大模型网关部署方案？从0到1上手指南
数据库·人工智能·gateway·ai网关
Raas1007 天前
AI网关用开源够用吗？MAI Gateway入选2026年企业级AI网关推荐清单
人工智能·开源·gateway·ai网关·mai gateway·企业级ai网关·企业级产品
Raas1007 天前
MAI Gateway（魔芋企业级AI网关）选购攻略：AI网关厂商排名？避坑指南与对比
大数据·人工智能·网关·gateway·mai gateway·企业级产品
JJJennie7777 天前
大模型网关部署方案？MAI Gateway从部署到上线全流程
人工智能·gateway·ai网关
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点03历年考研数学一、数学二、数学三真题试卷及答案PDF04几个好用的ip纯净度检测网站05苹果iPA游戏软件资源下载网站06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07如何新建文件夹？ 电脑新建文件夹的4种方法08昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战09Dify：一站式AI应用开发平台全解析与Windows部署指南10Android 屏幕适配系列开篇：核心概念、官方机制与主流方案