以下是 Prisma 的 Pierre-Antoine Mills、Miguel Fernández 和 Petra Donka 撰寫的客座文章。Prisma 提供了一個伺服器端程式庫，可以幫助開發人員以直覺、高效、安全的方式讀寫資料到資料庫。
Prisma 的使命是重新定義開發人員建立資料驅動應用程式的方式。Prisma 的核心提供了一個開源的下一代 TypeScript 物件關係映射 (ORM) 庫，該程式庫憑藉其直覺的資料模型、遷移、類型安全性和自動完成功能，將開發人員體驗提升到了新的水平。
Prisma ORM 經歷了顯著的成長，吸引了充滿活力的開發者社群。雖然這是一個很大的問題，但這種成長導致我們的 AWS 基礎設施成本激增。在研究了廣泛的替代方案後，我們選擇了 Cloudflare 的R2 儲存- 結果令人興奮的是，我們的引擎分發成本降低了98%，同時提供了一流的性能。
這是天作之合：Prisma 已經是Cloudflare 引以為傲的技術合作夥伴，提供與 Cloudflare Workers 的深度資料庫整合。Cloudflare 產品為Prisma Accelerate和Prisma Pulse提供了許多底層基礎設施，從而支援以使用者為中心的產品開發。在這篇文章中，我們將深入探討如何決定將與 Cloudflare 的持續合作擴展到 Prisma ORM，以及如何在零停機的情況下從 AWS S3 + CloudFront 遷移到 Cloudflare R2。
發放 Prisma ORM 及其引擎
Prisma ORM 憑藉其類型安全的Prisma Client簡化了資料訪問，並透過Prisma CLI實現高效的資料庫管理，以便開發人員可以專注於產品開發。
Prisma 用戶端和 Prisma CLI 都依賴Prisma 引擎，後者以 Rust 實作並作為特定於平台的編譯二進位檔案分發。Prisma 引擎執行各種任務，從提供有關類型產生的架構資訊或遷移資料庫，到將 Prisma 查詢轉換為 SQL，以及對資料庫執行這些查詢。將引擎視為 Prisma ORM 中與資料庫對話層。
作為開發人員，開始使用Prisma 的第一步是從 npm 安裝Prisma 用戶端和Prisma CLI。安裝後，這些軟體包需要 Prisma 引擎才能運作。這些引擎具有複雜的目標平台規則，最初設想與 npm 套件分開分發，因此它們可以在 Node.js 生態系統之外使用。因此，它們由 Prisma CLI 按需下載，僅下載給定專案嚴格需要的內容。
截至 2023 年中期，這些引擎每月下載量為 1 億次，出口資料傳輸量為 250 TB，並且隨著用戶群的成長逐月持續成長。這凸顯了高度可用、全球性和可擴展的基礎設施的重要性，該基礎設施為世界各地的 Prisma 用戶提供低延遲引擎下載。
我們最初的解決方案：AWS S3 和 CloudFront
在 Prisma ORM 的早期開發過程中，我們的工程團隊尋找工具來建造用於引擎分發的 CDN。憑藉豐富的 AWS 經驗，我們選擇了顯而易見的方案：用於引擎檔案的 S3 blob 儲存和用於快取更靠近使用者的內容的 CloudFront。
我們對 AWS 非常滿意，它能夠根據我們的需求進行擴展。然而，隨著我們的用戶群不斷增長，成本也在不斷增長。在我們的流量規模下，資料傳輸成為一項相當大的成本項目，我們知道這種成本只會持續成長。
這些服務的成本不斷增加，促使我們探索替代方案，以更好地滿足我們的需求，同時至少保持相同水準的效能和可靠性。Prisma 致力於為我們的用戶提供最好的產品和解決方案，這項承諾的一個重要部分是有意識地分配我們的資源，包括合理的支出，使我們能夠以盡可能最好的方式為不斷增長的用戶群提供服務。
探索分發選項
我們廣泛探索了不同的技術和服務，以提供可靠、快速的引擎分配，同時具有成本效益。
免費解決方案：GitHub 和 npm
由於 Prisma ORM 是一個開源解決方案，因此我們探索了透過現有分銷管道免費分發引擎的各種方法。在這個領域，我們將 GitHub Releases 和 npm 作為託管和分發引擎文件的候選人。我們很早就放棄了 GitHub Releases，因為服務品質得不到保證，這是我們對使用者的要求，因此我們可以確保在任何情況下都能提供良好的開發人員體驗。
我們也查看了 npm，並確認託管引擎檔案將符合其服務條款。這使得 npm 成為一個可行的選擇，但也意味著我們必須更改引擎下載和上傳邏輯以適應不同的系統。此外，這意味著我們必須更新許多過去的 Prisma CLI 版本，要求我們的用戶升級才能利用新的解決方案。
付費解決方案：CDN 和 Cloudflare
然後我們考慮只取代 CloudFront，它占我們分發成本的 97%，同時保留 S3 作為來源。當我們評估不同的 CDN 時，我們發現替代方案可帶來估計 70% 的成本降低。
為了最終確定我們的決定，我們實施了一項測試來證實我們對 Cloudflare 服務品質的直覺。我們向全球 50 個城市部署了一個腳本，代表我們的傳入流量，以測量引擎檔案的下載延遲（約 15MB）。該測試運行了多次，記錄了不同快取狀態的延遲，並與我們先前基於 AWS 的解決方案進行了比較。結果證實，Cloudflare R2 的可靠性和效能至少與 AWS S3 + CloudFront 相當。由於 R2 與 S3 相容，因此我們無需對軟體進行重大更改即可遷移到 Cloudflare。這些都是很棒的結果，我們迫不及待想切換！
我們的解決方案：遷移到 Cloudflare 的 R2
為了將我們的引擎檔案分發轉移到 Cloudflare，我們需要確保能夠在不對使用者造成任何干擾或影響的情況下進行切換。
雖然 R2 URL 與 S3 的格式匹配，但 Prisma CLI 使用固定域來指向引擎文件分發。這個固定域使我們能夠在不對舊 Prisma 版本的程式碼進行任何更改的情況下進行過渡，只需將現有 URL 指向 R2。但是，為了進行轉換，我們需要更改 DNS 配置以指向 Cloudflare。雖然這看起來微不足道，但潛在的問題（例如意外的 DNS 傳播挑戰或透過 TLS 連線時的憑證驗證問題）要求我們提前規劃，以便自信、安全地進行。
我們修改了 Prisma ORM 發布管道以將資產上傳到 S3 和 R2，並使用R2 Super Slurper將過去的引擎版本遷移到 R2。這確保了過去和未來的所有 Prisma 版本都存在於這兩個地方。我們還建立了 Grafana 監控檢查，以從 R2 提取引擎文件，使用與我們所需的生產設置類似的 DNS 和 TLS 配置，但透過實驗域。這些監控檢查後來在最終流量切換期間重複使用，以確保服務不會中斷。
由於確保不會對使用者造成影響或中斷至關重要，因此我們使用 DNS 負載平衡（一種分配給網域的一組別名記錄採用不同權重的方法）逐步推出 DNS 變更。這表示 DNS 解析器會將更多流量定向到重量較大的記錄。我們首先使用模擬舊設定的負載平衡配置，其中一筆記錄（控制）指向 AWS CloudFront，另一筆記錄（候選）指向 R2。最初，所有權重都在控制上，有效地保留了到 CloudFront 的舊路由。我們也設定了盡可能低的 TTL，因此記錄權重的變更會盡快生效，以便更好地控制 DNS 傳播。此外，我們還實施了健康檢查，如果下載延遲明顯較高或檢測到錯誤，則將所有流量重定向到控件，從而確保穩定的回退。
至此，一切都已就緒，我們可以開始部署了。
首次推出時，R2 的 DNS 權重逐漸增加，我們的監控儀表板顯示 Cloudflare 下載量與分配給 R2 的權重成正比。正如預期的那樣，只有 5% 的流量路由到 Cloudflare，快取命中率接近 100%。延遲與控制相匹配，因此健康檢查一切正常，我們的後備從未啟動。在一個小時的時間內，我們逐漸增加了 R2 的 DNS 權重，以管理 25%、50%，最後 100% 的流量，沒有任何問題。切換過程再順利不過了。
經過兩天的額外監控，我們簡化了 DNS 拓撲並專門路由到 Cloudflare。我們對這項變更非常滿意，並開始看到我們的基礎設施成本大幅下降，正如預期的那樣，更不用說零停機時間和零報告的用戶問題。
成功
由於其出色的產品和工具、直覺的平台和支援團隊，遷移到 Cloudflare R2 非常容易。他們的服務為我們帶來了極好的體驗，始終如一的出色的正常運行時間、效能和延遲。Cloudflare 再次證明是幫助我們擴展規模的寶貴合作夥伴。
我們很高興我們的引擎分銷成本降低了 98%。Cloudflare 經濟高效的解決方案不僅提供了一流的效能，也為我們的營運帶來了顯著的節省。全面成功！
如果您想了解 Prisma 的實際應用，請從快速入門指南開始。