跳到主要内容
版本:2.13.2304

名词解释

集群

集群 ID

集群的唯一标识,不可修改。

集群状态

正常:集群可正常连接对应的 etcd 资源。

异常:集群无法连接对应的 etcd 资源,导致网关数据面无法运行。

工作分区

主机名

对工作分区内所有路由/API 的格式要求。不符合主机名格式的路由/API 无法添加。

信息

举例:工作分区中主机名设置为*.wk,则该工作分区内所有路由/API 的主机名,可以是a.wk,a.b.wk等,但不可以是a.wk.com

etcd 资源

节点地址

etcd 集群需要至少一个节点,如需考虑 etcd 高可用,则需要至少三个节点。同一个 etcd 集群下所有节点中储存的配置数据是一致且实时同步的。节点地址包括节点的 ip 地址和端口。

状态

运行中:该 etcd 集群可以正常连接。

已停止:该 etcd 集群无法连接(没有足够的健康节点)。

身份认证

API7 网关需要对 etcd 的完全访问权限才可正常运行。更多背景知识请参考etcd 身份认证文档.

如果在 etcd 集群中开启了身份认证,则需要在 API7 网关侧录入可供使用的 root 用户名称及密码。

双向认证

考虑 etcd 安全性,可以为每个 etcd 用户添加证书开启双向认证。更多背景知识请参考etcd 安全模式文档.

如果在 etcd 集群中启用了证书,则需要在 API7 网关侧录入证书、秘钥、证书颁发机构信息。

上游

上游类型

上游使用的负载均衡算法的类型。

负载均衡算法

目前支持以下算法:

  • roundrobin - 带权轮询。
  • chash - 带权一致性哈希。
  • ewma - 指数加权移动平均法,选择延迟最小的节点。参考 EWMA chart
  • least_conn - 最小连接数。选择 (active_conn + 1) / weight 最小的节点。此处的 active connection 概念跟 NGINX 的相同,它是当前正在被请求使用的连接。

目标节点

上游的服务节点,网关转发流量的实际去处。必须是固定不变的静态节点,可以是 ip 地址或者域名。

警告

如果所有目标节点都为空,则转发到此上游的路由/ API 会返回502状态码。

权重

用于负载均衡算法的节点权重,影响节点的选择。

Host 请求头

请求转发到上游时,可以选择直接透传,与客户端保持一致的主机名,或使用目标节点列表中的主机名或 IP 替换原有请求中的 Host.

重试次数

当请求转发到上游时,先按照所选负载均衡算法,为所有的目标节点排序。优先将请求转发到排序第一的目标节点,如果失败,将请求转发到下一个顺位的目标节点,以此类推。

  • 如果重试次数留空不填,将默认启用重试机制且次数为{可用的目标节点数量-1},即一个请求将在所有目标节点尝试处理,所有目标节点均处理失败请求才算失败。
  • 如果重试次数设置为 0,表示不启用重试机制,只要首个目标节点处理失败,即返回请求失败。
  • 如果重试次数大于目标节点数量,在最后一个目标节点请求仍失败后,将回头重试排序第一的目标节点,并继续循环,直至重试次数耗尽。
  • 如果重试次数小于目标节点数量,重试次数耗尽时,即使仍有排序靠后的目标节点未尝试过,仍然返回请求失败。

协议

跟上游通信时使用的 scheme。对于 7 层代理,可选值为 [http, https, grpc, grpcs]。默认值为 http。

连接超时

建立从请求到上游服务器的连接的超时时间。

发送超时

发送数据到上游服务器的超时时间。

接收超时

从上游服务器接收数据的超时时间。

健康检查-主动检查

主动健康检查主要是指通过预设的探针类型,主动探测上游节点的存活性,无论上游是否收到了请求。目前支持 HTTP、HTTPS、TCP 三种探针类型。

当发向健康节点 A 的 N 个连续探针都失败时(取决于如何配置),则该节点将被标记为不健康,不健康的节点将会被负载均衡器忽略,无法收到请求;若某个不健康的节点,连续 M 个探针都成功,则该节点将被重新标记为健康,进而可以被代理。

健康检查-主动检查-类型

执行主动健康检查的探针类型,目前支持 HTTP、HTTPS、TCP 三种。

健康检查-主动检查-超时时间

主动健康检查的套接字的超时时间。

健康检查-主动检查-并行数量

在主动健康检查中同时检查的目标节点数量。

健康检查-主动检查-主机名

进行主动健康检查时使用的 HTTP 请求主机名。若使用 TCP 无需填写。

健康检查-主动检查-端口

主动检查的 HTTP 请求主机端口。

健康检查-主动检查-请求路径

向目标节点发出 HTTP 请求时应使用的路径。

健康检查-主动检查-请求头

主动检查使用 HTTP 或 HTTPS 类型检查时,设置额外的请求头信息。

健康检查-主动检查-健康状态-间隔时间

对健康的上游服务目标节点进行主动健康检查的间隔时间(以秒为单位)。数值为 0 表示对健康节点不进行主动健康检查。

健康检查-主动检查-健康状态-成功次数

主动健康检查的 HTTP 成功次数,若达到此值,表示上游服务目标节点是健康的。

健康检查-主动检查-健康状态-状态码

HTTP 状态码列表,当探针在主动健康检查中返回时,视为健康。

健康检查-主动检查-不健康状态-超时时间

活动探针中认为目标不健康的超时次数。

健康检查-主动检查-不健康状态-间隔时间

对不健康目标的主动健康检查之间的间隔(以秒为单位)。

健康检查-主动检查-不健康状态-状态码

HTTP 状态码列表,当探针在主动健康检查中返回时,视为不健康。

主健康检查-主动检查-不健康状态-HTTP 失败次数

主动健康检查的 HTTP 失败次数,默认值为 0。若达到此值,表示上游服务目标节点是不健康的。

健康检查-主动检查-不健康状态-TCP 失败次数

主动探测中 TCP 失败次数超过该值时,认为目标不健康。

健康检查-被动检查

被动健康检查是指,通过判断从 API7 网关转发到上游节点的请求响应状态,来判断对应的上游节点是否健康,如果上游一直没有请求,则不会执行被动健康检查。 相对于主动健康检查,被动健康检查的方式无需发起额外的探针,但是也无法提前感知节点状态,可能会有一定量的失败请求。

若发向健康节点 A 的 N 个连续请求都被判定为失败(取决于如何配置),则该节点将被标记为不健康。

由于不健康的节点无法收到请求,仅使用被动健康检查策略无法重新将节点标记为健康,因此必须同时开启主动健康检查策略。

健康检查-被动检查-类型

执行被动健康检查的探针类型,目前支持 HTTP、HTTPS、TCP 三种,应当与上游的协议类型保持一致。

健康检查-被动检查-健康状态-状态码

HTTP 状态码列表,当探针在被动健康检查中返回时,视为健康。

健康检查-被动检查-健康状态-成功次数

被动健康检查的 HTTP 成功次数,若达到此值,表示上游服务目标节点是健康的。

健康检查-被动检查-不健康状态-超时次数

活动探针中认为目标不健康的超时次数。

健康检查-被动检查-不健康状态-TCP 失败次数

被动探测中 TCP 失败次数超过该值时,认为目标不健康。

健康检查-被动检查-不健康状态-HTTP 失败次数

被动健康检查的 HTTP 失败次数,默认值为 0。若达到此值,表示上游服务目标节点是不健康的。

健康检查-被动检查-不健康状态-状态码

HTTP 状态码列表,当探针在被动健康检查中返回时,视为不健康。

开发者门户

API

对应 API7 网关上的路由/API。

目录

目录一般用于 API 分类,如将属于同一模块或功能相关的 API 放在同一目录下,开发者可以基于目录快速查找 API。每个 API 只能属于一个目录。

信息

当前仅支持 default 目录,后续将支持新增和管理自定义目录。

关联集群/关联路由

发布到开发者门户的 API 必须和 API7 网关中已有的路由相关关联。路由所在的集群即为此 API 所关联的集群。

开发者门户中的 API 与其关联路由是实时联动的,如果在 API7 网关中修改了该路由,或者更换该 API 所关联的路由,则会立刻影响对应 API 的行为和用法。因此当 API 关联的路由发生调整时,请及时修改对应 API 文档并通知订阅的开发者。

认证方式

API 的关联路由上如果开启了认证类插件,则需要开发者需要按照对应的方式认证才可调用此 API。

信息

当前仅支持 key-auth 认证方式,后续将支持更多。

开发者邮箱

开发者账户的唯一标识,邮箱不可重复使用。

信息

开发者账户创建时的默认密码即为邮箱,后续支持修改及重置密码。

开发者门户地址

开发者门户地址指的是访问开发者门户展示端(供开发者使用的站点)的 URL,比如 https://mydevportal.com。此站点需要自行部署,且必须是唯一的。