
如何获取免费的ChatGPT API密钥 – Apidog
## 绕过API,直接部署数据库
在构建工具的过程中,最让人兴奋的部分莫过于发现它们的意外用途。这种感觉就像在写一本谋杀悬疑小说,但连自己都不知道凶手是谁!历史上有许多这样的意外发现:例如,WD-40最初是为了保护洲际弹道导弹免受锈蚀,如今却成为修复门把手刺耳噪音的神器;气泡膜最初是作为壁纸出售的,现在却成了保护快递包裹的必备品。
当我们开始开发分布式SQLite数据库LiteFS时,原本的目标是实现地理分布式数据存储,让全球用户都能享受到快速的响应时间。例如,布加勒斯特的用户可以像圣何塞的用户一样快速访问数据。大多数LiteFS用户确实是这样使用的,但我们意外发现了另一种用途:用SQLite数据库替代服务之间的API层。
---
### LiteFS的意外用途:替代API层
在LiteFS开发的早期阶段,我们需要一个真实的测试平台来发现自动化测试中未能捕捉到的潜在问题。我们的基础设施中有一个名为“Corrosion”的程序,它通过八卦协议在所有服务器之间共享状态信息。Corrosion会跟踪每台服务器的虚拟机状态、健康检查以及其他关键信息,并将这些信息同步到其他服务器,以便它们能够更智能地进行请求路由和虚拟机分配。所有这些数据都存储在SQLite数据库中,作为快速本地副本。
于是,我们在LiteFS上运行了一个Corrosion实例。这不仅帮助我们发现并修复了一些问题,还带来了另一个意外的好处:让内部服务能够直接访问Corrosion的数据。

---
### 跳过API设计,直接传递数据库
传统上,服务之间的数据传递需要耗费数周时间设计API,并围绕API构建服务。API设计需要充分考虑每个消费服务的不同用例,以确保高效地提供所需数据。否则,客户可能需要为每个请求调用多个API接口。

然而,我们选择了一种完全不同的方法:直接将整个数据库传递给客户端。这样一来,无需考虑消费服务的访问模式,因为客户端可以直接使用标准SQL查询和连接来获取所需数据。这正是我们使用LiteFS所实现的。
---
### 只读数据库副本的优势
虽然我们可以将每个下游服务设置为Corrosion节点,但八卦协议可能会导致过多的通信开销。而实际上,我们只需要单向的数据更新流。通过LiteFS设置只读实例非常简单,只需提供上游主节点的主机名即可完成连接。这样,应用程序就能获得完整的只读数据库副本。
此外,直接查询服务通常需要应对多个租户竞争计算资源的问题,例如速率限制和查询超时。而通过向客户端提供只读数据库副本,这些问题迎刃而解。客户端可以自由使用自己的硬件资源,即使某个租户消耗了大量CPU资源,也不会影响其他租户的正常运行。
---
### 技术权衡与挑战
尽管只读副本带来了许多便利,但它也有一些限制和挑战:
1. **只读限制**
只读副本无法进行数据更新。如果客户端需要对数据进行修改,仍然需要通过API来完成。
2. **数据库约定的灵活性**
与API相比,数据库的约定可能不够严格。API的一个优势是可以隐藏底层数据库结构的变化,而直接传递数据库则需要客户端适应这些变化。幸运的是,许多数据库变更(例如添加新列)通常是向后兼容的,客户端无需修改代码。此外,可以通过数据库视图来重塑数据结构,确保数据的一致性。
3. **访问控制的限制**
如果数据库是多租户的,直接传递数据库可能会导致数据泄露风险。解决方案是为每个租户创建独立的数据库。SQLite数据库非常轻量化,因为它们只是磁盘上的文件。这种方法不仅提高了安全性,还能防止跨租户的查询错误。
---
### 未来展望:将查询推送给最终用户
虽然这种方法在内部工具中表现良好,但在更广泛的软件领域中,它的应用前景如何?API可能在未来仍然占据主导地位,但对于某些特定用例,提供只读数据库副本是非常有意义的。
想象一下,能够直接从本地数据库查询所有的Stripe数据或GitHub数据。用户可以将这些数据与自己的数据集结合起来,并在自己的硬件上快速执行查询。这种灵活性和功能性对数据提供者和消费者来说都有巨大的吸引力。
例如,Stripe或GitHub可能会将租户数据存储在一个共享数据库中,而许多公司则可以通过Kafka等工具运行事件总线,为每个租户生成独立的SQLite数据库,并将其流式传输给客户。
这种方式不仅提高了数据访问的灵活性,还为数据消费者提供了更强大的功能支持。
---
### 总结
通过LiteFS直接部署只读数据库副本,为服务之间的数据传递提供了一种全新的思路。虽然这种方法并不能完全取代API,但在特定场景下,它能够显著提升数据访问的效率和灵活性。未来,随着技术的不断发展,这种模式或许会在更多领域中得到应用,为数据提供者和消费者带来更多可能性。
原文链接: https://fly.io/blog/skip-the-api/