反规范化设计方法？ 常见反规范化技术： 增加冗余列：在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作。 增加派生列：在表中增加可以由本表或其他表中数据计算生成的列，减少查询时的连接操作 并且避免计算或使用集合函数。 重新组表：如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个 表来减少连接而提高性能。 水平分割表：根据一列或多列数据值，把数据放到多个独立表中，主要用于表现数据规模很 大，表中数据相对独立或数据需要存放到多个介质上时使用。 垂直分表：对表进行分割，将主键和部分列放到一个表中，主键与其他列放到另外一个表中， 查询时减少IO的次数。 用户查询商品信息时可以采用增加冗余列的方式。
反规范化带来数据的不一致性问题？ 批处理维护：指对复制列或派生列的修改积累一定的时间后，运行一个批处理作业或存储过 程对复制或派生列进行修改，这只能对实时性要求不高的情况下使用。 应用逻辑：要求必须在同一个事务中对所有涉及的表进行增删改等操作。用逻辑来实现数据 的完整性风险较大，因为同一逻辑必须在所有的应用中使用和维护，容易遗漏，在需 求变化时，不易于维护。 触发器：对数据的任何修改立即触发对复制列或派生列的相应修改。触发器是实时的，易于 维护。
Redis 和MySQL 数据实时同步问题？
- 对强一致性要求比较高的，采用实时同步方案，即查询缓存查询不到再从DB查询，保存到 缓存；更新缓存时，先更新数据库，再将缓存的设置过期。
- 对于并发程序较高的，采用异步队列的方式同步，采用kafka等消息中间件处理消息生产 和消费。 3.使用阿里的同步工具canal，canal实现方式时模拟mysql slave和master的同步机制， 监控DB bitlog 的日志更新来触发缓存的更新。
- 采用UDF自定义函数的方式，对mysql的API 进行编程，利用触发器进行缓存同步。
Redis 数据库缓存数据类型？ String 类型： 常规的key/value List 类型：各类列表 SET类型： 各类列表，提供去重操作，提供集合操作。 HASH类型：存储部分变更数据。 ZSET 类型：存储部分变更数据提供自动排序，可实现带权重的队列。 如各类排行榜
Redis热键Key的处理方式： 1.使用本地缓存 2.数据分散存储 3.单独存储热Key 4.优化业务逻辑 5.读写分离
Redis 持久化方式RDB与AOF 的区别？ RDB： 在指定时间间隔内将内存中的数据集快照写入磁盘，默认持久化方式。 AOF：Redis 会将每一个收到的写命令都通过write函数追加到日志文件中。 磁盘更新频率： AOF比RDB 文件更新频率高。 数据安全： AOF比RDB更安全。 数据一致性：RDB间隔一段时间存储，可能发生数据丢失或不一致，AOF通过append 模式写文件，即使发生服务器宕机，也可以通过redis-check-aof 工具解决 数据一致性问题。 重启性能：RDB性能比AOF好 数据文件大小：AOF比RDB大。
Redis 选择定期删除+惰性删除策略，策略失效，三种内存淘汰机制？ 1.从已设置过期时间的数据集最近最少使用的数据淘汰 2.从已设置过期时间的数据集将要过期的数据淘汰 3.从已设置过期时间的数据集任意选择数据淘汰 4.从数据集最近最少使用的数据淘汰 5.从数据集任意选择数据淘汰。
MySQL主从复制的工作原理： MYSQL主从复制基于主从模型工作，其中主服务器（Master）负责处理写操作（INSERT、UPDATE、DELETE等），而从服务器（Slave） 则复制主服务器的数据变更。主服务器记录所有的写操作，并将这些操作以二进制格式写入到二进制日志（Binary Log）中。 从服务器连接到主服务器，并从其获取二进制日志文件，然后将这些日志应用到自身的数据上，以保持与主服务器数据的同步。
CPS 的三类威胁，举例说明？ 感知层安全威胁：感知数据破坏、信息窃听、节点捕获 网络层安全威胁：拒绝服务攻击、选择性转发、方向误导攻击 控制层安全威胁：用户隐私泄露、恶意代码、非授权访问。
反规范化： 技术手段： 增加派生性冗余列、增加冗余列、重新组表、分割表。 优点： 连接操作少，检索快、统计快；需要查询的表减少，检索容易。 缺点： 数据冗余，需要更大储存空间；插入、更新、删除操作开销更大；数据不一致，可能产生添加、修改、删除异常；更新和插入代码更难写。 Rest ： REST Representational State Transfer 表述性状态转移是一种通常使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性， 提高系统的可伸缩性。 五个原则： 1. 网络上的所有事物都被抽象为资源； 2. 每个资源对应一个唯一的资源标识； 3. 通过通用的连接件接口对资源进行操作； 4. 对资源的各种操作不会改变资源标识； 5. 所有的操作都是无状态的。
云原生架构： 云原生架构是基于云原生技术的一组（架构原则）和（设计模式）的集合。 非功能特性： 弹性、韧性、安全、可观测性、灰度 特点： 轻量、敏捷、高度自动化 云计算3层概念：基础设施即服务 IaaS、平台即服务PaaS、软件即服务SaaS 云原生的代码包括三部分： 业务代码：指实现业务逻辑的代码 三方软件：业务代码中依赖的所有三方库，业务库和基础库； 处理非功能性的代码：指实现高可用、安全、可观测性等非功能性能力的代码。 云平台架构包括：业务组件、微服务治理组件、中间件服务、DevOps、容器云平台、混合云环境。 云原生架构7个原则： 速记：服弹可韧自信演 服务化原则、弹性原则、可观测原则、韧性原则、所有过程自动化原则、零信任、架构持续演进原则。 云原生架构的反模式： 速记：庞单硬拆缺乏自动化 1.庞大的单体应用 2.单体应用硬拆为微服务，典型例子：小规模软件服务的拆分、数据依赖、性能降低 3. 缺乏自动化能力的微服务。
DSSA的创建步骤： 速记：领域范围、特定元素、设计约束、模型架构、重用单元
- 定义领域范围：
- 定义领域特定元素：编译领域字典和领域术语的同义词词典。
- 定义领域特定的设计和实现需求约束：
- 定义领域模型和架构
- 产生、搜集可重用的产品单元。
DSSA的必备特征： 速记：严格定义问题域、领域特定的应用、整个领域的抽象、领域元素可重用。 1.一个严格定义的问题域或解决域 2.具有普遍性，使其可以用于领域中某个特定应用的开发 3.对整个领域的合适程度的抽象 4.具备该领域固定的、典型的在开发过程中可重用的元素。
DSSA 的基本活动：
- 领域分析，主要目标是获得领域模型。
- 领域设计，主要目标是获得DSSA。
- 领域实现，主要目标是依据领域模型和DSSA开发和组织可重用信息。 DSSA的人员4种角色： 领域专家、领域分析人员、领域设计人员和领域实现人员。
数据中台必备的4个能力： 数据汇聚整合、数据提纯加工、数据服务可视化、价值变现方面。
4+1 视图模型描述软件架构： 逻辑视图、进程视图、物理视图、开发视图、场景视图
MVC ： Model 模型：是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。 view 视图：是应用程序中处理数据显示的部分，通常视图是依据模型数据创建的。 Controller 控制器：是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
效用：
-
性能： 系统的响应能力，即系统经过多长时间对某个事件做出响应或者在某段时间内系统所能处理的事件的个数。 指标：响应时间、吞吐量 策略：优先级队列、增加计算资源、引入并发机制、减少计算开销、资源调度
-
可用性： 系统能够正常运行的时间比例，出现故障时系统能够恢复正常的速度。 策略：心跳机制、Ping/Echo机制、冗余和选举策略
-
可修改性： 能够快速地以较高的性能价格比对系统进行变更的能力。 包括可维护性、可扩展性、结构重组、可移植性 策略：接口-实现分离、抽象和信息隐藏
-
安全性： 系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。 包括保密性、完整性、不可抵赖性和可控性 策略：入侵检测、用户认证和授权、追踪审计
系统架构风险： 是指架构设计中潜在的、存在问题的架构决策所带来的隐患。 敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。 权衡点： 是影响多个质量属性的特性，是多个质量属性的敏感点。
安全架构设计 五大安全： 应用安全、网络安全、数据安全、控制安全、设备安全。 WPDRRC模型包括6个环节和3大要素： 速记：预保检响恢反 6个环节：预警、保护、检测、响应、恢复和反击 模型蕴涵的网络安全能力： 预警能力、保护能力、检测能力、响应能力、恢复能力和反击能力。 3大要素：人员、策略和技术 区块链技术的核心特点： 去中心化：通过分布式计算和存储，所有节点的权利和义务均等，没有中心化的管理机构，数据由维护节点共同管理。 开放性：交易信息公开，但账户身份信息经过高度加密，保护用户隐私。 自治性：基于协商一致的协议和算法，所有节点在信任环境中自由安全地交换数据，减少对人为干预的依赖。 安全性：数据存储在多个节点上，篡改数据需要改动51%的节点，难度极大，同时，交易通过私钥签名，保证交易的真实性和不可伪造性。 匿名性：节点之间的交互无需信任，依靠固定算法自动验证交易有效性，促进信用的积累。 架构实现过程： 复审后文档化架构、分析与设计、构件实现、构件组装、系统测试、架构演化。
基于构件的软件开发方法：
- 发现待选构件
- 产生合格构件
- 调整构件
- 组装构件
- 扩展和升级构件。
ABSD 基于架构的软件开发方法： 6个过程：架构需求、设计、文档化、复审、实现和演化
ABSD方法的优点：
快速启动设计、迭代和递归、灵活性、资源优化、
缺点：
需求不明确、管理挑战、依赖经验、文档化要求高。
用例用于捕获用户功能需求，质量场景识别系统的非功能需求，如性能和可靠性。
解释器和管道过滤器哪个更适合应用于集成开发环境的开发中？ 请从用户交互方式，扩展性方面，数据管理方面分别阐述。 用户交互方式：因为集成开发环境中，用户需要对脚本语言进行编辑、解释执行与调试，所以需要较强的交互性，管道过滤器的交互能力支持比较有限，以 数据为中心的架构风格能很好的支持用户的交互。 扩展性：集成开发环境需要实现各种功能的灵活组合、配置与替换，管道过滤器的扩展性方面比较有限，以数据为中心的架构风格因为组件之间的耦合性低， 可以灵活的替换组件，可以有更好的扩展性。 数据管理：集成开发环境可能会保存编译期间产生的语法树和脚本语言，管道过滤器在数据保存和转换方面支持有限，以数据为中心的架构风格可以以文件的 形式存储语法树，并且可以灵活编写转换器来进行格式转换，所以数据管理方面强于管道过滤器。
事务的特性：ACID 原子性、一致性、隔离性、持久性。
面向对象和解释器的差别从性能、灵活性和可扩展性描述？ 性能：面向对象是代码层面的，一次编译后加载到内存运行，效率较高；解释器则需要边解释边执行，效率稍微差一些。 灵活性：面向对象需要通过组合模式或者策略等设计模式实现该功能，但仍然需要重新编译和重启服务；解释器可以支持灵活自定义功能，不需要重启。 可修改性：面向对象是如果修改规则代码，需要重新编译和重启服务；解释器是独立的语法规则，可对变化的规则进行解释，比如只需要修改规则脚本。
解释器： 灵活性高，扩展能力强，通过自定义规则配套解释器引擎开发，可以做到用户层面的规则完全自定义而不需要修改代码，无论是修改已有业务或者 扩展新的业务都较为便利。 管道过滤器：灵活性低，扩展能力弱，把数据处理职能做成过滤器，把数据传递做成管道，流程不变化是可以的，一旦流程变化需要重新修改代码。 隐式调用：灵活性一般，扩展能力一般强调间接方式调用，如果采用事件机制，需要先完成某个动作来触发事件，通过事件与动作关联来提高灵活性、比管 道过滤器强，比解释器弱。
仓库风格和管道过滤器风格从交互方式、数据结构、控制结构和扩展方法进行对比？ 交互方式：管道过滤器是顺序结构或循环结构，数据在管道中进行传递；仓库结构是数据在中心 位置所有的处理均是中心节点与周边节点之间的交互。 数据结构：仓库风格使用一个文件将数据保存起来，所有操作围绕这个文件进行；管道过滤器是在过滤器之间传递数据流。 控制结构：从控制结构来说仓库风格是业务功能驱动，而管道-过滤器是由数据流驱动的。 扩展方法：管道过滤器是通过过滤器提供标准接口与其它过滤器对接；仓库风格要共享数据或者扩展功能，只要功能操作与数据模型本身匹配就行。 AI 芯片的关键特征： 新型的计算范式：AI计算既不脱离传统计算，也具有新的计算特质 训练和推断：AI系统通常涉及训练和推断过程大数据处理能力，满足高效能机器学习的数据处理要求 数据精度：降低精度的设计 可重构的能力：针对特定领域而不针对特定应用的设计，可以重新配置，适应新的AI算法、架构和任务。
软件系统的质量属性，开发期质量属性有哪些？ 易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性
运行期质量属性有哪些？ 性能、安全性、可伸缩性、互操作性、可靠性、可用性、鲁棒性
质量属性场景是什么？包含那些？ 质量属性场景是一种面向特定质量属性的需求。 质量属性场景由6个部分组成： 刺激源：这是某个生成该刺激的实体（人、计算机系统或者其他刺激器） 刺激：该刺激是当刺激到达系统时需要考虑的条件。 环境：该刺激在某些条件内发生。当刺激发生时，系统可能处于过载、运行或者其他情况。 制品：某个制品被激励。这可能是整个系统，也可能是系统的一部分。 响应：该响应是在激励到达后所采取的行动。 响应度量：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。 质量属性场景主要关注可用性、可修改性、性能、可测试性、易用性和安全性。
常用的架构评估方法：问卷调查，基于场景，基于度量。
SAAM：最开始只针对可修改性（1）场景开发（2）架构描述（3）单个场景的架构评估（4）多个场景的交互（5）总体评估。
ATAM：架构权衡分析方法（1）场景与需求收集，通过会议的形式介绍ATAM，多方人员成为评估小组
（2）架构视图和场景实现，对收集到的场景进行实现，产生架构视图
（3）属性模型构造，生成质量效应树（4）对架构进行评价与折中。
ATAM九个步骤，分别是：
描述和介绍阶段：（1）描述ATAM方法（2）描述业务动机（3）描述体系结构
调查和分析阶段：（4）确定体系结构方法（5）生成质量属性效用（6）分析体系结构方法
测试阶段：（7）讨论和分级场景（8）分析体系结构方法（9）描述评估结果
质量属性场景是一种面向特定质量属性的需求。 质量属性场景由6个部分组成： 刺激源：这是某个生成该刺激的实体（人、计算机系统或者其他刺激器） 刺激：该刺激是当刺激到达系统时需要考虑的条件。 环境：该刺激在某些条件内发生。当刺激发生时，系统可能处于过载、运行或者其他情况。 制品：某个制品被激励。这可能是整个系统，也可能是系统的一部分。 响应：该响应是在激励到达后所采取的行动。 响应度量：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。 质量属性场景主要关注可用性、可修改性、性能、可测试性、易用性和安全性
能力成熟度模型CMM： 初始级、可重复级、已定义级、已管理级、优化级。 能力成熟度模型集成CMMI： 初始级、已管理级、已定义级、量化管理级、优化级。
用例图用例模型包括： 识别参与者 合并需求获得用例 细化用例描述 调整用例模型 用例图分析模型包括： 定义概念类 识别类之间的关系 为类添加职责 建立交互图 中间件的作用和特点是什么？ 1.负责客户机与服务器之间的连接与通信，以及客户机与应用层之间的高效通信。 2.提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。 3.提供多层架构的应用开发和运行的平台。 4.屏蔽硬件、操作系统、网络和数据库的差异。 5.提供应用的负责均衡和高可用性、安全机制与管理功能。 6.提供一种通用的服务去执行不同的功能，避免重复的工作和使应用之间高效协作。
信息安全的5个基本要素： 机密性：网络信息不泄露给非授权的用户实体或程序，能够防止非授权者获取信息。 完整性：网络信息或系统未经授权不能进行更改的特性。 可用性：合法许可的用户能够及时获取网络信息或服务的特性。 可控性：可以控制授权范围内的信息流及行为方式。 可审查性：对出现的信息安全问题提供调查的依据和手段。
大数据架构： 大数据处理系统三大挑战： 1.如何利用信息技术处理非结构化和半结构化数据。 2.大数据复杂性，不确定性特征描述的刻画方法以及大数据的系统建模 3.数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响。 八大特征： 1.鲁棒性和容错性 2.低延迟读取和更新能力 3.通用性 4.横向扩容 5.延展性 6.即席查询能力 7.最少维护能力 8.可调试性 Lambda架构： 提供一个能满足大数据系统关键特性的架构，包括高容错、低延迟、可扩展。 分为三层：批处理层、加速层和服务层。 主要用于： 用于同时处理离线和实时数据，可容错的、可扩展的分布式系统。 具备强鲁棒性，提供低延迟和持续更新。 用于机器学习、物联网和流处理场景。 Lambda 架构优缺点： 优点：容错性好、查询灵活度高、易伸缩、易扩展 缺点： 1.全场景覆盖带来的编码开销 2.针对具体场景重新离线训练一遍益处不大。 3.重新部署和迁移成本很高。
Lambda 架构和Kappa 架构对比：
复杂度与开发、维护成本：
Lambda需要维护两套系统，复杂度高、开发维护成本高
Kappa 只需要维护一套系统，复杂度低、开发维护成本低。
计算开销：
Lambda 需要一直运行批处理和实时计算，计算开销大。
Kappa 必要时进行全量计算，计算开销相对较小。
实时性：
满足实时性
历史数据处理能力：
Lambda 批式全量处理，吞吐量大，历史数据处理能力强。
Kappa 流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱。
国产密码算法： SM1 : 对称加密，分组长度和密钥长度为128比特。 SM2：非对称加密，用于公钥加密算法、密钥交换协议、数字签名算法 SM3：杂凑算法，长度256比特，用于数字签名和验证。 SM4：对称加密，分组长度和密钥长度为128比特。 SM9：标识密码算法，不需要申请数字证书。
架构评估方法主要SAAM和ATAM，两种方法步骤或阶段： SAAM分析评估体系结构：场景开发、架构描述、单个场景评估、场景交互和总体评估。 ATAM 分为9个步骤： 描述ATAM方法、描述业务动机、描述体系结构、确定系统结构方法、生成质量属性效用树、 分析体系结构方法、讨论和分级场景、分析体系结构方法、描述评估结果。
NoSQL数据的特点： 优点： 数据库支持高并发数据访问，性能较高。 数据库的存储结构松散，能够灵活支持多种类型的数据格式。 数据库能支持海量数据的存储，且易于横向扩展。 数据库基于分布式数据存储，不存在单点故障和性能瓶颈，系统可用性高。 缺点： 数据模型和查询语言没有经过数学验证。不支持ACID特性等。
鸿蒙操作系统： 采用分层的层次化设计，从下向上依次是内核层、系统服务层、框架层和应用层。 系统功能按照系统->子系统->功能/模块 内核层：内核子系统和驱动子系统 内核子系统：采用多内核设计，支持针对不同资源受限设备选用适合的OS内核。 驱动子系统：提供统一外设访问能力和驱动开发、管理框架。 系统服务层：HarmonyOS 的核心能力集合，通过框架层对应用程序提供服务。包含4个部分： 系统基本能力子系统集：为分布式应用在HarmonyOS多设备上的运行、调度、迁移等操作提供基础能力。 基础软件服务子系统集：为HarmonyOS 提供公共的通用的软件服务。 增强软件服务子系统集：为HarmonyOS 提供针对不同设备的、差异化的能力增强型软件服务。 硬件服务子系统集：为HarmonyOS提供硬件服务。 框架层： 为HarmonyOS的应用程序提供了Java/C/C++/JS等多种语言的用户程序框架和Ability框架，以及各种软硬件服务对外开放的多语言框架API。 应用层：包括系统应用和第三方非系统应用。HarmonyOS的应用由一个或多个FA或PA组成。
鸿蒙操作系统架构4个技术特性： 分布式架构首次用于终端OS，实现跨终端无缝协同体验。 确定时延引擎和高性能IPC技术实现系统天生流畅。 基于微内核架构重塑终端设备可信安全。 通过统一IDE支撑一次开发，多端部署，实现跨终端生态共享。
在HarmonyOS架构中，重点关注于分部署架构所带来的优势： 分布式软总线是多种终端设备的统一基座，为设备之间的互联互通提供了统一的分布式通信能力。 分布式设备虚拟化平台可以实现不同设备的资源融合、设备管理、数据处理，针对不同类型的任务，为用户匹配并选择能力合适的执行硬件。 分布式数据管理基于分布式软总线的能力，实现应用程序数据和用户数据的分布式管理。 分布式任务调度构建统一的分布式服务管理机制。支持对跨设备的应用进行远程启动、调用连接以及迁移等操作，选择合适的设备并运行分布式任务。
管道-过滤器与数据仓储对比？ 1. 交互方式：管道过滤器的构件是顺序交互，前一个构件的输出是后一个构件的输入；数据仓库是星型交互， 构件都和一个共享数据库进行交互。数据仓库风格更加灵活。 2. 数据结构：管道过滤器是基于数据流结构的，构件之间传递数据结构可能是结构体等常规数据结构；数据 仓库是基于数据库结构的，构件之间传递数据是基于关系数据库。数据仓库风格会更加实用。 3. 控制结构：管道过滤器是数据流顺序传递，数据仓库是面向应用，由业务功能驱动，因此更加灵活。 4. 扩展方法：管道过滤器是顺序结构，通过接口适配扩展；数据仓库可以直接通过数据库内增加数据， 通过模型适配更加灵活。
分层数据流图父图与子图平衡？ 父图与子图之间平衡，子图边界上的输入、输出数据流必须与其父图对应的加工的输入输出数据流保持一致。 父图中某个加工的一条数据流对应子图中的几条数据流而子图中组成的这些数据流的数据项正好等于父图中的这条数据流。
状态图与活动图的概念与特点： 状态图：描述对象状态和事件之间的关系，强调一个实体基于事件反应的动态行为。适合用于表述在不同用例之间的对象行为。 活动图：描述对象活动的顺序关系所遵循的规则，着重表现系统的行为，强调行为活动的顺序和条件控制。活动图依据对象状态 的变化来捕获动作与动作的结果。活动图中一个活动结束立即进入下一个活动。
RUP软件开发生命周期9个核心工作流及主要作用： 1.业务建模：理解待开发的系统所在机构及商业运作，确保所有参与人员对待开发系统有共同的认识，评估待开发系统对所在机构的影响。 2. 需求：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。 3.分析与设计：把需求分析结果转化为分析与设计模型。 4.实现：把设计模型转换为实现结果，对开发的代码进行单元测试，将不同实现人员开发的模块集成为可执行系统。 5.测试：检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。 6.部署：打包、分发、安装软件，升级旧系统；培训用户及销售人员，提供技术支持。 7.配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。 8.项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。 9.环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
基于架构的软件设计(ABSD) ABSD方法是架构驱动，即强调由业务【商业】质量和功能需求的组合驱动架构设计。 ABSD方法有三个基础。 第一个基础是功能的分解。在功能分解中， ABSD方法使用已有的基于模块的内聚和耦合技术; 第二个基础是通过选择架构风格来实现质量和业务需求; 第三个基础是软件模板的使用。软件模板利用了一些软件系统的结构。 开发过程:架构需求、架构设计、架构文档化、架构复审、架构实现、架构演化。
访问控制三要素： 主体：可以对其他实体施加动作的主动实体。 客体：是接受其他实体访问的被动实体。 控制策略：是主体对客体的操作行为集和约束条件集。 访问控制的实现技术： 访问控制矩阵（ACM）、访问控制列表、能力表、授权关系表。
软件架构风格 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。 五大架构风格以及子风格划分: 数据流风格:批处理、管道-过滤器 调用/返回风格:主程序/子程序、面向对象、分层架构 独立构件风格:进程通信、事件驱动系统(隐式调用) 虚拟机风格:解释器、规则系统 以数据为中心:数据库系统、黑板系统、超文本系统
智能制造体系架构中，系统层级是指与企业生产活动相关的组织结构的层级划分， 包括设备层、单元层、车间层、企业层和协同层。
数字化转型的5个发展阶段企业数字化转型的五个发展阶段分别为: 初始级发展阶段、单元级发展阶段、流程级发展阶段、网络级发展阶段、生态级发展阶段。 逆向工程及其相关的概念 (1)重构(restructuring):重构是指在同一抽象级别上转换系统描述形式。 (2)设计恢复(designrecovery):设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。 (3)逆向工程(reverseengineering):逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。 (4)正向工程(forwardengineering):正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统以改善其整体质量。 (5)再工程(re-engineering):再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。
边云协同的分类 【资源协同】边缘节点有基础设施资源的调度管理能力，可与云端协同。 【数据协同】边缘节点采集数据并初步分析，再发给云端做进一步处理。 【智能协同】分布式智能，云端做集中式模型训练，再将模型下发到边缘节点。 【应用管理协同】边缘节点提供应用部署与运行环境，云端主要提供应用开发、测试环境。 【业务管理协同】边缘节点提供模块化、微服务化的应用/数字孪生/网络等应用实例;云端主要提供按照客户需求实现应用/数字孪生/网络等的业 务编排能力。 【服务协同】边缘节点按照云端策略实现部分ECSaaS服务，通过ECSaaS与云端SaaS的协同实现面向客户的按需SaaS服务;云端主要提供SaaS服务在 云端和边缘节点的服务分布策略，以及云端承担的SaaS服务能力。
传统数据处理系统问题？ 数据流激增、性能瓶颈、缓冲隔离、分区问题、人为错误风险
大数据处理系统架构特征有哪些？ 鲁棒性和容错性、低延迟读取和更新能力、横向扩容、通用性、即席查询能力、最少维护能力、可调试性。
lambda 架构分层： 批处理层：存储数据集，预计算查询函数，生成Batch View。处理全体数据集，适用于离线数据。 加速层：处理最近的增量数据流，实时更新视图。提供低延迟实时视图。 服务层：响应用户查询，合并Batch View 和Real-time View。提供对主数据计算结果的低延迟访问。
论文题目及相应的写作论点 云原生架构：Web前端服务、平台保障服务、业务服务。 微服务架构：服务化、强韧性、可观测性和自动化四类设计原则。微服务部署、服务的快速启动、职责专一、服务的复用。 论软件设计方法：业务流程优化、数据结构组织的优化、软件结构的优化。 系统测试：功能测试、用户界面测试与性能测试。 统一过程：初始阶段、细化阶段、构建阶段、交付阶段。 层次式架构：表示层、中间层、数据层。 SOA架构：服务提供者、服务注册中心和服务请求者。 ————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
