Day33-04｜14.2.3 主要架构模式：云原生场景下的结构选择与权衡

一、教材定位与学习目标

14.2.3“主要架构模式”是云原生架构由原则进入具体结构的部分。架构模式不是可以机械套用的模板，而是针对一类重复出现的问题形成的、经过验证的结构化解决方案。高级系统架构设计师考试往往给出业务规模、流量特征、团队能力、数据一致性和部署环境，要求考生选择或组合合适的架构模式，并说明为什么这样选择。

本节学习重点不是记住“微服务、事件驱动、无服务器”这些名词，而是掌握模式选型的判断依据：

业务变化 + 质量属性 + 团队能力 + 运行环境
                     ↓
                架构模式选择
                     ↓
          边界、通信、数据和治理设计

学习完成后，应能够：

1. 说明模块化单体、微服务、事件驱动、无服务器和云边协同等模式的基本结构。
2. 从可维护性、弹性、性能、可靠性、成本和复杂度角度比较不同模式。
3. 识别多种模式组合使用时的边界和风险。
4. 在案例题中给出“问题—模式—措施—权衡—验证”的完整答案。

二、模式选型前先看问题，而不是先看产品

同一种业务可以采用不同模式。例如一个订单平台可以采用模块化单体，也可以拆成微服务；报表任务可以部署为定时作业，也可以采用事件驱动函数；工厂设备可以直接连接云端，也可以通过边缘节点先处理。没有脱离上下文的“最佳模式”。

选型时至少考察以下维度：

如果题目只要求内部管理系统、访问量稳定、团队规模小，模块化单体通常更稳妥；如果题目强调多个团队独立发布、模块负载差异大和故障隔离，微服务更有理由；如果题目强调事件异步、峰值削峰和松耦合，事件驱动更合适；如果任务短小、触发不规律、运维资源有限，可以考虑无服务器。

三、模块化单体模式

3.1 基本结构

模块化单体把多个业务模块部署为一个应用单元，但在代码、接口、数据访问和依赖方向上保持清晰边界。模块之间通过内部接口或领域事件协作，禁止随意访问其他模块的内部对象和数据表。

一个部署单元
├── 会员模块
├── 商品模块
├── 订单模块
├── 库存模块
└── 支付模块
   每个模块拥有明确接口和职责，内部可独立测试

模块化单体可以使用容器、自动化流水线、外部配置、托管数据库和可观测平台，因此它并不等于传统的混乱单体，也不排斥云原生实践。

3.2 优点与局限

优点是调用简单、事务边界容易管理、部署对象少、调试成本低，适合业务边界尚未稳定、团队规模较小或系统规模中等的场景。局限是所有模块共享发布单元和运行资源，一个模块出现问题可能影响整体；不同模块难以独立扩缩和采用不同技术栈。

3.3 适用判断

如果系统目前最主要的问题是代码耦合，而不是独立扩展和故障隔离，那么先做模块化单体往往比直接微服务化更有价值。模块化单体还可以作为未来拆分的过渡形态，但前提是模块边界和接口真的得到执行，而不是仅仅把目录重新命名。

四、微服务架构模式

4.1 基本结构

微服务按照业务能力拆分为多个可独立构建、部署和运行的服务。服务通过同步 API 或异步消息通信，各自拥有相对明确的数据责任和技术边界。

客户端 → API 网关 → 商品服务
                     ↓
             订单服务 → 库存服务
                     ↓        ↓
                  支付服务  消息服务

网关可以承担路由、认证、限流和协议适配，但不能承载所有业务逻辑。服务治理平台通常还需要提供服务发现、配置、熔断、监控、日志和发布能力。

4.2 微服务的收益

服务可以按照业务负载独立扩展，团队可以独立发布，局部故障可以在一定程度上隔离，技术栈也能在明确边界内选择。对于大型团队和复杂业务，这些收益可以显著提高交付效率和系统可演进性。

4.3 微服务的代价

进程内调用变成网络调用后，延迟、超时、重试和部分失败变得普遍；本地事务变成分布式一致性问题；服务数量增加后，配置、证书、版本、日志和追踪都需要治理；数据库拆分和数据所有权不清会造成跨服务联表和强耦合。

因此，微服务模式的完整答案必须包括通信治理、数据一致性、服务发现、版本兼容、故障隔离和可观测性。只写“拆分为若干微服务并使用容器部署”，不能体现高级架构设计能力。

五、事件驱动架构模式

5.1 基本思想

事件驱动架构由事件生产者、事件通道和事件消费者组成。生产者发布“订单已创建”“支付已完成”“设备状态变化”等事实，消费者根据自身职责订阅并处理。生产者不需要同步知道所有消费者，有利于解耦和异步扩展。

生产者 → 事件总线/消息队列 → 消费者A：库存
                          → 消费者B：通知
                          → 消费者C：积分

事件应描述已经发生的事实，而不是把远程调用命令简单改名。事件契约需要包括事件编号、产生时间、主体、版本、关联业务单号和必要的业务数据，并规定重复、乱序、延迟和失败处理方式。

5.2 优点与风险

事件驱动可以削峰填谷、异步解耦、支持多个消费者独立演进，并适合审计和事件历史。但系统行为变得间接，调用链和数据状态不容易立即观察；消息可能重复、乱序或积压；消费者失败后需要重试、死信和补偿；跨消费者的数据最终一致性需要业务接受。

5.3 适用场景

订单后续通知、积分、物流同步、日志分析、设备遥测和报表汇总都适合事件驱动。对必须立即返回结果且强一致的核心校验，不应盲目异步化。可以采用同步完成核心决策、异步发布后续事件的混合方式。

六、无服务器架构模式

6.1 基本概念

无服务器模式把服务器管理、容量配置和运行时调度更多地交给平台，开发者以函数、任务或托管服务的方式提交业务逻辑。函数通常由 HTTP 请求、消息、定时器、文件上传或数据库变更触发，平台按调用量或执行资源提供弹性。

6.2 优势

无服务器适合调用不规律、任务短小、事件触发明显的业务。它可以减少服务器运维、按量计费、快速扩展，并适合图片处理、通知分发、数据清洗和自动化任务。

6.3 限制

函数可能存在冷启动，执行时间、内存和并发受到平台约束；本地文件和进程内状态不适合长期保存；复杂调试、版本治理、跨函数事务和供应商迁移可能更困难。函数数量过多也会形成新的分布式系统，需要统一日志、追踪、权限和依赖治理。

无服务器并不意味着没有服务器，也不意味着不需要架构设计。架构师仍然需要设计触发关系、幂等、重试、权限、数据一致性、成本上限和失败补偿。

七、云边协同架构模式

7.1 基本结构

云边协同把云端的集中管理、全局分析和资源能力，与边缘节点的低时延、数据就近处理和断网自治结合起来。边缘节点可以是工厂网关、门店设备、园区节点或车载计算单元。

终端设备 → 边缘节点：采集、过滤、控制、缓存
                ↓ 上行摘要/事件
              云平台：全局管理、模型训练、分析、策略下发

7.2 为什么需要边缘

当网络延迟、带宽、数据隐私或现场连续运行要求较高时，所有数据都上传云端再决策可能不可行。边缘可以过滤冗余数据、就近执行实时控制、在断网时暂存并继续提供有限服务。云端则适合跨区域管理、长期存储、全局优化和统一运维。

7.3 云边协同的难点

需要解决云边版本一致、策略下发、设备身份、断网缓存、时钟同步、数据冲突和远程升级问题。边缘节点的资源和安全能力通常弱于云端，必须限制权限、加密存储、建立远程审计和回滚机制。题目中出现“低时延、网络不稳定、现场自治、集中管理”时，应优先考虑云边协同，而不是只写云端微服务。

八、混合架构与模式组合

真实系统往往组合多个模式。例如：

组合模式时必须明确交界处：同步链路到哪里结束，事件从哪里产生，谁拥有数据，哪个状态是权威，失败如何补偿，统一平台如何治理。模式越多，越需要架构约束和可观测性，否则系统会变成技术拼盘。

九、模式选型的质量属性权衡

9.1 可维护性与复杂度

模块化单体的运行复杂度较低，微服务和事件驱动的独立演进能力较强，但治理成本也高。团队没有相应平台和经验时，复杂模式可能降低而不是提升可维护性。

9.2 性能与弹性

微服务和无服务器可以按业务负载扩展，事件驱动可以削峰，但跨网络调用和消息传递会增加延迟。低延迟核心路径应减少不必要的同步跳转，异步化要配合用户体验和业务状态展示。

9.3 一致性与可用性

事件驱动和云边协同经常采用最终一致性，以换取可用性和断网自治。若业务要求强一致，应缩小事务边界，或通过预留、状态机、补偿和对账建立可接受的一致性保证。不能在答案中同时承诺“全链路强一致、跨地域高可用、无限扩展和零延迟”，而不解释代价。

9.4 成本与供应商风险

无服务器按量计费，适合低频任务，但高频稳定负载下未必成本最低；托管服务可以降低运维成本，也可能带来接口绑定和迁移成本。架构师应从全生命周期成本、人员成本、故障成本和迁移成本综合评估。

十、案例分析：物流平台的模式组合

某物流平台包含订单、轨迹、计费、客服和设备定位功能。订单和计费要求准确，轨迹数据量大，车辆网络可能中断，客服查询流量不稳定，平台还要求降低基础设施运维投入。

可以采用组合模式：订单和计费先采用模块化或边界清晰的服务，使用关系数据库和明确事务；车辆定位采用云边协同，边缘节点在本地采集和缓存，网络恢复后上传事件；轨迹处理采用事件驱动，把位置事件送入消息通道，分别供实时轨迹、历史分析和告警消费者使用；客服查询采用独立查询服务和缓存，按流量弹性扩展；低频的文件转换和通知任务采用无服务器函数。

关键治理措施包括：定位事件使用设备编号和序列号幂等，订单和计费使用业务状态机，消息设置分区、重试和死信，边缘节点进行证书认证和远程升级，所有模式统一接入指标、日志、追踪和权限平台。这样既利用了不同模式的优势，也避免把所有功能强行套成同一种架构。

十一、课后练习

练习一：选择题

下列哪种情况更适合优先采用模块化单体？

A. 业务边界稳定，多个团队需独立发布且模块负载差异很大

B. 团队规模小，业务仍在快速探索，流量稳定且需要简化事务管理

C. 设备分布广泛，现场网络经常中断且需要低时延控制

D. 大量短时任务由事件触发且调用频率波动明显

答案：B。 A 更偏向微服务，C 更偏向云边协同，D 可考虑事件驱动和无服务器。模块化单体适合降低早期分布式复杂度，同时保持代码边界。

练习二：简答题

事件驱动架构为什么需要幂等、重试和死信机制？

参考答案： 消息可能因确认丢失、网络故障或消费者重启而重复投递，也可能暂时无法处理或长期失败。幂等保证重复处理不会造成重复扣款等错误；有限重试和退避处理临时失败；死信队列保存多次失败消息，便于人工分析和补偿，防止一条坏消息阻塞正常消息。还应记录事件编号、处理状态和错误原因。

练习三：案例题

某医院预约系统要求高峰期间弹性扩展，挂号核心数据不能重复或丢失，短信通知允许延迟，报表每天生成一次。请设计模式组合。

参考答案： 挂号和号源管理可采用模块化单体或边界清晰的核心服务，以关系数据库、唯一约束、事务和状态机保证号源与预约一致；入口和查询服务可无状态化并水平扩展，必要时使用缓存和限流；预约成功后发布可靠事件，短信服务异步消费并使用幂等、重试和死信，允许最终一致；报表通过事件或业务数据进入独立批处理任务，避免影响交易库。平台统一提供认证、审计、指标、日志和追踪。若使用无服务器生成报表，应设置执行时间、权限、失败重跑和成本上限。方案的关键是根据不同业务的实时性和一致性要求选择模式，而不是全系统采用单一模式。

十二、论文写作与综合知识迁移

论文中写架构模式时，建议先描述选型背景，再分别说明模式解决的问题。不要写成产品清单。可以这样组织：面对稳定核心交易，采用模块化或服务化边界控制一致性；面对高峰和异步后续处理，采用事件驱动削峰并建立可靠消息；面对低频任务，采用无服务器降低闲置成本；面对网络不稳定的现场，采用云边协同实现低时延和断网自治。

每种模式都要写出其代价和治理措施。微服务要写分布式事务和可观测，事件驱动要写重复和乱序，无服务器要写冷启动、执行限制和供应商绑定，云边协同要写版本、缓存和远程安全。这样的论述才能体现架构决策，而不是概念堆砌。

十三、今日复盘清单

• 我能否说明模块化单体为什么也是一种合理的云原生演进形态？
• 我能否列出微服务和事件驱动各自解决的问题及新增代价？
• 我能否解释无服务器的适用边界和限制？
• 我能否根据低时延、断网自治和集中管理需求识别云边协同？
• 我能否把多种模式组合起来，并明确同步边界、数据权威和失败补偿？

本节的核心结论是：架构模式是解决特定问题的结构化选择，没有脱离业务上下文的最佳模式。云原生系统通常需要模块化单体、微服务、事件驱动、无服务器和云边协同等模式按场景组合，架构师必须同时说明适用条件、质量收益、新增复杂度和治理方案。