簡化完整堆疊
今天是愚人節，儘管我們也希望像其他人一樣玩個痛快，但更希望利用這一天發佈嚴肅的公告。實際上，截至今天，有 200 多萬開發人員在 Cloudflare 的平台上進行構建，這可不是開玩笑！
在 Developer Week 活動週初始之際，我們針對以下三種產品撥動了重要的「生產就緒」開關：D1，這是我們的無伺服器 SQL 資料庫；Hyperdrive，可讓您的現有資料庫感覺是分佈式的（並且更快速！）；Workers Analytics Engine，這是我們的時間序列資料庫。
一段時間以來，我們始終致力於讓開發人員將整個堆疊移轉至 Cloudflare，但基於 Cloudflare 構建的應用程式可能是什麼樣子呢？
該圖表本身看起來與您已經熟悉的工具應該沒有太大的差異：您需要一個資料庫用於核心使用者資料；需要一個物件儲存體用於資產和使用者內容；可能需要一個佇列用於背景工作，如電子郵件或上傳處理；需要一個快速鍵值儲存，用於執行階段設定；甚至可能需要一個時間序列資料庫，用於彙整使用者事件和/或效能資料。這是我們使用 AI 之前的情況，而現在，在搜尋、建議和/或影像分析工作（至少！）中，AI 越來越成為很多應用程式的核心部分。
而且，想都不用想，此架構是在全球執行的，而這意味著可擴展、可靠和快速，並且全部現成可用。
D1 正式上市：生產就緒
您的核心資料庫是組成基礎架構的一個最關鍵部分。它需要超級可靠；它不能遺失資料；它必須能夠擴展。因此，在過去的一年中，我們專注於將這些部分部署到位，以確保 D1 生產就緒。現在，我們無比興奮地宣佈，我們的全球無伺服器 SQL 資料庫 D1 正式上市了。
D1 的 GA 版實現了一些最受歡迎的功能，包括：
- 支援 10GB 的資料庫，且每個帳戶可擁有 50,000 個資料庫；
- 全新的資料匯出功能；以及
- 增強的查詢偵錯功能（我們稱之為「D1 Insights」），它可讓您瞭解哪些查詢耗費最多時間和成本，或者哪些查詢完全低效……
……從而讓開發人員能夠使用 D1 構建生產就緒應用程式，來滿足所有關聯式 SQL 需求。重要的是，在一個「免費方案」或「業餘愛好方案」概念似乎面臨風險的時代，我們並不打算移除 D1 的免費方案，也不會減少每月 5 美元的 Workers Paid 方案中所包含的 250 億列讀取：
對於那些從一開始就在關注 D1 的使用者來說：正式版與我們在公開測試版中宣布的定價相同
但我們並不會止步於正式上市：我們還為 D1 規劃了一些重要的新功能，包括全球讀取複製、更大的資料庫、更多的 Time Travel 功能（可讓您建立資料庫分支）以及全新的 API（可用於動態查詢和/或從 Worker 內建立新的即時資料庫）。
D1 的讀取複製會根據需要自動部署讀取複本，從而讓資料更靠近使用者：並且您不必開發、管理擴展，也不會遇到一致性（複製滯後）問題。讓我們提前一覽 D1 即將推出的 Replication API 是什麼模樣：
export default {
async fetch(request: Request, env: Env) {
const {pathname} = new URL(request.url);
let resp = null;
let session = env.DB.withSession(token); // An optional commit token or mode
// Handle requests within the session.
if (pathname === "/api/orders/list") {
// This statement is a read query, so it will work against any
// replica that has a commit equal or later than `token`.
const { results } = await session.prepare("SELECT * FROM Orders");
resp = Response.json(results);
} else if (pathname === "/api/orders/add") {
order = await request.json();
// This statement is a write query, so D1 will send the query to
// the primary, which always has the latest commit token.
await session.prepare("INSERT INTO Orders VALUES (?, ?, ?)")
.bind(order.orderName, order.customer, order.value);
.run();
// In order for the application to be correct, this SELECT
// statement must see the results of the INSERT statement above.
//
// D1's new Session API keeps track of commit tokens for queries
// within the session and will ensure that we won't execute this
// query until whatever replica we're using has seen the results
// of the INSERT.
const { results } = await session.prepare("SELECT COUNT(*) FROM Orders")
.run();
resp = Response.json(results);
}
// Set the token so we can continue the session in another request.
resp.headers.set("x-d1-token", session.latestCommitToken);
return resp;
}
}
重要的是，我們將讓開發人員能夠維護基於工作階段的一致性，以便使用者不僅可以看到自己的變更情況，同時仍然受益於複製帶來的效能和延遲改進。
您可以閱讀我們的深入解讀貼文，進一步瞭解 D1 的讀取複製如何在後台運作，如果您要立即開始在 D1 上進行構建，請前往我們的開發人員文件，建立您的第一個資料庫。
Hyperdrive: 正式上市
在去年 9 月的生日週期間，我們發佈了 Hyperdrive 開放測試版，現在它已正式上市了，換言之，它經過實戰考驗並可用於生產環境了。
如果您尚不瞭解 Hyperdrive 是什麼，那麼請允許我快速介紹一下，這款產品旨在讓您現有的集中式資料庫給人全球化的感覺。我們使用自己的全球網路，可以更快地路由至您的資料庫，確保連線集區準備就緒，並在盡可能靠近使用者的位置快取最經常執行的查詢。
重要的是，Hyperdrive 原生支援最熱門的驅動程式和 ORM（物件關係對應程式）庫，因此您無需重新學習或重新撰寫查詢：
// Use the popular 'pg' driver? Easy. Hyperdrive just exposes a connection string
// to your Worker.
const client = new Client({ connectionString: env.HYPERDRIVE.connectionString });
await client.connect();
// Prefer using an ORM like Drizzle? Use it with Hyperdrive too.
// https://orm.drizzle.team/docs/get-started-postgresql#node-postgres
const client = new Client({ connectionString: env.HYPERDRIVE.connectionString });
await client.connect();
const db = drizzle(client);
但有關 Hyperdrive 的工作並不會因正式上市而停下來。在接下來的幾個月中，我們將為另一個部署最廣泛的資料庫引擎提供支援：MySQL。我們還將透過 Cloudflare Tunnel 和 Magic WAN，支援連線至私人網路（包括雲端 VPC 網路）內的資料庫。除此之外，我們還計劃為無效判定和快取策略提供更多的可設定性，以便您能夠針對效能與資料新鮮度做出更精細的決策。
當我們思考如何為 Hyperdrive 定價時，我們意識到，對它收費似乎不太合適。畢竟，Hyperdrive 不僅具有顯著的效能優勢，而且對連線至傳統的資料庫引擎至關重要。如果沒有 Hyperdrive，每次請求需要 6 次以上往返來連線和查詢資料庫，支付這筆延遲開支是不合理的。
因此，我們很高興地宣佈，對於採用 Workers Paid 方案的任何開發人員，免費提供 Hyperdrive。這不僅包括查詢快取和連線共用，還包括建立多個 Hyperdrive 的能力，這可用於分隔不同的應用程式（生產與暫存）或提供不同的設定（例如，快取與未快取）。
若要開始使用 Hyperdrive，請前往文件，瞭解如何連線現有的資料庫並從 Workers 開始查詢。
Queues: 隨時隨地提取
工作佇列在構建現代、完整堆疊應用程式方面發揮著越來越重要的作用，這也是我們最初推出 Queues 公開測試版時所考慮的因素。此後，我們一直致力於打造數種主要的 Queues 功能，本週我們將推出其中兩種：提取式取用者和全新的訊息傳遞控制。
任何 HTTP 語音用戶端現在都可從佇列中提取訊息：呼叫佇列上的新 /pull 端點來請求一批訊息，並在您成功處理它們時呼叫 /ack 端點來確認每條訊息（或一批訊息）
// Pull and acknowledge messages from a Queue using any HTTP client
$ curl "https://api.cloudflare.com/client/v4/accounts/${CF_ACCOUNT_ID}/queues/${QUEUE_ID}/messages/pull" -X POST --data '{"visibilityTimeout":10000,"batchSize":100}}' \
-H "Authorization: Bearer ${QUEUES_TOKEN}" \
-H "Content-Type:application/json"
// Ack the messages you processed successfully; mark others to be retried.
$ curl "https://api.cloudflare.com/client/v4/accounts/${CF_ACCOUNT_ID}/queues/${QUEUE_ID}/messages/ack" -X POST --data '{"acks":["lease-id-1", "lease-id-2"],"retries":["lease-id-100"]}' \
-H "Authorization: Bearer ${QUEUES_TOKEN}" \
-H "Content-Type:application/json"
提取式取用者可在任何位置執行，讓您能夠同時執行佇列取用者以及現有的傳統雲端基礎架構。Cloudflare 內部的團隊很早就採用了這種方式，其中一個使用案例是從我們 310 多個資料中心將裝置遙測寫入至佇列，並在執行於 Kubernetes 之上的部分後台基礎架構內取用。重要的是，我們的全球分散式佇列基礎架構意味著訊息保留在佇列內，直到取用者準備好處理它們。
Queues 現在也支援延遲訊息，這同時涵蓋傳送至佇列和標記訊息進行重試。這可能對未來的佇列工作很有用，如果上游 API 或基礎架構的限速要求您調整處理訊息的速度，則也可用於套用輪詢機制。
// Apply a delay to a message when sending it
await env.YOUR_QUEUE.send(msg, { delaySeconds: 3600 })
// Delay a message (or a batch of messages) when marking it for retry
for (const msg of batch.messages) {
msg.retry({delaySeconds: 300})
}
在接下來的幾個月，我們也會大幅提高每個佇列的輸送量，來推動 Queues 正式上市。對我們而言，Queues 的高度可靠性極為重要：如果郵件遺失或被捨棄，則意味著使用者不會收到訂單確認電子郵件、密碼重設通知及/或處理的上傳數，每種情況都會影響使用者，且很難恢復。
Workers Analytics Engine 已正式上市
Workers Analytics Engine 透過一個內建 API 從 Workers 寫入資料點，並透過一個 SQL API 查詢該資料，從而提供大規模的無限基數分析。
Workers Analytics Engine 由基於 ClickHouse 的系統提供支援，我們 Cloudflare 多年來也依賴於該系統。我們用它來觀察自身服務的運作狀況，擷取產品使用資料進行計費，並回答有關具體客戶使用模式的問題。幾乎每次向 Cloudflare 的網路發出請求時，都會向此系統寫入至少一個資料點。Workers Analytics Engine 讓您使用相同的基礎架構構建自己的自訂分析，同時，我們會幫您管理最困難的部分。
自推出測試版以來，開發人員開始依賴 Workers Analytics Engine 來處理這些使用案例以及更多其他使用案例，從大型企業到開放原始碼專案（如 Counterscale）。多年來，Workers Analytics Engine 一直以生產規模運作，處理任務關鍵型工作負載，但直到今天，我們從未分享過任何有關定價的資訊。
我們的 Workers Analytics Engine 定價非常簡單，基於以下兩個指標：
- 寫入的資料點數： 每次在 Worker 中呼叫 writeDataPoint() 時，都會算作寫入了一個資料點。每個資料點的成本是相同的，與其他平台不同，新增維度或基數不會帶來額外成本，並且無需預測壓縮資料點的可能大小和成本。
- 讀取的查詢數：每次發佈到 Workers Analytics Engine SQL API，都會算作讀取了一次查詢。每次查詢的成本是相同的，與其他平台不同，查詢複雜性不會帶來額外成本，並且無需對每次查詢讀取的資料列數進行推理。
Workers Free 方案和 Workers Paid 方案都包含寫入資料點數和讀取查詢數的配額，額外使用量的定價如下：
採用此定價，您可以透過計算在 Worker 中呼叫函數的次數以及向 HTTP API 端點發出請求的次數，來回答「Workers Analytics Engine 將花費多少錢？」這一問題。這是用紙筆就可計算出來的簡單數學題，甚至用不上試算表。
此定價將在幾個月後向所有人提供。在此之前，Workers Analytics Engine 會繼續免費提供。您可以立即開始從 Worker 寫入資料點——只需幾分鐘的時間和不到 10 行程式碼，即可開始擷取資料。我們很樂意聽取您的想法！
本週才剛剛開始
明天是 Developer Week 的第二天，敬請期待我們為您準備的內容。如果您有問題或想要展示已經構建完成的好東西，請加入我們的開發人員 Discord。