架构师学习笔记9–架构设计

学习软件架构知识是为了站在较高层面上整体地解决好软件的设计、复用、质量和维护等方面的实际问题。

一、概述
（一）软件架构的重要性
1、项目关系人交流的平台

2、早期设计决策
1）明确对系统实现的约束条件
2）预测系统的质量
3）维护决策提供根据
4）有助于原型开发
5）估计成本与进度

3、在较高层面上实现软件复用

4、指导和规范开发

传统软件开发模式中，软件架构应位于概要设计之前，需求分析之后；
而基于架构的软件开发模型则将整个软件过程划分为架构需求、设计、文档化、评审（评估）、实现、演化等6部分。

(二)架构模型
软件架构可归纳为结构模型，框架模型，动态模型，过程模型，功能模型5种，但各有所长，将它们有机统一起来也许更合适，所以有人提出了“4+1”视图模型：

2、调用/返回风格
系统采用了调用与返回机制，实质是一种分而治之的策略，主要思想为将复杂的大系统分解为若干子系统，降低复杂度，增加可修改性。
包括
1）主程序/子程序
2）面向对象风格
对象通过函数和方法进行交互。
3）层次结构风格
上层调用下层。
CS、BS、MVC、MVP都属于层次结构。

4、虚拟机风格
人为构建一个运行环境，系统运行于其中，可以解析与运行自定义的语言，增加架构的灵活性。包括
1）解释器
2）以规则为中心

四、面向服务的架构（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好像还提供了工作流p>

听上去，ESB就是一种服务之间的粘合剂，万金油。但我实在想不出它是个什么鬼。

（三）微服务
微服务也属于SOA的一个概念。传统意义上的SOA，是跨系统的，不同的系统做成不同的服务，粗粒度；而微服务则是将一个程序再细分成若干个微服务，细粒度。

其优势是可以针对不同的功能，细分成不同的微服务，从而选用不同的技术和产品，比如用文档型数据库来存储帖子内容，用图数据来存储朋友圈，或者用于测试新技术，等等。其他像系统弹性、扩展、简化部署、组合等都有优势。

缺点主要是增加了复杂度，以及系统的不稳定性。这是一种综合衡量的结果。一方面，划分成不同的微服务，可能有利于清晰业务逻辑，降低了整个系统的耦合程度，变简单了；但本来一个系统，现在是几个小系统，系统多了，又算复杂了；本来单个系统，有一个地方 错，很可能整个系统都崩溃，但划分成微服务后，单个故障，其他还能用，增强了系统的可用性；但因为多个微服务之间通信，很可能是分布式的，反而带来更多的不确定性因素。

五、架构设计
架构风格就是架构模式。这些模式都有相应的套路，在高层抽象层次上具有普遍实用性和复用性。通过架构模式，架构设计师可以借鉴和复用他人的经验，看看类似的问题别人是如何解决的，但这只是一种解决问题的思路，并非硬性规定。

架构设计模型典型的有演变交付生命周期模型。该模型中，架构设计有少量关键需求就可以开始着手开始，把架构作为骨架，在骨架上循环迭代，逐步长出有血有肉的系统之躯。其中属性驱动设计法就是一种定义架构的方法。按照质量属性来划分模块。

模块分解完成后，就可以分配给各开发小组。此谓按架构组织开发团队。

六、软件架构文档化
记录软件架构即编写架构文档。一方面，编写过程促使架构师进一步思考，文档编写过程就是整理思路的过程；另一方面，文档是架构开发的成果，供项目关系人使用：
程序员希望从中获得限制和许可范围；测试和集成人员从中得到测试黑箱；项目经理则据此获得工作任务，组建开发小组，规划和分配资源。
UML是编写架构文档事实上的标准表示法。

七、软件架构评估
（一）评估方法
1、调查问卷
2、基于场景
通过分析软件架构对场景的支持程度，从而判断该架构对质量需求的满足程度。有

架构权衡分析法
软件架构分析法

3、基于度量

（二）架构的权衡分析法
从技术角度对软件架构进行评估，通过分析来预见软件的质量，创建、选择、评估与比较不同的架构。

（三）成本效益分析法
成本效益分析法是在架构权衡分析法基础上构建，用来对架构设计决策的成本和收益进行建模，是优化此类决策的一种手段。其思想就是架构策略影响系统的质量属性，反过来这些质量属性又会带来收益。

八、构件及其复用
构件是复用的基础。

九、产品线及系统演化
用架构技术构建产品线，并在此基础上借助复用技术持续演化，不断推出新产品，满足产品升级换代的需求。