架构

1.软件架构的定义
 A>程序或计算机系统的软件架构是该系统的一个（或多个）结构，它由软件元素，元素的外部可见性以及他们之间的关系组成。
 B>架构是一系列重要决策的组合
 C>从需求角度：架构是产品需求到产品组建需求的过程。

2.为什么要架构
 缺陷按阶段引入的比例：需求-56%； 设计-27%; 编码-10%； 其他-7%；<需求和设计引入近85%的缺陷，编码实现只引入10%的缺陷>
     --〉控制需求和设计是关键,控制需求就是有效需求分析，得到完整一致的需求规格说明书；控制设计就是软件的架构。
    
3.架构如何展现----〉架构视图
软件架构是一种无法以简单的一维方式进行说明的复杂实体。
多种架构视图必不可少是因为各类涉众（用户，客户，开发，测试，维护，内部操作人员，其他）需要从各自的角度理解和使用架构。
-------
逻辑视图：消费者：客户/用户/开发组织管理者；主要元素：系统，子系统，功能模块，子功能模块，借口；视角：系统的功能元素，以及它们借口，指责交互；用途：开发组织划分，成本/进度的评估。
开发视图：消费者：开发/测试；主要元素：描述系统的层，分区，包，框架，系统地通用服务，业务通用服务，类和接口，系统平台和相关基础架构；用途：知道开发设计和开发实现；
物理部署视图：消费者：系统集成商，系统运维人员；主要元素：物理节点以及各节点的通信；视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置。
进程视图：消费者：性能优化/开发设计人员；主要元素：系统进程/线程以及处理队列等；视角：系统运行时性能表现，线程/进程的情况；
场景视图：消费者：设计和开发人员；视角：概括了架构上最重要的场景（最典型或最有风险）以及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式。
数据视图：消费者：数据架构师，开发人员；主要元素：系统核心实体模式及相应的数据存储模型和存储方式，系统地数据存储策略，系统地核心数据流。
实现视图：消费者：开发/测试/实施；视角：系统交付物结构形式及相关实现规范；主要元素：创建可交付物的形式（网页，DLL，可执行文件，源码）以及组织结构，开发编程过程必须遵守的相关规范和指南。
*构架设计设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要确立每个构架视图的整体结构，试图的详细组织结构，元素的分组以及这些主要分组之间的接口。因此，与其他角色相比，架构设计师的见解重在广度，而不是深度*

4.软件架构驱动因素
<1>功能性需求---关注变化点和进化点。
<2>非功能性需求
  A.质量属性(满足非功能性需求往往比满足功能性需求更重要；架构指名了功能必须以何种品质交付，才能被系统的相关所接受，系统的结果包含这些人的既定利益。）
    系统质量属性：
      运行时的质量属性：性能，可扩张，安全性，易用性，持续可用性，互操作性，可靠性；
      开发时的质量属性：可重用性，可维护性，可测试性，可移植性；
    商业质量属性：政治因素（决策方），商业潜规则，上市时间，成本和收益，系统生命周期，目标市场，推出计划，与老系统集成；
  B.约束条件
    客户需求以及业务相关的约束：行业相关标准的约束，政策法规，遗留系统。
    用户以及使用环境的约束：用户特定及用户水平，早期产品使用习惯。
    开发组织以及开发环境的约束：开发组织的技术特点，开发组织的分布以及相关的资产。

问题：实际架构过程中，质量属性面临不可度量的问题。
如何解决：质量场景决策法，为了确保非功能性需求被满足，在架构设计中必须将希望达到的质量属性细化为具体的场景，并由此制定高层的架构设计决策。
E.G: 质量属性：可移植性； 场景：服务器运行到Windows/Linux/Unix平台； 决策：采用J2EE架构；
     质量属性：可移植性； 场景：客户浏览器使用IE/Chrome/Firefox； 决策：Ajax框架，结合JQuery等JS框架。

5.软件架构策略：刺激 ----- > 架构策略 ----- > 响应
软件架构师首先定义质量属性，然后采用设计模式，架构模式或者架构策略设计‘战术’，满足系统的响应。

1>可用性策略（错误 --- 〉控制可用性策略 --- 〉屏蔽修复错误）
99.999% --->每年停机5分钟。
可用性一般度量：平均故障间隔时间；平均修复时间；错误和缺陷率；

高可用性原则：
  A.remember everything fails, Assume every operation will fail and every resource will be unavailable.
    B.Automate Everything
    C.设计能够监控的应用
   D.避免单点故障
   E.避免系统串联
   F.没有回退的设计师失败的设计
 
最佳实践1：错误检测
  命令/相应；
  心跳；
  异常；
  监控系统的同时能监控应用程序；
  
最佳最佳实践2:错误隔离/恢复/降级或掩盖
  冗余计算：同等计算（表决；并行（热备份）；被动冗余（冷备份）；
  恢复：状态再同步；事务/会滚；
  降级操作；
  隔离（采用故障隔离的‘泳道’）；
  掩盖；
  
最佳实践3：错误预防
  系统健康检查/监控；进程/系统/健康监控检查；
  设计预防：避免单点故障；避免系统串联；确保能够启用/禁用功能；没有回退的设计师失败的设计； 

一个明智的程序员，如果不能让系统在紧急的情况下回退代码，就不应该发布代码。
回退的主要难点在于数据库：因该坚持以下原则：
 数据库修改只能是增量，只能增加数据库的列和表，不能删除。一旦实施这个标准，每个版本的数据库应该有部分代码专门标记或删除遗留的不再使用的数据。
 DDL和DML必须脚本化且测试过，每个数据库的版本修改必须通过脚本实现；
 对应用中的SQL查询进行约束，消除SQL语句中的歧义。
 数据的语义修改：比如票务表的某一列由三个状态，新版本就不能增加4个。
 Wire On/Wire Off:有关闭功能的特性。 
 
2>可维护性：最重要的质量属性。
Cost(Total) = Cost(Develop) + Cost(maintain);
Cost(maintain) >>>远远大于 Cost(Develop)
Cost(maintain) = Cost(understand) + Cost(change) + Cost(test) + Cost(Deploy)

架构师的关键任务 --- 〉系统通用服务架构与实现；
系统必备的服务：
 Caching Service
 Configuration Service
 MessageQueue Service
 EventNotifacation Service
 Authorization Service & Authentication Service
 Transaction Service
 Exception Service
 Cryptography(密码) service
 Workflow Service
 Time Service
 Logging and Instrumentation
 State Management
 Validation
 Communication
 ...
 
数据存取曾架构策略：
 数据存取对象的构建
 数据访问的Connection管理
 并发和锁的管理
 批处理和存储过程的应用
 数据格式的选择
 异常的管理
 查询的处理
 事务的管理
 ......

3>高性能（请求到达 --- 〉高性能架构策略 --- 〉在时间限制内完成请求） 
性能指标：
 相应时间：系统完成一册外部请求处理所需要的时间；
 吞吐率：给定的时间内能处理多大的请求量；
 响应抖动：随着请求的增加，等待时间的变化；
 丢失率：系统太忙无法相应，导致的为处理的信息的丢失；
 
原则：
 性能目标原则和探测原则:为性能定义具体的量化的可测量的目标。
 Partition Everything
 Asynchrony Everything
 
 麦当劳原则：尽量加工成品或半成品
 重要的事情优先原则：如果不能在可用的时间内完成所有请求，优先考虑最重要的
 最小消息原则：使处理与频率的乘积达到最小
 固定点原则，E.G:连接池
 本地化（缓存）原则
 批处理原则
 弹性时间原则：分散到高使用率的请求到不同的时段
 并行于分散负载原则
 ...
 
4>可扩展性（扩张 ---- 〉控制可扩展性策略 --- 〉顺利的增加）
原则：
 横向扩展（X轴扩展-通过克隆进行扩展）：适用情况：读写比例高（5：1或更高）；事务增长大于数据库增长的系统；可通过克隆服务并实施负载均衡来实现；X轴拆分能快速实现，但是只能提高事务的扩展性，不能提高数据的扩展性；
 拆分不同的东西(Y轴扩展-通过拆分不同的东西进行扩展)：通过服务或资源进行扩展，重点是扩展数据的集合，事务和程序员小组；适用情况：大数据集合，数据间关系不重要，大型的复杂系统，需要扩展编程资源；Y轴拆分，是面向数据/服务的拆分，能有效地扩展事务，有助于故障隔离；
 拆分相近的东西（Z轴扩展-通过拆分相似的东西进行扩展）：通常可以利用客户特有的属性进行拆分，比如客户ID/NAME/address;适用情况：非常大的相似数据集合；Z轴拆分有助于扩展客户群，还适应其他不能用Y轴拆分的大型数据集合；
 努力实现无状态：目的是设计和实现无状态系统；
 尽可能在浏览器维护会话：应用理由是避免服务器保存状态，以致服务器任何一台可以处理。
 利用分布式缓存存放状态：只用数据库实现成本最高，但所有数据都是持久化的，非持久化的分布式对象缓存比较快，成本低，但是出故障后不能恢复数据，另外对用户访问间隔时间较长的情况不适应，最好采用两者的混合反感，又数据库提供持久化，由缓存提供性价比的扩展性；
 合理使用数据库，结合内存和关系型数据库；
 放松时序约束；
 CAP（Consistency一致性；Availability可用性；Tolerance of network Partition分区容忍性）只能满足三者中的两者；
 尽可能使用异步通信，使用异步可以确保每个服务层是独立的，这样系统的可扩展性程度比所有部件都耦合在一起的系统大得多；
 确保消息总线能够扩展；
 DID，20-3-1.5(Design-Implement-Deploy),按照20倍的体量设计；按照3倍的体量实现；按照1.5倍的体量部署；
  .....
 
**架构是需要监控的，通过监控各项指标，在最适当的时候对架构进行最适当的重构，以满足变化的需求**

5>架构是避免：技术债务(利息）;破窗效应;

6>架构的定义（过程）
 管理非功能性需求
 架构定义
 架构技术选型
 架构评估
 架构协作
7>架构的发布（交付）
 拥有全局的视角
 领导力
 教练和指导
 质量保证
 设计/开发/测试
 
8>敏捷开发流程 VS 架构
敏捷需要一个脊梁来支撑，而软件架构提供了这个脊梁。
架构设计和敏捷需要共存。不是有你没我，而且相互合作。这里的关键点就是做"刚刚好"的设计。
        
 

转载于:https://my.oschina.net/ysk/blog/848142