Windows 11 Version 21H2 更新提示 “你的设备缺少重要的安全更新。”

最近 (2024/12/24) 家里的电脑在 Windows 更新界面提示 “你的设备缺少重要的安全更新。请确保设备保持打开状态并接通电源,以便更新可以完成。”

如下图:

不管如何点击刷新重试,都会出现上述提示。

系统版本为 Windows 11 Version 21H2,详细信息参考下图:

原因为 Windows 11 Version 21H2 已经在 2023/10/10 终止服务,所以已经无法更新系统补丁。如下图:

解决方法就是安装依旧提供支持的系统版本 Windows 11 Version 23H2 或者 Windows 11 Version 24H2

需要注意的是,升级到  24H2 无法保留已经安装的软件,因此当前 (2024/12/24) 只能升级到 23H2  。

对于不支持的硬件进行升级安装,可以通过 Rufus 写入到 U盘后,不重启电脑,直接点击 U 盘上的安装文件进行安装,可以正常完成系统升级。

如下图:

点击开始会弹出如下信息,保持信息不变即可,如下图:

参考链接


OpenSCAD圆角矩形

OpenSCAD实现圆角矩形,可以参考如下代码:

参考链接


Way to round edges of objects opensCAD

Could not find a command named "/data/Android/flutter/bin/cache/dart-sdk/bin/snapshots/frontend_server.dart.snapshot"

经过多次的 Flutter 版本升级,以前的老项目脚本在执行 flutter pub get 相关的命令时候报错如下:

解决方法为删除项目下的所有 pubspec.lock 文件即可。

参考链接


Flutter 错误:找不到名为 frontend_server.dart.snapshot 的命令

Caught error: Unsupported operation: Platform._operatingSystem

Flutter 代码运行在 Chrome 上的时候报错 “Caught error: Unsupported operation: Platform._operatingSystem”。

报错的原因是因为代码中使用了 Platform.isIOSPlatform.isAndroid 等函数判断系统类型,可惜的是,这些函数并不能在 Chrome 上运行。 

修改方法就是自己封装一个自定义工具类,先使用 kIsWeb 排除一下浏览器。参考如下:

参考链接


Flutter Web 警告 Local variable for "serviceWorkerVersion" is deprecated

升级到 Flutter 3.22.0 之后,在 Chrome 上运行 Flutter Web 应用程序时收到以下警告:

这个警告的原因是,新版本的 Flutter Web 应用加载 service_worker.js 的方式发生了变化,原来的加载脚本被 {{flutter_bootstrap_js}} 替代。

调整为新的初始化代码即可解决此问题。

原始的代码如下:

调整后的代码如下:

参考链接


Ubuntu 22.04 LTS 中安装经典 GNOME Flashback 指南

GNOME Flashback(又名 classic GNOME)是旧 GNOME 3 shell 的一个分支,它使用早期 GNOME 2 技术的布局和原则。它的速度快如闪电,并且在设计上非常轻量级。因此,它非常适合几十年前的老旧硬件。

随着带有现代 GNOME 42 的 Ubuntu 22.04 LTS 的发布,有必要寻找轻量级的桌面环境选项。

此外,GNOME Flashback 很容易安装在现代 Ubuntu Linux 中,你仍然可以享受 Ubuntu 性能而不必关心 GNOME 42、GTK4、libadwaita 之类的东西。

在 Ubuntu 22.04 LTS 中下载并安装经典 GNOME Flashback

按照以下步骤在 Ubuntu 22.04 LTS 中下载并安装经典 GNOME Flashback(Metacity)。

在 Ubuntu 22.04 LTS 中打开终端(CTRL+ALT+T)并运行以下命令。安装大小约为 61MB。

Install GNOME Classic Flashback Metacity in Ubuntu 22.04 LTS
Install GNOME Classic Flashback Metacity in Ubuntu 22.04 LTS

最后,安装完成后,退出。重新登录时,在登录选项中使用经典的 GNOME Flashback(Metacity) 。

Choose GNOME Classic while logging in
Choose GNOME Classic while logging in

经典 GNOME Flashback 的特点

首先,当你登录时,你将体验到传统的 GNOME 技术,它已被证明具有良好的生产力,并且比今天的技术快得多。

在顶部有旧版的面板,左侧是应用菜单,而系统托盘位于桌面的右上方。应用程序菜单显示所有已安装的应用和软件快捷方式,你可以在工作流程中轻松浏览。

此外,在右侧部分,系统托盘具有默认小部件,例如网络、音量控制、日期和时间以及关机菜单。

Classic GNOME Flashback Metacity in Ubuntu 22.04 LTS
Classic GNOME Flashback Metacity in Ubuntu 22.04 LTS

底部面板包含打开的窗口和工作区切换器的应用列表。默认情况下,它为你提供四个工作区供你使用。

此外,你可以随时更改顶部面板的设置以自动隐藏、调整面板大小和背景颜色。

除此之外,你可以通过 ALT + 右键点击 顶部面板添加任意数量的旧版小程序。

Panel Context Menu
Panel Context Menu

 

Add to panel widgets
Add to panel widgets

经典 GNOME 的性能

首先,磁盘空间占用极小,仅安装 61 MB。我的测试使用了大约 28% 的内存,其中大部分被其他进程占用。猜猜是谁?是的,是 snap-store(又名 Ubuntu 软件)。

因此,总体而言,它非常轻巧,内存(仅 28 MB)和 CPU(0.1%)占用空间非常小。

Performance of GNOME Classic in Ubuntu 22.04
Performance of GNOME Classic in Ubuntu 22.04

此外,假设你将其与同样使用相同技术的 Ubuntu MATE 进行比较。在这种情况下,它比 MATE 更轻量,因为你不需要任何额外的 MATE 应用及其用于通知、主题和其他附加资源的软件包。

结束语

我希望本指南在你决定在 Ubuntu 22.04 LTS Jammy Jellyfish 中安装经典 GNOME 之前帮助你获得必要的信息。

参考链接


Flutter error G5FE39F1E: Type 'UnmodifiableUint8ListView' not found

问题描述

原本在 macOS 开发的项目,现在 Windows 10 运行时报如下错误:

解决方法

参考链接


Flutter Error: Type ‘UnmodifiableUint8ListView‘ not found

2023年下半年系统架构设计师下午论文真题

试题一 论边缘计算及其应用

边缘计算是在靠近物或数据源头的网络边缘侧,融合网络、计算、存储、应用核心能力的分布式开放平台(架构),就近提供边缘智能服务。边缘计算与云计算各有所长,云计算擅长全局性、非实时、长周期的大数据处理与分析,能够在长周期维护、业务决策支撑等领域发挥优势;边缘计算更适用局部性、实时、短周期数据的处理与分析,能更好地支撑本地业务的实时智能化决策与执行。因此边缘计算与云计算之间不是替代关系,而是互补协同关系,边云协同将放大边缘计算与云计算的应用价值。

请围绕“论边缘计算及其应用”论题,依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。

2.结合项目实际,概要说明六种边云协同,既资源协同、数据协同、智能协同、应用管理协同、业务管理协同、服务协同的含义。

3.具体阐述你参与管理和开发的项目如何利用边缘计算进行设计与实现。

试题二 论多源数据集成及应用

在如今信息爆炸的时代,企业、组织和个人面临着大量的数据。这些数据来自不同的渠道和资源,包括传感器、社交媒体、销售记录等,它们各自具有不同的数据格式、分布和存储方式。因此如何收集、整理和清洗数据,以建立一个一致、完整的数据集尤为重要。多源数据集成可以提供更全面的数据视角,将来自不同渠道的数据结合起来,通过这种方式整合多个数据源,从而减少单一数据源带来的误差和不准确性。此外,多源数据集成还可以帮助识别和矫正数据中的错误和重复项,提高数据的质量。

请围绕“论多源数据集成及应用”论题,依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。

2.结合项目实际,详细说明多源数据集成的策略有哪些。

3.具体阐述你参与管理和开发的项目如何基于多源数据集成进行设计与实现。

试题三 论面向对象的建模及应用

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

请围绕“论面向对象的建模及应用”论题,依次从以下三个方面进行论述。

1.概要叙述你参与的软件系统开发项目以及你所担任的主要工作。

2.说明什么是用例模型和分析模型以及你所参与的项目中是如何使用这两种模型的。

3.详细说明你所参与的软件系统开发项目在使用用例模型和分析模型的过程中遇到哪些问题,是如何解决的。

试题四 论软件的可靠性评价

软件可靠性评价是软件可靠性活动的重要组成部分,既适用于软件开发过程,也可针对最终软件系统。在软件开发过程中使用软件可靠性评价,可以使用软件可靠性模型,估计软件当前的可靠性,以确认是否可以终止测试并发布软件,同时还可以预计软件要达到相应的可靠性水平所需要的时间和工作量,评价提交软件时的软件可靠性水平。对于最终软件产品,软件可靠性评价结合可靠性验证测试,确认软件的执行与需求的一致性,确定最终软件产品所达到的可靠性水平。

请围绕“论软件的可靠性评价”论题,依次从以下三个方面进行论述。

1.概要叙述你参与开发的软件项目以及你在其中所承担的主要工作。

2.说明可靠性模型有哪些,以及如何选择合适的可靠性模型。

3.具体阐述你参与开发的项目如何对选用的可靠性模型进行分析来进行可靠性评价的。

参考链接


2023年下半年系统架构设计师下午论文真题

2024年11月系统架构设计师论文冲刺指南

众所周知,系统架构设计师考试论文科目考察的范围很广,几乎涵盖了软件开发的方方面面,包括软件工程、数据库、架构基础理论以及热门技术等。

面对如此广泛的考察范围,我们常常会感觉无从下手,不知道怎么写、写哪些主题以及从哪些主题开始写起。特别是越临近考试日期,我们就越着急和恐惧,越不知所措。

可是,着急和恐惧除了让我们的心境更加焦躁不安之外,并不能真正解决任何问题,反而可能影响我们的判断力和创造力,使我们在准备论文的过程中更加难以集中注意力。

因此,在这个关键时刻,保持冷静和积极的心态尤为重要。我们需要调整好心态,并通过有效的写作训练来帮助我们战胜“论文”这个敌人,而不是让负面情绪左右我们的行动。

那么,我们应该怎么样进行有效的训练呢?

首先,我们需要了解论文的本质,只有了解了论文的本质,真正对论文祛魅了,我们才能做到"以终为始"和"精准打击"。

然后,我们需要掌握通用的论文写作思路。不管论文试题如何变化,我们要用固定的套路,以不变应万变,做到"兵来将挡水来土掩"。

接下来,我们要正确处理论文和技术的关系。技术不是论文的核心和主体,技术只是起到支撑论述的作用。

最后,我们要选取种子主题并勤加练习。我们不能"广撒网",而是应该把握核心,做到"以少胜多,四两拨千斤"。

通过上述步骤进行有效的训练,不仅有助于构建清晰的写作框架,还能提高文章的专业性和说服力,从而在考试中写出合格的论文。接下来,我们将逐一解析上述要点,希望能为即将参加系统架构设计师考试的你提供实质性的帮助。

论文的本质

论文的本质是对特定问题解决方案的展示。不管是软件工程、数据库,还是架构方面的论文试题,其目的都是考察我们在项目中是如何解决特定问题的。比如,敏捷开发方法是为了解决传统的瀑布开发方法中存在的不能灵活应对需求变更的问题 ,NoSQL 数据库是为了解决关系型数据库存在的数据格式不灵活、扩展困难等问题,云原生架构是为了解决传统架构中开发人员不能专注于业务本身、需要分心处理非功能特性的问题。

通用论文写作思路

在了解了论文的本质过后,我们要采用"以始为终"的策略,论文考察什么,论文的本质是什么,我们就怎么备考论文,也就是所谓的"知己知彼,百战不殆"。

现在,我们已经明确了论文的本质是对特定问题解决方案的展示,下一步我们要做的就是了解如何展示特定问题的解决方案。

在这里,我们需要通过抽象,从众多的解决方案中抽取出属于解决方案的共同的、本质的特征,并舍弃非本质的特征。这些共同的、本质的特征,有助于我们总结通用的论文写作思路,不管论文题目如何变化,我们都能以固定的套路去应对,以不变应万变,实现"兵来将挡水来土掩"。

解决方案最本质的特征是它有一个结构化的框架。一般来说,一个完整的解决方案包括但不限于以下内容:问题背景、目标、具体内容、碰到的困难及解决办法、结果。

既然,论文的本质是对特定问题解决方案的展示,那么我们写论文时也应该还原解决方案最本质的特征——结构化框架,这样我们的论文才会有条理、逻辑清晰和论证充分,才更容易获得阅卷老师的认可。

以下就是一个通用的描述解决方案的结构化框架。

问题背景

首先,明确你要讨论的问题是什么,这个问题产生的背景是什么。在系统架构设计师考试论文科目这个场景下,背景信息包括项目的基本信息、你在这个项目中担任的角色以及承担的主要工作、在这个项目中面临着什么样的困难或挑战(从指定论文主题的角度去思考)。

目标

接着,阐述你的解决方案要解决的具体问题或要达到的目标。比如,通过使用敏捷开发方法降低项目失败的风险。

具体内容

这部分是解决方案的核心,需要详细描述你的解决方案,包括解决方案的核心思想、具体实施过程、你采用了哪些手段、你遵循了哪些原则等。确保这一部分的内容逻辑清晰、论据充分,能够有力支持你的观点。

我们可以采用"总分总"的形式来描述我们的解决方案。

首先,简明扼要地从整体上概括该解决方案的核心思想。

然后,从时间维度或空间维度分 2- 3 点展开我们的解决方案。

怎么理解时间维度呢?任何解决方案要落地,都会有步骤地进行实施,我们可以按照步骤一步一步地展开,这就是时间维度。

怎么理解空间维度呢?任何解决方案,都有若干个关键、若干个模式、若干个原则、若干个最佳实践等,我们可以选择 2-3 个展开,这就是空间维度。

遇到的困难及解决办法

在解决问题的过程中,我们难免会遇到各种阻碍。这部分要求我们记录下这些困难或挑战,并分享你是如何克服它们的。这不仅展示你的问题解决能力,同时也能凸显你项目的真实性。

此外,这部分也是字数不够的万能补救方法。如果你把前面的 4 点都写过了,字数还不够,你也可以描述你遇到的困难及解决方法。

结果

最后,总结你这个解决方案的实际效果。如果可能的话,可以提供一些指标数据直观地展示出来,增强说服力。

下面,我以一个具体的论文题目为例来展示在论文中如何展现你的解决方案。

该论文题目是来自于 2020 年系统架构设计师考试论文科目中的试题三《论云原生架构及其应用》,也是某培训机构要求重点关注的题目之一。

论云原生架构及其应用

请围绕"论云原生架构及其应用"论题,依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的软件项目以及承担的主要工作。

2.服务化、弹性、可观测、韧性和自动化是云原生架构重要的设计原则,请简要对这些设计原则的内涵进行阐述。

3.具体阐述你参与管理和开发的项目是如何采用云原生架构的,并围绕上述设计原则,详细论述你在项目设计与实现过程中遇到哪些实际问题,是如何解决的。

我们把云原生架构看作是一种解决方案,论文需要展示这个解决方案。

首先要明确这个解决方案是解决什么问题的,即云原生架构是解决什么问题的?迅速回忆一下云原生架构相关的知识,云原生架构是为了解决传统开发模式存在的非功能特性保障难的问题,比如弹性、韧性、安全、可观测性。在搜索到相关的知识点之后,继续思考,既然云原生架构是解决这些问题的,那么就要说项目中面临着这些问题。比如,可以这样写:

在该项目中,由于加油站是一个高度运转的环境,系统的稳定性至关重要。在稳定性方面,我们主要面临着以下三个挑战:如何确保能够及时发现并处理系统的问题,以维持系统的稳定运行;如何实现在流量高峰时段自动扩展资源,而在低峰时段释放多余资源,以最大化资源利用率;如何实现从代码提交到生成环境部署的全流程自动化,以提高开发效率并减少人为错误。

这样写,清晰地描述了在非功能特性保障方面遇到的挑战。

接下来,需要描述解决方案的目标,引出论题,可以这样写:

为了应对这些挑战,经过项目团队成员充分讨论,我们决定采用云原生架构来提高系统的稳定性,最大限度保障加油站业务的连续性。

接下来,可以简单介绍一下云原生架构的一些理论知识,至于介绍哪些方面,需要严格遵照试题中的要求。在这里,题目要求我们介绍云原生架构设计原则的内涵。理论知识是纯记忆和理解的东西,此处不再赘述。

接下来,可以介绍解决方案的具体的内容。既然题目要求围绕设计原则来展开,那首先从设计原则的角度总体概述一下解决方案,可以这样写:

在该项目中,云原生架构的运用,我们主要遵循了可观测、弹性和自动化的设计原则。其中,遵循可观测原则确保能及时发现并处理系统的问题,以维持系统的稳定运行;遵循弹性原则实现资源的按需分配和弹性伸缩;遵循自动化原则提高开发效率并减少人为错误。

然后,分别从可观测原则、弹性原则和自动化原则三个方面展开我们的解决方案。如何展开呢?在这里,可以把每个方面或每个步骤也看做是一个小型的解决方案,按照解决方案的写法展开每个方面或每个步骤。比如,以可观测为例,可以这样写:

我们遵循可观测原则确保能够及时发现并处理系统的问题,以维持系统的稳定运行。我们采取了一系列措施来加强系统的可观测性,包括自动化性能监控与告警、日志集中管理以及调用链跟踪……(分别从这三个方面介绍我们具体是如何做的,最后举一个具体事例支撑论述)

弹性原则和自动化原则部分,也是类似的套路,此处也不再赘述。

当解决方案展开论述完毕之后,可以这样描述结果:

通过云原生架构的运用,我们提高了系统的稳定性、降低了成本并提高了开发效率。最终,经过 10 个月的研发,该项目于 2023 年 12 月完成并交付上线,至今运行稳定,各项功能和性能指标均达到客户要求,得到了客户和各级领导的一致好评。

至此,就把整个解决方案描述清楚了。

采用这个通用论文写作思路来备考和撰写系统架构设计师考试论文,有以下几个显著的好处。

  1. 增强逻辑性和条理性

    通过构建一个结构化的框架,每一篇论文都能够保持清晰的逻辑和条理性。这种结构不仅有助于我们组织思路,也有助于阅卷老师快速抓住论文的核心内容,提高评分效率。例如,先介绍问题背景,再明确目标,接着介绍解决方案的具体内容,最后总结成果,这样的结构能够让论文内容层次分明,一目了然。

  2. 提高专业性和说服力

    按照论文的本质来准备,能够确保论文内容的专业性和说服力。通过对特定问题解决方案的深入剖析,结合实际情况提出具体措施,并详细描述遇到的困难及解决方法,可以让阅卷老师感受到我们深厚的理论功底和丰富的实践经验。

  3. 减轻备考压力

    掌握了论文写作的固定套路后,可以更加自信地面对各种可能的考题。无论考题如何变化,都可以迅速联想到论文的本质,即展示特定问题的解决方案,并根据结构化框架有序展开论述。这不仅有助于提高备考效率,还能有效减轻考前的心理压力,让我们以更加平和的心态迎接考试。

  4. 培养良好的写作习惯

    在备考过程中,通过不断地练习和反馈,可以逐渐培养出良好的写作习惯。这种习惯不仅对于通过考试大有裨益,对未来的职业发展同样重要。无论是撰写技术文档、研究报告还是项目提案,良好的写作习惯都将帮助我们更有效地表达观点,提升沟通效率。

正确处理论文和技术的关系

在论文中,正确处理论文和技术的关系是非常重要的。技术在论文中扮演的角色并不是主导地位,而是只是作为一种支撑手段,用来证明你的解决方案的有效性和可行性。因此,理解并正确处理两者之间的关系,对于写出合格的论文至关重要。

首先,需要明确的是,虽然技术是实现解决方案的重要工具,但它并不是论文的核心。论文的核心应该是对特定解决方案的展示,包括问题背景、目标、具体的实施步骤、遇到的挑战和最终的结果。技术的应用应当服务于这些内容的呈现,帮助阅卷老师更好地理解和接受你的观点。

其次,技术在论文中的作用更多是为了支撑论述,而不是为了炫耀技术能力。当你在论文中谈到某种技术时,应该着重于解释这项技术是如何帮助解决问题的,而不是详细描述技术本身的原理和实现细节。当然,适当的背景介绍和技术说明是必要的,但这些都应该服务于论文的整体论述,而不是喧宾夺主。

如果你不熟悉某个技术,也不要紧。技术本身也是一种解决方案,我们完全可以按照前面提到的结构化框架对技术进行拆解,掌握宏观上的设计思想和理念,将这些运用到论文写作中绰绰有余,哪里需要讲技术实现细节!

需要练习哪些论文呢

由于论文考察的范围较广,备考的时间有限,不可能所有主题都写上一遍,事实上也做不到。

因此,要想提高论文写作效率,必须练习一部分种子主题,并想办法将这些论文中的素材迁移到其他的论文主题中,就算没时间写,也要提前思考。只有这样,才能"以少胜多,四两拨千斤"。

那么哪些主题可以算得上是种子主题呢?

就系统架构设计师的论文而言,主要有两个重要的种子主题:质量属性和热门架构模式。其中质量属性主题又包括以下子主题:性能设计、安全性设计、可靠性设计和可修改性设计,热门架构模式主题又包括以下子主题:架构风格、层次式架构、微服务架构、云原生架构和大数据架构。

为什么要选择质量属性主题作为种子主题呢?

质量属性是系统设计或架构设计的主要目标,质量属性设计也是解决方案的核心组成部分。任何解决方案的目标都是为了满足质量属性。例如,提高系统的响应速度是为了满足性能要求,确保系统的不间断运行是为了满足可用性要求,云原生架构是为了提高系统的可扩展性和可靠性等。

此外,质量属性贯穿整个系统生命周期,在每个阶段,都需要考虑和优化这些质量属性,因此,掌握质量属性的设计方法,可以帮助更好地完成各个阶段的任务。

掌握了质量属性的设计方法和策略,就能应对系统设计或者架构设计方面的绝大部分主题。比如,如果项目采用设计模式提高了系统的可维护性,那么这个事例就可以抽取为素材并运用在面向对象设计、可维护性、架构演化等多个主题中。

为什么选择热门架构模式作为种子主题呢?

模式是成熟的套路,是经过实践检验的经验的总结。掌握模式可以让我们在设计系统时少走弯路,事半功倍。正因为如此,热门的架构模式必然成为论文科目的新宠。

结合之前某机构的初步预测,需要重点准备的论文主题分为以下三个梯队:

第一梯队:微服务架构、云原生架构、层次式架构、架构风格

第二梯队:性能设计,可靠性设计,安全性设计,可修改性设计

第三梯队:RUP 统一过程开发方法、基于架构的开发方法、基于构件的软件开发方法、架构评估方法、系统测试、企业应用集成。

其中,第一梯队的优先级最高、第二梯队的优先级次之,第三梯队的优先级最低。

纸上得来终觉浅,绝知此事要躬行

本文围绕系统架构设计师考试的论文备考策略展开,详细介绍了论文写作的本质和通用写作思路,强调了正确处理技术和论文关系的重要性,并提出了具体的练习和准备策略。

首先,论文的本质是展示特定问题的解决方案,因此,需要从问题背景、目标、具体内容、遇到的困难及解决方法、结果等方面进行结构化的论述。通过这种方法,能够增强论文的逻辑性和条理性,提高专业性和说服力,减轻备考压力,并培养良好的写作习惯。

其次,正确处理技术和论文的关系尤为重要。技术在论文中应作为支撑手段,而非核心。应当着重于技术如何帮助解决问题,而不是详细描述技术本身的原理和实现细节。

最后,针对备考时间有限的情况,建议重点准备质量属性(如性能设计、安全性设计、可靠性设计和可修改性设计)和热门架构模式(如微服务架构、云原生架构、层次式架构和架构风格)等种子主题。通过练习这些主题,可以有效地将素材迁移到其他主题中,实现“以少胜多,四两拨千斤”。

参考链接


系统架构设计师 & 系统分析师论文范文:《论软件可靠性设计及其应用》

软件可靠性主题,在系统架构设计师和系统分析师考试论文科目中,总共直接考察过 5 次,分别是 2023 年系统架构设计师论文科目试题一《论软件可靠性分析与评价》,2014 年系统架构设计师论文科目试题三《论软件的可靠性设计》,2013 年的系统架构设计师论文科目试题三《论软件的可靠性设计技术的应用》,2013 年系统分析师论文科目试题四《论信息系统的可靠性分析与设计》,2010 年系统架构设计师论文科目试题四《论软件可靠性评价》。下面我们来看看这几道试题是怎么考的。

2014 年系统架构设计师论文科目试题三

请以"论软件的可靠性设计"为题,依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作。

2.简要说明目前比较主流的软件可靠性设计技术,结合项目实际情况,阐述所选择的可靠性设计技术及其原因。

3.结合你具体参与管理和开发的实际项目,举例说明所选取的软件可靠性技术的具体实施过程,并详细分析实施效果。

2013 年系统架构设计师论文科目试题三

请围绕"软件可靠性设计技术的应用"论题,依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作。

2.结合项目实际,论述你在项目开发过程中,进行软件可靠性设计时遵循的基本原则,以及你在该项目中所采用的具体可靠性设计技术。

3.阐述你在具体的可靠性设计工作中,为了分析影响软件可靠性的主要因素,所采用的可靠性分析方法。

2013 年系统分析师论文科目试题四

请围绕"信息系统的可靠性分析与设计"论题,依次从以下三个方面进行论述。

1.概要叙述你参与管理和开发的信息系统以及你在其中所担任的主要工作。

2.容错技术是提高系统可靠性的常用技术,请列举两种常见的系统容错技术,并对每种技术进行解释。

3.结合你具体参与管理和开发的信息系统,说明在系统分析与设计过程中针对何种具体的可靠性要求,使用了哪些提高系统可靠性的技术,具体实施过程和效果如何。

2010 年系统架构设计师论文科目试题四

请围绕"软件可靠性评价"论题,依次从以下三个方面进行论述。

1.简要叙述你参与实施的软件开发项目以及你担任的主要工作。

2.说明你在项目实施过程中所选择的软件可靠性模型,并论述在软件可靠性模型选择时应该考虑的主要因素。

3.收集软件可靠性数据时经常遇到的问题有哪些,简述你收集软件可靠性数据时所遇到的具体问题及解决的方法。

不难看出,对于软件可靠性的考察主要集中在可靠性分析、设计和评价三个方面。但由于可靠性分析和可靠性评价都涉及到了可靠性模型,可靠性模型过于复杂和抽象,再加上也没有具体的案例可以参考,我们不建议死磕,毕竟难度太高。我们应该着重掌握常见的可靠性设计技术主题论文的写法。

相关知识点

可靠性

软件可靠性是指软件系统在一定的时间内持续无故障运行的能力。

可靠性通常用平均失效等待时间(MTTF)和平均失效间隔时间(MTBF)来衡量。

影响可靠性的因素

从技术的角度来看,影响软件可靠性的主要因素如下。

1.运行剖面(环境):软件可靠性的定义是相对运行环境而言的,一样的软件在不同的运行剖面下,其可靠性的表现是不一样的。

2.软件规模:软件规模也就是软件的大小,一个只有数十行代码的软件和几千、几万行代码的软件是不能相提并论的。

3.软件内部结构:结构对软件可靠性的影响主要取决于软件结构的复杂程度,一般来说,内部结构越复杂的软件,所包含的软件缺陷数就可能越多。

4.软件的开发方法和开发环境:软件工程表明,软件的开发方法对软件的可靠性有显著影响。

5.软件的可靠性投入:软件在生命周期中可靠性的投入包括开发者在可靠性设计、可靠性管理、可靠性测试和可靠性评价等方面投入的人力、资金、资源和时间等。经验表明,在早期重视软件可靠性并采取措施开发出来的软件,可靠性有明显的提高。

可靠性设计技术
容错设计技术

常见的容错设计技术主要有恢复块设计、N 版本程序设计和冗余设计三种方法。

恢复块设计指将程序看作是由一系列的恢复块组成的,一个恢复块包括若干个功能相同、设计差异的程序块,每一时刻只有一个程序块处于运行状态。一旦该程序块出现故障,则用备份程序块加以替换,从而构成"动态冗余"。

N 版本程序的核心是通过设计出多个模块或不同版本,对于相同初始条件和相同输入的操作结果,实行多数表决,防止其中某一软件模块/版本的故障提供错误的服务,以实现软件容错。

冗余设计是指在一套完整的软件系统之外,设计一种不同路径、不同算法或不同实现方法的模块或系统作为备份,在出现故障时可以使用冗余的部分进行替换,从而维持软件系统的正常运行。

集群技术

集群技术是指将多个独立的服务器通过网络互联,形成一个统一的整体,对外提供相同的服务。在集群中,各个服务器之间可以相互监控、负载均衡和故障转移,从而确保整个系统的稳定运行。

当集群中的某个服务器发生故障时,其他服务器可以接管其工作,确保服务不中断,这种机制大大降低了单点故障的风险。

集群可以根据服务器的负载情况,合理分配任务,避免某个服务器过载,提高整体系统的可靠性。

集群中的服务器通过心跳信号相互监控,一旦某服务器心跳消失,则可认为其发生故障。

总之,集群技术是提高系统可靠性和性能的有效手段。在实际应用中,应根据业务需求和预算,合理选择和配置集群,以达到最佳效果。

检错技术

检错技术是指在软件出现故障后能够及时发现故障并报警,提醒维护人员进行处理。

检错技术实现的代价一般低于容错技术和冗余技术。

但它有一个明显的缺点,就是不能自动解决故障,出现故障后如果不进行人工干预,将最终导致软件系统不能正常运行。

防卫式程序设计

防卫式程序设计是一种编程范式,旨在创建能够预测和防止错误的程序。这种理念强调在编写代码时采取预防措施,以确保程序在面对意外情况、不合理的输入或错误地使用时,仍能保持稳定运行,不产生不可预见的行为。

防卫式程序设计的目的是提高软件的健壮性、可靠性和安全性,减少软件缺陷和漏洞,从而降低维护成本和提高用户体验。通过采取这些措施,程序在面临异常情况时能够更加稳健地运行,减少系统错误和崩溃的风险。

接下来,我们进入主题,来看看下面这篇范文。

论软件可靠性设计及其应用

摘要

2023 年 3 月,我所在的公司承接了某油企智慧加油站平台的建设工作。该项目旨在帮助加油站提升运营效率、降低运营成本和提高销售额。我在该项目中担任系统架构设计师,负责整个项目的架构设计工作。

本文结合我在该项目中的实践,详细论述了软件可靠性设计技术的具体应用。我们主要采用了防卫式程序设计、集群技术和检错技术三种可靠性设计技术。我们采用防卫式程序设计预见潜在错误并提前采取措施,采用集群技术避免单点故障,采用检错技术及时发现故障并报警。通过以上三种技术,我们有效地提升了系统的可靠性。

整个项目历时 10 个月开发完成,并于 2023 年 12 月正式交付并稳定运行至今,各项功能和性能指标均达到了客户要求,得到了客户和各级领导的一致好评。

正文
项目背景

随着国内成品油零售行业竞争日益激烈,某油企为增强市场竞争力,决定建设一个智慧加油站平台,通过引入信息技术来优化运营管理,进一步提升加油站的管理水平和服务质量。我所在的单位成功中标该项目,并于 2023 年 3 月正式启动该项目的建设工作。我被任命为系统架构设计师,负责该项目的系统架构设计工作。

该项目的主要建设内容包括智慧支付、智慧营销、智慧运营等功能子系统。其中智慧支付子系统提供了对多种支付方式的支持,比如现金支付、油卡支付、微信支付、支付宝支付、云闪付支付、车牌付、人脸付、ETC 支付等,以确保顾客下单支付的便利性和安全性;智慧营销子系统支持开展多种形式的营销活动,比如消费返券、趣味抽奖、积分任务、限时秒杀、充值优惠等,以提高顾客复购率;智慧运营子系统涵盖了站务管理、运营数据统计分析等功能,以提高加油站运营效率。

该项目选用 Java 作为主要开发语言,采用基于 Spring Cloud Alibaba 的微服务架构进行构建。我们选择 MySQL 作为数据库,Doris 作为实时数仓,Redis 作为分布式缓存,RocketMQ 作为消息中间件,Flink 作为实时流式计算引擎,并最终在 Kubernetes 集群中部署运行。

可靠性设计的重要性

由于加油站是一个高度运转的环境,任何故障都可能影响加油站的正常运营,因此保障系统的可靠性显得至关重要。软件可靠性是指软件在一定的时间内持续无故障运行的能力,通常使用通常用平均失效等待时间(MTTF)和平均失效间隔时间(MTBF)来衡量。

主流的可靠性设计技术主要有防卫式程序设计、集群技术和检错技术。防卫式程序设计强调在编写代码时采取预防措施,以确保程序在面对意外情况、不合理的输入或错误的使用时,仍能保持稳定运行,避免产生不可预见的行为。集群技术是一种将多台服务器连接在一起,共同工作以实现特定目标的技术。这些节点通过高速网络连接,对外表现为一个单一的系统,共同承担计算任务、数据存储和应用程序的运行。检错技术是指在软件系统出现故障后能够及时发现并告警,提醒相关人员进行处理。检错技术的代价一般低于容错技术和冗余技术。检错技术有一个明显的缺点,那就是发现故障后不能自动修复故障,需要人工进行干预。

在该项目中,为了提高系统的可靠性,我们主要采用了防卫式程序设计、集群技术和检错技术三种可靠性设计技术。下面我将详细介绍这三种可靠性技术在该项目中的具体应用。

防卫式程序设计

我们采用防卫式程序设计来预见错误并提前采取措施来减少这些错误的影响。在智慧营销子系统中,加油站通常会和合作商家联手开展个性化的营销活动,以此提高用户的忠诚度和复购率,一种常见的合作形式是用户在智慧加油站平台中参与营销活动后所获得的奖励需要通过合作商家提供的开放的 API 接口进行兑换。然而,合作商家的系统可能存在不稳定的情况,比如频繁请求响应慢或请求超时等问题。为了避免该系统被这些外部系统拖垮,在智慧营销子系统开发之初,我们就设计了熔断的处理策略。当检测到合作商家的 API 接口在一段时间内频繁出现响应慢或者请求超时等问题,系统会立即停止对合作商家 API 接口的调用,防止问题的进一步扩散。这样可以确保其他子系统的功能不受影响,依然能够正常运行。在熔断期间,系统会持续监测合作商家的系统状态,并定期发起试探性的请求,如果试探请求正常了,则恢复对其接口的正常调用,以恢复奖励兑换等功能。通过熔断措施,我们有效控制了外部系统故障的影响范围,避免了局部的故障逐渐演变为严重的系统事故。

集群技术

我们采用集群技术来避免单点故障。为了简化集群的管理,我们最终将系统部署运行在 Kubernetes 集群上。Kubernetes 可以管理多个工作节点,每个工作节点上可以部署多个服务,此外,还提供自动故障转移和服务自愈的能力。我们将整个系统划分为多个可以独立开发、独立部署的小服务,每个服务开发完成后,我们将其打包成为 Docker 镜像,并编写该服务的 Deployment 描述文件,在这个文件中配置所需的 CPU 资源、内存资源以及期望的服务副本数量等信息。然后通过 kubectl apply 命令将该服务部署到 Kubernetes 中,多个服务实例会被均匀地部署到多个工作节点上。Kubernetes 会定期检查这些服务实例的状态,确保它们按照预设的数量正常运行。如果某个工作节点宕机了,该工作节点上的服务实例会在其他工作节点上重新部署,从而实现了自动故障转移。如果某个服务实例意外停止或崩溃,Kubernetes 将自动创建新的服务实例来确保服务实例数量与预设的数量相符,从而实现了服务自愈。这一过程无需人工干预,有效地保障了系统的稳定性和可靠性。

检错技术

我们采用检错技术确保能够及时发现故障并报警,提醒相关人员进行处理。我们采用了 Prometheus 和 Grafana 搭建了一套实时自动化的监控告警系统,用于监控各个工作节点、服务以及组件的运行状态和关键指标,比如内存使用率、CPU 使用率、磁盘使用率、网络带宽占用、响应时间 TP99、请求错误率等。当检测到异常时,该监控告警系统就会自动触发告警,提醒相关人员处理。提醒的方式主要包括短信和企业微信。通过这种方式,我们可以对系统的健康状况有一个全面的了解,并且可以在问题发生时迅速做出反应。

例如,在一次消费送积分的营销活动中,监控告警系统检测到积分服务的响应时间突然增加,并触发了告警。我们收到告警信息后,通过查看 Grafana 的可视化实时监控图表发现某个工作节点的磁盘使用率达到了 100%,然后我们对该工作节点进行了进一步的排查,发现了问题源头在于该工作节点的磁盘被大量日志文件占满了,这导致积分服务无法正常提供服务。于是我们迅速采取了行动,清理了不必要的日志文件,并优化了日志的存储策略,解决了磁盘空间不足的问题,恢复了积分服务的正常运行。

总结与感悟

通过以上可靠性设计技术的运用,我们有效提高了系统的可靠性,从而确保了业务的连续性。最终,经过 10 个月的研发,该项目于 2023 年 12 月完成并交付上线,至今运行稳定,各项功能和性能指标均达到客户要求,得到了客户和各级领导的一致好评。虽然项目取得了成功,但我们也看到了一些不足之处,其中需求频繁变更导致项目团队经常加班是比较突出的问题。针对这个问题,我们采取了以下两个措施:一是规范需求变更流程,提升变更成本,以避免过度的需求变更;二是通过灵活的配置和架构设计,低成本响应需求变更。

通过该项目的开发,我在系统分析与设计方面积累了不少宝贵的经验,为我后续的工作提供了很大的帮助。这也激励着我不断学习,不断丰富自己的知识体系,为将来能够应对更复杂的工作做好准备。

参考链接