跳到主要内容
版本：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。此站点需要自行部署，且必须是唯一的。