【软考高级·系统分析师全链路通关实战】第 48 篇：微服务系统分析与设计
本系列定位：面向有开发经验、从零备考软考高级「系统分析师」的工程师，以《系统分析师教程（第 2 版）》为主线，按「综合知识 → 案例分析 → 论文」三科组织，需求工程与 UML 建模深拆，60 篇带你从考试小白到三科同过。
本篇你将学到
- 微服务需求分析的特殊性：服务边界即需求边界——拆分是分析问题不是技术问题
- 服务拆分与需求映射：从业务域到服务清单的完整推导方法
- 微服务测试四层：单元、集成、组件、端到端（教材专章内容，案例可考）
- 服务治理需求：限流、熔断、降级的分析论证——什么场景要什么手段
- 云诊通实战：处方服务从单体中拆出的完整分析（论文核心素材）
模块九第五站。微服务是近年案例与论文的双料高频主题；本篇给出「为什么拆、怎么拆、拆后怎么保」的三段完整论证框架。
考点热力表
| 知识点 | 综合知识 | 案例分析 | 论文 |
|---|---|---|---|
| 微服务 vs SOA 本质差异 | ★★★ | ★★ | ★★ |
| 服务拆分方法（业务能力/限界上下文） | ★★ | ★★★ | ★★★ |
| 微服务测试四层 | ★★ | ★★★ | ★ |
| 限流熔断降级 | ★★ | ★★★ | ★★ |
| 分布式事务（Saga/最终一致） | ★★ | ★★ | ★★ |
一、服务边界即需求边界
1.1 拆分为什么是分析问题
微服务的技术细节（容器、注册发现）是架构师的词，但**「沿什么线拆」由业务需求决定**：服务边界划错，跨服务调用会像跨部门办事一样昂贵。第 37 篇已给出云诊通七大业务域→服务清单的总览，本篇换一个视角：一次真实拆分的完整决策过程。
先回顾判定基线（第 36 篇）：微服务相对 SOA 的本质差异——服务粒度细、去中心化治理（无 ESB 总线）、独立部署与数据库私有、轻量协议（REST/消息）。
1.2 拆分的四个信号
何时把一个模块从单体中拆出去？四个触发信号：
- 变更节奏不同步：该模块需求变更频率与主体差异大，频繁发版互相牵连
- 负载形态不同：峰值特征差异大，扩容时「一损俱损」（第 44 篇问诊高峰的教训）
- 团队边界清晰：有专属小团队可以独立负责（康威定律：系统结构映射组织结构）
- 合规与可用性等级特殊：需要独立的审计、容灾与发布管控
四信号同时命中越多，拆分收益越大——这套判定语言可直接用于案例论证。
二、云诊通实战：处方服务拆出的完整分析
2.1 背景与触发信号
云诊通第一阶段单体运行半年后，处方模块呈现全部四个信号：
| 信号 | 处方模块表现 |
|---|---|
| 变更节奏 | 监管处方规则季度级调整 vs 挂号问诊双周迭代，互相拖累发版 |
| 负载形态 | 处方开具集中于问诊高峰后 1 小时，与问诊同时段叠加打满数据库 |
| 团队边界 | 处方规则复杂，已形成 3 人专属小组 |
| 合规等级 | 处方实时上报监管、审方留痕，需要独立发布管控与审计 |
2.2 拆分推导五步
第一步 界定业务能力：处方域能力 = 处方开具、药师审方、处方流转（第 03 篇业务域原文）、监管上报、处方档案查询。边界依据是限界上下文（第 32 篇）：「处方」在问诊上下文中只是输出物，在处方上下文中才是聚合根——上下文边界即服务边界。
第二步 剥离数据：处方库独立，问诊服务只保留处方号引用（数据库私有是微服务硬约束）；跨服务查询走 API 组合而非跨库 join。
第三步 定义接口契约：开具（问诊→处方，同步 REST）、上报结果回调（处方→监管网关，异步消息）、状态变更事件（处方→配送/随访，发布订阅，第 35 篇事件驱动思想）。
第四步 处理分布式事务：问诊开处方不再有本地事务。采用Saga 分步补偿：问诊扣减问诊次数 → 创建处方 → 发送上报消息；任一步失败则逆序补偿（恢复次数、作废处方草稿）。放弃强一致换取可用性，靠补偿与对账兜底——这句取舍表述是采分点。
第五步 治理配套：注册发现、网关鉴权（第 40 篇保护代理）、独立流水线（第 41 篇 CI）。
2.3 拆分成效（论文数据）
处方服务独立后：发布频率从随单体双周变为按需（季度合规调整当日上线）、问诊高峰数据库连接占用下降约 40%（处方写流量隔离）、处方上报及时率从 99.2% 提升到 99.9%——每项成效对应一个拆分信号，论文写作的因果闭环。
三、微服务测试四层
单体测试五层次（第 42 篇）在微服务下的变体，教材专章的分层：
| 层 | 测什么 | 手段 |
|---|---|---|
| 单元测试 | 服务内代码逻辑 | 常规，最多最快 |
| 集成测试 | 服务与外部设施协作（数据库、消息） | 测试环境真实设施或替代品 |
| 组件测试 | 单个服务整体的功能，借替身隔离其依赖 | 模拟依赖服务的桩/契约替身 |
| 端到端测试 | 多服务组合的完整业务流 | 少量关键路径 |
核心思想：把「服务间依赖」用替身挡在组件层，端到端只留关键路径——否则服务数量平方级放大测试组合，流水线永远跑不完（第 41 篇 CI 的前提）。案例问「微服务环境测试策略」按四层 + 替身思想作答。
四、服务治理需求：限流、熔断、降级
4.1 三种手段辨析
| 手段 | 解决的问题 | 一句话 |
|---|---|---|
| 限流 | 上游流量超容量 | 排队/拒绝超额请求，保住系统不死 |
| 熔断 | 下游持续故障拖垮调用方 | 连续失败即跳闸，快速失败不再等待 |
| 降级 | 故障时保核心弃外围 | 返回兜底数据，关闭非核心功能 |
三者常组合：问诊高峰对营销活动接口限流；处方服务调用药典知识库连续超时则熔断，恢复探测后再闭合；熔断期间审方降级为「人工审方队列 + 提示药师」——降级预案必须仍是合规路径（自动审方可以降，药师复核不能省，监管红线不可降），这是医疗场景治理论证的特色采分点。
4.2 治理论证模板
案例题「分析该场景应采取何种治理措施」：先指出故障传播链（哪个上游被哪个下游拖垮）→ 按上表归位手段 → 给出参数依据（阈值、窗口）→ 说明降级后的业务语义。四步齐了就是满分结构。
再补一个容量参数的估算视角：限流阈值不是拍脑袋数字，而应来自压测得出的单实例容量乘以实例数再留安全余量（如实测容量的七成）——把第 44 篇「定量容量分析」的方法迁移到治理参数上，论证就有数据支撑；论文里写「阈值来源于压测与高峰复盘」远比「设置了合理阈值」可信。
五、拆分粒度权衡：不是越细越好
微服务案例题的高阶问法是「评价该拆分方案是否合理」——考的不是拆分步骤，而是粒度意识。拆分粒度的收益与代价随服务数量此消彼长：
| 维度 | 拆得粗（服务少） | 拆得细（服务多） |
|---|---|---|
| 独立部署与扩容 | 弱——一域高峰全舱陪跑 | 强——按域精准伸缩 |
| 团队并行与Ownership | 弱——改动常互相踩 | 强——康威定律对齐（第一节信号三） |
| 跨服务一致性与事务 | 好——库内事务搞定 | 差——Saga 补偿与对账成本陡增 |
| 运维与联调复杂度 | 低 | 高——链路追踪、服务治理、环境数量齐涨 |
| 故障隔离 | 弱——一处缺陷全局重启 | 强——故障域缩小 |
粒度合适的三个信号：① 一个服务的发布节奏与数据所有权只对应一个业务能力（挂号是挂号，不是「挂号+号源+排班」一把抓）；② 跨服务事务边界与限界上下文边界重合——上下文内部强一致、跨上下文最终一致，若发现大量 Saga 补偿横跨两服务，说明边界切错了位置；③ 一个小团队（「两个披萨」量级，对应云诊通 7 名开发的服务域划分）能独立维护该服务全生命周期。反之，过细的警报：服务间调用链超过四层、一个用户请求扇出到十个以上服务、大量「贫血转发性」服务（只做数据搬运没有业务规则）——命中任意一条就应考虑合并。
云诊通的粒度决策实例：一期只拆了处方服务（合规等级特殊 + 发布节奏不同步两个强信号命中），挂号与问诊仍留在单体域内——不是做不到更细，而是七人团队下更细粒度的运维成本会吞噬独立部署的收益。论文里把这个「克制」写成决策：拆分是手段不是目标，粒度由团队规模与信号强度共同决定——这句表述本身就是加分点。
演进式拆分补充：粒度决策不是一次性定终身，正确路径是「单体 → 垂直拆分（按大业务域）→ 再按信号逐步细拆」——每拆一步观察四信号的命中变化，命中不明显就停。云诊通的节奏正是如此：一期垂直拆分（问诊域独立），二期信号增强才拆处方服务，三期对配送域评估后主动放弃（变更节奏与问诊高度同步、团队无独立ownership，拆了徒增治理成本）。「评估后不拆」与「拆」同样是分析结论——案例题问「哪些服务该拆」时，答出「哪些不该拆及理由」往往才是区分度所在。
真题风格自测题
1. 微服务区别于 SOA 的本质特征不包括（ ）。
A. 服务粒度更细 B. 去中心化治理、无集中总线 C. 每服务独立数据库 D. 必须使用统一 ESB
2. 「服务边界即需求边界」的含义是（ ）。
A. 服务按技术层划分 B. 服务划分应沿业务能力/限界上下文的边界 C. 服务越大越好 D. 边界随意划分
3. 以下最适合作为拆分服务的触发信号是（ ）。
A. 变更节奏不同步、负载形态差异、团队边界清晰、合规等级特殊 B. 代码不够美观 C. 程序员想尝试新技术 D. 数据库表太多
4. 微服务架构下，跨服务查询的正确做法是（ ）。
A. 跨库 join B. API 组合或服务间接口调用 C. 直接读对方库表 D. 人工导表
5. 问诊扣次数、创建处方、发送上报的分步补偿方案属于（ ）。
A. 两阶段提交 2PC B. Saga 模式 C. 乐观锁 D. 分布式快照
6. Saga 模式换取的核心收益是（ ）。
A. 强一致 B. 可用性，以补偿与对账兜底一致性 C. 免除一切事务 D. 更快网络
7. 微服务测试四层中，以替身隔离依赖、验证单个服务整体功能的是（ ）。
A. 单元测试 B. 集成测试 C. 组件测试 D. 端到端测试
8. 微服务测试「把依赖挡在组件层、端到端只留关键路径」的目的是（ ）。
A. 防止测试组合随服务数平方级爆炸 B. 少写代码 C. 降低覆盖率 D. 跳过集成
9. 上游流量超过系统容量时排队或拒绝超额请求，属于（ ）。
A. 限流 B. 熔断 C. 降级 D. 隔离部署
10. 下游服务持续故障时调用方快速失败、避免被拖垮，属于（ ）。
A. 限流 B. 熔断 C. 降级 D. 鉴权
11. 故障期间关闭非核心功能、返回兜底数据，属于（ ）。
A. 限流 B. 熔断 C. 降级 D. 审计
12. 云诊通熔断药典知识库后降级为人工审方，不能降级的是（ ）。
A. 界面美化项 B. 药师人工复核（监管红线） C. 营销推送 D. 推荐模块
13. 康威定律在微服务设计中的含义是（ ）。
A. 系统结构映射组织沟通结构，团队边界宜与服务边界对齐 B. 摩尔定律失效 C. 代码行数翻倍 D. 无关
14. 处方服务拆分后「发布频率不再受单体牵制」，对应的拆分信号是（ ）。
A. 变更节奏不同步 B. 机房电力 C. 编程语言差异 D. 界面风格
参考答案：1.D 2.B 3.A 4.B 5.B 6.B 7.C 8.A 9.A 10.B 11.C 12.B 13.A 14.A（治理口诀：限流防压垮、熔断防拖垮、降级保核心；红线不可降）
本篇小结
| 知识点 | 核心内容 |
|---|---|
| 拆分四信号 | 变更节奏、负载形态、团队边界、合规等级——命中越多越该拆 |
| 拆分五步 | 界定能力（限界上下文）→ 数据剥离 → 契约定义 → Saga 补偿 → 治理配套 |
| vs SOA | 粒度细、去中心化、库私有、轻协议；禁跨库 join 用 API 组合 |
| 测试四层 | 单元→集成→组件（替身隔离）→端到端（关键路径）；防空爆炸 |
| 治理三手段 | 限流（超容）、熔断（下游故障）、降级（保核心弃外围）；合规红线不可降 |
| 论文闭环 | 每项成效对应一个拆分信号：发版、连接占用 40%、上报 99.9% |
下篇预告
第 49 篇：信息物理系统 CPS 分析与设计
模块九收官：3C（计算-通信-控制）融合、CPS 三层架构与反馈控制回路建模、远程医疗监护的完整 CPS 分析。
如果本篇内容对你有帮助，欢迎点赞收藏！有任何疑问，欢迎在评论区交流。
