网站优化的策略,2017网站建设费用,做网站需要了解的东西,实力网站优化公司首选文章目录 前言0 系统架构设计师0.1 考架构还是考系分0.2 架构核心知识0.3 架构教材变化 1 计算机操作系统1.1 cpu 组成1.2 内核的五大功能1.3 流水线技术1.4 段页式存储1.5 I/O 软件1.6 文件管理1.7 系统工程相关 2 嵌入式2.1 嵌入式技术2.2 板级支持包#xff08;BSP#xf… 文章目录 前言0 系统架构设计师0.1 考架构还是考系分0.2 架构核心知识0.3 架构教材变化 1 计算机操作系统1.1 cpu 组成1.2 内核的五大功能1.3 流水线技术1.4 段页式存储1.5 I/O 软件1.6 文件管理1.7 系统工程相关 2 嵌入式2.1 嵌入式技术2.2 板级支持包BSP2.3 实时操作系统2.4 物联网M2M 3 数据库3.1 数据库设计过程3.2 数据模型3.3 关系代数3.4 模式分解保持函数依赖分解无损分解 3.5 封锁协议3.6 数据仓库和联邦数据库3.7 常见的反规范化设计方法 4 计算机网络4.1 网络协议SMTP/POP3、IMAPIPv6 4.2 DNS4.3 网络规划与设计网络设计阶段逻辑网络设计物理网络设计 4.4 5G网络的主要特征4.5 多媒体 5 信息化5.1 信息技术趋势5.2 国家信息化体系六要素5.3 企业信息化5.4 信息系统战略规划第一阶段:以数据处理为核心围绕职能部门需求第二阶段:以企业内部MIS(管理信息系统)为核心围绕企业整体需求第三阶段:综合考虑企业内外环境以集成为核心围绕企业战略需求 5.5 信息系统架构方法TOGAF 企业架构框架ADM架构开发方法 6 知识产权6.1 知识产权保护期限6.2 开源许可证 7 软件工程7.1 信息系统生命周期7.2 能力成熟度模型集成CMMI7.3 信息系统开发方法结构化开发方法面向对象开发方法原型化开发方法统一过程RUP开发方法模型驱动架构开发方法 7.4 企业应用集成技术EAI7.5 系统规划系统规划阶段产出物可行性研究盈亏平衡点净现值计算 7.6 需求工程需求分析结构化需求分析方法面向对象需求分析方法PDOA 需求分析方法UML 事务间关系UML 41 视图 需求变更 7.7 图形表示工具7.8 系统设计基本原则7.9 面向对象设计7.10 SysML基于模型的系统工程MBSE 7.11 设计模式7.12 白盒测试用例7.13 软件度量7.14 垃圾回收7.15 遗留系统7.16 系统维护 8 软件架构设计8.1 架构和框架8.2 架构评估8.3 基于架构的软件设计 ABSD8.4 鸿蒙系统架构8.5 信息系统架构8.6 层次式架构UIP (UserInterface Process)业务逻辑层 8.7 面向服务架构SOASOA的设计模式常见的微服务设计模式 9 系统可靠性9.1 系统质量属性质量属性场景健壮性 VS 容错性关键应急响应指标 9.2 系统架构的脆弱性分析 10 系统安全性10.1 信息安全10.2 访问控制模型10.3 安全模型一. HRU模型【基本模型】二. BLPBell-LaPadula模型【机密性】三. Chinese Wall模型【机密性】四. Biba模型【完整性】五. Clark-Wilson模型【完整性】 10.4 系统安全架构WPDRRC模型 10.5 系统安全保护等级10.6 Kerberos认证10.7 RADIUS远程访问拨号用户服务 11 扩展知识11.1 边缘计算11.2 SSE11.3 仓颉语言11.4 数字孪生11.5 宏编程11.6 LLVM 12 应用软件12.1 NoSQL12.2 Elasticsearch概念分片Shards分词器其他 架构节点类型分段存储延迟写策略段合并机制 ES 优化写优化读优化 12.3 Kafka分区 Partition副本Replicas生产者ProducerKafka 高吞吐量 12.4 RocketMQ12.5 RabbitMQ12.6 MysqlMySQL引擎 12.7 Memacache12.8 Redis12.9 Prometheus Grafana 13 案例分析13.1 云原生架构服务化架构Mesh 化架构Serverless 架构可观测架构 13.2 大数据架构Lambda架构Kappa 架构Lambda 架构 vs Kappa 架构Kappa 架构变种KappaKappa-SKappa-Lambda 流批一体Dataflow 模型实时数仓不同架构对比 13.3 Redis 架构Redis 怎么 6.0 成了多线程的Redis 过期策略以及内存淘汰机制Redis与MySQL的数据同步方案一. 实时同步方案二. 异步准实时方案 缓存和数据库的数据一致性问题缓存穿透缓存击穿缓存雪崩 13.4 分布式架构开放分布进程 ODP分布式架构主从架构主主架构无主架构 事务隔离事务的四大特性 ACID事务的并发问题事务隔离级别锁S锁和X锁乐观锁和悲观锁 分布式事务理论CAP定理BASE理论 分布式事务框架 Seata2PC 两阶段提交3PC 三阶段提交Seata事务类型 14 论文14.1 论文框架14.2 摘要模板14.3 常考理论14.4 历年论文 前言
博主参加了2024年下半年的架构设计师考试幸运的通过了在此分享学习备考过程中做的笔记希望对大家有所帮助。 很多人可能会问考软考有没有用见仁见智吧觉得没用的人都不会多看一眼凡事预则立不预则废只希望能把路越走宽。
0 系统架构设计师
0.1 考架构还是考系分 0.2 架构核心知识 0.3 架构教材变化
V2 删除
新大纲删除了对数据流图和Uml图的要求新大纲删除了对设计模式的要求
V2 新增
新大纲增加了系统架构的脆弱性分析、通信系统的架构设计、信息系统的架构设计、安全架构设计与安全模型
1 计算机操作系统
1.1 cpu 组成 冯诺依曼结构是一种将程序指令和数据合并在一起的存储器结构。
现代计算机在冯诺依曼结构的基础上进行了改进如引入高速缓存Cache来减少CPU访问内存的次数。
1.2 内核的五大功能
进程管理文件管理网络管理内存管理设备管理
1.3 流水线技术 1.4 段页式存储
快表 是将页表存于cache中; 慢表 是将页表存于内存上。慢表需要访问两次内存才能取出页而快表是访问一次Cache和一次内存因此更快。
现代操作系统是 分段分页相结合的内存管理方式但 操作系统通过巧妙的设置‘屏蔽’了段的存在。
现在的操作系统Windows和Linux整个进程的地址空间实际上就是一个段通过这种方式架空了CPU的分段内存管理机制。
1.5 I/O 软件 1.6 文件管理
索引结构。将逻辑上连续的文件信息 (如记录)存放在不连续的物理块中系统为每个文件建立一张索引表。索引表记录了文件信息所在的逻辑块号对应的物理块号并将索引表的起始地址放在与文件对应的文件目录项中。
1.7 系统工程相关 2 嵌入式
2.1 嵌入式技术
嵌入式微控制器 MCU单片机泛指字长16位及以下微处理器片上外设丰富。嵌入式微处理器 MPU。嵌入式数字信号处理器 DSP 哈弗结构程序和数据分开存储流水线处理比CPU快10-50倍。潜入式片上系统 SOC软硬件结合。
2.2 板级支持包BSP
板级支持包BSP 是介于主板硬件和操作系统中驱动层程序之间的一层一般认为它属于操作系统一部分。 BSP 主要包括两个方面的内容引导加载程序 BootLoader 和设备驱动程序。
BootLoader 是嵌入式系统加电后运行的第一段软件代码类似BIOS
1.片级初始化完成微处理器芯片的初始化纯硬件的初始化过程。2.板级初始化初始化片上其他设备如LED显示设备串口通信内存控制器等等同时包含软件和硬件的初始化过程。3.加载内核系统级初始化将操作系统和应用程序加载到内存。
2.3 实时操作系统
实时操作系统特征
高精度计时系统多级中断机制实时调度机制
2.4 物联网
M2M
M2M 全称 Machine to Machine是指数据从一台终端传送到另一台终端也就是机器与机器的对话。M2M应用系统构成有智能化机器、M2M硬件、通信网络、中间件、应用。
智能化机器 让机器具有信息感知、信息加工及无线加工的能力M2M硬件具备联网能力和远程通信的部件。通信网络将M2M硬件传输的信息送达指定位置处于 M2M 技术框架的核心的地位。中间件M2M网关完成在不同协议之间的转换在通信网络和IT系统之间建立桥梁。应用对获得的数据进行加工分析提供决策依据。
但从广义上M2M可代表机器对机器Machine to Machine人对机器Man to Machine、机器对人Machine to Man、移动网络对机器Mobile to Machine之间的连接与通信它涵盖了所有实现在人、机器、系统之间建立通信连接的技术和手段。
3 数据库
3.1 数据库设计过程 需求分析画出数据流程图建立数据字典形成用户确认的文档。 概念设计使E-R图建立概念模型。 逻辑设计将概念结构转换为某个具体数据库管理系统所支持的数据模型表结构。 物理设计选择存储结构和存取方法考虑硬件环境和数据库产品的限制。 数据库实施建立数据库编写和调应用程序。 数据库的运行和维护
3.2 数据模型 弱实体和强实体:弱实体依赖于强实体的存在而存在。
3.3 关系代数 其中 F 为 R(U) 的一组函数依赖记为 R(U, F) X,Y,Z,U 都是属性集
3.4 模式分解
保持函数依赖分解
对于关系模式R有依赖集F若对R进行分解分解出来的多个关系模式保持原来的依赖集不变则为保持函数依赖的分解。另外注意要消除掉冗余依赖(如传递依赖)
实例:设原关系模式R(A,B,C)依赖集F(A-B,B-C,A-C)将其分解为两个关系模式R1(A,B)和R2(B,C)此时R1中保持依赖A-BR2保持依赖B-C说明分解后的R1和R2是保持函数依赖的分解因为A-C这个函数依赖实际是一个元余依赖可以由前两个依赖传递得到因此不需要管。
无损分解
分解后的关系模式能够还原出原关系模式就是无损分解不能还原就是有损。
定理:如果R的分解为p{R1R2)F为R所满足的函数依赖集合分解p具有无损连接性的充分必要条件是R1∩R2-(R1-R2)或者R1∩R2-(R2-R1)。 3.5 封锁协议
一级封锁协议: 事务在修改数据R之前必须先对其加X锁直到事务结束才释放。可解决丢失更新问题。
二级封锁协议: 一级封锁协议的基础上加上事务T在读数据R之前必须先对其加S锁读完后即可释放S锁。可解决丢失更新、读脏数据问题。
三级封锁协议: 一级封锁协议加上事务T在读取数据R之前先对其加S锁直到事务结束才释放。可解决丢失更新读脏数据、数据重复读问题
X锁:写锁排它锁(exclusive locks独家排它)T对R加X锁T只能读取和修改其他事务不能对R任何锁。
S锁:读锁共享锁(share locks)T对RS锁T只能读不能改其他事务可以对RS锁。
3.6 数据仓库和联邦数据库 3.7 常见的反规范化设计方法
反规范化是指在逻辑设计阶段有意地引入冗余以提高数据库的读性能。 1增加冗余列在多个表中保留相同的列避免查询时的连接操作。 2增加派生列在表中增加由本表或其它表中数据计算生成的列减少查询时的连接操作和计算操作避免使用聚集函数。 3重新组表频繁查询两个表连接出来的结果把两个表重新组成一个表来减少多表连接操作。 4水平分割表按行进行分割用于表数据规模很大、表中数据相对独立、数据需要存放到多个介质上时。 5垂直分割表按列进行分割将主键与部分列放到另一个表中。用于表中某些列常用而其它列不常用垂直分割使数据行变短查询时减少I/O次数。
4 计算机网络
4.1 网络协议
网络协议三要素:语法、语义、时序。
OSI定义的7层协议中会话层没有提供安全服务。 SMTP/POP3、IMAP
SMTP 即 简单邮件传输协议。POP3 用于支持使用客户端远程管理在服务器上的电子邮件它会下载所有邮件到本地计算机并从邮件服务器上删除它们。IMAP 协议与 POP3 协议一样也是规定个人计算机如何访问互联网上的邮件服务器进行收发邮件的协议但是IMAP4协议同POP3协议相比更高级。它在邮件服务器上保留邮件副本这意味着您可以在多个设备上查看和管理您的邮件。
IPv6
IPv6规定每个网卡最少有3个IPv6地址分别是链路本地地址、全球单播地址和回送地址(站点本地地址)。
IPv6没有广播的术语而是将广播看作多播的一个特例。
4.2 DNS
浏览器输入域名: HOSTS - 本地DNS缓存 - 本地DNS服务器 - 根域名服务器 - 顶级域名服务器 - 权限域名服务器。
4.3 网络规划与设计
网络设计阶段
需求分析 - 通信规范分析 - 逻辑网络设计 - 物理网络设计 - 实施阶段
逻辑网络设计 物理网络设计
输出内容
网络物理结构图和布线方案设备和部件的详细列表清单软硬件和安装费用的估算安装日程表详细说明服务的时间以及期限安装后的测试计划用户的培训计划
4.4 5G网络的主要特征
1.服务化架构2.网络切片3.基于OFDM优化的波形和多址接入4.实现可扩展的OFDM间隔参数配置5.OFDM加窗提高多路传输效率6.大规模MIMO最多256根天线。7.频谱共享8.毫米波频率大于24GHz以上的频段。9.先进的信道编码设计
4.5 多媒体
人耳能听到的音频信号的频率范围是 20Hz~20KHz。
声音的采样频率一般为最高频率的两倍才能保证不失真。
曼彻斯特编码是一种数字通信中常用的编码方式用于将数字信号转换为易于传输的波形。 5 信息化
5.1 信息技术趋势
我国在“十三五”规划纲要中将培育人工智能、移动智能终端、第五代移动通信 (5G)、先进传感器等作为新一代信息技术产业创新重点发展拓展新兴产业发展空间。
5.2 国家信息化体系六要素 5.3 企业信息化
企业信息化方法主要包括业务流程重构、核心业务应用、信息系统建设、主题数据库、资源管理和人力资本投资方法。
企业信息化需要从企业战略的层面、业务运作层面、管理运作层面这3个层面来实现。
市场营销和客户服务是CRM的支柱性功能。
5.4 信息系统战略规划
第一阶段:以数据处理为核心围绕职能部门需求
企业系统规划法BSP: 自上而下地识别企业目标、企业过程和数据然后对数据进行分析自下而上地设计信息系统。重视数据的创建和使用以数据的创建和使用归类提供一个信息系统规划建立CU矩阵(创建使用矩阵。关键成功因素法CSF: 重视关键因素每个企业在某阶段都有关键因素抓住关键信息。战略集合转化法SST: 将企业的战略信息(环境、目标等)收集起来当成一个“信息集合”并且转换为信息系统的战略信息全方位的注重企业的战略信息。
第二阶段:以企业内部MIS(管理信息系统)为核心围绕企业整体需求 战略数据规划法SDP: 强调建立企业模型和主题数据库(重点和关键是面向业务主题整个企业的》数据类基本上是稳定的而业务和流程是多变的。 信息工程法IE:第一次提出以工程的方法来建立信息系统信息工程是面向企业计算机信息系统建设以数据为中心的开发方法。信息工程方法认为与企业的信息系统密切相关的三要素是:企业的各种信息、企业的业务过程和企业采用的信息技术。信息工程自上而下地将整个信息系统的开发过程划分为四个实施阶段分别是信息规划阶段、业务领域分析阶段、系统设计阶段和系统构建阶段。 战略栅格法SG: 建立一个2*2的矩阵每个矩阵元素代表过程对数据类的创建和使用等。栅格即划分矩阵。
第三阶段:综合考虑企业内外环境以集成为核心围绕企业战略需求 价值链分析法VCA: 将所有对企业有影响的信息作为一个个活动其都有可能对企业造成增值分析其中对企业增值最大的信息。 战略一致性模型SAM: 保证企业战略和信息系统战略要一致。
5.5 信息系统架构方法
TOGAF 企业架构框架
TOGAFThe Open Group Architecture Framework是一种开放式「企业架构框架」标准 。它提供了一套企业架构的参考模型结构化的方法、模型、工具帮助企业定义其业务目标、业务流程、信息流、技术架构等方面的要素并建立起这些要素之间的关联和整合包括企业架构的多个视图和视角
业务架构信息系统架构应用 数据技术架构
TOGAF框架的「六个组件」
1.架构开发方法, ADM是TOGAF的核心描述了一种开发企业架构的分步方法。2.ADM指南和技术3.架构内容框架, 描述了TOGAF内容框架包括架构工件的结构化元模型、可重用架构构建块ABB的使用、典型架构可交付成果的概述。4.企业连续体和工具, 分类法工具用于对企业内部架构活动的输出进行分类和存储。5.TOGAF参考模型, 提供2个架构参考模型TOGAF技术参考模型TRM 集成信息基础设施参考模型III-RM6.架构能力框架, 在企业内建立和运营架构实践所需的组织、流程、技能、角色和职责。
TOGAF框架的「核心思想」
模块化架构内容框架扩展指南架构风格
ADM架构开发方法
TOGAF 的关键是架构开发方法 ADMArchitecture Development Method,它是一个可靠的、行之有效的方法能够满足商务需求的企业架构。ADM 为开发企业架构所需要执行各个步骤以及它们之间的关系进行详细的定义是TOGAF规范中最为核心的内容。
ADM方法是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成。ADM 全生命周期划分为十个反复迭代的过程。在ADM的全生命周期中每个阶段都需要根据原始业务需求对设计结果进行确认每个阶段都应该考虑到架构资产的重用。
ADM生命周期十阶段
1.准备: 为成功的架构项目、组织准备2.需求管理 : 确保 TOGAF 每一个阶段均基于需求3.架构愿望: 制定架构项目的约束和期望创建架构愿景4.业务架构: 开发基线和目标业务架构分析差距5.信息系统架构(应用数据) : 开发基线和目标数据/应用架构分析差距6.技术架构: 开发基线和目标技术架构分析差距7.机会和解决方案: 进行初步的实施规划识别主要实施项目8.迁移计划: 分析成本、效益、风险开发详细的实施和迁移计划9.实施治理: 为实施提供架构监管确保实施项目准守架构10.架构变更管理: 提供持续的检测和变更管理流程 6 知识产权
6.1 知识产权保护期限 商业秘密受到法律保护的依据是必须具备构成商业秘密的三个条件即不为公众所知悉、具有实用性、采取了保密措施缺少三个条件之一都会造成商业秘密丧失法律保护。
专利包括发明、实用新型和外观设计。
6.2 开源许可证
根据使用条件的不同开源许可证分成两大类。
宽松自由软件许可协议Permissive free software licence著佐权许可证copyleft license
著佐权Copyleft是一个由自由软件运动所发展的概念是一种利用现有著作权体制来保护所有用户和二次开发者的自由的授权方式。在自由软件授权方式中增加著佐权条款之后该自由软件除了允许使用者自由使用、散布、修改之外著佐权许可证更要求使用者修改后的衍生作品必须要以同等的授权方式释出以回馈社会。
其中Apache、MIT、BSD 都是宽松许可证。GPL 是典型的强著佐权copyleft许可证LGPL、MPL 是弱著佐权copyleft许可证。
常见的宽松式许可证有四种。它们都允许用户任意使用代码区别在于要求用户遵守的条件不同。 BSD二条款版分发软件时必须保留原始的许可证声明。 BSD三条款版分发软件时必须保留原始的许可证声明。不得使用原始作者的名字为软件促销。 MIT分发软件时必须保留原始的许可证声明与 BSD二条款版基本一致。 Apache 2分发软件时必须保留原始的许可证声明。凡是修改过的文件必须向用户说明该文件修改过没有修改过的文件必须保持许可证不变。
常见的 Copyleft 许可证也有四种对用户的限制从最强到最弱排序。 Affero GPL (AGPL)如果云服务即 SAAS用到的代码是该许可证那么云服务的代码也必须开源。 GPL如果项目包含了 GPL 许可证的代码那么整个项目都必须使用 GPL 许可证。 LGPL如果项目采用动态链接调用该许可证的库项目可以不用开源。 MozillaMPL只要该许可证的代码在单独的文件中新增的其他文件可以不用开源。
总得来说除非有明确的 “保留专利” 的条款使用开源软件都不会构成侵犯专利。
GPL 许可证规定只要你的项目包含了 GPL 代码整个项目就都变成了 GPL。有人把这种传染性比喻成 “GPL 病毒”。
7 软件工程
7.1 信息系统生命周期 7.2 能力成熟度模型集成CMMI
CMMI是若干过程模型的综合和改进不仅仅软件而是支持多个工程学科和领域的系统的、一致的过程改进框架能适应现代工程的特点和需要能提高过程的质量和工作效率。
7.3 信息系统开发方法
结构化开发方法
结构化方法也称为生命周期法是一种传统的信息系统开发方法由结构化分析(Structured Analysis,SA)、结构化设计 (Structured Design,SD)和结构化程序设计 (Structured ProgrammingSP) 三部分有机组合而成其精髓是自顶向下、逐步求精和模块化设计。
遵循“用户第一”的原则在系统分析与设计时从整体和全局考虑自顶向下地分解。在系统实现时根据设计的要求先编写各个具体的功能模块然后自底向上逐步实现整个系统
面向对象开发方法
其关键在于建立一个全面合理、统一的模型(用例模型和分析模型)系统分析、系统设计和系统实现三个阶段的界限变得不明确某项工作既可以在前一个阶段完成也可以在后一个阶段完成
面向对象需求分析方法: UML
面向对象的分析模型 主要由顶层架构图、用例与用例图、领域概念模型构成
面向对象的设计模型 包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。
当前一些大型信息系统的开发通常是将结构化方法和面向对象方法结合起来首先使用结构化方法进行自顶向下的整体划分;然后自底向上地采用00方法进行开发。因此结构化方法和面向对象方法仍是两种在系统开发领域中相互依存的、不可替代的方法。
原型化开发方法
原型法是以用户为中心来开发系统用户参与的程度大大提高。原型法适用于那些需求不明确的系统开发。事实上对于分析层面难度大、技术层面难度不大的系统适合于原型法开发。从严格意义上来说目前的原型法不是一种独立的系统开发方法而只是一种开发思想它只支持在系统开发早期阶段系统分析阶段快速生成系统的原型没有规定在原型构建过程中必须使用哪种方法。因此它不是完整意义上的方法论体系。这就注定了原型法必须与其他信息系统开发方法结合使用。
统一过程RUP开发方法
它的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品。3个显著特点: 用例驱动、以架构为中心、迭代和增量。4个流程: 初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束时都要安排一次技术评审以确定这个阶段的目标是否已经达到。适用:一个通用过程框架可以用于种类广泛的软件系统、不同的应用领域不同的组织类型、不同性能水平和不同的项目规模。
模型驱动架构开发方法
模型驱动架构Model Driven ArchitectureMDA是一种软件开发方法论它强调使用一系列抽象层次的模型并利用模型之间的转换来实现从需求到设计、直至代码生成的全过程。
MDA是一种基于诸如统一建模语言(UML)、可扩展标记语言(XML)和 公共对象请求代理体系结构(CORBA) 等一系列业界开放标准的框架。
MDA基于三种建模方法 统一建模语言(UML)包括各种软件建模所需的子语言UML主要的子语言用于表达类图、活动图与状态图。 元对象工具(MOF)是作为UML构造的一个子集而建立的具有足够的表达能力来表达重要的模型。 公共仓库元模型(CWM)标准化了数据仓库应用程序的生命周期(例如设计、构建和管理)。
在MDA开发过程可从三个不同的层次建立系统模型 1.计算无关模型(Computational Independent ModelCIM)该模型关注于业务环境和需求而不考虑计算环境。该模型通常由业务分析人员创建展示了系统的业务模型可以理解为系统需求。 2.平台无关模型(Platform Independent ModelPIM)该模型考虑在计算系统环境中的业务逻辑表示但不关注具体的实现平台。该模型通常由系统架构师创建关注系统功能可以理解为分析模型。 3.平台相关模型(Platform Specific ModelPSM)该模型关注于如何在特定平台(如JavaEE)下如何实现业务逻辑可以理解为设计模型。
CIM — PIM — PSM — 实现代码
1.基于MDA的开发过程首先通过业务领域的分析和建模构造CIM以描述需求。2.结合相关的标准规范将CIM转换为PIM。3.在PIM基础上针对不同的实现环境可以构造出不同的PSM。4.最后将PSM转换成目标代码完成开发过程。
7.4 企业应用集成技术EAI
EAI 一般包括
表示集成数据集成控制集成业务流程集成
数据集成主要有数据联邦、数据复制、基于接口的数据集成三种模式。
其中数据联邦指不同的应用共同访问一个全局虚拟数据库通过全局虚拟数据库管理系统为不同的应用提供全局信息服务。 基于接口的数据集成指不同的应用系统之间利用适配器来实现相互调用以达到集成的目标。
7.5 系统规划
系统规划阶段产出物
系统规划阶段产出物可行性研究报告、系统设计任务书。
可行性研究
可行性研究通常从经济可行性、技术可行性、法律可行性和用户使用可行性四个方面来进行分析其中经济可行性通常被认为是项目的底线。
经济可行性:也称为投资收益分析或成本效益分析主要评估项目的建设成本运行成本和项目建成后可能的经济收益。技术可行性:也称为技术风险分析研究的对象是信息系统需要实现的功能和性能以及技术能力约束。法律可行性:也称为社会可行性具有比较广泛的内容它需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性。用户使用可行性:也称为执行可行性是从信息系统用户的角度来评估系统的可行性包括企业的行政管理和工作制度、使用人员的素质和培训要求等可以细分为管理可行性和运行可行性。 管理可行性。管理可行性是指从企业管理上分析系统建设可行性。主管领导是否支持管理方法是否科学相应的管理制度改革的时机是否成熟规章制度是否产全等。运行可行性。运行可行性也称为操作可行性是指分析和测定信息系统在确定环境中能够有效工作并被用户方便使用的程度和能力。例如ERP系统建成后的数据采集和数据质量问题企业工作人员没有足够的IT技能等
盈亏平衡点
盈亏平衡点销售额总固定成本总可变成本 总固定成本[可变成本占销售额的比例*盈亏平衡点销售额]
净现值计算 7.6 需求工程
需求开发 需求获取 - 需求分析 - 需求定义需求规格说明书- 需求验证 需求管理变更控制 - 版本控制 - 需求跟踪 - 需求状态跟踪
需求分析 结构化需求分析方法
结构化分析的结果
功能模型数据流图DFD描述系统的功能需求过程建模 / 功能建模DFD 是需求分析的手段是理解和表达用户需求的重要工具是需求分析结果的表达工具。行为模型状态转换图STD描述系统的状态和引起状态转换的事件和条件。数据模型实体联系图E-R描述系统中各个实体之间的关系。数据字典对DFD中的各个元素做出详细的定义和说明。 数据流图是可以分层的从顶层 (即上下文无关数据流)到0层、1层等顶层数据流图只含有一个加工处理表示整个管理信息系统描述了系统的输入和输出以及和外部实体的数据交互。
面向对象需求分析方法
UML 统一建模语言方法 PDOA 需求分析方法
面向问题域的分析 - Problem Domain Oriented Analysis
面向问题域的分析更多的强调描述而少强调建模包括
关注问题域。关注解系统(即系统实现)的待求行为
在PDOA 方法中对整个过程有着一个清晰的定义:
(1)收集基本的信息并开发问题框架以建立问题域的类型。(2)在问题框架类型的指导下进一步收集详细信息并给出一个问题域相关特性的描述(3)基于以上两点收集并用文档说明新系统的需求。
从上面的描述中可以看出问题框架是 PDOA 的核心元素是将问题域分为一系列相互关联的子域而一个子域可以是那些可能算是精选出来的问题域的一部分。
UML 事务间关系 用例图中只包含3种关系包含include、扩展extend、泛化
UML 41 视图 需求变更 7.7 图形表示工具 程序流程图(Program Flow DiagramPFD)用一些图框表示各种操作。任何复杂的程序流程图都应该由顺序、选择和循环结构组合或嵌套而成。 IPO图Input Process Output 也是流程描述工具用来描述构成软件系统的每个模块的输入、输出和数据加工。 N-S图盒图容易表示嵌套和层次关系并具有强烈的结构化特征。但是当问题很复杂时N-S图可能很大因此不适合于复杂程序的设计。 问题分析图(PAD)是一种支持结构化程序设计的图形工具。PAD具有清晰的逻辑结构、标准化的图形等优点更重要的是它引导设计人员使用结构化程序设计方法从而提高程序的质量。 Petri图 一种对系统状态转移的天然并行的模型描述方法适合于描述异步的、并发的计算机系统模型。
7.8 系统设计基本原则 7.9 面向对象设计 7.10 SysML
系统建模语言SysMLSysML 是一种用于系统工程应用的通用系统架构建模语言。它是由对 UML2.0 的子集进行重用和扩展而来的。
SysML 已成为基于模型的系统工程MBSE应用程序的事实上的标准系统架构建模语言。
SysML 为 UML 添加了两个有用的图表用法需求图扩展了UML类图;参数图扩展了UML类和复合结构图
SysML在一定程度上重用了UML部分元模型同时针对系统工程对UML进行扩展增加了诸如需求、块、限制之类描述系统的元素和相关图形支持。
UML中被SysML重用的部分称为UML4SysMLSysML Profile是扩展的部分。
SysML为支持从结构、行为模型、需求和参数四个方面来构建系统模型
结构模型强调系统的层次以及对象之间的相互连接关系行为模型强调系统中对象的行为包括它们的活动、交互和状态历史需求模型强调需求之间的追溯关系以及设计对需求的满足关系参数模型强调系统或部件的属性之间的约束关系。
模块定义图Block Definition DiagramBDD用于表示模块和值类型之类的元素定义能够在可操作的系统中存在的事物类型以及那些元素之间的关系。BDD的通常用法包括显示系统层级关系树以及分类树。
内部模块图Internal Block DiagramIBD用于指定单个模块的内部结构。更精确的说法是IBD会显示模块内部组成部分之间的关系以及它们之间的接口。
参数图Parametric Diagram用于表示一种或多种约束——特别是等式和不等式——如何与系统的属性绑定。参数图支持工程分析包括性能、可靠性、可用性、电力、人力和成本。参数图还可以用于支持候选物理架构的优劣势研究。
需求图Requirement Diagram用于表示基于文字的需求、需求之间7种关系。
基于模型的系统工程MBSE
基于模型的系统工程MBSE又称基于模型的系统开发MBSD是一种系统工程过程范例强调严格的体系结构建模原则和最佳实践应用于整个系统开发生命周期SDLC中的系统工程活动。这些系统工程活动包括但不限于需求分析功能分析性能分析系统设计贸易研究系统架构规范以及系统验证和验证VV。
7.11 设计模式 7.12 白盒测试用例
覆盖级别从低至高分为 语句覆盖SC: 逻辑代码中的所有语句都要被执行一遍覆盖层级最低因为执行了所有的语句不代表执行了所有的条件判断。 判定覆盖DC: 逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。 eg: (a b c) in [true, false] 条件覆盖CC: 针对每一个判断条件内的每一个独立条件都要执行一遍真和假。eg: (a b c), a in [true, false], b in [true, false], c in [true, false] 条件判定组合覆盖CDC: 同时满足判定覆盖和条件覆盖。 路径覆盖: 逻辑代码中的所有可行路径都覆盖了覆盖层级最高。
7.13 软件度量
McCabe度量法: 又称为环路复杂度假设有向图中有向边数为m节点数为n则此有向图的环路复杂度为 m-n2。 7.14 垃圾回收
垃圾回收GCGarbage Collection是指程序把不用的内存空间视为垃圾并回收掉的整套动作。
GC 要做的有两件事
找到内存空间里的垃圾回收垃圾让程序能再次利用这部分空间。
没有 GC 可能引发的问题内存泄露悬垂指针错误释放
内存泄露内存空间在使用完毕后未释放该内存空间就会发生内存泄露。即无法被使用但它又会持续存在下去总有一刻内存会被占满甚至还可能导致系统崩溃。悬垂指针在释放内存空间时如果忘记初始化指向已经回收的内存地址对象已释放的指针这个指针就会一直指向释放完毕的内存空间。如果在程序中错误地引用了悬垂指针 就会产生无法预期的 BUG。错误释放一旦错误释放了使用中的内存空间下一次程序使用此空间时就会发生故障。
评价 GC 算法的性能时采用以下 4 个标准
吞吐量。运行用户代码时间 / (运行用户代码时间 垃圾收集时间)最大暂停时间。大部分 GC 算法都会在 GC 执行过程中令应用程序暂停执行堆使用效率。访问的局部性。
三种最基本的 GC 算法
GC 标记-清除法。由标记阶段和清除阶段构成。标记阶段是把所有活动对象都做上标记的阶段。清除阶段是把那些没有标记的对象也就是非活动对象回收的阶段。GC 引用计数法。让所有对象事先记录下“有多少程序引用自己”。形象点儿说就是让各对象知道自己的“人气指数”让没有人气的对象自己消失。GC 复制算法。就是只把某个空间里的活动对象复制到其他空间把原空间里的所有对象都回收掉。
7.15 遗留系统 7.16 系统维护
系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度其评价指标如下:
(1)易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。(2)易改变性。软件产品使指定的修改可以被实现的能力实现包括编码、设计和文档的更改。(3)稳定性。软件产品避免由于软件修改而造成意外结果的能力。(4)易测试性。软件产品使已修改软件能被确认的能力。(5)维护性的依从性。软件产品遵循与维护性相关的标准或约定的能力。
系统维护包括硬件维护、软件维护和数据维护其中软件维护类型如下
正确性维护:发现了bug而进行的修改。适应性维护:由于外部环境发生了改变被动进行的对软件的修改和升级。完善性维护:基于用户主动对软件提出更多的需求修改软件增加更多的功能使其比之前的软件功能、性能更高更加完善。预防性维护:对未来可能发生的bug进行预防性的修改。
8 软件架构设计
8.1 架构和框架
通过框架实现了架构的沉淀落地框架的质量决定了系统整体架构的质量对框架的验证验证了整体系统架构
8.2 架构评估
软件架构评估有三种方式基于调查问卷检查表基于度量基于场景。
基于场景的方法主要有三种
软件架构分析法 SAAMSoftware Architecture Analysis Method架构权衡分析法 ATAMArchitecture Tradeoff Analysis Method成本效益分析法 CBAMCost Benefit Analysis Method
SAAM 主要针对可修改性也可用于可移植性、可扩充性等。
SAAM的主要输入是问题描述、需求说明和架构描述其分析过程主要包括
1场景开发2架构描述3单个场景评估4场景交互评估5总体评估。
ATAM 核心是结合质量属性效用树对系统进行评价确定风险点、敏感点、权衡点并对系统架构做出决策和折中。整个评估过程强调以质量属性作为评估核心主要针对性能、实用性、安全性和可修改性在系统开发之前对这些质量属性进行评价和折中。
ATAM分成4个阶段
1场景和需求收集2架构视图描述和场景实现3质量属性模型构造和分析4质量属性评价和折中
8.3 基于架构的软件设计 ABSD
ABSDArchitecture-Based Software Design
架构驱动强调由业务商业、质量、功能需求的组合驱动架构设计。
描述软件架构视角视图描述需求用例(描述功能需求) 质量属性场景(描述质量需求)
使用ABSD方法的3个基础 1功能的分解使用已有的基于模块的内聚和耦合技术。 2选择架构风格实现质量和业务需求。 3软件模板的使用软件系统的结构复用。
基于架构的软件开发
架构设计过程 1提出架构模型 - 2映射构件 - 3分析构件间相互作用 - 4产生架构 - 5设计评审
架构复用的过程 1获取可复用的软件资产复用的前提- 2管理可复用资产构件库- 3使用可复用资产组装与集成形成系统
8.4 鸿蒙系统架构
鸿蒙整体采用分层的层次化设计从上向下依次为
应用层系统应用第三方非系统应用 app应用框架层多语言的框架系统服务层核心能力通过框架层对应用层程序提供服务。内核层多内核针对不同资源受限设备选用合适的OS内核屏蔽多内核差异。
HarmonyOS的4个技术特征
分布式架构首次用于终端OS跨终端无缝协同。确定时延引擎高性能IPC技术系统天生流畅。微内核统一IDE一次开发多端部署跨终端生态共享。
2024年 Harmony Next 会开始使用全自研内核去掉了传统的 AOSP 代码仅支持鸿蒙内核和鸿蒙系统的应用。
在 Harmony NEXT 上官方现采用全新的 ArkTS 和 ArkUI
ArkTS在保持原 TypeScript 基本语法风格的基础上对 TS 的动态类型特性施加了更严格的约束引入静态类型。ArkUI一套构建分布式应用界面的声明式 UI 开发框架。
8.5 信息系统架构
MVC 架构 在 J2EE架构中Controller 控制器指 Web 服务器层 Model模型层指应用逻辑实现及数据持久化部分
企业信息系统总体框架由四个部分组成 1战略系统、2业务系统、3应用系统、4信息基础设施
企业信息基础设施又分为三部分 1技术基础设施、2信息基础设施、3管理基础设施
TOGAF(The Open Group Architecture Framework)是一种开放企业架构框架标准他是基于一个迭代的过程模型支持最佳实践和一套可重用的现有架构资产。
TOGAF 的关键是架构开发方法Architecture Development Meth: ADM,他是个能满足商务需求的企业架构。
信息系统生命周期五个阶段 1系统规划阶段输出 可行性分析报告、系统设计任务书 2系统分析阶段又称逻辑设计阶段输出 系统说明书 3系统设计阶段又称物理设计阶段输出 系统设计说明书 4系统实施阶段输出 实施进度报告、系统测试分析报告 5系统运行和维护阶段
8.6 层次式架构
层次式架构的划分 表现层负责向用户呈现数据和交互界面用户输入处理将用户的操作转化为对业务逻辑层的请求并将业务逻辑层返回的结果呈现给用户。 业务逻辑层BLL负责实现业务逻辑和规则接受表现层的请求通过调用数据访问层提供的接口来完成数据的读取或更新并对数据进行处理和转换然后将结果返回给表现层。 数据访问层DAL负责数据库的访问执行数据的读取、写入、更新、删除等操作。封装对数据库的访问细节提供统一的操作数据库的接口供业务逻辑层调用。 数据层是实际存储数据的地方。
UIP (UserInterface Process)
UIP 提供了一个扩展的框架用于简化用户界面与商业逻辑代码的分离的方法。
使用UIP框架的应用程序把表现层分为以下几层 1UI ComponentsUIC)这个组件就是原来的表现层用户看到并与之进行交互的组件负责获取用户的数据并返回结果。 2UI Process ComponentsUIP)用于协调用户界面的各个部分使其配合后台的活动、以及状态和视图的管理。对用户不可见为UIC提供了重要的支持。
UIP的组件主要负责的功能是 管理经过UIC的信息流。 管理UIP中各个事件之间的事务。 修改用户过程的流程以响应异常。 将概念上的用户交互流程从实现/涉及的设备上分离出来。 保持内部的事务关联状态通常是持有一个或多个的与用户交互的事务实体。 业务逻辑层
业务逻辑层采用容器的形式降低业务和相邻各层的耦合有效防止业务层代码渗透到表示层便于系统功能的开发、代码重用和管理。 1Domain Model是领域层业务对象仅包含业务相关的属性。 2Service是业务过程实现的组成部分是应用程序的不同功能单元通过在这些服务之间定义良好的接口和契约联系起来。 3Control服务控制器通过服务控制器实现不同服务之间的切换将服务的实现和服务的转向控制分离。“服务和控制的分离”
Domain Model — Service — Control 关系 Service的运行依赖Domain Model的状态。 Service根据业务规则改变Domain Model的状态。 Control根据Domain Model的状态决定Service之间的执行顺序和相互关系。
工厂模式在数据访问层应用
工厂模式定义一个用于创建对象的接口让子类决定实例化哪一个类使一个类的实例化延迟到其子类。
Entity Bean
①CMPContainer Managed Persistence容器管理的持续性。构件的相关数据库操作由容器自动完成不需要在bean 中编写数据库操作的代码。②BMPBean Managed PersistenceBean管理的持续性。构件的相关数据库操作由开发人员在代码中通过JDBC编程来实现。
CMP是由EJBContainer来维护而BMP则是由Bean自行维护资料的一致性。
8.7 面向服务架构SOA
ref: https://mp.weixin.qq.com/s/gu2ppkRqCZhi_Hogb7nTmA
BPEL: 面向Web服务的业务流程执行语言
SOA 与微服务的区别
1微服务相比于 SOA 更加精细微服务更多地以独立进程方式存在相互之间并无影响2微服务提供的接口方式更加通用化各种终端都可以调用无关语言、平台限制3微服务更加倾向于分布式去中心化的部署方式在互联网业务场景下更适合
可将 SOA 视为组件模型SOA 架构以企业服务总线链接各个子系统是集中式的技术架构。
以服务为中心的企业集成采用 “关注点分离Separation of Concern” 的方法规划企业集成中的各种架构元素同时从 服务视角 规划每种架构元素提供的服务以及服务如何被组合在一起完成某种类型的集成。
从服务为中心的视角看企业集成的架构可分为6类
1业务逻辑服务2控制服务3连接服务企业服务总线4业务创新和优化服务用于监控业务性能和变化5开发服务贯彻整个软件开发生命周期的开发平台建模服务、设计服务、实现服务、测试服务6IT服务管理支持业务系统运行的各种基础设施管理能力或服务
SOA的设计模式
注册表模式
服务注册服务提供者向注册表公布他们的功能。服务位置查询注册服务寻找符合要求的服务。服务绑定消费者利用检索到的服务合同来开发代码开发的代码将与注册的服务绑定、调用注册的服务、与它们实现互动。
企业服务总线ESB模式
由中间件技术实现的支持面向服务架构的基础软件平台支持异构环境中的服务以基于消息和事件驱动模式的交互。
ESB的核心功能
提供位置透明的消息路由和寻址服务。提供服务注册和命名的管理过程。支持多种消息传递范型发布-订阅、请求-响应。支持多种可广泛使用的传输协议。支持多种数据格式及其相互转换。提供日志和监控功能。
常见的微服务设计模式 聚合器聚合器调用多个微服务实现系统应用程序所需功能具体有两种形式 (1) 将检索到的数据信息进行处理并直接展示(2) 对获取到的数据信息增加业务逻辑处理后再进一步发布成一个新的微服务。 链式返回一个经过合并处理的响应服务之间形成一条调用链。 数据共享多个微服务共享缓存与数据库存储。 异步消息传递写入一个消息队列中实现业务逻辑以异步方式运行。
9 系统可靠性
9.1 系统质量属性
软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分 开发期属性 易理解、可扩展、可重用、可测试、可维护、可移植 运行期属性性能、安全、可伸缩、互操作、可靠、可用、鲁棒也叫健壮性容错性
可修改性 4个方面
可维护性可扩展性结构重组重新组织软件系统的构件及构件间的关系可移植性
质量属性场景主要关注的质量属性可用性、可修改、性能、可测属性、易用性、安全性6类。
质量属性场景
质量属性可以通过场景来描述以便更好地理解和分析。
它是一个具体的质量属性需求是利益相关者与系统的交互的简短陈述。
质量属性场景由6部分组成 1.刺激源(Source): 生成刺激的实体(人、计算机或其他) 2.刺激(Stimulus): 刺激到达系统时需要考虑的条件 3.环境(Environment): 该刺激在某些条件内发生当激励发生时系统可能处于过载、运行或其他情况。 4.制品(Artifact): 某个制品被激励。可能是整个系统也可能是系统的一部分。 5.响应(Response): 激励到达后采取的行动。 6.响应度量(Measurement): 当响应发生时应当能够以某种方式对其度量以对需求进行测试。
健壮性 VS 容错性
健壮性和容错性在概念上有重叠但重点不同 健壮性: 健壮性是系统在面对异常输入或异常操作时能够正常运行并终止。健壮系统在面对不可恢复的错误时会采取预先设定的措施进行安全终止以避免更大的损失或风险。 容错性: 是指系统在部分组件发生故障时仍能继续提供正常或降级的服务。容错性主要关注的是系统如何通过冗余、备份和自动切换等机制在发生故障时维持功能。
关键应急响应指标 MTBFMean Time Between Failures平均无故障时间指两次故障之间的平均时间通常用于衡量设备或系统的可靠性。 MTTDMean Time to Detect平均故障检测时间指从故障发生到检测到故障的平均时间。较短的MTTD意味着系统能够更快地发现故障有助于缩短MTTR。 MTTFMean Time to Failure平均故障间隔时间指设备或系统的平均无故障运行时间。 MTTRMean Time to Repair平均故障修复时间是指故障发生到故障修复完成的平均时间。用于衡量系统可用性和可靠性。MTTR越短表示系统修复故障的能力越强系统的可用性和可靠性越高 9.2 系统架构的脆弱性分析
微服务架构
分布式系统的复杂结构服务之间的通信机制服务管理的复杂性
微内核架构
难以进行良好的整体化优化核心态只实现了最基本的系统操作进程间通信开销比宏内核系统要大的多通信损失率高
MVC架构
层次结构的复杂性降低运行效率。视图与控制器间紧密连接视图对模型数据的低效率访问
事件驱动架构
组件组件间数据交换组件间逻辑关系事件驱动容易进入死循环高并发的脆弱性固定流程的脆弱性因为事件驱动的响应流程基本都是固定的如果操作不当容易引发安全问题。
10 系统安全性
10.1 信息安全
安全架构的三道防线
产品安全架构安全技术体系架构审计架构
信息系统的威胁 4 个方面
人为蓄意破坏灾害性攻击系统故障人员无意识行为
信息安全的5个基本要素
网络安全威胁
非授权访问信息泄露或丢失破坏数据完整性拒绝服务攻击利用网络传播病毒
密钥安全 密码法将密码分为核心密码、普通密码和商用密码。核心密码、普通密码属于国家秘密。核心密码保护信息的最高密级为绝密级普通密码保护信息的最高密级为机密级。
国密算法分类
SM1: 对称加密算法分组密码算法分组长度为128位密钥长度都为 128 比特SM2非对称加密算法用来做非对称加解密以及数字签名。类似rsaSM3hash摘要算法用来做数字指纹类似md5SM4对称加密算法用来做加解密类似aes分组算法用于无线局域网产品。SM7分组密码算法对称算法。SM7适用于非接触式IC卡应用包括身份识别类应用(门禁卡、工作证、参赛证)票务类应用(大型赛事门票、展会门票)支付与通卡类应用积分消费卡、校园一卡通、企业一卡通等。SM9标识密码算法适用于云技术的密码服务、电子邮件安全、智能终端保护、物联网安全、云存储安全等。
10.2 访问控制模型
ACL(Access Control List)、RBAC(Role-Based Access Control)、DAC(Discretionary Access Control)、MAC(Mandatory Access Control) 都是从系统的角度(控制环境是静态的)出发保护资源。其访问控制的原理可以简单地描述为:如果主体对某客体有访问操作请求,而且主体拥有操作权限,则提供访问操作。
TBAC是基于任务的访问控制模型。它从工作流中的任务角度建模,可以依据任务和任务状态的不同,对权限进行动态管理。适用于工作流、分布式处理和事务管理系统中的决策制定与权限管理。
基于任务的访问控制TBAC模型包括以下四个部分 1. 工作流Workflow工作流定义了任务的执行流程和步骤描述了任务之间的依赖关系和执行顺序。工作流确保任务按照预定的流程进行并且能够有效管理和监控任务的执行。 2. 授权结构体Authorization Structure授权结构体定义了角色、用户和任务之间的关系确定了哪些用户和角色有权执行特定的任务。它是任务与权限之间的映射关系。 3. 受托人集Trustee Set受托人集是指被授权执行任务的用户集合。受托人集中的用户通过其角色或直接授权来获取执行任务的权限。 4. 许可集Permission Set许可集定义了每个任务所需的具体权限。这些权限与系统资源和操作相关联确保用户在执行任务时具有适当的权限。
10.3 安全模型 一. HRU模型【基本模型】
HRU访问控制矩阵模型模型是一种计算机安全的访问控制模型通过使用保护矩阵和访问控制规则来描述和控制系统中对资源的访问。它主要解决了系统访问请求的安全性和合法性问题。
二. BLPBell-LaPadula模型【机密性】
Bell-LaPadula模型主要用于保护信息的机密性。特点
信息只能从高安全级别向低安全级别进行传输不允许反向传输。只能下读只能从高安全级别向相同或更高安全级别的写入信息。只能上写
安全规则
简单安全规则下读星属性安全规则上写强星属性安全规则同级别读写自主安全规则使用访问控制矩阵
三. Chinese Wall模型【机密性】
是应用在多边安全系统中的安全模型通过行政规定和划分、内部监控、IT系统等手段防止各部门之间出现有损客户利益的利益冲突事件。
安全策略基础客户访问的信息不会与当前他们可支配的信息产生冲突。
访问客体的安全规则
与主体曾经访问过的信息属于同一公司数据集合的信息墙内信息可以访问。属于完全不同的利益冲突组可以访问。主体能够对一个客体进行写的前提主体未对任何属于其他公司数据集进行过访问。
四. Biba模型【完整性】
Biba模型主要用于保护信息的完整性通过限制主体的写入操作确保高完整性级别的对象不受低完整性级别的主体的非授权修改。特点
只能下写只能上读
五. Clark-Wilson模型【完整性】
将完整性目标、策略、机制融为一体的模型。
用户完整性职责隔离目标。数据完整性应用相关的完整性验证进程。过程完整性对于变换过程的应用相关验证。
CWM的主要特征
采用Subject / Program / Object 方式Subject只能通过Program访问Object。权限分离原则将要害功能分为2个或多个Subject防止已授权用户进行未授权的修改。具有审计能力。
10.4 系统安全架构
围绕 技术安全、管理安全、组织安全进行全面考虑。 WPDRRC模型
WPDRRC模型是中国“八六三”信息安全专家组提出的信息系统安全保障体系建设模型它是在PDRR模型保护、检测、响应、恢复的基础上增加了预警Warning和反击Counterattack两个环节。
预警 waring保护 protect加密机制、数字签名、访问控制、防火墙检测 detect入侵检测、攻击检测、系统脆弱性检测、数据完整性检测响应 react封堵、隔离、报告恢复 restore容错、冗余反击 counterattack
信息系统安全设计的2个方面
系统安全保障体系安全服务、协议层次、系统单元信息安全体系架构物理安全、系统安全、网络安全、应用安全、安全管理
10.5 系统安全保护等级
中国国家标准GB 17859-1999《计算机信息系统安全保护等级划分准则》中将计算机系统安全级别从低到高分为以下四组七等级 最低级别D级称为自主保护级它又细分为D1级。 中间级别C级称为系统审计保护级分为C1级自主安全保护和C2级受控访问保护。 较高级别B级称为安全标记保护级包括B1级标记安全保护、B2级结构化保护和B3级安全域。 最高级别A级称为访问验证保护级仅有A1级是安全级别中最高的要求最为严格提供形式化的安全验证。
10.6 Kerberos认证
Kerberos认证流程中涉及到三种角色客户端Client、服务端Server、密钥分发中心KDCKey Distribution Center。
KDC是一个网络服务提供ticket和临时会话密钥。 由三个部分组成认证服务器Authentication ServerAS、票证授予服务器Ticket Grantion ServerTGS、Kerberos数据库。 认证服务器AS: 负责认证客户端的身份并发放客户端访问TGS的TGT(Ticket Grantion Ticket票据授予票据)。 票证授予服务器TGS: 用来发放客户端访问服务端所需的服务授予票据ticket。 Kerberos数据库客户端和服务端添加进keberos系统时有对应的密钥数据库负责存储这些密钥并保存客户端和服务端的基本信息如用户名、用户IP地址、服务端IP、服务端名称等。 1.客户端向KDC AS获取TGT(票据授予票据)2.客户端向KDC TGS获取目标服务器的ST(服务授予票据)3.客户端向服务端发送通信请求
Kerberos具备如下三点优势
密码无需进行网络传输。基于 Ticket 实现身份认证保障密钥安全性。双向认证。整个认证过程中不仅需要客户端进行认证待访问的服务也需要进行身份认证。高性能。密钥采用对称加密方式相比于SSL的密钥操作快几个数量级。一旦Client获得用过访问某个Server的Ticket该Server就能根据这个Ticket实现对Client的验证而无须KDC的再次参与。
10.7 RADIUS远程访问拨号用户服务
AAA验证、授权和记账Authentication、Authorization、Accounting是一种管理框架可以用多种协议来实现是一个能够处理用户访问请求的服务器程序提供验证授权以及帐户服务主要目的是管理用户访问网络服务器对具有访问权的用户提供服务。
RADIUSRemote Authentication Dial In User Service远程访问拨号用户服务是应用最广泛的AAA协议。
NAS网络接入服务器作为RADIUS客户端向远程接入用户提供接入及与RADIUS服务器交互的服务。RADIUS服务器上则存储用户的身份信息、授权信息以及访问记录对用户进行认证、授权和计费服务。
RADIUS 软件架构分为三个层面:协议逻辑层、业务逻辑层和数据逻辑层
协议逻辑层处理网络通信协议的建立、通信和停止方面的工作。业务逻辑层业务逻辑进程分为认证、计费和授权三种类型不同的业务逻辑进程可以接收不同协议进程之间的信息并进行处理。数据逻辑层需要对来自业务逻辑处理线程统一管理与处理数据库代理池的数据由数据库代理池统一连接数据库以减少对数据库系统的压力。
RADIUS 是基于 UDP 的一种客户机/服务器协议。 RADIUS 协议的认证端口是1812 计费端口是1813。
11 扩展知识
11.1 边缘计算
边缘计算特点
1联接性联接性是边缘计算的基础2数据第一入口边缘计算作为物理世界到数字世界的桥梁3约束性边缘计算产品需要适配工业现场相对恶劣的工作条件与运行环境4分布性实际部署天然具备分布式特征
六种边云协同既资源协同、数据协同、智能协同、应用管理协同、业务管理协同、服务协同
11.2 SSE
什么是SSE
SSEServer-Sent Events是一种用于实现服务器主动向客户端推送数据的技术也被称为“事件流”Event Stream。它基于 HTTP 协议利用了其长连接特性在客户端与服务器之间建立一条持久化连接并通过这条连接实现服务器向客户端的实时数据推送。
SSE和Socket的区别 SSE 基于 HTTP 协议利用了其长连接特性通过浏览器向服务器发送一个 HTTP 请求建立一条持久化的连接。而 WebSocket 则是通过特殊的升级协议HTTP/1.1 Upgrade 或者 HTTP/2建立新的 TCP 连接与传统 HTTP 连接不同。 SSE 可以传输文本和二进制格式的数据但只支持单向数据流即只能由服务器向客户端推送数据。WebSocket 支持双向数据流客户端和服务器可以互相发送消息并且没有消息大小限制。 SSE 的实现比较简单都是基于 HTTP 协议的与普通的 Web 应用没有太大差异因此风险相对较低。WebSocket 则需要通过额外的安全措施如 SSL/TLS 加密来确保数据传输的安全性避免被窃听和篡改否则可能会带来安全隐患。
chatGPT 返回的数据 就是使用的SSE 技术实时数据大屏 如果只是需要展示 实时的数据可以使用SSE技术 而不是非要使用webSocket
11.3 仓颉语言
仓颉编程语言作为一款 面向全场景应用开发 的现代编程语言。
高效编程仓颉是一门多范式编程语言支持函数式、命令式和面向对象等多种范式。安全可靠仓颉追求编码即安全通过静态类型系统和自动内存管理确保程序的类型安全和 null safety等内存安全。轻松并发仓颉语言实现了轻量化用户态线程和并发对象库让高效并发变得轻松。卓越性能仓颉编译器及运行时从全栈对编译进行优化包括编译器前端基于CHIRCangjie HighLevel IR高层编译优化基于后端的编译优化基于运行时的优化。
仓颉语言的架构通常包括以下组件 前端负责词法分析、语法分析和生成抽象语法树Abstract SyntaxTree即 AST。前端还进行初步的语义分析和类型检查。 中端负责生成中间表示IR并进行各种优化如常量折叠、死代码消除和循环优化等。 后端负责将中间表示转换为目标代码可以是虚拟机字节码或机器代码。后端还包括代码生成和优化器。 运行时环境提供程序执行所需的支持包括内存管理、垃圾回收和标准库。 仓颉在编译架构中引入了一层 Cangjie High-Level IR简称 CHIR ref: https://zhuanlan.zhihu.com/p/709603695
11.4 数字孪生
数字孪生生态系统包含 基础支撑层、数据互动层、模型构建与仿真分析层、共性应用层、行业应用层 基础支撑层: 涉及物联网终端设备如芯片和传感器负责数据采集和发送。 数据互动层: 包括数据采集、传输和处理。数据采集通常通过DCS、PLC系统和智能仪表进行。 模型构建与仿真分析层: 提供数据建模、仿真和控制服务。核心技术包括测绘扫描、几何建模等主要由国有测绘企业主导。 共性应用层: 涵盖描述、诊断、预测和决策四个方面需要软件定义的工具和平台支持。 行业应用层: 数字孪生技术在智慧城市、交通、水利、工程、工业生产、能源、自动驾驶和公共应急等领域的应用服务。
信创即信息技术应用创新产业简称“信创”。信创产业主要包括基础硬件、基础软件、应用软件、信息安全四大领域。
11.5 宏编程
宏是一种编程语言的扩展机制宏通常指的是一种预处理指令用于在编译前展开一系列的代码块它允许程序员在编译阶段对源代码进行转换和操作从而提供更高层次的抽象和灵活性。
宏有两种形式文本宏和函数宏。
文本宏是在编译时进行简单的文本替换将宏名称替换为宏定义的内容。函数宏则是在编译时通过函数调用进行替换可以含有参数和返回值。
宏的主要作用包括但不限于
代码重用宏可以将重复的代码片段封装起来通过宏名调用减少代码冗余。提高效率在编译阶段之前宏通过预处理器展开可以避免在运行时进行函数调用从而提高程序的执行效率。条件编译宏允许根据不同的条件编译不同的代码块使得程序更加灵活能够适应不同的编译环境或平台。
以下是关于宏的五个关键点
模板替换宏通过将源代码中的标识符替换为事先定义好的模板来实现代码的转换。例如宏可以将一段常用的代码片段封装为一个宏然后在源代码中使用宏的名字编译器会在编译阶段将宏展开成实际的代码。这样可以减少重复性代码的编写提高代码的可读性和可维护性。参数化宏可以使用参数来增加灵活性和通用性。程序员可以在宏定义中定义参数并在宏的使用处传递实际的参数值。这样可以根据具体的需求生成不同的代码。参数化使得宏可以适用于不同的场景提高代码的复用性。编译时计算宏可以在编译阶段进行计算和操作从而在运行时之前就生成结果。这种编译时计算可以帮助程序员在编译阶段检测错误和优化代码提高程序的性能和效率。元编程宏可以用来实现元编程即编写能够生成和操作代码的代码。通过宏程序员可以在编译阶段扩展和改变程序的结构和行为从而实现更高级别的抽象和自动化。跨语言支持宏不仅仅局限于某一种编程语言它可以跨越不同的编程语言进行使用。许多编程语言都支持宏机制例如C语言的宏、Lisp语言的宏、Rust语言的宏等。通过宏的跨语言支持程序员可以将某种编程模式或者技巧应用到多种编程语言中提高自己的编程能力和效率。
11.6 LLVM
LLVM: Low Level Virtual Machine, 低级虚拟机的缩写。
LLVM 是一个新型编译器框架用于将语言代码生成本机代码。可用它来开发并推出新的编程语言也可以增强现有编程语言。
LLVM 是一个从任何类型的源代码生成目标代码的框架。LLVM 专为可移植性而设计。
LLVM 是一个用于以编程方式创建本机机器代码的库。开发人员使用其 API 以其称为中间表示IR的格式生成相关指令。然后 LLVM 可以将 IR 编译为独立的二进制文件对代码执行 JIT即时编译这样就可在运行时环境例如该语言的解释器或运行时的上下文中正常运行。
LLVM的架构可以分为三个主要部分前端、中间表示IR和后端。 前端前端负责将源代码转换为LLVM的中间表示。LLVM支持多种语言的前端例如Clang用于C/C、Swift、Rust、Node.js、Go和Python等。 中间表示IRLLVM的IR是一种强类型、低级别的指令集设计用于优化和代码生成。IR是LLVM的核心支持三种形式文本、二进制和内存中的数据结构。 后端后端将IR转换为目标机器码。LLVM的后端支持多种架构如X86、ARM、PowerPC等。 LLVM 没有提供垃圾收集器机制但它提供了实现垃圾收集的工具 允许用元数据标记代码从而使编写垃圾收集器变得更容易。
12 应用软件
12.1 NoSQL NoSQL 体系框架
接口层为上层应用提供数据调用接口数据逻辑模型层数据的逻辑表现形式数据分布层定义了数据是如何分布的数据持久层定义了数据的存储形式
12.2 Elasticsearch
概念
分片Shards
Shards代表分片。当索引的数据量太大时受限于单个节点的内存、磁盘处理能力等节点无法足够快地响应客户端的请求此时需要将一个索引上的数据进行水平拆分。拆分出来的每个数据部分称之为一个分片。
实际应用中每个分片都会放到不同的服务器上。 在创建索引时需要指定分片的数量并且分片的数量一旦确定就不能更改。
es会把查询发送给每个相关的分片并汇总各个分片的查询结果。 对上层的应用程序而言分片是透明的也就是说应用程序并不知道分片的存在。
分词器
分词是将全文本转换为一系列单词的过程这些单词称为term或者token而这个过程称为分词。
分词是通过 分词器Analyzer 来实现的比如用于中文分词的 IK分词器 等。当然你也可以实现自己的分词器例如可以简单将全文本以空格来实现分词。ES内置了一些常用的分词器。 Standardstandard分词器通常用于处理多种语言的文本它会识别并拆分单词、数字、电子邮件地址、网址等并且能够处理一些标点符号。对于中文、日文、韩文等不使用空格的语言Standard 分词器可能不是最佳选择因为它不能很好地理解这些语言的语法规则。例如“Hello, World!” 分词结果为[“Hello”, “,”, “World”, “!”]。 Simplesimple分词器非常基础它只是简单地按照非字母字符进行分割即将所有的非字母字符视为分隔符。因此所有连续的字母序列都会被视为一个词汇单元而任何非字母字符如空格、标点符号、数字都会被丢弃或用作分隔标志。例如“Hello, World! How are you?”分词结果为[“Hello,”, “World!”, “How”, “are”, “you?”] Whitespacewhitespace分词器仅仅根据空白字符如空格、制表符、换行符来分割文本不会去除任何字符也不会考虑标点符号。这意味着标点符号会被当作独立的词汇单元处理。例如“Hello, World! How are you?”分词结果为[“Hello,”, , “World!”, , “How”, , “are”, , “you?”] Keywordkeyword分词器并不真正执行分词操作。相反它会将整个输入文本作为一个单独的词汇单元输出。这意味着输入文本中的所有内容都被认为是一个不可分割的整体。例如“Hello, World!” 分词结果为 [“Hello, World!”]。
其他
Settings Settings是对集群中索引的定义信息比如一个索引默认的分片数、副本数等。
MappingMapping 表示定义索引中字段(Field)的存储类型、分词方式是否存储等信息类似于mysql数据库中的表结构信息。
一个索引的 Mapping一旦创建若已经存储了数据就不可修改了。
架构 节点类型
数据节点负责数据的存储相关的操作如对数据进行增、删、改、查和聚合等。
候选主节点是被选举为主节点的节点在集群中只有候选主节点才有选举权和被选举权其他节点不参与选举工作。 一旦候选主节点被选举为主节点则主节点就要负责创建索引、删除索引、追踪集群中节点的状态以及跟踪哪些节点是群集的一部分并决定将哪些分片分配给相关的节点等。
在es中每个节点可以有多个角色节点既可以是候选主节点也可以是数据节点。
在做数据检索时es默认会搜索所有分片上的数据最后在主节点上汇总各个分片数据并进行排序处理后返回最终的结果数据。
分段存储
索引数据在磁盘上的是以分段形式存储。
“段”是es从 Lucene 中继承的概念。在索引中索引文件被拆分为多个子文件其中每个子文件就叫作“段”每个段都是一个倒排索引的小单元。
引入分段的原因
不分段会使数据更新时效性很差、且耗费大量资源可以减少锁的使用提高并发大大提高es的读写性能当分段被写入磁盘后会生成一个提交点提交点意味着一个用来记录所有段信息的文件已经生成当一个段一旦拥有了提交点就表示从此该段仅有读的权限永远失去写权限
更新操作由于分段不可修改的特性那么es无法通过修改旧的段来反映文档的更新。所以更新操作变成了“先删除后新增”两个操作的结合。
延迟写策略
为了提升写的性能es没有每新增一条数据就增加一个段到磁盘上而是采用延迟写策略。
由于新数据会持续写入内存而内存中的数据并不是以段的形式存储所以不能提供检索功能。
只有当数据经由内存刷新到文件缓存系统并生成新的段后新的段才能供搜索使用而不需要等到被刷新到磁盘才可以搜索。
段合并机制
在es自动刷新流程中每秒都会创建一个新的段。这就会导致短时间内段的数量猛增而当段数量太多时会带来较大的资源消耗如对文件句柄、内存和 CPU 的消耗。
段合并机制在后台定期进行从而小的段被合并到大的段然后这些大的段再被合并到更大的段。
在段合并过程中es会将旧的已删除文档从文件系统中清除。被删除的文档不会被拷贝到新的大段中当然在合并的过程中不会中断索引和搜索。
ES 优化
写优化
副本数量0 首次 初始化数据时将副本设置为0写入完毕再改回避免了副本建立索引的过程自动生成id 可以避免写前判断是否存在的过程禁用评分延长索引刷新间隔将多个索引操作放入到batch进行处理
读优化
客户端使用别名访问对数据进行分组按照日月年不同维度分组查询可集中在局部index中使用Filter代替Query减少打分计算使用bool组合query和filter查询
12.3 Kafka 一个Borker就是Kafka集群中的一个实例或者说是一个服务单元。
Kafka 在consumer之上加了一层group。同一个group的consumer可以并行竞争消费同一个topic的消息但是同group的consumer不会重复消费。
kafka中消息订阅和发送都是基于某个topic。
分区 Partition
Topic可以被分成若干分区分布于kafka集群中方便扩容 单个分区内是有序的partition设置为一才能保证全局有序
副本Replicas
每个主题被分为若干个分区每个分区有多个副本。
生产者Producer
生产者在默认情况下把消息均衡地分布到主题的所有分区上
直接指定消息的分区根据消息的key散列取模得出分区轮询指定分区。
Kafka 高吞吐量
零拷贝: 减少内核态到用户态的拷贝磁盘通过sendfile实现DMA 拷贝Socket buffer顺序读写: 充分利用磁盘顺序读写的超高性能页缓存mmap: 将磁盘文件映射到内存, 用户通过修改内存就能修改磁盘文件。
12.4 RocketMQ
满足各种严苛场景下的高级特性需求例如异步通知、微服务间解耦、削峰填谷、缓存同步、实时计算等。
RocketMQ 特色解决分布式事务问题分布式事务消息
RocketMQ 消息类型
普通消息先进先出的顺序消息系统解耦且保证数据最终一致性的分布式事务消息适用于有时间窗口要求场景的定时/延时消息
12.5 RabbitMQ Broker表示RabbitMQ服务每个Broker里面至少有一个Virtual host虚拟主机。
Exchange与Queue之间通过RoutingKey形成绑定关系Binding。
Connection是一个TCP长连接。
Channel是在Connection的基础上建立的虚拟连接。 通常情况下每个线程创建单独的Channel进行通讯每个Channel都有自己的channel id帮助Broker和客户端识别Channel所以Channel之间是完全隔离的。
Exchange的4种类型了direct、fanout、topic、headers。 direct的意思是直接的direct类型的Exchange会将消息转发到指定Routing key的Queue上Routing key的解析规则为精确匹配。 fanout是扇形的意思该类型通常叫作广播类型。fanout类型的Exchange不处理Routing key而是会将发送给它的消息路由到所有与它绑定的Queue上。 topic的意思是主题topic类型的Exchange会根据通配符对Routing key进行匹配只要Routing key满足某个通配符的条件就会被路由到对应的Queue上。 Routing key必须是一串字符串每个单词用 “.” 分隔 符号 “#” 表示匹配一个或多个单词 符号 “*” 表示匹配一个单词。 headers Exchange中Exchange与Queue之间的绑定不再通过Binding key绑定而是通过Arguments绑定。
如果一条消息设置了TTL属性或者进入了设置TTL属性的队列那么这条消息如果在TTL设置的时间内没有被消费则会成为死信。
如果设置了队列的TTL属性则一旦消息过期就会被队列丢弃(如果配置了死信队列被丢到死信队列中)
TTL死信队列 可以实现延时队列的功能 死信的来源 消息TTL过期。 队列达到最大长度(队列满了无法再添加数据到mq中)。 消息被拒绝(basic.reject或basic.nack)并且 requeuefalse。 12.6 Mysql 1)最上层是连接层比如连接处理、授权认证、安全等2)第二层包括MySQL的很多核心服务功能查询缓存、解析器、优化器包括查询解析、分析、优化、缓存以及所有的内置函数例如日期、时间、数学和加密函数所有的跨存储引擎的功能都在这一层实现存储过程、触发器、视图等。3)第三层包含了存储引擎存储引擎负责MySQL中数据的存储和提取是数据库中非常重要非常核心的部分也是MySQL区别与其他数据库的一个重要特性。
MySQL默认的存储引擎InnoDB应该就是其最佳选择
事务的四个特性(ACID)
原子性。原子性是指事务包含的所有操作要么全部成功要么全部失败回滚一致性。一个事务执行之前和执行之后都必须处于一致性状态。隔离性。当多个用户并发访问数据库时比如操作同一张表时数据库为每一个用户开启的事务不能被其他事务的操作所干扰多个并发事务之间要相互隔离。持久性。指一个事务一旦被提交了那么对数据库中的数据的改变就是永久性的。
MySQL常用存储引擎的锁机制
MyISAM和MEMORY采用表级锁。BDB采用页级锁或表级锁默认为页级锁。InnoDB支持行级锁和表级锁,默认为行级锁。只有通过索引条件检索数据InnoDB才使用行级锁否则InnoDB将使用表锁。
MyISAM中是不会产生死锁的因为MyISAM总是一次性获得所需的全部锁要么全部满足要么全部等待。而在InnoDB中锁是逐步获得的就造成了死锁的可能。
在MySQL中行级锁并不是直接锁记录而是锁索引。
MySQL引擎 ISAM是一个定义明确且历经时间考验的数据表格管理方法它在设计之时就考虑到数据库被查询的次数要远大于更新的次数。读取操作的速度很快不支持事务处理不支持外键也不能够容错 MyISAM是MySQL的ISAM扩展格式。不支持事务处理、不支持外键。 HEAP允许只驻留在内存里的临时表格。 InnoDB给MySQL提供了具有提交、回滚和崩溃恢复能力的事务安全存储引擎。
适用场景MyISAM适合(1)做很多count 的计算(2)插入不频繁查询非常频繁(3)没有事务。InnoDB适合(1)可靠性要求比较高或者要求事务(2)表更新和查询都相当的频繁并且表锁定的机会比较大的情况。
12.7 Memacache
基于Key-Value的内存缓存系统
Memacache 代码层次类似Hash简单易用。
1.支持简单数据类型2.不支持数据持久化存储3.不支持主从4.不支持分片分割数据进行存储
12.8 Redis
Redis 采用了 Gossip 协议作为通信协议。Gossip 是一种传播消息的方式可以类比为瘟疫或者流感的传播方式使用 Gossip 协议的有Redis Cluster、Consul、Apache Cassandra 等。Gossip 协议类似病毒扩散的方式将信息传播到其他的节点这种协议效率很高只需要广播到附近节点然后被广播的节点继续做同样的操作即可。
Redis的内存占用组成
自身内存对象内存缓冲内存内存碎片
Redis的持久化
RDB快照持久化保存某个时间点的全量数据快照。AOF(Append-Only-File)持久化保存写状态。也就是说AOF不是像RDB记录数据库状态而是记录数据库接收到的指令。记录除了查询以外的所有变更数据库状态的指令。以append的形式追加保存到AOF文件中增量
Redis 集群中使用哈希槽来实现数据的分片和负载均衡 集群的中每个redis实例都负责接管一部分槽总槽数为163842^ 14
槽位映射
哈希取余一致性哈希服务器IP节点映射
redis 操作命令 list 操作命令RPUSH、LPUSH、LPOP、RPOP、LINDEX、LRANGE set 操作命令SADD、SMEMBERS、SISMEMBER、SREM zset 操作命令ZADD、ZRANGE、ZRANGEBYSCORE、ZREM hash 操作命令HSET、HGET、HGETALL、HDEL 查看内存命令info memory
12.9 Prometheus Grafana
Exporter 监控工具获取数据Prometheus 普罗米修斯时序数据库用来存储和查询你的监控数据Grafana 仪表盘
Grafana 是一个监控仪表系统Prometheus是一个时间序列数据库。 Grafana 不仅仅只支持Prometheus作为查询的数据库。
Prometheus 主要任务负责数据的收集存储并且对外提供数据查询支持 只要能够向Prometheus提供标准格式的监控样本数据那就是一个ExporterPrometheus周期性的从Exporter暴露的HTTP服务地址(通常是 http://IP:9100/metrics )拉取监控样本数据
13 案例分析
13.1 云原生架构
目的将云应用中的非业务代码部分进行最大化的剥离让云设施IaaS和PaaS接管应用中原有的大量非功能特性使业务不再有非功能性业务中断困扰的同时具备轻量级、敏捷、高度自动化的特点。
服务化架构
服务化架构拆分为微服务把代码模块关系和部署关系进行分离。
Mesh 化架构
Mesh化架构服务网格化把中间件框架从业务进程中分离让中间件SDK与业务代码进一步解耦使得中间件升级对业务进程没有影响。
服务网格化无侵入式的服务量编排和治理将服务治理从业务逻辑中抽取出来实现中间件SDK与业务进程的解耦。
将微服务之间的连接、安全、流量控制、可观测等通用功能下沉为平台基础设施实现应用与平台基础设施的解耦。
服务网格 Istio 开源项目清晰定义了数据平面开源软件Envoy承载 和 管理平面Istio自身核心能力是大部分云厂商默认使用的服务网格方案。
Serverless 架构
Serverless将“部署”这个动作从运维中“收走”使开发者不用关心应用运行地点、操作系统、网络配置等把应用的整个运行都委托给云。
Serverless 具备以下特征
全托管的计算服务无需关心运行、部署专注于业务代码编写。通用性能过够支持云上所有类型的应用。自动弹性伸缩用户无需为资源使用提前进行容量规划。按量计费无需为闲置资源付费。
Serverless 架构应该是采用 FaaS函数即服务和 BaaS后端即服务服务来解决问题的一种设计。
BaaS 后端即服务Serverless 把运维的工作全部包揽下来全部由云平台完成。除此之外像缓存、数据库、文件存储、消息中间件等也全部由云平台帮我们做好封装起来以接口的形式提供服务这就是 BaaS所谓后端即服务。FaaS 函数即服务FaaS 是以函数的方式运行代码本质上 FaaS 就是一个函数运行平台。
基于 FaaS 和 BaaS 的架构是一种「计算」和「存储」分离的架构。计算由 FaaS 负责存储由 BaaS 负责。无运维 事件驱动 按量付费 弹性伸缩。
优点 Serverless 可以不用运维、实现自动的弹性伸缩、按量付费节省成本、更高的安全性、易于迭代和部署。
缺点 依赖第三方服务Serverless 产品一定是和云厂商绑定的不同的云厂商实现了不同的 FaaS 接口同一套代码是无法在不同的 Serverless 产品上运行的要想从一个云平台迁移到另一个云平台成本非常高。 开发调试困难难以在本地环境搭建要想在本地开发调试非常复杂。同时Serverless 架构正处于飞速发展的阶段其开发、调试、部署工具链并不完善。 底层硬件的多样性应用代码在 FaaS 上运行但 BaaS 是个黑盒其底层的硬件资源是不确定的目前云厂商并没有提供针对底层硬件的可选项。
可观测架构
可观测架构可观测三个方面 (1) Logging 提供多个级别的详细信息跟踪由应用开发者主动提供(2) Tracing 提供一个请求从前端到后端的完整调用链路跟踪对于分布式场景尤其有用(3) Metrics 提供对系统量化的多维度度量。 13.2 大数据架构
Lambda架构
它的目标是构建一个通用的、健壮的大数据系统能够同时满足实时查询和历史数据批处理的需求。
Lambda 架构总共由三层系统组成 批处理层Batch Layer批处理层存储管理主数据集不可变的数据集和预先批处理计算好的视图。 速度处理层Speed Layer速度处理层会实时处理新来的大数据。 响应查询的服务层Serving Layer所有在批处理层和速度层处理完的结果都输出存储在服务层中服务层通过返回预先计算的数据视图或从速度层处理构建好数据视图来响应查询。
批处理层更关注精确计算而速度层则关注近似计算。 Kappa 架构
Kappa架构是对Lambda架构的改进和优化。
随着流式计算系统的发展Lambda架构存在的一些问题逐渐显现出来
系统复杂度高需要同时开发和维护批处理系统和流式系统。通过日志重播实现低延迟查询会导致数据冗余。实时视图和批处理视图存在延迟不一致的问题。
为了解决这些问题Kappa架构去除了Lambda架构的批处理层直接通过流式处理系统实现整个流程。
Kappa架构主要包含两个层: 流式处理层通过流式处理系统接收所有数据并进行实时计算更新存储中的结果视图。 服务层对外提供查询服务直接基于流式处理层更新的结果视图进行查询返回。 Kappa架构减少了系统复杂度避免了数据冗余和数据不一致的问题。但需要流式处理系统能够保证 Exactly-once语义精确一次语义以保证流式计算的正确性。而且去除批处理系统后对历史数据的复杂计算会更加困难。
Lambda 架构 vs Kappa 架构 Kappa 架构变种
Kappa
Kappa架构将不同来源的数据通过Kafka导入到Hadoop中通过HDFS来存储中间数据再通过spark对数据进行分析处理最后交由上层业务进行查询。
核心思想让流计算框架直接读HDFS里的数据仓库数据一并实现实时计算和历史数据回溯计算不需要为backfill作业长期保存日志不需要把数据拷贝回消息队列。
Kappa将数据任务分为无状态任务和时间窗口任务。
无状态任务根据吞吐速度合理并发扫描全量数据。时间窗口任务将数据仓库数据按照时间粒度进行分区存储窗口任务按时间顺序一次计算一个分区的数据分区内乱序并发。
Kappa-S
该架构在Kappa架构的基础上引入了Stream-Serving层。 通过引入Stream-Serving层针对历史数据进行预计算Kappa-S架构减轻了流式处理的压力使历史数据的查询和分析更加简单同时也避免了流式系统需要提供精确一次语义的复杂性。可以看作是Kappa架构和Lambda架构的折中方案。
Kappa-Lambda
Kappa-Lambda架构是在 Kappa 架构的基础上引入了 Lambda 架构中的批处理层Batch层用于复杂的历史数据分析组件形成的一种混合架构。
Batch层定期从Stream层获取数据进行复杂的历史数据分析和处理。
流批一体
流批一体(Unified Batch and Streaming Processing)是指将流式处理和批处理统一在一个运行时框架中进行一体化的处理。实时数据流和历史数据批量处理可以使用同一组数据处理工具和技术例如Apache Spark、Apache Flink等。
流批一体可以看作是对Lambda架构的简化也是实时处理和批处理融合的产物以应对实时数据和历史数据双需求的场景。
Dataflow 模型
DataFlow 模型是一种用于描述数据处理流程的计算模型它描述了数据从源头到目的地的流动过程并指定了数据处理的方式和顺序。
DataFlow 模型常用于 并行计算 和 数据流处理 领域例如流处理框架 Apache Flink 就是基于 DataFlow 模型实现的。
在 DataFlow 模型中数据被视为流动的实体数据处理被视为一系列的数据转换操作
实时数仓
典型的实时数仓架构包括数据收集层、数据存储层、实时计算层和实时应用层。数据收集层负责接收和传输数据数据存储层用于实时数据存储实时计算层用于实时计算和分析实时应用层用于数据分析和挖掘。
不同架构对比 Lambda架构适合大数据场景但维护批处理层和速度层的重复开发较为麻烦。Kappa架构简单高效但对实时流有较高要求历史数据处理不如Lambda架构方便。流批一体简化系统但实时性不如纯流式处理。Dataflow模型可以灵活表示复杂处理流程。实时数仓可以快速分析数据并实时更新但对基础设施要求较高。
13.3 Redis 架构
Redis 怎么 6.0 成了多线程的
Redis6.0的多线程是用多线程来处理数据的读写和协议解析但是Redis执行命令还是单线程的。
这样做的⽬的是因为Redis的性能瓶颈在于⽹络IO⽽⾮CPU使⽤多线程能提升IO读写的效率从⽽整体提⾼Redis的性能。
Redis 过期策略以及内存淘汰机制
“定期删除惰性删除”策略 内存淘汰机制。
定期删除Redis默认每隔100ms就随机抽取一些设置了过期时间的key检查其是否过期如果有过期就删除。惰性删除定期删除可能会导致很多过期的key到了时间并没有被删除掉此时就要用到惰性删除。在你请求某个key的时候redis会检查这个key是否设置了过期时间并判断是否过期了如果过期就删除。
Redis中的缓存淘汰策略
1.LRU 最近最少使用 — 基于缓存中数据的访问顺序2.LFU 最不经常使用 ----基于缓存中每个数据的使用频率3.Random 随机淘汰策略4.TTL 生存时间
Redis与MySQL的数据同步方案
一. 实时同步方案
实时同步适用于对「强一致性」有严格要求的场景可以提供实时的数据同步但对数据库的负载较高同步并发时的性能不可控。
写操作写关系数据库MySql写成功后删除缓存Redis中的值。
利用「触发器」进行缓存同步
1.采用 UDF 自定义函数通过添加新的函数对MySQL的功能进行扩充实现将数据的变更操作发送到Redis的功能。2.在MySQL中创建触发器用于捕获数据变更事件在触发器中调用UDF函数。3.当触发器触发时直接立即更新Redis。 UDF是mysql的一个拓展接口UDFUserdefined function用户自定义函数 二. 异步准实时方案
异步更新当数据库中的数据更新时不立即更新缓存数据而是将更新操作记录成日志再逐步排队完成更新。适用于并发程度较高对「性能」有严格要求的场景可以提高系统的性能但会带来一定的数据延迟。
1. 采用「异步队列」的方式同步 当数据库中的数据更新时不立即更新缓存而是将更新操作记录发送到消息队列中然后异步处理队列中的消息来完成Redis的更新。
2. canal监听binlog触发更新Redis 使用阿里的MySql数据库同步工具canal基于最终一致性canal的实现方式是模拟mysql的slave和master同步机制监听mysql中binlog日志的更新来触发Redis缓存的更新。这种方法可以减少开发工作量但在使用时有些局限性。
缓存和数据库的数据一致性问题
https://mp.weixin.qq.com/s/iQxQepKP5mKFgtFR_zVTLA
最佳的缓存更新策略先更新数据库再删除缓存在用到缓存时才去更新缓存。
「延时双删」策略
1.先删除缓存2.写入数据库3.休眠几毫秒然后再次删除缓存
延时的目的是为了确保读操作结束写操作可以删除读操作造成的缓存脏数据。
数据库的读操作的速度远快于写操作
缓存穿透
缓存穿透查询的数据在缓存和数据库中都不存在由于缓存未命中导致每次请求该数据都要去数据库再查询一遍。
利用不存在的key频繁攻击系统在短时间内有大量系统不存在的随机key发起了查询请求而这些不存在的key在缓存里找不到引发了大量对数据库服务器的查询请求从而导致了数据库服务器的宕机。
穿透的解决方案 设置空值 当在数据库中也未查询到该key时在缓存中为key设置空值防止对数据库发起重复查询。设置空值方案存在问题不在系统中的key值是无限的如果均设置key值为空会造成内存资源的极大浪费引起性能急剧下降。 布隆过滤器 实现方式在缓存之前添加一个布隆过滤器将系统中所有可能存在的key全部映射到布隆过滤器中。当查询请求到来的时候先到布隆过滤器里面对key进行过滤只允许系统中存在的key进行后续查询。
「布隆过滤器」 是一个很长的二进制向量位数组 - Bit Array和一系列随机映射函数用于快速判断元素是否存在于集合中。
布隆过滤器的优点
占用内存小。查询效率高。不需要存储元素本身。
布隆过滤器的缺点
有一定的误判率。不能获取元素本身。一般情况下不能从布隆过滤器中删除元素。
缓存击穿
缓存击穿某个超热点数据的缓存突然失效导致大量请求直接访问数据库数据库压力瞬间升高同时引起大量的缓存更新操作造成整个系统性能急剧下降。
击穿的解决方案 缓存预热提前加载热门数据到缓存中避免在流量高峰期读数据库。 热点数据永不过期。 限流策略通过限制并发访问的请求数量避免系统在缓存失效时被大量请求冲垮。 缓存失效后通过加锁、队列的方式控制写缓存的线程数量保证缓存的单线程写使得缓存更新串行化大量的缓存更新操作排队进行从而降低更新频率。
缓存雪崩
缓存雪崩由于缓存中大量的key设置了相同的过期时间导致大规模的缓存在某一时刻同时失效或者是缓存节点宕机造成数据库请求瞬时爆量系统崩溃。
雪崩的解决方案 设置随机的缓存失效时间使失效时间的分布尽量均匀从根源上避免大量缓存key值同时失效。 设置两级或多级缓存将缓存划分为多个层级每个层级具有不同的过期时间和容量。 限流通过限制并发访问的请求数量避免系统在缓存失效时被大量请求冲垮。 熔断在数据库访问出现故障时通过切断对数据库的请求并提供备选方案来防止故障蔓延。
穿透查询的数据在缓存中不存在数据库中也不存在。— key不存在
击穿热点数据的缓存突然失效。— 热点的key失效
雪崩大量的缓存在某一时刻同时失效。— 大规模的key失效
13.4 分布式架构
开放分布进程 ODP 分布式架构
主从架构
即主节点负责写入数据从节点来分担读流量对于数据一致性要求较高的场景可以通过“主写主读”的方式来解决
同步方式场景优点缺点同步复制数据在主节点写入成功之后还需要确保各个从节点同步数据成功之后才向上游返回成功 ack。一般用于对数据可靠性要求较高的场景主从间的数据同步强一致数据可靠性高数据同步环境对网络的延时要求较高从节点越多写入的效率会越低数据复制效率较低半同步复制数据在主节点写入成功之后从节点同步只要同步成功一个即返回成功 ack。一般用于对数据写入效率要求较高的场景折中方式主从同步效率高对网络延时较不敏感可能出现幻写即刚写入的数据再读取的时候发生丢失数据可靠性较低异步复制数据在主节点写入成功后立即返回从节点异步复制主节点的数据。一般用于对数据写入效率要求较高的场景主从同步效率很高从节点无法和主节点保持完全同步可能出现主从间数据不一致的场景
主主架构
解决了主从架构下单点写的问题可以由多个节点承载着写和读的流量并且完成从节点的数据同步动作。
常见的应用场景主要见于多数据中心、离线客户端操作、协同编辑
写冲突解决
处理写冲突及时发现并且阻塞写请求串行化写影响写入效率避免冲突如在多数据中心的场景下我们也可以将用户路由到最近的数据中心进行写入以此来降低数据冲突的概率一致性状态收敛进行数据合并可以使用以下几种方式 给写入分配时间戳并且以后写入的数据为准。为每个同步节点分配唯一 ID指定规则如序号高的副本始终优先于序号低副本的写入。按照预定义的合并规则自动将数据进行合并。将合并控制权交给用户让用户自行决定数据合并。
无主架构
允许任何副本节点承载写和读的流量写入的时候只要保证写入“大多数成功”即认为写入成功写入的数据中附带版本号。
如何保证写入和读取正确 有 n 个副本写入需要 w 个节点确认读取必须至少查询 r 个节点则只要满足 wrn 的条件那么读取的节点中一定会包含最新值。只要我们能保证读和写的节点之间存在交叉即可
事务隔离
事务的四大特性 ACID
原子性事务是一个不可分割的执行单元要么全部执行成功要么全部回滚。一致性使数据库从一个一致性状态转变到另一个一致性状态。隔离性事务的执行是相互独立的互不干扰。持久性事务的执行结果必须是持久化保存的事务一旦提交改变是永久的。
事务的并发问题 脏读脏读指一个事务「读到」了另一个「未提交事务修改过的数据」。脏读最大的问题就是可能会读到不存在的数据。可使用排他锁X来对数据加锁。 不可重复读在一个事务内多次读取同一个数据如果出现前后两次读到的数据不一样的情况就意味着发生了「不可重复读」现象。事务 A 多次读取同一数据事务 B 在事务A多次读取的过程中对数据作了更新并提交导致事务A多次读取同一数据时结果不一致。可使用共享锁S来对数据加锁 幻读在一个事务内多次查询某个符合查询条件的「记录数量」如果出现前后两次查询到的记录数量不一样的情况就意味着发生了「幻读」现象。 注意不可重复读的和幻读很容易混淆不可重复读侧重于修改幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行解决幻读需要锁表。 事务隔离级别
读未提交read uncommitted一个事务还没提交时它做的变更就能被别的事务看到。读提交read committed一个事务提交之后它做的变更才会被其他事务看到。可重复读repeatable read一个事务执行过程中看到的数据总是跟这个事务在启动时看到的数据是一致的。这是MySQL InnoDB 引擎的默认隔离级别串行化serializable 对于同一行记录“写”会加“写锁”“读”会加“读锁”。当出现读写锁冲突的时候后访问的事务必须等前一个事务执行完成才能继续执行。
我们设置的隔离级别越高那么事务并发执行的效率就会越低。因此很多时候我们都要在隔离级别与效率之间寻找一个平衡点。
锁
S锁和X锁
锁说明S锁:共享锁加了S锁的记录允许其他事务再加S锁不允许其他事务再加X锁X锁:排他锁加了X锁的记录不允许其他事务再加S锁或者X锁
乐观锁和悲观锁
乐观锁 : 我不锁先更新更新失败了再重新来过。 悲观锁 : 我先判断能否拿到锁没拿到就排队等待。
乐观锁 OCC 允许多个事务执行并发的读写操作,每个事务在访问数据时记录该数据项的版本号提交时通过版本号来判断是否有其它事务对数据进行了修改如果有则回滚当前事务重新读取数据后再进行操作。 适用于读多写少的场景 不会产生死锁,能够提高并发性能和系统吞吐量 在大量写操作和冲突高的情况下,会导致频繁的回滚和重试从而影响性能
悲观锁 PCC 读写数据时先对数据加锁其它事务必须等待锁释放后才能继续操作。 适用于写多读少的场景 能够保证数据的准确性和一致性 增加死锁的机会操作被串行化降低了系统的并发性能
分布式事务理论
CAP定理
指在一个分布式系统中不可能同时满足一致性C、可用性A、分区容错性P三者不可兼得。 一致性 Consistency 分布式系统中的所有数据备份在同一时刻值相同。 可用性 Availability 在部分节点故障后集群整体仍能响应客户端的读写请求。 分区容错性 Partition tolerance 系统中的节点之间由于网络问题导致无法相互通信即在网络分区的情况下仍能保持正常运行。
对于分布式系统CAP理论更合适的描述是在满足分区容错性的前提下没有算法能同时满足数据一致性和服务可用性。因此需要在C和A之间进行取舍。
CP架构刚性事务 如果要满足数据的强一致性就必须在一个服务的数据资源锁定时对分布式系统中其它服务的数据资源同时锁定等待全部服务处理完业务才可以释放资源。
AP架构柔性事务 如果要满足服务的强可用性每个服务就可以各自独立执行本地事务而无需相互锁定其它服务的资源。
BASE理论
BASE是对CAP中一致性和可用性权衡的结果通过牺牲强一致性来获得高可用性。
核心思想 即使无法做到强一致性但每个应用都可以根据自身业务特点采取适当的方式来使系统达到 最终一致性 。 基本可用 Basically Availability 分布式系统在出现故障时保证核心功能是可用的允许部分功能适当的降低响应时间甚至是服务降级。 软状态 Soft State 允许系统中的数据存在中间状态即系统在不同节点的数据副本之间进行数据同步的过程中存在延迟。 最终一致性 Eventially Consistent 所有的数据副本在经过一段时间的同步之后最终都能达到一致性的状态。
分布式事务框架 Seata
Seata 是一款开源的分布式事务解决方案致力于提供高性能和简单易用的分布式事务服务。Seata 提供了 AT、TCC、SAGA 和 XA 事务模式为用户打造一站式的分布式解决方案。Seata 默认是AT模式。
一个分布式的全局事务整体是「两阶段提交2PCTwo-Phase-Commit」模型。
一阶段 prepare 行为二阶段 commit 或 rollback 行为
2PC 两阶段提交
「表决阶段」 事务管理器向所有参与者发送prepare消息每个数据库参与者为资源加锁在本地执行事务完成undo_log和redo_log的写入但不提交事务。「执行阶段」 事务管理器收到了参与者执行失败或超时消息给每个参与者发送回滚消息否则发送提交commit消息。参与者根据事务管理器的指令执行提交或者回滚并释放事务处理过程中使用的资源。 redo_log按照时间顺序记录了每个事务对数据库的修改操作。 undo_log存放着修改之前的数据即数据的历史版本。 存在的问题 阻塞对于任何一次指令必须收到明确的响应才会继续做下一步否则处于阻塞状态占用的资源被一直锁定不会被释放。 单点故障如果协调者宕机参与者没有了协调者指挥会一直阻塞尽管可以通过选举新的协调者替代原有协调者但是如果之前协调者在发送一个提交指令后宕机而提交指令仅仅被一个参与者接受并且参与者接收后也宕机新上任的协调者无法处理这种情况。 脑裂协调者发送提交指令有的参与者接收到执行了事务有的参与者没有接收到事务就没有执行事务多个参与者之间是不一致的。
3PC 三阶段提交
三阶段提交协议3PC 协议是两阶段提交协议的改进版本。它通过 超时机制 解决了阻塞的问题并且把两个阶段增加为三个阶段询问阶段、准备阶段、提交阶段。 询问阶段 尽可能早的发现无法执行操作而需要中止的行为但是它并不能发现所有的这种行为只会减少这种情况的发生。 等待超时 如果在询问阶段等待超时则自动中止如果在准备阶段之后等待超时则自动提交。
Seata事务类型
根据两阶段行为模式的不同Seata将分支事务划分为「AT模式」和「TCC模式」。
「AT模式」 基于支持本地ACID事务的关系型数据库
一阶段 prepare 行为业务数据和回滚日志记录在同一个本地事务中提交。二阶段 commit 行为马上成功结束自动 异步批量清理回滚日志。二阶段 rollback 行为通过回滚日志自动 生成补偿操作完成数据回滚。
「TCC模式」 不依赖于底层数据资源的事务支持
一阶段 prepare 行为调用 自定义 的try逻辑。二阶段 commit 行为调用 自定义 的commit逻辑。二阶段 rollback 行为调用 自定义 的cancel逻辑。
「Saga模式」 是长事务解决方案
把分布式事务看作一组本地事务构成的事务链业务流程中每个参与者都提交本地事务当出现某一个参与者失败则补偿前面已经成功的参与者。
一阶段正向服务二阶段补偿服务
正向服务和反向补偿都需由业务开发实现。
14 论文
14.1 论文框架 请围绕“XXXXXX”论题依次从以下三个方面进行论述。
1简要叙述你参与的软件开发项目以及你所承担的主要工作。
2列举出几种 XXXXXX 的主要思想和技术特点。
3根据你所参与的项目中使用的 XXXXXX具体阐述使用方法和实施效果。摘要 背景 子题目 正文 结尾
【摘要】逻辑上分2段300字以内
1.项目概述通用模板。150字2.对正文的概括3句话每句话概括正文的一段。150字
【背景】回应子题目1通用模板400字
3.介绍项目背景解决了什么问题你在其中承担的主要工作。200字4.详细介绍项目功能组成 技术实现重点在解释说明 200字
【子题目】回应子题目2300字
5.过渡语句 理论知识回答题目2
【正文】回应子题目3“总-分式”描述“一总三分”1500字 过渡段引出核心论点即总-分结构中的总
【结尾】通用模板300字 项目运行效果 不足和改进
14.2 摘要模板 14.3 常考理论
软件系统建模方法
1.结构化建模2.信息工程建模数据库建模3.面向对象建模4.基于构件的开发方法
软件设计方法和软件系统建模方法大同小异
1.结构化设计2.信息工程3.面向对象设计4.原型设计5.基于构件的开发方法
提高软件可靠性方法
1.避错设计可靠性设计准则模块化、模块独立、信息隐蔽、局部化2.检错设计被动、主动式检错3.容错设计N版程序设计、恢复快设计、冗余设计
软件质量保证SQA常见活动
1.准备SQA计划制定项目计划是制定 SQA计划2.参与软件过程描述软件开发小组选择软件过程SQA小组评审过程说明确保其符合企业政策、内部标准和外界标3.评审评审各项软件工程活动验证是否符合定义的软件过程4.审计审计软件工作产品识别、记录和跟踪出现的偏差5.处理偏差并文档化6.记录不规范并上报7.协调变更管理
数据湖与数据仓库
1.数据源不同2.数据模式转换时机不同3.数据存储成本不同4.数据质量不同5.面向用户不同6.支持应用类型不同
影响软件维护的主要因素
1.可理解性2.可测试性3.可修改性4.可靠性5.可移植性6.可使用性7.效率
云上自动化运维
可用性和可靠效率指标性能指标成本指标监控指标变更管理标
14.4 历年论文
年份第1题第2题第3题第4题备注2014论软件需求管理论非功能性需求对企业应用架构设计的影响论软件的可靠性设计论网络安全体系设计解析2015论应用服务器基础软件论软件系统架构风格论面向服务的架构及其应用企业集成平台的技术与应用解析2016论体系系统架构评估其应用论软件设计模式及其应用论数据访问层设计技术及其应用论微服务架构及其应用解析2017论软件系统建模方法及其应用论软件架构风格论无服务器架构及其应用论软件质量保证及其应用解析2018论软件开发过程RUP及其应用论软件体系结构的演化论面向服务架构设计及其应用论NoSQL数据库技术及其应用解析2019论软件设计方法及其应用论软件系统架构评估及其应用论数据湖技术及其应用论负载均衡技术在 Web 系统中的应用解析2020论数据分片技术及其应用论云原生架构及其应用论软件测试中缺陷管理及其应用论企业集成架构设计及其应用解析2021论面向方面的编程技术及其应用论系统安全架构设计及其应用论企业集成平台的理解与应用论微服务架构及其应用解析2022论基于构建的软件开发方法及其应用论软件维护方法及其应用论区块链技术及其应用论湖仓一体架构及其应用解析2023论面向对象设计的应用与实现论多数据源集成的应用与实现论软件可靠性评价的设计与实现论边云协同的设计与实现解析2024-上模型驱动架构设计方法及其用云上自动化运维及其应用大数据lambda架构单元测试及运用x2024-下论软件维护及其应用论面向服务的架构设计论多源异构数据集成方法论分布式事务及其解决方案解析
