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 月完成并交付上线,至今运行稳定,各项功能和性能指标均达到客户要求,得到了客户和各级领导的一致好评。虽然项目取得了成功,但我们也看到了一些不足之处,其中需求频繁变更导致项目团队经常加班是比较突出的问题。针对这个问题,我们采取了以下两个措施:一是规范需求变更流程,提升变更成本,以避免过度的需求变更;二是通过灵活的配置和架构设计,低成本响应需求变更。

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

参考链接


软考系列(系统架构师)- 2022年系统架构师软考案例分析考点

试题一 软件架构(架构风格、质量属性)

试题一是必答题
阅读以下关于软件架构设计与评估的叙述,在答题纸上回答 问题 1 问题 2
【说明】
某电子商务公司拟升级其会员与促销管理系统,向用户提供个性化服务,提高用户的粘性。在项目立项之初,公司领导层一致认为本次升级的主要目标是提升会员管理方式的灵活性,由于当前用户规模不大,业务也相对简单,系统性能方面不做过多考虑。新系统除了保持现有的四级固定会员制度外,还需要根据用户的消费金额、偏好、重复性等相关特征动态调整商品的折扣力度,并支持在特定的活动周期内主动筛选与活动主题高度相关的用户集合,提供个性化的打折促销活动。
在需求分析与架构设计阶段,公司提出的需求和质量属性描述如下:
(a)管理员能够在页面上灵活设置折扣力度规则和促销活动逻辑,设置后即可生效;
(b)系统应该具备完整的安全防护措施,支持对恶意攻击行为进行检测与报警;
(c)在正常负载情况下,系统应在0.3秒内对用户的界面操作请求进行响应;
(d)用户名是系统唯一标识,要求以字母开头,由数字和字母组合而成,长度不少于6个字符;
(e)在正常负载情况下,用户支付商品费用后在3秒内确认订单支付信息;
(f)系统主站点电力中断后,应在5秒内将请求重定向到备用站点;
(g)系统支持横向存储扩展,要求在2人•天内完成所有的扩展与测试工作;
(h)系统宕机后,需要在10秒内感知错误,并自动启动热备份系统;
(i)系统需要内置接口函数,支持开发团队进行功能调试与系统诊断;
(j)系统需要为所有的用户操作行为进行详细记录,便于后期查阅与审计;
(k)支持对系统的外观进行调整和配置,调整工作需要在4•人天内完成。
在对系统需求、质量属性描述和架构特性进行分析的基础上,系统架构师给出了两种候选的架构设计方案,公司目前正在组织相关专家对系统架构进行评估。

【问题  1 】(12分)
在架构评估过程中,质量属性效用树(utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入 图1-1 中(1)、(2)空白处,并选择题干描述的(a)~(k)填入(3)~(6)空白处,完成该系统的效用树。

图 1-1 会员与促销管理系统效用树

【问题  2 】(13分)
针对该系统的功能,李工建议采用面向对象的架构风格,将折扣力度计算和用户筛选分别封装为独立对象,通过对象调用实现对应的功能;王工则建议采用解释器(interpreters)架构风格,将折扣力度计算和用户筛选条件封装为独立的规则,通过解释规则实现对应的功能。请针对系统的主要功能,从折扣规则的可修改性、个性化折扣定义灵活性和系统性能三个方面对这两种架构风格进行比较与分析,并指出该系统更适合采用哪种架构风格。

答案与解析
  • 试题难度:一般
  • 知识点:案例分析>质量属性
  • 试题答案:
    【问题 1】(12分)
    (1)安全性
    (2)可修改性
    (3)E
    (4)J
    (5)H
    (6)K

    【问题 2】(13分)
    灵活性,解释器优于面向对象,因为解释器架构可以通过解释器来解析,动态的适配对象需要的规则。
    可修改性,解释器优于面向对象,因为解释器是独立的语法规则,只需要新增规则和修改规则就好。
    性能,面向对象优于解释器,因为不需要再次解析,对象和规则在一个整体一起运行。
    综合考虑,这个场景解释器架构更适合规则系统。

从下列的 4 道试题(试题二至试题五)中任选 2 道解答。

试题二 软件建设与设计(E-R图)

阅读以下关于软件系统设计与建模的叙述,在答题纸上回答问题1至问题3。

【说明】
煤炭生产是国民经济发展的主要领域之一,其煤矿的安全非常重要。某能源企业拟开发一套煤矿建设项目安全预警系统,以保护煤矿建设项目从业人员生命安全。本系统的主要功能包括如下(a)~(h)所述。
(a) 项目信息维护
(b) 影响因素录入
(c) 关联事故录入
(d) 安全评价得分
(e) 项目指标预警分析
(f) 项目指标填报
(g) 项目指标审核
(h)项目指标确认

【问题 1】(9分)
王工根据煤矿建设项目安全预警系统的功能要求,设计完成了系统的数据流图,如图2-1所示。请使用题干中描述的功能(a)~(h),补充完善空(1)~(6)处的内容,并简要介绍数据流图在分层细化过程中遵循的数据平衡原则。

图 2-1 煤矿建设项目安全预警系统数据流图
图 2-1 煤矿建设项目安全预警系统数据流图

【问题 2】(9分)
请根据【问题1】中数据流图表示的相关信息,补充完善煤矿建设项目安全预警系统总体E-R图(见图2-2)中实体(1)~(6)的具体内容,将正确答案填在答题纸上。

图2-2 煤矿建设项目安全预警系统总体E-R图
图2-2 煤矿建设项目安全预警系统总体E-R图

【问题3】(7分)
在结构化分析和设计过程中,数据流图和数据字典是常用的技术手段,请用200字以内的文字简要说明它们在软件需求分析和设计阶段的作用。

答案与解析

【问题 1】(9分)
1到3,f,g,h
4,d
5,b
6则是e
父图和子图的输入/输出数据流必需平衡,父图的一条输入/输出流对应子图的一条输入输出流;父图的一条输入/输出流对应子图的多条,子图的多条数据流刚好对应父图这一条输入/输出流。
子图内部的输入/输出流也必须一一对应。

【问题2】(9分)
(1)管理员
(2)项目经理
(3)项目指标数据
(4)项目信息
(5)指标参数
(6)事务及其影响因素

【问题3】(7分)
数据流图在需求分析阶段主要是建立数据流图模型,完成需求分析。
在设计阶段为接口和模块的划分提供依据,在数据流图的基础上进行。
数据字典在需求分析和设计阶段主要是起到了统一的标准,可以确定数据在系统中完整性和一致性。具体要求各个列、相互参照、由描述内容检索名称、一致性校验和完整性校验。

试题三 嵌入式

阅读以下关于嵌入式系统故障检测和诊断的相关描述,在答题纸上回答 问题 1问题 3
【说明】
系统的故障检测和诊断是宇航系统提高装备可靠性的主要技术之一,随着装备信息化的发展,分布式架构下的资源配置越来越多、资源布局也越来越分散,这对系统的故障检测和诊断方法提出了新的要求。为了适应宇航装备的分布式综合化电子系统的发展,解决由于系统资源部署的分散性,造成系统状态的综合和监控困难的问题,公司领导安排张工进行研究。张工经过分析、调研提出了针对分布式综合化电子系统架构的故障检测和诊断的方案。

【问题 1】(8分)
张工提出:宇航装备的软件架构可采用四层的层次化体系结构,即模块支持层、操作系统层、分布式中间件层和功能应用层。为了有效、方便地实现分布式系统的故障检测和诊断能力,方案建议将系统的故障检测和诊断能力构建在分布式中间件内,通过使用心跳或者超时探测技术来实现故障检测器。请用 300 字以内的文字分别说明心跳检测和超时探测技术的基本原理及特点。
【问题 2】(8分)
张工针对分布式综合化电子系统的架构特征,给出了初步设计方案,指出每个节点的故障监测与诊断器主要负责监控系统中所有的故障信息,并将故障信息进行综合分析判断,使用故障诊断器分析出故障原因,给出解决方案和措施。系统可以给模块的每个处理机器核配置核状态监控器、给每个分区配置分区状态监控器、给每个模块配置模块状态监控器、给系统配置系统状态监控器,如图3-1所示。

图3-1 系统故障检测和诊断原理
图3-1 系统故障检测和诊断原理

请根据下面给出的分布式综合化电子系统可能产生的故障(a)~(h),判断这些故障分别属于哪类监控器检测的范围,完善表3-1的(1)~(8)的空白。

(a)应用程序除零
(b)看门狗故障
(c)任务超时
(d)网络诊断故障
(e)BIT检测故障
(f)分区堆栈溢出
(g)操作系统异常
(h)模块掉电

【问题 3】(9分)
张工在方案中指出,本系统的故障诊断采用故障诊断器实现,它可综合多种故障信息和系统状态,依据智能决策数据库提供的决策策略判定出故障类型和处理方法。智能决策数据库中的策略可以对故障开展定性或定量分析。通常,在定量分析中,普遍采用基于解析模型的方法和数据驱动的方法。张工在方案中提出该系统定量分析时应采用基于解析模型的方法。但是此提议受到王工的反对,王工指出采用数据驱动的方法更适合分布式综合化电子系统架构的设计。请用300字以内的文字,说明数据驱动方法的基本概念,以及王工提出采用此方法的理由。

答案与解析

【问题 1】(8分)
心跳是一种用于故障检测的手段。分布式系统中,各种异常,如:宕机、磁盘损坏、网络故障等,时有发生,通过心跳可以快速有效的定位集群中的错误结点,并做及时的处理保证集群正常服务。
通常探针会不断发送健康检查来检查服务是否健康。当远程节点没有响应时,我们只能猜测数据包在过程中的某个地方丢失了。下一个操作将是重试或等待一段时间,直到超时。

【问题 2】(8分)
(1) (2) b、e
(3) f
(4) (5) (6) a、d、h
(7)(8) g、c

【问题 3】(9分)
通过对系统运行过程中的监测数据进行分析,从而在无精准系统数学模型情况下,对系统进行故障诊断,具体方法包括机器学习、统计分析法和信号分析法
因为宇航系统是一个非常复杂的系统,如果采用张工的基于解析模型的方法,这一类方法需要建立再精准数学模型的基础上来进行故障诊断。但是对于宇航系统这种非常复杂的系统难以精确建模。所以王工提出了数据驱动的方法,不需要精准系统数学模型。

试题四 数据库缓存

阅读以下关于数据库缓存的叙述,在答题纸上回答问题1至问题3。
【说明】
某大型电商平台建立了一个在线 B2B 商店系统,并在全国多地建设了货物仓储中心,通过提前备货的方式来提高货物的运送效率。但是在运营过程中,发现会出现很多跨仓储中心调货从而延误货物运送的情况。为此,该企业计划新建立一个全国仓储货物管理系统,在实现仓储中心常规管理功能之外,通过对在线 B2B 商店系统中订单信息进行及时的分析和挖掘,并通过大数据分析预测各地仓储中心中各类货物的配置数量,从而提高运送效率,降低成本。
当用户通过在线 B2B 商店系统选购货物时,全国仓储货物管理系统会通过该用户所在地址、商品类别以及仓储中心的货物信息和地址,实时为用户订单反馈货物起运地(某仓储中心)并预测送达时间。反馈送达时间的响应时间应小于 1 秒。
为满足反馈送达时间功能的性能要求,设计团队建议在全国仓储货物管理系统中采用数据缓存集群的方式,将仓储中心基本信息、商品类别以及库存数量放置在内存的缓存中,而仓储中心的其它商品信息则存储在数据库系统。

【问题 1】(9分)
设计团队在讨论缓存和数据库的数据一致性问题时,李工建议采取数据实时同步更新方案,而张工则建议采用数据异步准实时更新方案。
请用 200 字以内的文字,简要介绍两种方案的基本思路,说明全国仓储货物管理系统应该采用哪种方案,并说明采取该方案的原因。
【问题 2】(9分)
随着业务的发展,仓储中心以及商品的数量日益增加,需要对集群部署多个缓存节点,提高缓存的处理能力。李工建议采用缓存分片方法,把缓存的数据拆分到多个节点分别存储,减轻单个缓存节点的访问压力,达到分流效果。
缓存分片方法常用的有哈希算法和一致性哈希算法,李工建议采用一致性哈希算法来进行分片。请用 200 字以内的文字简要说明两种算法的基本原理,并说明李工采用一致性哈希算法的原因。
【问题 3】(7分)
全国仓储货物管理系统开发完成,在运营一段时间后,系统维护人员发现大量黑客故意发起非法的商品送达时间查询请求,造成了缓存击穿。张工建议尽快采用布隆过滤器方法解决。请用 200 字以内的文字解释布隆过滤器的工作原理和优缺点。 

答案与解析

【问题 1】(9分)
实时方案:强一致性,更新数据库之后主动淘汰缓存,读请求更新缓存,为避免缓存雪崩,更新缓存的过程需要进行同步控制,同一时间只允许一个请求访问数据库。
异步准实时更新方案:准一致性,当数据库数据更新时,异步更新缓存数据,采用多线程技术或MQ(消息队列)逐步完成数据的更新。
应该采用异步准实时更新方案,因为题目中对性能有严格要求,要求在 1 秒内完成,而且多数请求是读操作,写操作少。实时同步方案最大的问题在于同步并发时的性能不可控。

【问题 2】(9分)
哈希分片:对缓存的 Key 做哈希计算,然后对总的缓存节点个数取余,得出的结果就是要存入缓存节点的序号。这种算法的优点就是简单易,缺点是集群中增加或者减少缓存节点时,缓存总的节点个数变化造成计算出来的节点发生变化,从而造成缓存失效不可用。
一致性哈希分片:将存储节点和数据都映射到一个0~232首尾相连的虚拟哈希环上,存储节点可以根据IP 地址进行哈希,数据通常通过顺时针方向寻找的方式,来确定自己所属的存储节点。这种算法的优点是缓存集群增加和删除节点时,只有少量的 Key 会漂移到其它节点上,而大部分的 Key 命中的节点还是会保持不变,从而可以保证命中率不会大幅下降。缺点是缓存节点在圆环上分布不平均,会造成部分缓存节点的压力较大。
采用一致性哈希算法的原因:一致性哈希分片的方式在扩充缓存结点时,只需要对少量数据的存储位置进行更新,而哈希分片需要对几乎所有数据的存储位置进行更新。

【问题 3】(7分)
布隆过滤器通过一个很长的二进制向量和一系列随机映射函数来记录与识别某个数据是否在一个集合中。如果数据不在集合中,能被识别出来,不需要到数据库中进行查找,所以能将数据库查询返回值为空的查询过滤掉。
优点:占用内存小,查询效率高,不需要存储元素本身,在某些对保密要求比较严格的场合有很大优势。
缺点:有一定的误判率,不能100%准确判断元素是否在集合中,不能获取元素本身,一般情况下不能从布隆过滤器中删除元素。

试题五 WEB系统架构

阅读以下关于 Web 系统架构设计的叙述,在答题纸上回答 问题 1问题 3
【说明】
某公司拟开发一套基于边缘计算的智能门禁系统,用于如园区、新零售、工业现场等存在来访、被访业务的场景。来访者在来访前,可以通过线上提前预约的方式将自己的个人信息记录在后台,被访者在系统中通过此请求后,来访者在到访时可以直接通过“刷脸”的方式通过门禁,无需做其他验证。此外,系统的管理员可对正在运行的门禁设备进行管理。
基于项目需求,该公司组建项目组,召开了项目讨论会。会上,张工根据业务需求并结合边缘计算的思想,提出本系统可由访客注册模块、模型训练模块、端侧识别模块与设备调度平台模块等四项功能组成。李工从技术层面提出该系统可使用 Flask 框架与 SSM 框架为基础来开发后台服务器,将开发好的系统通过 Docker 进行部署,并使用 MQTT 协议对 Docker 进行管理。

【问题 1】(5分)
MQTT 协议在工业物联网中得到广泛的应用,请用 300 字以内的文字简要说明 MQTT 协议。
【问题 2】(14分)
在会议上,张工对功能模块进行了更进一步的说明:访客注册模块用于来访者提交申请与被访者确认申请,主要处理提交来访申请、来访申请审核业务,同时保存访客数据,为训练模块准备训练数据集;模型训练模块用于使用访客数据进行模型训练,为端侧设备的识别业务提供模型基础;端侧识别模块在边缘门禁设备上运行,使用训练好的模型来识别来访人员,与云端服务协作完成访客来访的完整业务;设备调度平台模块用于对边缘门禁设备进行管理,管理人员能够使用平台对边缘设备进行调度管理与状态监控,实现云端协同。
图5-1给出了基于边缘计算的智能门禁系统架构图,请结合 HTTP 协议和 MQTT 协议的特点,为 图 5-1 中(1)~(6)处选择合适的协议;并结合张工关于功能模块的描述,补充完善 图 5-1 中(7)~(10)处的空白。

图 5-1 基于边缘计算的智能门禁系统
图 5-1 基于边缘计算的智能门禁系统

【问题 3】(6分)
请用 300 字以内的文字,从数据通信、数据安全和系统性能等方面简要分析在传统云计算模型中引入边缘计算模型的优势。

答案与解析

【问题 1】(5分)
MQTT (消息队列遥测传输)是一个基于客户端-服务器的消息发布/订阅传输协议。它工作在 TCP/IP 协议族上,是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的发布/订阅型消息协议。MQTT 协议是轻量、简单、开放和易于实现的。

【问题 2】 (14分)
⑴HTTP ⑵MQTT (3)MQTT (4)MQTT ⑸HTTP ⑹HTTP (7)端侧识别 (8)模型训练 (9)设备调度平台 (10)访客注册

【问题 3】(6分)
数据通信:通信数据量更少速度更快。因为数据处理比对在边缘设备上完成,无需回传服务器,通信效率更高。
数据安全:数据以加密方式存储在需要用到的边缘设备上,本地化处理比对,减少原始信息在网上的传递带来的安全隐患。黑客无法通过攻击一台设备来影响整个系统。
系统性能:性能更高,以人脸识别为例,在进行识别时,只在本地进行比对不用把人脸数据传递到远程服务器对比。

参考链接


软考系列(系统架构师)- 2020年系统架构师软考案例分析考点

试题一 软件架构(架构风格、质量属性)

阅读以下关于软件架构设计与评估的叙述,回答 问题  1问题  2
【说明】
某公司拟开发一套在线软件开发系统,支持用户通过浏览器在线进行软件开发活动。该系统的重要功能包括代码编辑、语法高亮显示、代码编译、系统调试、代码仓库管理等,在需求分析与架构设计阶段,公司提出的需求和质量属性描述如下:

a)根据用户的付费情况对用户进行分类,并根据类别提供相应的开发功能;
b)在正常负载情况下,系统应该在 0.2s 内对用户的界面操作请求进行响应;
c)系统应该具备完善的安全防护措措施,能够对黑客的攻击行为进行检测和防御;
d)系统主站点断电后应在 3s 内将请求重定向到备用站点;
e)系统支持中文昵称,但用户名必须以字母开头,长度不少于 8 个字符;
f)系统宕机后,需要在 15s 内发现错误,并启用备用系统;
g)在正常负载情况下,户的代码提交请求应在 0.5s 内完成;
h)系统支持硬件设备灵活扩容,应保证在 2人・天内完成;
i)系统需要针对代码仓库的所有操作进行详细记录,便于后期查阅与审计;
j)更改系统 web 界面风格需要在  4人・天内完成;
k)系统本身需要提供远程调试接口,支持开发团队进行远程排错;

在对系统需求质量属性和架构特性进行分析的基础上,该公司的系统架构师给出了两种方案,分别是管道-过滤器和仓库风格。

【问题 1】(13分)
请问该需求应该采用哪一种风格。表  1-1 是对这两种风格分别从数据处理方式、系统拓展方式和处理性能三个方面进行了比较,请填写 表  1-1 中(1)~(4)处的空白。

【问题 2】(12分)
1、请分析题干中的需求描述,填写 图  1-2 中  (1)~(6) 处的空白。

答案与解析
  • 试题难度:一般
  • 知识点:案例分析>软件架构风格与架构设计
  • 试题答案:

    【问题 1】(13分)
    1.该系统更适合采用仓库架构风格。(5分)
    2.表(1)-(4)空的空白分别为:(8分)
    (1)数据存储在中心仓库,处理流程独立,支持交互式处理。
    (2)数据与处理紧密关联,调整处理流程需要系统重新启动。
    (3)数据与处理分离,需要加载数据,性能降低。
    (4)数据处理组件之间一般无依赖关系,可并发调用,提高性能。
    【问题 2】(12分)
    (1)安全性
    (2)可修改性
    (3)g
    (4)i
    (5)f
    (6)j

试题解析:

本题考查的是架构设计过程中涉及到的一些质量属性,以及架构风格的对比。
【问题 1】(13分)
在管道/过滤器风格的软件体系结构中,每个构件都有一组输入和输出,数据输入构件,经过内部处理,然后产生数据输出。因此,这里的构件被称为过滤器,这种风格的连接件就像是数据流传输的管道,将一个过滤器的输出传到另一过滤器的输入。
在仓库(repository)风格中,有两种不同的构件:中央数据结构说明当前状态,独立构件在中央数据存储上执行。一方面,若构件控制共享数据,则仓库是一传统型数据库;另一方面,若中央数据结构的当前状态触发进程执行的选择,则仓库是一黑板系统。
通过交互方式、数据结构、控制结构和扩展方法分别对仓库风格和管道过滤器风格进行对比,如下所示:
交互方式:管理过滤器很明显是顺序结构或循环结构,数据在管理中进行传递。而仓库结构是数据在中心位置,所有的处理均是中心结点与周边结点之间的交互,从形态来看,是星型的。
数据结构:从数据结构来看,仓库风格会使用一个文件将数据保存起来,所有的操作围绕这个文件进行。而管道过滤器则是在过滤器之间传递数据流。
控制结构:从控制结构来说仓库风格是业务功能驱动,而管道过滤器是由数据流驱动的。
扩展方法:从扩展方法来讲,管道过滤器是通过过滤器提供标准接口与其它过滤器对接,而数据仓库风格,要共享数据,扩展功能,只要功能的操作与数据模型本身是匹配的就行了,就像我们要共享一个数据库做系统集成,此时共享同一数据库的多个应用系统所用的数据模型一定会是一致的,否则无法去共享。
【问题 2】(12分)
本题主要考查考生对于软件质量属性的理解、掌握和应用。
本题考查的是架构设计过程中涉及到的一些质量属性,以及架构风格的对比。常用的质量属性包括:
1、性能
性能(performance)是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数。
2、可靠性
可靠性(reliability)是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
3、可用性
可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4、安全性
安全性(security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
5、可修改性
可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过考察这些变更的代价衡量可修改性。
6、易用性
软件开发工具应有十分友好的用户界面,用户乐于使用;工具应能剪裁和定制,以适应特定用户的需要;工具应能提示用户的交互操作,提供简单有效的执行方式;工具还应能检查用户的操作错误,尽可能自动改正错误。
识别软件架构质量属性是进行架构设计的重要步骤。根据对相关质量属性的定义和含义,其中:“c)系统应该具备完善的安全防护措措施,能够对黑客的攻击行为进行检测和防御”、“i)系统需要针对代码仓库的所有操作进行详细记录;便于后期查阅与审计”属于安全性;“h)系统支持硬件设备灵活扩容,应保证在2人天内完成”、“j)更改系统web界面风格需要在4人天内完成”这描述的是系统的可修改性;“g)在正常负载情况下,户的代码提交请求应在0.5s内完成”描述的是性能属性。

试题二 数据库(规范化)

阅读下列说明,回答 问题 1问题 3 ,将解答填入对应栏内。
【说明】
某企业委托软件公司开发一套包裹信息管理系统,以便于对该企业通过快递收发的包裹信息进行统一管理,在系统设计阶段,需要对不同快递信息的包裹单信息进行建模,其中,邮政包裹单如 图  2-1 所示:

图2-1 包裹详情单
图 2-1 包裹详情单

【问题  1】(13分)
请说明关系型数据库开发中,逻辑数据模型设计过程包含哪些任务?根据 图  2-1 包裹详情单应该设计出哪些关系模式的名称,并指出每个关系模式的主键属性。
【问题  2】(6分)
请说明什么是超类实体?结合图中包裹单信息,试设计一种超类实体,给出完整的属性列表。
【问题  3】(6分)
请说明什么是派生属性?结合图中包裹单信息说明哪个属性是派生属性。

答案与解析

  • 试题难度:一般
  • 知识点:
  • 试题答案:

    【问题 1】(13分)
    逻辑结构设计包含的任务主要有:
    (1)把概念结构设计阶段设计好的基本E-R图转换为关系数据库的关系模式;(2)对关系模式进行优化;(3)设计用户视图。
    设计的关系模式主要有:
    收件人信息。主键:证件号
    寄件人信息。主键:用户代码
    包裹单信息。主键:包裹单编号
    快递员信息。主键:员工编号
    邮局站点信息。主键:邮局编号
    【问题 2】(6分)
    将一些子实体所共有的属性抽象为一个单独的新实体,这个新的实体就是超类实体。
    比如根据这个包裹单信息可以设计一个 “人员信息”的超类:人员信息(姓名,电话,单位名称,详细地址,邮政编码)。
    【问题 3】(6分)
    可以从其它属性得来的属性就叫派生属性。包裹图中的“总计”属性是派生属性。

  • 试题解析:

    【问题 1】(13分)
    数据库设计分为概念结构设计、逻辑结构设计、物理结构设计:
    概念设计也称为概念结构设计,其任务是在需求分析阶段产生的需求说明书的基础上,按照特定的方法将它们抽象为一个不依赖于任何DBMS的数据模型,即概念模型。概念模型的表现形式即ER模型。
    逻辑设计也称为逻辑结构设计,其主要任务是将概念设计阶段设计好的E-R图转换为与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构(如:关系模式)。
    物理设计也称为物理结构设计,其任务是对给定的逻辑模型选取一个最适合应用环境的物理结构,所谓数据库的物理结构,主要是指数据库在物理设备上的存储结构和存取方法。
    【问题 2】(6分)
    当较低层次上实体类型表达了与之联系的较高层次上的实体类型的特殊情况时,就称较高层次上实体类型为超类型,反之为子类型。子类到超类的过程为概化,超类到子类的过程为特化。
    ①子类与超类之间具有继承特点,即子类包含了超类的所有属性,并且可以比超类拥有更多的属性。
    ②这种继承性是通过子类实体和超类实体有相同的实体标识符实现的。
    【问题 3】(6分)
    可以从其它属性得来的属性就叫派生属性。包裹图中的“总计”属性是派生属性。可以从资费、挂号费、保价费、回执费累加计算出来。

试题三 嵌入式

阅读以下关于开放式嵌入式软件架构设计的相关描述,回答 问题 1问题 3
【说明】
某公司一直从事宇航系统研制任务,随着宇航产品综合化、网络化技术发展的需要,公司的业务量急剧增加,研制新的软件架构已迫在眉睫。公司架构师王工广泛调研了多种现代架构的基础,建议采用基于FACE (Future Airborne Capability Environment)的字航系统开放式软件架构,以实现字航系统的跨平台复用,实现字航软件高质量、低成本的开发。公司领导肯定了王工的提案,并指出公司要全面实施基于FACE的开放式软件架构,应注意每个具体项目在实施中如何有效实现从需求到架构设计的关系,掌握基于软件需求的软件架构设计方法,并做好开放式软件架构中各段间的接口标准化设计工作。
【问题  1】(9分)
王工指出,软件开发中需求分析是根本,架构设计是核心,不考虑软件需求便进行软件架构设计很可能导致架构设计的失败,因此,如何把软件需求映射到软件架构至关重要。请从描述语言、非功能性需求描述、需求和架构的一致性等三个方面, 用300字以内的文字说明软件需求到架构的映射存在哪些难点。
【问题 2】(10分)
图3-1是王工给出的FACE架构布局,包括操作系统、I/O 服务、平台服务、传输服务和可移植组件等5个段;操作系统、I0和传输等3个标准接口。请分析图3-1给出的FACE架构的相关信息,用300字以内的文字简要说明FACE 5个段的含义。

【问题  3】(6分)
FACE架构的核心能力是可支持应用程序的跨平台执行和可移植性,要达到可移植能力,必须解决应用程序的紧耦合和封装的障碍。请用200字以内的文字简要说明在可移植性上,应用程序的紧耦合和封装问题的主要表现分别是什么,并给出解决方案。

答案与解析

  • 试题难度:一般
  • 知识点:案例分析>嵌入式系统设计
  • 试题答案:

    【问题 1】(9分)
    (1)需求和架构描述语言存在差异:软件需求是频繁获取的非正规的自然语言,而软件架构常用的是一种正式语言。
    (2)非功能属性难于在架构中描述:系统属性中描述的非功能性需求通常很难在架构模型中形成规约。
    (3)需求和架构的一致性难以保障:从软件需求映射到软件架构的过程中,保持一致性和可追溯性很难,且复杂程度很高,因为单- -的软件需求可能定位到多个软件架构的关注点。反之,架构元素也可能有多个软件需求。
    【问题 2】(10分)
    操作系统服务段:为FACE架构其他段提供操作系统、运行时和操作系统级健康监控等服务。通过开放式OSGi框架为上层功能提供OS标准接口,并可实现上层组件的即插即用能力。
    I/O服务段:主要针对专用IO设备进行抽象,屏蔽平台服务段软件与硬件设备的关系。由于图形服务软件和GPU处理器紧密相关,因此I/0服务段不对GPU驱动进行抽象。
    平台服务段:主要是指用户需要的共性软件,如:系统级健康监控(HM).配置、日志和流媒体等服务。本段可包括平台公共服务、平台设备服务和平台图像服务等三类。
    传输服务段:主要为上层可移植组件段提供平台性的数据交换服务。可移植组件将通过传输服务段提供的服务实现交换,禁止组件间直接调用。
    可移植组件段: 提供了多组件使用能力和功能服务。主要包括公共服务和可移植组件两类。
    【问题 3】(6分)
    紧耦合问题主要表现在:I/O问题、业务逻辑问题和表现问题。
    解决方案:可采用分离原则,通过隔离实现硬件特定信息和少数模块的代码,减少耦合性。
    封装问题主要表现在: ICD硬编码问题、组件的紧耦合问题、直接调用问题。
    解决方案:可以通过提供数据源或槽的软件服务的方法,将紧耦合组件分解出应用程序,并将平台相关部分加入计算环境中,在计算平台内提供数据源或槽的软件服务,并实现接口标准化。

  • 试题解析:【问题 1】
    软件需求是指为用户解决某一问题或达到某一目标所需的软件功能;系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。
    软件需求包括三个不同的层次:业务需求、用户需求和功能需求;软件需求规格说明还应包括非功能需求,它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性。
    架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。
    通常在软件开发过程中,需求会随着开发深入而有所变化,而架构又不能完全地将需求全部反映出来,因此,如何把软件需求映射到软件架构是至关重要一个问题。
    (1)从描述语言方面来讲:软件需求是频繁获取的非正规的自然语言,而软件架构常用的是一种正式语言。
    (2)从非功能性需求描述方面来讲:系统属性中描述的非功能性需求通常很难在架构模型中形成规约。
    (3)从需求和架构的一致性方面来讲:从软件需求映射到软件架构的过程中,保持一致性和可追溯性很难,且复杂程度很高,因为单一的软件需求可能定位到多个软件架构的关注点。反之,架构元素也可能有多个软件需求。

    【问题 2】
    FACE软件架构是建立在操作系统上的一个三维架构,该架构由操作系统、I/O服务、平台服务(PSS)、传输服务(TSS)、可移植组件五部分组成。该软件架构能够更好的将关注点分离,软件功能能够重用,旨在实现FACE的目标——降低研发和集成的成本。
    (1)操作系统服务段:为FACE架构其他段提供操作系统、运行时和操作系统级健康监控等服务。通过开放式OSGi框架为上层功能提供OS标准接口,并可实现上层组件的即插即用能力。本段是FACE架构的基本服务段。
    (2)I/O服务段:主要针对专用I/O设备进行抽象,屏蔽平台服务段软件与硬件设备的关系,形成一种虚拟设备,这里隐含着对系统中的所有硬件I/O的虚拟化。由于图形服务软件和GPU处理器紧密相关,因此I/O服务段不对GPU驱动进行抽象。
    (3)平台服务段:主要是指平台/用户需要的共性服务软件,主要涵盖跨平台的系统管理、共享设备服务,以及健康管理等。如:系统级健康监控(HM)、配置、日志和流媒体等服务。本段主要包括平台公共服务、平台设备服务和平台图像服务等三类。
    (4)传输服务段:通过使用传统跨平台中间件软件(如CORBA、DDA等),为平台上层可移植组件段提供平台性的数据交换服务,可移植组件将通过传输服务段提供的服务实现交换,禁止组件间直接调用。本段应具备QoS质量特征服务、配置能力服务以及分布式传输服务等。
    (5)可移植组件段:为用户软件段,提供了多组件使用能力和功能服务。主要包括公共服务和可移植组件两类。

    【问题 3】
    可移植性是软件质量之一,良好的可移植性可以提高软件的生命周期。可移植性是指软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。
    紧耦合就是模块或者系统之间关系太紧密,存在相互调用。紧耦合系统的缺点在于更新一个模块的结果导致其它模块的结果变化,难以重用特定的关联模块。
    封装,即隐藏对象的属性和实现细节,仅对外公开接口,控制在程序中属性的读和修改的访问级别。
    紧耦合问题主要表现在:I/O问题、业务逻辑问题和表现问题。
    解决方案:可采用分离原则,通过隔离实现硬件特定信息和少数模块的代码,减少耦合性。
    封装问题主要表现在: ICD硬编码问题、组件的紧耦合问题、直接调用问题。
    解决方案:可以通过提供数据源或槽的软件服务的方法,将紧耦合组件分解出应用程序,并将平台相关部分加入计算环境中,在计算平台内提供数据源或槽的软件服务,并实现接口标准化。

试题四 数据缓存(Redis)

阅读以下关于数据库缓存的叙述,回答 问题 1问题 3
【说明】
某互联网文化发展公司因业务发展,需要建立网上社区平台,为用户提供一个对网络文化产品(如互联网小说、电影、漫画等)进行评论、交流的平台。该平台的部分功能如下:
(a)用户帖子的评论计数器;
(b)支持粉丝列表功能;
(c)支持标签管理;
(d)支持共同好友功能等;
(e)提供排名功能,如当天最热前 10 名帖子排名、热搜榜前 5 排名等;
(f)用户信息的结构化存储;
(g)提供好友信息的发布/订阅功能。
该系统在性能上需要考虑高性能、高并发,以支持大量用户的同时访问。开发团队经过综合考虑,在数据管理上决定采用 Redis +数据库(缓存+数据库)的解决方案。

【问题  1】(10分)
Redis支持丰富的数据类型,并能够提供一些常见功能需求的解决方案。请选择题干描述的  (a) ~ (g)  功能选项,填入 表  4-1 中 (1) ~ (5) 的空白处。

表 4-1 Redis 数据类型与业务功能对照表

【问题  2】(7分)
该网上社区平台需要为用户提供  7×24 小时的不间断服务。同时在系统出现宕机等故障时,能在最短时间内通过重启等方式重新建立服务。为此,开发团队选择了  Redis 持久化支持。Redis 有两种持久化方式,分别是  RDB(Redis DataBase) 持久化方式和  AOF (Append OnlyFile)  持久化方式。开发团队最终选择了  RDB 方式。请用  200 字以内的文字,从磁盘更新频率、数据安全、数据一致性、 重启性能和数据文件大小五个方面比较两种方式,并简要说明开发团队选择  RDB 的原因。
【问题  3】(8分)
缓存中存储当前的热点数据,Redis 为每个 KEY 值都设置了过期时间,以提高缓存命中率。为了清除非热点数据,Redis 选择 “定期删除+惰性删除” 策略。如果该策略失效,Redis 内存使用率会越来越高,一般应采用内存淘汰机制来解决。请用  100 字以内的文字简要描述该策略的失效场景,并给出三种内存淘汰机制。

答案与解析

  • 试题难度:一般
  • 知识点:
  • 试题答案:

    【问题 1】(10分)
    (1)a
    (2)b,g
    (3)c,d
    (4)f
    (5)e
    【问题 2】(7分)
    (1)磁盘更新频率:AOF 比 RDB 文件更新频率高;
    (2)数据安全:AOF 比 RDB 更安全;
    (3)数据一致性:RDB 间隔一段时间存储,可能发生数据丢失和不一致;AOF 通过 append 模式写文件,即使发生服务器宕机,也可通过 redis-check-aop 工具解决数据一致性问题;
    (4)重启性能:RDB 性能比 AOF 好;
    (5)数据文件大小:AOF 文件比 RDB 文件大。
    综合上述五个方面的比较。考虑在系统出现宕机等故障时,需要在最短时间内通过重启等方式重新建立服务,因此开发团队最终选择了 RDB 方式。
    【问题 3】(8分)
    由于 Redis 定期删除是随机抽取检查,不可能扫描清除掉所有过期的 key 并删除,然后一些 key 由于未被请求,惰性删除也未触发。这样 Redis 的内存占用会越来越高。此时就需要内存淘汰机制。
    常用的内存淘汰机制是六种(volatile-lru、volatile-ttl、volatile-random、allkeys-lru、allkeys-random、no-enviction)。注:任选其中三种都可得分。

  • 试题解析:

    【问题 1】(10分)

    【问题 2】(7分)
    本问题考察 Redis 持久化存储的基本概念及应用。
    Redis 提供了两种持久化存储的机制,分别是 RDB(Redis DataBase)持久化方式和 AOF(Append Only File)持久化方式。RDB 持久化方式是指在指定的时间间隔内将内存中的数据集快照写入磁盘,是 Redis 默认的持久化方式。AOF 方式是指 Redis 会将每一个收到的写命令都通过 write 函数追加到日志文件中。

    【问题 3】(8分)
    过期策略:即 Redis 针对过期的key使用的清除策略,策略为:定期删除+惰性删除。
    1、定期删除:
    Redis 会将每个设置了过期时间的 key 放入到一个独立的字典中,以后会定期遍历这个字典来删除到期的 key。Redis默认是每隔 100ms 就随机抽取一些设置了过期时间的 key,检查其是否过期,如果过期就删除。注意这里是随机抽取的。为什么要随机呢?你想一想假如 Redis 存了几十万个 key ,每隔100ms就遍历所有的设置过期时间的 key 的话,就会给 CPU 带来很大的负载。
    2、惰性删除:
    所谓惰性策略就是在客户端访问这个 key 的时候,Redis 对 key 的过期时间进行检查,如果过期了就立即删除,不会给你返回任何东西。
    定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key,靠定期删除没有被删除掉,还停留在内存里,除非你的系统去查一下那个 key,才会被 Redis 给删除掉。这就是所谓的惰性删除,即当你主动去查过期的key时,如果发现key过期了,就立即进行删除,不返回任何东西.
    由于 Redis 定期删除是随机抽取检查,不可能扫描清除掉所有过期的key并删除,然后一些key由于未被请求,惰性删除也未触发。这样 Redis 的内存占用会越来越高。此时就需要内存淘汰机制。
    主要有如下一些策略:
    1、volatile-lru:从设置过期时间的数据集中挑选出最近最少使用的数据淘汰。没有设置过期时间的key不会被淘汰,这样就可以在增加内存空间的同时保证需要持久化的数据不会丢失。
    2、volatile-ttl:除了淘汰机制采用LRU,策略基本上与volatile-lru相似,从设置过期时间的数据集中挑选将要过期的数据淘汰,ttl值越大越优先被淘汰。
    3、volatile-random:从已设置过期时间的数据集中任意选择数据淘汰。当内存达到限制无法写入非过期时间的数据集时,可以通过该淘汰策略在主键空间中随机移除某个key。
    4、allkeys-lru:从数据集中挑选最近最少使用的数据淘汰,该策略要淘汰的key面向的是全体key集合,而非过期的key集合。
    5、allkeys-random:从数据集中选择任意数据淘汰。
    6、no-enviction:禁止驱逐数据,也就是当内存不足以容纳新入数据时,新写入操作就会报错,请求可以继续进行,线上任务也不能持续进行,采用no-enviction策略可以保证数据不被丢失,这也是系统默认的一种淘汰策略。

试题五 Web应用(质量属性)

阅读以下关于 Web 系统架构设计的叙述, 在答题纸上回答 问题 1问题 3
【说明】
开发基于 Web 的基业设备检测系统,以实现对多种工业数据的分类采集,运行状态检测以及相关信息的管理该系统应具备以下功能:

现场设备状态采集功能,根据数据类型对设备检测指标状态信号进行分类采集,设备采集数据传输功能;
9-11个月可靠的传输技术,实现将设备数据从制造现场传输到系统后台设备检测显示功能;
对设备的运行状态工作以及报警状态进行检测并提供相应的图形化界面设备信息管理功能;
支持设备运行历史状态,报警记录参数信息的查询。

同时,该系统还需满足以下非功能性需求:

(a)系统应支持大于  100 个工业设备的运行检测;
(b)设备数据以制造现场传输到系统后台传输时间小于 1s;
(c)系统应在 7*24 小时工作;
(d)可抵御 XSS 攻击;
(e)系统在故障情况下,应在 0.5 小时内恢复;
(f)支持数据审计。

面对系统需求,公司召开项目讨论会议,制定系统设计方案,最终决定使用三层拓补结构,即现场设备数据采集层、Web检测服务层和前端Web显示层。

【问题  1】(6分)
请按照性能、安全性和可用性三种非功能需求分类将题干的(a)~(f)填入 (1)~(3)  空白处。非功能性需求归类表:

【问题  2】(14分)

该系统 Web 检测服务层拟采用 SSM 框架进行系统研发,SSM 工作流程图如下 图 5-1 所示,请从下面给出的 (a) ~ (k) 中进行选择,补充完善 图 5-1 中 (1) ~(7) 处空白的内容:

(a) Connection pool
(b) Struts2
(c) Persistent Layer
(d) Mybatis
(e) HTTP
(f) MVC
(g) Kafka
(h) View Layer
(i)  Jsp
(j)  Conrtoller Layer
(k) Spring

【问题  3】(5分)
该工业设备检测系统拟采用工业控制领域中统一的数据访问机制,实现与各种不同设备的数据交互,请用 100 以内的文字说明采用标准的数据访问机制的原因。

答案与解析

  • 试题难度:一般
  • 知识点:
  • 试题答案:

    【问题 1】(6分)
    (1)a、b
    (2)d、f
    (3)c、e
    【问题2】(14分)
    (1)a
    (2)c
    (3)d
    (4)k
    (5)j
    (6)h
    (7)i
    【问题 3】(5分)
    通过采用标准的数据访问机制,可以屏蔽不同设备之间数据交互的差异,解决了系统使用数据不一致性,又在一定程度上减低了数据结构与应用系统的耦合度,减少了应用系统的维护的工作量。

  • 试题解析:

    【问题 1】(6分)
    本题考查的是架构设计过程中涉及到的一些质量属性。常用的质量属性包括:
    1、性能
    性能(performance)是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数。
    2、可靠性
    可靠性(reliability)是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
    3、可用性
    可用性(availability)是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
    4、安全性
    安全性(security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
    5、可修改性
    可修改性(modifiability)是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过考察这些变更的代价衡量可修改性。
    6、易用性
    软件开发工具应有十分友好的用户界面,用户乐于使用;工具应能剪裁和定制,以适应特定用户的需要;工具应能提示用户的交互操作,提供简单有效的执行方式;工具还应能检查用户的操作错误,尽可能自动改正错误。
    【问题 2】(14分)
    Spring 是一个轻量级的企业级应用开发框架,于2004年由 Rod Johnson 发布了1.0 版本,经过多年的更新迭代,已经逐渐成为 Java 开源世界的第一框架,Spring 框架号称 Java EE 应用的一站式解决方案,与各个优秀的 MVC 框架如 SpringMVC、Struts2、JSF 等可以无缝整合,与各个 ORM 框架如 Hibernate、MyBatis、JPA 等也可以无缝衔接,其他各种技术也因为 Spring 的存在而被很容易地整合进项目开发之中,如 Redis 整合、Log4J 整合等等
    SpringMVC 是 Spring 框架体系中的全功能 MVC 模块。SpringMVC 是基于 Java 语言实现 MVC 设计模式的请求驱动类型的轻量级 Web 框架,目的是将 Web 开发模块化及代码简化。其提供了 DispatcherServlet 前端控制器分派请求,同时提供灵活的配置处理程序映射、视图解析,并支持文件上传,目前已经是众多 MVC 框架中的佼佼者。
    MyBatis 的前身是 Apache 社区的一个开源项目 iBatis,于2010年更名为 MyBatis。MyBatis 是支持定制化 SQL、存储过程以及高级映射的优秀的持久层框架,避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集,使得开发人员更加关注 SQL 本身和业务逻辑,不用再去花费时间关注整个复杂的 JDBC 操作过程。
    Spring+spring mvc+mybatis整合的框架组件图如下所示:

参考链接


米家石墨烯智能电暖器电源开关维修

天气渐凉,翻出以前购买的小米 “米家石墨烯智能电暖器”,如下图:

通电测试功能,结果发现开关只能处于导通状态,无法关闭。关机需要直接拔掉插头,安全性没有保障。以前曾经闻到过烧糊的气味,但是功能正常,于是就没有太在意。

今天拆开发现开关的 1号管脚 烧糊了,如下图:

开关烧糊的另一面,如下图:

出问题的原因是 1号管脚 的接头没有卡紧,导致虚接发热,开关过热损坏,绝缘热缩管也都烤糊了,部分导线需要更换。

这部分的问题还是蛮严重的,可能诱发着火问题。小米的品控持续堪忧。

解决方法比较简单,更换一个新的开关模块,并且需要清理烧糊的插头,重新压线。不要复用原来的插头,原来的插头已经受热氧化,即使勉强能用也会由于电阻升高,依旧诱发接头过热。

开关的原始安装位置,开关的灯是向上的,后面安装的时候参考下图即可:

淘宝搜索 “HS9 智米小米取暖器二挡电源开关艾美特电暖器开关大电流船型开关”/ “智米小米1S取暖器开关”/“HUACONN 3脚2挡”,可以找到替代开关。参考商家链接 东莞蓝浩电子

至于已经烧的发黑的连接线,可以在淘宝搜索  “6.3 双头 高温编织线” ,线号选择 1.5平编织线,购买合适颜色的,我这边是白色的,原来的线接头是旗形的,其实内部安装空间足够,非旗型也是可以的。 参考商家链接 东莞市悦泰电子

其他符合如下尺寸的开关也可以进行替换安装:

注意,拆螺丝的时候,有一颗三角形的特殊螺丝,可以使用 2.3MM 的螺丝刀/批头拆卸。恰好家里以前买过一套 “米家精修螺丝刀套装” ,里面的三角批头刚刚合适。

套装如下图: 

没有这个套装的话,可以淘宝搜索 “2.3mm三角螺丝刀”,购买一把即可。

RAV4 2016款 前拖车环(牵引环)锐博软胶前杠配件

最近发现家里的 2016 RAV4 在当时买车时候安装的 WINBO锐搏软胶前杠,驾驶侧的螺栓没有安装,只安装了副驾驶一侧的。副驾驶一侧的前保险杠支架断掉了。

前保险杠如下:

上述的保险杠使用原车的拖车孔位置安装固定螺丝。

首次安装螺丝的时候,可能会由于螺孔脏污,生锈等原因,导致螺丝非常难以拧紧,一般建议先喷一些润滑油,比如 WD40 之类的。再使用原车拖车环拧进去,疏通一下油污,然后拧下拖车环后安装固定螺丝。

断掉的前保险杠支架可以单独在淘宝购买,搜索 “荣放16RAV4前杠支架”,可找到如下图所示的支架:

至于前保险杠支架的安装螺丝,可找使用到如下图所示的直径 24MM 内六角 螺距 2MM 全螺纹 50MM长螺丝替代,如下图:

这颗螺丝使用 19MM 的内六角扳手进行安装。

VNC Viewer记住密码功能失效的解决办法

使用 VNC Viewer 的时候可能会遇到记住密码功能失效的问题,每次登录都需要重新输入密码,该怎么解决呢?

这个问题发生的原因是由于系统升级/新旧电脑数据迁移之后,  VNC Viewer 存储在本地的密码密钥丢失。没办法在进行加解密,而以前残存的损坏的密码文件,又恰好阻挡了新密码的写入。

这个问题在 macOS 系统上更加严重,密钥是不允许跨设备传输的,导致迁移的时候,加密文件能迁移成功,但是数据解密不出来。

最简单的办法就是直接删除之前的密码存储文件,对于 macOS 来说,可以执行:

对于 Windows 来说

当然也可以参考官网提供的解决方法:

两者的方案原理是一致的,都是强制重建已经存在的密码存储文件。

翻译过来就是:

在 VNC 查看器 > 首选项 > 隐私中,请勾选“使用主密码保护 VNC 查看器”,设置密码,然后单击应用,确定。

完成此操作后,重新打开首选项并取消选中“使用主密码保护 VNC 查看器”并重试连接。

继续阅读VNC Viewer记住密码功能失效的解决办法

如何修复 Ubuntu 上的 Busybox Initramfs 错误

本简短指南介绍了如何修复 Ubuntu Linux 上的 Busybox Initramfs 错误。我使用 Ubuntu 24.04 LTS 作为我的 Dell Inspiron 笔记本电脑上的日常驱动程序。今天我将其打开,启动过程将我带到 BusyBox shell,最后出现 initramfs 提示符。

据我所知,我没有做错任何事。我没有强行关闭系统电源。昨天还运行得很好!然而,今天当我开机时,在启动过程中遇到了意想不到的问题。我发现自己没有正常加载,而是重定向到 BusyBox shell,并最终到达 initramfs 提示符。

我无法跳过这个屏幕。而且它也没有显示问题到底是什么。我所看到的只是一个空白的 Busybox shell

我此时不知道该怎么办。所以我只是通过 exit 命令来看看会发生什么。

然后我看到了实际的错误:

Ubuntu 上的 Busybox Initramfs 错误
Ubuntu 上的 Busybox Initramfs 错误

正如您在上面的输出中看到的,/dev/sda1 分区已损坏。该分区中的文件系统有一些错误。

如果您遇到过此类问题,则需要使用 fsck 命令检查并修复有问题的 Linux 文件系统。

请注意,有时输入 exit 命令后您不会看到任何错误。在这种情况下,请尝试在所有文件系统上运行 fsck

什么是 Busybox 和 Initramfs?

对于那些想知道的人来说,BusyBox 是一个软件套件,它在一个小型可执行文件中提供了许多常见的 UNIX 实用程序。它提供了您通常在 GNU fileutilsshellutils 等中找到的大多数实用程序的替代品。

Initramfs是一个基于 tmpfs 的初始ram文件系统。它包含在调用实际根文件系统上的 init 二进制文件之前挂载文件系统所需的工具和脚本。

修复 Ubuntu Linux 上的 Busybox Initramfs 错误

1. 要解决 Ubuntu Linux 上的 initramfs 错误,您需要使用 fsck 修复损坏分区中的文件系统 命令如下:

将 /dev/sda1 替换为您的分区名称。在您的系统中,它可能是 /dev/sdb1/dev/sdc1 等。您可以使用 cat /proc/partitions 或 blkid 或 lsblk 命令来获取 Busybox 中的 Linux 分区详细信息。请参阅本指南列出 Linux 中的磁盘分区。不要忘记传递 -y 标志。否则,您应该手动键入 -y 并每次按 ENTER 键来修复错误。

2. 现在,fsck 命令将开始自动修复文件系统中的所有坏块。

几分钟后,您将看到如下输出:

3. 接下来,输入 reboot 并按 ENTER 重新启动系统!

修复 Ubuntu Linux 上的 Busybox Initramfs 错误
修复 Ubuntu Linux 上的 Busybox Initramfs 错误

如果 reboot 命令不起作用,请输入 exit 并按 ENTER

交叉手指并等待系统重新启动!如果一切顺利,您的系统将正常启动,没有任何问题。

这些步骤帮助我和其他许多人解决了 Ubuntu Linux 操作系统上的 Busybox Initramfs 错误。如果您陷入 initramfs 提示符,本指南肯定会帮助您修复 Ubuntu 中的 initramfs 错误。

注意:如果您经常收到此错误,则可能是您的硬盘变得越来越弱。遇到这种情况,建议尽快备份数据并更换硬盘。

这不仅仅适用于 Ubuntu 操作系统。 initramfs 错误可能发生在 Debian 和其他 Ubuntu 衍生产品(例如 Pop OS、Linux mint 等)上。为了修复基于 Debian 的系统中的 initramfs 错误,只需按照上述步骤操作即可。

参考链接


如何修复 Ubuntu 上的 Busybox Initramfs 错误

實測 Raspberry Pi 5 上的 SD 卡效能

在 Raspberry Pi 5 使用高速的 SD 卡有用嗎? 我們實測 Raspberry Pi 5 上的 SD 卡效能,發現使用同一張 SD 卡可以在 Raspberry Pi 5 有更高的效能,可實際發揮 UHS-I SDR104 的速度。

要順暢的使用 Raspberry Pi,SD 卡(或稱 microSD 卡)是重要的組件。因為 SD 卡的速度會直接影響 Raspberry Pi 的運作速度,就像硬碟的速度影響傳統桌上型電腦的運作速度一樣。從 SD 卡中讀取資料的速度越快,Raspberry Pi 的啟動速度就越快,程式的載入速度就越快。同樣,寫入速度也會影響保存大量資料的程式的運作效果,因此使用高速的 SD 卡非常重要。

SD 卡科普

SD 卡的速度等級會印在卡片本身或包裝上。下圖所示的 32GB 卡屬於 Class 4,以字母 C 內的 4 表示——這表示它的寫入速度為 4MB/s。

圖片來源:Raspberry Pi SD Card Speed Test
圖片來源:Raspberry Pi SD Card Speed Test

下面顯示的 64GB 卡屬於 Class 10,因此可以用 10MB/s 的速度寫入。上頭顯示的 UHS(Ultra High Speed) Class 1 的標誌,字母 U 裡面的 1,對應著相同的速度。

圖片來源:Raspberry Pi SD Card Speed Test
圖片來源:Raspberry Pi SD Card Speed Test

效能標示

表格來源:SD卡
表格來源:SD卡

A2 等級 SD 卡,最低隨機讀取(Random Read Speed)要達到 4000 IOPS,最低隨機寫入(Random Write Speed)要達到 2000 IOPS

速度標示

表格來源: SD卡
表格來源:SD卡

例如標示 UHS-I SDR104 要能達到 104MB/s 的總線速度(Bus speed)。

表格來源:SD卡
表格來源:SD卡

而最低寫入速度為 30 MB/s 的話,可以在 UHS Speed Class 標示為 Class 3 (U3),在 Video Speed Class 標示為 Class 30 (V30),表示可以順暢的播放 4K 影片 60/120 fps (UHS)。

因為 Raspberry Pi 5 升級了 SD Controller,因此可支援 SD 卡 的 SDR104 高速模式。

Raspberry Pi 上的 SD 卡效能測試工具

自從 2020-05-27 Raspberry Pi OS 釋出後就新增了多種應用程式,例如內建 Raspberry Pi Diagnostics 功能可以診斷各種硬體資源,第一個工具就是 SD 卡效能檢測(SD Card Speed Test)。

SD Card Speed Test 操作方法

SD Card Speed Test 解讀

  • 操作過程將每秒隨機寫入操作 500 次,每秒隨機讀取操作 1500 次。
  • IOPS(Input/Output Operations Per Second)是一個用於電腦儲存裝置效能測試的量測方式,表示每寫寫入/讀取次數。
  • 如果將 IOPS 乘以 Transfer Size in Bytes 可計算出每秒可讀寫的頻寬(單位 MB/s)
  • 本例的循序寫入速度(Sequential Write Speed)為 42390 KB/sec,超過 12MB/s 標準。
  • 本例的隨機寫入速度(Random Write Speed)為 2109 IOPS,超過 2000 IOPS 標準。
  • 本例的隨機讀取速度(Random Read Speed)為 4755 IOPS,超過 4000 IOPS 標準。
  • 日誌檔預設會用 rpdiags.txt 檔名存放在家目錄。

實測 Raspberry Pi 5 上的 SD 卡效能

測試環境
測試結果

從左上、右上、左下、右下依序為 Raspberry Pi 5、Pi 4、Pi 3B+、Pi 3B(圖片來源:PiePie 台灣樹莓派)
從左上、右上、左下、右下依序為 Raspberry Pi 5、Pi 4Pi 3B+Pi 3B(圖片來源:PiePie 台灣樹莓派

上圖是使用同一張 microSDXC UHS-I(V30)(A2) 64GB 記憶卡使用 SD Card Speed Test 在 Raspberry Pi 不同主板上的執行結果。下方圖表可清楚看到在 Raspberry Pi 5Pi 4Pi 3B+Pi 3BZero 2 上執行,Raspberry Pi 5 上的 SD 卡效能 可以發揮的更好!

SD Card Speed Test 在不同 Raspberry Pi 主板上的執行結果(表格來源:PiePie 台灣樹莓派)
SD Card Speed Test 在不同 Raspberry Pi 主板上的執行結果(表格來源:PiePie 台灣樹莓派

備註:64-bit OS 只支援 Pi 3B 和 Zero 2 以上版本。

参考链接


【教學/基礎】實測 Raspberry Pi 5 上的 SD 卡效能