系统设计：系统拆分

可视化演示

展示单体架构到微服务的拆分过程，通过滑块控制服务拆分粒度，实时观察耦合度、通信开销与一致性指标变化。

单体架构困境

小餐馆最初只有一位全能厨师：所有的菜谱、食材、收银都在他脑子里。顾客再多也只能一桌一桌做——不是因为他能力不行，而是所有事情缠在一起，任何一步都依赖其他步骤。软件世界的“全能厨师”就是单体架构（Monolith）：一个应用打包了所有业务模块，启动时全量加载，模块之间互相调用没有边界，专业说法叫“高耦合”。

单体的问题可以归结为三件事。第一，代码耦合：改一个支付模块，可能会影响到下单流程，回归测试必须全量跑一遍。第二，发布风险：任何小改动都要把整个系统重新打包上线，就像为了换一口锅要把整个厨房停业一天。第三，资源扩缩：只有下单功能流量大，却必须把整个系统一起扩容，白白浪费计算资源。

更本质的是，模块越多，彼此之间潜在的影响关系呈平方级增长。这个规律可以用沟通渠道数来量化：

就像餐馆老板每加一道新菜，都要重新核对它与所有旧菜的搭配禁忌——工作量逐年膨胀，直到某一天，你不得不按下“拆分”的开关。这就是单体架构在增长中必然走向拆分的根本原因。

拆分维度选择

餐馆扩店后，老板面临两个组织方案：按工种分（切菜组、炒菜组、甜品组），或者按菜系分（川菜档口、粤菜档口）。按工种分，人力可以复用，但一道菜从切配到上桌要跨组协作，沟通成本极高；按菜系分，一个团队能完整负责一道菜的备料、烹饪和出品，边界清晰。

软件拆分也有这两条主线：按功能拆和按领域拆（即 DDD 中的“限界上下文”）。按功能拆，就像把所有“切菜的”放在一起——代码结构好看了，业务上却是撕裂的，改一个订单功能要同时改好几个服务。按领域拆则是让订单域、支付域、库存域各自闭环，一个域内的修改不扩散到其他域。

业界更推荐按领域拆，因为领域边界就是业务边界。识别边界有一个很实用的量化手段——看“变更耦合度”：如果两个模块总是被同时修改，说明它们其实是同一件事，不该被拆开。

这里还藏着一个深刻的规律：康威定律——组织的沟通结构决定了系统的架构形状。就像餐馆老板如果把川菜和粤菜分给两个团队管，后厨自然会长出两个菜系档口。所以，拆分维度不是纯技术问题，先回答“团队怎么组织”，再回答“系统怎么拆”。

数据一致性保障

拆成多个档口后，最头疼的是食材账本。以前一个账本大家共用，谁都看得见；现在每个档口都有自己的小库房。如果川菜档口取走了冰箱里最后一块牛肉，粤菜档口不知道，就可能在同一天把同一块牛肉卖给两桌客人——这就是“数据不一致”。

软件里对应的是分布式事务难题：下单、扣库存、支付分属三个服务，原来单体里的本地数据库事务失效了。有人会想到“两阶段提交”（2PC）来强制一致，但它的代价就像要求所有档口同时举手确认才能开炒——只要一个档口网络抖动，整桌菜就要停摆，可用性大打折扣。

所以大多数业务场景改用最终一致性方案，最经典的是“本地消息表 + 消息队列 + 幂等消费”：订单服务把业务操作和消息写进同一个本地事务，然后异步把消息搬给库存、支付服务，发送失败就反复重试，消费端对同一个订单号去重。为什么我们要尽量避免跨服务的强一致？看这个连乘公式就明白了：

回到餐馆：账本不需要实时同步，每晚对一次总账完全可以接受——高峰期“库存先扣、支付稍后确认”，偶尔短时间对不上没关系。用“最终一致”换“高可用”，这才是分布式时代的账房哲学。

服务间通信协议

档口之间怎么协作？有两条路：让服务员跑腿传单，当面等对方回复——这叫同步调用，稳但慢；或者把菜单往传菜口一放，后厨自己来取——这叫异步消息，快但没法当场确认结果。两种方式各有各的用武之地。

软件里有三类主流通信方式。REST/HTTP + JSON：可读性好、跨语言通用，适合对外部开放的 API。RPC（如 gRPC）：走二进制序列化 + 长连接，体积小、性能高，适合内部服务间高频调用。消息队列（如 Kafka、RocketMQ）：生产者把消息扔进队列就走，消费者异步处理，适合削峰填谷和跨服务解耦。

选择的关键是理解同步与异步的权衡：同步链路实时性强，但延迟会逐跳叠加，适合查询类操作；异步吞吐高、不阻塞，但结果滞后、排查困难，适合事件通知和跨服务的写操作。调用链越长，越应该考虑异步化。网络延迟的叠加规律可以用一个简单的公式描述：

就像高峰期客人催菜，服务员跑腿传单的人越多，走廊越拥挤——这时候不如把点单往传菜口一放，后厨按优先级自己消化掉，前台也不用干等。异步消息牺牲一点实时性，换回的是整个系统的吞吐和平滑。

运维复杂度管理

档口多起来之后，老板发现管理成本反而涨了：新档口开张，客人怎么知道？今日菜单改了，怎么让所有档口同步知道？一道菜从下单到上桌，出了问题怎么知道是哪一步的锅？这三个问题，对应微服务的三大基础设施。

第一个问题靠服务注册与发现：新档口开张时，把自己的招牌挂到公告栏（注册中心），客人点餐时先看公告栏找到档口位置，档口歇业了自动摘牌。第二个问题靠配置中心：菜单统一由总厨下发，档口不用改火候设置、不用重启，配置热更新即时生效。第三个问题靠链路追踪：一张订单从下单到上桌，每个环节都盖一个带 traceId 的章，出了问题顺着章就能查到是哪一步。

此外还有故障隔离：一个档口着火了，要保证其他档口还能正常营业。实现手段是熔断、限流和舱壁隔离，调用某服务失败率达到阈值就熔断，不让故障像多米诺骨牌一样传遍全链路。为什么要这么较真？因为整体可用性是连乘的：

档口多了，老板必须把“挂招牌、发菜单、查流程”变成制度化工具，否则拆完的系统比单体还难伺候。这也是为什么成熟的微服务实践都强调：先建好可观测性和容灾能力，再动手拆分。

拆分评估与演进

是不是所有餐馆都该拆成十个档口？当然不是。一家只有三张桌子的小店，拆了反而亏钱——多出来的传菜流程和档口间的扯皮，比省下的那点人力还贵。老板要算一笔账：拆了之后，上菜速度真的快了吗？交付一道新菜的成本真的降了吗？

评估拆分的核心指标是交付周期（CT）：一个需求从提出到上线要多久。如果单体里发布一次要全量回归两周，CT 就极长；拆成独立服务后，每个团队只对自己的模块负责，CT 大幅缩短。这里有一个通用的定量工具——Little's Law：

具体怎么拆？业界推荐绞杀者模式：在旧系统旁边建一条新走廊，把单体的一条条业务按“领域走廊”逐步迁出，每迁出一个域就灰度验证，验证不过随时回滚。反过来，两个经典反模式要避开：一是“一步到位的大爆炸重构”，好比把厨房整个拆了重建，期间只能停业；二是“为了拆而拆”，把服务拆到十几个微服务，每个却只有几百行代码，纯粹给自己增加运维负担。

电商案例实战

把餐厅搬上线，就是电商系统。用户下单就像客人点菜：先看菜单（商品校验），再锁定食材（扣库存），最后结账（支付）。在单体时代，这一步用一个数据库事务就搞定了；拆成订单、库存、支付三个服务后，同一个流程要在网络上跑好几趟，任何一环失败都会造成“订单下了但没扣库存”或“库存扣了但没付钱”的尴尬。

拆分后的典型分工是这样的：订单服务创建订单，把“待扣库存”消息写进本地消息表；库存服务消费消息扣减库存，扣减失败就回滚订单并发起补偿；支付服务收到支付回调后幂等入账，同一个订单号重复回调只记一次。失败的流程用 SAGA 补偿事务处理：按逆序执行补偿操作，比如先取消订单、再释放库存，让系统回到一致状态。

很多人担心“重试会不会永远失败”？不会。只要单次调用的成功率稳定，重试足够多次后，最终成功率以指数级速度逼近 100%，这就是补偿和重试的底气和数学依据：

拆分前后的对比很直观：拆分前，大促时单体 CPU 打满，为了撑住流量只能把整个系统翻倍扩容，一次发布要全量停服半小时；拆分后，大促只需单独扩容订单和库存服务，发布互不干扰，某个服务出故障也有熔断和降级兜底。从“一个账本包打天下”到“本地消息表 + 重试 + 幂等 + 补偿”四件套兜底，看似绕了远路，实则每个服务都轻装上阵，系统在高并发下依然稳如老狗。

AI 应用场景

Python 演示

import random # 模拟"本地消息表 + 定时重试"方案:# 业务操作与消息在同一个本地事务中写入, 发送失败后持续重试,# 配合消费端幂等, 最终实现跨服务的最终一致性。class Outbox:    def __init__(self, success_rate):        self.rows = []        self.success_rate = success_rate        self.delivered = set()     def add(self, msg_id, business):        # 业务与消息同事务写入本地消息表        self.rows.append({"id": msg_id, "biz": business, "status": "pending"})     def deliver_once(self):        # 一轮发送尝试: 网络失败的消息留在表里等下一轮        for row in self.rows:            if row["status"] == "pending" and random.random() < self.success_rate:                row["status"] = "delivered"                self.delivered.add(row["id"])     def done(self):        return len(self.delivered) == len(self.rows)  def simulate(order_count, success_rate):    outbox = Outbox(success_rate)    for order_id in range(order_count):        outbox.add(order_id, "deduct_stock_and_pay")    rounds = 0    while not outbox.done() and rounds < 10000:        outbox.deliver_once()        rounds += 1    return rounds, len(outbox.delivered)  if __name__ == "__main__":    print("单次成功率\t重试轮数\t最终投递数")    for rate in (0.3, 0.6, 0.9):        rounds, delivered = simulate(50, rate)        print(f"{rate:.0%}\t\t{rounds}\t\t{delivered} / 50")

1. outbox.add(order_id, "deduct_stock_and_pay")模拟订单创建时，在同一“事务”里同时写入业务数据和待发消息，这是本地消息表的精髓。
2. def deliver_once(self)每一轮扫描消息表做发送尝试，失败的消息状态不变，留在表里等待下一轮。
3. while not outbox.done() and rounds < 10000无限重试直到全部投递完成，用轮数上限做安全阀，体现最终一致性。
4. for rate in (0.3, 0.6, 0.9)对比不同单次成功率，你会发现即使只有 30% 成功率，重试几十轮后 50 条消息依然全部送达。

常见误区

面试题