架构模式
架构攸关需求（ASR，Architecturally Significant Requirements）
定义
ASR指对体系结构产生深远影响的需求，影响了关键体系结构设计决策
需求越困难越重要，越可能影响体系结构，越可能成为ASR
如何识别ASR
-
需求文档中收集：可以使用“MoSCoW”样式或用户故事收集需求
-
通过采访利益相关者：可以使用质量属性工作坊QAW：
- QAW演示介绍
- 介绍业务任务
- 介绍架构计划
- 识别架构驱动程序
- 场景集思广益
- 合并方案
- 优先级排序
- 细化按方案
-
通过了解业务目标
-
通过质量属性实体树来管理ASR：逐渐对质量需求进行细化，直到含有量化指标为止
架构设计模式
程序设计模式 → 架构模式 → DSSA，层层递进，应用的领域知识越来越多
架构模式
架构模式是在实践中反复发现的一套设计决策，具有允许重复的已知属性。和DSSA很相似但是应用在更低层次上，并且作用域更小。
架构模式关联三种角色：
- 背景和上下文：发生问题的场景
- 问题：给定上下文中适当概括过的问题
- 解决方案：针对问题的成功解决经过适当抽象后的方案
领域特定的软件体系结构（DSSA，Domain-Specific Software Architecture）
DSSA是软件组件的组合，
- 专注于特定任务
- 领域内的高效使用
- 由标准化拓扑组成，高效构建应用
DSSA可以最大限度重用知识和进行先期开发，并因此开发新的体系结构设计
分层模式
模块模式
分层模式用来构造可以分解为子任务组的程序，每个子任务组都处于一个特定的抽象级别，每层为下一层提供更高层次服务。关键在于确定依赖，关注点分离，且必须逐层访问。
上下文：一般桌面应用、OSI网络模型等
优点：高内聚、松耦合、易于维护
缺点：降低系统性能，增加开发成本
解决方案
辨析
上图不是分层模式，既没有保证逐层访问，又形成了环形依赖，bad case
上图严格来说也不是，但是当D不依赖A、B时可以算是
代理模式 Broker Pattern
组件-连接器模式
代理模式可用于构建分布式系统， 分离组件间通过RMI交互，代理组件负责协同通信
上下文
多个同步或异步对象组成的系统
解决方案
提供通讯代理，隔离通信功能和主应用程序
模式图示例
优点
- 提高Client和Server交互性，
- 提高可扩展性，
- 整体性能提升
缺点
- 局部单点性能下降
- 前期复杂度高
- 通信代理存在安全性隐患
MVC模式
组件-连接器模式
MVC是分层架构的变种，更强调模块之间的约束和依赖关系。三个组件：
- model：业务逻辑、数据模型等
- view：用户展示、操作等
- controller：处理用户操作请求、信息通知model
解决方案
模式图示例
优点
- 耦合低，可重用性、可维护性较好
- 生命周期成本低
- 部署快，方便管理
缺点
- 缺乏明确定义，不适合中小型应用，因为会增加实现复杂度
- model和controller过于紧密，view对模型访问低效（基本无法访问）
管道和过滤模式
组件-连接器模式
管道和过滤模式应用于顺序处理结构中，有一系列过滤器filter
- filter：相当于组件Component，用来处理数据、计算，每个filter有input和多个output，数据向后传递
- pipe：相当于Connector，连接filter，将某个filter地output导给其他filter的input
缺点
不适合交互式系统，filter太多会导致计算开销太大
解决方案
模式图示例
上图中，每一个组件表示filter，连接组件的是pipe，任何一个filter都依赖前一个filter的输出（通过管道传递）。可以看出没有机会接受外界交互，不适合交互场景（会破坏现有依赖）
客户端-服务器模式
组件-连接器模式
客户端-服务器模式是一种分布式应用程序结构，在资源（服务器）和请求者（客户端）之间划分任务和负载，客户端和客户端一般通过计算机网络在单独的硬件上通信。
典型例子是电子邮件、web服务
两类Component：Client和Server，与代理模式相比少了Broker
上下文
比如客户端应用
缺点
服务器会成为性能瓶颈、可能单点失效等
解决方案
模式图示例
对比CS架构与Broker架构
代理模式也存在Client和Server之间的关系，但CS架构下互操作性降低，因为少了broker需要人为固定连接，并且CS不用broker可能导致请求被拦截
点对点模式 P2P
组件-连接器模式
点对点模式中的组件是对等的，可能上一刻是服务提供者，下一刻就是服务消费者。
解决方案
模式图示例
上下文
分布式应用程序体系结构，应用于对等体之间划分任务和工作负载
缺点
安全性不高（节点即是客户端又是服务端，被攻击的可能性提高），备份、修复更复杂，小型点对点系统不能持续实现质量目标
面向服务模式 SOA Pattern
SOA组件-连接器模式
面向服务的体系结构（SOA）是一种软件设计风格，其服务通过应用程序组件，通过网络上的通信协议提供给其他组件。服务是一个独立的功能单元。
面向服务模式是代理模式的延伸，Component包含很多，比如服务提供者、服务消费者、企业服务总线（ESB）、企业服务组件等
解决方案
模式图示例
优势/与其他架构的区别
- SOA具备代理模式的优点，但又没有代理
- SOA具备更高的互操作性和扩展性
缺点
构建复杂，且单独的服务可能成为性能瓶颈，中间件导致额外性能开销等。
连接器
- SOAP：简单对象访问协议，通过HTTP交换请求
- REST：代表性状态传输协议，四个基本状态（GET、POST、PUT、DELETE）的HTTP请求
- 异步消息传递
发布-订阅模式
组件-连接器模式
订阅者对发布者进行注册，某个发布者发布自己的消息被所有订阅者看到。这是一种消息模式
流程概述：发布者不把消息直接发送给特定接收者（否则会产生大量直接耦合），而是把消息发送给连接器（连接器也不知道有哪些订阅者）；同时，订阅者关注发布者且只接受感兴趣（即关注）的消息，这些订阅者会收到来自连接器的相应发布者的消息（而本身不知道总共都有哪些发布者）
一般采用事件驱动的方式来管理发布订阅模式。
解决方案
模式图示例
优点
松耦合、更好的可扩展性
缺点
增加消息传递的延迟，降低可预测性
共享数据模式
组件-连接器模式
安全数据会被很多人共享访问
CAP原则
一致性、可用性和分区容错性不可得兼
一致性实现
追求最终一致性
解决方案
模式图示例
缺点
- 共享数据模型可能存在性能瓶颈
- 单点失效
- 中心点被攻击的风险
- 对于安全数据，一般会强调一致性，如果要求任一时刻都一致（不是最终一致性）那么会有漏洞
映射-规约模式
分配模式
Map负责抽取所需信息，完成信息转换，多个Map可以处理各自任务，互相独立；Reduce负责合并，输出最终答案
示例：词频统计:：文本划分为多个partition，每个partition一个Map，每个Map统计完后由Reduce汇总并排序
解决方案
模式图示例
缺点
- 使用条件苛刻：
- 如果数据集不够大，那么开销不值得
- 如果分割大小不相似，并行会失去优势
- 多次合并难以编排
多层模式
分配模式
注意和分层模式区分
"Layer"是真实存在的，这个“层”指的是逻辑的组合，不是分层模式的强依赖关系，软件完成内容是一致的，但是在不同部署环境中分层不同。
许多系统的执行结构被组织成一组逻辑组件，每个分组称为一个层。
上下文
旅行社（tips: 上下文可以理解为具体场景）
缺点
前期成本过高，复杂性也高
解决方案
模式图示例
架构设计模式 v.s. 架构策略（重要）
- 策略比模式更简单
- 模式通常将多个设计决策组合成一个包
- 模式和策略共同组成了软件架构师的主要工具
- 策略是设计的构建基块，架构模式由其创建而成
- 大多数模式由若干策略构成，这些策略
- 服务于同一目标
- 用来保证不同质量属性
比如分层模式，既增加语义内聚，又限制依赖关系。
终于赤完了
微信支付