跳至主要內容

Tyk：从 Gateway 与 Redis 到 API 管理控制面

高谷深陵大约 22 分钟约 6627 字

一个团队把 API Key、限流和访问分析一起交给网关。业务请求起初都能通过，几天后 Dashboard 的图表停止更新，值班人员检查 /hello 仍是 HTTP 200，于是判断网关健康；与此同时，一次 Policy 调整让原本只能访问订单查询的消费者获得了更多路径权限。流量面、运行状态、控制面和分析链混在一起后，“健康”这个词已经失去诊断价值。

Tyk 不是单个代理进程的别名。最小开源形态由 Gateway 与 Redis 组成；引入 Dashboard、Pump 和 MongoDB 或 PostgreSQL 后，配置管理、运行态、分析队列与持久数据分别落在不同组件。学会 Tyk 的关键，不是记住多少配置字段，而是能沿一次请求和一次配置变更追踪状态在哪里保存、谁有权修改、故障会传播到哪一层。

Tyk Gateway Redis Dashboard Pump MongoDB PostgreSQL 控制面与数据流知识海报
Tyk 控制面、运行态与分析数据链Gateway 执行 Definition 与 Policy，Redis 承载会话和计数，Pump 把临时分析数据搬运到持久存储；每条链路有独立健康证据。高清原图

先拆开五类组件和三种状态

Gateway 接收流量，加载 API Definition 与 Policy，执行认证、授权、限流、quota、变换和 analytics 采集。Redis 不是可选缓存，而是所有 Tyk 安装的运行依赖，保存 key/session、计数、临时 analytics 和节点协调等状态。

Dashboard 是许可化的管理 API 与 UI，负责 API、Policy、组织、用户及分析展示；它还需要 MongoDB 或 PostgreSQL 一类持久主存储。Pump 不代理业务请求，它从 Redis 消费 Gateway 产生的 analytics，再写入一个或多个持久 sink。于是至少有三类状态：配置真相、请求运行态、分析数据。把它们都叫“网关数据库”，会直接导致备份、健康检查和故障恢复设计错误。

开源 file mode 把 Definition 放在 Gateway 可读的 apps 目录；Dashboard 模式把定义放进持久主存储并由管理面发布。二者不能同时被当成双写真相源。Cloud、Self-Managed 与 MDCB 的控制面位置、数据驻留、同步和许可不同，也不能从本地 Gateway + Redis 的拓扑直接类推。

用 Gateway 与 Redis 建立最小隔离环境

第一次学习先使用开源 Gateway + Redis，把管理面和分析持久化暂时留在拓扑之外。选择目标 Gateway 发行线后，分别核对 Gateway、Redis/Valkey 和镜像架构兼容矩阵，记录每个镜像 digest；不要从一个 stack tag 推导所有组件版本。

# compose.yaml
services:
  redis:
    image: redis:${REDIS_TAG:?set REDIS_TAG}
    command: ["redis-server", "--appendonly", "no"]
    networks: [tyk_lab]

  orders:
    image: hashicorp/http-echo:1.0
    command: ["-listen=:8080", "-text={\"service\":\"orders\",\"ok\":true}"]
    networks: [tyk_lab]

  profile:
    image: hashicorp/http-echo:1.0
    command: ["-listen=:8080", "-text={\"service\":\"profile\",\"ok\":true}"]
    networks: [tyk_lab]

  gateway:
    image: tykio/tyk-gateway:${TYK_TAG:?set TYK_TAG}
    ports: ["127.0.0.1:8080:8080"]
    environment:
      TYK_GW_SECRET: ${TYK_SECRET:?set an isolated secret}
    volumes:
      - ./tyk.conf:/opt/tyk-gateway/tyk.conf:ro
      - ./apps:/opt/tyk-gateway/apps:ro
    depends_on: [redis, orders, profile]
    networks: [tyk_lab]

networks:
  tyk_lab: {}
{
  "listen_port": 8080,
  "template_path": "/opt/tyk-gateway/templates",
  "use_db_app_configs": false,
  "app_path": "/opt/tyk-gateway/apps",
  "storage": {
    "type": "redis",
    "host": "redis",
    "port": 6379
  },
  "enable_analytics": false,
  "health_check": { "enable_health_checks": true }
}

Compose 通过 TYK_GW_SECRET 覆盖 Gateway 的 shared secret；其他配置项的环境变量映射也要以目标发行线文档与镜像行为核对。shared secret 不应提交到仓库，也不要直接写进会被复制的 tyk.conf。本实验把 analytics 关闭，是为了先证明代理与 Redis 状态链；后面再单独增加 Pump，避免一次启动多个组件却无法判断哪一层失败。

为两个上游分别建立 Tyk OAS 定义。REST 新接入优先从 Tyk OAS 开始，标准 OpenAPI 描述与 x-tyk-api-gateway 扩展共同组成完整网关行为；纯 OpenAPI 文件不足以表达全部认证和中间件配置。GraphQL、XML/SOAP、TCP 及旧发行线仍可能需要 Classic Definition，应按目标版本和协议选择，不能机械转换。

将下面的完整对象保存为 apps/orders.json：

{
  "openapi": "3.0.3",
  "info": {
    "title": "Orders Lab",
    "version": "1.0.0"
  },
  "paths": {
    "/": {
      "get": {
        "operationId": "getOrders",
        "responses": {
          "200": { "description": "synthetic response" }
        }
      }
    }
  },
  "x-tyk-api-gateway": {
    "info": {
      "id": "orders-lab",
      "name": "Orders Lab",
      "state": { "active": true }
    },
    "upstream": { "url": "http://orders:8080" },
    "server": {
      "listenPath": {
        "value": "/orders/",
        "strip": true
      }
    }
  }
}

不要靠手工复制再凭记忆改第二份文件。下面用结构化工具从已校验的 orders 定义生成 profile 定义，并立即检查 JSON 与四个决定路由身份的字段；缺少唯一 info.id 会让发布、Policy 引用和排障证据混在一起，错误的 upstream.url 或 listenPath.value 则会把请求送错服务。

jq '
  .info.title = "Profile Lab"
  | .info.version = "1.0.0"
  | .paths."/".get.operationId = "getProfile"
  | ."x-tyk-api-gateway".info.id = "profile-lab"
  | ."x-tyk-api-gateway".info.name = "Profile Lab"
  | ."x-tyk-api-gateway".upstream.url = "http://profile:8080"
  | ."x-tyk-api-gateway".server.listenPath.value = "/profile/"
' apps/orders.json > apps/profile.json
jq -e '
  ."x-tyk-api-gateway"
  | .info.id == "profile-lab"
    and .upstream.url == "http://profile:8080"
    and .server.listenPath.value == "/profile/"
    and .server.listenPath.strip == true
' apps/profile.json

REST 新接入优先从 Tyk OAS 开始；GraphQL、XML/SOAP、TCP 及旧发行线仍可能需要 Classic Definition。Tyk OAS 扩展的精确 schema 会随发行线演进，尤其 OpenAPI 3.1 的关键字支持不能靠版本号想当然；导入前应使用目标文档、schema 工具和隔离 Gateway 做反例验证。

docker compose pull
docker image inspect "tykio/tyk-gateway:${TYK_TAG}" --format '{{index .RepoDigests 0}}'
docker compose up -d
docker compose exec gateway tyk version --json
curl -sS http://127.0.0.1:8080/hello | jq .
curl -i http://127.0.0.1:8080/orders/
curl -i http://127.0.0.1:8080/profile/

这些步骤需要在选定制品上实际执行。预期证据是两个路径返回可区分的 service，Gateway 日志显示各自 Definition，/hello 的 JSON status 与 details.redis 表明 Redis 状态正常。只看到 HTTP 200 不足以判定健康；/hello 也不覆盖 Pump、Dashboard 主库或 analytics sink。

Definition 发布不能只看 reload 返回值

Gateway 级配置通常从 tyk.conf 或等价环境变量在启动时加载，API 级行为来自 Definition。file mode 可以通过文件变化与 reload 更新路由；管理 API 也能创建 Definition、Policy、Key/Session 并触发 reload，但它使用高权限 shared secret，缺少供外部租户使用的细粒度授权体系，必须只绑定回环或管理网络。

一条可审计的发布链先离线校验 JSON/OAS，再在隔离 Gateway 加载，直接请求两个上游保存基线，然后调用正确控制面的 reload。每次发布记录 Definition 摘要、Gateway build info、reload 响应、实际已加载 API 列表和路由烟测。hot reload 成功仅说明控制动作被接受，不证明 schema、上游或业务契约正确。

read -rsp 'isolated Tyk secret: ' TYK_SECRET; export TYK_SECRET
curl -sS -H "x-tyk-authorization: $TYK_SECRET" \
  http://127.0.0.1:8080/tyk/apis | jq .
curl -sS -H "x-tyk-authorization: $TYK_SECRET" \
  http://127.0.0.1:8080/tyk/reload/group | jq .
unset TYK_SECRET

不要把真实 header 写进命令历史、CI 输出或文档截图。/tyk/reload/group 会影响组内节点，先在单节点隔离环境确认行为，再进入滚动发布。Dashboard 模式应通过 Dashboard 管理面发布，不要绕过它直接改 file mode 定义，形成无法解释的漂移。

正向实验：从消费者 Key 追到 Redis Session

把 orders 和 profile 都改为需要 Auth Token 时，OpenAPI 描述和 Tyk 扩展必须一起变化：在根级 components.securitySchemes 声明 labToken 的 type: apiKey、in: header、name: Authorization，在根级 security 引用它，再把 x-tyk-api-gateway.server.authentication.enabled 与 securitySchemes.labToken.enabled 都设为 true。前一组字段定义客户端把凭证放在哪里，后一组字段决定 Gateway 是否真正执行认证；只写 OpenAPI security 可能仍把认证责任留给上游，只开 Tyk 扩展又会失去明确的凭证位置契约。两个 API 都受保护、测试 Policy 只授予 orders，才能用 profile 请求证明 ACL 拒绝，而不是误测一个公开路由。可用下面的结构化变更生成受保护定义，避免把真实 token 写进文件：

for api in orders profile; do
  jq '
    .components.securitySchemes.labToken = {
      "type": "apiKey", "in": "header", "name": "Authorization"
    }
    | .security = [{"labToken": []}]
    | ."x-tyk-api-gateway".server.authentication = {
        "enabled": true,
        "stripAuthorizationData": true,
        "securitySchemes": {"labToken": {"enabled": true}}
      }
  ' "apps/$api.json" > "apps/$api.protected.json"
  jq -e '
    .components.securitySchemes.labToken.type == "apiKey"
    and ."x-tyk-api-gateway".server.authentication.enabled == true
    and ."x-tyk-api-gateway".server.authentication.securitySchemes.labToken.enabled == true
  ' "apps/$api.protected.json"
  mv "apps/$api.protected.json" "apps/$api.json"
done

stripAuthorizationData: true 表示 Gateway 验证后不把消费者 token 转发给 orders 上游，减少凭证扩散；如果上游确实需要独立身份，应由网关换成另一枚最小权限凭证，而不是把消费者 key 原样透传。随后通过受控管理 API 创建一个只允许 orders 的测试 key。新设计使用 Session 的 apply_policies 引用 Policy；单值 apply_policy_id 是兼容字段，不应作为新基线。请求进入后，Gateway 从 Redis 读取 Session，克隆内存副本，加载并动态叠加 Policy，再执行 ACL、rate limit 和 quota；quota 消耗写回 Session，rate-limit counter 使用独立 Redis key。

实验要保存四组证据：无 key 被拒绝；正确 key 访问 orders 成功；同一 key 访问 profile 被拒绝；Redis 中与测试 key 相关的 Session/计数状态发生可解释变化。示例 key 必须是一次性合成值，并在结束时立即撤销。

curl -i http://127.0.0.1:8080/orders/
curl -i -H "Authorization: $TEST_KEY" http://127.0.0.1:8080/orders/
curl -i -H "Authorization: $TEST_KEY" http://127.0.0.1:8080/profile/

预期不变量是“身份与授权结果可区分”，不是写死某个状态码：具体认证方案和 Definition 会决定 header 与响应。记录 Gateway 状态、命中 API、消费者/key 的不可逆摘要、Policy ID、配置版本和上游实际调用次数；被拒绝的请求不应到达上游。

反向实验：Policy 叠加可能扩权

很多人把多 Policy 理解为“后者覆盖前者”，Tyk 的动态合并并非如此。ACL 取允许集合并集，rate limit 取最高有效请求率，quota 与 complexity 取较大值；quota_max 和 quota_renewal_rate 甚至可能来自不同 Policy，合并结果不一定等于任一原始对象。某些 partitioned 与 per-API 组合会被拒绝，且行为需要按目标版本验证。

构造 Policy A 仅允许 orders、Policy B 仅允许 profile，再把二者同时应用到一枚测试 key。先预测合并后的 ACL、rate 和 quota，然后分别请求两个 API，读取 Session 结果并对照日志。这个反例的预期证据是权限集合扩大，而不是“最后一个 Policy 生效”。若目标版本拒绝某种组合，应保存错误日志、管理 API 响应和旧 Session 是否仍有效。

Policy 变更可能立即影响大量关联 key。生产发布前先查询受影响消费者和 API，生成合并后权限差异，使用小批合成 key 灰度，并保存旧 Policy 与 Session 引用快照。回滚不是只把 JSON 改回去，还要确认缓存失效、关联 key 重新计算且被撤销路径不再到达上游。

Redis 故障为什么不是一个简单的缓存 miss

Redis 同时影响 key/session、quota、rate limit、临时 analytics 和部分节点协调。停止 Redis 后，公开 API 对不同认证和策略配置可能表现为拒绝、错误或已有内存状态的短时差异；准确 fail-open/fail-close 行为必须锁定版本、配置和请求类型实测，不能用一句“Redis 挂了网关仍可用”概括。

隔离实验按顺序执行：保存健康基线；停止 Redis；分别请求无认证路由、受 key 保护路由和接近 quota 的路由；解析 /hello JSON；恢复 Redis；观察 Session、计数和请求结果是否恢复。每一步记录客户端状态、上游调用数、Gateway 日志和 Redis 连接错误。不要在共享或生产 Redis 上制造故障。

/hello 可能仍返回 HTTP 200，因此探针要解析业务状态字段；健康接口本身也有成本，不应成为每个业务请求前的高频前置调用。真正的就绪判据应按部署形态组合 Gateway 进程、Redis 可用性、Definition 已加载和一条无副作用烟测。

响应缓存必须同时验证隔离、失效和容量

Tyk 的响应缓存也落在 Redis，而不是 Gateway 进程内存。默认缓存键会综合 API ID、请求方法、路径、请求体摘要，以及认证头或客户端 IP；Classic Definition 的 cache_by_headers 还可以把指定 header 纳入键，Tyk OAS 则应以目标发行线的 Vendor Extension schema 选择等价能力。这个设计能降低不同消费者互相读到结果的概率，却不等于业务隔离天然正确：如果上游还根据租户 header、区域、语言或实验分组返回不同内容，而这些维度没有进入缓存键，第一次响应就可能被错误复用。

对只读 orders 查询，可以先在 API Definition 中启用一个短 TTL，并限制只缓存成功响应：

{
  "x-tyk-api-gateway": {
    "middleware": {
      "global": {
        "cache": {
          "enabled": true,
          "timeout": 15,
          "cacheAllSafeRequests": false
        }
      },
      "operations": {
        "getOrders": {
          "cache": {
            "enabled": true,
            "timeout": 15,
            "cacheResponseCodes": [200]
          }
        }
      }
    }
  }
}

全局 enabled 打开该 API 的缓存能力，timeout 给出默认最大有效期；cacheAllSafeRequests: false 保留逐 operation 选择，避免一个 API 内所有 GET、HEAD、OPTIONS 被一并缓存；operations.getOrders 必须与 OpenAPI 的 operationId 精确对应；cacheResponseCodes 防止临时错误被固化。若启用全局 safe-request 缓存，它会覆盖逐 endpoint 的选择；若业务错误地让 safe 方法产生副作用，也不能启用。

正向实验使用两个合成租户和一个能返回递增版本号的上游。租户 A 连续请求两次，第二次应出现 X-Tyk-Cached-Response: 1，且上游调用数不增加；租户 B 使用同一路径请求，必须得到自己的内容并触发独立上游调用。随后等待 TTL 或通过受控管理面删除该 API 的缓存，再次请求应得到新版本。Dashboard 管理的集群优先调用 Dashboard 的 API 级失效入口，使消息分发到全部 Gateway；直接调用单节点 Gateway 控制 API，不能证明所有副本都已清除。

反向实验改用没有认证、只靠可伪造 X-Tenant-Id 区分租户的测试路由，再用 A、B 交替请求相同资源。若该 header 没有被可靠纳入目标版本的缓存键，B 可能收到 A 的标识；出现后立即停止实验并清理缓存。证据至少保留响应 header、脱敏 body 摘要、上游调用次数、API ID、配置摘要和 Gateway 节点。正确修复是先建立可信消费者身份，再按已验证 schema 把真正影响响应的维度纳入缓存键，或直接禁用缓存；余额、权限、库存和撤销状态通常不应只靠短 TTL 控制风险。

高流量 API 可以通过 enable_separate_cache_store 与 cache_storage 把响应缓存和 Session/限流状态拆到不同 Redis，但这不是逻辑租户隔离。两套 Redis 都要分别做 TLS、ACL、连接池、容量、延迟、备份或可重建性判断。缓存容量模型至少包含键基数、平均与高分位响应大小、TTL、并发 miss、失效广播和 Redis 淘汰策略；缓存 Redis 被淘汰只应增加上游负载，不能误删认证 Session，更不能让 allkeys-* 策略在共享实例上把安全状态当普通缓存逐出。

接入 Pump 后，健康证据要再分一层

开启 analytics 后，Gateway 先把记录写进 Redis 临时队列，Pump 周期性消费并 flush 到持久 sink。Dashboard 分析通常同时需要 per-request/raw 与 aggregate 数据。Mongo raw pump 默认按请求写文档，aggregate pump 按 API、path、status、key 等维度汇总；SQL sink 也有各自 raw、aggregate 和 uptime 形态。目标 schema、索引与迁移由 Pump/Dashboard 组合决定。

正向实验只发送合成 token、路径和 body：记录 Redis 队列趋势、Pump 成功消费、目标表或集合新鲜度和 Dashboard 可见性。然后停止 Pump，保持 Gateway 流量，观察队列积压；恢复 Pump 后检查积压是否下降以及是否出现重复或丢失。再分别停止持久库，证明 Gateway 请求热路径与分析写入故障可以分离。

enable_detailed_recording 会把入站请求和出站响应的 HTTP wire data 写进 analytics，显著放大 Redis、Pump、数据库和 Dashboard 压力，也可能收集 API key、header、body、IP 与客户数据。默认保持关闭；只有在脱敏合成流量或短时受控排障窗口中启用，并在结束后删除数据库记录、导出、备份和日志副本。

多个 Pump 实例写相同 backend 组合是官方支持的扩容形态；使用不同 backend 组合的多个实例不受支持。不要凭消费者组经验自行设计，扩容前要按目标 Pump 文档验证 backend 配置、重复语义、lag 和恢复行为。

从开源模式走向 Self-Managed 或多数据中心

Self-Managed 通常增加 Dashboard、Pump、Redis 与 MongoDB/PostgreSQL，控制面拥有自己的用户、组织、审计和许可边界。安装时必须分别锁定 Gateway、Dashboard、Pump、chart、Redis/Valkey 和主库的实际版本与 digest；Gateway 的 Git tag 不等于 Dashboard 的发行版本，单一“最新版”也不能替代兼容矩阵。

Cloud 把控制面交给 Tyk 托管，Hybrid/Data Plane Gateway 可以运行在客户环境；区域、数据驻留、Pump、升级节奏和可配置项以实际服务与合同为准。MDCB 用于控制面与多数据面分离，各侧有自己的 Redis、持久状态和断连策略。单数据中心的共享 Redis 拓扑不能直接复制成多数据中心方案，否则网络分区会把认证、计数和配置同步一起拖入不可控延迟。

设计多数据中心时逐项回答：Definition 与 Policy 的权威源在哪里；控制面断连后数据面能服务多久；key/session 在哪里创建与撤销；全局 quota 需要多强一致；analytics 在哪一侧汇聚；恢复同步时如何处理旧配置与计数。节点、Data Plane、Gateway、支持和许可口径要从实际 license、Dashboard 显示和订单确认，正文里的固定数字无法替代采购与容量核算。

单区域 HA 的起点是多个配置一致的 Gateway 置于负载均衡器后，并让它们访问同一套受支持的 Redis 高可用拓扑和持久主库。Gateway 多副本只能消除代理进程单点，不能消除 Redis、Dashboard 主库、入口负载均衡器和证书终止层的单点。Redis Sentinel、Redis Cluster 或托管服务的选择还会改变客户端配置、故障转移时间、写入确认和运维责任；storage.addrs、master_name、TLS、用户名、密码及连接超时必须与所选拓扑一致，不能只把单机 host 改成多个地址。

故障演练按故障域逐个执行：摘除一个 Gateway，确认连接排空且另一副本继续服务；切换 Redis 主节点，观察认证、quota 和缓存的错误窗口；停止一个 Pump，观察 analytics lag 而不影响请求热路径；隔离 Dashboard 或主库，证明已有数据面与新配置发布的边界。每轮都记录负载均衡节点、Gateway build、Redis role/epoch、Definition 摘要、成功率、延迟、重复或丢失证据，并恢复后验证旧节点不会带着过期配置重新入池。

项目仓库怎样承载 Tyk 变更

把经过批准的 OpenAPI 契约作为输入，Tyk 扩展、Policy 和环境值分别管理；不要让 Dashboard 导出和仓库文件互相覆盖。一个可维护的目录可以是：

gateway/
  apis/
    orders.oas.yaml
    profile.oas.yaml
  policies/
    orders-reader.json
  environments/
    dev.values.example
  tests/
    routes.sh
    authz.sh
    policy-merge.sh
    analytics.sh
  evidence/
    component-digests.txt
    definition-sha256.txt

流水线先做 OAS/JSON 校验和敏感信息扫描，再启动隔离 Gateway，执行两个可区分上游、错误路径、错误凭证和策略冲突实验。通过后由唯一控制面发布，读取实际已加载定义并做数据面烟测。配置版本应进入日志或部署标签，使一次请求能关联 Definition 摘要、Policy ID 和 Gateway build，而不是只能关联一次模糊的“reload 成功”。

排障时不要让组件名代替因果链

先判断故障属于请求热路径、控制面发布还是分析链，再向下取证：

现象第一证据下一层
路由 404 或命中错误上游已加载 Definition、listen path、API ID、配置摘要reload 日志、旧节点、副本差异
正确 key 仍被拒绝Session、apply_policies、Policy 合并结果Redis 连接、缓存失效、时钟与计数
quota/限流异常Session quota 与独立 counter 趋势Policy 合并、窗口、节点与 Redis 延迟
/hello 正常但图表停更Pump lag/error、Redis 队列趋势sink 新鲜度、主库、Dashboard 查询
Dashboard 可改配置但流量未变化发布目标、Gateway group、实际加载版本控制面到数据面同步与断连状态

每次请求至少保留 request ID、网关状态码、上游状态码、命中 API/路由、消费者摘要、Policy、配置版本、Gateway 节点和上游耗时。管理面日志还要有操作者、对象、前后摘要和发布结果。敏感 header 与 body 默认不落日志，必要排障使用短时采样和脱敏合成请求。

选型从组织能力而不是功能勾选开始

只需要高性能代理、少量静态路由且不愿承担 Redis 运行依赖时，Tyk 未必是最轻的选择。需要消费者 Key、Policy、quota、集中分析和逐步走向 API 管理时，Gateway + Redis 提供了清晰起点；需要组织、管理 UI、门户、多数据中心控制面和商业支持时，再评估 Self-Managed、Cloud 与 MDCB。

代价同样明确：Redis 进入请求关键依赖；Policy 动态合并提高灵活性也提高扩权风险；analytics 把一次请求放大为队列、Pump、持久写入、索引和查询成本；多组件升级要求兼容矩阵与备份恢复。容量评估同时测入口 RPS、Redis 操作和延迟、Session/计数键规模、analytics 每请求字节、Pump lag、sink 写放大、索引增长与 Dashboard 查询负载。

Gateway 仓库根目录及除 ee 外代码与 ee 目录采用不同许可结构，Pump 也有自己的开源许可。技术选型只能记录目标制品和仓库的实际许可构成，不能替代法律意见，也不能把整个 Tyk Stack 简化为“全部开源免费”。报价、试用、API/节点/环境数量、SLA、区域和支持周期都按当期合同确认，不写死进架构基线。

权限、凭证、数据和成本治理

Gateway shared secret 相当于高权限控制面凭证，只进入受控 secret manager，并限制到管理网络；业务消费者 key 与上游身份分开轮换，不能让一个 key 同时承担管理和调用。Dashboard 用户按组织和职责最小授权，服务账号与人工账号分离，离职和项目退订触发 key、Session、Policy 引用及门户订阅的回收。

凭证轮换采用双凭证窗口：创建新凭证、灰度消费者、观察旧凭证命中归零、撤销旧凭证，再清理 Redis Session 和下游缓存。fail-open/fail-close 必须按身份类别和业务风险定义：公共只读接口与支付写接口不应共享同一故障策略。撤销实验要证明旧 key 不再到达上游，而不是只证明管理 API 返回删除成功。

analytics 的数据分类要贯穿 Redis、Pump、数据库、导出 sink、Dashboard、备份和日志。为 raw 与 aggregate 数据分别定义用途、保留、访问、删除和 owner；详细记录默认关闭。成本看板至少拆 Gateway 资源、Redis 容量与高可用、主库与索引、Pump 计算、日志/Trace、网络与商业许可，避免把“每次 API 调用”当唯一成本单位。

升级、回滚和退出

升级前分别备份 Definition、Policy、组织与用户配置、Redis 中必须恢复的状态、Dashboard 主库和 analytics sink；哪些状态可以重建、哪些必须恢复要提前演练。先在隔离环境用目标组件组合验证 OAS/Classic 导入、Policy 合并、Redis 兼容、Pump schema 和管理 API，再让一小组 Gateway 双跑相同合成流量，比较路由、状态码、header、body、延迟和计数。

回滚窗口内保留旧镜像、旧 Definition/Policy 摘要和可兼容的数据备份。若数据库迁移不可逆，就不能把“容器换回旧 tag”称为回滚；要有经过验证的前向修复或恢复到隔离备份的方案。控制面和数据面分离时，还要证明旧数据面不会继续接受已撤销配置。

退出 Tyk 时先导出标准 OpenAPI 契约和消费者/Policy 映射，再在候选网关建立等价路由与认证，双跑合成与镜像流量，最后切换入口。Tyk 特有的多 Policy 合并、Session quota、analytics 维度和 Dashboard 组织模型需要显式转换，不能假定另一产品有同名字段就有相同语义。

精确清理实验环境

先撤销测试 key、删除测试 Policy 与 API Definition，触发受控 reload，并证明旧 key 和旧路径不再命中上游。若启用了 analytics，再停止流量、等待或记录队列状态，删除合成 raw/aggregate 数据、导出与备份；最后停止 Gateway、Pump、Redis 和持久库。

unset TYK_SECRET TEST_KEY
docker compose down --remove-orphans
docker compose ps -a
docker network ls --filter name=tyk_lab

只有确认 volume 全部属于本实验、没有共享主库或待保留证据时，才执行带 volume 的删除。清理完成要复查监听端口、容器、网络、volume、临时配置、shell history 和 CI artifact。这样，一次 Tyk 学习或迁移才真正闭环：不仅能把请求送到上游，还能解释 Definition 怎样发布、Policy 怎样改变 Session、Redis 故障如何传播、analytics 为什么可能独立停摆，以及团队怎样撤销凭证、恢复版本并最终退出平台。

跳到正文