分布式系统概述：什么是分布式系统

说实话，我第一次接触分布式系统时，脑子里就一个想法：这不就是把一堆机器连起来干活吗？后来被现实狠狠教育了一顿，才明白事情远没那么简单。

分布式系统，说白了就是一群独立的计算机，通过网络互相通信，对外表现得像一台超级计算机。你想想看，淘宝双十一的流量，单台机器根本扛不住。那就多搞几台，大家一起分担。这就是分布式最朴素的动机。

我个人习惯把分布式系统拆成三个核心要素来看：

• 多节点：至少两台机器，各自有独立的CPU、内存、硬盘
• 网络通信：节点之间靠网络交换数据，比如RPC、消息队列
• 统一对外：用户感知不到背后有多少台机器，只看到一个服务

举个例子，你用的微信。发一条消息，背后可能经过了接入层、逻辑层、存储层，每一层都有几十上百台机器在干活。但你感觉不到，对吧？这就是分布式系统的魅力。

分布式系统的挑战

嗯，这里要重点聊聊。我在项目中踩过的坑，十有八九都跟分布式系统的固有挑战有关。你以为多几台机器就万事大吉了？天真了。

1. 网络不可靠

这是最让人头疼的。两台机器之间发消息，可能丢包、可能延迟、可能乱序。我在一个金融项目里遇到过，A机器给B机器发了个转账指令，网络闪断了。B机器到底收没收到？A机器该不该重发？

这就是经典的「两将军问题」——你永远无法100%确认对方收到了你的消息。

2. 时钟不一致

每台机器都有自己的时钟，但它们的走时速度不一样。你想想看，A机器记录事件发生在10:00:00，B机器记录同一事件发生在10:00:01。到底哪个是对的？

我曾经排查过一个bug，日志里两个事件的时间戳差了3秒，但实际只差了200毫秒。查了半天，原来是两台机器的NTP同步周期不一样。

3. 部分失败

这是分布式系统最恶心的特性。单机系统里，要么成功要么失败，很干脆。但在分布式系统里，可能A成功了，B失败了，C还在跑。你怎么办？

我记得有一次线上事故，订单服务调用了三个下游服务，两个成功了，一个超时了。结果订单状态变成了「已支付未发货」，用户投诉了一整天。

4. 一致性难题

数据在多个节点上都有副本，怎么保证它们一模一样？CAP理论告诉我们，一致性、可用性、分区容忍性，三者只能选两个。

场景	选择	典型系统
银行转账	强一致性	传统数据库
社交动态	最终一致性	NoSQL
缓存	弱一致性	Redis

为什么需要日志与链路追踪

好，前面说了这么多分布式系统的坑，那怎么填坑呢？答案就是——可观测性。而可观测性的三大支柱，就是日志、指标、链路追踪。

日志：分布式系统的黑匣子

飞机上有黑匣子，记录飞行数据。分布式系统也需要黑匣子，那就是日志。每台机器、每个服务都在不停地写日志，记录自己干了什么。

但问题来了——日志太多了。一个中等规模的系统，一天能产生几个TB的日志。你不可能一台一台机器去翻日志。所以需要分布式日志采集，把分散在各处的日志集中起来，统一检索。

我个人习惯用ELK这套方案。Filebeat采集日志，Logstash做过滤和转换，Elasticsearch做存储和检索，Kibana做可视化。嗯，后面章节会详细讲。

链路追踪：还原请求的完整旅程

日志只能告诉你「发生了什么」，但没法告诉你「为什么发生」。比如一个请求超时了，日志里只看到超时异常。但到底是哪个环节慢了？是数据库查询慢？还是下游服务响应慢？

这时候就需要链路追踪。它给每个请求分配一个全局唯一的Trace ID，然后把这个请求经过的所有服务、每个服务的耗时都记录下来。你就能看到完整的调用链：

用户请求 → API网关(5ms) → 订单服务(120ms) → 库存服务(980ms) → 数据库(950ms)

看到没？瓶颈在数据库查询，花了950ms。这就是链路追踪的价值——一眼定位性能瓶颈。

日志 + 链路追踪 = 1+1 > 2

单独用日志，你只能看到局部。单独用链路追踪，你只能看到调用关系，看不到具体的业务数据。两者结合，才是完整的可观测性。

举个例子：链路追踪告诉你订单服务调用了支付服务，耗时2秒。但为什么耗时2秒？你需要去查支付服务的日志，看看是不是参数传错了，还是支付网关超时了。

说白了，链路追踪给你画了一张地图，日志给你提供了每个地点的详细信息。两者缺一不可。

小结

这一章我们聊了分布式系统是什么、有哪些坑、为什么需要日志和链路追踪。总结下来就三句话：

• 分布式系统让一堆机器协同工作，但引入了网络、时钟、部分失败等新问题
• 日志是分布式系统的黑匣子，帮你记录发生了什么
• 链路追踪是分布式系统的X光机，帮你看到请求的完整路径

下一章，我们会深入日志采集的具体技术方案。嗯，到时候我会分享一些我在生产环境踩过的坑，保证让你少走弯路。

---

公众号:蓝海资料掘金营，微信deep3321