《一线架构师实践指南》

《一线架构师实践指南》

[一线架构师实践指南].温昱 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系统：
        服务受理系统和外线施工系统相互独立，采用独立策略。
        服务受理系统内部采用集中策略。
        外线施工系统采用水平分区策略。

目标-场景-决策