ACI.dev 的統一 MCP 伺服器僅透過一個 MCP 伺服器和兩個功能提供您的 AI 代理程式所需的每個 API。一次連線即可解鎖600 多個具有內建多租用戶驗證和自然語言權限範圍的整合。
- 即插即用－與框架無關，適用於任何架構。
- 安全性－為您的代理程式的最終使用者提供租戶隔離。
- 智能——動態意圖搜尋為每個任務找到正確的功能。
- 可靠——子 API 權限邊界，以提高代理程式的可靠性。
- 完全開源－後端、開發入口網站、函式庫、MCP 伺服器實作。
跳過數月的基礎設施管道工程；運送重要的代理功能。
然而，大規模收集有意義的分析結果不僅與儀表板有關，還與管道有關。
在 Canva，分析不僅是儀表板的工具，也是核心基礎設施的一部分。每個查看的設計、點擊的按鈕或載入的頁面都會轉換為一個事件。將其乘以數百個功能和數百萬個用戶，它變成了一條消防水帶：每天有 250 億個事件，正常運行時間為五個九。
要實現這種規模需要深思熟慮的設計選擇：嚴格的模式管理、批次壓縮、回退佇列以及將攝取與交付分開的路由器架構。
本文介紹了 Canva 如何建構、收集和分發每天數十億個事件，而不會陷入技術債和增加雲端費用。
他們的系統分為三個核心階段：
- 結構：定義嚴格的模式
- 收集：採集並豐富事件
- 分發：將事件路由到適當的目的地
讓我們詳細看看每個階段。
結構
大多數分析管道都是從考慮實施速度開始的，從而導致未記錄的類型和不相容的格式。它一直有效，直到有人問為什麼這個指標下降了，並且沒有令人滿意的答案。
Canva 從第一天起就鎖定了其分析模式，從而避免了這一陷阱。從頁面瀏覽到範本點擊的每個事件都遵循嚴格定義的 Protobuf 模式。
Canva 並未將模式視為事後才想到的事情，而是將其視為長期合約。每個分析事件都必須符合保證完全傳遞相容性的 Protobuf 模式：
- 向前相容：新消費者必須處理舊客戶端建立的事件。
- 向後相容：舊消費者必須處理來自新客戶端的事件。
不允許進行諸如刪除必填欄位或更改類型之類的重大變更。如果需要從根本上改變某些事情，工程師就會發布一個全新的模式版本。這使得多年的歷史資料可以訪問，並且分析查詢具有面向未來性。
為了自動執行這些模式規則，Canva 建構了 Datumgen：一個超越標準程式碼產生的協定頂層。
Datumgen 處理各種組件，例如：
- 前端的 TypeScript 定義，確保事件在編譯時進行類型檢查。
- 產生或使用分析的後端服務的 Java 定義。
- Snowflake 的 SQL 模式，因此資料倉儲始終知道傳入資料的形狀。
- Canva 的任何人都可以瀏覽即時事件目錄 UI，查看存在哪些事件、它們包含哪些欄位以及它們被路由到哪裡。
每個事件模式必須列出兩位人類所有者：
- 技術所有者：通常是編寫事件邏輯的工程師。
- 企業主：通常是了解事件如何對應到產品行為的資料科學家。
字段還必須包含清晰的、人工書寫的註釋，以解釋其含義和重要性。這些不僅對隊友有幫助。它們直接為 Snowflake 和事件目錄中顯示的文件提供支援。
收集
分析管道的最大挑戰不是收集一個事件，而是跨瀏覽器、設備和不穩定網路收集數十億個事件，而不會將攝取服務變成瓶頸或特定於平台的駭客攻擊的脆弱混亂。
Canva 的攝取層透過專注於兩件事來解決這個問題：統一的用戶端和非同步的、由 AWS Kinesis 支援的豐富管道。 Canva 沒有為 iOS、Android 和 Web 建置（和維護）單獨的分析 SDK，而是反其道而行：每個前端平台都使用相同的 TypeScript 分析客戶端，在 WebView shell 中運行。
僅使用薄的本機層來取得特定於平台的元數據，如裝置類型或作業系統版本。從事件結構到排隊到重試，其他一切都在一個共享程式碼庫中處理。
這在幾個關鍵方面帶來了回報：
- 工程師不必在三個地方修復錯誤。
- 模式定義在各個平台之間保持一致。
- 功能檢測保持統一，減少重複和漂移。
一旦事件離開客戶端，它們就會到達中央攝取端點。
在發生任何其他事情之前，都會根據預期模式檢查每個事件。如果不符合（例如，如果某個欄位缺失、格式錯誤或完全錯誤），則會立即被刪除。這種預先驗證可作為抵禦不良資料的防火牆。
然後，有效事件會被非同步推送到 Amazon Kinesis Data Streams (KDS)，後者充當管道其餘部分的提取緩衝區。
這裡的關鍵舉措是解耦：攝取端點不會阻塞豐富或下游交付。它可以快速驗證、快速排隊並繼續前進。這樣可以保持較低的反應時間，並將攝取延遲與下游複雜性隔離。
攝取工作器從初始 KDS 流中提取事件，並處理客戶端不能或不應該做的所有繁重工作，例如：
- 基於 IP 的地理位置豐富。
- 根據可用元資料進行設備指紋識別。
- 時間戳校正以修復時脈漂移或陳舊的客戶端緩衝區。
一旦事件豐富起來，它們就會被轉送到第二個 KDS 流，該流充當路由和分送層的交接。
這種分階段模型有兩大好處：
- 它將豐富邏輯與攝取路徑分開，防止緩慢的查找或第三方呼叫影響前端延遲。
- 它可以隔離故障。如果豐富失敗或滯後，它不會阻止新事件進入管道。
遞送
分析管道中常見的故障模式不是遺失數據，而是傳輸數據的速度太慢。當個人化引擎滯後、儀表板變空白或即時觸發器停滯時，通常會追溯到一個罪魁禍首：攝取和交付之間的緊密耦合。
Canva 透過乾淨地分割管道來避免這個陷阱。一旦事件豐富，它們就會流入解耦的路由器服務。
路由器服務位於豐富和消費之間。它的工作在理論上很簡單，但在實踐中至關重要：將每個事件送到正確的位置，而不讓任何消費者拖慢其他事件的速度。
工作原理如下：
- 從第二個 Kinesis 資料流 (KDS) 中提取豐富的事件。
- 將每個事件與程式碼中定義的路由配置進行比對。
- 將每個事件傳遞給訂閱該類型的下游消費者集。
為什麼要將路由與攝取工作者分開？因為將它們結合起來意味著：
- 緩慢的消費者會阻礙所有其他消費者。
- 一個系統中的模式不匹配會導致級聯重試。
- 擴展變得很痛苦，特別是當一些消費者想要即時交付而其他消費者每小時批量交付一次時。
Canva 將分析事件傳遞到幾個關鍵目的地，每個目的地針對不同的用例進行了最佳化：
- Snowflake（透過 Snowpipe Streaming）：儀表板、指標和 A/B 測試結果來自這裡。延遲並不重要。幾分鐘內的新鮮度就足夠了。然而，可靠性和模式穩定性非常重要。
- Kinesis：用於與個人化、推薦或使用情況追蹤服務相關的即時後端系統。 Kinesis 在這裡表現出色，因為它支援高吞吐量並行讀取、有狀態流處理和重播。
- SQS 佇列：非常適合僅關心少數事件類型的服務。 SQS 維護成本低且易於整合。
這種多目的地設定讓每個消費者可以選擇自己關心的權衡：速度、容量、簡單性或成本。
該平台保證「至少一次」交付。換句話說，一個事件可能會被傳遞多次，但永遠不會被悄悄丟棄。這意味著每個消費者都負責重複資料刪除，無論是使用冪等寫入、事件 ID 或視窗邏輯。
這種權衡利弊在於耐用性比純度更重要。在大型系統中，超額交付比因瞬態故障而導致永久性資料遺失的風險更便宜、更安全。
基礎設施成本最佳化
以下是該團隊如何在不犧牲可靠性或速度的情況下將基礎設施成本降低 20 倍以上的流程。
SQS + SNS
Canva 事件傳遞管道的 MVP 版本仰賴 AWS SQS 和 SNS：
- 易於設置。
- 自動縮放。
- 與現有服務順利整合。
但便利是有代價的。久而久之，SQS和SNS佔據了平台營運費用的80%。
這引發了串流媒體解決方案之間的爭論：
- Amazon MSK（Managed Kafka）降低了 40% 的成本，但帶來了巨大的營運開銷：代理、分區、儲存調整和 JVM 託管。
- Kinesis Data Streams (KDS) 並不是最快的，但它在簡單性、可擴展性和價格方面勝出。
數字讓決定變得簡單：與 SQS/SNS 堆疊相比，KDS 的成本降低了 85%，而延遲僅略有增加（增加了 10-20 毫秒）。該團隊進行了轉換並將成本削減了 20%。
先壓縮，再出貨
Kinesis 按容量收費，而不是按訊息數量收費。這使得壓縮成為節省成本的主要槓桿。 Canva 不會逐一觸發事件，而是執行一些關鍵最佳化，例如：
- 一次大量收集數百個事件。
- 使用 ZSTD 對其進行壓縮：一種快速、高比率的壓縮演算法。
- 將壓縮的 blob 推送到 KDS。
這一微小的轉變產生了巨大的影響。部分統計數據如下：
- 典型分析資料（往往是重複的）的壓縮率為 10 倍。
- 每批壓縮/解壓縮開銷約 100ms：流處理中的捨入誤差。
- 每年可節省 60 萬美元，且速度或準確性沒有明顯降低。
KDS尾部延遲
Kinesis 並不完美。雖然平均延遲保持在 7 毫秒左右，但尾部延遲可能會飆升至 500 毫秒以上，尤其是當分片接近其 1MB/秒的寫入限制時。
這對前端回應時間構成了威脅。等待 KDS 表示用戶也要等待。那是不行的。
修復方法是，每當 KDS 出現異常時，回退到 SQS：
- 如果寫入受到限製或延遲，則攝取服務將寫入 SQS。
- 即使在分片壓力下，這也可以使 p99 反應時間保持在 20 毫秒以下。
- 維護這個溢出緩衝區每月的費用不到 100 美元。
這種回退也充當了一種災難復原機制。如果 KDS 發生全面中斷，系統可以將整個事件流重新導向到 SQS，且不會造成停機。
結論
Canva 的事件收集管道是正確完成基本任務的一個很好的例子：嚴格的模式、解耦的服務、類型化的用戶端、智慧批次和優雅失敗的基礎設施。建築中沒有任何事物是經過廣泛實驗的，這就是重點。
當實際系統針對極端情況進行過度設計或針對規模進行設計不足時，就會崩潰。 Canva 的方法展示瞭如何走這條路：足夠的抽像以保持靈活性，足夠的紀律以保持安全性，足夠的簡單性以保持工程師的高效。
對於任何考慮擴展分析的團隊來說，經驗教訓就是建立可靠性、成本和長期清晰度。這就是將數十億事件轉化為可用見解的方法。
