EP 8：'ShopStream'的传奇：双架构的故事

Source: Dev.to

单体方法

为什么它有效

• 速度 – 同一模块中的函数可以直接调用另一个函数，无需网络延迟或 API 开销。
• 简洁 – 部署只需一个可执行文件；把它拖到服务器上并重启即可。
• 成本 – 运行在每月 5 美元的廉价虚拟机上。

教训

起初，单体是王者。对于创业公司或 MVP，交付速度胜过架构优雅。

单体的成长痛点

合并冲突地狱

当 支付团队 更新结账逻辑时，意外覆盖了 视频团队 的代码。

脆弱的玻璃效应

一名初级开发者在评论模块中写错了一个字符，导致内存泄漏，整个应用崩溃——用户既不能评论 也 不能购买。

扩展问题

在黑色星期五，视频流需要额外的 100 台服务器，而用户资料页只需要一台。由于应用是单体，整个系统必须复制 100 次，资源被浪费。

教训

单体在规模化时会遇到困难。大团队和不均衡的流量模式会让单一代码库成为瓶颈，并导致资源使用低效。

向微服务的转变

分手

架构师 Sasha 在六个月内剖析了单体：

• 将 支付逻辑 提取为独立服务并使用单独的数据库。
• 将 视频转码 隔离为独立服务。
• 将 库存系统 分离出来。

所有服务现在通过网络 API 进行通信，就像市场中的不同店铺。

为什么它有效

• 故障隔离 – 评论服务的崩溃不再导致视频或支付服务宕机；用户只会看到加载指示，但仍可观看和购买。
• 独立扩展 – 黑色星期五期间，支付服务自动扩展到 500 个实例，而用户资料保持两台。
• 技术自由 – 数据科学团队用 Python 构建推荐引擎，而核心后端仍使用 Java。

新挑战

• 调试变得更复杂；追踪一次请求现在涉及多个服务。
• 运维开销增加，需要专门的 DevOps 团队来管理 Kubernetes、Docker 容器和分布式追踪。

教训

微服务用运维复杂性换取开发简洁性。只有在规模真正需要时才应采用。

选择合适的架构

如果以下情况，继续使用单体

• 你是创业公司或小团队（10–20 人以下）。
• 你在构建新产品（MVP）。
• 你的业务领域简单。
• 你需要快速迭代和容易的调试。

如果以下情况，转向微服务

• 你是大型企业（Netflix、Uber、Amazon 级别）。
• 多个团队必须独立工作，互不阻塞。
• 应用的不同部分需要截然不同的扩展规模。
• 任意组件的故障不应导致整个系统宕机。

金科玉律

先从单体开始。 尽可能长时间保持单体。只有当管理单体的痛苦超过管理微服务的痛苦时，才将其拆分。