《一线架构师实践指南》
[一线架构师实践指南].温昱 http://download.csdn.net/download/exc_rsy/4932967
6个经典困惑:
1、将系统划分模块,如何更合理?
2、大系统架构设计,如何起步?
3、总觉得需求很糟糕,影响了架构设计。
4、非功能需求很重要,但如何设计?
5、架构亲手:缺乏指导,架构设计不知所措。
6、架构老手:缺乏总结,任怕下个项目。
架构设计方法首先应当是多阶段的,其次才是多视图的。
先做后做叫阶段,齐头并进叫视图。
阶段1:把握需求特点,确定架构驱动力 预备阶段(PA)
阶段2:根据重大需求,确定架构概念 概念阶段(CA)
阶段3:细化架构设计,关注不同视图 细化阶段(RA)
预备阶段:理解需求、建立需求大局观、确定架构设计方向
业务级需求: 业务目标 快、好、省
技术性约束
法规性约束
技术趋势
竞争因素与竞争对手
遗留系统集成
标准型约束
分批实施
用户级需求: 用户需求 运行期质量
用户群特点
用户水平
多国语言
开发级需求 行为需求 开发期质量
研发团队技术水平
研发团队分布情况
管理:保密要求
安装
研发团队磨合程度
研发团队业务知识
管理:产品规划
维护
高性能和灵活扩展存在矛盾关系, 性能和安全性与其他质量属性都是矛盾的
持续可用性:不停机,失效次数尽量少,而且“因失效造成的中断的持续时间”必须尽量短。
包括可靠性、安全性、可维护性、可管理性
性能、
可扩展性
安全性
可互操作性:与公司各系统间互操作
可维护性:易恢复性、易分析性、稳定性、易测试性
可移植性:适应性、易安装性、共存性、易替换性
可靠性 :系统在规定时间内无故障工作的概率(0-1),包括成熟型、鲁棒性、容错性、易恢复性
可重用性
鲁棒性:健壮性、容错性,各种异常情况服务依然能够正常运行
可测试性
易用性:易理解、易学、易操作、容错
效率:时间特性、资源特性
功能需求、质量属性及约束共同决定了架构。
ADMEMS矩阵四步法
需求结构化
分析约束影响
确定关键质量
确定关键功能
尽早开始架构设计
让架构师参加需求分析工作
不能被动的等待完善的《软件需求规格说明书》出现的那一刻。
架构设计依赖
明确的业务需求
全面的用户需求
典型的行为需求
关键需求决定架构,其余需求验证架构
功能需求做减法,找关键需求
质量属性需求做减法,确定重点支持哪些属性
约束性需求做加法,充分考虑需求及业务环境因素、用户群及使用环境、开发方及构建因素、业界当前技术环境因素
确定关键功能 (大概占总数的20%-30%)
核心功能:业务层接口要反映这些功能
必做功能:依据客户方的背景
高风险功能:基于务实考虑
独特功能:上述3类没有涉及的职责
概念设计
概念阶段:
基于关键功能,进行初步设计
综合初步设计,确定高层分割
考虑非功能需求,做出相应决策
持续可用性
数据库服务器(故障转移集群) + 磁盘
架构=组件+交互
概念架构为投标、售前、市场宣传等工作提供强力支持。
步骤:
初步设计:基于关键功能,借助鲁棒图进行以发现职责为目的。需求捕获、需求分析、系统分析.
高层分割:例如切分复杂系统为多个二级系统,或者直接切分系统为具体子系统。
考虑非功能需求:概念架构不等于理想化架构,采用ADMENS推荐 “目标-场景-决策”表。
鲁棒图
边界对象:负责接收外部输入,包括远程调用接口、设备、用户界面。
控制对象:对行为进行封装,描述用例中事件流的控制行为,包括应用逻辑、业务逻辑、数据访问逻辑。
实体对象:包括数据。
分层方法
Layer:逻辑层,重视职责的划分
Tier:物理层,“能分布”在在不同机器上的软单元。如JavaEE
按通用性分层:将通用性不同的部分划归不同的层。
技术堆叠:基于其他分层架构提供的进一步说明。
细化架构
细化阶段:
逻辑架构:职责划分(逻辑层、子系统、模块、关键类)、职责间协作(接口、协作关系)
数据架构:持久数据单元(文件、关系数据库、实时数据库)、数据存储格式(文件格式、数据库)
开发架构:程序单元(源文件、配置文件、程序库、框架、目标单元)、程序单元组织(project划分、project目录结构、编译依赖关系)
运行架构:控制流(进程/线程、终端服务程序)、控制流组织(系统启动与停机、控制流通信、加锁与同步)
物理架构:物理节点(PC/服务器、软件安装、部署、烧写、系统软件选型)、物理节点拓扑(连接方式、拓扑结构、物理层、冗余考虑)
划分子系统的4大原则:
职责分离原则:职责不同的单元划归不同子系统
通用专用分离原则:通用性不同的单元。。。
技能分离原则:需要不同开发技能的单元。。。
工作量均衡原则:兼顾工作量的相对均衡,进一步切分太大的子系统
运行架构
进程、线程
逻辑架构
接口的定义
子系统的划分
结构化方法的模块
逻辑层(Layer)
物理架构
服务器的选型
物理层(Tier)
开发架构
(并行开发需要)源程序目录
数据架构
数据分布与数据库Schema
(没选RDBNS)文件格式
(嵌入式系统)Flash存储结构
划分子系统的3中必用策略
分层的细化:展现层、控制层、业务接口层、业务实现层、业务实体层
分区的引入:分区是一种单元,类似项目(project)?开发应“深度优先”,而不是“广度优先”。
机制的提取:基于接口和抽象类的协作是机制,可以理解为划分接口?
借助序列图让切分的职责协作起来,验证能否完成功能。
数据分布的6中策略
独立:通信开销和可管理性冠军,不同子系统有自己独立的数据库,架构师应首选,减少系统之间无谓的相互影响
集中:可管理性和数据一致性冠军,指一个大系统必须支持来自不同地点的访问,或由多个相关的小系统组成,而持久集中化的数据进行集中化、统一格式的存储
分区:可伸缩性冠军
水平分区:为“地域分布广泛的用户”提供“相同的服务”时。相同的应用程序、不同的应用程序部署,相同的数据模型,不同的数据值。
垂直分区
复制:可靠性冠军,可能造成资源浪费
数据保存多个副本,并且以某种机制(实时或快照)保持多个数据副本之间的数据一致性。
子集:是复制的特殊方式,某节点因功能或非功能考虑而保存全体数据的一个相对固定的子集
重组:重新组织表,并同步需要的数据。
举例:
电子病历、详单:属于只读数据,可采用复制策略。
用户信息:有很强的修改特性,使用集中策略
电信BOSS系统:
服务受理系统和外线施工系统相互独立,采用独立策略。
服务受理系统内部采用集中策略。
外线施工系统采用水平分区策略。
目标-场景-决策