04-架构模式

解决特定问题的设计决定的集合，但是可以参数化配置。

• DSSA 领域特定软件架构

  1. 面向特定任务(task/domain)
  2. 在这个领域里是通用的
  3. 标准结构

• 架构模式

  1. 背景
  2. 问题
  3. 解决方案（Element + Relations + Constraints）

• 设计模式

  • 

• 架构模式分类

  1. Module
  2. Component-Connector
     1. 在Runtime动态建立联系
  3. Allocation

1. Layered Pattern

• Module类架构
• 解释
  1. 一个Layer里包含多个Module，不存在跨层的Module
  2. 限制层与层之间的依赖关系，质量属性的可修改性策略就使用了分层
  3. 各层之间不能跨层调用，只能上面调下面，关注点分离
• 影响的质量属性：可修改性、可模块化、可维护性、可复用性

1.1. Solution

• 元素：层，包含一些模块
• 关系：allowed-to-use
• 限制
  1. 每个模块只能被分配到一层
  2. 至少有两层
  3. allowed-to-use关系不能是环，低层不能调用高层
• 弱点
  1. 增加层很复杂
  2. 性能

1.2. Pattern

---

如果D是sidecar，那么也是分层；但如果D也有一定业务，则不是分层

2. Broker Pattern

• Component-Connector类模式

2.1. Solution

• 元素
  1. Client
  2. Server
  3. Broker：中介，帮助client找到server，传递请求
• 约束：一个客户端只能连接一个中介，服务端也是
• 分析
  1. 提升了互操作性、可修改性
  2. 现代场景下如果有多个broker实例，可以提高扩展性、安全性、可用性（补充设计）
  3. 可能单点失效，减低性能、安全性、可用性
  4. 减低可测试性，无法预先确定client和server的状态

2.2. Pattern

3. Model-View-Controller Pattern

• 类型
  1. 从动态看属于Component-Connector
  2. 从开发态看属于Module

3.1. Solution

• 元素
  1. model：业务逻辑
  2. view：向用户展示，接受用户操作
  3. controller：对用户操作进行处理，把消息通知给model
• 关系：通知
• 约束：
  1. 每个元素至少有一个实例
  2. model不能直接和controller交互，controller单向操作Model
• 弱点：对于简单的用户界面过于复杂

3.2. Pattern

4. Pipe-and-Filter Pattern

• 类别：Component-Connector

4.1. Solution

• 元素

  1. pipe
     • 相当于Connector
     • 必须有数据的输入和输出
     • 连接一系列的数据处理/计算
  2. filter
     • 相当于Component，通过pipe连起来
     • 处理数据，计算
     • 有input和多个output

• 限制

  1. 系统里不可能只有孤立的pipe

• 弱点

  1. 不适合交互式系统
  2. 有大量的独立过滤器会增加计算开销
  3. 不适合长时间运行的计算

4.2. Pattern

5. Client-Server Pattern

• 类型：CC

5.1. Solution

• 元素

  1. Client
  2. Server

• 不需要broker：在有限的网络中，有哪些服务是预先知道的,client和server的关系不需要动态改变

• 分析：

  • CS架构导致互操作性降低，没有broker需要，人为连接。
  • 可能被拦截

5.2. Pattern

6. Peer-to-Peer Pattern

• 类型：CC

没有明确的地位差距

节点可以自由加入退出

6.1. Solution

• 元素：
  1. peer即可以发送也可以接受数据
  2. request/reply connector
• 关系：peer之间的连接器
• 约束
  1. 每个节点的最大连接数
  2. 节点的hops(hops：限制可感知的范围)
  3. 哪个节点知道其他节点的信息，有一些p2p网络时星型拓扑
• 分析
  1. 提高了系统的可伸缩性
  2. 牺牲安全性：检点既是客户端又是服务端，被攻击可能增加
  3. 可用性：数据分布在不同节点上，可能导致数据不一致，但个别数据有问题不影响整体
  4. 性能：多个节点同时提供服务，新能好

6.2. Pattern

7. Service-Oriented/SOA Pattern

• 类型：cc
• 计算是使用一组通过网络提供消费服务的协作组件实现的。计算通常使用工作流语言进行描述。

7.1. Solution

• Component
  1. Service Provider
  2. Service Consumer
  3. Registry：注册服务
  4. ESB：企业服务总线，client到server的通信路由，类似broker
  5. Orchestration server：编排组织业务
• Connector:
  1. SOAP（简单对象访问协议）
  2. REST
  3. 异步消息传递（即忘即发）：参与者不必等待确认。
• 弱点
  1. SOA系统构建很复杂，无法控制独立服务的演变
  2. 中间件存在性能开销，服务可能还曾为性能瓶颈，通常不提供性能开销

可以访问到其他组织，不同技术实现的服务
质量属性：提高互操作性

7.2. Pattern

虚线：组织边界，内部可以完全由组织控制

8. Publish-Subscribe Pattern

• 类型：CC

8.1. Solution

• 元素
  1. 事件分发器：connector/component
  2. 发布者/订阅者：component，存在多对多的关系
• 弱点：
  1. 增加延迟
  2. 降低可扩展性
  3. 难以预测消息什么时候收到】
  4. 不能保证一定会接收到，或即时接收到

8.2. Pattern

在OS中事件处理普遍使用

9. Shared-Data Pattern

• 类型：CC

9.1. Solution

存在中心的被共享的数据

• 元素
  1. 共享数据存储Shared-data store.
  2. 数据访问组件Data accessor component.
  3. 数据读写连接器Data readin and writin connector.
• 限制：只能通过数据访问组件和数据交互
• 分析
  1. 星型结构，可能单点失效，性能瓶颈
  2. 想要获取数据高一致性、实时性时的妥协

9.2. Pattern

10. Map-Reduce Pattern

• 类型：Allocation
  通过并行提高了性能

10.1. Solution

• 元素
  1. Map：任务分割，一组相同的任务并行，每一个任务都在一个Map上处理 。信息抽取，转换。
  2. Reduce：把Map的输出整合在一起，变成单一输出
• 关系：
  1. Deploy on是 map 或 Reduce 函数实例与安装该函数的处理器之间的关系。
  2. 实例化、监视和控制是基础架构与 map 和 Reduce 实例之间的关系。
• 约束
  1. 要分析的数据必须以一组文件的形式存在
  2. map 函数是无状态的，彼此之间不通信
  3. map 实例和 Reduce 实例之间的唯一通信是从 map 实例以 <key, value>对形式发出的数据。
• 弱点
  1. 要求数据是大量的，否则map-reduce的代价不划算
  2. 如果不能把数据集划分成多个相似的子集，无法发挥并行的优势
  3. 需要多次reduce的操作协调起来很复杂。

10.2. Pattern

11. Multi-Tier Pattern

• 类型：Allocation

11.1. Solution

Tier：逻辑的分层，不是真实存在的层，没有分层模式的强依赖关系。软件的每一个计算资源作为一个Tier。
分层模式中的Layer时真实存在的

• 元素
  1. Tier
• 关系：
  • Is part of：把组件组织成层
  • Communicates with，层和组件之间通信
  • Allocated to：为了把层映射到计算平台
• 约束
  • 一个软件组件只能属于一个层
• 弱点
  • 前期成本高且复杂

11.2. Pattern

12. Pattern和Tactic

Pattern：一组设计决定
Tactic：最小单元