第3章 接通血脉：服务间通信

第3章 接通血脉：服务间通信

本章把镜头对准那台已经切开的商城：器官都分出来了，接下来要让它们"活"起来——服务之间到底怎么说话？同步还是异步？谁来当统一大门？这么多服务老是变来变去，客户端怎么知道找谁？这四件事，是"切得开"之后"活得起来"的总闸。

服务边界是静态的（上一章），通信是动态的（本章）。拆出来的服务犯的最大的错，是把它当回单体来调用——互相直接 class.func()、直接读对方数据库、把接口契约当摆设。通信没设计好，十几个服务只会变成"分布式的巨型单体"，比原来更难养。所以本章连着讲四关，一关卡一关。

一条主线

场景还是那台商城：用户点"下单"，一笔交易需要商品、库存、支付、积分多个服务配合。我们跟着这笔"下单"一起走——它先落到哪个关卡、用同步还是异步、要过几扇门、最终怎么把结果凑齐。走完你就懂了通信的取舍，而不是死记"同步 vs 异步哪个好"。

沿途站点

3.1 同步通信：REST 与 gRPC 双通道——讲清同步调用怎么用、什么场景要"立刻要结果"，以及 REST 和 gRPC 各自适合谁、什么时候别硬上同步。

3.2 异步通信：消息队列与事件驱动——讲清什么时候该"发出去就不管"，消息队列、事件流各自的玩法，以及解耦的另一面——你再也拿不到一个即时的调用结果，事情没做完怎么办。

3.3 API 网关：手术室的门禁与分流——讲清为什么客户端不该直连一堆服务，网关怎么干"路由、认证、限流、聚合"这几件杂活，以及网关本身的单点风险怎么化解。

3.4 服务发现：定位每个跳动的器官——讲清服务扩容、宕机、升级后地址漂移，客户端和网关怎么知道该找谁，注册中心 + 心跳是怎么工作的，以及注册中心本身挂了怎么办。

拐点与结论

本章最重要的认知转折是："同步好还是异步好"是个伪命题，真正的问题是"这个动作能容忍多久才要结果"。一个必须立刻给用户答复的动作，多半走同步；一个可以缓口气再处理的动作，多半走异步。把这个判断练顺了，网关怎么搭、要不要事件流都有了解答。这也是第 4 章"数据一致性"的地基——异步拿不到即时结果，才需要最终一致。

这一章最容易踩的三个坑

通信设计错了，服务拆得再好也是白拆。三个最常犯的错：

1. 把"同步/异步"当二元立场去站队。有人逢同步反对、逢异步彩旗飘飘，有人反过来。真正的尺子只有一个：这个动作能容忍多久才要结果。急着要结果就同步，能缓口气就异步，别带着喜好做技术判断。
2. 同步调用不配超时和重试。以为"反正会回来"就裸同步，结果上游一慢，下游线程池被占满，一个慢服务拖垮整条链。同步通信必须带超时兜底，这条在第 6 章还会再捶一遍。
3. 把网关塞成一坨"无所不能的大爆炸"。认证、路由、限流、聚合、业务逻辑全堆进网关，网关自己又成了那个没人敢动的单体。网关只该收口通用横切能力，业务逻辑留在各自服务里。

把这三道关想清楚再看站点，通信的取舍会顺很多。

读完你应该

• 判断一个业务动作该用同步还是异步，并说出理由
• 会用 REST 和 gRPC 各自的最佳场景，说明它们的分工
• 说清 API 网关收的"四件杂活"，并知道它的单点风险
• 解释服务注册与发现＋心跳的全过程
• 途经网关、发现、同步/异步把一笔跨服务下单完整走通

下一章的接力

通信通了，下一个绕不开的是数据。第 4 章我们把镜头沉到服务下面——每个服务说自己管一份自己的数据，那数据怎么拆、怎么保证最终一致、跨服务的查询怎么做。这几关在拆服务时最容易被低估，也是后面无数事故的源头。