在LiteFS開發的早期階段，我們需要一個真實的測試平臺來發現自動化測試中未能捕捉到的潛在問題。我們的基礎設施中有一個名為“Corrosion”的程序，它通過八卦協議在所有服務器之間共享狀態信息。Corrosion會跟蹤每臺服務器的虛擬機狀態、健康檢查以及其他關鍵信息，并將這些信息同步到其他服務器，以便它們能夠更智能地進行請求路由和虛擬機分配。所有這些數據都存儲在SQLite數據庫中，作為快速本地副本。
于是，我們在LiteFS上運行了一個Corrosion實例。這不僅幫助我們發現并修復了一些問題，還帶來了另一個意外的好處：讓內部服務能夠直接訪問Corrosion的數據。
傳統上，服務之間的數據傳遞需要耗費數周時間設計API，并圍繞API構建服務。API設計需要充分考慮每個消費服務的不同用例，以確保高效地提供所需數據。否則，客戶可能需要為每個請求調用多個API接口。
然而，我們選擇了一種完全不同的方法：直接將整個數據庫傳遞給客戶端。這樣一來，無需考慮消費服務的訪問模式，因為客戶端可以直接使用標準SQL查詢和連接來獲取所需數據。這正是我們使用LiteFS所實現的。
雖然我們可以將每個下游服務設置為Corrosion節點，但八卦協議可能會導致過多的通信開銷。而實際上，我們只需要單向的數據更新流。通過LiteFS設置只讀實例非常簡單，只需提供上游主節點的主機名即可完成連接。這樣，應用程序就能獲得完整的只讀數據庫副本。
此外，直接查詢服務通常需要應對多個租戶競爭計算資源的問題，例如速率限制和查詢超時。而通過向客戶端提供只讀數據庫副本，這些問題迎刃而解。客戶端可以自由使用自己的硬件資源，即使某個租戶消耗了大量CPU資源，也不會影響其他租戶的正常運行。
盡管只讀副本帶來了許多便利，但它也有一些限制和挑戰：
只讀限制
只讀副本無法進行數據更新。如果客戶端需要對數據進行修改，仍然需要通過API來完成。
數據庫約定的靈活性
與API相比，數據庫的約定可能不夠嚴格。API的一個優勢是可以隱藏底層數據庫結構的變化，而直接傳遞數據庫則需要客戶端適應這些變化。幸運的是，許多數據庫變更（例如添加新列）通常是向后兼容的，客戶端無需修改代碼。此外，可以通過數據庫視圖來重塑數據結構，確保數據的一致性。
訪問控制的限制
如果數據庫是多租戶的，直接傳遞數據庫可能會導致數據泄露風險。解決方案是為每個租戶創建獨立的數據庫。SQLite數據庫非常輕量化，因為它們只是磁盤上的文件。這種方法不僅提高了安全性，還能防止跨租戶的查詢錯誤。
雖然這種方法在內部工具中表現良好，但在更廣泛的軟件領域中，它的應用前景如何？API可能在未來仍然占據主導地位，但對于某些特定用例，提供只讀數據庫副本是非常有意義的。
想象一下，能夠直接從本地數據庫查詢所有的Stripe數據或GitHub數據。用戶可以將這些數據與自己的數據集結合起來，并在自己的硬件上快速執行查詢。這種靈活性和功能性對數據提供者和消費者來說都有巨大的吸引力。
例如，Stripe或GitHub可能會將租戶數據存儲在一個共享數據庫中，而許多公司則可以通過Kafka等工具運行事件總線，為每個租戶生成獨立的SQLite數據庫，并將其流式傳輸給客戶。
這種方式不僅提高了數據訪問的靈活性，還為數據消費者提供了更強大的功能支持。
通過LiteFS直接部署只讀數據庫副本，為服務之間的數據傳遞提供了一種全新的思路。雖然這種方法并不能完全取代API，但在特定場景下，它能夠顯著提升數據訪問的效率和靈活性。未來，隨著技術的不斷發展，這種模式或許會在更多領域中得到應用，為數據提供者和消費者帶來更多可能性。
原文鏈接: https://fly.io/blog/skip-the-api/