Alexey Evlampiev：请求即事务
内容提要
将API事务边界移至PostgreSQL内部，使路由、验证、授权和事务管理成为数据库原生操作。通过将API契约建模为数据表，实现单一权威、单一事务和可执行证明。测试可在同一事务中验证响应与状态变更，并回滚。此设计适用于以事务决策为核心的系统，网络层仍由网关处理。
延伸解读
权威单一化：消除双重维护
文章指出，传统架构中数据库与框架层各自维护一份规则副本，如校验、授权、事务边界，导致权威分裂。将API事务边界移入PostgreSQL后，路由、验证、授权等均以数据表或约束形式存在，单一权威从构造上消除规则漂移。例如，唯一性校验由数据库唯一索引强制执行，应用层校验仅为便利副本。这种设计使规则变更只需修改一处，降低维护成本与不一致风险。
事务边界内移：消除跨网络执行缺陷
将事务边界移入数据库后，事务内无法进行网络I/O，从架构上杜绝了空闲事务占用连接池、N+1查询等缺陷。文章引用IBM案例：应用层事务边界导致65%连接空闲等待网络I/O，而数据库内事务则不可能出现此问题。此外，事务内可同时断言响应与状态变更，测试可在同一快照中验证并回滚，实现可执行证明，提升测试可靠性与部署信心。
适用边界与局限
该设计适用于以事务决策为核心、基于PostgreSQL的系统，不适用于网络I/O密集、媒体处理或流式场景。文章承认工具链、部署、调试等反对意见，并指出扩展性限制：数据库垂直扩展有限，且无法进行金丝雀发布。因此，采用此架构需权衡利弊，明确适用场景，避免盲目迁移。
Q&A
什么是“请求即事务”架构？
该架构将API的事务边界移至PostgreSQL内部，使路由、验证、授权和事务管理成为数据库原生操作。网络层（如TLS、HTTP解析）仍由网关处理，而事务性操作（如解析、验证、授权、状态转换）在数据库内执行，从而确保单一权威、单一事务和可执行证明。
为什么将API逻辑移入数据库能避免“双重权威”问题？
传统架构中，应用层和数据库分别维护规则（如验证、约束），导致两处权威可能不一致。将事务边界移入数据库后，规则只存在于数据库，消除了重复定义，从而避免因副本漂移导致的错误。
如何用PostgreSQL实现API路由？
将路由表建模为数据库表，包含路径、方法、版本、处理函数等字段。路由匹配通过SQL查询完成，支持事务性部署、可查询性和可证明性（如避免路由重叠）。
在“请求即事务”中，如何实现API版本控制？
版本控制通过路由表中的版本正则表达式实现，每个版本对应一行。旧版本无需迁移或包装，只需保留其路由行，新版本添加新行。通过显式版本模式避免依赖注册顺序。
数据库内授权如何工作？
使用行级安全（RLS）策略，将授权谓词附加到表上，确保任何查询路径都受策略约束。身份信息通过事务级设置传递，由网关验证后存储，数据库角色作为边界。
如何测试“请求即事务”架构？
测试可以在同一事务中调用API操作，断言响应和状态变更，然后回滚。例如，使用BEGIN; SELECT api.invoke(...); -- 断言; ROLLBACK; 确保测试不留下副作用。
这种架构适用于哪些场景？
适用于以事务决策为核心的系统，如订单处理、金融交易等，其中业务逻辑主要涉及对PostgreSQL状态的事务性修改。不适用于需要大量网络I/O、媒体处理或流式计算的场景。
