架构思维：拆分思想在高复杂度的业务后台系统中的价值

---

业务后台系统

1. 业务后台系统的定义与边界

我们以外卖系统为例，来说明业务后台系统

• 前台 vs. 后台：前台（iOS/Android/M 页/PC）负责与用户交互，展示内容；后台负责真正存储、处理和返回数据。
• 不含数据中台与算法中台：数据中台（BI、大数据）不直接对外部请求提供服务；算法研究仅负责模型调优，并由后台系统调用。

---

2. 基于“目的性”的三类后台系统

• 读业务（R）

  • 目的性：最大化“读”操作的可用性和性能，保障用户快速浏览与查询体验。
  • 举例：微博/知乎的浏览、新鲜事阅读、商品列表查询、短视频播放。

• 写业务（W）

  • 目的性：提供“101% 高可用”的写入能力，确保用户提交的订单、注册、评论等操作不丢失。
  • 举例：电商下单、外卖下单、打车请求。

• 扣减业务（D）

  • 目的性：在高并发下保障数据一致性与扣减准确性，防止超卖/超额扣减。
  • 举例：库存扣减、支付金额扣减、次数限制（如抢购、抽奖）。

3. 三类系统的技术关注点

业务类型	关键指标	典型技术手段
读业务	高性能、高可用	缓存（Redis/Memcached）、多副本、CDN、懒加载
写业务	绝对可用（101%）	分库分表、主备切换、异步补偿、降级限流
扣减业务	并发一致性、可用	乐观/悲观锁、分布式事务、流水线写入、令牌桶

---

“拆分”在架构降复杂度中的价值

1. 拆分的价值

• 将“大系统”划分为若干“小模块”，令每个团队聚焦单一职责、减少沟通与代码冲突成本；
• 降低系统耦合度，提高开发、测试与上线效率；
• 为后续的专题优化（性能、可用、并发）做好前提铺垫。

2. 何时该拆分

• 并行需求过多：代码分支冲突频发，合并耗时显著；
• 熟悉成本高：开发者在阅读代码上的时间远超编写时间；
• 上线协调复杂：每次发布需上百人同步评审和演练。

3. 拆分前提

• 团队组织：按模块分配足够小的团队（≈3–5人，“两比萨”法则）；
• 中间件与基础设施：RPC、监控、降级等要先行完善，避免拆分后引入新坑。

---

4. 拆分维度

• 业务流程垂直拆分（第一次）

• 按用户使用流程将系统切分为：用户、商品、促销、订单、支付、阅读等模块。

• 技术维度垂直拆分（第二次）
  

  • 在每个业务模块内，根据“读业务”、“写业务”、“扣减业务”特性再行拆分；
  • 例如用户模块→“用户读”＋“用户写”；支付模块→“额度查询”＋“支付扣减”。

• 共性度水平拆分（分层）

  • 将通用且稳定的部分（如数据访问、ORM 框架、SDK）抽离为“底层”模块；
  • “上层”易变模块保留业务逻辑，通过动态链接或打包方式复用底层组件，兼顾性能与复用性。

5. “微信读书”拆分实战

• 流程分析：注册登录→浏览书城→选书下单→支付→阅读；

• 第 1 次垂直拆分按业务流得出六大模块；
  

• 第 2 次垂直拆分在用户与支付模块内再细分为读/写/扣减子模块；

• 水平拆分将所有模块共用的数据访问逻辑抽象为“数据访问层”，编译为动态包（Java Jar、C/C++ .so），在业务模块中以依赖方式引入。

6. 注意事项与后续挑战

• 拆分带来分布式事务、链路跟踪、运维成本上升等新问题；
• 拆分粒度需结合团队规模与业务稳定度平衡，过细或过粗皆不可取；