风险驱动设计

风险指的是觉察到的失败概率*觉察到的影响。
风险驱动模型归纳为三个步骤：
1.识别风险，排定优先级
识别风险最简单的办法就是：从需求开始，找到那些难以实现的内容；不完整或者容易引起误解的质量属性需求。
优先级的排定可以使用风险矩阵。

image.png

2.选择并运用一组技术
3.评估风险降低的程度

计划式设计&演进式设计

Martin Flower估算的他自己会做20%的计划式设计和80%的演进式设计。
很多团队都已经采用敏捷的模式开展项目，所以我觉得对于这些项目来说最好的方案是在这两者之间找到一个平衡。在项目一开始要先做一些初始的计划式设计来确保架构可以处理一些最大的风险。在之后的过程中可以通过局部设计去处理未来的需求变化，如果项目上的重构、TDD和持续集成实践的比较好的话可以采用演进式设计。

当然真正实践过程中，还需要结合实际因地制宜。例如如果项目是对一组非常稳定的需求就适用计划式设计，但是如果项目需求变化迅速就比较适合演进式设计。

如果项目是XP（极限编程）模式

XP（极限编程）模式：是一种迭代过程与敏捷过程的专门化，包含了多次迭代。它不建议做预先设计的工作，但是大部分项目上为增加一个迭代0，这个迭代不会交付任何客户可见的功能，而是用来指导开发者完全采用演进式设计。不过有些项目在这基础之上做了调整，包含了少量的预先设计，降低一些识别出来的风险，例如建立开发环境，统一代码风格等等。这种模式中每个迭代的优先级排序是客户对功能的价值评估而不是风险。

风险驱动设计应用于敏捷过程

1.事先知道的架构风险可以在有时间限制的迭代0中去处理
2.迭代期间，有小的架构风险就要及时解决。
3.迭代期间，有大的架构风险则需要把它们提升至与feature同等重要的地位，加到backlog中考虑。

架构风格

下面会介绍很多架构风格，不同的架构风格有着不同的质量属性。
常见的质量属性有：
可用性：在一段时间中系统可以正常运行的概率。
可维护性：当有了系统修改需求以后，可以在对应的时间内修改完成。
容错性：系统中可能出现的故障会不会导致系统挂了。
可伸缩性：当用户规模增长时，系统会不会有问题。

分层架构风格

分层架构风格是由一堆层组成，每一层对上层来说都像个虚拟机。
简单的分层风格中一个层只能使用它相邻的下一层，这种约束就保证了更低层的内容是隐藏的。这样的约束会直接带来质量提升，保证了可修改性（modifiability）、可移植性(portability)和可重用性（reusability）

大泥球风格

实践中最常见到的风格就是大泥球风格。顾名思义，大泥球风格就是没有任何清楚的结构，例如随意共享的数据，随意全局化的数据结构。这样风格的系统可维护性（maintainability）和可扩展性（extensibility）都很差，最终导致整个系统难以改动，维护不下去。

管道-过滤器风格

管道-过滤器风格中，数据从管道流向过滤器，过滤器对数据进行处理，整个管道-过滤器网络持续地、增量式的处理数据。
管道-过滤器风格由四个元素组成：管道、过滤器、读端口、写端口。工作时，过滤器从一个或多个输入端口读取数据，进行处理（补充、细化或转化数据），然后写入一个或多个输入端口，不断重复以上过程直到结束。管道保证数据传输是单向的，永远从源头到槽（可以理解成数据要去的目的地）。过滤器之间是相互独立的，只能通过管道传输。
现在的前端框架或者组件中都有使用这种风格，例如angular中内置的Pipe系统、ramda、rxjs都有pipe的设计。

这种风格的质量属性有：

• 可修改性：根据已有的过滤器可以自由组合得到想要的结果
• 再配置型：可以使用已有的过滤器
• 被重用性：过滤器可以被重用
• 并行处理：因为每一个过滤器都工作在自己的线程和进程中，所以有机会使用并行处理。

批处理架构风格

批量顺序处理风格，数据流从一个阶段到下一个阶段，每个阶段都是相互独立的并且按顺序执行。
批处理架构风格在每个阶段都对数据进行完全的处理，然后交给下一个阶段，它不是增量式的。

这种风格的质量属性有：

• 可修改性：每个阶段之间相互独立。
• 不能并行

以模型为中心的风格（MVC）

以模型为中心的风格也叫仓库风格、共享数据风格，在这种风格中，独立的组件只与一个中心模型（数据存储或数据仓库）进行交互。每一个以模型为中心的系统都有一个模型（model）组件，一个或多个视图（view）、控制器（controller）、视图-控制器（view-controller）组件，视图和控制器都只依赖于模型，它们相互之间没有依赖。这种模型常见于后端Spring应用中。有些前端应用也使用了MVC的架构。

这种风格的质量属性有：

• 可修改性：因为视图和控制器组件都是独立的，信息的生产者和消费者被解耦，所以可修改性得到了提升。
• 可扩展性：视图和控制器可以很容易地添加。
• 并发：视图和控制器可以运行在它们自己的线程或进程中，所以可以并发。

分发-订阅风格

分发-订阅风格定义了两种端口：分发端口和订阅端口，和一个连接器（事件总线连接器）。分发端口用来分发事件，订阅端口用来订阅事件，事件总线连接器用来递交事件。
分发事件和订阅事件的组件是相互独立的，事件发布者不关心事件的消费（事件有没有被接收，有没有组件订阅这个事件），而事件订阅者也不关心是谁发布的事件。在前端代码中，为了解耦UI组件，也有使用分发-订阅风格，不同的组件监听不同的事件，当收到对应的事件后，做出对应的行为。

这种风格的质量属性有：

• 可维护性：这种风格进行了事件的生产者和消费者的解耦，使得可维护性和扩展性变高。
• 可扩展性

客户端-服务器风格

客户端-服务器风格包含了客户端和服务器组件、请求响应连接器和一些端口。只能客户端向服务器请求服务，即客户端向服务器发起通信，而服务器不能发起通信，它在与客户端建立通信之前不知道客户端身份。

多层架构风格：使用了两个或多个客户端-服务器风格实例，形成一个层的系列，每一层都定义了自己的职责，例如第一层处理用户交互、第二层处理业务逻辑、第三层处理数据持久化。

这种风格的质量属性有：

• 可维护性：当业务流程或规则发生更改的时候，只需要改变服务器上的实现，不用改变很多客户端上的实现，提高了系统的可维护性。
• 集成：客户端-服务器风格可以与现有的系统进行集成，例如：在现有的系统上创建一个外表面，把当前这个当成服务器。

对等风格

在对等架构风格中，节点之间的通信都是对等的，不能存在分层关系。每个节点既能做客户端也能做服务器。所以每个节点都可以请求服务也能向其他节点提供服务。对等风格常用于提供对资源的访问。例如BitTorrent网络中的文件。

对等风格是对不对称约束进行了特定的禁止，因为对等风格的质量在于减少不对称的发生。

这种风格的质量属性有：

• 可用性：一个节点离线了，还是可用的
• 弹性：单个节点的失败对于系统没有太大的损害。
• 可伸缩性
• 可扩展性

map-reduce 风格

单台计算机完成不了的任务，需要被拆到多台机器上运行，那么就适合用map-reduce 风格来处理巨大的数据集，例如搜索引擎、社交网络站点这种规模的系统。map-reduce 风格允许把计算分布到多台计算机上，当计算机数量不断增长时，部分机器宕机的可能性增加，使用这种风格可以让系统从这种失败中恢复。

这种风格的质量属性有：

• 可伸缩性
• 可用性：某一台机器挂的时候，可以把工作分配给别的机器运行。
• 性能高

学习&参考的书籍
《恰如其分的软件架构》