架构师学习笔记9--架构设计
学习软件架构知识是为了站在较高层面上整体地解决好软件的设计、复用、质量和维护等方面的实际问题。
一、概述
（一）软件架构的重要性
1、项目关系人交流的平台
2、早期设计决策
1）明确对系统实现的约束条件
2）预测系统的质量
3）维护决策提供根据
4）有助于原型开发
5）估计成本与进度
3、在较高层面上实现软件复用
4、指导和规范开发
传统软件开发模式中，软件架构应位于概要设计之前，需求分析之后；
而基于架构的软件开发模型则将整个软件过程划分为架构需求、设计、文档化、评审（评估）、实现、演化等6部分。
(二)架构模型
软件架构可归纳为结构模型，框架模型，动态模型，过程模型，功能模型5种，但各有所长，将它们有机统一起来也许更合适，所以有人提出了“4+1”视图模型：
二、架构需求与软件质量属性
软件属性包括功能属性和质量属性。软件架构重点关注质量属性。因为实现功能的方法多种多样，架构师要权衡利弊。软件架构在满足功能属性的前提下，寻找合适的套路来提升软件质量属性。
（一）软件质量属性
1、可用性
2、可修改性
3、性能
4、安全性
5、可测试性
6、易用性
各个质量属性之间互相制约或互相促进，需要衡量。
按项目阶段又可分为
开发期质量属性
运行期质量属性
1、可用性及其实现
故障处置。
1）错误检测
日志 心跳 异常捕捉
2）错误恢复
冗余，备件，回滚，事务，降级
3）错误预防
事务等
2、可修改性及其实现
1）将修改限制在局部
高内聚低耦合，降低对其他模块的依赖；提高模块的通用性；限制变更范围等；
2）防止连锁反应
对扩展开放， 对更改关闭。
3）推迟绑定时间
配置文件，多态，注册
3、性能及其实现
1）减少及控制资源使用
2）资源管理
引入并发，缓存，增加资源
3）资源仲裁
资源调度
4、安全性及其实现
1）防御攻击
2）检测攻击
3）恢复
5、可测试性及其实现
1）输入输出
记录，接口与实现分离，用实现替代用于测试
2）内部监控
6、易用性及其实现
1）运用时
记录用户习惯，收集用户反馈
2）设计时
用户接口独立
3）支持用户主动操作
三、软件风格
软件架构设计的一个核心问题是复用架构。基于此，带出软件架构的风格和类型问题。
软件架构风格为大粒度的软件重用提供了可能。
（一）软件架构风格分类
1、数据流风格
顺序执行。包括批处理序列和管道/过滤器。
2、调用/返回风格
系统采用了调用与返回机制，实质是一种分而治之的策略，主要思想为将复杂的大系统分解为若干子系统，降低复杂度，增加可修改性。
包括
1）主程序/子程序
2）面向对象风格
对象通过函数和方法进行交互。
3）层次结构风格
上层调用下层。
CS、BS、MVC、MVP都属于层次结构。
3、独立构件风格
强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。包括：
1）进程通信
通过消息传递来连接构件
2）事件子系统
基于事件的隐式调用风格。系统不直接调用构件，构件的过程注册到事件，当事件被触发，则注册于其中的所有构件都被执行。观察者模式。
我认为主要事件系统的优点在于调用和被调用没有直接关联，解耦。
4、虚拟机风格
人为构建一个运行环境，系统运行于其中，可以解析与运行自定义的语言，增加架构的灵活性。包括
1）解释器
2）以规则为中心
5、仓库风格
一个中央数据库，独立的构件围绕其上执行。
1）数据库
2）超文本系统
3）黑板。黑板相当于共享数据。知识源通过黑板交互。
四、面向服务的架构（SOA）
所有功能都定义成独立的服务，服务之间通过交互和协调完成业务的整体逻辑。所有服务通过服务总线或流程管理器来连接。松散耦合，各服务无需考虑对方的内部实现细节，以及部署在什么平台上。
(一)、SOA的关键技术
SOA关键技术有UDDI、WSDL、SOAP和REST，都以XML为基础发展而来。
1）UDDI 服务发布、查找及定位
2）WSDL 服务描述
3）SOAP 服务之间消息传输规范
4）REST
(二)、SOA的实现方法
SOA只是一种概念和思想，需要具体实现。
1、WebService
现实是往往是将WebService和SOA混为一谈。但WebService只是SOA的一个具体实现。或者也可以这么说，正是有了WebService，SOA才得以落地和推广。
2、企业服务总线（ESB）
一种为支撑SOA的统一通信环境。所有的服务都可以接入ESB来相互访问。服务利用ESB而不是直接互相访问，所以应该是中介者模式。
ESB具有服务功能，例如可负责在诸多服务之间转换业务逻辑和数据格式。如此说来，又是适配器模式。ESB还能在现有系统不更改代码的情况下，让现有系统具备全新的对外服务接口。ESB还提供安全机制。另外，ESB好像还提供了工作流？
听上去，ESB就是一种服务之间的粘合剂，万金油。但我实在想不出它是个什么鬼。
（三）微服务
微服务也属于SOA的一个概念。传统意义上的SOA，是跨系统的，不同的系统做成不同的服务，粗粒度；而微服务则是将一个程序再细分成若干个微服务，细粒度。
其优势是可以针对不同的功能，细分成不同的微服务，从而选用不同的技术和产品，比如用文档型数据库来存储帖子内容，用图数据来存储朋友圈，或者用于测试新技术，等等。其他像系统弹性、扩展、简化部署、组合等都有优势。
缺点主要是增加了复杂度，以及系统的不稳定性。这是一种综合衡量的结果。一方面，划分成不同的微服务，可能有利于清晰业务逻辑，降低了整个系统的耦合程度，变简单了；但本来一个系统，现在是几个小系统，系统多了，又算复杂了；本来单个系统，有一个地方报错，很可能整个系统都崩溃，但划分成微服务后，单个故障，其他还能用，增强了系统的可用性；但因为多个微服务之间通信，很可能是分布式的，反而带来更多的不确定性因素。
五、架构设计
架构风格就是架构模式。这些模式都有相应的套路，在高层抽象层次上具有普遍实用性和复用性。通过架构模式，架构设计师可以借鉴和复用他人的经验，看看类似的问题别人是如何解决的，但这只是一种解决问题的思路，并非硬性规定。
架构设计模型典型的有演变交付生命周期模型。该模型中，架构设计有少量关键需求就可以开始着手开始，把架构作为骨架，在骨架上循环迭代，逐步长出有血有肉的系统之躯。其中属性驱动设计法就是一种定义架构的方法。按照质量属性来划分模块。
模块分解完成后，就可以分配给各开发小组。此谓按架构组织开发团队。
六、软件架构文档化
记录软件架构即编写架构文档。一方面，编写过程促使架构师进一步思考，文档编写过程就是整理思路的过程；另一方面，文档是架构开发的成果，供项目关系人使用：
程序员希望从中获得限制和许可范围；测试和集成人员从中得到测试黑箱；项目经理则据此获得工作任务，组建开发小组，规划和分配资源。
UML是编写架构文档事实上的标准表示法。
七、软件架构评估
（一）评估方法
1、调查问卷
2、基于场景
通过分析软件架构对场景的支持程度，从而判断该架构对质量需求的满足程度。有
架构权衡分析法
软件架构分析法
3、基于度量
（二）架构的权衡分析法
从技术角度对软件架构进行评估，通过分析来预见软件的质量，创建、选择、评估与比较不同的架构。
（三）成本效益分析法
成本效益分析法是在架构权衡分析法基础上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。其思想就是架构策略影响系统的质量属性，反过来这些质量属性又会带来收益。
八、构件及其复用
构件是复用的基础。
九、产品线及系统演化
用架构技术构建产品线，并在此基础上借助复用技术持续演化，不断推出新产品，满足产品升级换代的需求。