Table of Contents

第一个编排链

本页在五分钟跑起来的基础上，给转发路由加一个处理步骤（限流）， 再升级为共享编排链——体验 KernLab.Traffic 的核心模型：请求不是被中间件链依次穿过， 而是执行一条编排的指令流。

两种编排形态

路由的处理步骤（steps）有两种来源，编译后等价：

形态 写法 适用
内联步骤 路由的 steps[] 直接写步骤 一步专用、无需复用
绑链 steps[] 里放一个 orch 步骤引用共享编排实体 多路由共享同一处理流、画布拖拽编辑

1. 内联步骤：给路由加限流

在 demo-api 路由上加一个 rate-limit 步骤（令牌桶：填充速率 1/秒，桶容量 2）：

{
  "cluster": "demo-upstream",
  "pathPrefix": "/api/",
  "order": 10,
  "steps": [
    { "code": "rate-limit", "settings": { "requestsPerSecond": 1, "burst": 2 } }
  ]
}

写入并发布（命令见上一页），然后连续快速请求：

req1=200 req2=200 req3=429 req4=429

桶容量 2：前两发通过，第三发起令牌耗尽返回 429——限流步骤真实生效。 步骤在编译期接受校验：settings 不符合该步骤的 schema、未知 code 都会导致 发布干跑拒绝（422），旧世代继续服务。

2. 升级为共享编排链

把同一段逻辑抽成编排实体（orch），供任意多条路由绑定：

curl -s -X POST http://127.0.0.1:7901/api/v1/default/config/set/orch/demo-chain \
  -H "Content-Type: application/json" \
  -d '{
    "nodes": [
      { "id": "n1", "step": "rate-limit",
        "settings": { "requestsPerSecond": 1, "burst": 1 },
        "failureStrategy": "FailFast",
        "canvas": { "x": 120, "y": 80 } }
    ],
    "links": []
  }'

图文档字段：

字段 必填 含义
nodes[] ✅ 处理节点：id 唯一标识、step 步骤码、settings 步骤参数、canvas 画布坐标（编辑器用）
links[] ✅ 节点间顺序边（from/to）；无边的单节点链给空数组
groups[] — 并行组（组内并发、组间按策略汇合）

再把路由的 steps 换成对链的引用：

{
  "cluster": "demo-upstream",
  "pathPrefix": "/api/",
  "order": 10,
  "steps": [ { "code": "orch", "settings": { "ref": "demo-chain" } } ]
}

发布后效果与内联一致（burst=1 → 第二发起 429）。链可嵌套引用（链里再引链，深度 ≤4）； 控制台 UI 的编排设计器就是这份图文档的可视化编辑器——拖拽保存与 CLI 写入的是同一实体。

3. 终端动作与步骤的关系

一条路由的终点必须是三选一（同时给两个＝编译拒绝）：

终点 语义
cluster 转发到上游（proxy 是固定终段，自动生效）
redirect 命中即重定向（30x），不执行 steps
directResponse 命中即直接应答，不进管线（steps 不执行）

所以编排链只挂在 cluster 路由上——这也是五分钟里 hello（直应）与 demo-api（代理）两条路由的本质区别。

下一步

Edit this page