中台场景路由编排引擎设计实战

布衣云水客大约 4 分钟

概要

在企业中台建设过程中，一个绕不开的难题是：如何让同一个服务接口在不同场景下，路由到不同的后端实现，并施加不同的鉴权策略？

传统做法是硬编码 if-else 或维护分散的配置文件，但随着业务场景膨胀——区域维度、产品线维度、客户维度交叉组合——这套方式很快就失控了。

我们设计了一套场景路由编排引擎，通过可视化的配置界面 + 规则引擎，实现了服务路由和鉴权的配置化、版本化管理。本文将分享其中的设计思路和关键技术细节。

核心概念

场景路由编排引擎的核心抽象只有三个：

概念	说明	示例
服务	对外暴露的统一 API 入口	`POST /api/order/query`
场景	同一服务在不同条件下的变体	华南区域订单查询、华北区域订单查询
规则	决定请求匹配到哪个场景的条件	`area=1, region=1079`

一次完整请求的生命周期：

路由规则设计

路由规则的核心是字段匹配模型，支持四种匹配方式：

匹配方式	说明	适用场景
等值匹配	`area = "1"`	精确的区域/渠道匹配
包含匹配	`tags contains "vip"`	标签类条件
存在匹配	`vipFlag exists`	判断字段是否存在
表达式匹配	`amount > 10000`	复杂业务规则

每种匹配方式的可视化配置：

{
  "fieldName": "area",
  "matchType": "0",
  "matchValue": "1,2"
}

多个路由字段可以组合形成复合匹配规则，只有全部匹配时才会命中对应场景。

鉴权引擎

鉴权是场景路由的另一大核心。我们设计了多维度的鉴权模型：

{
  "authFlag": "Y",
  "authDimension": ["区域维", "业务维", "产品部"],
  "resultMode": "throw"
}

关键设计决策：

鉴权维度可组合：支持区域维、业务维、产品部等多个维度同时校验，满足"华南区 + 直销业务 + 产品A"这样的组合权限控制
两种失败策略：
- throw：鉴权失败抛异常，适合严格权限控制的场景
- filter：鉴权失败过滤结果返回空数据，适合"能看到多少算多少"的场景
与路由解耦：鉴权规则和路由规则独立配置，可单独修改和发布

API 后端抽象

每个场景最终要映射到一个具体的后端 API：

{
  "apiType": "BIDS",
  "apiPath": "/bids/order/query/v2",
  "httpMethod": "POST",
  "resultType": "list",
  "resultPath": "data.orders"
}

支持的后端类型：

BIDS：企业内部数据服务总线
SOA：传统的 SOA 服务
HTTP：任意外部 HTTP 端点

结果路径配置解决了不同后端返回结构不一致的问题——引擎自动从响应中提取指定路径的数据，统一返回给调用方。

配置管理

一个容易被忽视但非常重要的部分是配置管理。我们实现了：

版本号管理：每次修改递增版本号，方便回滚
草稿/发布机制：编辑后先保存为草稿，确认无误再发布
历史版本查询：可回溯任意历史版本
导入/导出：支持配置的批量导入导出，便于环境迁移

<!-- 场景路由配置表的可视化界面 -->
<div class="table-container">
  <table id="scenario-table">
    <thead>
      <tr>
        <th>服务编码</th>
        <th>场景编码</th>
        <th>场景名称</th>
        <th>路由规则</th>
        <th>鉴权规则</th>
        <th>版本号</th>
        <th>状态</th>
        <th>操作</th>
      </tr>
    </thead>
  </table>
</div>

实战经验总结

这套引擎在实际项目中运行了一段时间，几点体会：

配置优于编码：新增一个场景只需要在界面上配一条记录，不需要改代码、不需要重新部署，业务响应速度从"天"级变成"分钟"级
鉴权是最大的坑：不同业务方对鉴权的理解不一致，throw vs filter 的选择需要和业务方充分对齐，建议默认 throw，显式改为 filter
监控不可少：路由命中率、鉴权失败率、后端响应时间等指标需要接入监控，否则出了问题很难排查
规则数量要控制：单个服务的场景数建议不超过 20 个，超过后考虑拆分服务

小结

场景路由编排引擎解决的是中台建设中的"最后一公里"问题——服务统一了，但不同场景的差异化需求怎么处理？通过配置化的路由 + 鉴权 + 后端抽象，我们做到了不改代码灵活适配多变业务。

如果你也在做中台建设，或者面临类似的"一个接口多种实现"的问题，希望这套设计思路能给你一些启发。

本文配套的配置界面原型代码和用例图可在项目仓库中查看。

中台场景路由编排引擎设计实战

# 概要

# 核心概念

# 路由规则设计

# 鉴权引擎

# API 后端抽象

# 配置管理

# 实战经验总结

# 小结

概要