产品简介
数据墙DBW 是一个配置驱动的数据 API 生成引擎，可运行在本地进程、容器或自托管环境中。它可以连接受支持的数据库，把表、视图、存储过程等数据库对象发布为 REST API、GraphQL API，并可为 AI 代理提供 MCP（Model Context Protocol，模型上下文协议）访问能力。
使用数据墙DBW时，开发者不需要为每张表或每个常见数据操作重复编写后端接口。你通过 JSON 配置声明数据源、实体、字段、关系、权限和运行时行为，服务启动后会根据配置生成统一的 API 入口。
解决什么问题
在很多业务系统中，后端接口的主要工作是围绕数据库做通用数据访问：查询、筛选、排序、分页、新增、更新、删除、调用视图或存储过程。这类接口数量多、逻辑相似，但仍然需要处理认证、授权、字段控制、接口文档、日志、健康检查和部署等工程问题。
数据墙DBW 将这部分重复工作抽象为配置：
- 用配置定义数据库连接，而不是在业务代码中硬编码连接逻辑。
- 用实体声明要公开的表、视图和存储过程，而不是逐个手写控制器。
- 用权限规则控制角色可执行的操作，而不是在接口中分散编写判断逻辑。
- 用统一运行时提供 REST、GraphQL、MCP、健康检查、日志和观测能力。
它适合作为数据库和应用之间的数据访问网关，帮助团队更快发布标准化、可治理的数据接口。
核心能力
数据墙DBW 的核心能力包括：
| 能力 | 说明 |
|---|---|
| 自动生成 REST API | 根据实体配置生成 REST 端点，支持常见 CRUD、分页、筛选、排序和字段选择。 |
| 自动生成 GraphQL API | 根据同一实体模型生成 GraphQL 查询和变更能力，支持关系查询、聚合和多重变更等场景。 |
| 配置化数据建模 | 通过配置定义数据源、实体、字段别名、主键、关系、缓存和健康检查。 |
| 身份认证与授权 | 支持匿名访问、JWT 身份验证、角色权限、字段级控制和数据库访问策略。 |
| MCP 集成 | 将数据库能力以 MCP 工具形式暴露给 AI 代理或 MCP 客户端。 |
| 可部署运行时 | 支持本地进程、容器和自托管环境，便于接入现有部署体系。 |
数据库支持
数据墙DBW 支持以下关系型数据库：
| 数据库 | 说明 |
|---|---|
| SQL Server | 支持表、视图、存储过程和自动实体发现。 |
| PostgreSQL | 支持表、视图、存储过程和完整的关系型能力。 |
| MySQL | 支持表、视图和存储过程。 |
数据墙DBW 可以同时连接多个数据源。你可以组合多个数据库，把不同数据源统一暴露为一致的 API 入口。各数据库的详细能力差异请参阅功能可用性。
配置文件结构
数据墙DBW 至少需要一个 JSON 配置文件。这个文件描述服务如何连接数据库、公开哪些数据库对象，以及运行时启用哪些接口和安全能力。常用配置部分如下：
| 配置项 | 作用 |
|---|---|
data-source | 定义数据库类型、连接字符串和数据源相关选项。 |
runtime | 定义服务运行行为，例如 REST、GraphQL、MCP、缓存、日志和健康检查。 |
entities | 定义要公开的数据库对象、API 形态、关系、权限、字段和缓存策略。 |
其中 entities 是对外发布数据能力的主要配置。一个实体通常对应数据库中的表、视图或存储过程。实体配置决定数据库对象如何呈现在 API 中，例如 REST 路径、GraphQL 类型、允许操作、字段别名、实体关系、缓存策略和 MCP 工具暴露方式。
通过这层实体模型，数据库表名、列名和内部结构可以与外部 API 契约解耦。你可以为 API 使用更稳定、更面向业务的命名，同时保留数据库内部实现。
工作原理
数据墙DBW 的核心思路是：用配置驱动运行时，而不是用代码生成接口。它不会修改数据库结构，也不会把配置转换成固定代码文件。
启动阶段，服务读取 JSON 配置文件，根据 data-source 建立数据库连接，根据 entities 或 autoentities 将数据库对象映射为实体模型，并根据运行时配置启用 REST、GraphQL、MCP、缓存和健康检查等能力。
完成启动后，服务进入请求处理阶段。具体处理步骤见下一节请求处理机制。
请求处理机制
当客户端调用 REST、GraphQL 或 MCP 接口时，数据墙DBW 不会简单地把请求原样转发到数据库。它会经过一组统一处理步骤：
- 解析请求协议和目标实体。
- 根据身份验证结果确定当前角色。
- 检查该角色是否拥有对应操作权限。
- 应用字段级限制、数据库访问策略和请求参数。
- 生成数据库查询或存储过程调用。
- 执行数据库访问并处理结果。
- 按协议格式返回响应。
这种处理方式让 REST、GraphQL 和 MCP 可以复用同一套数据源、实体和权限配置，减少多套接口之间的规则漂移。
REST、GraphQL 与 MCP 的关系
数据墙DBW 可以基于同一实体模型同时公开多种访问方式：
| 访问方式 | 主要用途 |
|---|---|
| REST API | 适合传统 Web、移动端、后端服务和低代码平台调用。 |
| GraphQL API | 适合需要按需选择字段、关系查询或聚合查询的客户端。 |
| MCP | 适合 AI 代理或 MCP 客户端以工具方式访问数据库能力。 |
这些协议并不是彼此独立的三套实现。它们共享同一份配置和权限模型。你可以只启用其中一种，也可以根据场景同时启用多种。
适用场景
数据墙DBW 更适合以下场景：
- 已有数据库需要快速发布标准 API。
- 前端、移动端、低代码平台需要统一数据访问入口。
- 企业内部系统需要封装数据库对象，减少重复接口开发。
- 团队希望用统一权限模型控制表、视图和存储过程访问。
- AI 代理或 MCP 客户端需要以受控方式读取或操作数据库数据。
不适合什么场景
数据墙DBW 不是替代所有后端服务的通用业务框架。以下场景通常仍需要业务服务或专门后端代码：
- 接口包含大量跨系统编排、复杂状态机或长事务流程。
- 每个接口都需要高度定制的业务算法、异步任务或消息队列处理。
- 需要在接口层实现复杂文件处理、实时通信或非数据库核心能力。
- 数据访问必须经过大量领域服务规则，不能直接映射为数据库对象访问。
常见做法是：用数据墙DBW 承担标准数据访问接口，用业务服务承担复杂业务流程。两者可以并行存在。
与传统后端 API 的关系
传统后端 API 通常由开发者编写路由、控制器、服务层、数据访问层和权限判断。数据墙DBW 将通用数据访问链路收敛到一个运行时中，通过配置生成接口。
这并不意味着完全不需要后端开发，而是把重复、标准化的数据接口交给配置化平台处理，让后端开发更专注于真正的业务逻辑、领域模型和系统集成。
下一步
- 阅读创建第一个数据 API，从关系型数据库开始快速体验。
- 阅读配置架构参考，了解配置文件的完整结构。