一线架构师实践指南
2021-06-25 13:06:05 9 举报AI智能生成
登录查看完整内容
《一线架构师实践指南》学习笔记
作者其他创作
大纲/内容
非功能性目标方法论
实际意义
设计更有针对性
设计贵在务实，贵在有针对性
可操作性强
思维明确化、可视化、操作操作化，利于架构新手学习、理解和掌握
避免过度设计
对非功能场景进行评估，权限场景发生几率、支持场景带来的价值、遗漏场景代价等因素，理性决定支持的场景
便于系统升级
将“目标-场景-决策”表文档化，有利于架构演进
方法论：“目标-场景-决策”表
需求的可验证性
问题
面对“高性能”这样“需求可验证性”很差的非功能需求无法有效展开设计
解决方式
通过场景化，增加非功能需求的可验证性
场景技术与“定量的需求”结合
场景的 5 要素与场景卡
影响来源
如何影响
受影响的对象
问题与价值
所处的环境
考虑场景评估因素
价值大小
代价大小
开发难度高低
技术趋势
出现几率
目标-场景-决策表
示例
细化架构阶段
A、进程、线程
B、接口的定义
C、子系统的划分
D、服务器的选型
E、结构化方法的模块
F、逻辑层
G、物理层
H、（并发开发需要）源程序目录
I、数据分布与数据库Schema
J、（没选RDMS）文件格式
K、（嵌入式系统）Flash存储结构
“细化架构”与“概念架构”的区别
接口
在细化架构中占核心地位，概念架构不关心；
子系统
细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口；
而概念架构中只有抽象的组件，这些组件没有接口；
交互机制
细化架构基于接口编程、消息机制或远程方法调用进行实在的交互；
而概念架构的交互是“概念化”的，如“A层使用B层服务”；
五视图与涵盖了架构师的各项具体的工作
运行构架（控制流组织）
逻辑架构(职责划分）
物理架构（物理节点安排）
开发架构（程序单元组织）
数据架构（持久化设计）
逻辑架构
划分子系统的 3 种必用策略
分层细化
分区
为了支持迭代开发，必须引入分区
针对每一层进行了分区设计，“深度优化”式的迭代开发就非常自然
机制提取
机制不权包含协作关系，同时也包含了协作流程
可以重用同一机制，避免重复进行繁琐的“组装”工作
划分子系统的 4 个重要原则
职责不同的单元划归不同子系统
通用性不同的单元划归不同子系统
需要不同开发技能的单元划归不同子系统
兼顾工作量的相对均衡，进一步切分太大的子系统
整体思维套路
质疑驱动的逻辑架构设计
结构设计与行为设计相分离
10 条经验要点
划分子系统：分层的细化
划分子系统：分区的引入
划分子系统：机制的提取
接口的定义：协作决定接口
选用序列图：杜绝f协作图
包-接口图：从结构到行为的桥
灰盒包图：描述关键子系统
循序渐进的螺旋思维
设计模式：包内结构
设计模式：包间协作
物理架构
3 项工作内容
硬件选择与物理拓扑
软件到硬件的映射关系
方案的优化
设计思维
思考维度
高性能
技术可用性
可伸缩性
经济性
易维护性
数据一致性
运行架构
工作内容
确定引入的控制流
确定每个控制流的任务
处理相关的问题：控件流的创建、销毁、通信机制
进一步思考：控制流之间的同步关系，资源争用引用加锁机制
引入控制流的思考维度
物理架构中的每个节点之上至少有一个控制流
为了实现节点之间的通信，通常的作法是引入一条控件流来负责
在需求一级的描述中就是并行或并发的，引入多条控制流
来自用户或外部系统的并发访问，常要求后端服务支持多控制流
如果控制流关系复杂，可以考虑引用对其它控制进行协调的控制流
实现控制流的 3 种常见手段
进程
线程
中断服务程序
开发架构
将“逻辑职责”映射为“程序单元”
要自主编写的源程序
可重用的库、框架
其它方式（如 Shell 脚本、平台支持下的配置文件）
开发技术选型
开发语言
开发工具
“程序单元”间关系
项目划分
项目结构
编译依赖关系
重用测试是关键
目的：从根本上降低维护成本
重用节省工作量升序排序
重用专家经验
重用标准的设计与算法
重用类库或程序
重用框架
重用完整的应用程序
数据架构
难点：数据分布
数据分布 6 种策略
独立Schema
优点
通信开销小
可管理性高
集中
可伸缩性强
复制
可靠性高
子集
是“复制”的特殊方式
重组
应用场景
统计性重组
结构性重组
二者差异
共同的优点
提升数据访问的性能
有针对性地进行优化
提高管理性
子集比复制的优势
减少数据传递的开销
降低数据冗余、节省存储成本
6 种策略的二维比较图
3 种应用原则
把握系统特点，确实分布策略（合适原则）
不同分布策略、可以综合运行（综合原则）
从“对吗”、“好吗”两方面进行评估优化（优化原则）
概念架构
概念架构是对系统设计的最初构想
抓住重大需求、特色需求、高风险需求，有针对性地确定设计策略
对系统进行适当分解，不陷入细节
确定最关键的设计要素和交互机制
步骤
初步设计
基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计
方法论
鲁棒图
定位
初步设计技术
3种元素
边界对象
负责接收外部的输入
处理内部内容的解释
表达或传递相应的结果
控制对象
对行为进行封装
描述用例中事件流的控制行为
实体对象
对信息进行描述
往往来自领域概念
作用
用助于确保用例文本的正确性
有助于确保用例考虑到了所有的必需的分支流程
有利于发现对象
10条经验
语法
遵循建模规则
简化建模语言
思维
遵循3种元素的发现思路
增量建模
实体对象 ≠ 持久化对象
技巧
只对关键功能（用例）画鲁棒图
每个鲁棒图有2~5个控制对象
注意
勿关注细节
勿过分关注UI，除非辅助或验证UI设计
鲁棒图 ≠ 用例规约的可视化
缩小分析与详细设计之间的鸿沟
高层分割
对系统这个黑盒子进行高层切分
实践套路
切系统为系统
把系统切成更小一级的系统
每个更小一级的系统可以有单独的需求、设计、实现
切系统为子系统
最常见的方式是分层
分层式概念架构实践
逻辑层
重视职责划分
物理层
“能分布”在不同机器上的软件单元
按通用分层
将通用性不同的部分划分归不同的层
通用程度越大，所处的层次就越靠下
技术堆叠
不是独立的架构模式
基于分层架构提供的进一步说明
考虑非功能需求
可重用性
持续可用性
安全性
一线架构师实践指南
ADMEMS方法体系
3 个阶段
预备架构（Pre-architecture）阶段（简称PA阶段）
最大误区：架构师是技术人员不必懂需求
实践要点：摒弃“需求列表”方式，建立二维需求观
思维工具：ADMEMS矩阵等
概念架构（Conceptual Architecture）阶段（简称CA阶段）
最大误区：概念架构 = 理想架构
实践要点：重大需求塑造概念架构
思维工具：鲁棒图、目标-场景-决策表等
细化架构（Refined Architecture）阶段（简称RA阶段）
最大误区：架构 = 模块 + 接口
实践要点：贴近实践的5视图法
思维工具：包图、包-接口图、灰盒包图、时序图、目标-场景-决策表等
1 个贯穿
对非功能目标的考虑。
Pre-architecture阶段：ADMEMS矩阵方法
Conceptual Architecture阶段：重大需求塑造做概念架构
Refined Architecture阶段:落地的5视图方法
持续关注非功能需求:“目标-场景-决策”表方法
如何解决“6大困惑”
划分子系统的4大原则
职责分离原则
通用专用分离原则
技能分离原则
工作量均衡原则
预备架构
四步法
意义
需求理解的大局观
关键需求决定架构，其余需求难架构
降低架构失败的风险
全面看待需求、避免遗漏重要的非功能需求
尽早开始架构设计
How
让架构师参与需求分析工作
不要被动地等待完善的《软件需求规格说明书》出现的那一刻
明确架构设计的“驱动力”
分析业务需求和约束背后的衍生需需求
发现遗漏需求
确定关键功能
确定关键质量
权衡质量属性之间的矛盾关系
不同需求影响架构的不同原理，才是架构设计思维的基础
需求结构化与分析约束影响
需求结构化
Why
更贴近一线架构设计的真实实践
全面理解需求的各个层次、各个方面
为分析需求之间关系、识别遗漏需求、发现延伸需求奠定基础
ADMEMS矩阵方法
分析约束影响
来自方方面面的约束性需求中潜藏着大量风险因素
识别架构影响因素，以便在架构设计中引用相应决策予以应对
4类约束的位置
约束来源
来自客户或出资方的约束性需求
来做用户的约束性需求
来自开发者和升级维护人员的约束性需求
也不能遗忘，业界当前技术环境本身也是约束性需求
理解
软件需求 = 功能需求 + 质量 + 约束
约束是架构设计要解决的问题的上下文
关键质量与关键功能
确定关键质量的5个原则
1、分类合适+必要扩展
现存的标准更大程度是对过去的总结，架构是面对的是现实存在的新问题
架构师应选择适合当前项目的分类方式 ，并在必要时做一定的扩充
2、考虑多方涉众
架构师应该全面考虑多方涉众的利益
用户不仅需要功能，也需要质量
客户不一定是最终的用户
在设计过程中，需要考虑开发人员
例如：最关心可扩展性的人不是用户，而是乙方的开发维护人员
3、检查性思维
确保每一项质量属性是否确实算不上“关键质量”
4、识别矛盾+划定优先级
质量属性关系矩阵
确定关键质量的优化先级，并在《架构文档》中明确记录此要求
5、严格程序符合领域与规模特点
质量严格程度受到系统所处领域及系统规模的影响
确定关键功能的4条规则
核心功能
必做功能
高风险功能
独特功能
0 条评论
回复 删除
下一页
