导图社区 软考-系统架构设计师（下篇）思维导图
- 89
- 2
- 0
- 举报
软考-系统架构设计师（下篇）思维导图
这是一篇关于软考-系统架构设计师（下篇）思维导图，知识点详细且全面，希望对大家有所帮助！
编辑于2024-05-17 17:54:14- 系统架构设计师
- 复习分享
- 《百年孤独》最全人物关系图
这是一篇关于《百年孤独》的思维导图，主要内容包括：时间背景:19世纪初(1800年代初)~20世纪中叶(1930年代)，拉丁美洲文学代表作之一，首次出版：1967年，哥伦比亚作家：加夫列尔·加西亚·马尔克斯，1982年诺贝尔文学奖得主，魔幻现实主义小说。
- 绝区零人物及组织图
绝区零人物及组织图，《绝区零》是由上海米哈游影铁科技有限公司制作发行的一款动作游戏。该游戏于2022年8月5日正式公布，并开启了“调律测试”的招募。游戏的世界观设定在一个被神秘灾害“空洞”所侵袭的近未来都市“新艾利都”，玩家将扮演不同的角色，在这个城市中展开探索、战斗和冒险。
- 追风筝的人人物关系图
追风筝的人人物关系图，人物关系图揭示了人物之间互动的逻辑基础，使读者更容易理解情节发展的内在逻辑。例如，阿米尔与哈桑之间的兄弟关系以及他们与父亲之间的复杂情感纠葛，是推动小说情节发展的重要因素。通过分析人物关系图，读者可以预测情节的发展方向和可能的转折点。例如，了解阿米尔对哈桑的愧疚和自责，可以预见他最终会为了救赎自己而采取行动。
软考-系统架构设计师（下篇）思维导图
社区模板帮助中心，点此进入>>
- 《百年孤独》最全人物关系图
这是一篇关于《百年孤独》的思维导图，主要内容包括：时间背景:19世纪初(1800年代初)~20世纪中叶(1930年代)，拉丁美洲文学代表作之一，首次出版：1967年，哥伦比亚作家：加夫列尔·加西亚·马尔克斯，1982年诺贝尔文学奖得主，魔幻现实主义小说。
- 绝区零人物及组织图
绝区零人物及组织图，《绝区零》是由上海米哈游影铁科技有限公司制作发行的一款动作游戏。该游戏于2022年8月5日正式公布，并开启了“调律测试”的招募。游戏的世界观设定在一个被神秘灾害“空洞”所侵袭的近未来都市“新艾利都”，玩家将扮演不同的角色，在这个城市中展开探索、战斗和冒险。
- 追风筝的人人物关系图
追风筝的人人物关系图，人物关系图揭示了人物之间互动的逻辑基础，使读者更容易理解情节发展的内在逻辑。例如，阿米尔与哈桑之间的兄弟关系以及他们与父亲之间的复杂情感纠葛，是推动小说情节发展的重要因素。通过分析人物关系图，读者可以预测情节的发展方向和可能的转折点。例如，了解阿米尔对哈桑的愧疚和自责，可以预见他最终会为了救赎自己而采取行动。
- 相似推荐
- 大纲
软考-系统架构设计师 （下篇） 思维导图
第12章 信息系统架构（ISA）设计理论与实践
信息系统架构基本概念及发展
暂无统一的定义
信息系统架构
信息系统架构风格：定义了用于描述系统的术语表和一组指导构建系统的规则。 信息系统架构风格也遵循通用的架构风格
数据流风格：
批处理序列
管道/过滤器
调用/返回风格：
主程序/子程序
面向对象风格
层次结构
独立构件风格：
进程通信
事件系统
虚拟机风格：
解释器
基于规则的系统
仓库风格：
数据库系统
超文本系统
黑板系统
信息系统架构分类
信息系统物理结构
集中式
分布式
信息系统逻辑结构
功能集合体
信息系统常用4种架构模型
单机应用模式
运行在一台物理机器上的独立应用程序
客户机/服务器模式（C/S）
两层C/S（胖客户端）
前台界面/服务
数据库
三层C/S
前台界面
后台服务
数据库
B/S（浏览器/服务器模式）
Web浏览器
Web服务器
数据库
多层C/S结构
前台界面
Web服务器
中间件/应用层
数据库
MVC
以J2EE架构为例：
Model模型层：应用逻辑实现与数据持久化
View视图层（表示层）：浏览器图形化展示请求结果
Controller控制层：Web服务器层
面向服务架构（SOA）模式
面向服务架构SOA：如果2个多层C/S结构的应用系统间需要相互进行通信，那么就产生了面向服务架构
Web Service：面向服务架构体现在Web应用间，就成为了Web Service
面向服务架构的本质：消息机制、远程过程调用（RPC）
企业数据交换总线
不同的企业应用间进行信息交换的通道
数据总线：实质是一个称为连接器的软件系统
企业信息系统的总体框架
第一层：战略系统
战略制定、高层决策
第二层：业务系统、应用系统
业务系统：企业中完成一定业务功能的各部分
应用系统：应用软件系统
第三层：信息基础设施（EII）
技术基础设施：计算机、网络、系统软件、数据交换协议等
信息资源设施：数据与信息本身、数据交换的形式与标准、信息处理方法等
管理基础设施：企业中信息系统部门的组织结构、信息资源设施管理人员的分工、企业信息基础设施的管理方法与规章制度等
信息系统架构设计方法
TOGAF：
是一种开放式企业架构框架标准。
ADM（架构开发方法）：TOGAF规范中最核心的内容。
ADM架构开发方法的全生命周期的十个阶段
准备
需求管理
架构愿景
业务架构
信息系统架构（应用和数据）
技术架构
机会和解决方案
迁移规划
实施治理
架构变更管理
信息化总体架构方法
信息化的一般概念
信息化：通讯现代化、计算机化和行为合理化的总称
信息化生产力
信息化建设：指品牌利用现代信息技术来支撑品牌管理的手段和过程
信息化特征
易用性
健壮性：软件能支撑的最大并发用户数
平台化、灵活性、扩展性
安全性
门户化、整合性
移动性
信息化工程建设方法
1）信息化架构模式
数据导向架构：重点在数据本身
流程导向架构：关注的是流程。SOA面向服务架构本身就是关键方法和技术
2）信息化建设生命周期
系统规划
系统分析
系统设计
系统实施
系统运行和维护
3）信息化工程总体规划的方法论，用的最多的三种：
关键成功因素法CSF
战略目标集转化法SST
企业系统规划法BSP
信息系统架构案例分析
价值驱动的体系结构--连接产品策略与体系结构
价值模型
价值期望值
反作用力
变革催化剂
Web服务在HL7上的应用--Web服务基础实现框架
HL7：Health Level Seven，是美国国家标准协会ANSI认可的标准化开发组织中的一个。最近的HL73.0版本扩展到了各种卫生保健行业、制药业、医疗设备业
HL7 3.0版本说明书是基于参考信息模型RIM的。
以服务为中心的企业整合
案例背景
业务环境分析
服务建模
IT环境分析
高层架构分析
第13章 层次式架构设计理论与实践
层次式体系架构概述
层次式架构是软件体系结构设计中最常用的一种架构形式。
它为软件系统提供了一种在结构、行为和属性方面的高级抽象。
核心思想：将系统组成为一种层次结构，每一层为上层服务，并作为下层客户。
主要结构：
表现层
中间层
访问层
数据层
设计时需要注意的点：
污水池反模式：请求流简单穿过几个层，但是每层基本没有业务逻辑
分层架构可能会让应用变得庞大
表现层框架设计
表现层设计模式
MVC模式
视图View：用户看到并与之交互的界面
控制器Controller：接收用户的输入并调用模型、视图去完成用户需求。是用户与模型Model的接口
模型Model：应用程序的主体部分
MVC模式优点：
允许多种用户界面扩展。因为视图层和模型层没有必然的关系
易于维护
功能强大的用户界面
MVP模式
视图层View：负责显示
Controller/Presenter：负责逻辑处理
模型层Model：提供数据
MVP模式特点：
MVP模式中View不直接使用Model，通信通过Presenter（MVC中的Controller）来进行
模型、视图完全分离，可以修改视图而不影响模型
可更高效地使用模型，因为交互都发生在Presenter内部
可将一个Presenter用于多个视图，而不需要改变Presenter的逻辑
如果把逻辑放在Presenter中，就可脱离用户接口来测试这些逻辑
MVVM模式
视图、观察者（View）
视图模型（ViewModel）
模型、被观察者（Model）
使用XML（可扩展标记语言）设计表现层， 统一Web Form与windows Form的外观
表现层中UIP设计思想
UIP：是微软社区开发的众多Application Block（应用程序块）中的其中之一，是开源的。
表现层动态生成设计思想
基于XML的界面管理技术可实现灵活的界面配置、界面动态生成和界面定制
中间层架构设计
业务逻辑层组件设计
业务逻辑组件的实现类：业务逻辑组件以DAO（数据访问对象）组件为基础。
业务逻辑组件的配置
业务逻辑层工作流设计
过程定义导入/导出接口
客户端应用程序接口
应用程序调用接口
工作流机协作接口
管理和监视接口
业务逻辑层实体设计
业务逻辑层框架
采用容器的形式，便于系统功能的开发、代码重用和管理。
数据访问层设计
5种数据访问模式
在线访问
DAO数据访问对象（DataAccess Object），标准J2EE设计模式之一
DTO数据传输对象（Data Transfer Object），经典EJB设计模式之一
离线数据模式
对象/关系(OR)映射
工厂模式在数据访问层的应用
ORM（对象关系映射）、Hibernate（一个开源的对象关系映射框架，本质是一个提供数据库服务的中间件）
灵活运用XML Schema（用来描述XML文档合法结构、内容和限制）
事务处理设计
事务的ACID原则
原子性
一致性：事务失败时所有被影响的数据都要恢复到事务执行前状态
隔离性：事务执行过程中对数据的修改，在事务提交前对其他事务不可见
永久性
JavaBean中使用JDBC方式进行事务处理
SessionBean中的JTA事务
连接对象管理设计
数据架构规划与设计
数据库设计与类的设计融合
数据库设计与XML设计融合
物联网层次架构设计
感知层：感知数据
网络层：传输和预处理感知层获得数据的问题
应用层：解决信息处理和人机交互的问题
层次式架构案例分析
第14章 云原生架构设计理论与实践
云原生（Cloud Native）架构产生背景
Cloud就是应用软件是在云端而不是传统数据中心； Native代表应用软件从一开始就是基于云环境、专门为云端特定而设计
DevOps：协调开发和运维的“信息对称”问题，提高开发周期和效率。
云原生的容器、微服务等技术为DevOps提供了前提条件
云原生架构内涵
定义：
云原生架构是基于云原生技术的一组架构原则和设计模式的集合。
代码结构发生巨大变化
非功能性大量委托
高度自动化的软件交付
技术部分依赖传统云计算的3层概念
基础设施即服务IaaS
平台即服务PaaS
软件即服务SaaS
云原生架构原则
服务化原则
微服务架构
小服务架构
弹性原则
可观测原则
韧性原则
所有过程自动化原则
零信任原则
架构持续演进原则
主要架构模式
服务化架构模式
把代码模块关系和部署关系分离，每个接口可以部署不同数量的实例，单独扩容/缩容。典型：
微服务模式
小服务模式
Mesh化架构模式
是把中间件框架（RPC、缓存、异步消息等）从业务进程中分离。
Mesh进程完成：流量控制、安全策略、微隔离......
Serverless模式
将“部署”这个动作从运维中“收走”，使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等
不适合：有状态的应用、长时间后台运行的密集型计算任务、频繁I/O的应用等
适合：事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务
存储计算分离模式
是把各类暂存数据（eg：session）、结构化和非结构化持久数据，都采用云服务器保存，从而实现存储计算分离。
分布式事务模式
可观测架构
Logging：提供多个级别的详细信息跟踪
Tracing：提供一个请求从前端到后端的完整调用链路跟踪
Metrics：提供对系统量化的多维度度量
事件驱动架构EDA
本质是一种应用/组件间的集成架构模式
应用场景
微服务解耦
增强服务韧性
CQRS
数据变化通知
构建开放式接口
事件流处理
典型的云原生架构反模式
庞大的单体应用
单体应用“硬拆”为微服务
缺乏自动化能力的微服务
云原生架构相关技术
容器技术：让应用不再受环境限制
背景与价值
Docker镜像
容器编排
开源的Kubernetes：成为分布式资源调度和自动化运维的事实标准
云原生微服务
主要微服务技术
Apache Dubbo阿里开源的高性能RPC框架，国内使用最广泛的微服务框架
Eclipse MicroProfile：Java微服务开发的基础编程模型
Tars：腾讯根据内部使用的微服务框架TAF+实践总结而成的开源项目
无服务器技术Serverless
全托管的计算服务，客户只需要编写代码构建应用
通用性
自动弹性伸缩
按量计费
函数计算，是Serverless中最具代表性的产品形态。
服务网格ServiceMesh
是分布式应用在微服务软件架构之上发展起来的新技术，旨在将微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。
云原生架构案例分析
同程艺龙
某汽车公司
申通
某电商
特步
第15章 面向服务架构设计理论与实践
SOA的相关概念
SOA的定义：
面向服务架构SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。
BPEL：
即面向Web服务的 业务流程执行语言。使用BPEL，用户可通过组合、编排和协调Web服务自上而下地实现面向服务的体系结构。
SOA的发展历史
发展史
萌芽阶段：以XML技术为标志
标准化阶段：三个著名的Web服务标准和规范
简单对象访问协议SOAP
Web服务描述语言WSDL
通用服务发现和集成协议UDDI
成熟应用阶段：三个重量级规范
SCA：SCA和SDO构成了SOA编程模型的基础；
SDO：SCA和SDO构成了SOA编程模型的基础；
WS-Policy：建立了SOA组件之间安全交互的规范
SOA的微服务化发展
SOA与微服务的区别：
（1）微服务更精细，微服务更多以独立进程的方式存在，互相之间无影响；
（2）微服务提供的接口更通用化，无关语言、平台限制；
（3）微服务更倾向于分布式去中心化的部署方式，更适合互联网业务场景。
总结：①SOA架构师面向服务的架构，可视为组件模型。SOA将系统拆分为多个独立的功能模块，模块之间通过接口调用和交互。系统模块间是松耦合的。SOA架构以企业服务总线链接各个子系统，是集中式的技术架构。应用服务间互相依赖。 ②微服务架构是SOA进一步的优化，去除了ESB企业服务总线。是真正意义上的去中心化的分布式架构。降低了微服务之间的耦合度，不同的微服务采用不同的数据库技术，服务独立，数据源唯一，应用易扩展和维护，降低了系统复杂性。
SOA的参考架构 （以IBM的Websphere业务集成参考架构为例）
业务逻辑服务：
应用和信息访问服务：整合已有应用
业务应用程序：整合新开发的应用
伙伴服务：整合客户和业务伙伴
控制服务：
信息服务：数据整合
流程服务：流程整合
交互服务：用户访问整合
连接服务：企业服务总线ESB（Enterprise Service Bus），采用总线这种模式来管理和简化应用间的集成拓扑模式。
业务创新和优化服务：
公共事件框架服务
采集服务
监控服务
开发服务：
建模服务
设计服务
实现服务
测试服务
IT服务管理
安全和目录服务
系统管理和虚拟化服务
SOA主要协议和规范
UDDI（统一描述、发现和集成协议）：定义商业实体在互联网上互相作用。
WSDL（Web服务描述语言）规范：描述Web服务和说明如何与Web服务通信的XML语言
SOAP协议（交换信息简单协议）：是在分散或分布式环境中交换信息的简单协议，是基于XML的协议。
REST规范：
资源：REST以资源为中心构建。
表述：REST中用“表述”描述资源在Web中某个时间的状态。
状态转移：
应用状态：保存在客户端。是对某个时间内用户请求会话相关信息的快照。
资源状态：保存在服务端。是对某个时间资源请求表述的快照。
超链接：是通过在页面中嵌入链接和其他资源建立联系。
SOA设计的标准要求
文档标准化：独立的自我描述XML文档
通信协议标准：SOA服务用消息进行通信，通常使用XML Schema来定义该消息。
应用程序统一登记与集成
服务质量QoS
可靠性
安全性
策略
控制
管理
SOA的作用
解决企业内部信息系统的“信息孤岛”问题。
步骤：①把应用和资源转换成服务
②把这些服务变成标准的服务，形成资源的共享。
SOA的设计原则
无状态
单一实例
明确定义的接口
WSDL定义服务的接口
WS-Policy描述服务规约
XML模式定义交换的信息格式
自包含和模块化
粗粒度：服务数量不应该太大
服务之间的松耦合
重用能力
互操作性、兼容和策略声明
SOA的设计模式
服务注册表模式
企业服务总线模式：ESB思想是提供一种标准的软件底层架构，各种程序组件能够以服务单元的方式“插入”到该平台上运行，且组件间能够以标准的消息通信方式来进行交互。
微服务模式
微服务架构模式方案
聚合器微服务
链式微服务
数据共享微服务
异步消息传递微服务
构建SOA架构时应该注意的问题
原有系统架构中的集成需求
服务粒度的控制及无状态服务的设计
SOA实施的过程
1、选择SOA解决方案
尽量选择能进行全局规划的方案
选择时充分考虑企业自身的需求
从平台、实施等技术方面考查
2、业务流程分析
建立服务模型
自顶向下分解法
业务目标分析法
自底向上分析法
建立业务流程
建立业务对象
建立服务接口
建立业务流程
第16章 嵌入式系统架构设计与实践
嵌入式系统概述：
嵌入式系统，是为特定应用专门构建的计算机系统。
发展历程：
单片微型计算机SCM阶段：即单片机时代
微控制器MUC阶段：以嵌入式微处理器为基础，以简单操作系统为核心
片上系统SoC。嵌入式系统能够运行在不同类型的微处理器
以Internet为基础的嵌入式系统。
在智能化、云技术推动下的嵌入式系统
面向端-端系统微型传感器设备
面向智能服务的设备
嵌入式系统硬件体系结构
嵌入式微处理器
微处理器MPU
微控制器MCU
信号处理器DSP
图形处理器GPU
片上系统SoC
存储器
RAM随机存取存储器
DRAM 动态随机存取存储器
SRAM 静态随机存取存储器
VRAM 视频内存
FPM DRAM 快速页切换模式动态随机存取存储器
EDO DRAM 延伸数据输出动态随机存取存储器
BEDO DRAM 爆发式延伸数据输出动态随机存取存储器
MDRAM 多插槽动态随机存取存储器
WRAM 窗口随机存取存储器
RDRAM 高频动态随机存取存储器
SDRAM 同步动态随机存取存储器
SGRAM 同步绘图随机存取存储器
SB SRAM 同步爆发式静态随机存取存储器
PB SRAM 管线爆发式静态随机存取存储器
DDR SDRAM 二部速率同步动态随机存取存储器
SLDRAM 同步链环动态随机存取存储器
CDRAM 同步缓存动态随机存取存储器
DDR II 第二代同步双倍速率动态随机存取存储器
DRDRAM
ROM只读存储器
MASK ROM 掩模型只读存储器
PROM 可编程只读存储器
EPROM 可擦可编程只读存储器
EEPROM 电可擦可编程只读存储器
Flash Memory 快闪存储器
内（外）总线逻辑：
按传输的信息种类分类
数据总线：CPU与RAM间传送数据
地址总线：指定在RAM中存储的数据的地址
控制总线：将微处理器控制单元的信号传送到周边设备
按拓扑结构分类
星型
树状
环形
总线型
交叉开关型
按连接部件分类
片内总线：CPU芯片内部
系统总线：计算机内部总线
局部总线：eg：内存到北桥的总线
通信总线：嵌入式系统主机外部总线
定时/计数器
看门狗电路：
嵌入式系统必须具备的一种系统恢复能力。
I/O接口：
串口、网络、USB、JTAG等
外部设备
嵌入式系统软件架构概述
嵌入式系统软件架构原理与特征
2种典型的嵌入式系统架构模式
层次化模式架构
封闭型：一层中的对象只能调用同一层或下一个底层的对象提供的方法。移植性较好。
开放型：一层中的对象可以调用同层或低于该层的任意一层的对象提供的方法。开放型的性能更好。
递归模式架构
嵌入式操作系统EOS
定义：指用于嵌入式系统的操作系统。
特点：
可裁剪性
可移植性
强实时性
强紧凑性
高质量代码
强定制性
标准接口
强稳定性、弱交互性
强确定性
操作简洁、方便
较强的硬件适应性
可固化性
分类：
面向控制、通信等领域的嵌入式实时操作系统
面向消费电子产品的非实时嵌入式操作系统
一般架构
4种架构
整体结构/（模块结构/无序结构）
操作系统内核
操作系统可配置库
与处理器外围芯片相关的驱动：板级支持包BSP
文件系统
I/O系统
网络系统
层次结构
客户/服务器结构
面向对象结构
基本功能
操作系统内核架构
宏内核：
用户服务和内核服务在同一空间实现。即内核可以代表内核进程运行代码。宏内核代码耦合度非常高。
微内核：
内核管理所有系统资源，用户服务和内核服务在不同的地址空间中实现。
优点：结构清晰，利于协作开发；代码少，良好的移植性、扩展性；
缺点：执行速度相对较慢，性能偏低
任务管理
任务=程序+执行
任务状态
执行态
阻塞态
就绪态
任务实时调度方法
离线和在线调度
抢占和非抢占调度
静态和动态调度
几个典型强实时调度算法：
最早截止时间优先EDF算法
最低松弛度优先LLF算法
单调速率调度算法RMS
存储管理： 对象是内存
分区存储管理
静态分区
可变分区
首次适应算法
最佳适应算法
最坏适应算法
可重定位分区
分页存储管理：
逻辑地址空间分成若干大小相等的片，称为页
分段存储管理：
逻辑地址=段号+段内地址
段页存储管理：
先分段，再对段分页
虚拟存储管理：
利用实际内存空间和相对大的多的外部存储空间相结合构成一个远远大于实际内存空间的虚拟存储空间。
任务间通信：
操作系统任务间的关系
相互独立
竞争
同步
通信
多任务间通信方法：
共享内存：简单的数据共享
信号量：基本互斥和同步
二进制信号量
互斥信号量
计数信号量
消息队列：统一CPU内多任务间消息传递
使用消息队列的方法
非互锁的单向数据通信
互锁的单向数据通信
互锁的双向数据通信
广播通信
消息队列中消息的队列存在的方式
先进先出FIFO
先进后出FILO
紧急消息
优先级消息
时限消息
Socket和远程调用：任务间透明的网络通信
Signals（信号）：用于异常处理
典型嵌入式操作系统
VRTX
VxWorks
LynxOS
Nucleus
QNX
Android
iOS
ROS
嵌入式数据库
定义
嵌入式数据库的名称来自独特的运行模式。嵌入式数据库嵌入到了应用程序进程中，消除了客户机服务器配置相关的开销。
嵌入式系统中，对数据库的操作具有定时限制的特性
特点
嵌入式
实时性
移动性
伸缩性
分类
按嵌入对象的不同
软件嵌入数据库
设备嵌入数据库
内存数据库
按系统结构不同
嵌入数据库
移动数据库
小型C/S结构数据库
按数据库存储位置不同
基于内存方式MMDB
基于文件方式FDB
基于网络方式NDB
嵌入式数据库的一般架构
数据库服务器与嵌入式数据库对比
（1）嵌入式数据库通常只允许应用程序对其访问和控制；数据库服务器一般允许非开发人员操作；
（2）嵌入式数据库的访问控制完全由应用程序控制；而数据库服务器程序和数据分离。
（3）嵌入式数据库通常和应用程序一起发布，不单独部署；数据库服务器需要独立安装部署管理。
嵌入式数据库的架构
基于内存的数据库系统
基于文件的嵌入式数据库系统
基于网络的数据库系统
嵌入式数据库的主要功能
高效的数据存储机制
数据安全控制
实时事务管理机制
数据库恢复机制
典型嵌入式数据库系统
SQLite
Berkeley DB
Firebird嵌入式服务器版
eXtremeDB
嵌入式中间件
定义
中间件处于操作系统软件与用户应用软件之间，在操作系统、网络和数据库之上，应用软件之下。作用是为上层应用提供运行与开发的环境
嵌入式中间件是在嵌入式系统中处理嵌入式应用和操作系统之间层次的中间软件，主要作用是对嵌入式应用屏蔽底层操作系统的异构性。常见功能：网络通信、内存管理、数据处理等
特点
通用性
异构性
分布性
网络化
支持流媒体应用
QoS质量品质
适应性等
分类
企业服务总线中间件
事务处理
分布式计算环境
远程过程调用
对象请求代理
数据库访问中间件
消息传递
基于XML的中间件
嵌入式中间件的一般架构
消息中间件，特点
采用异步处理模式
应用程序和应用程序调用关系为松耦合关系
分布式对象中间件，特点
嵌入式中间件的主要功能
网络通信、存储管理、数据处理
典型嵌入式中间件系统
公共对象请求代理结构CORBA
数据分发服务DDS
嵌入式系统软件开发环境
特点
集成开发环境
交叉开发
开放式体系结构
友好用户界面
等
分类
根据嵌入式系统软件的调试方法
模拟器方法
在线仿真器方法
监控器方法
JTAG仿真器
嵌入式软件开发环境的一般架构
Eclipse （开源的、基于Java的可扩展开发平台）
宿主层
基本工具层
应用工具层
驻留层
典型嵌入式开发环境
基于GCC开源工具的软件开发环境
Workbench开发环境
MULTI集成开发环境
嵌入式系统软件架构设计方法
基于架构的软件设计（ABSD）开发方法的应用
属性驱动的软件设计（ADD）方法
嵌入式系统关注的质量属性
可靠性
安全性
可用性
可修改性
性能
可测试性
易用性
可维护性
ADD开发过程
1、评审
2、选择驱动因子
3、选择系统元素
4、选择设计概念
5、实体化元素和定义接口
6、草拟试图
7、分析评价
实时系统设计方法DARTS
在分析阶段采用 实时结构化分析RTSA方法
在设计阶段采用 实时结构化设计RTSD方法
嵌入式系统软件架构案例分析
鸿蒙操作系统架构案例分析：
应用层
框架层
系统服务层：鸿蒙
内核层
微内核
面向安全攸关系统的跨领域GENESYS系统架构案例分析
物联网操作系统软件架构案例分析
第17章 通信系统架构设计理论与实践
通信系统概述
通信系统网络架构
局域网网络架构
单核心架构
一台核心交换（一般采用二层或三层以上交换机）设备
双核心
环形架构
采用多台交换机做核心
层次局域网/多层局域网
核心层交换设备、汇聚层交换设备、接入层交换设备
广域网网络架构
单核心广域网
双核心广域网
环形广域网
半冗余广域网
对等子域广域网
层次子域广域网
移动通信网网络架构
5GS与DN互联
透明模式
非透明模式
5G网络边缘计算
存储网络架构
直连式存储DAS
计算机通过I/O端口直接访问存储设备
网络连接存储NAS
计算机通过分布式文件系统访问存储设备
易用性、易管理性、可扩展性、更低的总拥有成本TCO
存储区域网络SAN
计算机通过构建的独立存储放罗访问存储设备
SAN注重高性能、低延迟
软件定义网络（SDN）架构
应用平面
控制平面与应用平面间通过NBI北向接口通信
控制平面
控制平面与数据平面间通过南向接口SBI通信
数据平面
由网络转发设备组成
网络构建关键技术
网络高可用设计
MTBF平均无故障时间
MTTR平均故障修复时间
IPv4与IPv6融合组网技术
过渡期主流3种过渡技术
双协议栈：使IPv6网络节点具有一个IPv6协议栈和一个IPv4协议栈，同时支持两种协议的处理
隧道技术
ISATAP隧道
6to4隧道
4over6隧道
6over4隧道
网络地址翻译技术
SDN技术
控制平面技术
数据平面技术
硬件处理方式
软件处理方式
转发规则一致性更新技术
网络构建和设计方法
网络需求分析
网络技术遴选和设计
局域网技术遴选
生成树协议STP
虚拟局域网
无线局域网
线路冗余设计
交换设备功能的合理使用
服务器冗余设计
广域网技术遴选
远程接入技术
广域网互联技术
地址规划模型
路由协议选择
层次化网络模型设计
网络高可用设计方法
提高网络可用性途径
耐久性
容错性
可维护性
网络安全
防火墙布设
VPN技术
访问控制技术
网络安全隔离
网络安全协议
网络安全审计
绿色网络设计方法 （节能、减排、可回收等）
设计原则
标准化
集成化
虚拟化
智能化
安全性
可靠性
通信网络构建案例分析
高可用网络构建分析
核心层高可用设计
双核心或多核心
汇聚层高可用设计
汇聚层到核心层
三角形
矩形
接入层高可用设计
接入层到汇聚层
倒U型接法
U型接法
矩形接法
三角形接法
园区网双栈构建分析
5G网络应用
第18章 安全架构设计理论与实践
安全架构概述
信息安全面临的威胁
人为蓄意破坏
被动型攻击
网络监听
非法登录
信息截取
主动型攻击
数据篡改
假冒身份
拒绝服务
重放攻击
散播病毒
主观抵赖
灾害性攻击
自然灾害、战争等
系统故障
硬件故障
软件故障
链路故障
供电故障
人员无意识行为
编程错误
操作错误
无意泄密
安全架构的定义和范围
产品安全架构
安全技术体系架构
审计架构
与信息安全相关的国内外标准及组织
国内标准：
GA开头：国家安全行业标准规范
GB：国家标准规范
GJB：国家军用标准规范
标准化组织
ISO 国际标准化组织
IEC 国际电工委员会
SAC 中国国家标准 化管理委员会
全国信息技术标准化技术委员
安全模型 （准确的描述安全的重要方面及其与系统行为的关系）
状态机模型：
用状态语言将安全系统描述成抽象的虚拟机，用状态变量表述系统的状态，用转换规则描述变量变化的过程
Bell-LaPadula模型：
属于强制访问控制模型，以敏感度划分安全级别
Biba模型：
与上面的模型很相似，但重视的是完整性级别
Clark-Wilson模型：
实现了事务处理机制，常用于银行心痛保证数据完整性
Chinese Wall模型：
通过行政规定和划分，防止各部门出现有损客户利益事件
系统安全体系架构规划框架
安全技术体系架构
信息系统安全体系规划
技术体系
组织结构体系
机构
岗位
人事
管理体系
信息系统安全规划框架
依托信息化战略规划
需要围绕技术安全、管理安全、组织安全考虑
以信息系统与信息资源的安全保护为核心
信息安全整体架构设计（WPDRRC模型） （W预警、P保护、D检测、R响应、R恢复、C反击）
WPDRRC信息安全体系架构模型 （我国“八六三”信息安全专家提出的适合中国国情的信息系统安全保障体系建设模型）
信息安全体系架构设计
系统安全保障体系
安全服务
协议层次
系统单元
信息安全体系架构
物理安全
系统安全
网络安全
应用安全
安全管理
网络安全体系架构设计
OSI安全体系架构 （OSI：开放式通信系统互联模型）
7层协议
应用层
表示层
会话层
传输层
网络层
数据链路层
物理层
防御能力的三种方式
多点技术防御
分层技术防御
支撑性基础设施
认证框架
鉴别的方式
已知的。eg：秘密口令
拥有的。eg：令牌、IC卡
不改变的特性。eg：生物特征
相信可靠的第三方建立的鉴别。eg：递推
环境。eg：主机地址
访问控制框架
机密性框架
通过禁止访问提供机密性
通过加密提供机密性
完整性框架
抗抵赖性框架
证据生成
证据传输、存储及修复
证据验证
解决纠纷
数据库系统的安全设计
数据安全设计的评估标准
安全产品均是指安全级别在B1以上的产品
数据库的完整性设计
确定层次和方式
实体完整性约束
慎用触发器功能
在需求分析阶段就要完成完整性约束的命名规范
对数据库完整性进行细致测试
要有专职数据库设计小组
应采用合适的case工具来降低设计阶段的工作量
系统架构的脆弱性分析 （即系统漏洞分析）
概述
软件设计时的瑕疵
软件实现中的弱点
软件本身瑕疵
系统和网络的错误配置
软件脆弱性
IBM的软件缺陷分类法
有意的
恶意的
陷阱
逻辑/时间炸弹
存储
定时
非恶意的
隐蔽通道
不一致的访问控制途径
无意的
验证错误
寻址错误
不充分的参数值验证
不正确的检测位置
不充分鉴定/认证
抽象错误
对象重用缺陷
内部表示暴露
异步错误
并发
别名
子组件误用/失败
资源泄露
功能的错误理解
功能性错误
错误处理故障
其他安全缺陷
典型软件架构的脆弱性分析
分层架构
层间的脆弱性
层间通信的脆弱性
C/S架构
客户端软件的脆弱性
网络开放性的脆弱性
网络协议的脆弱性
B/S架构
采用HTTP协议，相对C/S架构更易被病毒入侵
事件驱动架构
组件的脆弱性
组件间交换数据的脆弱性
组件间逻辑关系的脆弱性
事件驱动容易陷入死循环
高并发的脆弱性
固定流程的脆弱性
MVC架构
MVC架构的复杂性带来的脆弱性
视图与控制器间紧密连接的脆弱性
视图对模型数据的低效率访问的脆弱性
微内核架构
难以进行良好的整体化优化
进程间通信开销较大
通信损失率高
微服务架构
开发人员需要处理分布式系统的复杂结构
开发人员要设计服务间的通信机制
服务管理的复杂性
安全架构设计案例分析
电子商务系统的安全性设计
基于混合云的工业安全架构设计
第19章 大数据架构设计理论与实践
传统数据处理系统存在的问题
访问量增加->读写分离技术->大数据架构开始被研究
大数据处理系统架构分析
大数据处理系统面临挑战
非结构化、半结构化数据的处理问题
大数据复杂性、不确定性特征描述刻画方法、大数据的系统建模
数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响
大数据处理系统架构特征
鲁棒性和容错性
低延迟读取和更新能力
横向扩容
通用性
延展性
即席查询能力
最少维护能力
可调式性
Lambda架构
Lambda架构对大数据处理系统的理解
Lambda架构同时处理离线和实时数据、可容错、可扩展的分布式系统，强鲁棒性、提供低延迟和持续更新；可集成Hadoop、Kafka、Spark、Storm等大数据组件
Lambda架构应用场景
机器学习中的Lambda架构
物联网的Lambda架构
流处理和Lambda架构挑战
Lambda架构介绍： （批处理层、加速层、服务层）
批处理层（Batch Layer）：离线数据处理 ①处理全体数据集。在数据集上预先计算查询函数，并构建查询所对应的View。适合处理离线数据； ②产生批处理结果视图Batch View； ③结果认为是精准且全量的； ④数据处理时延很高。
加速层（Speed Layer）：实时数据处理 ①处理的是最近增量数据流。更适合处理实时数据； ②产生流处理结果视图Real-time View； ③流处理层的数据可能不是准确的、不是全量的； ④数据处理时延很低。
服务层（Serving Layer）： ①汇总流处理视图+批处理视图； ②产生查询视图
查询视图
Lambda架构的实现
Hadoop【适合运行在通用硬件上的分布式文件系统】（HDFS）用于存储主数据集。 成熟的离线数据处理技术
Spark【专为大规模数据处理设计的快速通用计算引擎】（或Storm）可构成速度层
HBase【高可靠、高性能、面向列、可伸缩的分布式存储系统】（或Cassandra作为服务层）
Hive创建可查询的视图
Lambda架构优缺点
优点：
容错性好
查询灵活度高
易伸缩
易扩展
缺点：
全场景覆盖带来的编码开销
针对具体场景重新离线训练一遍益处不大
重新部署和迁移成本很高
Lambda与其他架构模式对比
事件溯源Event Sourcing与Lambda架构
事件溯源架构：
整个系统以事件为驱动
事件是核心，系统的数据以事件为基础
业务数据只是一些由事件产生的视图
Lambda架构中数据集的存储使用概念与事件溯源架构的思想一致
命令查询分离CQRS架构与Lambda架构
CQRS架构分离了对于进行的读操作和写操作
Lambda架构中，数据修改通过批处理和流处理实现，通过写操作将数据转换成查询时所对应的视图，查询时直接读取视图得到结果，实际是形式的读写分离
Kappa架构
Kappa架构下对大数据处理系统的理解
数据的特性
数据是与时间相关的
数据本身不可变，过往的数据已成为事实
数据的存储
Lambda架构：数据不可变，存储所有数据
Kappa架构介绍（实时层、服务层） ①在Lambda基础上进行优化，删除了批处理层，将数据通道以消息队列进行替代； ②对于Kappa架构，依旧以流处理为主，但数据在数据湖层面进行了存储；当要进行离线分析或再次计算时，则将数据湖的数据再次经过消息队列重播一次即可。
输入数据
实时层
服务层
外部查询
Kappa架构的实现
部署Apache Kafka，设置数据日志保留期(你希望能重新处理的历史数据的时间区间)
设置重新启动一个Kafka作业实例Instance
将Log OFFset设置0，新的作业实例就会从头开始处理历史数据
当新的数据视图处理过的数据赶上旧的数据视图时，应用就可以切换到从新的数据视图读取
停止旧版本做作业实例，删除旧的数据视图
Kappa架构的优缺点
Kappa架构优点
将实时和离线代码统一，方便维护且统一了数据口径的问题。避免了Lambda架构中与离线数据合并的问题。查询历史数据使只需要重放存储的历史数据即可
Kappa架构缺点
放弃了对批处理的支持，可以理解为Lambda架构的简化版
消息中间件缓存的数据量和回溯数据有性能瓶颈-->Kappa+框架提出用HDFS来存储中间数据
在实时数据处理时，很可能因为数据流先后顺序问题，导致数据丢失
Kappa抛弃了离线数据处理模块同时，也抛弃了离线数据更加稳定可靠的特点； Lambda岁保证了离线计算的稳定性，但双系统的维护成本高且两套代码后期维护困难
常见Kappa架构变形
Kappa+架构
无状态任务：根据吞读速度合理并发扫描全量数据即可
时间窗口任务：将数据仓库数据按照时间粒度分区存储，按时间先后顺序一次计算一个区的数据。
混合分析系统的Kappa架构：
源数据
Flink
Kafka
ElasticSearch
Lambda架构与Kappa架构的对比和设计选择
Lambda架构与Kappa架构的特性对比
①复杂度与开发、维护成本
Lambda架构需维护2套系统（引擎），复杂度高，开发、维护成本高；
Kappa架构只需维护一套系统（引擎），复杂度低，开发、维护成本低
②计算开销
Lambda架构需一直运行批处理和实时计算，计算开销大
Kappa架构必要时进行全量计算，计算开销相对较小
③实时性
2个架构均满足实时性
④历史数据处理能力
Lambda架构 批量式全量处理，吞吐量大，历史数据处理能力强
Kappa架构 流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱
Lambda架构与Kappa架构的设计选择
业务需求与技术要求
业务对Hadoop、Spark、Strom等关键技术有强依赖，则选Lambda架构； 如数据偏于流式计算，又依赖Flink计算引擎，则选Kappa架构
复杂度
如需要对算法模型参数频繁修改，则Kappa架构只需要改一套代码，更方便； 批处理层和流处理层不能合并时（eg：先离线批处理得到训练模型，后实时流式处理验证测试），则只能Lambda架构
开发维护成本
Kappa一套
Lambda两套
历史数据处理能力
eg：海量数据集分析，过往十年内地区降水数据，适合批处理系统分析，选Lambda架构； 始终使用小规模数据集，流处理系统完全够用，则选Kappa架构。
大数据架构设计案例分析
Lambda架构在某网奥运中的大数据应用
Lambda架构在某网广告平台的应用与演进
某证券公司大数据系统
某电商智能决策大数据系统
第20章 系统架构设计师论文写作要点
论文写作方法
摘要 （300-400字，250左右最好）
2022年6月（3年内）-2023年1月（持续6个月以上），我参加了X，担任系统架构师。该项目...（项目背景、简单功能介绍）。本文结合作者的实践，以X项目为例，讨论X（论文主题），包括...（技术、方法、工具、措施、手段）
正文 （2000-3000字，2500左右最好）
项目背景（500字）
主体（1200字）
结尾（500字）