每个 Java 程序员的职业生涯里，都有那么一段被 Controller-Service-Mapper 三层架构支配的恐惧。

---

一、一个所有后端都经历过的"至暗时刻"

产品经理走过来：“这个需求很简单，就是加几个查询接口。”

你打开数据库，设计好表结构。

然后——

• 写 Entity
• 写 Mapper 接口
• 写 Mapper XML
• 写 Service 接口
• 写 Service 实现
• 写 Controller
• 写 DTO/VO 转换
• 写 Swagger 注解
• 写单元测试

一个接口，8 个文件，200 行代码。

而这段代码里，真正有业务逻辑的部分，可能不到 20 行。

剩下的 180 行，全是"体力活"——把数据从一层搬到另一层，换个名字，换个格式，再搬回去。

你开始怀疑人生：我学了四年计算机科学，就是为了当一个人肉搬运工吗？

---

二、SQLREST：把 API 开发从"编码"变成"配置"

SQLREST 是 Dromara 开源社区的一个项目，核心理念只有一句话：

你写好 SQL，剩下的交给它。

它的工作方式很简单：

1. 在 Web 管理界面上配置好数据源
2. 写一条 SQL（支持 MyBatis 动态 SQL）
3. 设置接口路径和参数
4. 点击保存

一个符合 RESTful 规范的 API 接口就诞生了。

不需要写 Controller，不需要写 Service，不需要写 Mapper。

你只需要关心一件事：数据怎么查。

---

三、它到底解决了什么痛点？

3.1 重复编码，占到开发时间的 60% 以上

有团队做过统计，一个典型的后端项目中，超过 60% 的代码是 CRUD 样板代码。

这些代码的特点是：

• 逻辑简单，但数量庞大
• 每改一个字段，要同步改 3-4 个文件
• 出错概率低，但一旦出错排查困难（因为代码太"平"了，看不出问题）

SQLREST 把这部分工作从"编码模式"切换到了"配置模式"。

配置模式的效率，是编码模式的 5-10 倍。

3.2 数据中台场景下的"接口爆炸"

在做数据中台、数据共享平台时，一个常见的需求是：把数据库里的几十上百张表，对外提供查询接口。

如果按传统方式，每个表写一套 CRUD，几十个表就是几百个文件。

用 SQLREST，每个表只需要配置几条 SQL，工作量从"周"级别降到"小时"级别。

3.3 前后端协作中的"接口文档滞后"

后端写完接口，忘记更新 Swagger 文档；前端拿着旧文档调接口，报错后找后端对质——这个场景太常见了。

SQLREST 自动生成 Swagger 在线文档，接口配置完，文档就同步更新了。

---

四、“低代码"不等于"低能力”

很多人听到"低代码"三个字，第一反应是：功能肯定很受限，复杂场景搞不定。

SQLREST 的设计思路是：80% 的场景用 SQL 解决，剩下 20% 用 Groovy 脚本兜底。

4.1 MyBatis 动态 SQL：复杂查询不是问题

它原生支持 MyBatis 的动态 SQL 语法：

<select id="searchUsers" resultType="User">
    SELECT * FROM user
    <where>
        <if test="name != null">
            AND name LIKE CONCAT('%', #{name}, '%')
        </if>
        <if test="status != null">
            AND status = #{status}
        </if>
        <if test="startTime != null and endTime != null">
            AND create_time BETWEEN #{startTime} AND #{endTime}
        </if>
    </where>
    ORDER BY create_time DESC
</select>

条件查询、分页查询、多表 JOIN，MyBatis 能做的，它都能做。

4.2 Groovy 脚本：SQL 搞不定的，代码来

有些场景确实超出了 SQL 的能力边界：

• 需要调用外部 HTTP 接口
• 需要复杂的条件判断和数据转换
• 需要操作文件系统或消息队列

这时候，SQLREST 支持在接口中嵌入 Groovy 脚本：

def result = sql.query("SELECT * FROM order WHERE id = ?", orderId)
if (result.isEmpty()) {
    return [code: 404, msg: "订单不存在"]
}
def order = result[0]
// 调用外部服务查询物流
def logistics = http.get("https://api.logistics.com/track", [orderNo: order.orderNo])
return [code: 200, data: [order: order, logistics: logistics]]

SQL + Groovy 的组合，覆盖了从简单查询到复杂业务的全场景。

---

五、架构设计：为什么是"三节点"模式？

SQLREST 采用基于 Spring Cloud 的微服务架构，由三个核心组件组成：

┌─────────────────────────────────────────────────┐
│                  Gateway（网关节点）              │
│  - 统一入口                                      │
│  - 身份认证（Token 校验）                         │
│  - 流量控制（Sentinel）                           │
│  - 路由转发                                      │
└──────────────────┬──────────────────────────────┘
                   │
        ┌──────────┼──────────┐
        ▼          ▼          ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│Executor#1│ │Executor#2│ │Executor#3│
│ 执行SQL   │ │ 执行SQL   │ │ 执行SQL   │
│ 执行Groovy│ │ 执行Groovy│ │ 执行Groovy│
└──────────┘ └──────────┘ └──────────┘
        ▲          ▲          ▲
        └──────────┼──────────┘
                   │
┌──────────────────┴──────────────────────────────┐
│                Manager（管理节点）                │
│  - Web 管理界面                                  │
│  - 数据源配置                                    │
│  - SQL 配置                                      │
│  - 接口管理                                      │
│  - 配置持久化                                    │
└─────────────────────────────────────────────────┘

三个组件各司其职：

组件	角色	职责
Manager	大脑	提供管理界面，处理所有配置操作
Executor	肌肉	接收请求，执行 SQL/Groovy，返回结果
Gateway	门户	统一入口，认证鉴权，流量控制

这种解耦设计的好处是：部署方式灵活。

• 开发/测试环境：三个组件部署在同一台机器上，单机运行
• 生产环境：Executor 可以水平扩展，应对高并发；Manager 独立部署，保证配置安全

---

六、企业级特性：不是玩具，是工具

很多低代码项目止步于"能跑通 Demo"，但 SQLREST 内置了一系列企业级特性：

6.1 安全：Token 认证

基于 Bearer Token 的身份认证机制，每个 API 调用都需要携带有效的 Token。

6.2 性能：Redis / Hazelcast 缓存

支持配置接口级别的缓存策略。对于查询频率高、数据变更少的接口，开启缓存后响应时间可以从百毫秒级降到个位数毫秒。

6.3 稳定性：Sentinel 流量控制

集成 Sentinel，可以对每个接口设置 QPS 上限、并发数限制。防止某个接口被突发流量打垮，影响整个系统。

6.4 可观测：统一告警对接

支持与外部告警系统对接，接口异常、超时、错误率超标时自动触发告警。

6.5 MCP 服务：面向 AI 时代的扩展

最新版本支持将 SQL 接口直接发布为 MCP Tool，让 AI Agent 能够通过标准协议调用数据库能力。

这一点非常值得关注——当你的数据接口同时服务于前端应用和 AI Agent 时，SQLREST 提供了一条统一的发布路径。

---

七、数据库兼容性：不挑活

SQLREST 支持 20+ 种数据库，涵盖主流开源库和国产数据库：

主流开源： MySQL、PostgreSQL、Oracle、SQL Server、SQLite、MariaDB…

国产数据库： 达梦、金仓、OceanBase、TDengine、TiDB…

时序/分析型： ClickHouse、Doris…

这意味着，无论你公司的技术栈是什么，基本都能找到对应的驱动。

---

八、5 分钟快速上手

最简单的体验方式是用 Docker Compose 一键部署：

# 1. 拉取代码
git clone https://gitee.com/dromara/sqlrest.git

# 2. 进入部署目录
cd sqlrest/build-docker/install

# 3. 一键启动
docker-compose up -d

启动完成后，浏览器访问 http://localhost:8090：

• 默认用户名：admin
• 默认密码：123456

登录后，配置一个数据源，写一条 SQL，设置一个路径——你的第一个 API 就上线了。

全程不需要写一行 Java 代码。

---

九、适合谁用？不适合谁用？

✅ 适合的场景

• 中小型项目快速交付：团队人少，时间紧，需要快速出接口
• 数据中台/数据共享：需要把大量数据表对外提供查询接口
• 内部工具/管理后台：接口逻辑简单，以 CRUD 为主
• 原型验证/MVP：快速验证业务想法，后续再考虑重构
• AI Agent 数据层：通过 MCP 协议将数据库能力暴露给 AI 应用

❌ 不适合的场景

• 核心业务系统：涉及复杂事务、分布式锁、强一致性要求的场景
• 高并发 C 端接口：需要极致性能优化的场景（虽然可以加缓存，但毕竟多了一层代理）
• 强定制化需求：每个接口都有独特逻辑，无法用 SQL + Groovy 覆盖

SQLREST 不是银弹，但它能帮你解决 80% 的重复劳动。

---

十、写在最后

每个程序员都应该问自己一个问题：

我的时间，应该花在"写样板代码"上，还是"解决业务问题"上？

SQLREST 给出的答案是：把重复的交给工具，把创造留给自己。

当你不再需要为每个 CRUD 接口写 8 个文件的时候，你省下来的不只是时间——

还有对编程这件事的热情。

---

项目信息：

• Gitee：https://gitee.com/dromara/sqlrest
• Dromara 社区：https://dromara.org/zh/
• 使用文档：https://www.yuque.com/sanpang-jq7te/nys82g/hur636mthgyhaodb

---

🎁 福利时间

如果你正在备战面试或者想要学习其他知识，给大家推荐一个宝藏知识库，作者整理了一些列 Java 程序员需要掌握的核心知识，有需要的自取不谢。

知识库地址：https://farerboy.com/

---