【软考高级】系统架构设计师复习笔记-精华版

pushiqiang2024-12-26 21:07

文章目录

  • 前言
  • [0 系统架构设计师](#0 系统架构设计师)
    • [0.1 考架构还是考系分](#0.1 考架构还是考系分)
    • [0.2 架构核心知识](#0.2 架构核心知识)
    • [0.3 架构教材变化](#0.3 架构教材变化)
  • [1 计算机操作系统](#1 计算机操作系统)
    • [1.1 cpu 组成](#1.1 cpu 组成)
    • [1.2 内核的五大功能](#1.2 内核的五大功能)
    • [1.3 流水线技术](#1.3 流水线技术)
    • [1.4 段页式存储](#1.4 段页式存储)
    • [1.5 I/O 软件](#1.5 I/O 软件)
    • [1.6 文件管理](#1.6 文件管理)
    • [1.7 系统工程相关](#1.7 系统工程相关)
  • [2 嵌入式](#2 嵌入式)
    • [2.1 嵌入式技术](#2.1 嵌入式技术)
    • [2.2 板级支持包（BSP）](#2.2 板级支持包（BSP）)
    • [2.3 实时操作系统](#2.3 实时操作系统)
    • [2.4 物联网](#2.4 物联网)
  • [3 数据库](#3 数据库)
    • [3.1 数据库设计过程](#3.1 数据库设计过程)
    • [3.2 数据模型](#3.2 数据模型)
    • [3.3 关系代数](#3.3 关系代数)
    • [3.4 模式分解](#3.4 模式分解)
    • [3.5 封锁协议](#3.5 封锁协议)
    • [3.6 数据仓库和联邦数据库](#3.6 数据仓库和联邦数据库)
    • [3.7 常见的反规范化设计方法](#3.7 常见的反规范化设计方法)
  • [4 计算机网络](#4 计算机网络)
  • [5 信息化](#5 信息化)
  • [6 知识产权](#6 知识产权)
    • [6.1 知识产权保护期限](#6.1 知识产权保护期限)
    • [6.2 开源许可证](#6.2 开源许可证)
  • [7 软件工程](#7 软件工程)
  • [8 软件架构设计](#8 软件架构设计)
    • [8.1 架构和框架](#8.1 架构和框架)
    • [8.2 架构评估](#8.2 架构评估)
    • [8.3 基于架构的软件设计 ABSD](#8.3 基于架构的软件设计 ABSD)
    • [8.4 鸿蒙系统架构](#8.4 鸿蒙系统架构)
    • [8.5 信息系统架构](#8.5 信息系统架构)
    • [8.6 层次式架构](#8.6 层次式架构)
    • [8.7 面向服务架构（SOA）](#8.7 面向服务架构（SOA）)
  • [9 系统可靠性](#9 系统可靠性)
    • [9.1 系统质量属性](#9.1 系统质量属性)
    • [9.2 系统架构的脆弱性分析](#9.2 系统架构的脆弱性分析)
  • [10 系统安全性](#10 系统安全性)
    • [10.1 信息安全](#10.1 信息安全)
    • [10.2 访问控制模型](#10.2 访问控制模型)
    • [10.3 安全模型](#10.3 安全模型)
      • [一. HRU模型【基本模型】](#一. HRU模型【基本模型】)
      • [二. BLP（Bell-LaPadula）模型【机密性】](#二. BLP（Bell-LaPadula）模型【机密性】)
      • [三. Chinese Wall模型【机密性】](#三. Chinese Wall模型【机密性】)
      • [四. Biba模型【完整性】](#四. Biba模型【完整性】)
      • [五. Clark-Wilson模型【完整性】](#五. Clark-Wilson模型【完整性】)
    • [10.4 系统安全架构](#10.4 系统安全架构)
    • [10.5 系统安全保护等级](#10.5 系统安全保护等级)
    • [10.6 Kerberos认证](#10.6 Kerberos认证)
    • [10.7 RADIUS（远程访问拨号用户服务）](#10.7 RADIUS（远程访问拨号用户服务）)
  • [11 扩展知识](#11 扩展知识)
    • [11.1 边缘计算](#11.1 边缘计算)
    • [11.2 SSE](#11.2 SSE)
    • [11.3 仓颉语言](#11.3 仓颉语言)
    • [11.4 数字孪生](#11.4 数字孪生)
    • [11.5 宏编程](#11.5 宏编程)
    • [11.6 LLVM](#11.6 LLVM)
  • [12 应用软件](#12 应用软件)
  • [13 案例分析](#13 案例分析)
  • [14 论文](#14 论文)
    • [14.1 论文框架](#14.1 论文框架)
    • [14.2 摘要模板](#14.2 摘要模板)
    • [14.3 常考理论](#14.3 常考理论)
    • [14.4 历年论文](#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->B，R2保持依赖B->C，说明分解后的R1和R2是保持函数依赖的分解，因为A->C这个函数依赖实际是一个元余依赖，可以由前两个依赖传递得到，因此不需要管。

无损分解

分解后的关系模式能够还原出原关系模式，就是无损分解，不能还原就是有损。

定理:如果R的分解为p={R1，R2)，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对R+S锁，T只能读，不能改，其他事务可以对R+S锁。

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 企业架构框架

TOGAF（The Open Group Architecture Framework）是一种开放式「企业架构框架」标准 。它提供了一套企业架构的参考模型，结构化的方法、模型、工具，帮助企业定义其业务目标、业务流程、信息流、技术架构等方面的要素，并建立起这些要素之间的关联和整合，包括企业架构的多个视图和视角：

  • 业务架构
  • 信息系统架构（应用 & 数据）
  • 技术架构

TOGAF框架的「六个组件」

  • 1.架构开发方法, ADM是TOGAF的核心，描述了一种开发企业架构的分步方法。
  • 2.ADM指南和技术
  • 3.架构内容框架, 描述了TOGAF内容框架，包括架构工件的结构化元模型、可重用架构构建块ABB的使用、典型架构可交付成果的概述。
  • 4.企业连续体和工具, 分类法+工具，用于对企业内部架构活动的输出进行分类和存储。
  • 5.TOGAF参考模型, 提供2个架构参考模型：TOGAF技术参考模型TRM + 集成信息基础设施参考模型III-RM
  • 6.架构能力框架, 在企业内建立和运营架构实践所需的组织、流程、技能、角色和职责。

TOGAF框架的「核心思想」

  • 模块化架构
  • 内容框架
  • 扩展指南
  • 架构风格
ADM架构开发方法

TOGAF 的关键是架构开发方法 ADM（Architecture 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：如果项目采用动态链接调用该许可证的库，项目可以不用开源。

  • Mozilla（MPL）：只要该许可证的代码在单独的文件中，新增的其他文件可以不用开源。

总得来说，除非有明确的 "保留专利" 的条款，使用开源软件都不会构成侵犯专利。

GPL 许可证规定，只要你的项目包含了 GPL 代码，整个项目就都变成了 GPL。有人把这种传染性比喻成 "GPL 病毒"。

7 软件工程

7.1 信息系统生命周期

7.2 能力成熟度模型集成CMMI

CMMI是若干过程模型的综合和改进不仅仅软件，而是支持多个工程学科和领域的系统的、一致的过程改进框架能适应现代工程的特点和需要，能提高过程的质量和工作效率。

7.3 信息系统开发方法

结构化开发方法

结构化方法也称为生命周期法，是一种传统的信息系统开发方法，由结构化分析(Structured Analysis,SA)、结构化设计 (Structured Design,SD)和结构化程序设计 (Structured Programming，SP) 三部分有机组合而成，其精髓是自顶向下、逐步求精和模块化设计。

  • 遵循"用户第一"的原则
  • 在系统分析与设计时 ，从整体和全局考虑，自顶向下地分解。
  • 在系统实现时 ，根据设计的要求，先编写各个具体的功能模块，然后自底向上逐步实现整个系统

面向对象开发方法

  • 其关键在于建立一个全面合理、统一的模型(用例模型和分析模型)
  • 系统分析、系统设计和系统实现三个阶段的界限变得不明确，某项工作既可以在前一个阶段完成，也可以在后一个阶段完成

面向对象需求分析方法: UML

面向对象的分析模型： 主要由顶层架构图、用例与用例图、领域概念模型构成

面向对象的设计模型： 包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。

当前，一些大型信息系统的开发，通常是将结构化方法和面向对象方法结合起来首先，使用结构化方法进行自顶向下的整体划分;然后，自底向上地采用00方法进行开发。因此，结构化方法和面向对象方法仍是两种在系统开发领域中相互依存的、不可替代的方法。

原型化开发方法

  • 原型法是以用户为中心来开发系统，用户参与的程度大大提高。
  • 原型法适用于那些需求不明确的系统开发。事实上，对于分析层面难度大、技术层面难度不大的系统，适合于原型法开发。
  • 从严格意义上来说，目前的原型法不是一种独立的系统开发方法，而只是一种开发思想，它只支持在系统开发早期阶段（系统分析阶段）快速生成系统的原型，没有规定在原型构建过程中必须使用哪种方法。因此，它不是完整意义上的方法论体系。这就注定了原型法必须与其他信息系统开发方法结合使用。

统一过程（RUP）开发方法

  • 它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。
  • 3个显著特点: 用例驱动、以架构为中心、迭代和增量。
  • 4个流程: 初始阶段、细化阶段、构建阶段和交付阶段。每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经达到。
  • 适用:一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域不同的组织类型、不同性能水平和不同的项目规模。

模型驱动架构开发方法

模型驱动架构（Model Driven Architecture，MDA）是一种软件开发方法论，它强调使用一系列抽象层次的模型，并利用模型之间的转换来实现从需求到设计、直至代码生成的全过程。

MDA是一种基于诸如统一建模语言(UML) 、可扩展标记语言(XML) ，和 公共对象请求代理体系结构(CORBA) 等一系列业界开放标准的框架。

MDA基于三种建模方法

  • 统一建模语言(UML)：包括各种软件建模所需的子语言，UML主要的子语言用于表达类图、活动图与状态图。

  • 元对象工具(MOF)：是作为UML构造的一个子集而建立的，具有足够的表达能力来表达重要的模型。

  • 公共仓库元模型(CWM)：标准化了数据仓库应用程序的生命周期(例如，设计、构建和管理)。

在MDA开发过程，可从三个不同的层次建立系统模型

  • 1.计算无关模型(Computational Independent Model，CIM)，该模型关注于业务环境和需求，而不考虑计算环境。该模型通常由业务分析人员创建，展示了系统的业务模型，可以理解为系统需求。

  • 2.平台无关模型(Platform Independent Model，PIM)，该模型考虑在计算系统环境中的业务逻辑表示，但不关注具体的实现平台。该模型通常由系统架构师创建，关注系统功能，可以理解为分析模型。

  • 3.平台相关模型(Platform Specific Model，PSM)，该模型关注于如何在特定平台(如JavaEE)下如何实现业务逻辑，可以理解为设计模型。

CIM ---> PIM ---> PSM ---> 实现代码

  • 1.基于MDA的开发过程，首先通过业务领域的分析和建模构造CIM以描述需求。
  • 2.结合相关的标准规范将CIM转换为PIM。
  • 3.在PIM基础上，针对不同的实现环境，可以构造出不同的PSM。
  • 4.最后将PSM转换成目标代码，完成开发过程。

7.4 企业应用集成技术（EAI）

EAI 一般包括：

  • 表示集成
  • 数据集成
  • 控制集成
  • 业务流程集成

数据集成主要有：数据联邦、数据复制、基于接口的数据集成三种模式。

其中，数据联邦 指不同的应用共同访问一个全局虚拟数据库，通过全局虚拟数据库管理系统为不同的应用提供全局信息服务。
基于接口的数据集成指不同的应用系统之间利用适配器来实现相互调用以达到集成的目标。

7.5 系统规划

系统规划阶段产出物

系统规划阶段产出物：可行性研究报告、系统设计任务书。

可行性研究

可行性研究通常从经济可行性、技术可行性、法律可行性和用户使用可行性四个方面来进行分析，其中经济可行性通常被认为是项目的底线。

  • 经济可行性:也称为投资收益分析或成本效益分析，主要评估项目的建设成本运行成本和项目建成后可能的经济收益。
  • 技术可行性:也称为技术风险分析，研究的对象是信息系统需要实现的功能和性能，以及技术能力约束。
  • 法律可行性:也称为社会可行性，具有比较广泛的内容它需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性。
  • 用户使用可行性 :也称为执行可行性，是从信息系统用户的角度来评估系统的可行性，包括企业的行政管理和工作制度、使用人员的素质和培训要求等可以细分为管理可行性 和运行可行性 。
    1. 管理可行性。管理可行性是指从企业管理上分析系统建设可行性。主管领导是否支持，管理方法是否科学，相应的管理制度改革的时机是否成熟，规章制度是否产全等。
    2. 运行可行性。运行可行性也称为操作可行性，是指分析和测定信息系统在确定环境中能够有效工作，并被用户方便使用的程度和能力。例如，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 4+1 视图

需求变更

7.7 图形表示工具

  • 程序流程图(Program Flow Diagram，PFD)用一些图框表示各种操作。任何复杂的程序流程图都应该由顺序、选择和循环结构组合或嵌套而成。

  • IPO图（Input Process Output） 也是流程描述工具，用来描述构成软件系统的每个模块的输入、输出和数据加工。

  • N-S图（盒图）容易表示嵌套和层次关系，并具有强烈的结构化特征。但是当问题很复杂时，N-S图可能很大，因此不适合于复杂程序的设计。

  • 问题分析图(PAD)是一种支持结构化程序设计的图形工具。PAD具有清晰的逻辑结构、标准化的图形等优点，更重要的是，它引导设计人员使用结构化程序设计方法，从而提高程序的质量。

  • Petri图 一种对系统状态转移的天然并行的模型描述方法，适合于描述异步的、并发的计算机系统模型。

7.8 系统设计基本原则


7.9 面向对象设计

7.10 SysML

系统建模语言（SysML）：SysML 是一种用于系统工程应用的通用系统架构建模语言。它是由对 UML2.0 的子集进行重用和扩展而来的。

SysML 已成为基于模型的系统工程（MBSE）应用程序的事实上的标准系统架构建模语言。

SysML 为 UML 添加了两个有用的图表用法（需求图扩展了UML类图;参数图扩展了UML类和复合结构图）

SysML在一定程度上重用了UML部分元模型，同时针对系统工程对UML进行扩展，增加了诸如需求、块、限制之类描述系统的元素和相关图形支持。

UML中被SysML重用的部分称为UML4SysML，SysML Profile是扩展的部分。

SysML为支持从结构、行为模型、需求和参数四个方面来构建系统模型：

  • 结构模型强调系统的层次以及对象之间的相互连接关系；
  • 行为模型强调系统中对象的行为，包括它们的活动、交互和状态历史；
  • 需求模型强调需求之间的追溯关系以及设计对需求的满足关系；
  • 参数模型强调系统或部件的属性之间的约束关系。

模块定义图（Block Definition Diagram，BDD）：用于表示模块和值类型之类的元素（定义能够在可操作的系统中存在的事物类型）以及那些元素之间的关系。BDD的通常用法包括显示系统层级关系树以及分类树。

内部模块图（Internal Block Diagram，IBD）：用于指定单个模块的内部结构。更精确的说法是，IBD会显示模块内部组成部分之间的关系，以及它们之间的接口。

参数图（Parametric Diagram）：用于表示一种或多种约束------特别是等式和不等式------如何与系统的属性绑定。参数图支持工程分析，包括性能、可靠性、可用性、电力、人力和成本。参数图还可以用于支持候选物理架构的优劣势研究。

需求图（Requirement Diagram）：用于表示基于文字的需求、需求之间7种关系。

基于模型的系统工程（MBSE）

基于模型的系统工程（MBSE），又称基于模型的系统开发（MBSD），是一种系统工程过程范例，强调严格的体系结构建模原则和最佳实践应用于整个系统开发生命周期（SDLC）中的系统工程活动。这些系统工程活动包括但不限于需求分析，功能分析，性能分析，系统设计，贸易研究，系统架构规范以及系统验证和验证（V＆V）。

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-n+2。

7.14 垃圾回收

垃圾回收（GC，Garbage 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 架构评估

软件架构评估有三种方式：基于调查问卷（检查表），基于度量，基于场景。

基于场景的方法主要有三种：

  • 软件架构分析法 ：SAAM，Software Architecture Analysis Method
  • 架构权衡分析法 ：ATAM，Architecture Tradeoff Analysis Method
  • 成本效益分析法 ：CBAM，Cost Benefit Analysis Method

SAAM 主要针对可修改性，也可用于可移植性、可扩充性等。

SAAM的主要输入是问题描述、需求说明和架构描述，其分析过程主要包括：

  • 1）场景开发
  • 2）架构描述
  • 3）单个场景评估
  • 4）场景交互评估
  • 5）总体评估。

ATAM 核心是结合质量属性效用树对系统进行评价，确定风险点、敏感点、权衡点，并对系统架构做出决策和折中。整个评估过程强调以质量属性作为评估核心，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

ATAM分成4个阶段：

  • 1）场景和需求收集
  • 2）架构视图描述和场景实现
  • 3）质量属性模型构造和分析
  • 4）质量属性评价和折中

8.3 基于架构的软件设计 ABSD

ABSD：Architecture-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框架的应用程序把表现层分为以下几层：

  • 1）UI Components（UIC)：这个组件就是原来的表现层，用户看到并与之进行交互的组件，负责获取用户的数据并返回结果。

  • 2）UI Process Components（UIP)：用于协调用户界面的各个部分，使其配合后台的活动、以及状态和视图的管理。对用户不可见，为UIC提供了重要的支持。

UIP的组件主要负责的功能是：

  • 管理经过UIC的信息流。

  • 管理UIP中各个事件之间的事务。

  • 修改用户过程的流程以响应异常。

  • 将概念上的用户交互流程从实现/涉及的设备上分离出来。

  • 保持内部的事务关联状态，通常是持有一个或多个的与用户交互的事务实体。

业务逻辑层

业务逻辑层采用容器的形式，降低业务和相邻各层的耦合，有效防止业务层代码渗透到表示层，便于系统功能的开发、代码重用和管理。

  • 1）Domain Model：是领域层业务对象，仅包含业务相关的属性。

  • 2）Service：是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。

  • 3）Control：服务控制器，通过服务控制器，实现不同服务之间的切换，将服务的实现和服务的转向控制分离。（"服务和控制的分离"）

Domain Model --- Service --- Control 关系

  1. Service的运行依赖Domain Model的状态。

  2. Service根据业务规则改变Domain Model的状态。

  3. Control根据Domain Model的状态决定Service之间的执行顺序和相互关系。

工厂模式在数据访问层应用

工厂模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类，使一个类的实例化延迟到其子类。

Entity Bean

  • ①CMP（Container Managed Persistence，容器管理的持续性）。构件的相关数据库操作由容器自动完成，不需要在bean 中编写数据库操作的代码。
  • ②BMP（Bean Managed Persistence，Bean管理的持续性）。构件的相关数据库操作由开发人员在代码中通过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）开发服务：贯彻整个软件开发生命周期的开发平台（建模服务、设计服务、实现服务、测试服务）
  • 6）IT服务管理：支持业务系统运行的各种基础设施管理能力或服务

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 容错性

健壮性和容错性在概念上有重叠，但重点不同

  • 健壮性: 健壮性是系统在面对异常输入或异常操作时能够正常运行并终止。健壮系统在面对不可恢复的错误时，会采取预先设定的措施进行安全终止，以避免更大的损失或风险。

  • 容错性: 是指系统在部分组件发生故障时，仍能继续提供正常或降级的服务。容错性主要关注的是系统如何通过冗余、备份和自动切换等机制，在发生故障时维持功能。

关键应急响应指标

  • MTBF（Mean Time Between Failures，平均无故障时间）：指两次故障之间的平均时间，通常用于衡量设备或系统的可靠性。

  • MTTD（Mean Time to Detect，平均故障检测时间）：指从故障发生到检测到故障的平均时间。较短的MTTD意味着系统能够更快地发现故障，有助于缩短MTTR。

  • MTTF（Mean Time to Failure，平均故障间隔时间）：指设备或系统的平均无故障运行时间。

  • MTTR（Mean Time to Repair，平均故障修复时间）是指故障发生到故障修复完成的平均时间。用于衡量系统可用性和可靠性。MTTR越短，表示系统修复故障的能力越强，系统的可用性和可靠性越高

9.2 系统架构的脆弱性分析

微服务架构

  • 分布式系统的复杂结构
  • 服务之间的通信机制
  • 服务管理的复杂性

微内核架构

  • 难以进行良好的整体化优化：核心态只实现了最基本的系统操作
  • 进程间通信开销比宏内核系统要大的多
  • 通信损失率高

MVC架构

  • 层次结构的复杂性，降低运行效率。
  • 视图与控制器间紧密连接
  • 视图对模型数据的低效率访问

事件驱动架构

  • 组件
  • 组件间数据交换
  • 组件间逻辑关系
  • 事件驱动容易进入死循环
  • 高并发的脆弱性
  • 固定流程的脆弱性，因为事件驱动的响应流程基本都是固定的，如果操作不当，容易引发安全问题。

10 系统安全性

10.1 信息安全

安全架构的三道防线：

  • 产品安全架构
  • 安全技术体系架构
  • 审计架构

信息系统的威胁 4 个方面：

  • 人为蓄意破坏
  • 灾害性攻击
  • 系统故障
  • 人员无意识行为

信息安全的5个基本要素

网络安全威胁

  1. 非授权访问
  2. 信息泄露或丢失
  3. 破坏数据完整性
  4. 拒绝服务攻击
  5. 利用网络传播病毒

密钥安全

密码法将密码分为核心密码、普通密码和商用密码。核心密码、普通密码属于国家秘密。核心密码保护信息的最高密级为绝密级，普通密码保护信息的最高密级为机密级。

国密算法分类

  • SM1: 对称加密算法，分组密码算法，分组长度为128位，密钥长度都为 128 比特
  • SM2：非对称加密算法，用来做非对称加解密，以及数字签名。类似rsa
  • SM3 ：hash摘要算法，用来做数字指纹，类似md5
  • SM4 ：对称加密算法，用来做加解密，类似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（访问控制矩阵模型）模型是一种计算机安全的访问控制模型，通过使用保护矩阵和访问控制规则来描述和控制系统中对资源的访问。它主要解决了系统访问请求的安全性和合法性问题。

二. BLP（Bell-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）两个环节。

  1. 预警 waring
  2. 保护 protect：加密机制、数字签名、访问控制、防火墙
  3. 检测 detect：入侵检测、攻击检测、系统脆弱性检测、数据完整性检测
  4. 响应 react：封堵、隔离、报告
  5. 恢复 restore：容错、冗余
  6. 反击 counterattack

信息系统安全设计的2个方面

  • 系统安全保障体系：安全服务、协议层次、系统单元
  • 信息安全体系架构：物理安全、系统安全、网络安全、应用安全、安全管理

10.5 系统安全保护等级

中国国家标准GB 17859-1999《计算机信息系统安全保护等级划分准则》中将计算机系统安全级别从低到高分为以下四组七等级：

  • 最低级别：D级，称为自主保护级，它又细分为D1级。

  • 中间级别：C级，称为系统审计保护级，分为C1级（自主安全保护）和C2级（受控访问保护）。

  • 较高级别：B级，称为安全标记保护级，包括B1级（标记安全保护）、B2级（结构化保护）和B3级（安全域）。

  • 最高级别：A级，称为访问验证保护级，仅有A1级，是安全级别中最高的，要求最为严格，提供形式化的安全验证。

10.6 Kerberos认证

Kerberos认证流程中涉及到三种角色：客户端Client 、服务端Server 、密钥分发中心KDC（Key Distribution Center）。

KDC是一个网络服务，提供ticket和临时会话密钥。

由三个部分组成：认证服务器（Authentication Server，AS）、票证授予服务器（Ticket Grantion Server，TGS）、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）是一种管理框架，可以用多种协议来实现，是一个能够处理用户访问请求的服务器程序，提供验证授权以及帐户服务，主要目的是管理用户访问网络服务器，对具有访问权的用户提供服务。

RADIUS（Remote 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

SSE（Server-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等内存安全。
  • 轻松并发：仓颉语言实现了轻量化用户态线程和并发对象库，让高效并发变得轻松。
  • 卓越性能：仓颉编译器及运行时从全栈对编译进行优化，包括编译器前端基于CHIR（Cangjie 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等。

  • 中间表示（IR）：LLVM的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内置了一些常用的分词器。

  • Standard：standard分词器通常用于处理多种语言的文本，它会识别并拆分单词、数字、电子邮件地址、网址等，并且能够处理一些标点符号。对于中文、日文、韩文等不使用空格的语言，Standard 分词器可能不是最佳选择，因为它不能很好地理解这些语言的语法规则。例如："Hello, World!" 分词结果为["Hello", ",", "World", "!"]。

  • Simple：simple分词器非常基础，它只是简单地按照非字母字符进行分割，即将所有的非字母字符视为分隔符。因此，所有连续的字母序列都会被视为一个词汇单元，而任何非字母字符（如空格、标点符号、数字）都会被丢弃或用作分隔标志。例如："Hello, World! How are you?"分词结果为["Hello,", "World!", "How", "are", "you?"]

  • Whitespace：whitespace分词器仅仅根据空白字符（如空格、制表符、换行符）来分割文本，不会去除任何字符，也不会考虑标点符号。这意味着标点符号会被当作独立的词汇单元处理。例如："Hello, World! How are you?"分词结果为["Hello,", " ", "World!", " ", "How", " ", "are", " ", "you?"]

  • Keyword：keyword分词器并不真正执行分词操作。相反，它会将整个输入文本作为一个单独的词汇单元输出。这意味着输入文本中的所有内容都被认为是一个不可分割的整体。例如："Hello, World!" 分词结果为 ["Hello, World!"]。

其他

Settings： Settings是对集群中索引的定义信息，比如一个索引默认的分片数、副本数等。

Mapping：Mapping 表示定义索引中字段(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)并且 requeue=false。

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实例都负责接管一部分槽，总槽数为：16384（2^ 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提供标准格式的监控样本数据，那就是一个Exporter，Prometheus周期性的从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架构存在的一些问题逐渐显现出来：

  1. 系统复杂度高：需要同时开发和维护批处理系统和流式系统。
  2. 通过日志重播实现低延迟查询，会导致数据冗余。
  3. 实时视图和批处理视图存在延迟不一致的问题。

为了解决这些问题，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的一个拓展接口，UDF（Userdefined 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在缓存里找不到，引发了大量对数据库服务器的查询请求，从而导致了数据库服务器的宕机。

穿透的解决方案：

  1. 设置空值

    当在数据库中也未查询到该key时，在缓存中为key设置空值，防止对数据库发起重复查询。设置空值方案存在问题：不在系统中的key值是无限的，如果均设置key值为空，会造成内存资源的极大浪费，引起性能急剧下降。

  2. 布隆过滤器

    实现方式：在缓存之前添加一个布隆过滤器，将系统中所有可能存在的key全部映射到布隆过滤器中。当查询请求到来的时候，先到布隆过滤器里面对key进行过滤，只允许系统中存在的key进行后续查询。

「布隆过滤器」 是一个很长的二进制向量（位数组 - Bit Array）和一系列随机映射函数，用于快速判断元素是否存在于集合中。

布隆过滤器的优点：

  • 占用内存小。
  • 查询效率高。
  • 不需要存储元素本身。

布隆过滤器的缺点：

  • 有一定的误判率。
  • 不能获取元素本身。
  • 一般情况下不能从布隆过滤器中删除元素。

缓存击穿

缓存击穿：某个超热点数据的缓存突然失效，导致大量请求直接访问数据库，数据库压力瞬间升高，同时引起大量的缓存更新操作，造成整个系统性能急剧下降。

击穿的解决方案：

  1. 缓存预热：提前加载热门数据到缓存中，避免在流量高峰期读数据库。

  2. 热点数据永不过期。

  3. 限流策略：通过限制并发访问的请求数量，避免系统在缓存失效时被大量请求冲垮。

  4. 缓存失效后，通过加锁、队列的方式控制写缓存的线程数量，保证缓存的单线程写，使得缓存更新串行化，大量的缓存更新操作排队进行，从而降低更新频率。

缓存雪崩

缓存雪崩：由于缓存中大量的key设置了相同的过期时间，导致大规模的缓存在某一时刻同时失效，或者是缓存节点宕机，造成数据库请求瞬时爆量，系统崩溃。

雪崩的解决方案：

  1. 设置随机的缓存失效时间，使失效时间的分布尽量均匀，从根源上避免大量缓存key值同时失效。

  2. 设置两级或多级缓存：将缓存划分为多个层级，每个层级具有不同的过期时间和容量。

  3. 限流：通过限制并发访问的请求数量，避免系统在缓存失效时被大量请求冲垮。

  4. 熔断：在数据库访问出现故障时，通过切断对数据库的请求并提供备选方案来防止故障蔓延。

穿透 ：查询的数据在缓存中不存在，数据库中也不存在。--- key不存在

击穿 ：热点数据的缓存突然失效。--- 热点的key失效

雪崩 ：大量的缓存在某一时刻同时失效。--- 大规模的key失效

13.4 分布式架构

开放分布进程 ODP

分布式架构

主从架构

即主节点负责写入数据，从节点来分担读流量，对于数据一致性要求较高的场景，可以通过"主写主读"的方式来解决

同步方式 场景 优点 缺点
同步复制 数据在主节点写入成功之后，还需要确保各个从节点同步数据成功之后才向上游返回成功 ack。一般用于对数据可靠性要求较高的场景 主从间的数据同步强一致，数据可靠性高 数据同步环境对网络的延时要求较高，从节点越多，写入的效率会越低，数据复制效率较低
半同步复制 数据在主节点写入成功之后，从节点同步只要同步成功一个即返回成功 ack。一般用于对数据写入效率要求较高的场景，折中方式 主从同步效率高，对网络延时较不敏感 可能出现幻写（即刚写入的数据再读取的时候发生丢失），数据可靠性较低
异步复制 数据在主节点写入成功后立即返回，从节点异步复制主节点的数据。一般用于对数据写入效率要求较高的场景 主从同步效率很高 从节点无法和主节点保持完全同步，可能出现主从间数据不一致的场景
主主架构

解决了主从架构下单点写的问题，可以由多个节点承载着写和读的流量，并且完成从节点的数据同步动作。

常见的应用场景主要见于：多数据中心、离线客户端操作、协同编辑

写冲突解决

  • 处理写冲突：及时发现并且阻塞写请求，串行化写，影响写入效率
  • 避免冲突：如在多数据中心的场景下，我们也可以将用户路由到最近的数据中心进行写入，以此来降低数据冲突的概率
  • 一致性状态收敛：进行数据合并，可以使用以下几种方式：
    1. 给写入分配时间戳，并且以后写入的数据为准。
    2. 为每个同步节点分配唯一 ID，指定规则如序号高的副本始终优先于序号低副本的写入。
    3. 按照预定义的合并规则自动将数据进行合并。
    4. 将合并控制权交给用户，让用户自行决定数据合并。
无主架构

允许任何副本节点承载写和读的流量，写入的时候只要保证写入"大多数成功"即认为写入成功，写入的数据中附带版本号。

如何保证写入和读取正确

有 n 个副本，写入需要 w 个节点确认，读取必须至少查询 r 个节点，则只要满足 w+r>n 的条件，那么读取的节点中一定会包含最新值。只要我们能保证读和写的节点之间存在交叉即可

事务隔离

事务的四大特性 ACID
  1. 原子性：事务是一个不可分割的执行单元，要么全部执行成功，要么全部回滚。
  2. 一致性：使数据库从一个一致性状态转变到另一个一致性状态。
  3. 隔离性：事务的执行是相互独立的，互不干扰。
  4. 持久性：事务的执行结果必须是持久化保存的，事务一旦提交，改变是永久的。
事务的并发问题

  • 脏读：脏读指一个事务「读到」了另一个「未提交事务修改过的数据」。脏读最大的问题就是可能会读到不存在的数据。可使用排他锁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模式。

一个分布式的全局事务，整体是「两阶段提交（2PC：Two-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字）

【子题目】回应子题目2，300字

  • 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架构 单元测试及运用 x
2024-下 论软件维护及其应用 论面向服务的架构设计 论多源异构数据集成方法 论分布式事务及其解决方案 解析
相关推荐
不止会JS2 天前
软考：系统架构设计师教材笔记（持续更新中）
系统架构·软件工程·软考
xcg34012311 天前
【系统分析师】-收官整理-已考过
软考·系统分析师
我码玄黄14 天前
软考系分：今日成绩已出
软考高级·软考·系统分析师·软考复习
HL_LOVE_C14 天前
系统架构-最终章
系统架构·软考·架构设计
李元中14 天前
2025软考中级《嵌入式系统设计师》案例模拟题合集
计算机·嵌入式·软考·案例分析·计算机软考·软考中级·嵌入式系统设计师
战神刘玉栋15 天前
《知识拓展 · 统一建模语言UML》
软考·uml·面向对象
战神刘玉栋15 天前
《经验分享 · 软考系统分析师》
经验分享·软考
小康师兄21 天前
【软考速通笔记】系统架构设计师⑭——面向服务架构设计理论与实践
笔记·微服务·设计模式·系统架构·软考·系统架构师·企业集成
小康师兄21 天前
【软考速通笔记】系统架构设计师⑨——软件可靠性基础知识
笔记·系统架构·软考·系统架构师·软件可靠性·容错设计·全国计算机专业与软件技术
热门推荐
01大模型国产化适配7-华为昇腾LLM落地可选解决方案（MindFormers、ModelLink、MindIE）02Ubuntu 20.04使用Livox mid 360 测试 FAST_LIO03玄机平台应急响应—webshell查杀04电赛2024年H题智能小车基于MSPM0G3507主控MCU（利用8路灰度加上MPU6050的解决方式）具体项目报告05组基轨迹建模 GBTM的介绍与实现（Stata 或 R）06支付宝短视频平台创作分成激励项目07怎么找小红书美食探店博主合作？08【一文读懂】NTN（非地面网络）技术介绍09优化手机性能，解决卡顿问题：关闭这3个微信开关，释放内存空间10STM32 无法烧录