Day31-13｜10.6.2 大型网站系统架构演化实例（二）：垂直架构阶段的拆分与权衡

一、教材定位

大型网站从单体架构继续发展时，常见的第一步不是直接进入复杂的分布式微服务，而是按业务功能进行垂直拆分。垂直架构通常把原来集中在一个应用中的模块，拆成相对独立的业务应用，并为每个应用配置相对独立的数据库或数据访问边界。用户、商品、交易、支付、内容和后台等能力可以分别部署、扩展和发布。

垂直拆分解决的是单体架构中“所有功能绑定在一起”的问题，重点改善扩展粒度、发布影响范围和团队协作。但它并没有彻底解决跨应用调用、数据一致性、公共服务、重复建设和分布式运维问题。考试答题时要说明垂直架构是阶段性演化：它比单体更有边界和扩展能力，但仍可能存在应用内部复杂、跨应用数据共享和调用链增长等局限。

二、垂直架构的基本结构

在单体应用阶段，所有功能通常部署为一个应用并共享数据库。垂直拆分后，可以形成多个按业务组织的应用：用户中心负责注册和身份，商品中心负责商品和库存展示，交易中心负责购物车和订单，支付中心负责渠道和账务，内容中心负责文章和媒体，运营后台负责管理。

每个应用通常拥有自己的代码、部署单元和数据访问逻辑。应用之间通过接口、消息或共享基础设施协作。垂直架构不一定要求每个应用立即拥有完全独立的数据库，但必须逐步明确数据所有权，避免拆了应用却继续互相直接读写同一组表。

三、为什么选择垂直拆分

1. 业务边界相对清晰

用户、商品、订单和支付等能力具有不同业务职责、变化原因和质量目标，按业务拆分比按技术层拆分更容易形成责任边界。团队可以围绕业务能力组织开发和运维。

2. 资源需求不同

搜索和内容浏览可能需要高吞吐，支付和订单更重视一致性和审计，后台报表具有批量和低频特征。垂直拆分允许针对不同应用配置不同实例、缓存、数据库和扩展策略。

3. 降低发布互相阻塞

商品应用修改不必重新发布支付应用，后台功能变化不会自动影响用户交易。独立发布仍需要处理接口兼容和端到端回归，但影响范围比单体更可控。

4. 为后续演化建立边界

垂直应用是从单体走向服务化的重要过渡。经过一段时间运行，可以根据流量、变化频率和故障隔离需求，进一步将应用内部能力拆成更细的服务或模块。

四、垂直拆分的设计原则

1. 按业务能力而不是按技术层拆分

将所有控制器、服务和数据访问层分别拆开，并不能解决业务耦合，只是把原来的分层复制到多个应用。应围绕业务能力、数据所有权、变化原因和团队责任划分边界。

2. 明确数据所有权

每类核心数据要有权威系统和责任团队。其他应用通过接口、事件或只读数据副本访问，不能为了方便直接修改所有者的数据。共享数据库可以作为过渡，但必须有退出计划和访问监控。

3. 设计稳定接口

接口应表达业务能力和契约，不暴露内部表结构。要定义版本、错误、超时、幂等、权限和限流。接口变化需要兼容窗口，不能把垂直拆分变成新的发布耦合。

4. 区分同步和异步协作

用户需要即时结果的核心查询可以同步调用；通知、索引、报表和非核心联动可使用可靠消息。选择方式要结合一致性、延迟、失败恢复和用户体验。

5. 为跨应用流程设计补偿

订单、库存和支付分散后，不再由一个本地事务统一回滚。需要状态机、幂等、重试、补偿、对账和人工接管。不要把跨应用调用链当成普通函数调用处理。

五、垂直架构的收益

1. 独立扩展

热点应用可以单独扩容，避免整体扩展造成浪费。通过缓存、读写分离和专用存储，可以针对业务特征优化。

2. 故障隔离有所改善

某个非核心应用故障时，可以通过降级、缓存或异步队列减少对核心交易的影响。但如果所有应用仍共享数据库、消息平台或网络入口，隔离效果会受到限制。

3. 团队责任更清晰

每个业务应用有相对明确的所有者、发布流程和值班责任，有利于问题定位和持续改进。

4. 技术选择更灵活

不同应用可以根据需要使用不同的缓存、存储和计算模式，但要避免技术栈过多导致运维和人才成本失控。

六、垂直架构的局限

1. 跨应用调用增加

原来进程内调用变成网络调用，延迟、超时、重试、协议、认证和可观测性都需要设计。调用链变长后，局部故障可能影响整个业务流程。

2. 数据一致性变复杂

订单、库存、支付和用户数据分散后，跨应用事务难以依赖单一数据库。需要明确最终一致性、补偿和对账，不能简单复制数据而没有权威来源。

3. 重复基础能力

不同应用可能重复实现登录、日志、权限、配置和消息处理。可以建设公共平台，但公共平台本身不能成为新的强耦合单点。

4. 运维复杂度上升

应用数量、配置、发布流水线、监控和告警增加。若没有自动化部署、服务目录、链路追踪和统一审计，垂直拆分可能让问题更难排查。

5. 应用内部仍可能很复杂

垂直应用只是按业务粗粒度拆分，商品或交易应用内部仍可能包含很多模块和历史代码。后续是否细拆，需要根据实际瓶颈和团队能力决定。

七、垂直架构中的数据迁移

1. 识别数据和消费者

盘点表、字段、存储过程、报表、批任务和直接访问代码，找出谁读、谁写、谁依赖。数据迁移最怕遗漏隐式消费者。

2. 选择迁移方式

可以采用停机迁移、全量加增量同步、双写、双读、变更数据捕获和按租户切换。在线系统通常使用渐进迁移，保留旧路径作为回滚手段。

3. 建立对账和补偿

迁移后比较记录数、摘要、金额、状态和更新时间，发现差异后暂停扩大范围并修复。双写部分失败时，需要记录待补偿事件，不能依赖人工重新执行所有请求。

4. 撤销旧访问

新应用稳定后，逐步收回其他应用的数据库权限，删除旧代码和脚本。只迁移数据而保留所有旧权限，会使数据所有权仍然模糊。

八、垂直架构中的发布与运维

独立应用需要独立构建、测试、发布和回滚，但端到端业务仍然需要协同验证。接口契约测试保证消费者与生产者兼容，场景测试验证跨应用流程，灰度发布观察真实流量。

运维平台应提供服务目录、版本、负责人、依赖、实例、配置和告警视图。日志和链路要使用统一关联号，业务指标要能跨应用聚合。发布失败时既要回滚单个应用，也要评估已发送消息和已写入数据的业务影响。

九、案例分析：大型网站的垂直拆分

某网站单体应用包含商品、订单、支付、评论和后台功能。商品浏览占据大部分流量，订单和支付需要高可靠，评论和后台变化频繁。单体扩容成本高，发布经常互相阻塞。

第一阶段按业务垂直拆分：商品应用独立部署并使用缓存和搜索读模型，评论应用采用异步审核和独立存储，后台应用与用户端资源隔离，订单和支付暂时保持紧密协作以保护交易一致性。各应用通过接口和消息协作，逐步禁止直接访问他人数据。

拆分过程中重点设计商品和订单的关系。下单需要读取商品价格和库存，不能把商品数据库表直接暴露给订单应用；应通过商品快照、价格冻结和库存接口完成。支付结果通过幂等回调更新订单状态，通知和评论不阻塞支付。迁移后观察商品缓存命中率、订单成功率、跨应用延迟、数据差异、发布周期和故障影响范围。

如果拆分后订单调用链过长、数据库同步差异增加，说明边界或协作方式需要调整。垂直架构是演化阶段，不要求一步达到最终微服务形态。

十、综合知识练习

题1

垂直架构与单体架构相比主要改善了什么？

参考答案：按业务能力拆分部署、扩展和责任边界，降低发布相互阻塞，允许针对不同业务进行资源和技术优化，并为后续服务化演化建立边界。但它会引入网络调用、数据一致性和运维复杂度。

题2

垂直拆分后为什么不能继续让所有应用直接访问共享数据库？

参考答案：直接访问会破坏数据所有权，导致表结构和事务耦合、发布互相阻塞、隐式依赖和数据不一致，架构只是部署拆分而没有真正形成边界。共享数据库可以作为过渡，但必须监控和逐步退出。

题3

垂直架构的跨应用流程如何保证可靠性？

参考答案：明确同步和异步边界，使用接口契约、超时、重试、幂等、状态机、可靠消息、补偿、对账和人工接管，并通过链路追踪和业务指标验证最终结果。

十一、论文写作素材

论文中可以这样描述垂直架构演化：

“随着网站流量和业务模块增加，单体应用出现整体扩容、发布阻塞和故障相互影响问题。我按业务能力进行垂直拆分，分别建立商品、交易、支付、内容和后台应用，明确数据所有权和团队责任。商品和内容采用独立缓存、搜索和读模型，核心交易通过稳定接口和可靠消息协作，支付回调采用幂等状态机，跨应用结果通过对账和补偿保证一致。迁移阶段使用适配器、双读、灰度和权限收缩，监控跨应用延迟、数据差异、核心成功率和发布失败率，避免只完成部署拆分而没有实现真正的业务边界。”

十二、今日复盘

垂直架构是从单体走向分布式的重要阶段，核心是按业务能力拆分。
它改善扩展、发布和团队边界，但增加网络、数据一致性和运维复杂度。
数据所有权、接口契约、同步异步选择和补偿机制是关键。
共享数据库可以过渡使用，但必须监控、迁移和收回旧权限。
垂直拆分不是服务越多越好，应以业务目标和质量指标验证。
案例答题要体现“按业务拆分—建立契约—渐进迁移—对账验证”。