Day34-20｜15.8.4 微服务模式：以自治小服务支撑快速演进

对应教材：第15章 面向服务架构设计理论与实践——15.8.4 微服务模式

学习目标：理解微服务模式与 SOA 的联系和区别；掌握微服务拆分、数据自治、通信、部署、治理和容错方法；能够判断何时适合微服务、何时不适合，并在案例分析和论文中写出完整设计。

一、微服务模式的核心思想

微服务是一种将应用划分为一组小型、自治、可独立部署的服务的架构模式。每个服务围绕一个业务能力或限界上下文构建，拥有明确职责、独立代码和相对独立的数据及运行环境，通过轻量通信方式协作。

“小”不是唯一目标。微服务的关键是自治、边界和独立演进。如果只是把一个单体应用拆成几十个进程，却仍然共享数据库、必须统一发布、调用链相互嵌套，得到的只是分布式单体。判断微服务质量，要看服务是否能独立理解、开发、测试、部署、扩展和恢复。

微服务通常包含以下特征：围绕业务能力组织；服务内部高内聚；服务之间低耦合；独立部署；数据尽量自治；自动化交付；基础设施可编程；具备可观测性和故障隔离。

二、微服务与 SOA 的关系

SOA 是更广泛的服务化架构思想，强调服务契约、异构集成、复用、组合和治理；微服务是更强调小粒度、自治团队、独立部署和持续交付的一种实践风格。二者并非完全对立，微服务可以看作在互联网和云环境中对服务化思想的进一步细化。

传统 SOA 常采用企业服务总线进行集中集成，微服务更倾向于轻量通信、智能端点和去中心化治理，但这不是绝对界限。关键在于解决的问题不同：跨组织异构系统整合可能需要 ESB；内部快速演进和弹性扩展可能更适合微服务平台。

考试中不要简单回答“SOA 已经过时，微服务替代 SOA”。应指出 SOA 关注服务化和企业集成，微服务关注自治、独立部署和快速交付；二者在契约、边界、复用和治理方面有共同基础，在中介程度、粒度和组织方式上存在差异。

三、服务拆分原则

1. 以业务能力和限界上下文拆分

服务边界应围绕业务规则、数据和变化原因。客户、订单、库存和支付通常具有不同业务目标和变化节奏，可以形成不同服务。不要按数据库表或技术层拆分，例如把“用户表服务”“订单表服务”当成服务，会把存储结构误认为业务边界。

2. 高内聚、低耦合

同一服务中的功能应共同变化、共同维护、共同测试；服务之间依赖应尽量少且稳定。若两个服务每次需求都必须同时修改和发布，可能需要重新划分边界；若一个服务包含多个几乎不相关的业务域，则可能过于粗大。

3. 以团队认知和责任为依据

服务需要明确负责团队。团队规模、专业能力、发布频率和运维能力都会影响拆分粒度。过细的服务会产生大量运维负担，小团队可能无法承担；过粗的服务则限制并行开发。架构设计应让团队能够端到端负责服务质量。

4. 尊重一致性边界

必须强一致的业务规则尽量放在同一服务内部，避免为追求形式上的微服务而跨多个服务执行长事务。无法避免跨服务时，应明确最终一致性、状态模型、补偿和对账。

四、数据自治与一致性

微服务通常要求服务对自己的数据拥有控制权，其他服务不能直接访问内部数据库。服务之间通过接口、事件或受控数据副本交换信息。

数据自治会带来重复存储和最终一致性。例如订单服务保存订单快照，库存服务保存可用库存，数据平台保存分析副本。副本之间允许存在传播延迟，但必须明确延迟范围、更新事件、失败重试和修复机制。

跨服务事务可采用以下方法：把事务收敛到单个服务；使用事件驱动和补偿；采用 Saga 协调长流程；使用事务消息保证本地事务与事件发布；通过幂等和对账处理重复与遗漏。不要把分布式锁和共享数据库当作默认答案，因为它们可能损害服务自治并形成性能瓶颈。

五、通信与接口设计

微服务通信可采用同步 REST、RPC 或异步消息。查询和即时校验适合同步；通知、数据同步和耗时流程适合异步。同步调用应设置超时、熔断、限流和隔离，防止调用链级联阻塞；异步消息应处理重复、乱序、积压、死信和重放。

接口要保持面向业务语义，使用明确资源和命令，统一错误码、追踪字段和版本。服务之间不要暴露内部数据库模型。对于高频组合查询，可以建设面向消费者的聚合层或读模型，避免客户端串联大量内部服务。

六、部署与交付

微服务的独立部署依赖自动化交付。代码提交后应执行单元测试、静态检查、契约测试、安全扫描和构建；发布时使用镜像、配置分离、灰度、蓝绿或滚动策略；出现异常可以快速回滚。没有自动化测试和发布流水线，微服务的服务数量会放大人工操作风险。

配置、密钥和环境参数不能硬编码在镜像中，应使用集中配置和安全存储。服务实例应尽量无状态，状态放在可靠的外部组件中，以便弹性扩展和故障转移。对于必须本地持有状态的服务，要明确持久化、迁移和恢复策略。

七、治理与可观测性

微服务不是无治理架构。需要统一身份认证、授权、服务发现、配置、日志、指标、链路追踪、限流、熔断、告警和审计。治理可以通过平台、网关、服务网格和开发框架提供，但核心业务团队仍对服务质量负责。

可观测性至少包括三类信号：指标说明系统是否健康，例如延迟、错误率、吞吐量和资源使用；日志说明发生了什么；链路追踪说明请求经过哪些服务。所有同步请求和异步消息应携带关联标识，支持按订单号、用户号或 traceId 查询完整过程。

故障隔离是微服务架构的关键。可以通过舱壁隔离线程池、连接池和队列；通过熔断阻止持续调用故障服务；通过降级提供可接受的替代结果；通过限流保护核心资源；通过多区域和副本提升可用性。设计时要明确哪些功能可以降级，不能只写“服务不可用时降级”。

八、微服务的优点与代价

优点包括：服务可独立发布，缩短交付周期；可按业务负载独立扩展；故障影响范围可隔离；团队可以围绕领域能力负责；技术栈可以在边界内演进；适合云平台和持续交付。

代价包括：网络调用增加延迟和故障；数据一致性更复杂；测试和排障需要跨服务协作；服务数量带来部署、监控和安全治理成本；版本和依赖管理更困难；团队必须具备自动化和运维能力。因此微服务不是默认升级方案，单体或模块化单体在业务稳定、团队较小、规模有限时可能更经济。

九、案例：电商平台微服务改造

某电商平台原有单体应用包含用户、商品、订单、库存、支付和营销模块。随着促销活动增加，订单发布频繁影响商品和营销功能；高峰扩容必须整体扩容；一个模块故障会拖垮整站。

架构团队先采用模块化单体梳理领域边界，再逐步拆出商品、订单、库存和支付服务。订单服务拥有订单状态，库存服务拥有库存，支付服务拥有交易；商品搜索采用独立读模型；营销和通知通过订单事件异步消费。

请求链路如下：

客户端 → 网关 → 订单服务 → 库存服务 ↓ ↓ 订单数据库 库存数据库 ↓ OrderCreated → 支付、营销、通知

库存预占失败时订单进入待处理或取消状态；支付超时通过查询确认；事件消费者使用业务键幂等；网关和服务设置限流、熔断和追踪；发布采用灰度和自动回滚。改造没有一次性拆完全部模块，而是优先处理变化快、负载差异大和故障影响明显的领域。

十、考试答题模板

题目问“微服务设计要点”，可按业务拆分、数据自治、契约通信、独立部署、自动化交付、服务发现、配置管理、可观测性、容错治理和安全控制展开。题目问“微服务带来的问题”，要写分布式事务、网络故障、调用链、版本、测试、运维和团队能力，并给出对应措施。

题目问“是否应该微服务化”，应从业务复杂度、团队规模、发布频率、负载差异、可靠性要求、组织边界、自动化能力和迁移成本判断。不能仅因为系统规模大就拆，也不能仅因为微服务流行就采用。

论文中可以写：本项目采用渐进式微服务化，先以模块化单体明确领域边界，再拆出变化频繁、负载差异明显且需要独立扩展的服务；每个服务拥有自己的数据和发布节奏，通过契约、事件、幂等、补偿和链路追踪控制分布式复杂度；对暂不具备自治条件的模块保持模块化单体，避免过度拆分。

十一、课后练习

练习1

共享数据库为什么会削弱微服务自治？

参考答案：多个服务依赖同一表结构和事务，任何字段变更都需要协同发布；权限和业务规则扩散；并发修改和数据所有权不清；故障与扩展无法隔离。应通过服务接口、事件或受控副本访问数据。

练习2

微服务中为什么必须建立契约测试？

参考答案：服务可以独立发布，但消费者依赖契约；单元测试无法发现跨服务字段、错误码和行为变化。契约测试在发布前验证提供者与消费者兼容，降低独立演进风险。

练习3

什么时候不建议采用微服务？

参考答案：业务简单稳定、团队规模小、发布频率低、没有自动化交付和运维能力、服务边界无法明确或强一致事务占主导时，微服务的治理成本可能超过收益，可优先采用模块化单体。

十二、今日复盘

微服务模式的核心不是服务数量，而是业务边界、自治、独立演进和自动化治理。它适合复杂业务和持续交付，但会引入网络、数据一致性、测试和运维成本。高级系统架构设计师应从收益、代价、场景和实施路线四个方面做出有依据的选择。