用旅行的心态一次性通过软考架构高级？（24年下半年真题回忆）

本文献给已经下定决心参加软考的读者，提供一个轻松有序，且能更好地和工作结合的复习方法

杭州软考的考点在下沙大学城，距离主城区特别的远，甚至隔一条街就到嘉兴海宁了，高德导航动不动就提示 “您已到达嘉兴市”，稍微拐个弯，又提示 “进入杭州市”。

因此我直接在下沙订了酒店，周六就到了下沙，方便周日一大早去参加软考。

酒店就定在嘉兴海宁的新晋打卡地--澜公园，周六我还顺便带老婆一起逛逛了下沙奥特莱斯，收获颇丰。所以那个周末对我来说与其说是考试，倒更像是一次有趣的下沙旅行。

澜公园一景

分数是在 12 月 11 日公布的，没有意外地通过了。“没有意外” 是因为软考的考试时间比较充裕。除了主观的论文外，客观题我都可以在做完后利用剩余时间，统计下有把握的分数，发现都能有50分（软考每科45分及格），因此考完我就跟老婆和朋友说 “我通过了！”， 并且周日晚上吃了顿好的。

幸好最后结果没有打脸， 不然就变成 “半场开香槟” 的笑话了：

复习时间安排

整个软考分为三个部分：

• 上午考4个小时
  • 前两个小时选择题
  • 后两个小时案例分析
• 下午考2个小时：论文写作

分享下我对每一部分的复习时间安排。

选择题--利用好碎片时间

互联网行业工作繁忙，不可能像学生时代一样全职备考了，因此利用好平时的碎片时间很重要。

特别是选择题，上下班路上， 吃饭排队时刷一刷，不会的看看答案其实是比较轻松的。

同事给我推荐了 “软考通” APP，通过 “刷题练习”，可以刷历年的全部选择题真题，总共 759 道题。

我给自己的规划是在国庆节结束前刷完历年全部选择题，看起来很多，其实分摊到每一周只需要刷 150 题就可以了：

时间	刷题数
9.2~9.8	150
9.9~9.15	150
9.16~9.22	150
9.23~9.30	150
国庆节假期	剩下的所有题目（159题）

每周150题看起来很多，其实实践起来压力不大，因为记忆型的题目偏多，外加大家作为程序员也算有点基础，基本上每天上下班路上点点就刷完了。

除了刷题外，每天晚上我也会总结下当天刷到的关键知识点，对于一些不太看得懂的题目，我也会去网上找找别人的解析，或者问问 AI，最后汇总成如下的一篇刷题笔记：

本文大家多多点赞，反馈好的话我把这篇笔记也发出来

国庆节距离考试还有一个月呢，为什么这么早就把题目刷完？留下的一个月时间我们可以把错题再多刷几遍，加深印象。

在刷历年真题的时候，大家可能和我一样有个困惑：之前考过的题目还会考吗？如果不考的话是不是白刷了呢？

参加完了24年下半年的考试后，我再也不怀疑了，感觉软考的出题老师比较懒，确实会有一些新题，但也会有大量的老题反复考，我们只要能把握住这些能把握住的老题，就足够及格了。

最后我的选择题分数也非常高，53分。

案例分析--周末多看多练

案例分析相比选择题，更需要体系化的知识，所以我把它放到周末用整块时间来学习。

9月份可以先看一些真题讲解视频，熟悉以下题目的套路，我是蹭的同事的希赛网的案例分析专题，这个是需要花钱的。不过我后来找找，发现 B 站上也很多免费的案例分析讲解，比如 青石竹屋的案例分析讲解。如果只看案例分析的话，内容不是很多，每周末看两个小时，一个月就可以学习完毕。

国庆节假期可以自己再练一练最近三年的案例分析真题，自己写完后对照下答案，对比下有什么不足。案例分析真题也可以从软考通上找到，或者去网络上搜索，非常多。

时间安排如下：

时间	安排
9月	学习案例分析讲解视频
国庆节	刷近三年真题

这几年案例分析的变化很大，越来越注重实践和积累，比如 20 年考了 Docker 命令，今年还考了 Elastic Search 的分词类型。所以后面我再推荐一本课外书，帮大家快速提升积累，提升胜率。

为什么我案例分析的安排也只到国庆节呢？因为后面的周末要安排给更重要的论文练习和模拟考试。

论文--一定自己写几篇

论文我一直放到最后一个月才开始复习，因为我觉得，只有先铺垫好基础知识，写起来才能更加得心应手。

可以十一假期中先看一些论文讲解视频，我蹭的是同事付费的希赛论文专题视频，B 站上也有免费的讲解视频，比如 论文-考情分析和注意事项，核心就是了解一个结构：

接下来就是自己写几篇了，我了解的很多考友，从来没自己写过，就准备依靠考前背那么一两篇，那是万万不可的。这样的论文基本都挂了，只有一个特别天赋异禀的通过了。

我在10月13日，也就是十一假期后的第一个周末，开始了自己的第一篇论文写作，可以从老师讲解过的真题中选一个进行练习。第一篇可以先开卷写作，不要给自己限时。

我的第一篇论文写了整整一天，我选择练习的真题是 “基于ABSD的软考开发”，我没有立马开始写作，而是先把ABSD相关的知识整理成了一个思维导图：

之后对照着论文结构，结合自己的项目实践，一点一点地将论文填充完整，第一篇论文我宁愿死板一点，和视频中讲解的论文结构保持完全一致。

第一篇论文出来后，其中的很多部分其实都是可以复用的，比如项目背景和论文结论，每次需要改动的也就是 相关问题回应 和 主题内容 两个部分。

之后距离考试其实就只有三周了，这三周中建议两周进行模考，一周再进行一次论文练习。大家可以看自己的时间进行安排，我是先进行了两次模考，然后最后一周再进行的论文练习。

最后一周练习一些自己觉得最通用的论文题目，比如 “软件架构风格”，“基于SOA的软件开发” 等等。熟练后，甚至都不需要写完整的论文，直接列列大纲就算练过了。考前把这些大纲带着复习下就行。下面是我对一些题目列的简单大纲， 用这种方法，一天练习五六题不在话下：

这几年论文题目的变化也比较大，类似于 “基于ABSD的软件开发”，或者 “基于构件的软件开发” 这种偏背书的题目越来越少，更多地是从实践出发，比如 “微服务架构”， “分布式事务”， “云原生架构” 等等。所以虽然我列很多的知识思维导图，考试中更多地还是用在了选择题，论文还是积累更加重要。所以后面我再推荐一本课外书，帮大家快速提升积累。

模拟考试--心里有底，方能不慌

孙子兵法云 “先胜后战”，在上真正考场之前，我们通过模拟考试就已经确认自己能过，才能做到最好的心态。

所以我给自己安排了两次模拟考试，分别在考试前的第三个周末和第四个周末，跟真正的考试时间保持严格一致。

模拟考试题目从哪里来呢？可以希赛网考前的两次模考大赛中获取 模考大赛地址 ，这个是免费的，只是注册后总是会有希赛的人打电话骚扰你，不接就行了。也不要指望模考能押到题，就是给你找个感觉。如果错过了模考大赛的话，也可以直接取历年真题。

不管模考有没有有没有通过，我们对考试的时间都有了更好的把握。整个软考的时间非常充裕的，我们充足的时间在做完题目后再进行检查，检查后还可以提前交卷。

我在模考的时候，还没来得及二刷选择题历年错题。希赛的模考中也有大量历年真题，很多题目我之前做错，模考还错了。于是我痛定思痛，一定要把错题再刷一遍。最后真正考试的选择题分数比我两次模考都要高，得了 53 分。

整体复习时间安排表

总结一下上文的内容，整体复习时间安排如下：

时间	选择题安排	案例分析安排	论文安排
9月-第一周	150题	看视频
9月-第二周	150题	看视频
9月-第三周	150题	看视频
9月-第四周	150题	看视频
国庆节假期	剩余真题	刷近三年真题	看视频
10月-第二周	刷错题		第一篇论文
10月-第三周	刷错题; 模拟考试	模拟考试	模拟考试
10月-第四周	刷错题; 模拟考试	模拟考试	模拟考试
11月-第一周	刷错题		常见论文练习
11月-第二周	进入考场	进入考场	进入考场

看课外书多拿20分

文末再分享一个意外多拿20分经历，可能没这分数，我这次也过不了。

我平时喜欢看课外书，就想在考前看一本架构师相关的课外书玩一玩， 增强自己工作能力的同时，也能对考试有点帮助。

不太想看教材，也不建议大家看，因为教材里很多的技术非常过时，和实践脱节，对工作没啥帮助。而且最近考试题的变化方向也是越来越与实践结合，而不是考察教材里背诵的知识，所以看教材就更加没有意义里。

我最后选择了周志明写的《凤凰架构》，一方面是这本书在豆瓣上有高达 9.3 分的高分，另一方之前读过的周志明的其他作品（《深入理解Java虚拟机》）和文章，给我的总体感觉是比较落地和踏实。不像很多其他架构师比较虚，总是说一堆听不懂的概念。

书的内容非常丰富和扎实，和实践连接得也很紧密。考前我只读到了四分之一，居然就命中了一道案例分析题，和论文题。可见出题越来越注重和实践的关系，而不仅仅是背诵教材。

有一道案例分析题考的 Cache Aside 模式缓存的读写步骤。大体就是把 Cache Aside 的读写流程中挖掉几个空，让你填写。最后再问 Cache Aside 可能导致数据不一致的情况与解决方法。

这些在《凤凰架构》的第 4 章 透明多级分流系统中都有详细的阐述。对于 Cache Aside 的操作流程，我估计大多数人和我一样，在看书之前也大概了解，但是对里面的细节可能记得不太清楚。比如写操作流程中到底是失效缓存，还是更新缓存。到底先更新数据源，还是先失效缓存，等等。如果细节记得不清楚，考到这道题就 G 了。好在 《凤凰架构》中周志明详细阐述了里面的细节，以及这么做的原因，而不像其他书一样只是把知识灌输给你，因此记得更加深刻，遇到这个题目轻松拿下。

另外就是论文题，24年下半年的四选一题目中，对于大多像我一样的业务开发者，就只能选择 “基于SOA的软件开发”，但是SOA相关的知识点我记得不太清了，而且除了传统企业，很少有项目会使用 SOA，我又不想瞎编。我又看了看剩下的题目，还有有个第四题，是 “分布式事务的应用”，题目中要求列举四种分布式事务的实现方式，这就把很多考友给难住了，因为我们大多在业务中只用过 TCC 事务。好在我刚在 《凤凰架构》第三章 事务处理中看到过对各种分布式事务实现方式的讲解，包括两阶段提交，可靠事件队列，TCC和Sage事务。靠着这个印象，论文也很顺利地完成了。虽然最后的分数 48 分，也算不是很高，但是通过就行了。

所以非常推荐大家在软考复习的两个多月的时间，利用每天晚上的一点课余时间，把这本书给刷了，通过考试的同时，还能大大提升工作能力和架构视野。

附录：软考考前速记知识整理

周日进考场前，一般还会有那么半小时时间背一点东西，我周六陪老婆逛完下沙奥特莱斯，稍微整理了一个小炒留考前看一看，这里也分享给大家。

当然，这只是我个人觉得需要考前再看看的知识，大家也可以根据个人需要修改。

软件架构风格

• 数据流风格
  • 批处理
  • 管道-过滤器
• 调用/返回风格
  • 主程序/子程序
  • 面向对象
  • 分层架构
• 独立构件风格
  • 进程通信
  • 事件驱动系统（隐式调用）
• 虚拟机风格
  • 解释器
  • 规则系统
• 以数据为中心（仓库）
  • 数据库系统
  • 黑板系统
  • 超文本系统

软件工程

ABSD

• 特点
  • 三个基础
    • 对功能进行分解
    • 使用软件架构风格实现质量和功能需求
    • 使用软件模板
  • 从不同的视角检查，得到不同的视图
    • 4+1视图
      • 4
        • 逻辑视图：最终用户
        • 开发/实现视图：程序员
        • 部署视图：系统工程人员
        • 进程视图：系统集成人员
      • 1
        • 用例视图/场景：分析人员/测试人员
• 六个阶段
  • 架构需求
    • 特点：需求库
    • 过程
      • 需求分析
      • 标识构件
        • 生成类图
        • 将类进行分组
        • 将类打包成构件
      • 需求评审
  • 架构设计
    • 过程
      • 提出软件架构模型
      • 映射构件
      • 分析构件相互作用
      • 产生架构
      • 设计评审
  • 架构文档化
    • 产出
      • 架构规格说明书
      • 测试架构需求的质量说明书（架构质量说明书）
  • 架构复审：识别潜在风险，及早发现架构中的缺陷
  • 架构实现
    • 过程
      • 分析与设计
      • 构件实现
      • 构件组装
      • 系统测试
  • 架构演化
    • 过程
      • 需求变动归类
      • 架构演化计划
      • 构件变动
      • 更新构件间相互作用
      • 构件组装与测试
      • 技术评审

UML 图

• 通信图（协作图）和顺序图（序列图）
  • 顺序图强调对象交互的时间次序
  • 通信图强调对象之间存在的消息收发关系，不专门突出时间顺序
• 活动图和流程图
  • 活动图描述的是对象活动的顺序关系所遵循的规则，着重表现系统行为，而非处理过程；流程图着重描述处理过程
  • 流程图一般限于顺序进程，而活动图可以支持并发进程
  • 活动图是面向对象的，而流程图是面向过程的

用例图

用例关系（含义和名称差别比较大，注意记忆）：

• 包含：多个用例共性
• 扩展：单个用例某种场景
• 泛化：父子关系
  • 和类图中泛化的图例一样

总结：

• 只有包含是从左到右，其他都是从右到左

类图

结构化开发与面向对象工具辨析

需求分析

• 核心工具
  • 数据流图
    • 建立软件的需求模型
    • 以图形化的方式呈现业务数据的流动和处理过程
    • 数据平衡原则
      • 父图与子图的平衡：子图和父图的输入输出数据流保持一致
      • 子图内平衡：每个加工必须有输入数据流和输出数据流，反映此架构的数据来源与变换结果
  • 数据字典
    • 关于数据信息的集合
    • 用于对数据流图中每个组成部分加以定义和说明
• 结构化需求分析：数据字典为核心
  • 数据模型：数据结构
  • 行为模型：控制结构
  • 功能模型：系统功能

• 面向对象需求分析：数据字典为核心
  • 对象模型
  • 动态模型
  • 功能模型

对比：

含义	结构化需求分析	面向对象需求分析	结构化建模工具	面向对象建模工具
数据结构	数据模型	对象模型	ER图	类图，对象图
控制结构	行为模型	动态模型	状态转换图	顺序图，通信图，状态图，活动图
系统功能	功能模型	功能模型	数据流图	用例图，数据流图

分析与设计（概要与详细设计）

阶段	结构化工具	面向对象工具
分析/概要设计	模块结构图/模块图，层次图，HIPO图	顶层架构图，用例与用例图，领域概念模型
设计/详细设计	程序流程图，伪代码，盒图	包图（软件体系结构图），交互图（用例实现图），类图，状态图，活动图

软件架构评估

ATAM

• 主要针对
  • 性能
  • 实用性（可用性）
  • 安全性
  • 可修改型
• 阶段
  • 场景和需求收集
  • 架构视图和场景实现
  • 属性模型构造和分析（质量效用树）
  • 折中

质量场景的6个要素

• 六要素
  • 刺激
  • 刺激源
  • 环境
  • 制品
  • 响应
  • 度量指标
• 核心三要素
  • 刺激
  • 环境
  • 响应

风险点和非风险点，敏感点和权衡点

• 风险点：架构设计中潜在的，存在问题的架构决策所带来的隐患
• 非风险点：不会带来隐患的分析与描述
• 敏感点：一个或多个构件（或构件之间的关系）的特性，它能影响系统的某个质量属性
• 权衡点：影响多个质量属性的特性，是多个质量属性的敏感点

数据库

数据库设计过程

锁的进化

阶段	是否加写锁	写锁释放时机	是否加读锁	读锁释放时机	解决的问题	隔离级别
一级封锁协议	是	事务结束	否		丢失更新/脏写	读未提交
二级	是	事务结束	是	读取完毕后	脏读	读已提交
三级	是	事务结束	是	事务结束	可重复读	可重复读
两阶段锁（扩张+收缩）	是	事务结束	是	事务结束	幻读	可串行化

总结：写锁是基本底线，并写要持有到事务结束。读锁从没有 -> 持有到读取完毕->持有到事务结束->两阶段锁

反规范化手段

• 增加冗余列
• 增加派生列
• 重新组表
• 分割表：水平分割

Redis

Redis和MemCache对比

	MemCache	Redis
数据类型	简单key/value结构	string,list,set,hash和zset等丰富的数据结构
持久性	不支持	支持，aof, rdb
分布式存储	哈希分片	主从，Sentinel和Cluster等多种分布式存储方式
多线程	支持	Redis5.0及以前版本不支持
事务支持	不支持	有限支持
数据容灾	不支持	支持，aof, rdb

Redis 淘汰策略

软件架构演进

两层，三层架构

• 两层C/S架构：客户端，网络，数据库服务器
• 三层C/S架构：客户端，网络， 应用服务器，数据库服务器
• 三层B/S架构：浏览器，网络，Web服务器，应用服务器，数据库服务器

遗留系统演化策略

• 淘汰：经过评价，发现将遗留系统完全淘汰，开发全新的系统比改造旧系统从成本上更合算。
• 集成：存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成
• 继承：（TLDR：兼容）在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。
• 改造：包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。

软件安全

安全模型

• BLP 模型：侧重机密性，下读上写
• Biba 模型：侧重完整性，上读下写

信息安全的5个基本要素

• 机密性
• 完整性
• 可靠性
• 可审查型
• 可控性