在開發 SaaS 產品時，最困難的挑戰之一就是將技術上的用量（Usage）準確地轉化為財務上的帳單（Billing）。Atlassian 的 Forge 平台作為一個讓開發者為 Jira 和 Confluence 構建插件的 Serverless 擴展平台，面臨的是極高複雜度的計費需求。當計費模式從簡單的訂閱制轉向基於用量的定價（Usage-based Pricing）時，系統必須能追蹤函數調用次數、儲存空間消耗以及各種操作遙測數據。
對於初入行的工程師來說，這類系統的核心痛點在於分佈式環境下的數據一致性。當成千上萬個獨立服務在不同時間點發出用量訊號時，如何保證不漏算、不重複計算，且能正確歸屬到對應的客戶帳戶下，就是這套架構要解決的問題。
分佈式用量追蹤的整體流程
Forge 的計費架構將整個流程拆分為四個主要階段：事件發送、數據攝入與流轉、用量追蹤處理，以及最終的計費與商務系統。
首先是事件發送端。每個 Forge 服務在執行操作時，會根據一套共享的 Schema（結構定義）發出結構化事件。使用共享 Schema 非常重要，因為這能確保下游系統無論接收到哪個服務的數據，都能用統一的方式解析，避免因為每個服務定義不同而導致的對帳混亂。
接著是攝入與流轉層。Atlassian 使用了基於 Kafka 的串流基礎設施。Kafka 在這裡扮演了緩衝區的角色，將事件的產生者（Producer）與消費者（Consumer）解耦。這樣做的好處是，即使後端處理速度暫時跟不上，事件也會暫存在 Kafka 中而不會丟失，且各個組件可以根據壓力獨立擴展。
核心的神經中樞：UTS 追蹤服務
整個架構最關鍵的組件是 Usage Tracking Service，簡稱 UTS。如果把 Kafka 比作血管，UTS 就是處理數據的神經中樞。它的核心職責是將原始的技術事件轉化為具有財務意義的紀錄。
UTS 必須處理兩個核心挑戰：歸屬（Attribution）與形狀（Shape）。歸屬是指系統必須精確判定這筆用量屬於哪個租戶（Tenant）、哪個訂閱方案或哪個權限範圍。形狀則是指將各種雜亂的原始事件，標準化為符合計費合約的格式，以便下游的財務系統能直接讀取。
在 UTS 內部，會進行驗證、標準化、富化（Enrichment）以及去重處理。富化是指在原始事件中加入額外的上下文資訊，例如將用戶 ID 轉換為具體的訂閱方案等級。
解決分佈式系統的正確性問題
在分佈式系統中，網路延遲或重試機制經常導致事件亂序到達（Out-of-order）或重複發送。如果直接累加，會導致客戶被多收錢，造成嚴重的財務爭議。
為了達成財務級別的正確性，Atlassian 採取了兩種策略。第一是冪等設計（Idempotent Design），這意味著同一筆事件無論被處理多少次，結果都與處理一次相同，從而徹底消除重複計算。第二是時間窗處理（Windowed Processing），透過定義時間窗口來處理遲到的事件，確保在聚合數據時能將延遲到達的訊號補回。
數據存儲與可視化
處理完的數據會被分層存儲。長期存儲層採取不可變（Immutable）設計，這對於審計（Audit）至關重要，因為財務數據不能被隨意修改。而低延遲的分析層則用於驅動開發者儀表板，讓開發者能近乎即時地看到自己的用量消耗情況。
總結來說，這套架構的設計邏輯是：透過標準化 Schema 降低複雜度，利用 Kafka 實現高可用解耦，由 UTS 確保歸屬正確性，最後透過冪等性與時間窗來保障財務數據的絕對精準。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。