学习地址：https://www.bilibili.com/video/BV1xepMzrEjD?spm_id_from=333.788.videopod.episodes&vd_source=461545ff50a35eaeaa8218ecdc5f7152

考试时间安排

时间段	考试科目	时长/规则	题型
08:30–12:30	综合知识 + 案例分析	连考240分钟 综合知识：最长150分钟、最短120分钟 案例分析：剩余时间	综合知识：75道单选 案例分析：5题（1必答+4选2）
14:30–16:30	论文	固定120分钟，不得提前交卷	4选1，写2500字左右

• 三科均为机考，满分75分，三科必须全部≥45分才算通过。
• 上午连考：综合知识交卷后可离场；继续作答案例分析，12:30前60分钟可交卷。
• 下午论文：全程120分钟，不可提前交卷。

考点

重点：
软件工程、软件架构设计

考试技巧

系统架构概述

1.系统架构的定义及发展历程

系统：系统是组织起来完成某一特定功能或一组功能的组件集。系统这个术语包括了单独的应用
程序、传统意义上的系统、子系统、系统之系统、产品线、整个企业及感兴趣的其他集合。系
统用于完成其环境中的一个或多个任务。

架构：架构是体现在组件中的一个系统的基本组织、它们彼此的关系与环境的关系及指导它的设
计和发展的原则。

⭐⭐⭐系统架构：系统架构 (System Architecture) 是系统的一种整体的高层次的结构表示，是系
统的骨架和根基，支撑和链接各个部分，包括组件、连接件、约束规范以及指导这些内容设计与演化的原理，它是刻画系统整体抽象结构的一种手段。

系统架构：需求分析完之后，对系统进行抽象的高层次的设计

2.软件架构的常用分类及建模方法

分层架构

⭐⭐分层架构：将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口进行通通信

● 表现层 (Presentation Layer): 用户界面，负责视觉和用户互动；
● 业务层 (Business Layer): 实现业务逻辑；
● 持久层 (Persistence Layer): 提供数据， SQL语句就放在这一层；
● 数据库 (Database Layer): 保存数据。

事件驱动架构

事件 (Event) 是状态发生变化时软件发出的通知。
⭐⭐事件驱动架构：事件驱动架构 (Event-driven Architecture)是通过事件进行通信的软件架构，是一种流行的分布式异步架构模式，适用于松散耦合系统。

● 事件队列 (Event Queue): 接收事件的入口；
● 分发器 (Event Mediator): 将不同的事件分发到不同的业务逻辑单元；
● 事件通道 (Event Channel): 分发器与处理器之间的联系渠道；
● 事件处理器 (Event Processor): 实现业务逻辑，处理完成后会发出事件，触发下一步
操作。

微核架构
微核架构 (Microkernel Architecture) 又称为插件架构 (Plug-in Architecture), 是指软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
内核 (Core) 通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信应该减少到最低，避免出现互相依赖的问题。

微服务架构
微服务架构 (Microservices Architecture) 是服务导向架构 (Service-Oriented Architecture,SOA)的升级。每一个服务就是一个独立的部署单元 (Separately Deployed Unit)。 这些单元都是分布式的，互相解耦，通过远程通信协议(比如 REST、SOAP) 联系。

微服务架构分成三种实现模式。
● RESTful API模式：服务通过API提供，云服务就属于这一类；
● RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部；
● 集中消息模式：采用消息代理 (Message Broker) 可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。

云架构

云架构主要分成两部分：处理单元 (ProcessingUnit) 和虚拟中间件 (Virtualized Middleware)

(1)处理单元：实现业务逻辑。
(2)虚拟中间件：负责通信、保持会话控制 (sessions)、 数据复制、分布式处理和处理单元的部署。
这里，虚拟中间件又包含四个组件：
● 消息中间件 (Messaging Grid): 管理用户请求和会话控制 (sessions), 当一个请求进来以后，它决定分配给哪一个处理单元。
● 数据中间件 (Data Grid): 将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
● 处理中间件 (Processing Grid): 可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元。
● 部署中间件 (Deployment Manager): 负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。

⭐⭐⭐系统架构的模型

架构师在进行软件架构设计时，必须掌握软件架构的表示方法，即如何对软件架构建模。根据建模的侧重点的不同，可以将软件架构的模型分成4种：结构模型、框架模型、动态模型和过程模型。

● 结构模型：这是一个最直观、最普遍的建模方法。此方法以架构的构件、连接件和其他概念来刻画结构。并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质。研究结构模型的核心是架构描述语言。
● 框架模型：框架模型与结构模型类似，但它不太侧重描述结构的细节，而更侧重整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的结构。
● 动态模型：动态模型是对结构或框架模型的补充，主要研究系统的“大颗粒”行为的性质。例如，描述系统的重新配置或演化。这里的动态可以是指系统总体结构的配置、建立或拆除通信或计算的过程，这类系统模型常是激励型的。
● 过程模型：过程模型是研究构造系统的步骤和过程，其结构是遵循某些过程脚本的结果。

上述介绍的4种模型并不是完全独立的，通过有机的结合才可形成一个完整的模型来刻画软件架构，也将能更加准确、全面地反映软件架构。软件架构可从不同角度来描述用户所关心架构的特征。 Philippe Kruchten 在1995年提出了一个“4+1”视角模型。“4+1”模型从5个不同的视角包括逻辑 (Logical) 视角、过程 (Process) 视角、物理 (Physical) 视角、开发(Development) 视角和场景 (Scenarios) 视角来描述软件架构。每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件架构的全部内容。

3.软件架构的应用场景

⭐不同的架构风格具有各自的优缺点和应用场景

架构风格	核心特点	典型适用场景
管道-过滤器	系统分为若干独立步骤，数据沿管道流转	数据流处理、编译器、数据流水线
主程序/子系统	自上而下调用，结构化分解	组件内部详细设计
面向对象	封装、继承、多态，对象间消息通信	组件内部详细设计
虚拟机风格	提供抽象执行环境，解释执行	解释器、专家系统、规则引擎
C/S	客户端+服务器，网络交互，胖客户端	数据与处理分布、网络连接的系统
B/S	浏览器+服务器，跨平台，易维护	数据与处理分布、网络连接的系统
平台/插件	核心平台+可扩展插件，松耦合	支持插件扩展功能的应用程序
MVC	模型-视图-控制器分离	用户交互程序设计
SOA	面向服务，粗粒度、跨系统集成	企业集成、系统间协同
C2	基于消息总线与连接器，灵活可扩展	GUI软件开发，灵活可扩展应用系统

论文写作要点

1.写作注意事项

1.1做好准备工作

根据考试大纲，论文试题的目的如下：

序号	考查目标	核心说明
1	检验架构实践经验	判定考生是否具备系统架构设计实操经验，无实践基础难以胜任架构师岗位与资格认定
2	考核分析与解决问题能力	考察独立工作能力，要求结合实际场景抓取关键因素，分析问题并输出合理架构设计方案
3	考核文字表达与文档能力	架构师需输出各类技术文档、报告；要求内容重点突出、用词准确、逻辑清晰、易于理解

加强学习

不同类型考生论文备考要点

考生类型	核心特点	备考重点与方法
经验丰富的应考人员	具备相关项目实践经验，有可梳理的实际项目案例	整理自身项目经验，从技术、管理、经济等多维度归纳、剖析项目，结合专业知识和关键技术进行抽象升华，形成系统的备考思路
经验欠缺的在职开发人员	有一定工作基础，但缺乏系统的架构设计和论文写作经验	1. 研读单位现有文档、项目案例，积累实践素材； 2. 参考历届考题，学习答题思路； 3. 培养系统架构师视角，练习论文写作，弥补经验短板； 4. 临摹优秀论文，提升写作与思考能力
学生考生	备考时间充足，但缺乏实际项目实践经验，论文易空洞	1. 大量阅读相关文章、论文范文，借鉴他人实践经验； 2. 加强论文写作强化练习，模拟架构设计相关场景，提升内容真实性和逻辑性； 3. 重点补充系统架构设计相关理论知识，弥补实践短板

1.2论文写作格式

论文考试的时间为下午(120分钟),且备选的论文题目通常包含4道题目，考生可以根据自己所从事的工作内容，选择比较接近的题目进行论文写作。

摘要和正文要分开写。摘要需要300～400字，正文需要2000～3000字。

2.如何解答试题

2.1论文解答步骤

论文写作时间分配表

任务环节	时间分配	具体说明
试题选择	3分钟	快速浏览所有试题，结合自身知识储备和写作难度，确定要撰写的论文题目，避免浪费时间。
论文构思	12分钟	明确论文核心主题、结构框架（如引言、核心内容、总结等），梳理写作思路，确定各部分核心内容，避免后续写作混乱。
摘要撰写	15分钟	提炼论文核心观点、研究内容和核心结论，语言简洁凝练，准确概括论文核心，符合考试答题规范。
正文撰写	80分钟	按照构思的框架，逐步展开正文内容，重点突出、逻辑清晰，确保内容贴合主题，同时兼顾格式规范，完成全文撰写。
检查修改	10分钟	通读全文，检查语法错误、逻辑漏洞、格式规范性，修正错别字和表述问题，优化语言流畅度，确保符合考试要求。

2.2论文解答实例

实例一

论文题目

论软件系统建模方法及其应用
软件系统建模 (Software System Modeling) 是软件开发中的重要环节，通过构建软件系统模型可以帮助系统开发人员理解系统、抽取业务过程和管理系统的复杂性，也可以方便各类人员之间的交流。软件系统建模是在系统需求分析和系统实现之间架起的一座桥梁，系统开发人员按照软件系统模型开发出符合设计目标的软件系统，并基于该模型进行软件的维护和改进。

请围绕“论软件系统建模方法及其应用”论题，依次从以下三个方面进行论述。
1.概要叙述你参与的软件系统开发项目以及你所担任的主要工作。
2.说明软件系统开发中常用的建模方法有哪几类?阐述每种方法的特点及其适用范围。
3.详细说明你所参与的软件系统开发项目中，采用了哪些软件系统建模方法，具体实施效果如何。

分析

问题1要点
该方面需要简要描述所参与分析和开发的软件系统开发项目，并明确考生指出在其中承担的主要任务和开展的主要工作。需注意所描述的项目应与论文题目中包含的主要论题相符。

问题2要点
该方面是对论文论题中涉及的专业知识的理解和掌握程度的考核，考生可以通过详细描述，说明自己所了解的软件系统开发中的常用建模方法，并阐述出每种方法的特点及其适用范围。
例如，考生可以描述的软件系统开发中常用的建模方法包括：
(1)功能分解法。
功能分解法以系统需要提供的功能为中心来组织系统。首先定义各种大的功能，然后把功能分解为子功能，同时定义功能间的接口。比较大的子功能还可以被进一步分解，直到我们可以对它进行明确的定义。总的思想就是将系统根据功能分而治之，然后根据功能的需求设计数据结构。
(2)数据流法/结构化分析建模方法。
基本方法是跟踪系统的数据流，研究问题域中数据如何流动以及在各个环节上进行何种处理，从而发现数据流和加工。然后将问题域映射为数据流、加工以及数据存储等元素并组成数据流图，用加工和数据字典对数据流及其处理过程进行描述。
(3)信息工程建模法。
在实体关系图基础上发展而来，其核心是识别实体及其关系。实体用于描述问题域中的一个事物，它包含一组描述事物数据信息的属性；关系描述问题域中的各个事物之间在数据方面的联系，它可以带有自己的属性。发展之后的方法把实体叫作对象，把关系的属性组织到关系对象中，具有面向对象的某些特征。
(4)面向对象建模法。
从面向对象设计领域发展而来，它通过对象对问题域进行完整的映射，对象包括了事物的数据属性和行为特征；它用结构和连接如实反映问题域中事物之间的关系，比如分类、组装等；它通过封装、继承和消息机制等使问题域的复杂性得到控制。

问题3要点
该方面是针对考生实际参与的软件系统开发项目，说明该项目所采用的系统建模方法，并描述这些建模方法所产生的实际应用效果。

实例二

论文题目

论软件架构风格
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

请围绕“论软件架构风格”论题，依次从以下三个方面进行论述。
1.概要叙述你参与分析和设计的软件系统开发项目以及你所担任的主要工作。
2.软件系统开发中常用的软件架构风格有哪些?详细阐述每种风格的具体含义。
3.详细说明你所参与分析和设计的软件系统是采用什么软件架构风格的，并分析采用该架构风格设计的原因。

分析

问题1要点
该方面是要求考生要简要叙述自己所参与分析和开发的软件系统，并明确指出在其中承担的主要任务和开展的主要工作。需注意所描述的项目应与论文题目中包含的主要论题相符。

问题2要点

序号	架构风格	核心内容
1	管道/过滤器	各构件具备独立输入、输出；读取数据流并内部处理，最终输出数据流，以数据流方式完成交互
2	数据抽象与面向对象	基于数据抽象与面向对象思想，将数据表示与对应操作封装在抽象数据类型或对象内部
3	基于事件的隐式调用	构件不直接调用方法，而是触发/广播事件；订阅事件的构件自动响应执行；事件触发者不感知下游构件
4	分层系统	采用层级化结构，每层为上层提供服务，同时作为下层的客户端，层级间单向依赖
5	仓库系统及知识库	包含中央数据结构与独立处理构件；分为传统数据库仓库与黑板系统；黑板由知识源、黑板数据结构、状态驱动控制三部分构成
6	C2风格	由连接件绑定并行构件网络，遵循固定连接规则；构件间禁止直连，只能通过连接件上下对接组合
7	客户/服务器(C/S)	由数据库服务器、客户端应用、网络三部分组成，典型二层架构模式
8	三层C/S结构	拆分表示层、功能层、数据层，解决二层C/S扩展差、负载高、安全性弱、运维困难等缺陷
9	浏览器/服务器(B/S)	属于三层C/S的实现形式，架构为：浏览器 + Web服务器 + 数据库服务器

问题3要点
该方面是针对考生自身具体参与分析和开发的实际软件系统，说明在该系统的设计和实现中，采用的具体一种或多种软件架构风格，并分析出采用这种软件架构风格设计的原因。

Spring Cloud 最接近：客户 / 服务器（C/S）+ 分层系统 + 隐式调用（事件 / 消息）的混合风格，考试里一般直接归为：客户 / 服务器（C/S）风格（分布式、多层）。
Spring Cloud = 分布式多层 C/S 为主，兼有分层系统、事件隐式调用特征。

3.论文写作方法

3.1如何写好摘要

摘要应控制在300～400字的范围内，凡是没有写论文摘要，摘要过于简略，或者摘要中没有实质性内容的论文将扣5～10分。如果论文写得辛辛苦苦，而摘要被扣分，就太不划算了。而且，如果摘要的字数少于120字，论文将“给予不及格”。

下面是摘要的几种写法，供考生参考。
(1)本文讨论⋯⋯系统项目的⋯⋯(论文主题)。该系统⋯⋯(项目背景、简单功能介绍)。在本文中首先讨论了⋯⋯(技术、方法、工具、措施、手段),最后⋯⋯(不足之处/如何改进、特色之处、发展趋势)。在本项目的开发过程中，我担任了⋯⋯(作者的工作角色)。

(2)根据⋯⋯需求(项目背景),我所在的⋯⋯组织了⋯⋯项目的开发。该项目⋯⋯(项目背景、简单功能介绍)。在该项目中，我担任了⋯⋯(作者的工作角色)。我通过采取⋯⋯(技术、方法、工具、措施、手段),使该项目圆满完成，得到了用户们的一致好评。但现在看来，⋯⋯(不足之处/如何改进、特色之处、发展趋势)。

(3)⋯⋯年⋯⋯月，我参加了⋯⋯项目的开发，担任⋯⋯(作者的工作角色)。该项目⋯⋯(项目背景、简单功能介绍)。本文结合作者的实践，以⋯⋯项目为例，讨论⋯⋯(论文主题),包括⋯⋯(技术、方法、工具、措施、手段)。

(4)⋯⋯是⋯⋯ (“戴帽子”,讲论文主题的重要性)。本文结合作者的实践，以⋯⋯项目为例，讨论⋯⋯(论文主题),包括⋯⋯(技术、方法、工具、措施、手段)。在本项目的开发过程中，我担任了⋯⋯(作者的工作角色)。

上述的“技术、方法、工具、措施、手段”就是指论文正文中论述的技术、方法、工具、措施、手段，可把每个方法(技术、工具、措施、手段)的要点用一两句话进行概括，写在摘要中。
在写摘要时，千万不要只谈大道理，而不牵涉到具体内容。否则，就变成了“摘要中没有实质性内容”。

3.2如何写好正文

写作技巧	核心要求	具体说明
以自我为中心	突出个人参与和贡献，让阅卷专家信服	1. 不炫耀参与的工程项目，重点说明自身在项目中的具体行动、遇到的问题及解决方法； 2. 核心要求：体现实际项目经验，不罗列课本内容； 3. 明确项目开发体制、规模，以及自身的工作任务、所起作用； 4. 重点阐述自身在项目中的贡献、努力过程，聚焦“我”的具体行动。
站在架构师角度	摆脱程序实现思维，具备全局视角	1. 避免单纯从程序实现细节考虑问题，要从全局出发； 2. 举例：撰写层次式架构论文时，需分析架构的优缺点、设计方法、各层次接口设计，而非局限于具体代码实现。
忠实于论点	紧扣题意，不偏离核心	1. 先仔细研读试题要求及背景说明，正确理解题意后提取论点； 2. 阐述内容严格围绕论点展开，不节外生枝、不偏离主题，避免半天未切入核心。
条理清晰，开门见山	结构清晰、重点突出	1. 选定题目后，梳理素材并列出提纲，聚焦自身在项目中做的相关工作，不贪多求全、不不懂装懂； 2. 项目概述需精炼，明确项目背景、意义、规模、开发过程及自身角色，吸引阅卷专家； 3. 分清主次，让专家快速了解论文核心及个人贡献。
标新立异，有主见	融入个人见解，避免千篇一律	1. 不局限于教科书内容和常规思维，结合项目实际提出个人见识和体会； 2. 无需刻意追求新奇，重点体现自身对项目、对架构设计的独立思考。
图文并茂	借助图形增强表达效果	1. 系统架构相关论文可绘制简洁、整洁的架构草图，直观展示设计思路； 2. 图形不宜过大、过潦草，线条、箭头需工整，帮助专家快速理解架构设计。
首尾一致	前后呼应，规范严谨	1. 正文开头与结尾相互呼应，言词表达前后一致，无矛盾； 2. 仔细检查论文，修正错字、漏字，若有剩余时间，做好细节修正，保证论文规范。

可能涉及的关键技术

系统架构设计师的论文题目是在对架构师所需专业知识掌握的前提下，进行专业知识在工程项目中的应用。因此，要撰写好论文，一定需要具有相关的专业技术知识，例如经典的架构风格及其应用场景(面向对象、面向过程、 SOA、 微服务等),架构设计中的质量属性设计(可用性、性能、安全性、可修改性、可测试性、易用性设计等)和质量属性提升策略，架构评估的过程、方法和技术，架构的建模和描述方式等。这些关键技术在本书中的前面章节均已向读者陈述，考生可以根据自身的情况进行阅读，查缺补漏。

3.3摘要和正文的关系

写作速度比较快而又自信对论文的把握比较好。先写正文，后写摘要。
这样，便于正文的正常发挥，正文写完了，归纳出摘要是水到渠成的事情。
这样，便于正文的正常发挥，正文写完了，归纳出摘要是水到渠成的事情。但是，这种方法的缺点是万一时间不够，来不及写摘要，损失就比较大了，结果论文写得很辛苦，因为摘要没有写而不及格；

写作速度比较慢，担心最后没有时间写摘要，则可先写摘要，后写正文。
这样做的好处是万一后面时间不足，可以简单地对正文进行收尾，从而避免“有尾无头”的情况发生，而不会影响整个论文的质量。但它的缺点是可能会限制正文的发挥，使正文只能在摘要的圈子里进行扩写。

4.常见问题及解决办法

系统架构设计师论文写作12条避坑要点

序号	避坑类型	核心注意事项	具体说明
1	避免走题	严格贴合试题3个问题组织内容	不盲目套用三段论，先仔细研读试题所有问题，明确考查侧重点；同一主题不同试题的考查方向可能差异极大，需针对性回应，避免“一套模板用到底”导致走题。
2	控制字数合规	严格遵循字数要求，不偏多偏少	1. 摘要：300-400字（建议350字以上）；2. 正文：2000-3000字（建议2500字左右）；3. 字数含标点、图形，按答题纸格子计数，练习时严格把控时间，避免超4000字。
3	避免字数过多	控制篇幅，贴合考试时间限制	不追求“面面俱到”，避免文章篇幅过长（杜绝4000字以上，尤其避免8000字极端情况）；日常练习需按考试时间模拟，避免因时间不足无法完成写作。
4	优化摘要撰写	摘要需精准概括全文，无冗余	摘要核心是“压缩正文重点”，达到“不看正文也能掌握全文核心”的效果；避免添加“帽子性”语句，直接提炼正文关键信息、核心措施和结论，不冗余。
5	保证文章深度	聚焦2-3个核心要点深入展开	不盲目罗列所有措施/技术，选择2-3个有特色的方法、技术重点阐述，结合项目实际细节展开，避免“蜻蜓点水”式描述，增强文章深度。
6	突出项目特色	结合具体项目，不泛泛而谈	不堆砌书刊理论知识点，以自身参与的具体项目为核心，详细说明项目背景、自身角色及具体操作，增强内容可信度；所有技术、措施均需结合项目实例。
7	规范语言表达	使用书面语，合理使用人称	杜绝口语化表达；以“我们”替代部分“我”，体现项目的集体协作属性，既符合实际工作场景，也避免语言过于生硬。
8	提升文字表达	加强书面表达训练	平时多阅读规范文档、多撰写技术文档，提升文字组织能力；避免因表达混乱导致核心内容无法清晰传递。
9	明确主题项目	必须包含具体项目信息（致命要点）	需明确说明参与的具体项目（时间、背景、功能），明确自身在项目中的角色；禁止笼统表述（如“负责银行软件”），需具体到项目名称、核心功能。
10	选用近期项目	优先选择近3年内的项目	避免使用年代久远的项目，确保项目的时效性和真实性，提升论文可信度。
11	优化文章结构	避免过于死板的条目化表述	可使用合理的序号辅助条理，但避免全文用“大一二三+小123”的刻板格式，减少压抑感，提升阅读体验。
12	优化段落排版	控制段落长度，提升可读性	每个自然段不超过8行，避免过长段落导致阅卷疲劳；合理划分段落，使文章结构清晰，避免因排版问题影响得分。