软考
新技术与Web架构
SOA/微服务、DevOps/云原生、大数据与云计算、2024-2025软考高频新方向速查表
一句话定位
本表覆盖软考 §3.9 新技术与Web架构，是案例第 2 题、论文高频考点（微服务拆分、分布式事务、高并发架构设计），也是 2024-2025 年真题新增方向（Serverless/秒杀/性能测试/EDA/Lambda）的集中汇总。
IMPORTANT
- 案例常考模式: 给出某业务场景，要求分析采用何种架构风格、拆分策略及分布式事务方案。
- 论文常考: “基于微服务的系统架构设计”——需写出服务拆分、熔断限流、分布式事务、DevOps 部署等完整方案。
- 本表内容量大，优先掌握加粗部分及对比表。
A. SOA / Web Services / REST
A.1 SOA 与微服务对比
| 维度 | SOA | 微服务 |
|---|---|---|
| 服务粒度 | 粗粒度（一个服务可能包含多个子系统） | 细粒度（一个服务对应一个业务领域） |
| 通信方式 | ESB 总线集中式通信（SOAP/XML） | 轻量级通信（HTTP/gRPC/消息队列） |
| 部署方式 | 通常统一部署 | 独立部署、独立运行 |
| 数据库 | 共享数据库 | 每个服务独立数据库 |
| 技术栈 | 统一技术栈 | 多种技术栈并存（Polyglot） |
| 运维 | 传统运维 | DevOps、持续交付 |
| 复杂度 | 治理复杂、重量级 | 运维复杂、轻量级 |
| 代表 | 传统企业应用集成 | 互联网分布式系统 |
NOTE
SOA 与微服务并不是简单的替代关系。微服务是 SOA 的一种轻量级实现，去掉了 ESB 的重量级编排，强调”高内聚、低耦合”的细粒度拆分。
A.2 Web Services 协议栈
| 协议 | 全称 | 作用 | 记忆点 |
|---|---|---|---|
| SOAP | Simple Object Access Protocol | 基于 XML 的通信协议，定义消息格式 | ”S”冰淇凌: SOAP |
| WSDL | Web Service Description Language | 描述服务接口（方法、参数、返回值） | 类似 Java 接口定义 |
| UDDI | Universal Description Discovery and Integration | 服务注册与发现 | 类似”服务黄页” |
A.3 REST 六大约束 + 与 SOAP 对比
REST（Representational State Transfer）并非协议，而是一种架构风格。
REST 六大约束：
- 客户端-服务器（Client-Server）：关注点分离
- 无状态（Stateless）：每个请求包含所有必要信息，服务器不保存客户端状态
- 可缓存（Cacheable）：响应必须显式标识是否可缓存
- 统一接口（Uniform Interface）：统一资源标识（URI）、资源多重表示、自描述消息、超媒体（HATEOAS）
- 分层系统（Layered System）：客户端不知道是否直连最终服务器
- 按需代码（Code on Demand，可选）：服务器可下发代码扩展客户端功能
| 对比维度 | REST | SOAP |
|---|---|---|
| 协议 | HTTP | 可基于多种协议（HTTP/SMTP/TCP等） |
| 消息格式 | JSON/XML（首选JSON） | XML only |
| 接口描述 | 无（或用OpenAPI） | WSDL |
| 调用方式 | 资源操作（GET/POST/PUT/DELETE） | 远程过程调用（RPC风格） |
| 安全性 | HTTPS + OAuth | WS-Security协议 |
| 性能 | 轻量、延迟低 | 较重、解析开销大 |
| 适用场景 | Web API、移动后端 | 企业级集成、金融系统 |
| 可读性 | 高（URL语义化） | 低（XML嵌套复杂） |
B. 微服务架构
B.1 拆分原则（DDD）
微服务拆分的核心依据是领域驱动设计(DDD)。
| 拆分原则 | 说明 | 反例/注意 |
|---|---|---|
| 按业务能力拆分 | 每个服务对应一个业务领域 | 避免按技术层拆分（如所有服务的DAO层算一个服务） |
| 高内聚低耦合 | 服务内部紧密相关，服务间接口最小化 | 避免循环依赖 |
| 独立部署 | 每个服务可独立打包、独立部署 | 避免”部署一个服务需要重启整个系统” |
| 数据独立性 | 每个服务有自己的数据库 | 避免多个服务直接操作同一张表 |
| 团队自治 | ”2 Pizza 团队”（6~10人） | 避免一个团队维护过多服务 |
B.2 服务注册与发现对比
| 组件 | 开发方 | 协议/架构 | 特点 | 适用场景 |
|---|---|---|---|---|
| Eureka | Netflix | AP 架构（自我保护机制） | 简单、自我保护（防止网络分区时误杀） | Spring Cloud 生态 |
| Nacos | 阿里巴巴 | AP+CP 可配置 | 支持服务发现 + 配置管理一体化 | 国内主流、云原生 |
| Consul | HashiCorp | 支持多数据中心 | 服务发现 + KV存储 + 健康检查 | 跨数据中心 |
| ZooKeeper | Apache | CP 架构（ZAB协议） | 强一致性、老牌 | Dubbo 早期默认 |
WARNING
CAP 是关键区分点：Eureka 是 AP（可用性+分区容错），牺牲一致性；ZooKeeper 是 CP（一致性+分区容错），牺牲可用性。网络分区时，Eureka 保留所有注册信息（可能包含已挂节点），ZooKeeper 可能拒绝服务直到选出新的 leader。
B.3 API 网关职责
API 网关是微服务的统一入口，核心职责：
| 职责 | 说明 | 常用技术 |
|---|---|---|
| 路由 | 根据 URL/Header 转发到对应服务 | Nginx、Spring Cloud Gateway |
| 鉴权 | 统一身份认证与权限校验 | JWT、OAuth2 |
| 限流 | 控制请求速率，防止系统过载 | 令牌桶、漏桶 |
| 熔断 | 服务故障时快速失败，防止雪崩 | Hystrix、Sentinel |
| 负载均衡 | 请求分发到多个服务实例 | Ribbon、Nginx |
| 协议转换 | HTTP ↔ gRPC、REST ↔ SOAP | 网关层适配 |
| 日志/监控 | 统一请求日志、监控埋点 | Prometheus、ELK |
B.4 熔断降级与限流
熔断降级组件
| 组件 | 开发方 | 功能特点 | 现状 |
|---|---|---|---|
| Hystrix | Netflix | 熔断、降级、隔离（舱壁模式）、请求缓存 | 已进入维护模式 |
| Sentinel | 阿里巴巴 | 流量控制、熔断降级、系统负载保护、热点参数限流 | 国内主流、活跃维护 |
熔断（Circuit Breaker）三状态：Closed（关闭/正常）→ Open（打开/熔断）→ Half-Open（半开/试探）。
限流算法对比
| 维度 | 令牌桶 (Token Bucket) | 漏桶 (Leaky Bucket) |
|---|---|---|
| 原理 | 以固定速率放入令牌，请求消耗令牌 | 以固定速率漏出请求，请求先进入桶 |
| 突发流量 | 允许一定程度的突发（桶内有令牌即可） | 平滑输出，不允许突发 |
| Rate | 平均速率 + 突发速率 | 固定速率 |
| 适用 | 电商秒杀（允许突发） | 视频流控（平滑输出） |
| 类比 | 银行柜台：有token才能办业务 | 医院输液：固定滴速 |
B.5 分布式事务方案（重点）
| 方案 | 一致性 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|---|
| 2PC | 强一致 | 预提交 → 确认提交/回滚 | 原理简单 | 同步阻塞、单点故障、性能差 | 传统数据库XA |
| 3PC | 强一致 | 引入CanCommit + 超时机制 | 减少阻塞 | 复杂度高、仍有不一致可能 | 理论了解 |
| TCC | 最终一致 | Try(预留) → Confirm(确认) → Cancel(取消) | 性能较好 | 业务侵入性强、幂等难保证 | 电商库存、支付 |
| Saga | 最终一致 | 长事务拆分为本地事务，故障时补偿 | 适合长事务 | 补偿逻辑复杂 | 旅游预订、物流 |
| 本地消息表 | 最终一致 | 本地事务 + 消息表 + 定时扫描 | 简单可靠 | 需额外维护消息表 | 异步通知 |
| 最大努力通知 | 最终一致 | 多次通知直到成功 | 简单 | 不保证一定送达 | 支付回调 |
| Seata | 最终一致/AT模式近强一致 | 阿里开源，AT(自动补偿)/TCC/Saga模式 | 对业务侵入小(AT) | 需引入Seata Server | 微服务分布式事务 |
IMPORTANT
考试重点：
- 2PC/3PC 是强一致性，但性能差、阻塞，适用于传统单体数据库。
- TCC/Saga/Seata(AT) 是最终一致性，适用于微服务分布式场景。
- 案例题常问：“某电商系统订单-库存-支付，应该采用什么分布式事务方案？“——答案通常是 TCC 或 Seata AT 模式。
B.6 微服务配套设施
| 设施 | 作用 | 代表产品 |
|---|---|---|
| 配置中心 | 集中管理配置，动态推送 | Nacos、Apollo、Spring Cloud Config |
| 链路追踪 | 追踪请求在微服务间的完整调用路径 | SkyWalking、Zipkin、Jaeger |
| 日志聚合 | 集中收集日志，全文检索 | ELK（Elasticsearch+Logstash+Kibana） |
| Service Mesh本体（服务网格） | 服务间通信的基础设施层（ Sidecar 代理） | Istio、Linkerd |
Service Mesh（服务网格）：将服务间的通信逻辑（负载均衡、熔断、安全、监控）从业务代码中抽离，由 Sidecar 代理（如 Envoy）统一处理。Istio 是目前最流行的 Service Mesh 实现。
B.7 微服务调用链 Mermaid 图
C. DevOps / 容器
C.1 CI/CD 与 CALMS 原则
| 缩写 | 全称 | 说明 |
|---|---|---|
| CI | Continuous Integration（持续集成） | 代码合并后自动编译、测试 |
| CD (交付) | Continuous Delivery（持续交付） | 自动部署到类生产环境，可手动上 |
| CD (部署) | Continuous Deployment（持续部署） | 自动部署到生产环境 |
CALMS 原则（DevOps 核心理念）：
- Culture（文化）：协作文化，打破开发与运维壁垒
- Automation（自动化）：自动化构建、测试、部署
- Lean（精益）：消除浪费，持续改进
- Measurement（度量）：可度量的指标驱动改进
- Sharing（分享）：知识共享、团队透明
Infrastructure as Code（基础设施即代码）：通过 Terraform、Ansible 等工具将基础设施配置代码化，实现版本控制和自动化管理。
C.2 Docker 核心概念
| 概念 | 说明 | 类比 |
|---|---|---|
| 镜像(Image) | 只读模板，包含运行应用所需的所有内容 | 类固醇增强版的”安装包” |
| 容器(Container) | 镜像的运行实例，相互隔离 | 轻量级虚拟机 |
| 仓库(Repository) | 镜像的集中存储与分发 | 类似 Maven 仓库/Github |
| Dockerfile | 定义镜像构建步骤的脚本 | ”食谱” |
| Volume | 容器数据持久化存储 | 外挂硬盘 |
C.3 Kubernetes 核心对象表
| 对象 | 作用 | 考试要点 |
|---|---|---|
| Pod | K8s 最小调度单元，可包含多个容器 | 共享网络/存储，同生共死 |
| Deployment | 管理 Pod 的部署与滚动更新 | 声明式部署，自动扩缩容 |
| Service | 为一组 Pod 提供统一访问入口 | 负载均衡、服务发现 |
| Ingress | 集群外部访问的 HTTP 路由规则 | 域名/路径路由 |
| ConfigMap | 存储非敏感配置信息 | 与 Secret 区分（Secret 存敏感信息） |
| Namespace | 资源隔离与逻辑分组 | 多租户环境隔离 |
| Master 节点 | 控制平面（API Server / Scheduler / Controller Manager） | 管理调度 |
| Node 节点 | 工作节点，运行 Pod | 实际承载工作负载 |
| etcd | 分布式键值存储一无keeper-like存储集群状态 | K8s 的数据库 |
| 自动伸缩(HPA) | 根据 CPU/内存等指标自动扩缩 Pod 数量 | Horizontal Pod Autoscaler 缩写 |
D. 云计算 / 大数据
D.1 云服务模式对比
| 模式 | 全称 | 提供商管理 | 用户管理 | 例子 |
|---|---|---|---|---|
| IaaS | Infrastructure as a Service | 机房、网络、硬件 | OS、中间件、应用 | AWS EC2、阿里云 ECS |
| PaaS | Platform as a Service | 硬件、OS、中间件 | 应用、数据 | Heroku、Google App Engine |
| SaaS | Software as a Service | 全部 | 仅使用 | 钉钉、Salesforce |
D.2 部署模式
| 模式 | 定义 | 适用 |
|---|---|---|
| 公有云 | 第三方提供，多租户共享 | 互联网应用、弹性需求 |
| 私有云 | 企业自建，独享资源 | 金融、政务、数据安全要求高 |
| 混合云 | 公有+私有，数据与应用分层 | 核心业务私有、扩展业务公有 |
| 社区云 | 特定组织/行业共享 | 医疗、教育等行业联盟 |
D.3 虚拟化 vs 容器 vs 云原生
| 对比项 | 虚拟机(VM) | 容器(D=Docker) |
|---|---|---|
| 启动速度 | 分钟级 | 秒级 |
| 资源占用 | 高（需完整OS） | 低（共享宿主机内核） |
| 隔离性 | 强（硬件级隔离） | 弱（进程级隔离） |
| 镜像大小 | 大（GB级） | 小（MB级） |
| 适用场景 | 需要强隔离的多租户 | 微服务、DevOps |
云原生四要素：微服务 + 容器 + DevOps + 持续交付。
D.4 大数据技术栈
大数据 5V 特征
| V | 含义 | 说明 |
|---|---|---|
| Volume | 大量 | 数据规模大（TB/PB级） |
| Velocity | 高速 | 数据产生与处理速度快 |
| Variety | 多样 | 结构化/半结构化/非结构化 |
| Value | 价值密度低 | 海量数据中有价值信息少 |
| Veracity | 准确性 | 数据质量与可信度 |
Hadoop 生态
| 组件 | 作用 | 类比 |
|---|---|---|
| HDFS | 分布式文件存储 | 超大号”网盘” |
| MapReduce | 分布式计算框架 | 分而治之：Map 分，Reduce 合 |
| Yarn | 资源调度管理 | 资源”管家” |
Spark vs Flink
| 对比项 | Spark | Flink |
|---|---|---|
| 计算模式 | 批处理为主，流处理为批处理模拟 | 真正的流计算（Native Streaming） |
| 核心抽象 | RDD（弹性分布式数据集） | DataStream |
| 延迟 | 秒级/分钟级（微批处理） | 毫秒级 |
| 适用 | 离线计算、机器学习 | 实时流处理（风控、推荐） |
| 特点 | 内存计算，速度快 sincronizada MapReduce | 低延迟、Exactly-Once |
D.5 数据存储架构对比
| 概念 | 定义 | 特点 | 代表 |
|---|---|---|---|
| 数据仓库 | 面向主题的、集成的、相对稳定的、反映历史变化的数据集合 | 结构化、面向分析、OLAP | Hive、Teradata、ClickHouse |
| 数据湖 | 存储原始格式数据的存储库 | 存原始数据、Schema-on-read | AWS S3、HDFS |
| 湖仓一体 | 结合数据湖的灵活性与数据仓库的规范性 | 统一存储、批流一体 | Delta Lake、Iceberg |
D.6 NoSQL 四类型
| 类型 | 特点 | 代表 | 适用场景 |
|---|---|---|---|
| 键值型 | 简单、高性能 | Redis、LevelDB | 缓存、会话存储 |
| 列族型 | 高写入、可扩展 | HBase、Cassandra | 日志、时序数据 |
| 文档型 | 灵活的类JSON结构 | MongoDB、CouchDB | 内容管理、用户资料 |
| 图型 | 关系查询高效 | Neo4j、JanusGraph | 社交网络、知识图谱 |
TIP
Redis 缓存注意点：缓存穿透（查询不存在数据→布隆过滤器）、缓存击穿（热点key过期→互斥锁/逻辑过期）、缓存雪崩（大量key同时过期→随机过期时间/多级缓存）。
D.7 消息队列与认证
| 组件 | 作用 | 代表 |
|---|---|---|
| 消息队列 | 削峰填谷、异步解耦、流量控制 | Kafka、RabbitMQ、RocketMQ |
| Redis | 高速缓存、会话共享、分布式锁 | 单线程+IO多路复用 |
| JWT | 无状态认证令牌（Header.Payload.Signature） | 常用于前后端分离 |
| OAuth2 | 授权框架，第三方应用无需存储用户密码 | 微信/QQ 登录 |
D.8 CAP vs BASE
| 定理 | 定义 | 核心思想 |
|---|---|---|
| CAP | Consistency、Availability、Partition Tolerance | 三者不可兼得，分布式系统只能同时满足两个 |
| BASE | Basically Available、Soft state、Eventually consistent | 牺牲强一致性，追求可用性和分区容错性 |
CAP 取舍：
- CP（一致性+分区容错）：ZooKeeper、HBase
- AP（可用性+分区容错）：Eureka、Cassandra、DynamoDB
E. 近年新高频方向（2024-2025 真题统计）
WARNING
以下方向为案例与论文的”新出题方向”，2024-2025 年真题中频繁出现，右必掌握核心概念与优缺点。
E.1 Serverless 无服务器架构
- FaaS（Function as a Service）：函数即服务，代码按函数粒度部署，事件触发执行，自动弹性伸缩。
- BaaS（Backend as a Service）：后端即服务，将数据库、认证、存储等后端能力以 API 形式提供。
- 优势：无需管理服务器、按量计费、自动扩缩容、开发效率高。
- 劣势：冷启动延迟、调试困难、供应商锁定（Vendor Lock-in）、不适合长时间运行任务。
E.2 秒杀/高并发场景
- 核心挑战：瞬时高并发（容量）、超卖（一致）、大流量（带宽）。
- 解决方案：
- 限流：入口限流（网关）、应用限流（Sentinel）、数据库限流（连接池）
- 熔断降级：非核心功能熔断保核心，Hystrix/Sentinel
- 缓存：多级缓存（浏览器-CDN-应用-Redis）、热点数据预热
- 动静分离：静态资源 CDN 分发，动态请求走应用集群
- 队列削峰：消息队列（RocketMQ/Kafka）异步处理订单，平滑流量
E.3 性能测试
论文 2025-11 出现”性能测试”相关考点。
- 负载测试：确定系统在各种工作负载下的性能指标，寻找性能拐点。
- 压力测试：超过正常负载，测试系统在极限条件下的行为和恢复能力。
- 并发测试：模拟多用户并发操作，发现资源竞争、死锁等问题。
- 性能指标：响应时间、吞吐量(TPS/QPS)、资源利用率、并发用户数、错误率。
E.4 事件驱动架构 EDA
- 定义：以事件为核心驱动，系统由事件生产、路由、消费组成。
- 教材映射：对应教材”事件驱动”架构风格（隐式调用），是微服务异步通信的重要实现方式。
- 核心组件： events生产者, 事件总线(Event Bus/Broker), 事件消费者(Event Consumer)
- 优点：高度解耦、可扩展、实时响应；缺点：消息顺序难保证、调试复杂、数据一致性挑战。
E.5 “Lambda 架构
- 三层结构：
- 批处理层（Batch Layer）：全量历史数据的离线计算，保证准确性
- 速度层（Speed Layer）：实时流处理新数据，保证低延迟
- 服务层（Serving Layer）：合并批处理层和速度层结果，提供统一查询
- 适用场景：大数据实时分析（日志分析、用户行为分析）。
- 演进：Kappa 架构（只用流处理，简化 Lambda）。
E.6 区块链（概要）
- 共识机制：PoW（工作量证明，比特币，能耗高）、PoS（权益证明，以太坊2.0，持币量决定出块权）
- 智能合约：运行在区块链上的自动执行脚本，code is law
- 特点：去中心化、不可篡改、透明可追溯
E.7 AI/ML/DL 概念概要
| 概念 | 全称 | 说明 |
|---|---|---|
| ** chimney | Artificial Intelligence | |
| ML | Machine Learning | 机器学习，从数据中学习规律，无需显式编程 |
| DL | Deep Learning | 深度学习，基于多层神经网络的机器学习方法 |
| 常用算法 | — | 神经网络、决策树、SVM、K-Means、CNN/RNN |
| 应用场景 | — | 图像识别、NLP、推荐系统、自动驾驶 |
F. 记忆口诀与易错点
微服务拆分 DDD 口诀
“限界上下文画边界，聚合根内聚实体；应用服务调领域，防腐层隔离外部。“
分布式事务选型口诀
“强一致选 2PC，高并发选 TCC；长事务用 Saga，自动补偿 Seata。“
熔断限流速记
“熔断三板斧：关闭-打开-半打开；限流两把桶：令牌允许突发，漏桶平滑输出。“
云计算服务模式速记
“IaaS 租硬件（阿里云ECS），PaaS 租平台（Google App Engine），SaaS 租软件（钉钉）。“
易错点汇总
WARNING
- REST 不是协议，是架构风格；SOAP 才是 protocol 。
- CAP 三选二：分区容错(P)是必选项，因此实际只选 CP 或 AP。
- Seata AT 模式是最终一致，不是强一致（通过 UNDO_LOG 反向补偿）。
- Lambda 架构 vs Kappa 架构：前者批+流两层，后者只有流处理层。
- Serverless 不是无服务器：还是服务器**：服务器仍然存在，只是由云厂商托管，开发者不可见。
G. 自测题（检验掌握程度）
-
某电商系统需要将单体应用拆分为微服务，订单、库存、支付分别独立部署。这种拆分依据是什么？
点击查看答案
领域驱动设计(DDD)的限界上下文。按业务能力（订单/库存/支付）进行拆分，每个服务对应一个限界上下文，独立数据库、独立部署。 -
令牌桶和漏桶限流算法的核心区别是什么？分别适合什么场景？
点击查看答案
令牌桶允许突发流量（桶内有令牌即可通过），适合电商秒杀等需要应对突发请求的场景；漏桶严格限制输出速率，平滑流量，适合视频流控、API 限流等需要稳定输出的场景。 -
简述 2PC 和 TCC 分布式事务方案的异同。
点击查看答案
相同点：都属于分布式事务解决方案。
不同点：2PC 是强一致性，通过预提交和确认提交实现，同步阻塞、性能差，适用于传统数据库 XA 事务；TCC 是最终一致性，需要业务层实现 Try/Confirm/Cancel 三个阶段，性能较好但业务侵入性强，适用于电商库存扣减等高并发场景。 -
Kubernetes 中，Pod 和 Deployment 的区别是什么？
点击查看答案
Pod是 K8s 的最小调度单元，可包含多个容器（同生共死）；Deployment是更高层的抽象，用于管理 Pod 的部署、滚动更新和自动扩缩容。Deployment 通过 ReplicaSet 确保指定数量的 Pod 副本在运行。 -
CAP 定理中，分区容错(P)为什么是必须选择的？实际应用中选择 CP 还是 AP？
点击查看答案
因为网络分区(P)在分布式系统中不可避免，只能尽量容忍。实际选择取决于业务需求：CP（如 ZooKeeper、HBase）适合对一致性要求高的场景（金融交易）；AP（如 Eureka、Cassandra）适合对可用性要求高的场景（社交网络）。
IMPORTANT
如果只能”看着面熟”但说不出来，说明还没真正掌握，建议回看对应章节并多做真题。本表要求掌握核心对比表、分布式事务选型、微服务组件职责等可默写内容。
上一篇导引：架构核心速查表涵盖架构风格对比、质量属性战术、ATAM/SAAM 评估流程。 下一篇导引：案例分析模板（待产）将提供软考案例题的答题套路与万能模板。