软件架构师思维导图模板_ProcessOn思维导图、流程图

信息系统架构设计

信息系统架构基本概念

信息系统架构基本信息

信息系统架构(ISA)是指

架构是对系统的抽象

它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象。因此，仅与内部具体实现有关的细节是不属于架构的，即定义强调元素的“外部可见”属性

架构由多个结构组成

结构是从功能角度来描述元素之间的关系的，具体的结构传达了架构某方面的信息，但是个别结构一般不能代表大型信息系统架构

任何软件都存在架构

但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而存在。如文档己过时，则该文档不能反映架构

元素及其行为的集合构成架构的内容

体现系统由哪些元素组成，这些元素各有哪些功能(外部可见),以及这些元素间如何连接与互动。即在两个方面进行抽象：在静态方面，关注系统的大粒度(宏观)总体结构(如分层);在动态方面，关注系统内关键行为的共同特征。

架构具有“基础”性：

它通常涉及解决各类关键重复问题的通用方案(复用性),以及系统设计中影响深远(架构敏感)的各项重要决策(一旦贯彻，更改的代价昂贵)

架构隐含有“决策”,即架构是由架构设计师根据关键的功能和非功能性需求(质量属性及项目相关的约束)进行设计与决策的结果。

信息系统架构

信息系统架构分类

逻辑结构

功能综合体和概念性框架

开发中对子系统的综合

横向综合

纵向综合

纵横综合

物理结构

集中式

分布式

企业信息系统的总体框架（ISA）

指对某一特定内容里的信息进行统筹、规划、设计、安排等一系列有机处理的活动。

实现四方面

战略体系

以计算机为基础的高层战略决策支持系统

企业的战略规划体系

含义

信息系统对高层战略决策支持能力

企业规划对信息系统的建设的影响和要求

业务体系

完成业务的各个部分

物质

能量

信息

人

业务流程重组（BPR）

子主题业务过程重组优化

应用系统

应用软件系统

TPS

事务处理系统

MIS

管理信息系统

DSS

决策支持系统

组成部分

内部功能实现部分

外部界面部分

信息基础设施（EII）

三部分

技术基础设施

计算机

网络

系统软件

支持性软件

数据交换协议

信息资源设施

数据与信息本身

数据与信息交换的形式和标准

信息处理方法

管理基础设施

信息系统部门的组织结构

信息资源设施的管理人员的分工

企业信息基础设施的管理方法和规章制度

信息系统架构设计方法

TOGAF

开放式企业架构框架标准

四个目标

确保关键利益相关方到团队成员的所有用户都使用相同的语言

避免被锁定到企业架构的专有解决方案

节省时间和金钱更有效的利用资源

实现客观的利益回报

核心思想

模块化架构

内容框架

扩展指南

架构风格

关键

架构开发方法（ADM）

架构执行步骤

步骤之间的关系

按照架构领域的架构开发顺序排列成环的多个阶段

三个级别的迭代

整体迭代

多个开发阶段迭代

一个开发阶段迭代

全生命周期十个

准备阶段

需求管理阶段

子主题

信息系统架构案例分析

层次式架构设计

表现层框架设计

中间层架构设计

组件设置

接口

定义业务逻辑

实现类

面向接口编程

工作流设计

工作流执行服务

工作流引擎

流程定义工具

客户端工具

应用调用

管理监控工具

实体设计

实体提供对业务数据及相关功能的状态编程访问

domain model

领域业务对象

仅仅包含业务相关的属性

service

业务过程实现的组成部分

control

服务控制器

不同服务之间的切换

数据访问层设计

5种数据访问模式

在线访问

会占用一个数据库连接，读取数据，每个数据库操作都会通过这个连接不断地与后台的数据源进行交互

DataAccess Object

是标准J2EE设计模式之一，开发人员常常用这种模式将底层数据访问操作与高层业务逻辑分离开。

Data Transfer Object

是经典EJB设计模式之一。DT0本身是这样一组对象或是数据的容器，它需要跨不同的进程或是网络的边界来传输数据。这类对象本身应该不包含具体的业务逻辑，并且通常这些对象内部只能进行一些诸如内部一致性检查和基本验证之类的方法，而且这些方法最好不要再调用其他的对象行为。

离线数据模式

以数据为中心，数据从数据源获取之后，将按照某种预定义的结构存放在系统中，成为应用的中心。离线，对数据的各种操作独立于各种与后台数据源之间的连接或是事务。

对象/关系映射(0bject/Relation Mapping,0/R Mapping)

工厂模式

事务处理设计

连接池

数据架构规划和设计

与xml融合

基于文件的存储方式

数据库存储方式

物联网层次架构设计

三个层次

用来感知数据的感知层

数据传输处理的网络层

与行业需求结合的应用层

云原生架构设计

云原生框架内涵

基于云原生技术将云应用中的非代码部分进行最大剥离，，从而让云设施接管应用中原有的大量非功能特性

应用包括三方面

业务代码

三方软件

处理非功能特性的代码

最大程度利用云服务和提升软件交付能力，进一步加快软件开发

原则

服务化原则

弹性原则

可观测原则

韧性原则

所有过程自动化原则

零信任原则

架构持续演进原则

主要架构模式

服务化架构模式

Mesh化架构模式

Serverless模式

存储计算分离模式

分布式事务模式

可观测架构

事件驱动架构

技术

容器技术

dockers

kubernet

云原生微服务

dubbo

springcloud

无服务技术（serverless）

特性

全托管的计算服务

通用性

自动弹性伸缩

按量计费

函数计算(FaaS)是Serverless中最具代表性的产品形态。通过把应用逻辑拆分多个函数，每个函数都通过事件驱动的方式触发执行。

关注点

计算资源弹性调度

负载均衡和流控

安全性

云原生框架相关技术

服务网格（servicemesh）

◆服务网格(ServiceMesh)是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。

面向服务架构设计

soa概述和发展

服务的概念

泛指系统对外提供的功能集

业务流程

为了实现某种业务目的行为所进行的流程或一系列动作

BPEL

使用Web服务定义和执行业务流程的语言

对soa的认知

SOA是一种应用框架

单独的业务功能和流程

构建、部署和整合这些服务

S0A是一个组件模型

通过这些服务之间定义良好的接口和契约联系起来

与微服务的关系

S0A架构向、更细粒度，更通用化程度发展，就成了所谓的微服务

更细粒度

区别

微服务相比于S0A更加精细，微服务更多地以独立的进程的方式存在，互相之间并无影响

微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；

微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。

S0A架构是一个面向服务的架构

以企业服务总线链接各个子系统，是集中式的技术架构,服务相互依赖，远程通信，部署复杂响应速度低

微服务架构除了ESB企业服务总线，是一个真正意义上去中心化的分布式架构

soa参考框架

关注点分离

服务类型

业务逻辑服务：包括用于实现业务逻辑的服务和执行业务逻辑的能力。

整合已有应用——应用和信息访问服务

整合新开发的应用——业务应用服务

整合客户和业务伙伴(B2C/B2B)——伙伴服务：提供与企业外部的B 2 B的集成能力，包括：社区服务、文档服务、协议服务

控制服务：包括实现人、流程和信息集成的服务，以及执行这些集成逻辑的能力。

数据整合——信息服务：提供集成数据的能力，目前主要包括如下集中信息服务：联邦服务(不同类型数据聚合)、复制服务(远程数据本地访问)、转换服务(格式转换)、搜索服务

流程整合——流程服务：完成业务流程集成，包括：编排服务(预定义流程顺序)、事务服务(保证ACID)、人工服务(人工活动集成到流程中)

用户访问整合——交互服务：实现用户访问集成，包括：交付服务(运行时交互框架)、体验服务、资源服务(运行时交互组件的管理)

连接服务：通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。

企业服务总线ESB

基本特征和能力

描述服务的元数据和服务注册管理

在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等

发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。

高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。

业务创新和优化服务：以业务性能管理(BPM)技术为核心提供业务事件发布、收集和关键业务指标监控
能力，采取措施适应变化的市场

公共事件框架服务：通过一个公共事件框架提供IT和业务事件的激发、存储和分类等

采集服务通过基于策略的过滤和相关性分析检测感兴趣的服务

监控服务：通过事件与监控上下文间的映射，计算和管理业务流程的关键性能指标

开发服务：贯彻整个软件开发生命周期的开发平台。

开发环境和工具中为不同开发者的角色提供的功能被称为开发服务。根据开发过程中开发者角色和职责的不同，有如下4类服务：建模服务、设计服务、实现服务、测试服务

IT服务管理：支持业务系统运行的各种基础设施管理能力或服务。

为业务流程和服务提供安全、高效和健康的运行环境，包括：安全和目录服务、系统管理和虚拟化服务

soa主要协议和规范

UDDI

统一描述、发现和集成协议

WSDL

Web服务描述语言

服务做些什么

如何访问服务

服务位于何处

SOAP

分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议

SOAP编码规则，用于表示应用程序需要使用的数据类型的实例

SOAP RPC表示是远程过程调用和应答的协定

S0AP绑定是使用底层协议交换信息

soa设计标准和原则

标准要求

文档标准化

通信协议标准

应用程序统一登记与集成

服务质量(QoS)

可靠性：“仅且仅仅传送一次”“最多传送一次”“重复消息过滤”和“保证消息传送”等特性消息的发送和确认。

安全性：主要包括认证交换、消息完整性和消息保密。

策略：服务提供者有时候会要求服务消费者与某种策略通信。

控制：在S0A中，进程是使用一组离散的服务创建的。BPEL4WS或者WSBPEL是用来控制这些服务的语言

管理：让系统管理员管理所有，运行在多种环境下的服务的管理系统。

设计原则

无状态。

单一实例

明确定义的接口。

自包含和模块化

粗粒度

服务之间的松耦合性

重用能力

互操作性、兼容和策略声明

soa的设计模式

服务注册表模式

服务注册：应用开发者，也叫服务提供者，向注册表公布他们的功能。

服务位置：也就是服务应用开发者，帮助他们查询注册服务，寻找符合自身要求的服务。

服务绑定：服务的消费者利用检索到的服务合同来开发代码，开发的代码将与注册的服务绑定、调用注册的服务以及与它们实现互动。

企业服务总线模式

由中间件技术实现的支持面向服务架构的基础软件平台，支持异构环境中的服务以基于消息和事件驱动模式的交互，并且具有适当的服务质量和可管理性。

核心功能

提供位置透明性的消息路由和寻址服务

提供服务注册和命名的管理功能

支持多种消息传递范型(如请求/响应、发布/订阅等)

支持多种可以广泛使用的传输协议

支持多种数据格式及其相互转换

提供日志和监控功能

微服务模式

特点

复杂应用解耦、独立、技术选型灵活、容错、松耦合易扩展

常见的微服务设计模式

聚合器微服务

链式微服务

数据共享微服务

异步消息传递微服务

问题与挑战

微服务架构分布式特点带来的复杂性

微服务架构的分区数据库体系，不同服务拥有不同数据库

增加了测试的复杂性

在大规模应用部署中，在监控、管理、分发及扩容等方面，微服务也存在着巨大挑战

soa的构建和实施

构建注意问题

原有系统架构中的集成需求

服务粒度的控制以及无状态服务的设计

实施过程

尽量选择能进行全局规划的方案

选择时充分考虑企业自身的需求

从平台实施等技术方面进行考察

业务流程分析过程

建立服务模型

自顶向下分解法

业务目标分析法

自底向上分析法

建立业务流程

建立业务对象

建立服务接口

建立业务流程

嵌入式系统架构设计

嵌入式系统软件架构和特征

层次化模式架构

位于高层的抽象概念与低层的更加具体的概念之间存在着依赖关系

封闭型

开放性

递归模式架构

需要将一个非常复杂的系统进行分解，并且还要确保分解过程是可扩展的，即只要有必要，该分解过程就可以持续下去

自顶向下

自底向上

嵌入式操作系统(EOS)

包括

硬件相关的底层驱动软件

系统内核

设备驱动接口

通信协议

图形界面

标准化浏览器

特点

可裁剪性

可移植性

强实时性

强紧凑性

高质量代码

强定制性

标准接口

强稳定性

弱交互性

强确定性

操作简洁方便

较强的硬件适应性

可固化性

系统体系架构

整体结构

层次结构

客户/服务器结构和面向对象

内核分类

宏内核

微内核

任务管理

任务调度

划分

离线和在线调度

抢占和非抢占式调度

静态和动态调度

算法

最早截止时间优先

最低松弛度优先

单调速率调度法

任务之间关系

相互独立

竞争

同步

通信

方式

共享内存

信号量

消息队列

Socket和远程调用

Signals(信号)

嵌入式数据库

存储位置

基于内存

基于文件

基于网络

不需要驱动文件

功能

●足够高效的数据存储机制； ●数据安全控制(锁机制); ●实时事务管理机制； ●数据库恢复机制(历史数据存储)。

功能

数据库运行处理

数据库存取

数据管理

数据库维护

数据库定义

解决以下几个设计问题

存储空间管理模块

数据安全性、完整性控制模块

事务并发控制模块

实时数据转储模块

嵌入式中间件

作用

对嵌入式应用屏蔽底层操作系统的异构性，常见功能有网络通信、内存管理和数据处理等

中间件的共性

通用性、异构性、分布性、协议规范性、接口标准化

嵌入式中间件提供对下列环境的支持

网络化

支持流媒体应用

QoS质量品质

适应性

通用中间件分类

●企业服务总线中间件：ESB是一种开放的、基于标准的分布式同步/异步信息传递中间件。 ●事务处理监控器：为发生在对象间的事务处理提供监控功能，以保证操作成功。 ●分布式计算环境：指创建运行在不同平台上的分布式应用程序所需的一组技术服务。 ●远程过程调用：指客户机向服务器发送关于运行某程序的请求时所需的标准。 ●对象请求代理：为用户提供与其他分布式网络环境中对象通信的接口。 ●数据库访问中间件：支持用户访问各种操作系统或应用程序中的数据库。 ●消息传递：电子邮件系统是该类中间件的其中之一。 ●基于XML的中间件：XML允许开发人员为实现Internet中交换结构化信息而创建文档。

嵌入式系统软件架构设计方案

基于架构的软件设计(ABSD)

属性驱动的软件设计(ADD)

把一组质量属性场景作为输入，利用对质量属性实现与架构设计之间的关系的了解(如体系结构风格、质量战术等)对软件架构进行设计的一种方法

经历七阶段

评审

选择驱动因子

选择系统元素

选择设计概念

实体化元素

定义接口

草拟视图

分析评价

实时系统设计法(DARTS)

将实时系统分解为多个并发任务，并定义这些任务之间的接口。提供了一些分解规则和一套处理并发任务的设计步骤，还提供了一套把实时系统建造成并发任务的标准和定义并发任务间接口的指南

种类

RTSAD(实时结构化分析和设计方法)

是DARTS方法的起源，是对传统结构化分析和设计方法的补充扩展，专门用于开发实时系统

组成五部分

用实时结构化分析方法(RTSA)开发系统规范：本阶段要开发系统环境图(SCD)和状态转换图(STD)

将系统划分为多个并发任务：任务结构化标准应用于数据流/控制流图层次集事件合中的叶子节点上。初步任务架构图(TAD)可以显示使用任务结构化标准确定的任务

定义任务间接口：通过分析在上一阶段确认的任务间的数据/控制流接口可以定义任务间的接口。任务间的数据流被映射为松耦合的或紧密耦合的消息接口。事件流被映射为事件信号。数据存储被映射为信息隐藏模块。这个阶段应该完成时间约束分析

设计每个任务：每个任务都代表了一个顺序程序的执行。在这个阶段要定义各个模块的功能以及与其他模块之间的接口。此外，还要设计各个模块的内部结构

设计过程的成果：RTSA规范、任务结构规范(定义每个并发任务功能及接口)、任务分解(定义每个任务分解为模块的过程以及模块的功能接口详细设计)

主要优势

强调把系统分解成并发的任务，并提供了确认这些任务的标准

提供了详细的定义任务间接口的指南

强调了用任务架构图(STD)的重要性，这在实时系统的设计中也非常重要

提供了从RTSA规格到实时设计的转换

不足

用结构化的设计方法把任务创建成了程序模块，而并非完全用IHM来封装数据存储。

如果RTSA阶段的工作没有做好，创建任务就非常困难。

实时结构化分析(RTSA)

主要对传统的结构化分析方法扩充了行为建模部分，它通过状态转换图(STD)刻画系统的行为特征，并利用控制转换与数据流图集成在一起。

实时结构化设计(RTSD)

是利用内聚和耦合原则进行程序设计的一个方法，它通过事务和变换两种策略将RTSA的分析结构DFD/CFD转换为程序结构图。

任务结构化标准

可以为设计人员将实时系统分解为并发任务的时候提供帮助。这些标准是从设计并发系统所积累的经验中得到的启发。确定任务过程中主要考虑的问题是系统内部功能的并发特性。信息隐藏作为封装数据存储的标准来使用。信息隐藏模块用于信息数据存储和状态转换表的内容和表示。

RTSAD设计方法

使用任务架构图来显示系统分解为并发任务的过程，以及采用消息、事件和信息隐藏模块形式的任务间接口。

通信系统架构设计

通信系统网络架构

局域网

单核心架构

双核心架构

环形架构

层次局域网架构

广域网

单核心广域网

双核心广域网

环形广域网

半冗余广域网

对等子域广域网

层次子域广域网

移动通信网（5G）

透明模式

非透明模式

边缘计算架构

软件定义网络

分层

控制层

数据层

平面

数据平面

控制平面

应用平面

网络构建的关键技术

网络可用性

网络部件

网络连接模型

有关网络协议

网络构建和设计方法

网络需求分析

用户需求

业务需求

应用需求

计算机平台需求

网络需求

网络技术选择和设计

局域网

广域网

路由协议

层次化网络设计

核心层

汇聚层

接入层

高可用设计方法

提高网络可靠性

缩短网络恢复时间

网络安全

绿色网络设计原则

标准化

集成化

虚拟化

智能化

安全架构设计

安全架构概述

威胁方面

物理环境威胁

通信链路威胁

网络系统威胁

操作系统威胁

应用系统威胁

管理系统威胁

安全威胁种类

信息泄露

破坏信息完整性

拒绝服务

非法使用（非授权访问）

窃听

业务流分析

假冒

旁路控制

授权侵犯

特洛伊木马

陷阱门

抵赖

重放

计算机病毒

人员渎职

媒体废弃

物理入侵

窃取

业务欺骗

三道防线

产安全架构

安全技术体系架构

审计架构

安全模型

定义

安全目标

控制和管理主体(含用户和进程)对客体(含数据和程序)的访问

安全模型

准确地描述安全的重要方面及其与系统行为的关系

应该做什么，不应该做什么

安全策略

从安全角度为系统整体和构成它的组件提出基本的目标

具体模型

状态机模型

BelI-LaPadula模型

Biba模型

Clark-Wilson模型

Chinese Wall模型

系统安全体系架构规划框架

定义

对组织机构信息技术系统的安全体系结构的整体描述

目标

建立可持续改进的安全技术体系架构的能力

5层次

应用、存储、主机、网络和物理

主体

技术体系

组织机构体系

管理体系

三方面

信息系统安全规划依托企业信息化战略规划

信息系统安全规划需要围绕技术安全、管理安全、组织安全考虑

信息系统安全规划以信息系统与信息资源的安全保护为核心

信息安全整体架构设计

WPDRRC

6要素

预警、保护、检测、响应、恢复和反击

3环节

人员、策略和技术。人员是核心，策略是桥梁，技术是保证

重点考虑2方面

系统安全保证体系

安全服务

协议层次

系统单元

信息安全体系架构

物理安全

系统安全

网络安全

应用安全

安全管理

网络安全体系架构设计

osi5类安全服务

鉴别

访问控制

数据机密性

数据完整性

抗抵赖性

三种方式

多点技术防御

分层技术防御

支撑性基础设施

数据库的安全设计

数据库完整性

7个基本原则

确定其实现的系统层次和方式

实体完整性约束、引用完整性约束

慎用目前主流DBMS都支持的触发器功能

在需求分析阶段就必须制定完整性约束的命名规范

根据业务规则对数据库完整性进行细致的测试

专职的数据库设计小组

采用合适的CASE工具来降低数据库设计各阶段的工作量。

完整性作用

防止合法用户使用数据库时向数据库中添加不合语义的数据

基于D B M S的完整性控制机制来实现业务规则，易于定义

同时兼顾数据库的完整性和系统的效能

有助于尽早发现应用软件的错误

分类

列级静态约束、元组级静态约束、关系级静态约束、列级动态约束、元组级动态约束和关系级动态约束

系统架构的脆弱性分析

漏洞来源

◆脆弱性分析主要是分析信息系统中产生脆弱性的根源、脆弱性可能造成的影响、如何利用脆弱性进行攻击、如何修补脆弱性、如何防止脆弱性被利用、如何探测目标系统的脆弱性、如何预测新的脆弱性的存在等一系列问题。
◆从技术角度而言，漏洞的来源主要有以下几个方面：。
◆软件脆弱性有其自身的特点，主要包括4个方面：
(1)脆弱性是软件系统中，但被利用后会产生严重的安全后果；
(2)在软件开发过程中，是大多数脆弱性的根本来源；
(3)与具体的系统环境密切相关，都有可能导致不同的脆弱性问题；
(4)旧的脆弱性，因此脆弱性问题会长期存在。
◆软件脆弱性的生命周期
脆弱性的引入阶段：引入软件脆弱性的原因有：
(1)输入验证错误；
(2)权限检查错误；
(3)操作序列化错误；
(4)边界检出错误；
(5)软件设计时的缺陷；
(6)其他错误。

软件设计时的瑕疵

软件实现中的弱点

软件本身的瑕疵

系统和网络的错误配置

自身特点

隐藏的一个弱点，本身不会引起危害

自觉或不自觉引入的逻辑错误

系统环境的任何差异

得到修补或纠正的同时可能引入新的脆弱性

生命周期

引入阶段

产生破坏效果阶段

修补阶段

从三方面分析

分析软件故障现象

分析软件开发

分析软件使用

分析对象

脆弱性数据

脆弱性软件

典型软件架构脆弱性分析

分层架构

事件驱动架构

MVC架构

微内核架构

微服务架构

大数据架构设计

大数据处理系统架构分析

三大挑战

处理非结构化和半结构化数据

探索大数据复杂性、不确定性特征描述的刻画方法及大数据的系统建模

数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响

lambda架构

目的

提供一个能满足大数据系统关键特性的架构

整合离线计算与实时计算

分层

批处理层

加速层

服务层

有点

容错好

查询灵活性高

易伸缩

易扩展

缺点

全场景覆盖带来的编码开销

具体场景重新离线训练一遍益处不大

重新部署和迁移成本很高

kappa架构

原理

在Lambda的基础上进行了优化，删除了Batch Layer的架构，将数据通道以消息队列进行替代

与lambda区别

Kappa不是Lambda的替代架构，而是其简化版本，Kappa放弃了对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求

Lambda直接支持批处理，因此更适合对历史数据分析查询的场景

优点

将实时和离线代码统一起来

缺点

消息中间件缓存的数据量和回溯数据有性能瓶颈

在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失

Kappa在抛弃了离线数据处理模块的时候，同时抛弃了离线计算更加稳定可靠的特点

lambda架构和kappa架构的对比和选择

选择考虑因素

业务需求

技术要求

系统复杂度

开发维护成本

历史数据处理能力