真实落地时，大家会马上追问：谁能调这个接口？能看到哪些字段？一次上限查多少？慢查询谁负责？数据源密码放哪？字段改名会影响哪些接口？有没有审计记录？这些都不是 SQL2API 本身能顺手解决的问题。

这一篇聊背景：为什么要从一个 SQL2API 工具，继续往数据开放平台演进，以及平台的架构怎么拆。

一、从 SQL2API 到数据开放平台

SQL2API 解决的是一个很具体的问题：把 SQL 变成 API，省掉 CRUD 的模板代码。 这个能力很有价值，但它只是数据开放链路里的一个环节。

真实场景里，一个完整的数据开放链路长这样：

1. 数据接入：连各种数据源（MySQL、PostgreSQL、ES、Hive、API），把数据接进来
2. 数据加工：字段映射、格式转换、数据脱敏、聚合计算
3. 服务发布：把加工后的数据发布成 API，支持多种协议（REST、gRPC、WebSocket）
4. 访问控制：AK/SK 认证、租户隔离、流量控制、配额管理
5. 监控治理：调用链追踪、慢查询告警、数据血缘、审计日志
6. 运维管理：灰度发布、容灾备份、SDK 生成、文档管理

SQL2API 只覆盖了第 3 步的一部分。要从"工具"升级为"平台"，需要把这六步都串起来，而且要能长期运维。

类比一下：SQL2API 是一个厨师，能把食材做成菜。数据开放平台是一个餐厅，从采购（数据接入）、备菜（数据加工）、烹饪（服务发布）、上菜（访问控制）、品控（监控治理）到运营（运维管理），全流程都有。

1.1 为什么不直接开放数据库

有人会问：既然本质是查数据，为什么不直接给业务方一个只读账号，让他们连库查？

这个方案短期速度高，长期更麻烦：

• 权限太粗：数据库账号一般按库、表授权，很难细到"这个应用只能看订单表里的 5 个字段"。
• 审计断层：只能看到某个账号执行了 SQL，很难还原到具体应用、具体接口、具体业务场景。
• 流量不可控：一个全表扫描或者大分页，就可能把线上库拖慢。
• 数据口径失控：每个调用方自己写 SQL，同一个指标可能有三种算法。
• 变更风险大：表结构改了，谁受影响靠猜，没人愿意拍胸脯。

所以数据库可以作为底座，但不应该直接暴露给调用方。平台要把权限、限流、审计、口径和 SLA 都挡在前面。

1.2 为什么也不能只靠网关

API Gateway 很重要，但它解决的是入口问题：认证、限流、路由、协议转换。它不知道某个接口背后查了哪些表，也不知道手机号字段该不该脱敏，更不知道这个 SQL 是否会扫全表。

数据开放平台需要补的是数据侧能力：

• 权限：应用级、API 级、字段级、数据范围级权限。
• 审计：谁在什么时间，用什么参数，访问了什么数据。
• 限流与配额：保护平台，也保护底层数据库。
• 元数据：数据源、表、字段、接口、参数、返回结构都要可管理。
• 血缘：一个字段变更，要知道影响哪些 API 和调用方。
• 数据源管理：连接池、密钥、健康检查、备用数据源不能散落在代码里。
• SLA：接口超时、成功率、慢查询、告警都要有明确指标。

这些能力靠网关很难补齐，必须下沉到数据服务平台本身。