一线架构师实践的思维脑图
2020-10-10 10:11:26 0 举报AI智能生成
登录查看完整内容
一线架构师实践指南-读书笔记-脑图
作者其他创作
大纲/内容
质量约束
鲁棒性
鲁棒是Robust的音译，也就是健壮和强壮的意思。
它也是在异常和危险情况下系统生存的能力。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。
根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。
鲁棒性差在不正确使用的情况下，可能会把系统搞瘫痪
持续可用性
性能
可扩展性
安全性
可互操作性
可维护性
可移植性
可靠性
可重用性
可测试性
易用性
预备架构阶段
执行指导
1. 需求结构化
衍生需求
发现遗漏需求
2. 分析约束影响
应用推导法则推导出约束带来的隐性需求
应用查漏法则进行需求遗漏补充
3. 确定关键质量
根据系统所在领域的特点及系统规模等因素，确定架构设计重点支持哪些质量属性
分析上述质量属性之间的制约关系，第一时间制定权衡折衷的具体策略
5大原则
1. 分类合适+必要扩充
2. 考虑多方涉众
3. 检查性思维
4. 识别矛盾+划定优先级
5. 严格程度复合领域与规模特点
4. 确定关键功能
5. 权衡质量属性之间的矛盾个关系
需求属性
关键需求
特色需求
高风险需求
三个需求层次
业务级需求
用户级需求
开发级需求
三类需求
功能
质量
约束
从需求转入设计时，因为指定方案过程的复杂性，会激增出大量的衍生需求（针对一种特定设计方案的需求）。设计需求是原始需求的50倍之多。
二维需求观
架构失败的常见原因
遗漏至关重要的架构影响因素 50%
不能驯服频繁变化的需求 40%
不能覆盖架构各方面 30%
不能验证架构并作出调整 40%
影响架构的因素
领域不同
如航空航天
电信
电子政务
规模不同
项目
产品
平台
条件不同
工期
预算
标准
不同需求，影响架构的原理不同
功能是发现职责的依据
每个功能都是由一条“职责协作链”完成的，架构师通过为功能规划职责责任链，将职责分配到子系统、为子系统界定接口、确定基于接口的交互机制，来推动架构设计的进行。
质量需求
质量是完善架构设计的动力
（必须）基于当前的架构设计中间成果，进一步考虑具体的质量要求，对架构设计中间成果进行细化、调整、甚至推到重来，一步步地使架构设计完善起来
质量和功能共同影响着架构设计，抛开功能，单依据质量要求设计架构是不可能的
约束对架构设计的影响分为几类
直接制约设计决策的约束（例如“系统运行与Unix平台之上”）
转化为功能需求的约束（例如“本银行系统执行现行利率”引出“利率调整”功能）
转化为质量属性需求的约束（例如“柜员计算机平均水平不高”引出易用性需求）
概念架构阶段
概念架构定义
概念架构满足“架构=组件+交互”的基本定义，值关注高层组件
对高层组件的职责进行了笼统的节点，给出组件间的相互关系
不涉及接口细节
概念架构的意义
在常规性架构参考的基础上，表达出重大需求、特色需求、高风险需求的要求，给出高层次的解决方案
实践要领
重大需求塑造概念架构
三个步骤
初步设计
借助鲁棒图发现在职责为目的的初步设计
高层分隔
分层多个二级系统或具体子系统
考虑非功能需求
鲁棒图的10条经验
语法
遵守建模规则
鲁棒图的建模规则
1. 参与者只能与边界对象交谈
2. 边界对象只能与控制对象和参与者交谈
3. 实体对象只能与控制对象交谈
4. 控制对象技能与边界对象交谈，也能与控制对象交谈，但不能与参与者交谈
简化建模语法
思维
遵循3中元素的发现思路
增量建模
实体对象！=持久化对象
技巧
只对关键功能（用例）画鲁棒图）
每个鲁棒图有2~5个控制对象
注意
勿关注细节
勿过分关注UI，除非辅助或验证UI设计
鲁棒图！=用例规约的可视化
1. 复杂系统切分多个系统
当系统覆盖的功能范围比较广泛时
当系统需要部署在比较复杂的硬件环境中时
2. 系统切分为子系统
分层方式（切分方式）
Layer：逻辑层
Tier：物理层
按通用性分层
没有绝对的上下关系，而是将不同通用性的组件分离分层
在分层的基础上做技术堆叠图
考虑非功能性需求
目标-场景-决策表
目标-场景-决策
细化架构
多视图优点
便于思考
因为分而治之的思维方式
便于交流
因为在一定程度上分离了涉众的关注点
要支持开发组相对独立地进行工作，需要提供指导和限制作用更明确的“规约”一级的设计
细化机构和概念架构存在如下典型差异
接口
细化架构中接口占据核心的地位
概念架构中并不关心明确的接口定义
子系统
细化架构总是通过子系统和模块来分隔整个系统，并明确子系统间的接口
概念架构只抽象组件，没有具体接口，只有职责
交互机制
细化架构中的交互机制应是“实在”的
概念架构中的交互机制是“概念化”的
方案和架构的联系与区别
方案包含一定的架构内容
方案涉及的架构基本在概念架构一级
架构设计的工作还远未完成
架构争论
程序员说：架构就是决定需要编写哪些类，使用哪些线程框架。
程序经理说：架构就是模块的划分和接口的定义
系统分析员：软件架构就是为业务领域对象的关系建模
配置管理员说：软件架构就是开发出来的及编译后的软件到底是个啥结构
数据库工程师：软件架构规定了持久化数据的结构，其他一切都不过是对数据的操作而已。
部署工程师：软件架构规定了软件部署到硬件的策略。
用户说：软件架构就是决定一个个功能子系统如何划分。
架构多视图
运行架构
进程、线程
逻辑架构
接口的定义
子系统的划分
（C类结构语言）结构化方法的模块
逻辑层（Layer）
物理架构
服务器选型
物理层（Tier）
开发架构
源程序目录
数据架构
数据分布与数据库Schema
没选（RDBMS）文件格式
（嵌入式系统）Flash存储结构
3种策略
分层的细化
3层变成更多层
分区的引入
只分层无法深度完成一个功能，进行快速迭代开发
机制的提取
机制的定义
软件系统中的机制，是指预先定义好的，能够完成预期目标的、基于抽象角色的协作方式。机制不仅包含了协作关系，同时也包含了协作流程。
通俗点讲，就是通用单元提取
整体执行思路
质疑驱动
结构设计和行为设计相分离
结构切分
职责责任链协作分析
时序图
10条经验
划分子系统：分层的细化
划分子系统：分区的引入
划分子系统：机制的提取
接口的定义：协作决定接口
选用序列图：杜绝协作图
包-接口图：从结构导行为的桥
灰盒包图：描述关键子系统
循序渐进的螺旋思维
设计模式：包内结构
设计模式：包间协作
3项任务
硬件选择与物理拓扑
软件到硬件的映射关系
方案的优化
多方涉众目标
高性能（攻）
持续可用性（攻）
可伸缩性（攻）
经济性（守）
技术可行性（守）
易维护性（守）
。。。。
思维要点
如何降低物理节点“内”的计算开销
如何降低物理节点“间”的通信开销
如何避免物理节点“内”CPU、内存、硬盘灯资源的争用
如何避免物理节点“间”网络的宽带资源冲突
几点考虑
物理架构中的每个节点之上至少有一条控制流
为了实现节点之间的通信，通常做法是引入一条控制流专门负责
节点是具有主动行为的设备，为其引入专门的控制流
在需求一级的描述中就是并行或并发的，引入多条控制流。
来自用户或外部系统的并发访问，长要求后端服务支持多控制流。
如果控制流关系复杂，可以考虑引入对其他控制流进行协调的控制流。
控制流的三种手段
进程
线程
终端服务程序
工作内容
将逻辑职责映射为程序单元
要自主编写的源程序
可重用的库、框架
其他方式（如shell脚本、平台支持下的配置文件）
开发技术选型
开发语言
开发工具
程序单元间的关系
project划分
project目录结构
编译依赖关系
根据数据产生、使用、管理的特点，有6中策略
独立Schema
多个独立的小项目应独立Schema
集中
集中存储、分布访问
分区
分区方式
水平分区
地域广的情况下要水平分区
垂直分区
复制
保存多个副本
子集
某节点因功能或非功能考虑而保存全体数据的一个相对固定的子集
优点
通过数据“本地化”，提升了数据访问性能
数据的专门副本，利于有针对性地进行优化
重组
将多组同源的数据进行重组
统计性重组
结构性重组
典型例子是BI系统
3条应用原则
合适原则
把握系统特点，确定分布策略
比如电子病历、有只读属性，可以采用分布策略。而身份信息容易修改，建议集中式
综合原则
不同分布策略，可以综合运用
应对复杂系统
优化原则
从“对吗”、“好吗”两方面进行评估优化
非功能目标的方法理论
非功能目标的设计是以场景技术为核心手段，以目标-场景-决策表为思维工具，致力于支撑非功能目标的理性设计过程
意义
设计更有针对性
可操作性更强
避免过度设计
便于系统升级时参考
场景技术
场景的5要素
影响来源
来自系统外部或系统内部的触发原因
如何影响
影响来源施加了什么影响
受影响对象
默认为本系统
问题或价值
受影响对象因此出现什么问题，或者需要体现什么价值
所处环境
此时，所处的环境或上下文如何
场景评估因素包括
价值大小
代价大小
开发难度高低
技术趋势
出现几率
不支持某场景也是架构师的一种重要决策
一线架构师实践的思维脑图
ADMEMS方法
三个阶段
实践要点：摒弃“需求列表”方式，建立二维需求官
思维工具：ADMEMS矩阵等
实践要点：重大需求塑造概念架构
思维工具：鲁棒图、目标-场景-决策表等
细化架构阶段
实践要点：贴近实践的5视图法
思维工具：包图、包-接口图、灰盒包图、序列图、目标-场景-决策表等。
划分子系统的4大原则
职责分离原则
通用专用分离原则
技能分离原则
工作量均衡原则
关注约束
关注约束，要趁早
架构成功的三个关键因素
功能需求
质量属性
名言
需求验证的目标是尽可能暴露问题，而不是证明无措。——徐峰，《软件需求最佳实践》
全面认识需求，是生产出高质量软件所必须的“第一项修炼”。 ——-温昱，《软件架构设计》
胜兵先胜而后求战，败兵先战而后求胜——《孙子兵法-形篇》
所谓鲁棒性分析是这样一种方法：通过分析用例规约中的事件流，识别出实现用例规定的功能的主要对象及其职责，形成以职责模型为主的初步设计。——温昱，《软件架构设计》
复杂性是根本问题，虽无法降低，但可以控制。——《人月神话》
有角度就有空间
书内核心名言
关键需求决定架构，其余需求验证架构
关键需求决定架构
功能需求做减法。在所有功能中挑选一个“关键功能子集”，作为“架构设计驱动力”的第一部分
质量属性需求做减法。根据系统所在领域的特点及系统规模等因素，确定架构设计重点支持哪些质量属性，作为“架构设计驱动力”的第二部分。
约束性需求做加法。充分考虑需求方及业务环境因素、用户群及使用环境因素、开发方及构建环境因素、业界当前技术环境因素等“4类约束”，将之作为“架构设计驱动力”第三部分，并以“做加法”的思维分析约束影响、识别约束背后的衍生需求。
问题是方法之父。不怕有问题，就怕发现不了问题。
协作决定接口
重用价值=重用次数*单次价值
软件架构设计就是要万恒从面相业务到面相技术的转换，在鸿沟上架起一座桥梁
将质量要求场景化
四拍型决策者
决策时拍脑袋——就这么定了
指挥时拍胸脯——保证没问题
失误时拍大腿——我怎么没想到
追查时拍屁股——老子不干了
说明
本文为《一线架构师指南》读书笔记
阅读原著请购买正版书籍
0 条评论
回复 删除
下一页
