2025年下半年系统架构设计师案例提炼

案例分析概述

案例分析作答要求

案例分析第一题必做，后面四道题四选二。机试选做题很简单，选哪一道题就做哪一道，不选的就清空不要写任何数据。考试的时候灵活应变，看清楚要求即可。

除此之外，综合知识和案例分析2个科目连考，作答总时长240分钟，综合知识科目最长作答时长150分钟，最短作答时长120分钟。诸葛老师不建议大家提前交卷，案例时间较为紧张，需要全都利用起来。

历年真题考点分析

从 2016 到 2025，试题已经从 “架构风格+UML图” 的静态理论题，演进为 “智能化分布式架构+AI/区块链/Web融合” 的系统实践题。 📌 未来重点复习主线： 质量属性 → 微服务与解释器风格 → Redis 架构与同步 → 云边端AI → 区块链智能合约

根据历年真题考点分析，将架构案例分析真题分为如下几个大类：

①软件架构设计：每年必考1-2题，并且是第1题必选题，必须掌握，主要涉及质量属性、软件架构风格、软件架构评估、MVC架构、面向服务的架构SOA、ESB、J2EE架构等。
②软件系统设计：几乎每年必考1题，主要涉及UML的图、关系的识别，尤其是类图、用例图、活动图、状态图；设计模式识别；数据流图、E-R图等简单识别；信息安全相关技术；项目管理-进度管理-关键路径。
③ 数据库系统设计：几乎每年必考 1 题，主要考查数据库的一些新技术的比较，如关系型数据库、非关系型数据库 NoSQL 以及内存数据库 Redis 等，还会包括反规范化技术、主从复制、负载均衡等。
④ 嵌入式系统设计：几乎每年必考1题，选做题，考查比较的多的是嵌入式系统的实时性和可靠性以及容错性等概念。大概率会考到一些嵌入式领域陌生技术，如果是完全没见过的技术，不选即可。
⑤Web系统设计：几乎每年必考1题，主要考查Web相关技术，一般结合架构进行考查。偶尔会考到新技术，遇到完全没听说过的技术，就不选。

改版后下篇八大架构是重中之重。

此外，若偶尔考到一些完全陌生的架构和技术，可直接选择忽略，因为陌生技术不会再考第二次，无法归纳总结，完全没有必要了解。

历年案例分析考点归纳如下

十年总体趋势概览（2016–2025）

历年考点发展脉络（时间线视图）

十年知识点热力图（🔥 越多代表考频越高）

考查知识结构图谱（抽象模型）

系统架构层面（宏观） │ ├── 软件架构 │ ├─ 架构风格（C/S、微服务、解释器、管道过滤器） │ ├─ 质量属性（六要素、效用树、敏感点、权衡点） │ ├─ 非功能性需求（性能、可靠性、安全性） │ ├── 数据架构 │ ├─ Redis（主从复制、分布式锁、持久化、cache-aside） │ ├─ MySQL（读写分离、分区、事务） │ └─ NoSQL（MongoDB、矢量化、缓存机制） │ ├── 嵌入式与工业物联网 │ ├─ ROS/RTOS、SOME/IP、DDS、资源池 │ ├─ 云测AI、端侧AI、边缘计算 │ ├── Web 架构 │ ├─ RESTful、响应式设计、爬虫Scrapy、异步I/O │ ├─ 区块链（六层、流程、智能合约） │ └── 设计建模与工程管理 ├─ UML / SysML 图（用例图、顺序图、类图） ├─ 敏捷开发（Scrum）、形式化开发

2025 年考情总结与趋势预测（⭐重点）

学习建议

案例分析学习建议：

第一步，听课，听一遍诸葛老师的系统架构设计师《案例分析专题课程》，里面详细讲解了大量典型案例真题、解题技巧、如何分析题目等，很重要。

第二步，学习考点，读此一本通第2章、第3章案例真题精华考点，将相关考点都理解和记忆，不理解的再去听课程对应部分知识点。

第三步，刷题，做此一本通第4章历年案例真题，先按题目分类进行专题训练，再按年份做题，并按规定90分钟练习，以模拟真实考试场景，浏览五道题目，第一题必做，其他四选二。做完后核对答案（在第5章），看看自己哪些知识点需要加强。当然，四选二的题，要选择自己擅长的题目，要学会临场应变。

第二版教材下篇架构设计是纯新增内容，有大量关于不同架构设计实战内容，涉及到不少新技术，是比较难理解的，同学们一定要先听教材下篇的诸葛老师课程讲解，再来看第3章，否则很难把握重点，同时，因为这一块实战性强，新技术多，老师也难免会有遗漏错误之处，敬请理解，也欢迎大家一起讨论反馈。

答题技巧

答题时，先看问题，再看题目描述。

第一题必做，先做完第一题。对于四选二，快速浏览所有题目问题和问题描述，是否能看懂，再进行选题。

问题与题目描述相结合，尤其是遇到系统分析和设计以及新技术等问题，答案一般都在题目描述里，从题目描述里抽象总结出问题答案即可。当然要以简练的语言写出答案，一般题目会有最大字数要求，不建议超过。

列条目回答问题，把自己认为对的都写上，多写不会扣分，少写一定会扣分。

若遇到新的知识点，没关系，要稳住心态。能避开则避开，否则就理解所问问题的倾向性，顺势答题即可。

软件工程章节

流程图和数据流图之间的区别与联系

数据流图作为一种图形化工具，用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流。

流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流。

两者的区别主要包括：

（1） 数据流图中的处理过程可并行；流程图在某个时间点只能处于一个处理过程。
（2）数据流图展现系统的数据流；流程图展现系统的控制流。
（3）数据流图展现全局的处理过程，过程之间遵循不同的计时标准；流程图中处理过程遵循一致的计时标准。
（4） 数据流图适用于系统分析中的逻辑建模阶段；流程图适用于系统设计中的物理建模阶段。

活动图和流程图的区别

（1） 活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现系统的行为，而非处理过程；而流程图着重描述处理过程。
（2）流程图一般都限于顺序进程，而活动图则可以支持并发进程。
（3） 活动图是面向对象的，而流程图是面向过程的。

状态图和活动图的含义及其区别

状态图主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件 （event），以及因状态转移而伴随的动作 （action）。

活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发）。

两者最大的区别是：状态图侧重于描述行为的结果，而活动图侧重描述行为的动作。其次活动图可描述并发行为，而状态图不能。

数据流图中所包含的基本元素及其作用

数据流：数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成。 外部实体：代表系统之外的实体，可以是人、物或其他软件系统。 加工（处理）：加工是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。 数据存储：表示信息的静态存储，可以是文件、文件的一部分、数据库的元素等。

数据流图与数据字典在软件需求分析和设计阶段的作用

数据流图是描述数据处理过程的工具，从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。数据流在分析阶段的作用是建立系统的功能模型。在设计阶段的作用是为模块划分与模块之间接口设计提供依据。数据字典是对于数据流图中出现的所有被命名的图形元素在数据字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。数据字典是所有人员工作的依据，统一的标准。它可以确保数据在系统中的完整性和一致性。具体作用包括：按各种要求列表、相互参照、由描述内容检索名称、一致性检验和完整性检验。

用例之间的关系

用例之间的关系主要有泛化 （Generalization）、包含 （Include） 和扩展 （Extend）。

（1） 当可以从两个或多个用例中提取公共行为时，可以使用包含关系来表示。
（2） 如果一个用例混合了两种或两种以上不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。
（3） 当多个用例共同拥有一个类似的结构和行为的时候，可以将它们的共性抽象成父用例，其他的用例作为泛化关系中的子用例。

非功能性需求可分为四类：操作性需求、性能需求、安全性需求和文化需求。其含义为

操作性需求（Operational Requirements）：指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求。 性能需求（Performance Requirements）：针对系统性能要求的指标。常见的包括：响应时间、吞吐率。 安全性需求（Security Requirements）：防止系统崩溃和保证数据安全所需要采取的保护措施或预防措施。 文化需求（Cultural Requirements）：使用本系统的不同用户群体对系统提出的特有要求。

对象模型、动态模型和功能模型的含义以及它们之间的关联关系

对象模型用于描述系统数据结构：动态模型用于描述系统控制结构：功能模型用于描述系统功能。 这3种模型都涉及数据、控制和操作等共同的概念，但侧重点不同，从不同侧面反映了系统的实质性内容，综合起来全面地反映了对目标系统的需求。 功能模型指明了系统应该“做什么”：动态模型明确规定了什么时候做：对象模型则定义了做事情的实体。

功能建模、数据建模、行为建模对比

1）功能建模是使用功能点的概念来描述系统的功能，并将其分解为各个子功能，以明确系统的功能需求，常用的方法有数据流图(DFD)。DFD描绘信息流和数据输入输出的移动过程。 2）数据建模是通过建立数据模型来描述系统所涉及的数据以及数据之间的关系，通常使用实体关系图(E-R图)来表示实体之间的关系和属性。E-R图提供了表示实体类型、属性和联系的方法。 3）行为建模是描述系统的行为和交互方式，常用的方法有状态转换图(STD)。STD通过描述系统的状态及引起系统状态转换的事件，表示系统的行为。

数据流图的平衡原则

（1） 子图与父图之间的平衡: 父图与子图之间平衡是指任何一张DFD子图边界上的输入/输出数据流必须与其父图对应加工的输入/输出数据流保持一致。 如果父图中某个加工的一条数据流对应于子图中的几条数据流，而子图中组成这些数据流的数据项全体正好等于父图中的这条数据流，那么它们仍然是平衡的。 （2）子图内部：加工的输入和输出需要平衡。 其中，数据流图常见3种错误：【黑洞】一个加工只有输入数据流而无输出数据流。【奇迹】一个加工只有输出数据流而无输入数据流。【灰洞】若一个加工的输入数据流无法通过加工产生输出流。

类之间的关系以及基本含义

依赖关系：一个事物发生变化影响另一个事物。 泛化关系：特殊/一般关系。 关联关系：描述了一组链，链是对象之间的连接。 聚合关系：整体与部分生命周期不同。 组合关系：整体与部分生命周期相同。 实现关系：接口与类之间的关系。

设计类通常分为三类，这三类的职责分别是

（1）实体类。实体类映射需求中的每个实体，保存需要存储在永久存储体中的信息，例如，用户、商品等。
（2）控制类。控制类是用于控制用例工作的类，用于对一个或几个用例所特有的控制行为进行建模。例如，结算、备货等。
（3）边界类。边界类用于封装在用例内、外流动的信息或数据流。例如，浏览器、购物车等。

SysML【系统建模语言】

对象管理组织OMG在对UML0的子集进行重用和扩展的基础上，提出了一种新的系统建模语言SysML（Systems Modeling Language），作为系统工程的标准建模语言。SysML的目的是统一系统工程中使用的建模语言。

SysML中的需求关系：包含、跟踪、继承需求、改善、满足、验证和复制。

包含 （Include）：需求可以且只能包含其他需求。 跟踪（Trace）：对提供方元素（位于箭头端）的修改可能会导致对客户端元素（位于尾端）修改的需要。 继承 （deriveReqt）：一个需求可以继承另一个需求的属性。 改善（refine）：表示一个需求改进了另一个需求的满足程度。 满足 （satisfy）：一般是模块满足某种需求。 验证（verify）：表示一个需求验证了另一个需求的正确性。 复制 （Copy）：表示一个需求复制了另一个需求的特性。

序列图

在序列图中，常见的消息类型有以下几种： 简单消息：简单消息可以泛指对象之间的任何消息调用或发送，而不必关心是异步还是同步的。 同步消息：表示在发送消息后，接收者必须向发送者返回响应才能继续执行。它是一种阻塞式的消息传递方式。 异步消息：表示在发送消息后，发送者不需要等待接收者的响应，可以继续执行其他操作。它是一种非阻塞式的消息传递方式。 返回消息：表示返回的消息。 创建消息：表示创建一个新的对象。 销毁消息：表示销毁一个对象。

在序列图中，条件分支的组合片段包括：选择片段、循环片段、并行片段。 选择片段是根据条件的成立与否来选择执行不同的消息流，只会选择其中的一条进行执行；循环片段是根据条件的成立与否来重复执行消息流，直到条件不成立为止；并行片段是将消息流并行执行，可以同时或并发执行其中的消息流，可以在不同的对象间进行交互。

Scrum 敏捷开发

该方法侧重于项目管理。Scrum 是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum 包括了一系列实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。在 Scrum 中，使用产品 Backlog 来管理产品的需求，产品 Backlog 是一个按照商业价值排序的需求列表。根据 Backlog 的内容，将整个开发过程被分为若干个短的迭代周期 （Sprint）。在 Sprint 中，Scrum 团队从产品 Backlog 中挑选最高优先级的需求组成 Sprint backlog。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。当所有 Sprint 结束时，团队提交最终的软件产品。

结构化分析方法

结构化分析方法（Structured Analysis，SA）主要用于系统需求分析。它通过图形化工具（如数据流图、数据字典等）表达用户需求，帮助系统分析人员产生功能规约。具体步骤包括：

（1） 分析当前情况，生成反映当前物理模型的数据流图 （DFD）。
（2） 推导出等价的逻辑模型的 DFD。
（3） 设计新的逻辑系统，生成数据字典和基元描述。
（4） 建立人机接口，提出目标系统物理模型的 DFD。
（5） 确定各种方案的成本和风险等级，进行分析。
（6） 选择一种方案。
（7） 建立完整的需求规约

信息工程方法

信息工程方法（Information Engineering，IE）是一种系统化的方法论，主要用于指导企业或组织的信息系统规划、设计、开发与管理。它以数据为中心，强调通过结构化流程、数据建模和技术整合来构建高效、可扩展的信息系统。

数据流图 （DFD）

DFD需求建模方法，也称为过程建模和功能建模方法。DFD建模方法的核心是数据流，从应用系统的数据流着手以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流。

DFD建模方法首先抽象出具体应用的主要业务流程，然后分析其输入，如其初始的数据有哪些，这些数据从哪里来，将流向何处，又经过了什么加工，加工后又变成了什么数据，这些数据流最终将得到什么结果。通过对系统业务流程的层层追踪和分析把要解决的问题清晰地展现及描述出来，为后续的设计、编码及实现系统的各项功能打下基础。

DFD方法由4种基本元素（模型对象）组成：数据流、处理/加工、数据存储和外部项。

（1） 数据流 （Data Flow）。数据流用一个箭头描述数据的流向，箭头上标注的内容可以是信息说明或数据项。
（2） 处理 （Process）。表示对数据进行的加工和转换，在图中用矩形框表示。指向处理的数据流为该处理的输入数据，离开处理的数据流为该处理的输出数据。
（3） 数据存储。表示用数据库形式（或者文件形式）存储的数据，对其进行的存取分别以指向或离开数据存储的箭头表示。
（4）外部项。也称为数据源或者数据终点。描述系统数据的提供者或者数据的使用者，如教师、学生、采购员、某个组织或部门或其他系统，在图中用圆角框或者平行四边形框表示。

建立DFD图的目的是描述系统的功能需求。DFD方法利用应用问题域中数据及信息的提供者与使用者、信息的流向、处理、存储4种元素描述系统需求，建立应用系统的功能模型。具体的建模过程及步骤如下。

（1） 明确目标，确定系统范围。

首先要明确目标系统的功能需求，并将用户对目标系统的功能需求完整、准确、一致地描述出来，然后确定模型要描述的问题域。虽然在建模过程中这些内容是逐步细化的，但必须自始自终保持一致、清晰和准确。

（2）建立顶层DFD图。

顶层DFD图表达和描述了将要实现的系统的主要功能，同时也确定了整个模型的内外关系，表达了系统的边界及范围，也构成了进一步分解的基础。

（3）构建第一层DFD分解图。

根据应用系统的逻辑功能，把顶层DFD图中的处理分解成多个更细化的处理。

（4） 开发DFD层次结构图。

对第一层DFD分解图中的每个处理框作进一步分解，在分解图中要列出所有的处理及其相关信息，并要注意分解图中的处理与信息包括父图中的全部内容。分解可采用以下原则：保持均匀的模型深度；按困难程度进行选择；如果一个处理难以确切命名，可以考虑对它重新分解。

（5）检查确认DFD图。

按照规则检查和确定DFD图，以确保构建的DFD模型是正确的、一致的，且满足要求。具体规则包括：父图中描述过的数据流必须要在相应的子图中出现；一个处理至少有一个输入流和一个输出流；一个存储必定有流入的数据流和流出的数据流；一个数据流至少有一端是处理端；模型图中表达和描述的信息是全面的、完整的、正确的和一致的。

软件设计方法包括

（1） 模型驱动设计。

模型驱动设计是一种系统设计方法，强调通过绘制图形化系统模型描述系统的技术和实现。通常从模型驱动分析中开发的逻辑模型导出系统设计模型，最终，系统设计模型将作为构造和实现新系统的蓝图。

（2）结构化设计。

结构化设计是一种面向过程的系统设计技术，它将系统过程分解成一个容易实现和维护的计算机程序模块。把一个程序设计成一个自顶向下的模块层次，一个模块就是一组指令：一个程序片段、程序块、子程序或者子过程，这些模块自顶向下按照各种设计规则和设计指南进行开发，模块需要满足高度内聚和松散耦合的特征。

（3） 信息工程。

信息工程是一种用来计划、分析和设计信息系统的模型驱动的、以数据为中心的但对过程敏感的技术。信息工程模型是一些说明和同步系统的数据和过程的图形。信息工程的主要工具是数据模型图（物理实体关系图）。

（4）原型设计。

原型化方法是一种反复迭代过程，它需要设计人员和用户之间保持紧密的工作关系，通过构造一个预期系统的小规模的、不完整的但可工作的示例来与用户交互设计结果。原型设计方法鼓励并要求最终用户主动参与，这增加了最终用户对项目的信心和支持。原型更好地适应最终用户总是想改变想法的自然情况。原型是主动的模型，最终用户可以看到并与之交互。

（5） 面向对象设计。

面向对象设计是一种新的设计策略，用于精炼早期面向对象分析阶段确定的对象需求定义，并定义新的与设计相关的对象。面向对象设计是面向对象分析的延伸，有利于消除“数据”和“过程”的分离。

（6） 快速应用开发。

RAD是瀑布的高速变种，通过使用基于构件的开发方法获得快速的开发进度。

使用UML两类交互图的选取原则

在软件分析和设计过程中，可以使用UML的其中两类交互图：顺序图和通信图来进行系统的建模和设计。选取原则是可以根据系统的功能需求决定使用哪种交互图。顺序图适用于描述对象之间的时序交互和消息传递顺序，适合描述系统中多个对象之间的交互逻辑，以及消息传递的时序；通信图适用于描述对象之间的合作关系和协作结构，强调收发消息的对象的结构组织。

OMT 方法

OMT方法的OOA模型包括对象模型、动态模型和功能模型。

（1）对象模型表示静态的，结构化的“数据”性质，它是对模拟客观世界实体的对象及对象间的关系映射，描述了系统的静态及结构。通常用类图表示。对象模型描述系统中对象的静态结构、对象之间的关系、对象的属性、对象的操作。对象模型表示静态的、结构上的、系统的“数据”特征。对象模型为动态模型和功能模型提供了基本的框架。对象模型用包含对象和类的对象图来表示。
（2）动态模型表示瞬间的，行为化的系统控制性质，它规定了对象模型中的对象合法化变化序列。通常用状态图表示。动态模型描述与时间和操作顺序有关的系统特征——激发事件、事件序列、确定事件先后关系的状态以及事件和状态的组织。动态模型表示瞬间的、行为上的、系统的“控制”特征。动态模型用状态图来表示，每张状态图显示了系统中一个类的所有对象所允许的状态和事件的顺序。
（3）功能模型表示变化的系统的功能性质，它指明了系统应该做什么，因此直接地反映了用户对目标系统的需求，通常用数据流图表示。功能模型描述与值变换有关的系统特征——功能、映射、约束和函数依赖。

架构设计章节

架构风格的概念

软件架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

五大架构风格有哪些

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

其中典型风格对比：

解释器

通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。

事件驱动风格

软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。(2分)选择李工方案的理由:(9分) (1)数据实时性: 事件驱动通过异步消息处理实现毫秒级响应，满足车流数据即时需求;分层架构因跨层调用链累积延迟，难以保障实时性。 (2)系统扩展性: 事件驱动以统一事件总线解耦设备接入，新增物联网设备仅需注册事件;分层架构需逐层修改接口协议，扩展成本显著增高。 (3)功能灵活性: 事件驱动支持动态订阅机制，专家规则变更即时生效:分层架构需重构业务逻辑层代码，灵活性严重受限。【问题2】(6分) 扩展实现: (1)新设备接入时实现统一事件发布接口 (2)将设备数据封装为标准事件格式 (3)向事件总线注册新事件类型，现有处理模块可选择性订阅 【问题3】(8分)仓库风格 或 黑板风格 (1)实时交通数据/黑板(共享数据) (2)-(5)流量预测模块、单路口 交通优化模块、干线协调(绿波)模块，区域协调模块，优先通行模块(消防车、救护车) 【(2)-(5)不区分顺序】 (6)计算/处理

层次架构优点

(1)使用层次化模型可使得网络成本降至最低。各层仅考虑自身的功能实现要求，以及运维资源要求，避免各层中不必要特性所花费的资金。 (2)层次化设计可充分利用不同层次成熟的模块化设备或部件，既避免不必要开发费用， 也利于网络稳定运行。 (3)层次化设计使得网络因需求而变化或演化更加容易。

层次架构的问题

层次式体系结构是一个可靠的通用的架构，对很多应用来说，如果不确定哪种架构适合，可以用它作为一个初始架构。但是，设计时需要注意以下两点。 (1)要注意的是污水池反模式 所谓污水池反模式，就是请求流简单地穿过几个层，每层里面基本没有做任何业务逻辑，或者做了很少的业务逻辑。比如一些JavaEE例子，业务逻辑层只是简单的调用了持久层的接口，本身没有任何业务逻辑。 (2)需要考虑的是分层架构可能会让你的应用变得庞大。即使你的表现层和中间层可以独立发布，但它的确会带来一些潜在的问题，比如:分布模式复杂、健壮性下降、可靠性和性能的不足，以及代码规模的膨胀等。

ESB的主要功能包括

ESB是传统中间件技术与XML、Web服务等技术结合的产物，主要支持异构系统集成。ESB基于内容的路由和过滤，具备复杂数据的传输能力，并可以提供一系列的标准接口。主要功能包括：

（1）应用程序的位置透明性；
（2）传输协议转换； （3）消息格式转换；
（4）消息路由；
（5）消息增强；
（6） 安全支持;
（7） 监控和管理。

MVC架构的含义

MVC全名是Model View Controller，是模型（model）一视图（view）一控制器（controller）的缩写，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

Model（模型） 是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。 View（视图） 是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。 Controller（控制器） 是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

MVC优点

(1)允许多种用户界面的扩展。在MVC模式中，视图与模型没有必然的联系，都是通过控制器发生关系，这样如果要增加新类型的用户界面，只需要改动相应的视图和控制器即可，而模型则无须改动。 (2)易于维护。控制器和视图可以随着模型的扩展而进行相应的扩展，只要保持一种公共的接口，控制器和视图的旧版本也可以继续使用。 (3)功能强大的用户界面。用户界面与模型方法调用组合起来，使程序的使用更加清晰，可将友好的界面发布给用户。

质量属性的含义

（1） 性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。
（2） 可用性是系统能够正常运行的时间比例。
（3） 可靠性是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。
（4） 健壮性是指在处理或环境中, 系统能够承受压力或变更的能力。
（5） 安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
（6） 可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力。
（7） 可变性是指体系结构经扩充或变更成为新体系结构的能力。
（8） 易用性是衡量用户使用一个软件产品完成指定任务的难易程度。
（9） 可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。
（10） 功能性是系统所能完成所期望工作的能力。
（11） 互操作性是指系统与外界或系统与系统之间的相互作用能力。

常见的几种软件质量属性的设计策略

（1）性能 性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。 代表参数：响应时间、吞吐量 设计策略：优先级队列、资源调度

（2）可用性 可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。 代表参数：故障间隔时间 设计策略：冗余、心跳线

（3）安全性 安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。 设计策略：追踪审计

（4） 可修改性 可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。 设计策略：接口-实现分离、抽象、信息隐藏

EJB中的Bean分三种类型

Session Bean 描述了与客户端的一个短暂的会话。当客户端的执行完成后，Session Bean 和它的数据都将消失； Entity Bean 描述了存储在数据库表中的一行持久稳固的数据，如果客户端终止或者服务结束，底层的服务会负责 Entity Bean 数据的存储； Message-Driven Bean 结合了 Session Bean 和 Java 信息服务（JMS）信息监听者的功能，它允许一个商业组件异步地接受 JMS 消息。

风险点、敏感点、权衡点的含义

系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。 敏感点是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

场景的描述

场景：场景是从风险承担者的角度与系统交互的简短描述。场景可从六个方面进行描述：刺激源、刺激、制品、环境、响应、响应度量。 刺激源 （Source）：这是某个生成该刺激的实体（人、计算机系统或者任何其他刺激器）。 刺激（Stimulus）：该刺激是当刺激到达系统时需要考虑的条件。 环境（Environment）：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。 制品（Artifact）：某个制品被激励。这可能是整个系统（或系统的一部分）。 响应 （Response）：该响应是在激励到达后所采取的行动。 响应度量（Measurement）：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

REST 的 5 个原则

（1） 网络上的所有事物都被抽象为资源。
（2） 每个资源对应一个唯一的资源标识。
（3） 通过通用的连接件接口对资源进行操作。
（4） 对资源的各种操作不会改变资源标识。
（5） 所有的操作都是无状态的。

云计算架构

【管理层】提供对所有层次云计算服务的管理功能。 【用户访问层】方便用户使用云计算服务所需的各种支撑服务，针对每个层次的云计算服务都需要提供相应的访问接口。 【应用层】提供软件服务，如：财务管理，客户关系管理，商业智能。 【平台层】为用户提供对资源层服务的封装，使用户可以构建自己的应用。 【资源层】提供虚拟化的资源，从而隐藏物理资源的复杂性。如：服务器，存储。

云原生架构设计原则

服务化原则：使用微服务。 弹性原则：可根据业务变化自动伸缩。 可观测原则：通过日志、链路跟踪和度量。 韧性原则：面对异常的抵御能力。 所有过程自动化原则：自动化交付工具。 零信任原则：默认不信任网络内部和外部的任何人/设备/系统。 架构持续演进原则：业务高速迭代情况下的架构与业务平衡。

分布式缓存和微服务架构对比

1.系统性能 微服务架构优势:通过服务拆分实现水平扩展，各服务可独 立优化(如课程服务使用高性能数据库、认证服务使用轻量级协议)，能显著提升系统整体吞吐量和容错能力。 劣势:服务间通信(如HTTPIRPC)会引入网络延迟，若拆分不合理(如跨服务事务过多)或缺乏异步设计，可能降低局部性能。 分布式缓存 优势:直接减少数据库访问压力，对读多写少场景(如课程列表、用户信息)性能提升立竿见影，响应时间可降低90%以上。 劣势:对高频写场景(如实时互动、频繁更新)效果有限，需额外处理缓存穿透/雪崩等问题，可能引入数据不一致风险。

2.开发复杂度 微服务架构 劣势:需重构单体应用为松耦合服务，引入服务注册、API网关、分布式事务(如Saga模式)、监控告警等基础设施，开发复杂度陡增。 优势:长期维护成本低，模块清晰，适合大规模团队协作。 分布式缓存 优势:仅需在数据访问层添加缓存逻辑(如Redis客户端)，无需大规模重构，开发周期短。 劣势:需处理缓存策略(如LRU/TTL)、一致性(如双写失效策略)等细节，但对架构整体影响较小。3.开发改造成本

ABSD方法是架构驱动，即强调由业务【商业】、【质量】和【功能需求】的组合驱动架构设计。ABSD方法有三个基础。第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基干模块的内聚和耦合技术;第二个基础是通过选择架构风格来实现质量和业务需求;第三个基础是软件模板的使用。视角与视图:从不同的视角来检查，所以会有不同的视图。用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求。

Redis 和 MemCache 对比

Redis 分布存储方案

Redis 集群切片的常见方式

Redis分片方案

Redis 持久化

RDB：传统数据库中快照的思想。指定时间间隔将数据进行快照存储。

AOF：传统数据库中日志的思想，把每条改变数据集的命令追加到 AOF 文件末尾，这样出问题了，可以重新执行 AOF 文件中的命令来重建数据集。

Redis内存淘汰机制

过期策略：即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 策略可以保证数据不被丢失，这也是系统默认的一种淘汰策略。

JWT

JWT（JSON Web Token）是一种用于身份验证和授权的开放标准。

它是一种轻量级的、基于JSON的令牌，可以在客户端和服务器之间传递信息。

JWT由三部分组成：

【头部】包含令牌类型和所使用的算法 【载荷】包含用户信息和其他元数据 【签名】用于验证令牌的完整性和真实性

JWT的应用场景：【信息交换】【授权】 不需要服务器端存储状态，安全地传递【非敏感信息】

负载均衡算法

静态算法是不考虑服务器动态负载的算法，包括：

（1） 轮转算法：轮流将服务请求（任务）调度给不同的节点（即：服务器）。
（2） 加权轮转算法：考虑不同节点处理能力的差异。
（3） 源地址哈希散列算法：根据请求的源IP地址，作为散列键从静态分配的散列表找出对应的节点。
（4） 目标地址哈希散列算法：根据请求目标 IP 做散列找出对应节点。
（5） 随机算法: 随机分配, 简单, 但不可控。

动态算法是考虑服务器动态负载的算法，包括：

（1） 最小连接数算法：新请求分配给当前活动请求数量最少的节点，每个节点处理能力相同的情况下。
（2） 加权最小连接数算法：考虑节点处理能力不同，按最小连接数分配。
（3） 加权百分比算法：考虑了节点的利用率、硬盘速率、进程个数等，使用利用率来表现剩余处理能力。

应用服务器

应用服务器是指通过各种协议把商业逻辑暴露给客户端的程序。

（1） 若系统负荷很大, 可以部署多台应用服务, 多台应用服务器分担任务, 以达到性能要求。
（2） 应用服务器可以通过灵活地增加服务器完成扩展，所以可扩展性很好。 （3） 应用服务器可长时间稳定运行。因为当一台应用服务器出现故障时，可以将当前运行的事务转移至正常应用服务器上完成执行，不影响业务正常执行，从而保障高可靠性与稳定性。

J2EE架构

在一个典型的基于 MVC（Model View Controller）的 J2EE 应用中，系统的界面由 JSP 构件实现，分发客户请求、有效组织其他构件为客户端提供服务的控件器由 Servlet 构件实现，数据库相关操作由 Entity Bean 构件实现，系统核心业务逻辑由 Session Bean 构件实现。

微服务架构

微服务架构是SOA架构的升级，是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间相互协调、相互配合、为用户提供最终价值。微服务架构中的每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制相互沟通。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等中。

通过比较微服务架构和单体式架构。

微服务架构的主要优点有：1）复杂应用解耦；2）独立；3）技术选型灵活；4）容错；5）松耦合，易扩展。

微服务架构的主要缺点有：1）微服务架构分布式特点带来的复杂性。服务发现与服务调用链跟踪变得困难；分布式环境下的数据一致性更复杂；测试的复杂性，需要对服务间依赖进行测试。2）。在大规模应用部署中，在监控、管理、分发及扩容等方面，微服务也存在着巨大挑战。

响应式Web设计

响应式Web设计是指我们设计与开发的页面可以根据用户的行为（比如改变浏览器的窗口大小）和不同的设备环境（比如系统平台、屏幕分辨率以及横竖屏等）做出相应的响应来调整页面的布局，以提供用户可感知的、流畅的阅读和操作体验。响应式设计一般遵循“设计先行，内容优先，移动优先”的原则。就是说，如果一个页面想要响应PC端和移动终端包括用户的一些行为等，那么设计师至少需要设计两套以上页面的设计图（PC端一套，移动终端一套），交互设计师也需先根据终端进行交互设计，把需求中最重要的内容展示在移动小屏幕上，然后前端工程师据此设计开发出响应式框架。

实现响应式Web设计主要依赖于以下几种技术：

流式布局：通过百分比或视口单位（如vw、vh）来定义元素的宽度和高度，使网页布局能够随着浏览器窗口的大小变化而自动调整。 弹性布局（Flexbox）：Flexbox 提供了一种更加灵活的方式来对容器中的项目进行排列、对齐和分配空间，即使它们的大小未知或是动态的，也能保持元素之间的间隔和对齐方式不变。此外，通过结合媒体查询，还可以实现弹性图片的缩放，以适应不同设备的显示需求。 媒体查询（Media Queries）：媒体查询允许我们在不同的设备条件下应用不同的样式规则。通过检测设备的特性（如屏幕宽度、高度、分辨率等），我们可以为不同的设备或屏幕尺寸编写特定的CSS样式，以实现更加精细化的布局控制。 综上所述，响应式Web设计通过综合运用流式布局、弹性布局和媒体查询等技术手段，确保了网页能够在各种设备和屏幕尺寸下都能提供优秀的用户体验。

胖客户端和瘦客户端的区别

什么是SOA

SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统 和通用的方式进行交互。

ESB在SOA中的作用

（1）SOA的一种实现方式，ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合； （2）描述服务的元数据和服务注册管理；
（3）在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等；
（4） 发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。

SOA信息系统安全保障的措施

（1） 数据保密性（机密性）：保密性旨在防止未经授权的用户访问敏感数据，从而避免数据泄露。在SOA中，数据在传输和消息交换过程中均需要保护。通过实施数据加密技术，可以在不同层面（如传输层和消息层）确保数据不被未授权人员查看。
（2）数据完整性：完整性确保数据在传输或存储过程中保持其原有的正确性、一致性和完整性，防止数据被篡改或损坏。使用数字签名技术可以验证数据的来源和完整性，确保接收方收到的数据是完整且未被篡改的。
（3）审计追踪（可审计性）：审计是一种事后监控机制，用于跟踪和记录系统的访问活动。通过审计，可以及时发现并响应非法访问行为，增强系统的安全防范能力。不同的系统根据其安全需求，可能需要不同级别的审计记录和监控。
（4）身份认证管理：身份认证是确保服务请求者和服务提供者之间交互安全的首要步骤。通过相互认证对方的身份，可以防止非授权实体访问服务。这种认证过程构成了系统安全的第一道防线，对于保护服务不被非法利用至关重要。 （5） 访问权限控制：授权管理涉及对Web服务访问权限的严格控制，以防止未授权用户访问敏感服务。通过实施细粒度的授权策略，可以确保只有经过授权的用户或服务才能访问特定的Web服务，从而维护系统的安全性和稳定性。
（6）身份信息管理：在SOA架构中，身份信息管理对于确保服务请求者和服务提供者之间的信任关系至关重要。与传统系统相似，SOA架构也需要有效管理服务请求者和服务提供者的身份信息，以防止身份冒充和数据篡改等安全风险。通过集中管理和验证身份信息，可以增强系统的整体安全性。

SSM 框架

Spring 是一个轻量级的企业级应用开发框架，于 2004 年由 Rod Johnson 发布了 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+SpringMVC+MyBatis整合的框架组件图如下所示：

软件需求到架构的映射的难点

在软件开发过程中，软件需求和软件架构是两个至关重要的组成部分，但它们之间确实存在一些明显的差异和挑战。

首先，软件需求通常以非正规的自然语言形式频繁获取，这主要是因为需求往往来源于业务用户、产品经理或利益相关者，他们习惯于使用日常语言和概念来表达他们的期望和需要。而软件架构则更倾向于使用一种更为正式、结构化的语言来描述系统的组件、接口、通信和交互方式。这种语言差异可能会导致在理解和沟通上的障碍。

其次，非功能属性（如性能、安全性、可用性等）在软件需求中通常被描述为系统属性，但在架构模型中形成规约却较为困难。这是因为非功能属性往往涉及多个系统组件和交互，需要综合考虑多个方面，而架构模型则可能更侧重于描述系统的结构和功能。因此，如何在架构中准确、全面地描述非功能属性是一个挑战。

最后，从软件需求映射到软件架构的过程中，保持一致性和可追溯性也是一个复杂且困难的任务。由于单一的软件需求可能涉及多个软件架构的关注点，而一个架构元素也可能对应多个软件需求，因此确保它们之间的映射关系是准确且可追溯的非常重要。这需要采用适当的需求管理和架构设计技术，以确保需求和架构之间的紧密联系和对应关系。

MQTT协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（publish/subscribe）模式的“轻量级”通讯协议，该协议构建于TCP/IP协议上，由IBM在1999年发布。MQTT最大优点在于，可以以极少的代码和有限的带宽，为远程连接设备提过实时可靠的消息服务，作为一种低开销、低带宽占用的即时通讯协议，使其在物联网、小型设备、移动应用等方面有较广泛的应用。MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。MQTT协议是轻量、简单、开放和易于实现的，这些特点使它适用范围非常广泛。

安全架构章节

加密技术为在网络中传输的数据提供机密性与完整性保障

对称加密策略

（1） 机密性：发送者利用对称密钥对要发送的数据进行加密，只有拥有相同密钥的接收者才能将数据正确解密，从而提供机密性保障。
（2）完整性：发送者根据要发送的数据生成消息认证码（或消息摘要），利用对称密钥对消息认证码进行加密并附加到数据上发送；接收者使用相同密钥将对方发送的消息认证码解密，并根据接收到的数据重新生成消息认证码，比较两个认证码是否相同以验证数据的完整性。

公钥加密策略

（1） 机密性：发送者利用接收者的公钥对要发送的数据进行加密，只有拥有对应私钥的接收者才能将数据正确解密，从而提供机密性保障。
（2） 完整性：发送者根据要发送的数据生成消息认证码（或消息摘要），利用自己的私钥对消息认证码进行加密并附加到数据上发送；接收者利用对方的公钥将对方发送的消息认证码解密，并根据接收到的数据重新生成消息认证码，比较两个认证码是否相同以验证数据的完整性。

信息系统面临的安全威胁

信息系统面临的安全威胁来自于物理环境、通信链路、网络系统、操作系统、应用系统以及管理等多个方面。

物理安全威胁是指对系统所用设备的威胁，如自然灾害、电源故障、数据库故障和设备被盗等造成数据丢失或信息泄漏。

通信链路安全威胁是指在传输线路上安装窃听装置或对通信链路进行干扰。

网络安全威胁当前主要是指由于因特网的开放性、国际性与无安全管理性，对内部网络形成的严重安全威胁。

操作系统安全威胁指的是操作系统本身的后门或安全缺陷，如“木马”和“陷阱门”等。

应用系统安全威胁是指对于网络服务或用户业务系统安全的威胁，包括应用系统自身漏洞，也受到“木马”的威胁。

管理系统安全威胁指的是人员管理和各种安全管理制度。

信息安全包括5个基本要素

安全模型

（1） BLP 模型：Bell-LaPadula 模型是符合军事安全策略的计算机安全模型，简称 BLP 模型。BLP 模型的安全规则如下：

简单安全规则：安全级别低的主体不能读安全级别高的客体；

星属性安全规则：安全级别高的主体不能往低级别的客体写；

强星属性安全规则：不允许对另一级别进行读写；

自主安全规则：使用访问控制矩阵来定义说明自由存取控制。

（2）Biba模型：BiBa模型主要用于防止非授权修改系统信息，以保护系统的信息完整性。该模型同BLP模型类似，采用主体、客体、完整性级别描述安全策略要求。BiBa模型能够防止数据从低完整性级别流向高完整性级别，其安全规则如下：

星完整性规则：表示完整性级别低的主体不能对完整性级别高的客体写数据； 简单完整性规则：表示完整性级别高的主体不能从完整性级别低的客体读取数据； 调用属性规则：表示一个完整性级别低的主体不能从完整性级别高的客体调用程序或服务。

（3）Chinese Wall模型：Chinese Wall模型的安全策略的基础是客户访问的信息不会与当前他们可支配的信息产生冲突。其访问客体控制的安全规则如下：

与主体曾经访问过的信息属于同一公司数据集合的信息，即墙内信息可以访问； 属于一个完全不同的利益冲突组的可以访问； 主体能够对一个客体进行写的前提是主体未对任何属于其他公司数据集进行过访问。 定理1：一个主体一旦访问过一个客体，则该主体只能访问位于同一公司数据集的客体或在不同利益组的客体。 定理2：在一个利益冲突组中，一个主体最多只能访问一个公司数据集。

WPDRRC模型包括6个环节和3大要素

6个环节包括：预警、保护、检测、响应、恢复和反击。模型蕴涵的网络安全能力主要是预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。

被动攻击和主动攻击

被动攻击：收集信息为主，破坏保密性。

主动攻击：主动攻击的类别主要有：中断（破坏可用性），篡改（破坏完整性），伪造（破坏真实性）。

区块链的特点

去中心化：由于使用分布式核算和存储，不存在中心化的硬件或管理机构，任意节点的权利和义务都是均等的，系统中的数据块由整个系统中具有维护功能的节点来共同维护。 开放性：系统是开放的，如：区块链上的【交易信息是公开的】，不过【账户身份信息是高度加密的】。 自治性：区块链采用基于协商一致的规范和协议（比如一套公开透明的算法），使得整个系统中的所有节点能够在信任的环境自由安全的交换数据，使得对“人”的信任改成了对机器的信任，任何人为的干预不起作用。 安全性（信息不可篡改）：数据在多个结点存储了多份，篡改数据得改掉 $51%$ 结点的数据，这太难。同时，还有其它安全机制，如：比特币的每笔交易，都由付款人用私钥签名，证明确实是他同意向某人付款，其它人无法伪造。 匿名性（去信任）：由于节点之间的交换遵循固定的算法，其数据交互是无需信任的（区块链中的程序规则会自行判断活动是否有效），因此交易对手无须通过公开身份的方式让对方对自己产生信任，对信用的累积非常有帮助。

抵御 SQL 注入攻击的方式

SQL注入攻击，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

可以通过以下方式抵御 SQL 注入攻击：

（1） 使用正则表达式；
（2） 使用参数化的过滤性语句;
（3） 检查用户输入的合法性；
（4） 用户相关数据加密处理；
（5） 存储过程来执行所有的查询;
（6） 使用专业的漏洞扫描工具。

安全威胁

信息物理系统（CPS）的安全性对于其可靠运行至关重要，特别是在宇航系统这样高度敏感和关键的应用领域。在研制安全可靠的CPS时，我们必须深入分析系统各层次可能面临的安全威胁。

（1） 首先，我们来看感知层。感知层主要存在以下安全威胁：

感知数据破坏：攻击者可能通过篡改传感器数据来影响系统决策。 信息窃听：未经授权的实体可能监听传感器与控制器之间的通信，窃取敏感信息。 节点捕获：攻击者可能物理捕获传感器节点，获取存储在其中的敏感数据。 被旁路：攻击者可能绕过正常的数据处理流程，直接对系统造成影响。

（2） 接下来是网络层。网络层主要存在以下安全威胁：

拒绝服务攻击 （DoS）：攻击者通过发送大量无效请求来耗尽系统资源，导致正常服务不可用。 选择性转发：攻击者可能只转发部分数据，影响系统决策。 方向误导：攻击者可能伪造或篡改路由信息，导致数据包被发送到错误的目的地。

（3） 最后是控制层。控制层主要存在以下安全威胁：

用户隐私泄露：系统可能不当地存储或传输用户的敏感信息。 恶意代码：攻击者可能通过注入恶意代码来篡改系统决策或窃取数据。 非授权访问：未经授权的实体可能访问控制层并影响系统决策。

危险驱动的安全分析过程

在危险驱动的安全分析过程中，通常包含以下四个步骤：

（1） 危险识别：此步骤的目标是确定系统中可能存在的所有危险。它涉及对系统的深入理解，包括其运行环境、操作模式、潜在故障模式等。通过分析系统各个组成部分的功能和相互作用，以及它们可能引发的危害，来识别出潜在的危险。
（2）风险分析：在识别出危险之后，需要对每个危险进行风险分析。这包括评估危险发生的可能性（概率）以及如果发生将造成的后果（严重性）。通过综合考虑这两个因素，可以确定每个危险的风险等级，从而确定哪些危险需要优先关注和处理。
（3）安全需求制定：基于风险分析的结果，需要制定安全需求。这些需求旨在防止或减轻已识别的危险及其潜在后果。安全需求应该具体、明确，并能够指导系统的设计和实现。它们可能包括各种安全措施、故障处理策略、系统冗余设计等。
（4）安全需求验证：最后一步是验证安全需求是否得到有效满足。这通常涉及对系统进行测试、仿真或实际运行，以确保其符合安全需求的要求。验证过程可能包括检查系统的故障响应、冗余功能、数据完整性等方面，以确保系统能够在各种情况下保持安全。

数据库设计章节

常见的反规范化技术

（1） 增加冗余列：增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。
（2） 增加派生列：增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量，从而加快查询速度。
（3） 重新组表：重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。
（4） 分割表：有时对表做分割可以提高性能。

针对反规范化数据不一致问题，可采用的解决方案包括

（1） 触发器数据同步。
（2） 应用程序数据同步。
（3） 批处理同步。

故障恢复

（1） 冷备份也称为静态备份，是将数据库正常关闭，在停止状态下，将数据库的文件全部备份（复制）下来。
（2） 热备份也称为动态备份，是利用备份软件，在数据库正常运行的状态下，将数据库中的数据文件备份出来。
（3） 完全备份：备份所有数据。
（4） 差量备份：仅备份上一次完全备份之后变化的数据。
（5） 增量备份：备份上一次备份之后变化的数据。
（6） 日志文件：事务日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。

关系数据库和 NoSQL 的对比

布隆过滤器的工作原理和优缺点

布隆过滤器通过一个很长的二进制向量和一系列随机映射函数来记录与识别某个数据是否在一个集合中。如果数据不在集合中，能被识别出来，不需要到数据库中进行查找，所以能将数据库查询返回值为空的查询过滤掉。

优点：

（1） 占用内存小
（2） 查询效率高
（3） 不需要存储元素本身，在某些对保密要求比较严格的场合有很大优势

缺点：

（1） 有一定的误判率，即存在假阳性，不能准确判断元素是否在集合中。
（2） 不能获取元素本身
（3） 一般情况下不能从布隆过滤器中删除元素

读写分离与主从复制

读写分离：主数据库负责“写操作”，从数据库负责“读操作”，根据压力情况，从数据库可以部署多个提高“读”的速度，数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据，业务服务器将写操作发给数据库主机，将读操作发给数据库从机。

主从复制的定义：

主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库。在复制过程中，一个服务器充当主服务器，而另外一台服务器充当从服务器。当一台从服务器连接到主服务器时，从服务器会通知主服务器从服务器的日志文件中读取最后一次成功更新的位置。然后从服务器会接收从哪个时刻起发生的任何更新，然后锁住并等到主服务器通知新的更新。

主从复制的基本步骤：

（1） 主服务器将所做修改通过自己的 I/O 线程, 保存在本地二进制日志中;
（2）从服务器上的I/O线程读取主服务器上面的二进制日志，然后写入从服务器本地的中继日志；
（3） 从服务器上同时开启一个 SQL thread，定时检查中继日志，如果发现有更新则立即把更新的内容在本机的数据库上面执行一遍。

主从复制优点

1、提升性能:交易平台要求高并发，主从复制方式一主多从，不同的用户请求可以从不同的从数据库读取数据，提高并发度。 2、可扩展性更优:如果采用单台数据库服务器，则访问量持续增加时，数据库瓶颈暴露，且无法迅速解决问题。 而主从结构可以快速增加从服务器数量，以满足需求。 3、提升可用性:一主多从，一台从服务器出现故障不影响整个系统正常工作。 4、相当于负载均衡:一主多从分担任务，相当于负载均衡。 5、提升数据安全性:系统中的数据冗余存放多份，不会因为某台机器硬件故障而导致数据丢失。

数据访问层实现技术对比

MongoDB 存储空间矢量要素的方式与优点

MongoDB 可以使用多种方式存储空间矢量要素。一种常见的方法是将要素的几何信息（如点、线、面等）存储为 GeoJSON 格式的文档，并将其他属性信息存储在该文档的字段中。另一种方法是使用 GeoHash 算法将空间矢量数据转换为字符串，并将该字符串作为索引存储在 MongoDB 的集合中。这样可以快速地进行空间查询和索引。

采用 MongoDB 存储空间矢量要素的优点有：

灵活性：MongoDB能够存储非结构化的数据，并且可以根据要求进行动态调整和扩展，适应不同规模和类型的数据要求。

查询和索引效率：MongoDB 可以使用内建的地理空间查询和索引功能，能够高效地进行空间数据的查询和分析，从而提升系统的检索性能。

分布式部署：MongoDB支持分布式的部署架构，可以将数据在多个节点上分布存储，提高系统的可用性和容错性。

数据可视化：MongoDB可以与常见的地理信息系统（GIS）工具集成，将存储的空间矢量数据可视化展示，便于用户进行数据分析和决策。

常见的数据访问层设计技术

（1） 在线访问: 该模式是基本的数据访问模式, 在软件系统中不存在专门的数据访问层, 由业务程序直接读取数据, 与后台数据源进行交互。
（2）Data Access Object：DAO模式是标准J2EE设计模式之一，该模式将底层数据访问操作与高层业务逻辑分离开。具体的DAO类包含访问特定数据源数据的逻辑。
（3） Data Transfer Object: DTO 是经典 EJB 设计模式之一。DTO 本身是一组对象或是数据的容器, 它需要跨越不同进程或者网络的边界来传输数据。这类对象通常本身不包括具体的业务逻辑, 对象内部仅进行一些诸如内部一致性检查和基本验证之类的方法。
（4） 离线数据模型：是以数据为中心，数据从数据源获取后，将按照某种预定义的结构（如IBM SDO的Data图表结构或ADO.NET中的关系结构）存放在系统中，成为应用的中心。其特点是：①离线，数据操作独立于后台数据源；②与XML集成，数据可以方便地与XML格式文档相互转换。
（5） 对象/关系映射 （Object/Relation Mapping): ORM 是一种工具、中间件或平台, 它能够帮助将应用程序中的数据转换成关系数据库中的记录; 或者是将关系数据库中的记录转换成应用程序中代码便于操作的对象, 使得程序员在开发过程中仅仅面对一个对象的概念, 降低了对程序员数据库知识的要求, 简化了数据库相关的开发工作。

分布式数据库缓存技术

分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。

数据库和缓存数据不一致

关于数据同步的潜在问题，当执行写入操作时，存在一种称为双写不一致的隐患。具体而言，有时我们可能遇到缓存写入成功但数据库写入失败，或者数据库写入成功而缓存更新失败的情况，这会导致数据在两个存储系统之间出现不一致。此外，当多个请求同时发生时，还可能出现读写冲突的并发问题，这进一步增加了数据一致性的挑战。

解决方案：

（1） 异步队列方式同步，可采用消息中间件处理：此方案利用消息中间件（如 Kafka）来确保数据的一致性。当线程 1 更新数据库后，会发送一个消息到消息队列中。线程 2 或另一个消费者线程会监听这个队列，并在收到消息后执行相应的缓存更新或删除操作。
（2）通过数据库插件完成数据同步：一些数据库插件或工具（如MySQL的binlog监听工具）可以监听数据库的更新操作，并在数据发生变化时自动更新缓存。
（3）利用触发器进行缓存同步：在数据库中设置触发器，当数据表发生INSERT、UPDATE或DELETE操作时，触发器会自动执行相应的缓存更新或删除操作。
（4） 锁机制。比如: 通过引入读写锁机制, 可以确保在数据更新时, 没有其他线程可以读取数据。这可以防止线程 2 在线程 1 更新数据库时读取到旧数据。在数据更新完成后, 再释放读锁, 允许其他线程读取数据。

缓存中key大量失效解决办法

(1)缓存失效后，大量的缓存更新操作进行排队。这种方案确实可以通过排队和串行化缓存更新操作来降低瞬时请求量，但它并没有解决大量kev值同时失效的根本问题。此外，串行化操作可能会降低系统的整体性能。 (2)给不同key设置随机或不同的失效时间。这是一种更为根本的解决方案，通过分散失效时间，可以有效避免大量key值同时失效的情况。这可以显著减少数据库服务器的瞬时压力，并提高系统的稳定性。 (3)设置两级或多级缓存。虽然多级缓存可以提高系统的缓存命中率，但它并没有直接解决大量key值同时失效的问题。如果所有级别的缓存都发生了失效，那么仍然会面临同样的挑战。

逻辑数据模型设计过程包含的任务

（1） 构建系统上下文数据模型，包含实体及实体之间的联系；
（2） 绘制基于主键的数据模型，为每个实体添加主键属性；
（3） 构建全属性数据模型，为每个实体添加非主键属性；
（4） 利用规范化技术建立系统规范化数据模型。

2PC的含义

1、两阶段提交协议2PC经常用来管理分布式事务。 (1)2PC包含协调者和参与者两类站点，只有协调者才拥有提交或撤销事务的决定权，而其他参与者各自负责在其本地数据库中执行写操作，并向协调者提出撤销或提交事务的意向。 (2)2PC分为两个阶段:表决阶段和执行阶段。 ①表决阶段，目的是形成一个共同的决定。协调者给所有参与者发送“准备提交"消息，并进入等待状态，所有参与者给与回复"建议提交”或“建议撤销”。只要有一个结点选择撤销，则整体事务撤销，否则，执行该事务。 ②执行阶段，目的是实现这个协调者的决定。根据协调者的指令，参与者或者提交事务，或者撤销事务，并给协调者发送确认消息。

2、两阶段提交协议2PC不能解决当前问题。 (1)分布式数据库遵循的是CAP 原则，会在一定程度上牺牲一致性。 (2)大多数 NoSQL 数据库并不支持 2PC。 (3)分布式两阶段提交协议2PC一般针对的对象在逻辑上是一个整体，对某一个整体事务需要在多个物理节点上执行时，进行表决和执行，对多个数据库的不同服务并不是很合适。

子类与超类实体

当较低层次上实体类型表达了与之联系的较高层次上的实体类型的特殊情况时，就称较高层次上实体类型为超类型，反之为子类型。子类到超类的过程为概化，超类到子类的过程为特化。

（1） 子类与超类之间具有继承特点，即子类包含了超类的所有属性，并且可以比超类拥有更多的属性。
（2） 这种继承性是通过子类实体和超类实体有相同的实体标识符实现的。

Redis 数据类型

基于Redis实现分布式锁

基于Redis的分布式锁主要利用Redis的原子性操作和键值过期机制实现资源的互斥访问，主流实现方式有两种：单节点锁（SET NX PX）和多节点容错锁（RedLock）。

优点：

（1） 高性能: Redis 基于内存操作, 读写速度极快 （微秒级响应）, 适合高并发场景。单节点锁的加锁操作复杂度为 $O（1）$ 。
（2）原子性保障：SETNXPX命令的原子性确保加锁与设置过期时间一步完成，避免竞态条件。
（3）自动过期防死锁：锁的自动过期机制（如30秒）防止客户端崩溃导致的死锁，无需手动清理。
（4） 支持分布式与高可用：RedLock 算法通过多节点容错提升可靠性，适用于 Redis 集群或哨兵模式。
（5）可重入锁支持：可通过记录客户端标识和重入计数实现可重入锁（需自行编码）。

缺点：

（1） 单点风险 （单节点锁）: 单Redis实例宕机时锁失效, 可能引发多个客户端同时持有锁。
（2）时钟漂移问题（RedLock）多节点间时钟不同步可能导致锁提前过期，破坏互斥性。
（3） 锁续期复杂性：若业务处理时间超过锁的过期时间，需通过“看门狗”机制（如定时任务）续期锁，实现复杂。

基于Redis的ZSet实现延迟队列

基于Redis的ZSet（有序集合）实现延迟队列是一种常见的解决方案，其核心原理是通过有序集合的排序特性管理任务的延迟执行时间。

优点：

（1） 高性能：ZSet 基于内存操作，读写速度快，适合高并发场景。有序集合的排序复杂度为 $O（\log N）$ ，查询效率高。
（2） 灵活性：支持任意时间精度的延迟任务（如秒级、毫秒级），无需预定义延迟级别。可动态调整任务执行时间（通过更新Score）。
（3） 分布式支持：Redis集群模式可横向扩展，提升队列容量和消费能力。
（4） 持久化与可靠性: Redis 支持 RDB 和 AOF 持久化, 防止任务因宕机丢失。
（5） 实现简单：无需引入额外中间件（如 RabbitMQ、Kafka），依赖 Redis 即可快速搭建。

缺点：

（1） 轮询开销：消费者需持续轮询ZSet，可能占用较多CPU和网络资源，尤其在低负载时效率较低。
（2） 无ACK机制：若任务处理失败或消费者宕机，可能导致任务丢失（需自行实现重试或补偿机制）。
（3） 重复消费风险：若处理任务后未及时删除ZSet中的成员，可能被重复拉取。
（4） 时间精度依赖Redis轮询频率：实际执行时间可能因轮询间隔（如1秒）产生误差，无法实现严格精确的延迟。
（5） 内存限制：Redis是内存数据库，大量延迟任务可能导致内存压力，需合理控制队列长度或结合冷热数据分层。
（6） 缺乏原生重试机制：需自行实现失败任务的重试逻辑（如重新设置 Score 并放回队列）。

Redis分片方式

1）基于属性范围分片，数据分布不均匀 2）基于哈希值分片，会均匀一些 3）一致性哈希。通过哈希环机制，增设了很多虚拟结点，再映射到物理结点，所以扩展结点时，不必像哈希分片那样对所有数据重新分配结点。只需要将部分数据做重新调整。

E-R图

E-R模型（Entity-Relationship Model）是一种用于数据库设计的概念模型。它提供了一种描述现实世界中数据组织和关联的图形化方法，用于表示实体、属性和联系之间的关系。

E-R图的构成：

（1） 实体 （Entity）: 实体表示现实世界中的一个独立对象, 可以是人、物、地点、概念等。在 E-R 图中, 实体用矩形框表示, 框内写上实体的名称。
（2） 属性（Attribute）：属性是描述实体特征的信息。每个实体可以有多个属性，例如一个人实体可以有姓名、年龄、性别等属性。属性以椭圆形状表示，并与相应的实体相连。其中能够唯一标识实体的属性称为主键。
（3） 关系 （Relationship）: 关系表示实体之间的相互作用或联系。关系可以是一对一、一对多或多对多的。在 E-R 图中, 关系用菱形表示, 并与相关的实体相连。关系还可以具有属性, 用于描述与关系相关的信息。

主键 （Primary Key）: 用于唯一标识实体的属性, 通常在实体框内用下划线或加粗表示。主键属性的值在整个实体集合中必须是唯一的, 用于区分不同的实体。

在E-R图中，根据实体之间的连接方式和关系类型，关联关系可以分为以下几种类型：

（1） 一对一（One-to-One）关联：一个实体实例与另一个实体实例之间存在唯一的关联关系。这种关系表示为一个实体的一个实例与另一个实体的一个实例相连接。
（2） 一对多（One-to-Many）关联：一个实体实例与另一个实体实例之间存在一对多的关联关系。这种关系表示为一个实体的一个实例与另一个实体的多个实例相连接。
（3） 多对多（Many-to-Many）关联：多个实体实例与另一个实体实例之间存在多对多的关联关系。这种关系表示为一个实体的多个实例与另一个实体的多个实例相连接。

数据流图和数据字典在软件需求分析和设计阶段的作用

（1）在软件需求分析阶段：

数据流图主要用于建立软件的功能模型，以图形化方式呈现业务数据的流动和处理过程。

数据字典是关于数据的信息集合，用于对数据流图中每个组成部分加以定义和说明。

（2）在软件设计阶段：

数据流图为模块划分与模块之间接口设计提供依据，数据流图主要用于经过一系列设计转换后，产生由模块图表示的软件设计模型；详细设计阶段数据流图可进行模块内部的数据流设计。

数据字典用于描述系统中各类数据，为数据库概要设计、逻辑设计提供支持。

MongoDB 如何存储空间矢量要素以及存储空间矢量要素的优点

MongoDB 可以使用多种方式存储空间矢量要素。一种常见的方法是将要素的几何信息（如点、线、面等）存储为 GeoJSON 格式的文档，并将其他属性信息存储在该文档的字段中。另一种方法是使用 GeoHash 算法将空间矢量数据转换为字符串，并将该字符串作为索引存储在 MongoDB 的集合中。这样可以快速地进行空间查询和索引。

采用 MongoDB 存储空间矢量要素的优点有：

（1） 灵活性：MongoDB 能够存储非结构化的数据，并且可以根据要求进行动态调整和扩展，适应不同规模和类型的数据要求。
（2）查询和索引效率：MongoDB可以使用内建的地理空间查询和索引功能，能够高效地进行空间数据的查询和分析，从而提升系统的检索性能。
（3）分布式部署：MongoDB支持分布式的部署架构，可以将数据在多个节点上分布存储，提高系统的可用性和容错性。
（4） 数据可视化：MongoDB 可以与常见的地理信息系统（GIS）工具集成，将存储的空间矢量数据可视化展示，便于用户进行数据分析和决策。

基于数据库实现分布式锁

基于数据库的分布式锁主要利用数据库的事务和唯一性约束特性来实现资源的互斥访问，常见的实现方式有两种：

（1） 基于唯一索引的锁表
（2） 基于行级锁

优点：

（1） 依赖简单：仅需数据库支持，无需引入额外中间件（如Redis、ZooKeeper），适合已有数据库且规模较小的系统。
（2） 强一致性保障：数据库的ACID特性（尤其是事务隔离级别）可保证锁操作的原子性和一致性。
（3） 实现直观：通过唯一索引或行级锁即可实现，逻辑简单，易于理解。 （4） 持久化可靠：锁记录存储在数据库中，即使服务重启，锁状态不会丢失。

缺点：

（1） 性能瓶颈：数据库的 I/O 性能较低，高并发场景下频繁的锁竞争可能导致吞吐量下降。基于行级锁的实现会阻塞其他事务，可能引发死锁或长时间等待。
（2） 死锁风险：若客户端获取锁后崩溃，未及时释放锁（如未删除记录或未提交事务），会导致锁长期占用。
（3） 锁释放的复杂性：必须严格保证锁的释放逻辑（如 DELETE 操作或事务提交），否则会导致资源不可用。
（4） 主从延迟问题：在数据库主从架构中，若主库写入成功但从库未同步，其他客户端可能读到过期的锁状态，导致锁失效。
（5）无法实现可重入锁：需要额外逻辑（如记录锁持有者及重入次数）才能支持同一客户端的重复加锁。

基于数据热度的HDFS动态存储策略

基于数据热度的HDFS动态存储策略是一种根据数据访问频率和时效性，自动调整数据存储位置和副本管理的智能方案。其核心目标是在保证高频访问数据性能的同时，降低低频数据的存储成本。

数据热度是对数据访问频率和时效性的量化指标，通常分为三类：

（1） 热数据 （Hot）: 近期频繁访问 （如每日多次访问）, 需要高性能存储和快速响应。
（2） 温数据（Warm）：访问频率中等（如每周几次），平衡性能和成本。
（3） 冷数据（Cold）：长期无访问（如数月未读），适合低成本归档存储。

动态存储策略的核心思想有：

（1） 分层存储：将不同热度的数据分配到不同性能的存储介质（如 SSD、HDD、磁带）。
（2） 动态迁移：根据数据热度的变化，自动将数据在不同存储层之间迁移。
（3） 副本优化：热数据保留多副本以提高并发能力，冷数据减少副本或使用纠删码节省空间。

未来信息技术章节

大数据特点

4个V：大规模（Volume）、高速度（Velocity）、多样化（Variety）、价值密度低（Value）。

【真实性 （Veracity）】

Lambda 架构

批处理层 （Batch Layer）：两个核心功能：存储数据集和生成 Batch View。 加速层 （Speed Layer）: 存储实时视图并处理传入的数据流, 以便更新这些视图。 服务层（Serving Layer）：用于响应用户的查询请求，合并Batch View和Real-time View中的结果数据集到最终的数据集。

Kappa 架构

Kappa 架构与 Lambda 的对比

边缘计算

边缘计算模型区别于传统的云计算模型、网格计算模型、分布式计算等模型，是一种新型的计算模型。

（1） 从资源配置看 边缘计算是调动全局的资源为其所用，是集中心侧、边缘侧资源整合整体优势进行相应的处理，完成全局的最优。也就是说，边缘计算并不是孤立的计算模型，需要整体考虑资源的配置和调度。

（2） 从协同模式看 边缘计算具备中心侧和边缘侧两方的资源，因此需要进行协同，本地能处理好的事情，就近处理，解决不了的事情交予中心侧或其他协同方的资源进行处理。因此，边缘计算模型是一种协同计算模型，与各个边缘侧、中心侧都有关联，需要统一的协调和资源调配，达到资源利用的最大化。

（3） 从智能程度看 边缘计算需要优势互补，需要协同并进、需要感知用户场景、需要优化配置资源，而这些势必需要机器智能，因此边缘计算涵盖一种智能化的、自动化的资源配置方式。事前简单的用户配置、参数定义，不能有效满足用户侧的效用需求。用户侧需要实时地感知配置资源，以便就近提供高带宽、高可靠、高性能的服务。

（4） 从体系结构看 边缘计算是在靠近网络边缘侧大规模部署智能终端设备，和传统的云、网、端三层模型具有一致性，但是亦有区别。原因在于，云、网、端只是基础设施的布局，是静态的一种结构，而边缘计算本质是一种动态的、自动化的资源配置方式，从而区别于以上静态结构。更确切的讲，边缘计算是云、网、端、智四位一体的模型，智能纵向涵盖云、网、端，从上到下均涵盖。因此边缘计算是一种具备智能的云、网、端结构，智能化是其重要的特征之一。

（5） 从异构处理看 参与边缘计算的设备众多，设备的异构是边缘计算的一大特征。传统的云计算往往通过设备的虚拟化、形成众多的虚拟机来进行统一管理。而边缘计算的设备异构型不能简单的虚拟化来解决，其复杂程度要远远高于云计算。例如：不同类型、不同指标、不同参数、不同用途、不同厂商、不同功能的设备需要互联，需要统一处理相应的问题。设备间的互联互通将是边缘计算模型中不可或缺的组成部分，是目前该技术面临的一大挑战。

（6） 从服务模式看 云计算具有三层服务模式，即：IaaS、PaaS、SaaS，而边缘计算将对此模式进行改变或补充。边缘计算不具有典型的三层模式，边缘计算无需统一屏蔽底层的差异，而是根据应用需求进行把控。边缘计算模型需要考虑问题是如何和云计算三层模型进行有效的对接和协同，而不是进行统一。因此，边缘计算具有其差异性和特殊性，不是典型的三层服务模型。

人工智能章节

人工智能应用场景

人工智能技术应用开发

【技术与解决方案】

嵌入式系统设计章节

实时系统 （Real-Time System, RTS）

实时系统是指能够在指定或者确定的时间内完成系统功能和外部或内部、同步或异步时间做出响应的系统。也就是说，系统计算的正确性不仅取决于程序的逻辑正确性，也取决于结果产生的时间，如果系统的时间约束条件得不到满足，将会发生系统错误。

实时系统的特性：

（1） 时间约束性 （及时性）
（2） 可预测性
（3） 高可靠性
（4） 与外部环境的交互作用性
（5） 多任务类型
（6） 约束的复杂性
（7） 具有短暂超载的特点

机器人操作系统 （ROS）

机器人操作系统是一种专为机器人应用设计的软件框架，它集成了多种功能以支持机器人的开发和运行。首先，它提供了硬件抽象描述和底层驱动程序管理，使得开发者无需直接面对复杂的硬件细节，从而简化了开发过程。其次，它执行公用功能，如资源管理、任务调度等，以确保系统的稳定运行。

在机器人操作系统中，程序间的消息传递机制是另一个关键特性。它允许不同的程序组件之间高效地进行通信，确保机器人能够协同工作并快速响应各种任务。此外，系统还提供了程序算法包管理功能，使得开发者可以方便地管理和使用各种算法包，以优化机器人的性能。

除了上述功能外，机器人操作系统还配备了一系列工具和库，这些工具和库为开发者提供了强大的支持。它们可以帮助开发者获取、建立、编写和运行多机整合的程序，从而实现机器人之间的协同作业。此外，这些工具和库还可以用于创建各种机器人应用程序，满足不同领域的需求。

机器人操作系统中采用的多节点跨平台模块化通信机制，为机器人应用程序的开发和运行提供了高效、灵活的基础。它用节点（Node）的概念表示一个任务，不同节点之间通过事先定义好的格式来实现消息通信，应用程序间具备主题（Topic）、服务（Service）和动作（Action）三类通信。

（1） 主题：主题是一种发布/订阅模式的通信方式。节点通过发布消息到特定的主题，其他订阅了该主题的节点就能接收到这些消息。
（2） 服务：服务是一种请求/响应模式的通信方式。客户端节点发送请求到服务端节点，并等待响应。
（3） 动作（action）是ROS提供应用程序间通信的一种较简单的方式，一般用于对某个事件、某个进程以及某个数据状态的监控，如：它可以监控长时间执行的进程。但是，从动作机制上看，设立监控机制比较复杂，需要应用程序间有握手信号。

ROS架构是由多个各自独立的节点（组件）组成，并且各个节点之间可以通过发布/订阅（publish/subscribe）消息模型进行通信。例如，我们将一个特定传感器的驱动模块作为一个ROS节点，其将传感器数据发布（publish）到消息流。这些消息可能会被某些节点获取到，例如滤波器、记录器、更高级系统中的应用如导航、路径查找等节点。

通常，ROS启动于ROSMaster。Master允许其他ROS中不同软件片（节点）查找对方或与对方交流。那样，我们就不必指定“发送传感器数据到IP为127.0.0.1的电脑”，我们只需要简单地告诉Node1发送消息到Node2。就是说，ROS节点间的数据通信都是以透明方式进行的。

嵌入式实时系统简单任务和复杂任务的特征区分

简单任务和复杂任务的特征区分主要表现为以下十个方面：

（1） 静态/动态特性：简单任务的时序关系是确定不变的，不会随时间偏移而变化。而随着复杂系统任务多样化发展，复杂任务将会随着时间、状态变化而变化。
（2）连续性/非连续性：简单任务仅仅考虑变量的随机性，而不考虑数据的继承性。而复杂任务由于受环境影响，其变量域需要考虑时间上的连续特性，及数据的继承关系。
（3）系统间的独立性：简单任务由于功能单一，仅仅需要考虑内部任务间交联关系，具备独立性。而复杂任务间有很高的交互操作，要把一个任务的行为隔离开是非常困难的。
（4） 顺序/并行性：简单任务由于功能单一、时序简单，通常情况下任务是顺序执行的，缺少并行性。而复杂任务功能、状态复杂，其属性与时间紧密相关，必然存在许多并行执行因子，并行性强。
（5） 单一/混合性：简单任务由于功能单一，其内部算法、执行策略都是单一的、不会随状态变迁而改变。而由于复杂任务的多样化，其任务内会存在不同构型、策略和算法，甚至对于不同状态任务需要综合考虑影响因子后方能决策，其混合性比较强。
（6） 工作原理：简单任务执行时仅仅考虑上下因果关系，无需考虑结果。而复杂任务必须考虑根据上下文反馈信息来决策处理流程。
（7） 线性/非线性：简单任务执行的功能一般呈现线性关系，功能间的上下关系是线性的。而复杂任务必须考虑根据多个上下文功能的结果决策处理流程，是非线性的。
（8） 上下文相关性：简单任务由于功能简单并呈现线性特征，其功能原理必然与上下文无关。而复杂任务属于非线性特征，其功能原理必然与上下文相关。
（9） 规律/不规律：简单任务的特征是规则整齐、原则清晰。而复杂任务由于上下文相关，其规则与上下文存在关系，缺少规律性。
（10） 表面属性：简单任务对外特征明显，比较好识别。而复杂任务由于其多样化，其外表特征被覆盖或抽象，对外表现不明显，不好识别。

FACE架构

FACE架构由五个主要的服务段组成，每个服务段都扮演着特定的角色，以确保系统的高效、可靠和模块化运行。以下是这五个服务段的简要描述：

操作系统服务段：这是FACE架构的基础，负责提供操作系统、运行时环境和操作系统级的健康监控服务。它通过开放式OSGi框架，为上层功能提供标准化的操作系统接口，并支持上层组件的即插即用能力，使得系统的扩展和维护变得更为便捷。

I/O服务段：这个服务段主要负责对专用I/O设备进行抽象，以简化平台服务段软件与硬件设备之间的交互。然而，由于图形服务软件和GPU处理器的紧密关系，I/O服务段并不对GPU驱动进行抽象，以确保图形处理的高效性和直接性。

平台服务段：此服务段提供了用户所需的共性软件服务，如系统级健康监控、配置管理、日志记录和流媒体服务等。它进一步细分为平台公共服务、平台设备服务和平台图像服务三类，以满足不同应用场景的需求。

传输服务段：作为数据传输的核心，该服务段主要为上层可移植组件段提供平台性的数据交换服务。它确保可移植组件之间通过标准接口进行通信，禁止组件间的直接调用，从而提高了系统的可移植性和互操作性。

可移植组件段：这是FACE架构中提供多组件使用能力和功能服务的部分。它主要包括公共服务和可移植组件两类，使得开发者能够基于这些组件快速构建和部署应用程序，同时确保这些应用程序在不同平台上的可移植性。

综上所述，FACE架构的五个服务段共同协作，为开发者提供了一个高效、可靠和模块化的软件开发环境。

应用程序的紧耦合和封装问题的主要表现与解决方案

紧耦合问题通常指的是系统中不同部分之间的高度依赖关系，这种依赖关系可能导致系统难以维护、扩展和测试。

（1） I/O 问题：当 I/O 操作（如文件读写、网络通信等）与业务逻辑紧密耦合时，任何 I/O 操作的更改都可能影响到整个业务逻辑，使得系统难以维护和扩展。
（2） 业务逻辑问题：如果业务逻辑与底层系统（如数据库、文件系统等）紧密耦合，那么在业务逻辑发生更改时，可能需要同时修改底层系统，这增加了系统的复杂性和维护成本。
（3） 表现问题：如果用户界面与业务逻辑紧密耦合，那么任何用户界面的更改都可能影响到业务逻辑，这限制了用户界面的灵活性和可定制性。

为了解决紧耦合问题，可以采用分离原则。这意味着将系统的不同部分（如I/O、业务逻辑、表现层等）进行隔离，使得它们之间的依赖关系尽可能少。通过定义明确的接口和协议，不同部分之间可以通过这些接口进行通信，而不需要直接访问对方的内部实现。

接下来，我们来看封装问题。封装是面向对象编程中的一个重要概念，它通过将对象的属性和方法隐藏起来，只提供必要的接口供外部调用，从而保护对象的内部状态和数据安全。然而，在某些情况下，封装可能会出现问题，如：

（1） ICD 硬编码问题：当接口控制文档（ICD）中的信息被硬编码到代码中时，任何 ICD 的更改都需要修改代码，这增加了系统的维护成本。 （2） 组件的紧耦合问题：如果组件之间的依赖关系过于紧密，那么一个组件的更改可能会影响到其他组件，导致系统难以维护和扩展。
（3） 直接调用问题：当组件之间直接调用彼此的接口时，如果接口发生变化，可能需要修改多个组件的代码，这增加了系统的复杂性。

为了解决封装问题，可以采用提供数据源或槽的软件服务的方法。这意味着将紧耦合的组件分解出应用程序，并将平台相关部分加入计算环境中。在计算平台内，提供数据源或槽的软件服务，这些服务可以封装底层系统的复杂性和变化性，为上层应用提供稳定、可靠的接口。同时，通过实现接口标准化，可以确保不同组件之间可以通过标准接口进行通信，降低了系统的复杂性和维护成本。

数据定义、数据分布、数据管理

数据定义在构建和管理数据系统中扮演着至关重要的角色。它不仅要反映业务模式的本质，确保数据架构能够满足业务需求的全面、一致和完整性，还要确保数据的高质量。数据定义的过程包括划分应用系统边界，这有助于明确各个系统之间的界限和交互方式；明确数据引用关系，这可以确保数据在系统中的正确流动和使用；以及定义应用系统间的集成接口，这对于实现系统间的无缝集成和数据共享至关重要。数据模型是数据定义的核心，它包括数据概念模型、数据逻辑模型、数据物理模型和数据标准。

数据分布是数据系统分布的基础，它涉及数据业务、数据分析和数据存储等方面。数据业务主要关注数据在业务各环节的创建、引用、修改或删除的关系；数据分析则侧重于在单一应用系统中分析数据结构与应用系统各功能间的引用关系，以及在多个系统间分析数据的引用关系；数据存储则包括分析数据集中存储和数据分布存储两种模式，需要根据实际需求选择适合的数据分布策略。

数据管理则是确保数据在整个生命周期中都能得到妥善管理的关键。它涵盖了数据模型与数据标准管理、数据分布管理、数据质量管理和数据安全管理等多个方面。通过制定这些管理制度，可以确保数据的准确性、完整性、可用性和安全性。同时，确定数据管理组织或岗位也是非常重要的，这可以确保有专门的人员负责数据的日常管理和维护。

心跳检测和超时探测技术

（1）心跳检测是分布式系统中常用的检测技术。是以固定的频率向其他节点汇报当前节点状态的方式。收到心跳，一般可以认为一个节点和现在的网络拓扑是良好的。如果在限定的一段时间（或超过某一门限值）没有收到心跳信息就被认为失效。心跳检测的主要特点是：原理简单，具有自适应、结构灵活性，具有可扩展性和健壮性。
（2）超时探测也是分布式系统中常用的检测技术。在整个分布式系统中为每个节点设计一种探针，探针会不断发送健康检查来检查服务是否健康。如果远程节点没有响应，则认为数据包在过程中的某个地方已丢失了，系统将重试或等待一段时间，直到超时。超时探测的主要特点是：适应大规模系统、具有高并发能力、具备可扩展性、具备容错能力。

基于定量分析的故障诊断方法

基于定量分析的故障诊断方法可以分为基于解析模型的方法和基于数据驱动的方法。

（1） 基于解析模型的方法通过被研究对象的数学模型和可观测输入输出量构造残差信号，在此基础上进行故障诊断。此类方法需要建立在精准数学模型的基础上，进行故障诊断。但是在实际中，复杂的系统难以精确建模，因此该类方法在实际应用中会有很大的局限。
（2） 基于数据驱动的方法通过对系统运行过程中的监测数据进行分析，从而在无精准系统数学模型情况下，对系统进行故障诊断，具体方法包括机器学习、统计分析法和信号分析法等等（数据驱动的方法是现有大量的数据，而不是预设模型，然后用很多简单的模型来契合数据。虽然通过这种方法找到的模型可能和真实模型存在一定的偏差，但是在误差允许的范围内，单从结果上和精确的模型是等效的）。对于宇航系统这种非常复杂的系统难以精确建模。

其他章节

提高系统可靠性采用的技术

可靠性（Reliability）是指产品在规定的条件下和规定的时间内完成规定功能的能力。

子特性：成熟性，容错性，易恢复性，可靠性的依从性。

提高可靠性的技术：

（1） N 版本程序设计
（2） 恢复块方法
（3） 防卫式程序设计
（4） 双机热备或集群系统
（5） 冗余设计

恢复块方法与 N 版本程序设计对比

要缩短项目的工期，主要的方法有

赶工：对成本和进度进行权衡，确定如何尽量少增加费用的前提下最大限度地缩短项目所需要的时间，称为赶进度也称赶工。

快速跟进：调整逻辑关系，通过对各种逻辑关系并行确定来缩短项目周期。在进行项目设计中，当风险不大时，通过精心安排而使项目的前后阶段相互搭接以加快项目进展速度的做法叫快速跟进。

TCP和UDP

TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP 之所以可靠，是因为建立连接时有 3 次握手，通信时有回应机制，所以丢了包，能重传以保障通信可靠性。

UDP 是一种面向无连接的传输层通信协议，丢了包不会重传，所以不能保障通信可靠性。

存储网络架构

一般来说，计算机访问磁盘存储有3种方式：

直连式存储（DirectAttachedStorage，DAS）：计算机通过I/O端口直接访问存储设备的方式。

网络连接的存储（Network Attached Storage，NAS）：计算机通过分布式文件系统访问存储设备的方式。

存储区域网络（Storage Area Network，SAN）：计算机通过构建的独立存储网络访问存储设备的方式。

其中SAN和NAS都可以用于集中管理存储，并供多主机（服务器）共享存储。但是，NAS通常是基于以太网，而SAN可使用以太网和光纤通道。此外，NAS注重易用性、易管理性、可扩展性和更低的总拥有成本（TCO），而SAN则注重高性能和低延迟。

软件定义网络架构

软件定义网络（Software Defined Network，SDN）：一种新型网络创新架构，其核心是将网络设备的控制面与数据面分离开来，从而实现了网络流量的灵活控制。

SDN架构如下所示，由下至上分为数据平面、控制平面和应用平面。

应用平面：在网络上运行的应用，用户无需关心底层细节就可编程、部署应用。

控制平面：包含了SDN控制器，它掌握着全局网络信息，是网络的“大脑”。

数据平面：交换机、路由器等物理硬件，单纯负责数据的转发。