日志系统架构设计：从集中到分布式，UDP 扮演什么角色？

做日志系统，第一步不是选工具，而是想清楚架构。我见过太多团队一上来就搭 ELK，结果流量一上来直接崩掉。说白了，架构设计决定了你的系统能扛多大压力，出问题了能不能快速定位。

这一章，我们聊聊日志架构的演进、UDP 在其中的位置，以及怎么评估系统吞吐量。嗯，这些都是实战中绕不开的硬骨头。

集中式日志架构：简单，但有天花板

早期很多项目用集中式架构。所有应用把日志发到一台中心服务器，由它统一存储和检索。结构很简单：生产者 → 收集器 → 存储 → 展示。

但问题也很明显。我在一个创业公司时，业务量涨了 10 倍，单台服务器 CPU 直接打满，磁盘 IO 也扛不住。集中式架构的瓶颈在于：

• 单点故障——收集器挂了，所有日志都丢了
• 性能瓶颈——单机处理能力有限，吞吐量上不去
• 扩展困难——加机器？架构不支持横向扩展

你想想看，如果每天产生几十 TB 的日志，集中式架构根本玩不转。这时候就得考虑分布式了。

分布式日志架构：扛得住大规模

分布式架构的核心思想是「分而治之」。日志从多个源头发送，经过负载均衡分发到多个收集节点，再写入分布式存储。结构变成了：生产者 → 负载均衡 → 收集集群 → 存储集群 → 展示层。

我个人习惯把分布式日志架构分成三层：

1. 采集层——负责从应用、服务器、容器中抓取日志
2. 传输层——负责把日志从采集点送到存储系统
3. 存储与分析层——负责持久化、索引、检索和可视化

这里有个关键点：传输层用什么协议？TCP 还是 UDP？

UDP 在日志链路中的角色：快，但有代价

很多人觉得日志传输必须用 TCP，因为要保证不丢。但我在高并发场景下踩过坑——TCP 的拥塞控制和重传机制，在高吞吐日志场景下反而成了累赘。

UDP 在日志链路中扮演什么角色？说白了，就是牺牲可靠性换取速度。

在日志系统里，UDP 最适合的场景是实时监控和告警。比如你只需要知道 QPS 是否超过阈值，丢几条日志不影响判断。但如果是金融交易日志，那还是老老实实用 TCP。

系统吞吐量评估：别等上线了才发现扛不住

吞吐量评估是架构设计中最容易被忽视的一环。我见过太多项目，上线第一天日志系统就挂了。为什么？因为没算清楚流量。

评估吞吐量，我一般按以下步骤来：

1. 估算日志产生速率——每个应用每秒产生多少条日志？每条多大？
2. 计算峰值流量——业务高峰期是平时的几倍？
3. 评估网络带宽——UDP 发送能跑满带宽吗？会不会被限速？
4. 评估收集节点处理能力——单机能处理多少 QPS？
5. 评估存储写入能力——后端存储能扛住多少写入？

举个例子：假设你有 100 台应用服务器，每台每秒产生 1000 条日志，每条 1KB。那么每秒总数据量是：

100 台 × 1000 条/秒 × 1KB = 100MB/s ≈ 800Mbps

这个流量已经接近千兆网卡的极限了。如果使用 TCP，加上重传和头部开销，实际有效吞吐量会更低。而 UDP 因为无连接、无重传，能更充分地利用带宽。

系统吞吐量 = min(网络带宽, 收集节点处理能力, 存储写入能力)

架构对比：一张图看懂

下面这张图展示了集中式与分布式日志架构的核心差异，以及 UDP 在其中的位置。

从图上可以清楚看到：集中式架构所有流量打到一个点，而分布式架构通过负载均衡分散压力。UDP 在传输层扮演「快车道」的角色，适合对实时性要求高、可容忍少量丢失的场景。

如何选择？我的建议

没有银弹。选哪种架构、用 TCP 还是 UDP，取决于你的业务场景。

• 小团队、低流量——集中式 + TCP 就够了，别折腾
• 中等规模、对实时性有要求——分布式 + UDP 传输，收集层用 TCP 保证不丢
• 大规模、高并发——全分布式，UDP 用于采集层，TCP 用于关键链路

我曾经在一个日处理 10TB 日志的项目中，采集层全部用 UDP，传输层用 Kafka（基于 TCP），存储用 Elasticsearch 集群。这样既保证了采集性能，又保证了关键数据不丢失。嗯，这个方案跑了两年没出过大问题。