Signal：实时遥测平台

问题

数百万人在 100 多个国家和地区完成身份验证，其中有些人悄悄中途放弃。当某个供应商集成出现故障时，没人察觉：我们靠手动阅读零散的服务器日志，一次诊断要一到三天。这意味着每多一天，就有真实用户无法完成注册。

方案

• 小而有类型的 SDK。 一个 TypeScript 埋点库在 Web、移动端和 Mini Program 的每个界面上采集相同的用户行为数据，因此各处的事件含义一致。
• 节流，并带安全阀。 SDK 将事件排队，每 3 秒或累计 10 个事件时发送，以先到者为准。每次点击发一个请求会耗尽浏览器的网络线程；缓存太久又可能在标签页关闭时丢失事件。页面卸载时使用 navigator.sendBeacon。
• 会做校验的 BFF。 批量数据进入 Backend for Frontend，它依据 TypeScript 定义校验 schema、检查时间戳是否合理、剔除多余字段和个人身份信息（PII），并附上会话元数据和后端的判定结果（通过、拒绝、待人工审核）。把这个判定与界面显示的内容对比，就能发现界面与后端状态不一致的问题。
• Kafka、Flink、ClickHouse、Grafana。 Kafka 承接全球流量高峰，Flink 实时处理事件，ClickHouse 负责存储（列式存储能在毫秒内完成对数十亿条高基数事件的聚合，而行存储会慢得多），Grafana 展示各个漏斗。
• 安静的失败处理。 如果管道不可用，SDK 会在 localStorage 中最多保留 100 个事件，并由被动式熔断器暂停发送。它不会主动请求服务器检查健康状态，而是等待下一次成功响应。

结果

发现故障的时间从 24–72 小时缩短到 5 分钟以内。对于某个供应商环节一旦出错就会导致成千上万次注册失败的漏斗来说，这是“事后复盘里的一条记录”与“当天上午就修好”之间的差别。