我的文档库基于 Cloudflare Workers 构建前端基础设施与可观测性平台
本文介绍一套基于 Cloudflare Workers 构建的前端基础设施平台，围绕数据采集、异步处理、性能监控、运行时配置和后台管理等能力，为前端应用提供统一的基础设施与可观测性支持。
本文介绍一套基于 Cloudflare Workers 构建的前端基础设施平台，围绕数据采集、异步处理、性能监控、运行时配置和后台管理等能力，为前端应用提供统一的基础设施与可观测性支持。
一、背景
随着前端应用规模不断增长，一些原本属于业务代码的能力逐渐变成了跨业务、跨应用的通用基础设施：
- 用户行为数据采集
- Web 性能监控
- 运行时配置管理
- 数据分析
- 后台管理
- 审计日志
- 静态资源同步
如果这些能力全部直接实现于主应用中，通常会产生几个问题：
- 基础设施代码与业务代码高度耦合
- 不同业务重复实现相同能力
- 数据采集与业务请求相互影响
- 数据处理逻辑难以独立扩展
- 性能监控缺乏统一的数据标准
- 后台管理与业务应用生命周期绑定
因此，我们将这些能力从业务应用中抽离，构建一套独立的前端基础设施平台。
本文将这套平台称为 Aether。
二、平台定位
Aether 并不是一个具体业务系统，而是一层位于：
Frontend Application
↓
Aether Platform
↓
Cloudflare Infrastructure之间的基础设施层。
业务应用主要负责：
UI
Business Logic
User Experience平台则负责：
Analytics
Performance
Configuration
Administration
Data Processing
Observability最终形成：
┌─────────────────────────────────┐
│ Frontend Applications │
│ │
│ Next.js / React / Other Apps │
└───────────────┬─────────────────┘
│
▼
┌─────────────────────────────────┐
│ Aether Platform │
│ │
│ Analytics │
│ Performance Monitoring │
│ Configuration │
│ Administration │
│ Data Processing │
└───────────────┬─────────────────┘
│
▼
┌─────────────────────────────────┐
│ Cloudflare Platform │
│ │
│ Workers / Queue / R2 / AE │
└─────────────────────────────────┘三、整体架构
平台采用多个独立服务组成：
Frontend
│
│ SDK
▼
┌─────────────────┐
│ Analytics Worker│
└────────┬────────┘
│
▼
┌──────────┐
│ Queue │
└────┬─────┘
│
┌─────────┴─────────┐
▼ ▼
┌─────┐ ┌──────────────┐
│ R2 │ │ Analytics │
│ │ │ Engine │
└──┬──┘ └──────┬───────┘
│ │
│ ▼
│ BI / Reports
│
┌────────┴────────┐
│ │
▼ ▼
Performance Admin BFF
Monitor │
▼
Admin SPA平台的核心数据链路可以概括为：
采集 → 接入 → 异步处理 → 持久化 → 分析 → 展示
四、为什么选择 Cloudflare Workers
这套平台并没有采用传统的：
Nginx
↓
Node.js
↓
Database
↓
Redis架构，而是大量使用 Cloudflare 的 Serverless 能力。
主要原因是平台中的服务天然具有事件驱动特征。
例如：
HTTP Request
Queue Message
Scheduled Event分别对应：
Worker
Queue Consumer
Cron Worker因此整个系统可以采用：
Event
↓
Serverless Function
↓
Storage / Queue的模型。
五、平台服务划分
目前可以将平台划分为以下几个核心模块：
| 模块 | 职责 |
|---|---|
| Analytics Worker | 接收前端埋点 |
| Browser SDK | 浏览器端数据采集 |
| Queue Consumer | 异步处理数据 |
| Performance Monitor | Web 性能监控 |
| Admin BFF | 后台管理 API |
| Admin SPA | 管理后台 |
| Storage Layer | 数据与配置持久化 |
各模块拥有相对独立的生命周期。
例如：
Browser SDK
│
│
▼
Analytics
│
▼
Queue
│
▼
Consumer性能监控则可以独立运行：
Cron
↓
Monitor
↓
Analytics
↓
R2后台管理也不需要与业务应用绑定：
Admin SPA
↓
Admin BFF
↓
Storage六、埋点系统
埋点系统是平台最核心的数据入口之一。
整体架构：
Browser
│
│ Event
▼
Browser SDK
│
▼
Analytics Worker
│
▼
Queue
│
▼
Consumer
│
├──────────────┐
▼ ▼
R2 Analytics Engine这里最重要的设计原则是：
浏览器负责采集，Worker 负责接入，Queue 负责解耦，Consumer 负责处理。
而不是让浏览器直接操作数据存储。
七、Browser SDK
前端 SDK 负责完成：
Event Collection
Device Identification
Buffering
Serialization
Transmission
Fallback例如：
track("page_view", {
page: "/home",
});SDK 内部负责将事件转换为统一的数据结构：
{
"event": "page_view",
"timestamp": 0,
"deviceId": "...",
"page": "/home"
}这样业务代码不需要关心：
- 数据格式
- 网络发送
- 重试
- 页面生命周期
- 浏览器兼容性
八、可靠的数据发送
浏览器存在一个特殊问题：
页面生命周期非常短。
用户可能：
- 关闭页面
- 切换标签页
- 网络断开
- 浏览器进入后台
因此普通：
fetch()并不总是适合作为页面生命周期结束时的数据发送机制。
SDK 优先使用：
sendBeacon失败后降级：
fetch + keepalive形成：
Event
│
▼
sendBeacon
│
├── Success → Done
│
└── Failed
│
▼
fetch keepalive这种设计能够提高页面关闭场景下的数据到达率。
九、异步数据处理
Worker 收到数据后，不直接执行复杂的数据处理。
而是：
Request
↓
Validation
↓
Queue
↓
Response消费者异步处理：
Queue
↓
Consumer
↓
Validate
↓
Transform
↓
Persist这种架构可以将：
用户请求延迟与数据处理耗时解耦。
十、为什么需要 Queue
假设某个活动突然产生大量访问：
100,000 Users
↓
Millions of Events如果所有请求都同步写入存储：
Request
↓
Parse
↓
Transform
↓
Storage
↓
Response大量并发会直接传递给后端。
引入 Queue 后：
Request
↓
Queue
↓
Response数据处理则变成：
Queue
↓
Consumer
↓
Batch
↓
StorageQueue 在这里承担：
- 流量削峰
- 异步处理
- 服务解耦
- 重试
- 提高吞吐
等职责。
十一、数据存储设计
平台采用两种不同类型的数据存储。
R2：长期数据
R2 用于保存：
Raw Events
Configuration
Audit Logs
Performance Snapshots
Historical Data其核心特点是：
对象存储 + 低成本 + 适合长期保存。
Analytics Engine：分析数据
Analytics Engine 更适合：
Aggregation
Metrics
Time Range Query
BI
Dashboard因此：
Event
│
▼
Queue
│
┌────────┴────────┐
▼ ▼
R2 Analytics Engine
│ │
│ ▼
│ Reports
│
▼
Historical Data两种存储承担不同职责。
十二、JSONL 数据格式
原始事件数据采用 JSON Lines 格式。
例如：
{"event":"page_view","timestamp":1000}
{"event":"click","timestamp":1100}
{"event":"exposure","timestamp":1200}每一行都是一个独立事件。
这种格式比较适合：
- 流式写入
- 批处理
- 日志分析
- 数据导入
- 文件合并
十三、数据 Compaction
大量埋点写入后会产生大量小对象：
raw/
├── 001.jsonl
├── 002.jsonl
├── 003.jsonl
├── 004.jsonl
└── ...如果长期保持这种状态，会增加对象数量以及后续处理成本。
因此平台增加定期 Compaction：
Small Objects
│
▼
Compaction
│
▼
Large JSONL例如：
001.jsonl
002.jsonl
003.jsonl
↓
compacted.jsonl最终形成：
写入阶段追求吞吐，读取阶段追求效率。
十四、Web 性能监控
性能监控负责采集真实用户环境下的 Web Performance 数据。
整体流程：
Browser
│
▼
Performance Metrics
│
▼
Analytics
│
▼
Performance Monitor
│
▼
R2
│
▼
Admin Dashboard监控服务不需要持续运行。
采用 Cron：
Cron
↓
Check Sampling Window
↓
Query Metrics
↓
Calculate Statistics
↓
Persist Snapshot这种设计可以降低持续运行带来的计算成本。
十五、为什么使用分位数
性能数据不能只看平均值。
例如：
100ms
120ms
130ms
150ms
5000ms平均值并不能完整描述真实用户体验。
因此监控系统应该同时关注：
Average
P50
P75
P90
P95
P99以及性能等级分布。
例如：
Performance
Good
████████████████
Needs Improvement
██████
Poor
██这样能够更好地观察长尾用户。
十六、异常数据处理
真实用户环境中会存在大量异常数据：
Network Failure
Background Tab
Device Suspension
Extreme Latency
Invalid Metric因此监控系统不能简单地将所有数据直接进行统计。
需要在计算阶段进行：
Validation
↓
Filtering
↓
Aggregation
↓
Percentile例如对于明显超出合理范围的性能数据，可以根据指标定义进行异常值过滤。
这里需要特别注意：
异常值处理应该基于指标定义，而不是简单删除所有“大值”。
十七、运行时配置
部分平台能力需要动态配置，例如：
Sampling Rate
Feature Configuration
Runtime Parameters
Monitoring Rules这些配置不应该全部硬编码在 Worker 中。
因此采用：
Admin
│
▼
Config API
│
▼
R2
│
▼
Worker
│
▼
In-memory CacheWorker 对配置进行短时间缓存，可以减少存储访问次数。
最终实现：
Dynamic Configuration
+
Low Read Cost
+
Simple Deployment十八、后台管理系统
管理后台采用：
React
+
Vite
+
UI Component System整体采用 SPA + BFF：
Admin SPA
│
▼
Admin BFF
│
├── Configuration
├── Accounts
├── Audit
├── Monitoring
└── Data后台前端不直接访问底层存储。
十九、为什么需要 BFF
如果 SPA 直接访问存储层：
Browser
↓
Storage会导致：
- 数据访问边界不清晰
- 权限控制困难
- 数据结构暴露
- 审计困难
- 业务逻辑散落在前端
因此采用：
Browser
↓
BFF
↓
StorageBFF 作为后台系统统一的数据访问边界。
二十、安全设计
平台的安全设计遵循：
客户端不可信，服务端负责建立真正的安全边界。
整体：
Browser
│
▼
HTTPS
│
▼
Worker
│
├── Authentication
├── Authorization
├── Validation
├── Signature Verification
│
▼
Storage客户端可以进行：
Encryption
Signing但这些机制不能替代服务端权限校验。
二十一、前端密钥问题
一个非常重要的前端安全原则：
打包进入 JavaScript Bundle 的内容，都不能被视为真正的 Secret。
例如：
VITE_*
NEXT_PUBLIC_*这类变量最终都可能出现在客户端代码中。
因此即使使用：
Minification
Obfuscation
Encryption也不能把它们当成真正的服务器密钥。
真正的安全边界应该放在：
Worker
│
├── Session
├── Authentication
└── Authorization二十二、数据访问边界
平台的数据访问可以统一抽象为：
┌─────────────┐
│ Browser │
└──────┬──────┘
│
▼
┌─────────────┐
│ Worker │
│ │
│ Auth │
│ Validate │
│ Transform │
└──────┬──────┘
│
┌─────────┴─────────┐
▼ ▼
R2 Analytics任何来自客户端的数据，都必须经过 Worker 的边界处理后才能进入内部数据层。
二十三、模块化部署
平台各服务可以独立部署：
┌───────────────────────────┐
│ Aether │
├───────────────────────────┤
│ │
│ Analytics │
│ Monitor │
│ Admin BFF │
│ Admin SPA │
│ Browser SDK │
│ │
└───────────────────────────┘这样可以实现：
Independent Development
Independent Deployment
Independent Scaling
Independent Failure Domain例如：
Analytics 更新
↓
不需要重新发布
↓
Admin
Monitor
SDK二十四、测试策略
基础设施平台的测试重点主要集中在数据链路和边界条件。
Analytics
Signature Validation
Invalid Payload
Replay Protection
Queue Retry
Consumer Idempotency
CompactionPerformance Monitor
Sampling Boundary
Metric Validation
Outlier Filtering
Aggregation
Cron Retry
IdempotencyAdmin
Authentication
Authorization
Session Expiration
Permission Guard
Mobile LayoutBrowser SDK
sendBeacon
fetch keepalive fallback
Network Failure
Device ID Fallback
SSR Environment
Page Lifecycle二十五、当前架构的局限
1. 单一存储依赖
如果多个核心能力都依赖同一个 R2 Bucket，那么存储层出现问题时可能影响多个服务。
后续可以针对关键数据增加：
Backup
Replication
Secondary Storage尤其是配置与审计数据，需要考虑更高等级的可靠性。
2. 浏览器数据并非绝对可靠
浏览器环境天然存在数据丢失可能。
例如：
Page Close
Network Failure
Browser Kill
Mobile Background如果业务对埋点完整性要求更高，可以增加持久化缓冲：
Memory
↓
IndexedDB
↓
sendBeacon
↓
Retry3. 大查询成本
随着数据量增长：
Raw Data
↓
Large Query
↓
High CPU / Latency因此更合理的方式是：
Raw Events
↓
Aggregation
↓
Precomputed Metrics
↓
Dashboard即：
尽可能使用预聚合数据，而不是每次打开后台都扫描大量原始数据。
二十六、设计原则
最终，这套平台可以归纳为五条核心原则。
1. Infrastructure First
将跨业务的通用能力从业务应用中抽离。
2. Async First
非实时任务尽可能异步化。
Request
↓
Queue
↓
Async Processing3. Data Decoupling
不同数据使用不同的存储能力：
R2
→ Historical / Raw Data
Analytics Engine
→ Metrics / Query
Queue
→ Buffer / Processing4. Security at Server Boundary
客户端永远不能作为真正的权限边界。
Client
→ Untrusted
Worker
→ Security Boundary
Storage
→ Internal Data Layer5. Observable by Default
基础设施自身也应该具备：
Logs
Metrics
Performance
Audit
Error Tracking否则基础设施最终会成为新的黑盒。
二十七、最终架构
经过模块化后，平台最终可以抽象成：
Frontend Applications
│
│ SDK
▼
┌──────────────────┐
│ Analytics Worker │
└────────┬─────────┘
│
▼
┌──────────┐
│ Queue │
└────┬─────┘
│
┌─────────┴─────────┐
▼ ▼
┌─────┐ ┌──────────────┐
│ R2 │ │ Analytics │
│ │ │ Engine │
└──┬──┘ └──────┬───────┘
│ │
│ ▼
│ BI / Reports
│
▼
┌────────────────┐
│ Monitor │
└───────┬────────┘
│
▼
Admin BFF
│
▼
Admin SPA整个系统形成了一条完整的数据闭环：
┌──────────────┐
│ Browser │
└──────┬───────┘
│
Collect
│
▼
┌──────────────┐
│ Worker │
└──────┬───────┘
│
Queue
│
▼
┌──────────────┐
│ Storage │
└──────┬───────┘
│
Analyze
│
▼
┌──────────────┐
│ Monitoring │
└──────┬───────┘
│
Report
│
▼
┌──────────────┐
│ Admin │
└──────────────┘二十八、总结
Aether 的核心并不是简单地组合几个 Cloudflare Worker，而是将前端应用中逐渐沉淀出来的通用能力进行基础设施化。
整个体系围绕：
Data Collection
+
Async Processing
+
Data Storage
+
Performance Monitoring
+
Runtime Configuration
+
Administration展开。
业务应用最终只需要关注：
Business Logic
UI
User Experience而平台统一提供：
Analytics
Performance
Configuration
Data Processing
Administration
Observability最终形成一层独立于具体业务的 Frontend Infrastructure Platform。
随着平台能力继续演进，还可以进一步扩展：
Real User Monitoring
Error Tracking
Feature Flag
A/B Testing
Edge Configuration
Release Management
Data Warehouse
Observability从而逐步形成面向现代 Web 应用的统一基础设施层。