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