系统架构设计师
2024-01-12 16:40:21 5 举报
AI智能生成
系统架构师思维导图
作者其他创作
大纲/内容
企业信息化战略与实施
企业信息化与电子商务
物料需求计划
企业资源计划(ERP)
有统一规划:互联互通,便于事前事中沟通
客户关系管理(CRM)
市场营销和客户服务:支柱性功能
自动化
子主题
通过维护客户关系,让企业获得利益
供应链管理(SCM)
理念:强强联合,整合与优化“三流”,打通企业间的信息孤岛,严格的数据交换标准
信息化的三流
信息流
需求信息流:客户订单,生产计划,采购合同等
供应信息流:入库单,完成报告单,库存记录,可供应销售量等
资金流
物流
做得好的代表:丰田汽车的零库存理念
商业智能(BI)
打包技术,成为解决方案
数据仓库
面向主题
集成的
相对稳定的(非易失的)
反应历史变化
发展历史:数据太多,影响系统的运行,存历史数据
抽取,清理,装载,刷新
先建数据集市,再建数据仓库,数据集市为小一号数据仓库
数据集市
OLAP
联机分析处理
数据挖掘
方法
决策树
神经网络
遗传算法
关联规则挖掘算法
分类
关联分析:挖掘出隐藏在数据建的相互关系——>啤酒和尿布的故事
序列模式分析
分类分析:分类整理,添加标签,按标签分类
聚类分析:物以类聚,人以群分
数据湖
新的主题,不建议写这个主题
概念
ODS:存储所有数据,不做精加工
决策支持系统(DSS):了解概念
支撑决策的信息,指导信息,得到结论
人工智能的早期表现
需要大量的数据
业务流程重组(BPR)
从人工到计算机处理,业务流程发生变化
对业务流程优化的方式
业务流程重组(BPR)
根本性:对业务流程彻底性的再设计
业务流程管理(BPM)
持续性的调优
PDCA:戴明环
企业门户
企业网站
注重单向信息传递,缺乏互动
企业信息门户(eip)
把应用系统,数据资源和互联网资源统一到企业门户下
企业知识门户(EKP)
增加知识性内容
企业应用门户(EAP)
业务流程和企业应用为核心
企业通用门户
集成上面四种
企业应用集成(EAI)
问题:数据不一致,系统间不融合
切入点
表示集成(界面集成)
整合所有系统的操作,跳转:解决不了问题
数据集成
避开业务逻辑
在数据上保持一致
控制集成(应用集成,API集成)
业务逻辑
一个系统调用另一个系统的接口
业务流程集成(过程集成,B2B)
业务逻辑
企业对企业,先做业务分析,工作量大
电子商务
电子商务形式
b:企业,c:个人
企业对消费者:B2C
企业对企业:B2B
消费者对消费者:C2C
线上对线下:O2O
团购
练习题
数据库
主要做高并发事务处理--OLTP
数据仓库
主要做决策分析处理--OLAP
商业智能,大数据,数据挖掘
过程集成
强调处理流程,处理逻辑层次
共享数据库集成
无法解决数据语义不一致问题
ESB企业服务总线
业务系统开发语言差异大,数据格式和通信协议不同
工作流
灵活组装,灵活度最大
数据库模型
描述日常事务
数据库仓库模型
提供决策分析
生产计划
误导选项
数据挖掘
利用隐藏的知识,通过奖励分析模型预测企业未来发展趋势
联机分析处理
通过上卷,旋转
软件工程
软件开发方法
软件开发方法
结构化法
用户至上
严格区分工作阶段,每阶段有任务和成果
强调系统开发过程的整体性和全局性
系统开发过程工程化,文档资料标准化
自顶向下,逐步分解(求精)
原型法
适用于需求不明确的开发
包括抛弃原型和进化型原型
面向对象法
更好的复用性
关键在于建立一个全面、合理、统一的模型
分析、设计、实现三个阶段,界限不明确
面向服务的方法
SO方法有三个主要的抽象级别:操作、服务、业务流程
SOAD分为三个层次
基础设计层(底层服务构件)
应用结构层(服务之间的接口和服务级协定)
业务组织层(业务流程建模和服务流程编排)
服务建模
服务发现,
服务规约
服务实现
软件开发模型
瀑布模型
结构化开发代表
演化模型
增量模型
每一个增量均发布一个可操作的产品
螺旋模型
适合大项目
原型模型
喷泉模型
面向对象
V模型
测试贯穿整个生命周期,测试要尽早尽快
迭代模型/迭代开发方法
子主题
快速应用开发
构件组装模型/基于构件的开发方法
子主题
统一过程/统一开发方法
子主题
生命周期
目标里程碑
架构里程碑
能力里程碑
发布里程碑
敏捷开发方法
总体
基本原则
短平快的会议、小型版本发布、较少的文档、合作为重、客户直接参与、自动化测试、
适应性计划调整、结对编程、测试驱动开发、持续集成、重构
适应性计划调整、结对编程、测试驱动开发、持续集成、重构
分类
XP极限编程
XP在一些对费用控制严格的公司中的使用,已经被证明是非常有效的。
4大价值观
沟通、简单、反馈、勇气
5大原则
快速反馈、简单性假设、逐步修改、提倡更改、优质工作
12大最佳实践
计划游戏,小型发布,隐喻、简单设计、测试先行、重构、结对编程、
集体代码所有制、持续集成、每周工作40小时、现场客户、编码标准
集体代码所有制、持续集成、每周工作40小时、现场客户、编码标准
Cockburn的水晶系列方法
与XP的高度纪律性不同,Alistair探索了用最少纪律约束而仍能成功地方法
开发式源码
程序开发人员在地域上分布很广
SCRUM
明确定义了的可重复的方法过程
2-4周一个冲刺,每次完成一部分东西
Coad的功用驱动开发方法
编程人员分两类:首席程序员和’类‘程序员(class owner)
ASD方法
三个非线性的、重叠的开发阶段:猜测、合作与学习
模型驱动的开发方法
基于架构的开发方法
需求分析定义-->体系结构设计-->构件库建立-->应用软件构建-->测试及发布
逆向工程
从现有产品找出原有需求
实现级
程序的抽象语法树、符号表、过程的设计表示
结构级
反映程序分量之间相互依赖关系的信息,例如调用图、结构图、程序和数据结构
功能级
反映程序段功能及程序段之间关系的信息,例如数据和控制流模型
领域级
反映程序分量或诸实体与应用领域概念之间对应关系的信息,例如实体关系模型
净室软件工程
需求工程
概述
软件需求是指用户对系统在功能、行为,性能,设计约束等方面的期待
软件需求是指用户解决问题或达到目标所需的条件或能力,是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需要具备的条件或能力,以及反映这些条件或能力的文档说明。
需求定义:SRS;需求验证:验证需求的基线;变更控制:变更需求的基线
需求开发
需求获取
分类
技术
业务需求
高层次的需求
用户需求
使用系统的人的需求
系统需求
功能需求
性能需求
设计约束
项目管理
基本需求
期望需求
隐含的需求
兴奋需求
客户不需要做,你自己做了的
获取方法
收集资料
联合讨论会
用户访谈
书面调查
现场观摩
参加业务实践
阅读历史文档
抽样调查
需求分析
面向数据流的结构性分析方法(SA)
分析工具
数据流图DFD
过程:加工,一步步地执行指令,完成输入到输出地转换
外部实体:也称为源/宿,系统之外的的数据源或目的
数据存储:也称为文件,存放数据的地方,一般是以文件、数据库等形式出现
数据流:从一处到另一处的数据流向
实时连接:当过程执行时,外部实体与过程之间的来回通信
数据字典DD
数据模型:E-R图
功能模型:DFD数据流图
行为模型/状态模型:状态转换图
面向对象的分析方法
基本概念
对象
类
实体类
映射需求中的每个实体,实体类保存需求存储在永久存储体中的信息
边界类
用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处,包括所有窗体、报表、打印机和扫描仪等硬件的接口,以及与其他系统的接口。
控制类
用于控制用例工作的类,一般是由动宾结构的短语转化来的名词
抽象
封装
继承和泛化
继承:子类继承父类,子类更加具体
多个类抽象出一个具有公共特性的类,更加抽象
多态
接口
消息
组件
模式和复用
代表方法
OOA
Booch方法
逻辑模型
状态转换图
时序图
类图
对象图
物理模型
模块图
进程图
OMT方法
对象模型
对象图
描述系统中对象的静态结构、对象之间的关系、属性、操作。
它表示静态的、结构上的、系统的“数据”特征
它表示静态的、结构上的、系统的“数据”特征
动态模型
状态图
描述与时间和操作顺序有关的系统特性,如激发事件、事件序列、确定事件先后关系的状态。
表示瞬时、行为上的、系统的“控制”特征。
表示瞬时、行为上的、系统的“控制”特征。
功能模型
数据流图
描述与值的变换有关的系统特征:功能、映射、约束和函数依赖
OOSE方法
在OMT的基础上,对功能模型进行补充,提出用例,最终取代数据流图进行需求分析。
UML
UML4+1视图
逻辑视图:以问题域的词汇组成的类和对象集合
进程视图:可执行线程和进程作为活动类的建模,它是逻辑视图的一次执行实例
实现视图:对组成基于系统的物理代码的文件和组件进行建模。
部署视图:把组件物理地部署到一组物理的、可计算的节点上。
用例视图:最基本的需求分析模型
UML图
静态图(结构图)
类图
一组类、接口、协作和它们之间的关系
对象图
一组对象及他们之间的关系
构件图
一个封装的类和它的接口
制品图
系统的物理结构
部署图
软硬件之间映射
包图
由模型本身分解而成的组织单元,以及他们之间的依赖关系
组合结构图
动态图(行为图)
状态图
状态转换变迁
交互概览图
用例图
系统与外部参与者的交互
基础
概念
用例图描述一组用例、参与者及它们之间的关系
用户角度描述系统功能
参与者是外部触发因素
用例是功能单元
关系
包含关系/使用关系
用于重用
当可以从两个或两个以上的原始用例中提取公共行为,或者发现能够使用一个组件来实现每一个用例的部分功能是很重要的事时,应该用包含(使用)关系这个提取出来的公共行为称为抽象用例
扩展关系
用于分离出不同的行为
如果一个用例明显地混合了两种或两种以上地不同场景,即根据情况可能发生多种事情。可以将这个用例分为一个主用例和一个或多个辅用例。
泛化关系
用例建模流程
识别参与者(必须)
合并需求获得用例(必须)
细化用例描述(必须)
用例名称
简要说明
事件流
非功能需求
前置条件
后置条件
扩展点
优先级
调整用例模型(可选)
顺序图
强调按时间顺序
通信图
协作图
活动图
类似程序流程图,并行行为
定时图
强调实际时间
UML关系
软件系统建模
系统设计
界面设计
置于用户控制之下
减少用户的记忆负担
保持界面的一致性
结构化设计
面向对象设计
设计原则
单一职责原则:设计目的单一的类
开放-封闭原则:对扩展开放,对修改封闭
李氏替换原则:子类可以替换父类
依赖导致原则:要依赖于抽象,而不是具体实现;针对接口编程,而不是针对实现编程
接口隔离原则:使用多个专门的接口比使用单一的总接口好
组合重用原则:尽量使用组合,而不是继承关系达到重用目的
迪米特原则(最少知识法则):一个对象应当对其他对象尽可能少的了解
设计模式
概念
架构模式
软件设计中的高层决策,例如C/S结构属于架构模式,架构模式反映了开发软甲系统过程中所做的基本设计决策
设计模式
主要关注软件系统的设计与实现,与具体语言无关
惯用法
最低层的模式,关注软件系统的设计与实现,与具体的编程语言相关,即语言的惯用法
分类
创建型:创建对象
工厂方法(Factory Method)模式
动态生产对象
定义一个创建对象的接口,但由子类决定需要实例化哪个类。工厂方法使得子类实例化的过程推迟
抽象工厂(Abstract Factory)模式
生产成系列对象
提供一个接口,可以创建一系列相关或相互依赖的对象,而无需指定它们具体的类
原型(Prototype)模式
克隆对象
用原型实例指定创建对象的类型,并且通过拷贝这个原型来创建新的对象
单例(Singleton)模式
单实例
保证一个类只有一个实例,并提供一个访问它的全局访问点
构建器(Builder)模式
复杂对象构造
将一个复杂类的表示与其构造相分离,使得相同的构造过程能够得出不同得表示
结构型:更大的结构
适配器(Adapter)模式
转换接口
将一个类的接口转换成用户希望得到的另一种接口,它使原本不相容的接口得以协同工作
桥接(Bridge)模式
继承树拆分
将类的抽象部分和它的实现部分分离开来,使它们可以独立变化
组合(Composite)模式
树形目录结构
将对象组合成属性结构以表示“整体-部分”的层次结构,使得用户对单个对象和组合对象的使用具有一致性
装饰(Decorator)模式
动态附加职责
动态的给一个对象添加一些额外的职责。它提供了用子类扩展功能的一个灵活的替代,比派生一个子类更加灵活
外观(Facade)模式
对外统一接口
定义一个高层接口为子系统中的一组接口提供一个一致的外观,从而简化了该子系统的使用
享元(Flyweight)模式
汉字编码
提供支持大量细粒度对象共享的有效方法
代理(Proxy)模式
快捷方式
为其他对象提供一种代理以控制这个对象的访问
行为型:交互和职责分配
责任链(chain of Responsibility)模式
传递职责
通过给多个对象处理请求的机会,减少请求的发送者与接收者之间的耦合
将接收对象链接起来,在链中传递请求,直到有一个对象处理这个请求
将接收对象链接起来,在链中传递请求,直到有一个对象处理这个请求
命令(Command)模式
日志记录,可撤销
将一个请求封装为一个对象,从而可用不同的请求对客户进行参数化,将请求排队或记录日志,支持可撤销的操作
解释器(Interpreter)模式
虚拟机的机制
给定一种语言,定义它的文法表示,并定义一个解释器,该解释器用来根据文法表示来解释语言中的句子
迭代器(Iterator)模式
数据集
提供一种方法来顺序访问一个聚合对象中的各个元素,而不需要暴露该对象的内部表示
中介者(Mediator)模式
不直接引用
用一个中介对象来封装一系列的对象交互。它使各对象不需要显示的相互调用,从而达到低耦合,还可以独立地改变对象间的交互
备忘录(Memento)模式
游戏存档
在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,从而可以在以后将该对象恢复到原先保存的状态
观察者(Observer)模式
联动
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖它的对象都得到通知并自动更新
状态(State)模式
状态变成类
允许一个对象在其内部状态改变时改变它的行为
策略(Strategy)模式
多方案切换
定义一系列算法,把他们一个个封装起来,并且使它们之间可互相替换,从而让算法可以独立于使用它的用户而变化
模板方法(Template Method)模式
框架
定义一个操作中的算法骨架,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤
访问者(Visitor)模式
数据与操作分离
表示一个作用于某对象结构中的各元素的操作,使得在不改变各元素的类的前提下定义作用于这些元素的新操作
考察点:1.设计模式分类;2.三种类型定位;3.应用场景和特点
测试与评审
系统运行与软件维护
软件架构设计
软件架构的概念
体系结构=架构,需求分析到软件设计的中间桥梁.
架构设计就是需求分配,将满足需求的职责分配到组件上
架构设计就是需求分配,将满足需求的职责分配到组件上
架构风格:描述某一特定应用领域中系统组织方式的惯用模式
定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束.
词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的.
定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束.
词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的.
作用: 为软件系统提供一个结构, 行为和属性的高级抽象,由构成系统的元素的描述, 这些元素相互作用
指导元素集成的模式以及这些模式的约束组成
指导元素集成的模式以及这些模式的约束组成
软件架构是项目干系人进行交流的手段,明确了对系统实现的约束条件,
决定了开发和维护组织的组织结构,制约着系统的质量属性
决定了开发和维护组织的组织结构,制约着系统的质量属性
使得推理和控制的更改更加简单,有助于循序渐进的原型设计
可以作为培训的基础
可以作为培训的基础
是可传递和可复用的模型,通过研究软件架构可能预测软件的质量
软件架构建模
结构模型
以架构的构件, 连接件和其他概念来刻画结构
框架模型
不太侧重描述结构的细节而更侧重于整体的结构
动态模型
系统的"大颗粒"的行为性质
过程模型
构建系统的步骤和过程
功能模型
由一组功能构件按层次组件,下层向上层提供服务
软件架构风格
概念
架构设计的一个核心问题是能否达到架构级的软件复用
架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个构件有效地组织成一个完整的系统
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
分类
数据流风格
批处理序列
构件为一系列固定顺序的计算单元,构件之间只能通过数据传递交互
每个处理步骤是一个独立的程序,每一步必须在其前一步结束后才能开始,
数据必须式完整的,以整体的方式传递
每个处理步骤是一个独立的程序,每一步必须在其前一步结束后才能开始,
数据必须式完整的,以整体的方式传递
管道-过滤器
每个构件都有一组输入输出,构件度输入的数据流,处理之后产生输出数据流。
处理数据流的构件为过滤器,连接件就是数据流传输的管道,传输数据流。
早期编译器采用这种架构。要一步一步处理的,可以采用这种架构风格
处理数据流的构件为过滤器,连接件就是数据流传输的管道,传输数据流。
早期编译器采用这种架构。要一步一步处理的,可以采用这种架构风格
调用/返回风格
主程序/子程序
单线程控制,构件为主程序和子程序,子程序通常可合成为模块。
过程调用作为交互机制,充当连接件。调用关系具有层次性。
过程调用作为交互机制,充当连接件。调用关系具有层次性。
面向对象
构件是对象,连接件是对象间的交互方式,对象通过函数和过程的调用来交互的
层次结构
构件组织成一个层次结构,连接件由决定层间交互的协议定义。
每一层为上一层提供服务,使用下一层的服务。隐藏问题的复杂度
修改某一层最多影响两层(通常只能影响上一层)
每一层为上一层提供服务,使用下一层的服务。隐藏问题的复杂度
修改某一层最多影响两层(通常只能影响上一层)
优点
支持基于可增加抽象层的设计,允许将一个复杂问题分解成一个增量步骤序列的实现。
不同的层次的抽象级别不同:越靠近底层,抽象级别越高;越靠近顶层,抽象级别越低
基于层间关系,允许每一层用不同的方法实现,为软件复用提供了强大的支持
缺点
并不是每一个系统都可以很容易的划分为分层的模式
很难找到一个合适的,正确的层次抽象方法
独立构件风格
进程通信
构件是独立的过程,连接件是消息传递。构件通常是命名过程,
消息传递方式可以是点对点,异步或者同步的方式,以及远程过程(方法)调用等
消息传递方式可以是点对点,异步或者同步的方式,以及远程过程(方法)调用等
事件驱动系统(隐式调用)
构件是匿名的过程,连接件为过程之间的隐式调用。
主要优点为软件复用提供支持,为构件的演化和维护带来方便。
缺点:构件放弃了对系统计算的控制
主要优点为软件复用提供支持,为构件的演化和维护带来方便。
缺点:构件放弃了对系统计算的控制
虚拟机风格
解释器
包含:一个完成解释工作的解释引擎
一个包含将被解释的代码的存储区,
一个记录解释引擎当前工作状态的数据结构
一个巨鹿源代码被解释执行的进度的数据结构
一个包含将被解释的代码的存储区,
一个记录解释引擎当前工作状态的数据结构
一个巨鹿源代码被解释执行的进度的数据结构
软件中含有一个虚拟机,可以仿真硬件的执行过程和一些关键应用,缺点时执行效率低
基于规则的系统
组成
规则集,规则解释器,规则/数据选择器和工作内存
一般用于人工智能领域和DSS中
仓库风格
数据库系统
黑板系统
组成
知识源
包括若干个独立计算的不同单元,提供解决问题的知识。知识源响应黑板的变化,也只能修改黑板
黑板
一个全局数据库,包含问题域解空间的全部状态,是姿势元相互作用的唯一媒介
控制
知识源响应式通过黑板状态的变化来控制的。
应用
黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理,问题规划和编译器优化等)
超文本系统
构件以网状链接方式相互连接,用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。
超文本式一种非线性的网状信息组织方法,它以结点为基本单位,链作为结点之间的联想式关联。
通常应用在互联网领域。
超文本式一种非线性的网状信息组织方法,它以结点为基本单位,链作为结点之间的联想式关联。
通常应用在互联网领域。
现代集成编译环境一般采用这种架构风格
过程控制
闭环控制架构
适合嵌入式系统,设计连续的动作与状态
C2风格
基本规则
构件和连接件都有一个顶部和一个底部
构件的顶部要连接到连接件的底部,构件的底部要连接到连接件的顶部,构件之间不允许直连
一个连接件可以和任意数目的其他构件和连接件连接
当两个连接件进行直接连接时,必须有其中一个的底部到另一个的顶部
层次架构风格
两层C/S
特点
开发成本高
客户端程序设计复杂
信息内容和形式单一
用户界面风格不一
软件移植困难
软件维护和升级困难
新技术不能轻易使用
三层C/S
三层B/S
特点
缺乏动动态页面的支持能力,没有集成有效的数据库处理功能
安全性难以控制
采用B/S架构的应用系统,在数据查询等响应速度上,要远远低于C/S架构
B/S架构的数据提交一般以页面为单位,数据的动态交互性不强,不利于OLTP应用
组成
表现层
MVC->model view controller
Model(模型)应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据->JSP
View(视图)处理数据显示部分。通常视图时依据模型数据创建的。->Servlet
Controller(控制器) 处理用户交互的部分。通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据。->Entity Bean,Session Bean
MVP->model view presenter
是MVC的变种
实现了View和Model之间的解耦
更好的支持单元测试
MVVM->view viewmodel model
中间层
数据访问层
orm
数据架构层
混合架构
内外有别
查改有别
富互联网应用(RIA)
结合了C/S架构反应速度快,交互性强的优点,以及B/S架构传播范围广及容易传播的特性
简化并改进了B/S架构的用户交互
数据能够被缓存咋i客户端,从而实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面
面向服务架构
基于服务的架构(SOA)
基本概念
服务
服务是一种为了满足每项业务需求的操作、规则等的逻辑组合,它包含一系列有序活动的交互,为实现用户目标提供支持。
特点
服务构件粗粒度,传统构件细粒度居多
服务构件的接口是标准的,主要是WSDL接口,传统构件常以具体的API形式出现
服务构件的实现与语言无关,传统构件绑定某种特定语言
服务构件可以通过构件容器提供QoS的服务,传统构件完全由程序代码直接控制
实现方式
Web Service
底层传输层
服务通信协议层
服务描述层
服务层
业务流程层
服务注册层
ESB
提供位置透明性的消息路由和寻址服务
提供服务注册和命名的管理功能
支持多种的消息传递范型
支持多种可以广泛使用的传输协议
支持多种数据格式以及其相互转换
提供日志和监控功能
服务注册表
服务注册
应用开发者(服务提供者)向注册表公布服务的共能
服务位置
服务使用者(服务应用开发者),帮助它们查询注册服务,寻找服务自身要求的服务。
服务绑定
服务使用者而利用检索到的服务接口来编写代码,所编写的代码将与组测的服务绑定,调用注册的服务,以及与它们实现互动。
关键技术
发现服务
UDDI
DISCO
描述服务
WSDL
WebService接口对应的WSDL文件,该文件通过xml格式说明如何调用,可以看作WebService的接口文档(使用说明书)
XML
Schema
消息格式层
SOAP
简单对象访问协议,访问网络服务协议;基于XML的简易协议,可使应用程序在HTTP之上进行信息交换。
是一种网络通信协议,用于网络上,不同平台,不同语言的应用程序件的通讯
SOAP协议=HTTP协议+XML数据格式
REST
HTTP+XML进行基于Web通信的技术
简单性,缺少严格配置文件
只支持几个操作(POST,GET,PUT,DELETE)
强调信息本身,称之为资源
网络上的所有事务都被抽象为资源
每个资源对应一个唯一的资源标识
通过通用的连接器接口对资源进行操作
对资源的各种操作不会改变资源标识
所有的操作都是无状态的
编码格式层
XML
DOM
SAX
传输协议层
HTTP
TCP/IP
SMTP
微服务
概念:很小的服务,属于面向服务架构的一种。
特点
小专注于做一件事情
轻量级的通信机制
松耦合,独立部署
优势
技术异构性
弹性
扩展
简化部署
与组织结构相匹配
可组合性
对可替代性的优化
挑战
分布式系统的复杂度
运维成本
部署自动化
DevOps与组织结构
服务间依赖测试
服务间依赖管理
SOA和微服务对比
MDA
组成
模型,客观事务的抽象表示
架构,构成系统的部件,连接件及其约束的规约
什么使模型驱动
使用模型完成软件的分析,设计,构建,部署,维护等各个开发活动
起源于分离系统规约和平台实现的思想
主要目标
可移植性 Protability
互通性 interoperability
可重用性 Reusability
核心模型
平台独立模型(PIM)
具有高层抽象,独立于任何实现技术的模型。
平台相关模型(PSM)
为某种特定实现技术量身定做,让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM
代码Code
用源代码对系统的描述(规约),每个PSM都被变换成代码。
架构描述语言ADL
特定领域软件架构
基于架构的软件开发
软件质量属性
性能
指系统的响应能力,即要经过多长事件才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数
代表参数-响应时间、吞吐量
设计策略:优先级队列,资源调度
可用性
系统能够正常运行的时间比例。经常用两侧故障之间的时间长度火灾出现故障时系统能够恢复正常的速度来表示。
参数:故障间隔时间
策略:冗余、心跳线
安全性
系统在向合法用户提供服务的同时能够组织非授权用户使用的企图活拒绝服务的能力。
安全性游客划分为机密性,完整性,不可否认性及可控制性等特性。
安全性游客划分为机密性,完整性,不可否认性及可控制性等特性。
策略:追踪审计
可修改性
能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过考察这些变更的代价衡量可修改性。
策略:信息隐藏
可靠性
软件系统在应用活系统错误面前,在意外活错误使用的情况下维持软件系统的功能特性的基本能力。主要考虑两个方面:容错,健壮性
参数:MTTF,MTBF
策略:冗余,心跳线
功能性
系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多活大多数构建的相互协作。
可变性
体系结构经扩充活变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则,
在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品(例如,软件产品线)的基础时,可变性时很重要的。
在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品(例如,软件产品线)的基础时,可变性时很重要的。
互操作性
作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境相互作用。为了支持互操作性,
软件体系结构必须为外部科室的功能特性和数据结构提供精心设计的软件入口。
程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题,这种互操作性也影响应用的软件体系结构。
软件体系结构必须为外部科室的功能特性和数据结构提供精心设计的软件入口。
程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题,这种互操作性也影响应用的软件体系结构。
软件架构评估
基本概念
三点
风险点
系统架构风险时值架构设计中潜在的,存在问题的架构决策所带来的隐患
敏感点
为了实现某种特定的质量属性,一个或多个构建所具有的特性
权衡点
影响多个质量属性的特性,时多个质量属性的敏感点。
三个方式
基于场景
要点
确定应用领域的功能和软件架构的结构之间的映射
设计用于体现待评估质量属性的场景
分析软件架构对场景的支持程度
方法
软件架构分析法(SAAM)
最初用于分析架构可修改性,后扩展到其他质量属性。
架构权衡分析法(ATAM)
特点
在SAAM的基础上发展起来的,主要针对性能,实用性,安全性和可修改性,
在系统开发之前,对这些质量属性进行评价和折中
在系统开发之前,对这些质量属性进行评价和折中
实施过程
第一阶段 场景和需求收集
第二阶段 架构视图和场景实现
第三阶段 属性模型构造和分析
第四阶段 折中标志敏感度
成本效益分析法(CBAM)
质量效用树
软件产品线
构件和中间件技术
构件
概念
构件的定义
定义1
软件构件是一种组装单元,他居于规范的接口规约和现实的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
定义2
构件是某系统中有价值的,几乎独立的并可替换的一个部分,他在良好定义的体系结构语境内满足某清晰地功能。
定义3
构件是一个独立发布的功能部分,可以通过其接口访问他的服务。
构件,对象,模块的区分
构件系统架构特性
构件系统体系结构由一组平台决策,一组构建框架和构件框架之间的互操作设计组成。
构件框架是一种专用的体系结构(通常围绕一些关键的机制),同时,也是一组固定地作用于构件层次机制地策略。
构件框架是一种专用的体系结构(通常围绕一些关键的机制),同时,也是一组固定地作用于构件层次机制地策略。
概念框架地互操作设计包括提醒体系结构连接地所有框架间地互操作地规则
构件是一组通常需要同时部署地原子构件。
一个原子构件是一个模块和一组资源。
模块是一组类和可能地非面向对象地结构体,比如过程或者函数。
资源是一个类型化地项地固定集合
构件的复用
检索与提取构件
基于关键字的检索
片面检索法
超文本检索法
理解与评价构件
要复用构件,准确地理解构件至关重要。特别是对构件修改使用时
为达到目的,必须要求构件地开发过程遵循公共标准
一般构件库地文档中全面而准确地说明以下内容:构件地功能与行为,相关的领域知识、可适应性约束条件与例外情形、可以预见的修改部分及修改方法
修改构件
理想状态是直接复用构件中现成的构件,但大多数情况下,必须对构件进行修改,应对新的需求
为了减少构件修改的工作量,在开发构件时尽量使构件的功能、行为和接口设计更为抽象化,通用化和参数化。复用的时候调整实参的选取来调整构件的行为和功能。这样还不行复用者借助设计信息和文档来修改构件。
构件库中没有可修改使用的构件,按新需求开发构件,存入构件库。
组装构件
基于功能的组装技术
基于数据的组装技术
面向对象的组装技术
构件组装阶段失配问题
构件引起的失配
连接件引起的失配
系统成分对全局体系结构的假设存在冲突引起的失配
中间件
概念
中间件是一种独立的系统软件或服务程序,可以帮助分布式应用软件在不同的技术之间共享资源
主要作用
负责客户机与服务器之间的连接和通信,以及客户机与应用层之间的高校率通信机制
提供应用层不同服务之间的互操作机制,以及应用层与数据库之间的连接和控制机制
提供多层架构䣌应用开发和运行的平台,以及应用开发框架,支持模块化的应用开发
屏蔽硬件,操作系统,网络和数据库的差异
提供应用的负载均衡和高可用性,安全机制与管理功能,以及交易管理机制,保证交易的一致性
提供一组通用的服务区执行不同的功能,避免重复的工作和使应用之间可以协作
优点
面向需求。
业务的分隔和包容性。
设计与实现隔离。
隔离复杂的系统资源
符合标准的交互模型
软件复用
提供对应用构件的管理
主要中间件
远程过程调用
对象请求代理
远程方法调用
面向消息的中间件
事务处理监控器
代表
CORBA
伺服对象(Servant)
CORBA对象的真正实现,负责完成客户端请求
对象适配器(Object Adapter)
用于屏蔽ORB内核的实现细节,为服务器对象的实现者提供抽象接口,以便它们使用ORB内部的某些功能
对象请求代理(Object Request Broker)
解释调用并负责查找实现该请求的的对象,将参数传递给找到的对象,
并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式,实现,激活或存储机制。
并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式,实现,激活或存储机制。
主要内容
对象请求代理(Object Request Borker,ORB)。
负责对象在分布环境中透明地收发请求和响应,它是构建分布对象应用,在异构或同构环境下实现应用间互操作地基础
对象服务(Object Service)
为使用和实现对象而提供的基本对象集合,这些服务应独立于应用领域。
公共设施(Common Facilitites)
向终端用户提供一组共享服务接口,例如系统管理,组合文档和电子邮件等。
应用接口(Application Interfaces)
由销售商提供的可控制其接口的产品,相应于传统的应用层表示,处于参考模型的最高层。
领域接口(Domain Interfaces)
为应用领域服务而提供的接口,如OMG组织为PDM系统制定的规范。
Web架构设计
多方位分析
从架构来看
MVC
MVP
MVVM
REST(表述性状态转移)
简介
是一种只是用HTTP和XML进行基于Web通信的技术,可以降低开发的复杂性,提高系统的可伸缩性。
5个原则
网络上的所有事务都被抽象为资源
每个资源对应一个唯一的资源标识
通过通用的连接器接口对资源进行操作
对资源的各种操作不会改变资源标识
所有的操作都是无状态的
WebService
微服务
中台
从缓存来看
MemCache
一个高性能的分布式的内存对象缓存系统,用于动态Web应用以减轻数据库负载。Memchache通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种各样的数据,包括图像、视频、文件以及数据库检索的结果等。
Redis
一个开源使用ANSI C语言编写、支持网络、可基于内存也可以持久化的日志型、Key-Value数据库,并提供多种语言的API。
常见难题
缓存雪崩
原因:大部分缓存失效-->数据库崩溃
解决方案
缓存的高可用性
缓存降级
Redis备份
提前演练
缓存穿透
原因:查询无数据返回-->直接查询数据库
解决方案
如果查询结果为空,直接设置一个默认值存放到缓存,这样第二次到缓冲中获取就有值了。
设置一个不超过5分钟的过期时间,以便能正常更行缓存。
设置一个不超过5分钟的过期时间,以便能正常更行缓存。
设置布隆过滤器将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。
Squid
Squid是一个高性能的代理缓存服务器,Squid支持FTP、gopher、HTTPS和HTTP协议。和一边的代理缓存软件不同,Squid用一个单独的,非模块化的、I/O驱动的进程来处理所有的客户端请求。
Redis和Memcache的差异
Redis和Memcache都是将数据放在内存中,都是内存数据库。他们都支持key-values数据类型。
同时Memcache还可用于缓存其他东西,例如图片、视频等等,
Redis还支持list、set、hash等数据结构的存储
同时Memcache还可用于缓存其他东西,例如图片、视频等等,
Redis还支持list、set、hash等数据结构的存储
Redis支持数据的持久化,可以将内存中的数据保存在次磁盘中,重启的时候可以再次加载进行使用
Memcache挂掉之后,数据就没了
Memcache挂掉之后,数据就没了
灾难恢复——Memcache挂掉之后,数据就没了
Redis数据丢失之后可以恢复
Redis数据丢失之后可以恢复
在Redis中,并不是所有数据都存在内存中,物理内存用完时,Redis可以将很久没用到的value交换到磁盘。
Memcache则所有数据在内存中。
Memcache则所有数据在内存中。
Redis在很多方面支持数据库的特性,可以说它就是一个数据库系统。
Memcache只是简单的K/V缓存
Memcache只是简单的K/V缓存
如果有持久化方面的需求或对数据类型和处理有要求的应该选择Redis。
如果简单的key/value存储应该选择Memcache。
如果简单的key/value存储应该选择Memcache。
从并发分流来看
集群(负载均衡)
负载均衡技术
应用层
基于特定软件的负载均衡技术(HTTP重定向)
原理:应用层的请求转发。用户的请求起始已经到了HTTP重定向负载均衡服务器,服务器根据算法要求用户重定向,用户收到重定向请求后,再次请求真正的集群。
特点:实现简单,性能较差
反向代理负载均衡
原理:用户请求到达反向代理服务器时(已经到达网站机房),由反向代理服务器根据算法转发到具体的服务器。常用的apache,nginx都可以充当方向代理服务器
特点:部署简单,单代理服务器可能成为性能的瓶颈。
传输层
基于DNS的负载均衡
原理:在用户请求DNS服务器,获取域名对应的ip地址时,dns服务器直接给出负载均衡后的服务器IP
特点:效率比HTTP重定向高,减少维护负载均衡服务器成本。缺--应用服务器故障不能及时通知dns,控制权在域名服务商手中,网站不能做更多的改善和更强大的管理
基于NAT的负载均衡
原理:将一个外部IP地址映射为多个IP地址,对每次连接请求动态地转换为一个内部节点的地址
特点:技术较为成熟,一般在网关位置,可以通过硬件实现。像四层交换机一般就采用了这种技术。
其他
混合型负载均衡
算法使用
动态
最小连接数算法
加权最小连接数算法
加权百分比算法
静态
轮转算法
加权轮转算法
源地址哈希散列算法
目标得知哈希散列算法
随机算法
软硬件划分
硬件负载均衡:F5
软件负载均衡
LVS
Nginx
HAproxy
CDN(内容发布网络)
内容发布网络。其基本思路时尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节,使内容传输的更快、更稳定。
从持久化来看
Hibernate
Mybatis
从分布存储来看
Hadoop
FastDFS
区块链
从数据编码来看
XML
JSON
从web应用服务器来看
Apache
WebSPhero
WebLogic
Tomcat
JBOSS
IIS
其他
静态化
有状态服务
与无状态服务相反,他会自身保存一些数据,先后的请求是有关联的。
无状态服务
对单次请求的处理,不依赖其他请求,也就是说,处理一次请求所需的全部信息,要么都包含在这个请求里,要么可以从外部获取到(比如说数据库),服务器本身不存储任何信息。
响应式Web设计
系统安全分析与设计
安全基础技术
对称与非对称加密
数字签名
信息摘要
网络安全
安全协议
网络攻击
等级保护标准
系统可靠性分析与设计
可靠性相关基本概念
系统可靠性分析
软件可靠性设计
项目管理
范围管理
时间管理
成本管理
软件质量管理
软件配置管理
风险管理
计算机组成与体系结构
Flynn分类法
CISC与RISC
存储系统
流水线技术
效验码
嵌入式系统
系统配置与性能评价
性能指标
阿姆达尔解决方案
性能评价方法
操作系统
进程管理
进程的状态
前驱图
信号量与PV操作
死锁及银行家算法
存储管理
段页式存储
页面置换算法
文件管理
绝对路径和相对路径
索引文件
位示图
作业管理
设备管理
虚设备与SPOOLING技术
微内核操作系统
嵌入式操作系统
计算机网络
TCP/IP协议族
DHCP与DNS
TCP与UDP
网络规划与设计
逻辑设计与物理设计
网络接入
3G与4G标准
网络存储
综合布线
物联网
云计算
数据库系统
数据库模型
ER模型
关系代数
规范化理论
并发控制
数据库完整性约束
分布式数据库
数据仓库与数据挖掘
数学与经济管理
图论应用
最小生成树
最短路径
网络与最大流量
运筹方法
线性规划
动态规划
预测与决策
数学建模
知识产权与标准化
保护范围与对象
保护期限
知识产权人确定
侵权判断
标准分类
标准代号的识别
论文
论文框架
0 条评论
下一页