# 04 架构模式演进与微服务

**扫描资料与纪要共同给出的答题方向：**架构模式不是背定义，而是解释“当时的核心矛盾是什么、改变了什么管理对象、解决了什么、又引入了什么代价”。扫描资料的总结句是：在新的成本结构下，重新划定边界和协作方式。

# 架构演进：每一步都是取舍

# 脑图：架构模式与微服务速记

**记忆方法：**模式题按“上下文、问题、结构、收益、代价”作答；微服务题再补部署、治理和分布式代价。

# 纪要补充：架构演进链和 SOA 骨架

回到总结页：纪要可能考查方式索引已把本知识点与相关训练题互链，复习时可从题型反查本节。

**作答原则：**模式题不靠名词解释拿分，要解释“为什么出现、改变了什么、牺牲了什么、带来什么新问题”。

可能画图	必须出现	可写取舍
SOA 骨架	消费者、服务总线/注册与治理、服务提供者	服务复用和集成能力提升，但总线/治理复杂，局部自治不如微服务。
C&C / P2P	运行时组件、连接器、交互关系	适合解释动态通信，不要画成静态类图。

阶段	想解决的痛点	获得的能力	新代价 / 下一步原因
主机终端	机器昂贵，需要共享计算资源	集中管控、一致性与可靠性	终端弱，交互体验不足
Client / Server	改善用户交互体验	客户端利用本地算力	胖客户端难部署、难维护
分层 / SOA	统一入口、降低维护耦合	职责分工、复用与集成	集中协调重、独立发布不足、性能开销
微服务	独立迭代与局部自治	按业务能力拆分、独立部署扩缩容	分布式故障、运维与长期稳定运行复杂
云原生 / 事件驱动	支撑大量服务稳定运行与弹性	容器化、编排、异步解耦、可观测	时序、一致性与故障定位更难

**论述题模板：**先给场景背景，再指出最关键质量属性，接着解释结构变化，最后写收益与引入的新风险。

# Pattern、Tactic 与 Style

# Tactic

控制单个质量响应的原子动作，如冗余、限制依赖、缓存。

# Pattern

针对反复出现问题的一组决策组合，如分层、Broker、Pipe-and-Filter。

# Style

描述元素和关系类型的组织方式，如微服务风格。

# 常见模式复习卡

模式	核心结构	优势	限制
Layered	按抽象层次组织模块	关注点分离、可修改	跨层开销、严格分层不灵活
Multi-tier	将运行元素部署到不同节点	部署隔离与扩展	网络与运维成本
Broker	代理协调客户端与服务端通信	位置透明、可扩展	中介瓶颈、安全和测试复杂
Pipe-and-Filter	数据依次通过过滤器转换	复用、并行、可组合	交互式处理和共享状态不佳
P2P	各 peer 既可请求也可提供服务	去中心化、资源聚合	协调、安全与一致性复杂
SOA	服务、注册表、ESB/编排	企业集成、服务复用	中间件复杂与发布粒度粗

# 常见 Pattern 分别属于什么 Style

判断口诀：看这个 pattern 的主问题是什么。若主要描述静态代码/模块如何分组和依赖，归入 Module Style；若主要描述运行期组件如何交互，归入 Component-and-Connector（C&C）Style；若主要描述软件元素如何映射到机器、进程、团队或部署环境，归入 Allocation Style。

Pattern	主要 Style	理由
Layered	Module Style	核心是把模块按抽象层次分组，并规定 allowed-to-use 依赖方向；讨论的是静态分解与依赖控制。
MVC	C&C Style	Model、View、Controller 作为运行期组件协作，关键关系是通知、调用与状态更新；重点不是部署位置。
Pipe-and-Filter	C&C Style / Data-flow Style	Filter 是组件，Pipe 是连接器，数据沿连接器被连续转换；判断点是运行期数据流。
Broker	C&C Style	Client、Server、Broker、Proxy 通过通信连接器协作；Broker 解决的是运行期定位、转发与解耦。
Client-Server	C&C Style	核心是 Client 通过 request/reply connector 调用 Server 服务；它可能被部署成多层，但模式本身先描述交互关系。
P2P	C&C Style	Peer 既请求也提供服务，运行期连接关系可变化；重点是对等组件之间的通信与协作。
SOA	C&C Style / Service Style	Service Provider、Consumer、Registry、ESB、Orchestration 通过 SOAP/REST/消息连接器协作；本质是服务组件和连接器的组织方式。
Publish-Subscribe	C&C Style / Event-based Style	发布者和订阅者通过事件分发连接器通信；关注点是事件通知、订阅关系和异步交互。
Shared-Data	C&C Style / Data-centered Style	数据访问组件通过共享数据存储通信；共享 store 既是协调中心，也带来耦合、瓶颈和单点风险。
Map-Reduce	Allocation Style	课程材料把它归为 Allocation Pattern，因为重点是 Map/Reduce 实例如何分配到处理器并由基础设施部署、监控和恢复。
Multi-tier	Allocation Style	Tier 是运行元素的逻辑分组，经常映射到不同平台或节点；它回答“部署到哪里、如何隔离和扩展”。
Microservices	C&C Style + Allocation 关注点	服务本身是独立运行组件，通过轻量 API、消息或网关交互；同时强调独立部署、DevOps 与运行治理，所以答题可先归 C&C，再补部署/运维维度。

考试提醒：一个 pattern 可以体现多个 style 的味道，但答题要抓主导结构。例如 Client-Server 可部署成多层系统，但它的基本定义是运行期请求/响应交互，所以先归 C&C；Multi-tier 则直接讨论 tier 到执行环境的映射，所以归 Allocation。

知识出处：04 架构模式演进与微服务、06 往年题与训练题；补充证据：扫描文档20260526_192514.pdf、slides/05_Patterns.pdf 与 研究生版/研究生往年题版.md。

# 架构模式速判图：Layered / Multi-tier / C&C

定位：上面的表格是文字版归属判断，这张图保留为图解版速判。考试时先看主导关系：模块依赖看 Layered / Module，部署映射看 Multi-tier / Allocation，运行交互看 C&C。

# 常见 Pattern 结构图补充

补图范围：速判图已作为图解版保留；这里优先使用 UML/PlantUML 补充常见具体模式的结构图，重点看元素和连接关系。

# MVC 结构图

# Client-Server 结构图

# Broker 结构图

# Pipe-and-Filter 结构图

# P2P 结构图

# Shared-Data 结构图

# Map-Reduce 结构图

# Microservices 结构图

读图方法：考试作图不用追求工具细节，优先标出组件/模块名称、连接器类型和主导约束。例如 Pipe-and-Filter 要画 Pipe，Broker 要画 Broker，SOA 要画 Registry 与 ESB，Microservices 要画 API Gateway、独立服务与独立数据。

知识出处：04 架构模式演进与微服务；补充证据：slides/05_Patterns.pdf、slides/08Microservices Architecture.pdf、扫描文档20260526_192514.pdf。

# 微服务：不要只背定义

# 六个应答关键词

**服务组件化：**小服务通过轻量通信协作。
围绕业务能力组织：服务边界不是技术分层，而是业务职责。
**独立自治：**服务可独立开发、部署与扩缩容。
**去中心化：**治理和数据管理更分散，但一致性更难。
**基础设施自动化：**持续交付、容器化与编排成为前提。
**演进与故障设计：**必须面向故障、监控和渐进变化。

# SOA 与微服务比较

维度	SOA	微服务
主要目标	企业服务集成与复用	快速独立演进与部署
通信/中介	常依赖 ESB 与较重治理	轻量 API/消息、API Gateway
服务粒度	相对更粗	围绕业务能力更细
关键风险	中介复杂、集中瓶颈	分布式事务、故障定位与运维复杂

# SOA 模式结构：消费者、服务总线与提供者

**画图落点：**不要只写 SOA 与微服务的差异；SOA 模式题应画出 Service Consumer → ESB / Orchestration → Service Provider，并标出 Service Registry 的发布与发现关系。

ESB 是什么：ESB 是 Enterprise Service Bus（企业服务总线）。在 SOA 中，它相当于企业内部的“服务中介/集成层”，负责把服务消费者和服务提供者连接起来，并承担路由、协议转换、消息格式转换、服务编排、安全与治理等工作。优点是便于企业系统集成和服务复用；代价是中间件变重，ESB 可能成为性能瓶颈或集中治理瓶颈，所以微服务更强调轻量 API、消息代理或点对点通信。

知识出处：04 架构模式演进与微服务；补充证据：slides/08Microservices Architecture.pdf、软件架构模式演进：从主机到 AI 原生。

来源：slides/05_Patterns.pdf、《软件体系结构复习课录音整理版.docx》，以及补充课件中关于架构模式演进的部分。若原文件标题含 AI 原生，仅作为考后或背景内容来源边界，不纳入本页考试范围。

# 微服务相关模式要会举例

# 拆分 / Decomposition

**Business Capability：**按业务能力拆服务。
**Subdomain：**按 DDD 子域拆服务。
**Strangler Fig：**逐步替换旧单体。
**Database per Service：**明确数据归属和自治边界。

# 通信 / Communication

**API Gateway：**统一入口、鉴权、限流和路由。
**Service Discovery：**定位动态实例。
**Messaging / Event-driven：**异步解耦。
**Circuit Breaker / Saga：**故障隔离与跨服务一致性。

# 部署 / Deployment

**Service Instance per Host：**隔离强。
**Multiple Service Instances per Host：**资源利用高。
**Service Instance per Container：**容器化独立发布。
**Serverless / FaaS：**事件触发，按需运行。

# 可观测性 / Observability

**Log Aggregation：**集中日志。
**Distributed Tracing：**跨服务调用链。
**Health Check API：**健康探测与摘流。
**Metrics / Monitoring：**指标、容量和告警。

# 微服务相关模式：人话版解释

一句话理解：微服务把一个大系统拆成很多小服务，好处是能独立开发和部署；坏处是服务变多、网络调用变多、故障点变多、排查更难。下面这些模式，就是给这些新麻烦配的工具。

模式	它在解决什么问题	更容易懂的解释	例子 / 代价
服务拆分 Decomposition	一个大系统太难改、太难发布。	把“大厨房”拆成多个窗口：课程、订单、支付、库存各管各的，哪个服务改了就发布哪个。	例子：支付服务单独升级不影响选课服务。代价：边界划错会导致服务之间频繁互相调用。
断路器 Circuit Breaker	一个服务坏了，其他服务一直等它，最后全系统被拖垮。	像家里的空气开关：下游连续失败时先“跳闸”，调用方快速失败或走降级，不再傻等。	例子：支付接口挂了，订单服务先提示稍后支付。代价：阈值难调，太敏感会误熔断。
服务注册与发现 Registry / Discovery	服务实例会动态扩缩容，调用方不知道该找哪台机器。	像通讯录：服务启动时登记地址，调用方先查通讯录，再去找可用实例。	例子：订单服务查注册中心，找到当前可用的库存服务。代价：注册中心本身要高可用。
API 网关 / 边缘网关 API Gateway	客户端如果直接调用很多服务，会很乱，也难统一鉴权、限流和路由。	像商场总服务台：用户只找一个入口，网关负责转发到课程、订单、支付等服务。	例子：网关统一做登录校验、限流、灰度路由。代价：网关可能成为瓶颈或单点风险。
容器化 Containerization	服务太多，部署环境不一致，发布和扩容麻烦。	把每个服务连同运行环境打包成“标准盒子”，到哪里都按同样方式运行。	例子：选课服务高峰期复制多个容器实例。代价：需要编排、镜像治理和运维平台。
Serverless	有些能力不是一直运行，自己维护服务和机器不划算。	按事件触发函数，平时不占资源，用到时再运行。	例子：支付成功后触发发送通知函数。代价：冷启动、调试和厂商绑定。
可观测性 Logs / Metrics / Tracing	请求跨多个服务，出问题时不知道卡在哪一步。	给系统装“行车记录仪”：日志看发生了什么，指标看是否变慢，调用链看请求经过了哪些服务。	例子：一次下单慢了，调用链显示卡在库存服务。代价：采集、存储和告警本身也有成本。
健康检查 Health Check	服务实例可能已经坏了，但负载均衡还在把请求打过去。	平台定期问服务“你还好吗？”不健康就先摘掉，等恢复再放回流量池。	例子：支付服务数据库连不上，健康检查失败，网关停止转发。代价：检查太频繁会增加额外负载。

答题模板：微服务相关模式不要只背名字，要按“拆小之后产生的问题 → 用什么模式处理 → 带来什么代价”来写。例如：服务拆小后故障会沿调用链传播，所以用断路器快速失败和降级；但它需要合理阈值，否则可能误熔断。

# 微服务部署与迁移决策

# 纪要补充：微服务考点只抓特性、对比和模式