💡 备考紧急提醒：距离软件架构设计师考试仅剩最后阶段，本文汇总考试全模块常见知识点，涵盖综合知识、案例分析、论文三大科目，按公众号阅读习惯排版，重点标红、分层清晰，可直接收藏背诵、打印刷题，帮你高效冲刺，查漏补缺！
软件架构设计师考试属于软考高级资格考试，核心考察考生对软件架构设计、系统开发、技术选型、性能优化、安全保障等核心能力的掌握，考试分为三大科目：信息系统综合知识（上午选择题，75分）、系统架构设计案例分析（下午问答题，75分）、系统架构设计论文（下午论文题，75分），三科均达到45分及以上即可通过考试。
软件架构基础（综合知识高频，案例分析基础）
一、软件架构核心概念
软件架构是系统的一组关键决策，包括结构元素及其相互关系、行为特征的外部可见属性、设计原理与约束条件，是软件系统的高层结构，决定了系统的质量属性、可扩展性、可维护性等核心特性，是连接需求分析与系统实现的桥梁，也是架构设计师考试的基础核心考点，在上午选择题中每年考察4-6题，占12-18分，案例分析中也会作为基础考点出现。
1. 核心定义（必背）
软件架构 = 组件（构件） + 连接件 + 约束
组件（构件）：系统中可独立替换、具有明确功能边界的模块，是构成系统的基本单元，分为业务构件（实现核心业务逻辑）和技术构件（提供通用技术支持，如日志、缓存）。
连接件：用于连接组件，实现组件间的通信与交互，常见的有接口、消息传递、远程调用（RPC）、管道等，是组件协同工作的核心。
约束：对组件、连接件的设计和交互方式的限制，包括技术约束（如编程语言、框架选型）、业务约束（如业务流程规范）、性能约束（如响应时间、并发量）等。
2. 软件架构的作用（高频考点）
协调利益相关者：平衡用户、开发人员、运维人员等不同角色的需求（如用户关注易用性，开发人员关注可开发性，运维人员关注可维护性）。
指导系统开发：为系统设计、编码、测试、部署提供统一的框架和标准，避免开发混乱。
决定系统质量：架构设计直接影响系统的性能、可用性、安全性、可扩展性等非功能属性，是系统质量的“基石”。
降低开发风险：提前规避技术选型、组件交互等方面的风险，减少后期返工成本。
3. 软件架构与设计模式的区别（易混淆点）
很多考生会混淆“软件架构”和“设计模式”，两者核心区别的考点在选择题中频繁出现，需重点区分：
对比维度 | 软件架构 | 设计模式 |
粒度 | 宏观层面，关注系统整体结构和组件间的关系 | 微观层面，关注具体模块内部的设计思路和代码实现 |
作用范围 | 整个系统或大型子系统 | 单个模块或少量模块的交互 |
核心目的 | 平衡系统质量属性，满足业务需求和技术约束 | 解决特定场景下的代码复用、解耦问题 |
例子 | 分层架构、微服务架构、管道-过滤器架构 | 单例模式、工厂模式、观察者模式 |
二、软件架构视图（必考考点）
软件架构视图是从不同角度描述系统架构的方式，每个视图对应不同利益相关者的需求，考试中重点考察“4+1视图模型”，选择题和案例分析题均会涉及，需熟练掌握每个视图的核心内容和作用。
1. 4+1视图模型（核心，必背）
由Philippe Kruchten提出，是软件架构设计的经典视图模型，也是考试中最常考的视图模型，5个视图相互补充，完整描述系统架构：
逻辑视图（Logical View）
开发视图（Development View）
进程视图（Process View）
物理视图（Physical View）
场景视图（Scenario View）
2. 其他常见视图（了解，选择题可能涉及）
数据视图：描述系统的数据结构、数据存储、数据流转，关注数据的完整性、一致性、安全性，对应E-R图、数据流程图（DFD）。
安全视图：描述系统的安全架构，包括安全策略、访问控制、加密机制、安全审计等，对应安全架构设计方案。
性能视图：描述系统的性能指标、性能优化策略，关注响应时间、并发量、吞吐量等，对应性能测试报告和优化方案。
三、软件架构设计原则（综合知识+案例分析高频）
软件架构设计需遵循一系列原则，这些原则是架构设计的指导思想，也是案例分析题中“架构设计合理性分析”“优化方案”的核心考点，需熟练掌握每个原则的含义、应用场景和注意事项。
1. 核心设计原则（必背，案例分析可直接套用）
高内聚、低耦合（最核心原则）
单一职责原则（SRP）
开闭原则（OCP）
依赖倒置原则（DIP）
接口隔离原则（ISP）
迪米特法则（最少知识原则，LOD）
里氏替换原则（LSP）
2. 设计原则的应用总结（案例分析答题模板）
案例分析题中，常要求“分析该架构设计是否合理，并说明理由”“如何优化该架构”，此时可套用以下模板：
该架构设计符合/不符合软件架构设计原则，具体分析如下：
是否符合高内聚低耦合原则：组件划分是否清晰，功能是否单一，组件间依赖是否较少，接口是否规范。
是否符合开闭原则：是否支持扩展，新增需求时是否需要修改原有代码，扩展方式是否合理。
是否符合单一职责原则：每个组件、接口是否只负责一个职责，避免职责冗余。
优化建议：基于设计原则，提出优化方案（如拆分功能混乱的组件、规范接口设计、采用抽象接口降低依赖等）。
四、软件架构生命周期（了解，选择题考点）
软件架构的生命周期与软件生命周期对应，分为5个阶段，每个阶段的核心任务是选择题的常见考点，需掌握各阶段的重点：
架构需求阶段：收集和分析利益相关者的需求（功能需求、非功能需求），明确架构设计的目标和约束，输出《架构需求规格说明书》。
架构设计阶段：根据架构需求，选择合适的架构风格、组件划分、连接件设计，输出《架构设计说明书》（核心阶段）。
架构实现阶段：根据架构设计，进行组件开发、接口实现、集成测试，将架构设计落地为实际系统。
架构部署阶段：将实现后的系统部署到目标环境，进行系统调试、性能测试，确保系统正常运行。
架构演化阶段：根据业务需求的变化、技术的升级，对架构进行调整和优化，确保架构始终适应系统的需求（如从单体架构演化为微服务架构）。
模块二：软件架构风格（必考模块，综合知识+案例分析+论文）
软件架构风格是软件架构的“模板”，是一组可复用的架构设计模式，描述了系统的组织方式和惯用模式，反映了领域中众多系统所共有的结构和语义特征。一个架构风格定义了一个词汇表和一组约束，词汇表包含构件和连接件的类型，约束规定了系统是如何将这些构件和连接件组合起来的。考试中，该模块是重中之重，选择题每年必考，案例分析题常要求“选择合适的架构风格”“分析不同架构风格的优缺点”，论文题也常以某类架构风格（如微服务、分层架构）为主题，需全面掌握各类架构风格的定义、优缺点、适用场景、典型案例。
一、经典架构风格（五大类，必背）
根据Garlan & Shaw的分类，软件架构风格可分为五大类，每类包含多个具体的子风格，需逐个掌握：
（一）数据流风格（流水线作业式）
核心特征：系统由一系列处理组件组成，数据以数据流的形式在组件间传递，前一个组件的输出是后一个组件的输入，强调数据的线性处理流程，组件之间是松耦合的，专注于数据的转换和处理。
1. 管道-过滤器风格（Pipe-Filter）
定义：每个构件（过滤器）都有一组输入和输出，构件读取输入的数据流，经过内部处理（计算或增值），产生输出数据流；连接件（管道）负责将一个过滤器的输出传递给另一个过滤器，形成一条流水线式的处理流程。
核心组件：过滤器（处理数据）、管道（传递数据）。
优点：
缺点：
适用场景：批处理系统、编译器（词法分析→语法分析→语义分析→目标代码生成，符合流水线处理）、传统信号处理系统、数据清洗系统。
考试考点：管道-过滤器风格的定义、优缺点、适用场景，与其他风格（如仓库风格）的对比，编译器场景下的应用。
2. 顺序批处理风格
定义：将数据处理分为多个步骤，每一步必须完全结束后，下一步才能开始；最核心的特征是数据必须是完整的，以整体的方式传递，不能并发处理数据流（区别于管道-过滤器风格）。
与管道-过滤器的区别：管道-过滤器可并行处理数据流，而顺序批处理必须串行执行，数据以整体形式传递（如先读取完整的文件，再进行处理，处理完成后再输出完整文件）。
适用场景：数据批量处理（如每天凌晨的订单统计、日志分析）、文件转换（如将CSV文件转换为Excel文件）。
考试坑点：若题干中强调“程序源代码作为一个整体，依次在不同模块中进行传递”，优先选顺序批处理，而非管道-过滤器风格。
（二）调用/返回风格（发号施令式）
核心特征：系统由多个组件组成，组件之间通过“调用-返回”的方式进行交互，一个组件调用另一个组件的接口，获取返回结果，强调组件间的同步交互，适合处理复杂的业务逻辑。
1. 主程序/子程序风格
定义：系统由一个主程序和多个子程序组成，主程序负责调用子程序，子程序完成具体的功能，执行完成后返回结果给主程序，主程序统一协调所有子程序的执行流程。
核心组件：主程序（协调者）、子程序（功能执行者）。
优点：结构简单、易于理解和实现，适合小型系统或简单的业务逻辑。
缺点：耦合度高（主程序与子程序直接依赖），可扩展性差（新增功能需修改主程序），不适合大型复杂系统。
适用场景：小型工具类软件（如计算器、文本编辑器）、简单的脚本程序。
2. 面向对象风格
定义：系统由多个对象组成，对象包含属性（数据）和方法（行为），对象之间通过消息传递进行交互，封装、继承、多态是核心特性，强调“万物皆对象”。
核心组件：对象（封装数据和行为）、消息（对象间的交互方式）。
优点：
缺点：
适用场景：大型复杂系统、业务逻辑多变的系统（如电商系统、管理系统）。
考试考点：面向对象风格的核心特性（封装、继承、多态）、优缺点、与其他风格（如解释器风格）的对比。
3. 层次结构风格（分层架构）
定义：将系统垂直划分为若干层，每一层只与其直接相邻的上层和下层交互，不允许跨层交互，每一层都有明确的职责，层与层之间通过接口通信。
常见分层（必背，案例分析常考）：
优点：
缺点：
适用场景：企业级应用、Web应用、管理系统（如ERP、CRM系统），是最常用的架构风格之一。
考试考点：分层架构的分层方式、各层的职责、优缺点、适用场景，案例分析中“分层架构设计”“层间交互问题”的分析与优化。
（三）独立构件风格（互相不认识，靠广播/事件驱动）
核心特征：系统中的组件是独立的，组件之间不直接通信，而是通过第三方（如事件总线、消息队列）进行交互，组件之间是松耦合的，适合处理异步、并发的场景。
1. 进程通信风格
定义：系统由多个独立的进程组成，进程之间通过进程间通信（IPC）机制进行交互，如管道、消息队列、共享内存、Socket等，每个进程负责一个具体的功能，进程之间相互独立。
优点：进程独立，一个进程故障不会影响其他进程，可扩展性好，适合并发处理。
缺点：进程间通信开销大，调试困难，开发复杂度高。
适用场景：大型分布式系统、并发处理系统（如操作系统中的进程交互）。
2. 事件系统（隐式调用风格）
定义：组件不直接调用一个过程，而是触发或广播一个或多个事件；组件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程，一个事件的触发就导致了另一个模块中的过程调用。
核心组件：事件源（触发事件的组件）、事件总线（传递事件）、事件监听者（注册事件并处理事件的组件）。
优点：
缺点：
适用场景：图形界面开发（如按钮点击事件、菜单选择事件）、IDE编辑器插件（如按下Ctrl+S保存代码，触发代码格式化插件）、实时通知系统（如消息推送）。
考试考点：隐式调用风格的定义、核心组件、优缺点、适用场景，调试器断点设置的本质（事件监听）。
（四）虚拟机风格（自己造个翻译官）
核心特征：系统包含一个虚拟机（解释器、规则引擎等），虚拟机负责解释和执行用户提供的代码或规则，组件之间通过虚拟机进行交互，强调灵活性和可定制性，只要题干里强调“用户可以自定义行为/逻辑/对象关系”“动态解析”，大方向上就是虚拟机风格。
1. 解释器风格
定义：系统包含一个解释器，解释器负责解析和执行自定义的脚本或语言，组件之间通过脚本交互，解释器将脚本转换为可执行的指令，实现动态功能。
核心组件：解释器（解析脚本）、脚本（用户自定义逻辑）、执行环境（脚本运行的环境）。
优点：
缺点：
适用场景：脚本引擎、工作流引擎（如Activiti）、游戏脚本（如Unity中的C#脚本）、支持用户自定义逻辑的系统（如报表系统）。
考试考点：解释器风格的定义、优缺点、适用场景，看到“解释引擎、自定义语言、工作流节点处理、游戏对象行为定义”，优先选解释器。
2. 规则系统风格
定义：系统包含一个规则引擎，规则引擎负责管理和执行规则（如IF-THEN规则），组件之间通过规则交互，规则引擎根据输入的数据，匹配对应的规则并执行，实现动态决策。
核心组件：规则集（知识库，存储IF-THEN规则）、规则解释器（推理引擎）、规则/数据选择器（决定应用哪条规则）、工作内存（存储当前数据和状态）。
优点：
缺点：
适用场景：专家系统、风控系统、保险理赔系统、决策支持系统，看到“规则集、知识库、响应外界突发事件调整状态”，优先选规则系统。
考试考点：规则系统的核心组件、优缺点、适用场景，与解释器风格的区别。
（五）数据中心风格（仓库风格，大家围着一块板子）
核心特征：系统以数据为中心，存在一个中央数据存储（仓库），所有组件都围绕中央数据存储进行交互，组件之间不直接通信，而是通过访问中央数据存储实现数据共享和交互，数据与处理解耦，可动态添加和删除处理组件。
1. 传统数据库系统风格
定义：以关系型数据库为中央数据存储，组件通过SQL语句访问数据库，实现数据的增删改查，组件之间通过数据库共享数据，属于“被动仓库”，由输入流中某类事务触发进程执行的选择（即构件主动发起请求）。
核心组件：中央数据库（数据存储）、应用组件（访问数据库的组件）、数据库接口（如JDBC、ODBC）。
优点：
缺点：
适用场景：管理信息系统（MIS）、企业级应用（如涉及异构数据库集成的系统）、数据一致性要求高的系统（如财务系统）。
2. 黑板体系结构风格
定义：以黑板（中央数据结构）为核心，黑板存储系统的所有数据和状态，多个知识源（组件）围绕黑板进行交互，知识源独立工作，通过读取黑板上的数据，处理后将结果写入黑板，属于“主动仓库”，由中央数据结构的当前状态触发进程执行的选择。
核心组件：
优点：
缺点：
适用场景：语音识别系统、模式识别系统、专家系统、复杂问题求解系统（如医疗诊断系统）。
考试考点：黑板体系结构的核心组件、优缺点、适用场景，与传统数据库系统风格的区别，IDE为什么优先选择仓库风格（高频案例题考点）。
二、现代架构风格（高频考点，贴合行业趋势）
随着技术的发展，现代软件架构风格成为考试的重点，尤其是微服务、云原生、分布式架构等，案例分析和论文题常以此为主题，需重点掌握。
1. 微服务架构（Microservices Architecture）
定义：将系统拆分为多个小型、独立的服务，每个服务负责一个具体的业务功能（如用户服务、订单服务、支付服务），服务之间通过RESTful API、消息队列等方式通信，每个服务可独立部署、独立扩展、独立升级，核心特征是服务原子化、独立部署、去中心化治理。
与单体架构的对比（必背，案例分析常考）： 对比维度单体架构微服务架构组件耦合度高耦合：所有组件集成在一个应用中，修改一个组件影响整个系统低耦合：服务独立，服务之间通过接口通信，互不影响部署方式整体部署：修改任何一个组件，都需要重新部署整个应用独立部署：每个服务可单独部署，不影响其他服务扩展性整体扩展：需要扩展整个应用，资源浪费严重
定义：将系统拆分为多个小型、独立的服务，每个服务负责一个具体的业务功能（如用户服务、订单服务、支付服务），服务之间通过RESTful API、消息队列等方式通信，每个服务可独立部署、独立扩展、独立升级，核心特征是服务原子化、独立部署、去中心化治理。
与单体架构的对比（必背，案例分析常考）： 对比维度单体架构微服务架构组件耦合度高耦合：所有组件集成在一个应用中，修改一个组件影响整个系统低耦合：服务独立，服务之间通过接口通信，互不影响部署方式整体部署：修改任何一个组件，都需要重新部署整个应用独立部署：每个服务可单独部署，不影响其他服务扩展性整体扩展：需要扩展整个应用，资源浪费严重按需扩展：可针对高负载服务单独扩展，资源利用率高维护成本维护成本高：代码量大，修改风险高，排查问题困难维护成本低：服务体积小，修改风险低，可针对性维护技术栈单一技术栈：整个应用只能使用一种编程语言和框架多技术栈：不同服务可选用适合自身的编程语言和框架
核心考点补充：微服务架构的核心挑战（服务治理、分布式事务、服务监控）、解决方案（Spring Cloud、Dubbo框架，分布式事务用Seata、RocketMQ）。
2. 云原生架构（Cloud-Native Architecture，高频考点，案例分析+论文重点）
核心定义（必背）：云原生架构是一种设计理念，基于云计算平台的特性（弹性、可扩展、高可用），通过容器化、微服务、DevOps、服务网格等技术，实现应用与底层基础设施的解耦，让应用能够快速部署、弹性扩展、按需伸缩，核心目标是“让应用更适配云环境，充分发挥云的价值”，是微服务架构的延伸和升级。
核心特征（必考，选择题+案例分析）： 容器化：应用被打包为容器（如Docker），容器包含应用运行所需的所有依赖（代码、运行时、库、配置），实现“一次构建，到处运行”，解决环境不一致问题。
微服务化：延续微服务架构的核心，将应用拆分为独立的微服务，每个服务聚焦单一业务功能，独立部署、独立扩展，降低耦合度。
弹性伸缩：基于云平台的资源调度能力，根据业务流量自动调整应用实例数量（高峰扩容、低谷缩容），提升资源利用率，降低成本。
DevOps一体化：融合开发（Dev）和运维（Ops）流程，通过自动化构建、测试、部署（CI/CD），实现应用快速迭代，缩短交付周期。
自愈能力：通过健康检查、故障转移、自动重启等机制，当应用或基础设施出现故障时，系统能自动恢复，提升系统可用性。
声明式API：通过声明“期望状态”（如期望的服务实例数、资源配额），由云平台自动将系统调整至该状态，简化运维管理。
关键技术栈（核心考点，论文常考技术选型）： 容器化技术： Docker：核心容器引擎，负责打包、运行容器，是云原生架构的基础，考点：Docker的核心组件（镜像、容器、仓库）、镜像与容器的区别。
容器镜像仓库：用于存储和管理Docker镜像（如Docker Hub、Harbor），考点：私有镜像仓库的作用（企业内部镜像管理、安全管控）。
容器编排技术（核心，必背）： Kubernetes（K8s）：目前主流的容器编排平台，负责容器的部署、调度、扩展、运维，是云原生架构的核心组件。
K8s核心组件（必考）： 控制平面（Master）：集群的管理中心，包含API Server（接收和处理请求）、Scheduler（容器调度）、Controller Manager（控制器，实现自愈、伸缩等功能）、etcd（分布式数据库，存储集群配置和状态）。
节点（Node）：运行容器的服务器，包含Kubelet（管理节点上的容器）、Kube-proxy（负责节点网络通信）、容器运行时（如Docker）。
K8s核心资源（必考）：Pod（最小部署单元，包含一个或多个容器）、Deployment（管理Pod的部署和扩展）、Service（暴露Pod的访问地址，实现服务发现）、ConfigMap（存储配置信息，解耦配置与代码）、Secret（存储敏感信息，如密码、密钥）。
服务网格（Service Mesh，高频考点）： 定义：专门处理服务之间通信的基础设施层，将服务间的网络通信（流量控制、负载均衡、熔断、监控）从业务代码中剥离，实现“业务与通信解耦”。
核心组件：数据平面（Sidecar代理，如Envoy，部署在每个Pod中，负责转发流量）、控制平面（如Istio，管理所有Sidecar代理，配置流量规则）。
考点：服务网格的作用、核心组件、与传统服务通信的区别，Istio的核心功能（流量管理、安全通信、可观测性）。
DevOps与CI/CD（案例分析常考）： CI（持续集成）：开发人员频繁提交代码，通过自动化构建、测试，快速发现代码问题，确保代码质量（工具：Jenkins、GitLab CI）。
CD（持续部署/持续交付）：将通过测试的代码自动部署到目标环境（开发、测试、生产），实现应用快速迭代（工具：Jenkins、ArgoCD）。
考点：CI/CD的流程、核心工具、DevOps与云原生的关系（DevOps是云原生的重要支撑，实现应用快速交付）。
Serverless（无服务器架构，了解+选择题考点）： 定义：开发者无需关注服务器的部署、运维、扩展，只需编写业务代码，由云平台根据请求自动分配资源、运行代码，按实际使用量计费（如AWS Lambda、阿里云函数计算）。
核心特征：无服务器管理、按需计费、弹性伸缩、事件驱动，适合突发流量、短时间运行的场景（如短信发送、文件处理）。
优缺点（必背，案例分析常考）： 优点： 弹性伸缩：按需分配资源，高峰扩容、低谷缩容，降低资源成本，提升系统应对突发流量的能力。
快速交付：通过容器化、CI/CD，实现应用快速构建、测试、部署，缩短迭代周期（如从周级交付缩短至日级、小时级）。
高可用性：通过容器编排、自愈机制、多可用区部署，减少单点故障，提升系统可用性（目标99.99%以上）。
可维护性强：服务独立部署、独立维护，修改一个服务不影响其他服务，排查问题更高效；配置与代码解耦，便于配置管理。
技术栈灵活：不同服务可选用适合自身的技术栈，适配不同业务场景的需求。
缺点： 复杂度高：引入容器、K8s、服务网格等技术，增加了系统的部署、运维和学习成本，对技术团队要求高。
分布式挑战：微服务化后，服务数量增多，面临分布式事务、服务依赖、服务治理（熔断、限流）等问题。
可观测性难度大：服务分散，需要搭建统一的监控、日志、追踪系统（如Prometheus、ELK、Jaeger），才能定位问题。
网络延迟：服务之间通过网络通信，相比单体架构，存在一定的网络延迟，需通过服务网格优化。
适用场景（必考，案例分析选型题）： 互联网应用：业务流量波动大（如电商、直播、社交），需要弹性伸缩应对高峰流量。
快速迭代的业务：如互联网创业公司、产品迭代频繁，需要通过CI/CD实现快速交付。
大型企业级应用：业务复杂，需要拆分微服务，实现模块化管理、独立扩展（如金融、政务系统）。
混合云/多云部署场景：需要实现应用在不同云平台（公有云、私有云）之间的无缝迁移，容器化可解决环境不一致问题。
不适用场景：小型简单应用（如工具类软件），无需复杂的弹性伸缩和快速迭代，采用单体架构更简洁、成本更低；对延迟要求极高的场景（如实时交易系统），需谨慎使用（需优化网络通信）。
考试考点汇总（必背）： 选择题：云原生的核心特征、K8s核心组件、服务网格的作用、容器与虚拟机的区别、CI/CD的定义。
案例分析：云原生架构的选型理由、优缺点分析、技术栈选择（如为什么用K8s编排容器、为什么引入服务网格）、架构优化方案（如如何解决分布式事务、如何提升可观测性）。
论文：以“云原生架构设计与实践”为主题，可从核心特征、技术栈选型、实施过程、遇到的问题及解决方案等方面展开，结合具体业务场景（如电商系统、政务系统）进行论述。
易混淆点（高频坑点）： 云原生 vs 微服务：微服务是云原生的核心组成部分，但云原生不止微服务，还包含容器化、DevOps、服务网格等技术，是更全面的架构理念。
对比维度 | 微服务架构 | 云原生架构 |
核心定位 | 一种服务拆分理念，聚焦“业务解耦”，将系统拆分为独立微服务，解决单体架构扩展性差的问题 | 一种完整的架构理念，聚焦“适配云环境”，充分发挥云的弹性、高可用优势，是微服务的延伸升级 |
核心技术 | 服务拆分、RESTful API、消息队列、服务治理（Spring Cloud、Dubbo） | 微服务、容器化（Docker）、容器编排（K8s）、服务网格、DevOps、Serverless |
核心目标 | 降低服务耦合，实现服务独立部署、独立扩展，提升业务迭代效率 | 实现应用与底层基础设施解耦，快速部署、弹性伸缩，降低资源成本，发挥云平台价值 |
依赖环境 | 可部署在物理机、虚拟机、云平台，对环境依赖较低 | 依赖云平台（公有云、私有云、混合云），需依托云环境实现弹性伸缩、自愈等特性 |
运维复杂度 | 需解决服务治理、分布式事务等问题，运维复杂度中等 | 需管理容器、K8s、服务网格等，还要实现DevOps自动化，运维复杂度更高 |
包含关系 | 是云原生架构的核心组成部分，云原生可以包含微服务 | 包含微服务，但不止微服务，还涵盖容器化、DevOps等完整技术体系 |
容器 vs 虚拟机：容器是轻量级的，共享宿主机的操作系统内核，启动快、资源占用少；虚拟机是重量级的，需要独立的操作系统，启动慢、资源占用多。
K8s Pod vs 容器：Pod是K8s的最小部署单元，一个Pod可包含多个容器，这些容器共享Pod的网络和存储资源。
容器 vs 虚拟机：容器是轻量级的，共享宿主机的操作系统内核，启动快、资源占用少；虚拟机是重量级的，需要独立的操作系统，启动慢、资源占用多。
K8s Pod vs 容器：Pod是K8s的最小部署单元，一个Pod可包含多个容器，这些容器共享Pod的网络和存储资源。
