yii 适合作为数据中台中边界清晰的业务逻辑与协议适配子模块，承担数据服务网关、元数据管理后台、指标api封装、权限策略执行点等角色，不替代flink、kafka或doris等底层引擎。
Yii 适合做数据中台的子模块，但不是作为“统一调度中枢”或“实时流处理引擎”，而是承担数据服务网关、元数据管理后台、指标API封装、权限策略执行点等边界清晰、偏业务逻辑与协议适配的角色。
明确 Yii 在数据中台里的定位
数据中台通常包含数据采集、存储、计算、治理、服务五大层。Yii 不适合写 Flink 作业、不直接对接 Kafka 消费组、也不替代 Doris/StarRocks 做即席查询——但它非常擅长把已加工好的数据，安全、稳定、结构化地“交出去”。典型适用子模块包括：
- 指标中心 Web 后台：管理指标定义、口径说明、责任人、SQL 模板、血缘标签
- 数据服务 API 网关：接收前端/BI/下游系统请求，校验权限、拼接参数、调用 Presto/Trino 或缓存层取数，返回标准 JSON
- 主数据管理（MDM）轻量版：维护组织、人员、产品等核心实体的增删改查与审批流
- 数据质量看板后端：聚合 DataQuality 工具（如DQC）的离线结果，提供 REST 接口供大屏调用
模块间对接的关键设计原则
避免让 Yii 子模块变成“胶水层黑洞”。所有对外依赖必须显式、可控、可替换：
- 不直连其他微服务数据库，只通过 HTTP（推荐 REST）或消息队列（如 yii\queue + RabbitMQ）通信
- 将外部服务调用封装为独立 Service 类（如
MetricsQueryService），禁止在 Controller 里 new Client 或拼 URL - 关键数据源（如指标元数据、权限策略）必须有本地缓存兜底，使用
yii\redis\Cache或ApcuCache，设置合理 TTL 和自动刷新机制 - 所有出向请求加超时（
timeout: 3）、重试（最多 1 次）、熔断（可用yiisoft/yii-queue的失败回调触发告警）
具体对接方式示例
以“指标 API 子模块”对接 Trino 查询引擎为例：
- 定义专用控制器
api\modules\v1\controllers\MetricsController，路由为GET /v1/metrics/{id} - 在 action 中不写 SQL，而是调用
$service->execute($metricId, $params)，该方法内部：先查 Redis 缓存metrics:def:{id}获取指标定义；再根据source_type（如 trino、mysql、redis）分发到对应执行器 - Trino 执行器使用
yii\httpclient\Client调用 Trino REST API，传入预编译 SQL 模板和绑定参数，解析 JSON 响应并标准化字段名（如统一转小写下划线） - 响应头强制添加
X-Data-Source: trino和X-Cache-Hit: MISS/YES，便于前端和运维追踪链路
权限与治理必须内建
数据中台子模块不能只管“能不能查”，更要回答“该不该查”：
- 接入统一认证中心（如 OAuth2 Server），用
authenticator中间件校验 token，并从 claims 中提取tenant_id、role - 在查询前调用
DataAccessPolicy::check($userId, $metricId, 'read')，策略规则可存在 DB 或配置文件中，支持按租户、角色、字段级控制 - 所有查询操作记录审计日志（含用户、指标ID、参数、耗时、是否命中缓存），日志推送到 ELK 或 Kafka
- 提供
/v1/metrics/{id}/explain接口，返回该指标的血缘路径（上游表、ETL 任务 ID、负责人邮箱），供数据治理平台拉取
