目录
一、引言：从单体到微服务
在软件架构演进的历史长河中，应用系统经历了从单体架构到面向服务架构（SOA），再到微服务架构和云原生架构的演变。每一次演进都是为了解决前一代架构在规模、复杂度、交付速度、可维护性上的瓶颈。理解这条演进路线，是掌握现代系统架构设计的起点，也是软考系统架构设计师考试的高频考点。
1.1 单体架构的痛点
单体架构（Monolithic Architecture）是将所有功能模块打包在一个可执行单元中部署的架构方式。在项目早期，单体架构因为开发简单、测试方便、部署轻松而广受欢迎。但随着业务规模膨胀，单体架构暴露出严重问题：
- 代码膨胀：百万行代码耦合在一起，新成员上手困难，修改一处可能引发连锁反应。
- 部署低效：哪怕只改了一行代码，也需要重新构建、测试、部署整个应用，发布周期长。
- 技术栈锁定：整个系统使用统一技术栈，无法针对不同模块选择最合适的语言和框架。
- 扩展困难：只能整体水平扩展，无法对瓶颈模块单独扩容，资源浪费严重。
- 可靠性差：一个模块的内存泄漏可能导致整个系统崩溃，故障无法隔离。
- 团队协作冲突：多个团队在同一代码库上工作，合并冲突频繁，发布节奏被最慢的团队拖累。
某电商系统中，"评论模块"出现死循环导致 CPU 飙升，由于它是单体应用的一部分，整个订单、支付、库存服务全部受影响，最终导致全站不可用 2 小时。这就是单体架构故障无法隔离的典型表现。
1.2 架构演进路线
为解决单体架构的痛点，业界依次提出了 SOA、微服务、云原生等架构理念。演进的核心驱动力是业务复杂度增长和对快速交付的需求。
· 单体：高耦合、低效率，适合小型项目
· SOA：引入 ESB 总线实现服务集成，但 ESB 易成瓶颈，中心化
· 微服务：进一步拆分，去中心化、独立部署、独立数据库
· 云原生：在微服务基础上，融合容器、DevOps、持续交付，充分发挥云的弹性
二、微服务核心概念
微服务架构（Microservices Architecture）是一种将应用划分为一组小型、自治、松耦合服务的架构风格。每个服务围绕业务能力构建，由独立团队维护，独立部署到生产环境，服务间通过轻量级协议（REST、gRPC、消息队列）通信。
2.1 微服务的定义与特征
Martin Fowler 和 James Lewis 在 2014 年的经典文章中系统化提出了微服务概念。微服务没有严格的定义，但具备以下核心特征：
- 单一职责：每个服务只做一件事，围绕业务能力组织。
- 独立部署：服务可以独立于其他服务发布，无需协调全量发布。
- 进程隔离：每个服务运行在独立进程中，资源互不干扰。
- 去中心化数据管理：每个服务拥有自己的数据库，避免共享数据库导致的耦合。
- 去中心化治理：无 ESB，服务间直接通信，技术栈可异构。
- 轻量级通信：使用 REST、gRPC、消息队列等轻量协议，而非笨重的 SOAP。
- 故障隔离：一个服务故障不会拖垮整个系统（通过熔断、降级实现）。
2.2 单体 vs 微服务对比
2.3 微服务四大原则
1. 高内聚低耦合（High Cohesion, Low Coupling）
每个服务内部功能高度相关（高内聚），服务之间依赖尽量少（低耦合）。这是衡量拆分是否合理的根本标准。如果一个服务的修改频繁引发其他服务变更，说明耦合过紧，需要重新划分边界。
2. 独立部署（Independent Deployment）
每个服务可以独立构建、测试、部署，不依赖其他服务的发布节奏。这是微服务最核心的特性，也是敏捷交付的基础。要求服务接口向后兼容，避免破坏性变更。
3. 去中心化（Decentralization）
去中心化治理（无 ESB，技术栈可异构）和去中心化数据管理（每服务独享数据库）。去中心化带来灵活性的同时，也带来数据一致性和事务管理的挑战。
4. 技术多样性（Technology Diversity）
不同服务可选用最合适的技术栈：AI 推理用 Python，高并发网关用 Go，业务系统用 Java，实时通信用 Node.js。但要避免过度多样化增加运维负担。
2.4 微服务优缺点对比
✓ 优点
- 独立部署，交付速度快
- 故障隔离，系统健壮性强
- 按需扩展，资源利用率高
- 技术栈灵活，可异构
- 团队自治，并行开发
- 易于持续集成和持续交付
- 单个服务代码量小，易维护
✗ 缺点
- 分布式系统复杂度高
- 服务间通信开销大（网络延迟）
- 数据一致性难保证
- 分布式事务复杂
- 运维和监控难度大
- 需要完善的自动化基础设施
- 服务拆分边界难以确定
微服务不是银弹。在以下场景应谨慎使用：
1. 业务规模小、团队人数少（<10人）
2. 缺乏 DevOps 和自动化基础设施
3. 对数据强一致性要求极高（如银行核心账务）
4. 系统模块边界尚不清晰，处于快速探索期
软考建议："先单体，后微服务"，待业务边界清晰、团队规模增长后再拆分。
三、微服务拆分原则与方法
微服务拆分是微服务架构设计的第一难题。拆得太细，服务数量爆炸，运维成本飙升；拆得太粗，又退化为单体。本节介绍两种主流拆分方法和拆分粒度判断标准。
3.1 按业务能力拆分（By Business Capability）
按业务能力拆分是根据企业业务功能模块来划分服务边界。每个服务对应一个明确的业务能力。例如电商系统的业务能力包括：用户管理、商品管理、订单管理、支付、库存、物流、营销等。
这种方法直观易懂，适合业务边界清晰的系统。关键在于识别业务的自然边界，让服务的职责与业务部门的职责对齐。
3.2 按子域拆分（DDD - 领域驱动设计）
领域驱动设计（Domain-Driven Design, DDD）由 Eric Evans 提出，是微服务拆分最系统化的方法。其核心思想是将软件模型与业务领域模型对齐，通过限界上下文（Bounded Context）来划分服务边界。
· 领域（Domain）：业务问题域，如"电商"
· 子域（Subdomain）：领域的细分，分为核心子域、支撑子域、通用子域
· 限界上下文（Bounded Context）：一个模型适用的明确边界，通常对应一个微服务
· 实体（Entity）：有唯一标识的领域对象，如"订单"
· 值对象（Value Object）：无唯一标识，如"地址"
· 聚合（Aggregate）：一组相关对象的集合，保证事务一致性
· 聚合根（Aggregate Root）：聚合的入口，外部只能通过它访问聚合内对象
3.3 拆分粒度判断标准
| 判断维度 | 粒度过粗（接近单体） | 粒度合适 | 粒度过细（纳米服务） |
|---|---|---|---|
| 服务职责 | 承担多个业务能力 | 单一业务能力 | 一个业务能力的一部分 |
| 团队规模 | 需多人团队维护 | 2-Pizza 团队（6-8人） | 不足 2 人 |
| 代码行数 | 十万行以上 | 万行级 | 千行以下 |
| 部署频率 | 数月一次 | 每周多次 | 每小时多次（过度） |
| 数据库 | 共享多张表 | 独立数据库 | 单表服务（过度） |
| 通信开销 | 低（多为进程内） | 适中 | 高（频繁网络调用） |
拆分粒度判断："一个服务一个能力，两块披萨一个团队，一周发布几次不嫌多，独立数据库不共享"。
核心原则：高内聚低耦合是根本标准，技术指标只是参考。
案例：电商系统微服务拆分
某中型电商平台原为单体 Java 应用，日订单量 50 万，团队 30 人，决定进行微服务拆分。采用 DDD 方法拆分过程如下：
第一步：领域建模。通过事件风暴（Event Storming）梳理业务流程，识别出核心子域（订单、支付、库存）、支撑子域（用户、商品）、通用子域（认证、通知）。
第二步：划分限界上下文。每个限界上下文对应一个微服务，共拆分出 8 个核心服务：用户服务、商品服务、订单服务、支付服务、库存服务、物流服务、营销服务、评价服务。
第三步：定义服务接口。服务间通过 REST API 同步调用（如订单查库存）和消息队列异步通知（如支付成功通知物流）通信。
第四步：数据库拆分。订单库（MySQL）、商品库（MySQL+ES）、库存库（Redis+MySQL）、用户库（MySQL）独立部署。
结果：拆分后各服务独立部署，订单服务发布频率从月级提升到日级，库存服务独立扩容应对秒杀，系统整体可用性从 99.5% 提升到 99.95%。
四、微服务核心组件
微服务架构不是简单的服务拆分，还需要一整套基础设施组件支撑服务的注册发现、配置管理、通信治理、容错保护。本节介绍六大核心组件。
4.1 微服务整体架构总览
4.2 API 网关（API Gateway）
API 网关是微服务对外的统一入口，承担路由转发、鉴权认证、限流熔断、日志监控、协议转换等横切关注点。客户端不直接访问后端服务，而是通过网关访问。
4.3 服务注册与发现（Service Registry & Discovery）
微服务实例动态创建销毁，IP 和端口不断变化。服务注册中心负责记录服务实例地址，让调用方能动态发现目标服务。分为客户端发现（客户端直接查询注册中心）和服务端发现（通过负载均衡器查询）两种模式。
| 注册中心 | 一致性模型 | 健康检查 | 典型用途 |
|---|---|---|---|
| Eureka | AP（最终一致） | 心跳 | Spring Cloud 经典选择 |
| Nacos | AP/CP 可切换 | 心跳+主动探测 | 注册+配置一体 |
| Consul | CP（Raft） | 主动探测 | 多数据中心 |
| Zookeeper | CP（ZAB） | 会话保活 | Dubbo/Kafka 协调 |
分布式系统无法同时满足一致性(C)、可用性(A)、分区容错性(P)，只能满足其中两个。注册中心通常选择 AP（如 Eureka）优先保证可用性，因为临时不一致比服务不可用更可接受。Zookeeper 选择 CP，适合强一致性场景。
4.4 配置中心（Config Center）
配置中心实现配置的集中管理、动态刷新、环境隔离、版本回滚。微服务环境下，数百个服务的配置散落在各处难以管理，配置中心解决了这个问题。主流实现有 Apollo、Nacos Config、Spring Cloud Config。
配置中心的核心能力是动态刷新：修改配置后无需重启服务即可生效，通过长轮询或推送机制通知客户端。这对调优（如线程池大小、限流阈值）极其重要。
4.5 服务网格（Service Mesh）
服务网格（Service Mesh）是处理服务间通信的基础设施层，通过 Sidecar 代理拦截所有进出流量，实现流量管控、熔断限流、安全加密、可观测性等能力，将治理能力从业务代码中剥离。代表实现 Istio、Linkerd。
4.6 熔断器（Circuit Breaker）
熔断器用于防止级联故障。当下游服务故障率达到阈值时，熔断器"跳闸"直接返回失败，不再调用下游，给故障服务恢复时间。熔断器有三个状态：
· 熔断：下游故障时切断调用，保护系统不级联崩溃
· 降级：主流程失败时返回兜底数据（如默认值、缓存）
· 限流：限制请求速率，防止流量过载
三者常配合使用：限流挡住洪峰 → 熔断切断故障 → 降级保证用户体验
五、容器化技术（Docker）
容器化是云原生的基石。Docker 通过容器技术将应用及其依赖打包成一个可移植的标准化单元，实现"一次构建，到处运行"。容器比虚拟机更轻量，启动更快，资源利用率更高。
5.1 Docker 核心概念
- 镜像（Image）：只读模板，包含应用运行所需的代码、依赖、环境。采用分层存储。
- 容器（Container）：镜像运行的实例，可启停删除。容器间共享主机内核，互相隔离。
- Dockerfile：构建镜像的脚本文件，描述镜像构建步骤。
- 仓库（Registry）：存储和分发镜像的服务，如 Docker Hub、Harbor、阿里云 ACR。
- 数据卷（Volume）：持久化数据的机制，独立于容器生命周期。
- 网络（Network）：容器间通信的虚拟网络，如 bridge、host、overlay。
5.2 Docker 架构
5.3 容器 vs 虚拟机
| 对比维度 | 虚拟机（VM） | 容器（Container） |
|---|---|---|
| 虚拟化层级 | 硬件级虚拟化 | 操作系统级虚拟化 |
| Guest OS | 每个 VM 完整操作系统 | 无，共享主机内核 |
| 启动时间 | 分钟级 | 秒级甚至毫秒级 |
| 资源占用 | GB 级 | MB 级 |
| 隔离性 | 强隔离 | 进程级隔离（较弱） |
| 安全性 | 高 | 中（共享内核有风险） |
| 密度 | 单机数十个 | 单机数百上千个 |
| 跨平台 | 强（硬件抽象） | 弱（依赖内核版本） |
5.4 常用 Docker 命令
| 命令 | 说明 |
|---|---|
| docker build -t name:tag . | 根据 Dockerfile 构建镜像 |
| docker images | 列出本地镜像 |
| docker run -d -p 8080:80 name | 后台运行容器并映射端口 |
| docker ps | 查看运行中的容器 |
| docker stop <id> | 停止容器 |
| docker rm <id> | 删除容器 |
| docker pull/push | 拉取/推送镜像 |
| docker logs <id> | 查看容器日志 |
| docker exec -it <id> bash | 进入容器执行命令 |
案例：容器化一个 Java Spring Boot 服务
Dockerfile 示例（多阶段构建优化镜像大小）：
第一阶段：使用 Maven 镜像编译打包，生成 jar 文件；第二阶段：使用精简的 JRE 镜像运行，最终镜像从 800MB 降到 150MB。最佳实践包括：使用官方基础镜像、利用缓存优化构建顺序、非 root 用户运行、使用 .dockerignore 排除无关文件、合理设置健康检查（HEALTHCHECK）。
注意事项：容器内日志输出到 stdout/stderr 便于收集；配置通过环境变量或配置中心注入，不硬编码；使用多阶段构建减小镜像体积；镜像打 tag 而非用 latest，保证可追溯。
六、容器编排（Kubernetes）
当容器数量从几个增长到几百上千个时，手动管理变得不可能。Kubernetes（K8s）是 Google 开源的容器编排系统，负责容器的自动部署、扩缩容、故障恢复、负载均衡，是云原生的事实标准。
6.1 K8s 架构
K8s 集群由控制面（Master）和工作节点（Worker Node）组成。Master 负责集群管控决策，Worker Node 运行实际业务容器。
6.2 K8s 核心概念
| 概念 | 说明 |
|---|---|
| Pod | K8s 最小调度单元，包含一个或多个紧密耦合的容器，共享网络和存储 |
| Deployment | 管理无状态应用，控制 Pod 副本数、滚动更新、回滚 |
| Service | 为一组 Pod 提供稳定的访问入口和负载均衡（IP/域名不变） |
| Ingress | HTTP/HTTPS 路由入口，将外部流量路由到 Service |
| ConfigMap | 存储非敏感配置信息，注入 Pod 作为环境变量或文件 |
| Secret | 存储敏感信息（密码、密钥），Base64 编码，可加密存储 |
| StatefulSet | 管理有状态应用（如数据库），Pod 有序、有持久标识 |
| DaemonSet | 每个节点运行一个 Pod 副本，用于日志收集、监控 |
| Namespace | 资源隔离的逻辑分区，如 dev/test/prod |
6.3 Pod 生命周期
案例：在 K8s 上部署微服务
某团队将订单服务部署到 K8s，流程如下：编写 Deployment 定义副本数 3，配置资源请求/限制（CPU 500m/1000m）；创建 Service 暴露订单服务，集群内通过服务名访问；配置 HPA（水平自动扩缩容），CPU 超过 70% 自动扩容到 10 个副本；通过 Ingress 暴露 HTTP 接口给外部；使用 ConfigMap 管理非敏感配置，Secret 管理数据库密码。结果：大促期间自动扩容应对流量洪峰，故障 Pod 自动重启，实现零运维介入。
七、CI/CD 与 DevOps
CI/CD 是微服务和云原生的"血管系统"，让代码从提交到生产的过程自动化、流水线化。DevOps 则是一种强调开发与运维协作的文化和实践。
7.1 CI/CD 概念
- 持续集成（CI）：开发人员频繁将代码合并到主干，每次合并自动触发构建和测试，尽早发现集成问题。
- 持续交付（CD）：在 CI 基础上，自动将代码部署到类生产环境，确保可随时发布到生产。
- 持续部署（CD）：更进一步，通过所有测试的代码自动部署到生产环境，无需人工干预。
DevOps = Development + Operations，强调开发运维一体化。核心实践包括：自动化 CI/CD、基础设施即代码（IaC）、监控告警、微服务、容器化、故障文化（Blameless）。目标是缩短交付周期、提高发布频率、提升系统可靠性。
案例：GitOps 工作流
某团队采用 GitOps 模式部署应用：所有 K8s 清单（YAML）存储在 Git 仓库作为唯一事实来源；开发人员修改 YAML 提交 PR；CI 自动校验语法和策略；合并后 ArgoCD 检测到 Git 变更，自动将声明状态同步到 K8s 集群；若部署异常，回滚只需 git revert。优势：审计追踪、环境可重现、回滚简单、声明式优于命令式。
八、云原生（Cloud Native）四要素
云原生（Cloud Native）是 Pivotal 公司于 2013 年提出、CNCF（云原生计算基金会）推动的技术理念，指充分利用云的弹性伸缩和分布式优势构建应用。云原生不是单一技术，而是一套方法论和技术集合。
云原生四要素："微、容、Dev、持" —— 微服务、容器化、DevOps、持续交付。四者缺一不可，共同构成云原生应用的基础。CNCF（Cloud Native Computing Foundation）是 Linux 基金会下的子组织，托管 K8s、Prometheus、Istio 等项目。
九、微服务通信模式
微服务间通信分为同步通信和异步通信两大类，选择合适的通信模式对系统性能和可靠性至关重要。
9.1 同步通信
- REST：基于 HTTP，简单通用，适合 CRUD 操作。无状态、易缓存、生态丰富。缺点：性能一般，负载较大（JSON）。
- gRPC：基于 HTTP/2 和 Protobuf，性能高、强类型、支持流式。适合内部服务间高性能调用。缺点：浏览器支持弱，调试不便。
- Thrift：Facebook 开源，类似 gRPC，支持多语言，二进制高效。
9.2 异步通信
- 消息队列：Kafka（高吞吐、日志流）、RabbitMQ（灵活路由、业务消息）、RocketMQ（事务消息、电商场景）。
- 事件驱动：服务发布事件，其他服务订阅，松耦合。适合状态变更通知。
| 维度 | REST | gRPC | 消息队列 |
|---|---|---|---|
| 通信方式 | 同步 | 同步 | 异步 |
| 协议 | HTTP/1.1 | HTTP/2 | TCP/AMQP |
| 序列化 | JSON | Protobuf | 多种 |
| 性能 | 中 | 高 | 高 |
| 耦合度 | 中 | 中 | 低 |
| 一致性 | 强 | 强 | 最终一致 |
| 典型场景 | 对外 API | 内部调用 | 事件通知 |
十、分布式事务
微服务拆分数据库后，原本一个本地事务就能保证的一致性，现在变成跨服务跨库的分布式事务问题。这是微服务架构最复杂的难题之一。
· CAP：一致性(C)、可用性(A)、分区容错(P) 三选二。分布式系统必选 P，故在 C 和 A 间权衡。
· BASE：基本可用(Basically Available)、软状态(Soft state)、最终一致(Eventually consistent)。是 AP 系统的实践指南。
分布式事务大多追求最终一致性而非强一致性。
10.1 2PC / 3PC（两阶段/三阶段提交）
2PC（Two-Phase Commit）引入协调者，第一阶段询问所有参与者能否提交（Prepare），第二阶段根据回复决定提交或回滚（Commit/Rollback）。
10.2 TCC（Try-Confirm-Cancel）
TCC 是业务层面的两阶段：Try 预留资源、Confirm 确认提交、Cancel 取消释放。每个服务需实现三个接口，侵入性强但性能好。
10.3 Saga 模式
Saga 将长事务拆分为一系列本地事务，每个本地事务有对应的补偿事务。任一步骤失败，执行已完成步骤的补偿操作回滚。分为编排式（Orchestration）和协同式（Choreography）两种。
| 方案 | 一致性 | 性能 | 复杂度 | 侵入性 |
|---|---|---|---|---|
| 2PC | 强一致 | 差 | 中 | 低 |
| 3PC | 强一致 | 差 | 高 | 低 |
| TCC | 强一致 | 好 | 高 | 高 |
| Saga | 最终一致 | 好 | 中 | 中 |
| 本地消息表 | 最终一致 | 中 | 低 | 中 |
案例：订单支付分布式事务
电商下单涉及订单服务、库存服务、支付服务三个独立数据库。采用 Saga 编排式方案：T1 创建订单(待处理) → T2 扣减库存 → T3 扣减余额 → T4 订单状态改为已支付。若 T3 余额不足，Saga 协调器依次执行补偿：C2 回滚库存 → C1 取消订单。最终一致性通过消息重试和幂等保证。相比 2PC，性能提升 5 倍，且无长时间锁资源。
十一、分布式链路追踪与可观测性
微服务环境下，一个请求可能经过数十个服务，故障定位极其困难。可观测性（Observability）通过三大支柱帮助理解系统内部状态。
案例：跨 5 个服务的请求追踪
用户下单请求经网关 → 订单 → 库存 → 支付 → 通知 5 个服务，总耗时 800ms 异常。通过 Jaeger 查看 Trace 发现支付服务耗时 500ms（正常 100ms），进一步定位是支付服务的数据库慢查询。OpenTelemetry 统一了三大支柱的数据采集标准，避免多套 SDK 维护负担。
十二、微服务安全
微服务安全涉及外部访问安全和服务间通信安全两个层面。
· OAuth 2.0：授权框架，四种授权模式（授权码、简化、密码、客户端凭证）
· JWT：Header.Payload.Signature，无状态令牌，自包含用户信息
· mTLS：双向 TLS 认证，服务间互验证书，防中间人攻击
十三、云原生实战案例
综合前述所有组件，构建一个完整的云原生电商系统架构。
案例：技术栈选型与经验总结
技术选型：网关 Spring Cloud Gateway；注册/配置 Nacos；熔断 Sentinel；追踪 SkyWalking；编排 K8s+ArgoCD；数据库 MySQL+Redis+ES。
踩坑经验：① 初期服务拆分过细（30个），运维负担重，后合并到 12 个；② 分布式事务选用 Saga + 本地消息表混合方案；③ 链路追踪采样率初期 100% 影响性能，调整为 10%；④ ConfigMap 存敏感配置导致泄露，迁移到 Vault；⑤ HPA 扩容滞后，提前配置预热。
收益：交付频率从月级到日级；大促扩容从 2 小时缩到 10 分钟；可用性 99.95%→99.99%。
十四、软考考点总结
1. 架构演进：单体 → SOA(ESB) → 微服务(去中心化) → 云原生(容器+DevOps)
2. 微服务特征：独立部署、独立数据库、去中心化、技术多样性、轻量通信
3. 拆分方法：按业务能力、按 DDD 限界上下文；判断标准：高内聚低耦合
4. 核心组件：API网关、服务注册发现、配置中心、服务网格、熔断器
5. Docker：镜像/容器/Dockerfile/仓库；容器 vs 虚拟机（共享内核、轻量）
6. K8s：Master(apiserver/scheduler/etcd/controller) + Worker(kubelet/kube-proxy)；Pod/Deployment/Service
7. 云原生四要素：微服务、容器化、DevOps、持续交付
8. 通信：REST/gRPC 同步，Kafka/RabbitMQ 异步
9. 分布式事务：2PC、TCC、Saga、本地消息表；CAP/BASE 理论
10. 可观测性：日志、指标、追踪三大支柱
| 易混淆点 | 辨析 |
|---|---|
| SOA vs 微服务 | SOA 用 ESB 中心化总线；微服务去中心化、独立数据库、轻量通信 |
| 容器 vs 虚拟机 | 容器共享内核、秒级启动、MB级；虚拟机完整OS、分钟级、GB级 |
| 熔断 vs 降级 vs 限流 | 熔断切断故障调用；降级返回兜底；限流控制速率 |
| CI vs CD vs CD | 持续集成(构建测试) → 持续交付(可发布) → 持续部署(自动上线) |
| 2PC vs TCC vs Saga | 2PC 资源层强一致；TCC 业务层强一致；Saga 最终一致+补偿 |
| AP vs CP 注册中心 | Eureka(AP可用) vs Zookeeper/Consul(CP一致) |
· 微服务四原则："高内聚、独立部、去中心、技术多"
· 云原生四要素："微、容、Dev、持"
· 熔断三态："闭→开→半"（Closed→Open→Half-Open）
· 可观测三支柱："日、指、追"（Logging/Metrics/Tracing）
· K8s Master 四组件："API、etcd、sched、ctrl"
1. 选择题：微服务特征、组件职责、K8s 概念、CAP 定理
2. 简答题：对比 SOA 与微服务、容器与虚拟机、各分布式事务方案
3. 论述题：给定场景设计微服务架构（拆分方案、组件选型、事务处理）
4. 案例分析：分析架构问题、给出改进建议（如拆分过细、缺少熔断、数据一致性问题）
微服务与云原生是系统架构设计师考试的现代架构核心考点。掌握演进路线、核心组件、分布式难题（事务/追踪/安全）的解决方案，并能结合实际场景做权衡设计，是考试通过的关键。架构没有银弹，权衡（Trade-off）始终是架构师最重要的能力。