如何利用SQL2API低代码重构HIS数据接口

0 阅读1分钟

在医疗、金融和传统制造业,普遍存在运行了十年以上的核心业务系统。以某三甲医院为例,其核心的 HIS(医院信息系统)是十多年前基于 C# 和 Oracle 数据库开发的单体应用。

随着互联网医疗的推进,医院需要开发微信小程序和移动端 App,实现线上挂号、报告查询、处方流转等功能。这要求后端提供大量轻量级的 RESTful API。然而,工程团队面临着一个死结:

  • 原开发商已停止维护,没有接口文档。
  • 医院现有的 Java/Go 研发团队不敢触碰庞大且缺乏测试覆盖的 C# 老代码。
  • 如果采用传统的“中间件重新封装”模式,需要后端工程师逆向梳理 Oracle 数据库中成百上千张缺乏注释的表,开发周期极长,且容易引发线上事故。

面对“代码已死,但数据依然鲜活”的局面,如何跳过应用层,直接将底层数据安全、快速地服务化输出,成为了架构重构的关键。

一、 引入防腐层 (Anti-corruption Layer):跳过应用层的旁路接入

在领域驱动设计(DDD)中,防腐层用于隔离新旧系统。在上述场景中,基础架构团队决定放弃对旧 C# 系统的改造,转而引入 SQL2API(QuickAPI)引擎,将其作为数据层面的防腐层。

架构解耦设计:

  1. 物理隔离: 通过 Oracle Data Guard 或类似同步机制,为 HIS 主库建立一个实时的只读备库(Read-only Replica)
  2. 旁路直连: SQL2API 引擎直接连接这个只读备库,完全绕过老旧的 C# 应用层。
  3. 能力映射: 将底层复杂的关系型数据,映射为现代前端友好的 HTTP/JSON 接口。

这种“旁路接入”模式确保了新业务的查询流量 100% 不会影响核心 HIS 系统的写入性能。

二、 核心技术落地:从复杂 SQL 到标准 API 的转化

部署 SQL2API 引擎后,接口的交付模式发生了质变。原本需要后端开发编写 Controller、Service、Mapper 的冗长流程,被精简为“数据视角的声明式配置”。

1. SQL 即接口 (SQL-as-an-API)

医院的 DBA 或熟悉业务表结构的数据工程师成为了接口的生产者。 例如,为了开发一个“查询患者就诊记录及检验结果”的接口,工程师只需在 QuickAPI 平台上编写如下 SQL 模板:

SELECT 
    p.patient_id, p.name, p.age,
    v.visit_date, v.department,
    r.test_name, r.result_value, r.reference_range
FROM patients p
JOIN visits v ON p.patient_id = v.patient_id
LEFT JOIN lab_results r ON v.visit_id = r.visit_id
WHERE p.id_card = ${req.query.idCard} -- 定义动态入参
ORDER BY v.visit_date DESC

平台接收到该 SQL 后,利用 AST(抽象语法树)解析器,自动识别出参和入参。点击发布,一个标准的 GET /api/v1/patients/visit-records 接口便即刻生成。

2. 协议与数据格式转换

遗留的 Oracle 数据库返回的是扁平的 ResultSet(结果集),而前端(尤其是移动端小程序)更期望接收具有层级结构的 JSON 数据。 SQL2API 引擎在网关层承担了序列化与重组的工作。它可以根据配置,将通过 JOIN 产生的冗余行数据,自动折叠(Fold)并转换为前端友好的嵌套 JSON 对象,免去了传统开发中编写大量 DTO(数据传输对象)的转换代码。

3. 隐性风险的网关层兜底

由于老系统的表结构往往缺乏合理设计(如缺少索引、数据倾斜),直接开放查询风险极高。SQL2API 在引擎层设置了强制的运行态约束:

  • 强制分页: 无论 SQL 是否编写了分页逻辑,引擎在解析时强制注入 ROWNUM 或 LIMIT/OFFSET 机制,防止一次性拉取数十万条记录导致的内存溢出(OOM)。
  • 超时控制与并发限流: 在网关层面针对不同的小程序应用分配不同的 AppKey,并设定严格的 QPS 上限和执行超时阈值。一旦查询超时,引擎主动向数据库发送 Kill 信号并向前端返回降级数据。

三、 总结:从“代码重构”转向“数据复用”

通过引入 SQL2API 构建数据访问防腐层,该医院在没有修改一行遗留系统代码的前提下,仅用数周时间就完成了几十个核心数据接口的现代化发布。

对于历史包袱沉重的企业而言,试图一次性重构整个单体系统往往会陷入“焦油坑”。SQL2API 提供了一种非常务实的架构演进思路:承认底层系统的现状,通过在数据存储层之上的动态协议转换,实现新旧生态的解耦。

这不仅极大地缩短了移动端业务的交付周期,也为未来彻底剥离和替换老系统,争取了宝贵的工程时间。