24、架构决策与风险分析全解析

架构决策与风险分析全解析

1. 架构决策示例

在一个拍卖系统的案例中，存在着众多架构决策。例如采用事件驱动的微服务、将投标人与拍卖师的用户界面分离、使用实时传输协议（RTP）进行视频捕获、采用单一 API 层以及使用发布 - 订阅消息传递等。这些决策无论看似多么显而易见，都应该被记录并给出合理的解释。

以拍卖系统中投标捕获、投标流处理和投标跟踪服务之间使用发布 - 订阅（pub/sub）消息传递为例，这一架构决策的架构决策记录（ADR）可能具有特定的格式。

2. 架构风险分析

每个架构都伴随着风险，可能涉及可用性、可扩展性或数据完整性等方面。架构风险分析是架构设计中的关键活动，通过持续分析风险，架构师可以发现架构中的不足并采取纠正措施来降低风险。

2.1 风险矩阵

在评估架构风险时，首先要确定风险应归为低、中还是高等级。通常，这种分类存在过多主观性，导致难以明确架构中哪些部分真正属于高风险或中等风险。不过，架构师可以借助风险矩阵来减少主观性，并对架构特定区域的风险进行量化。

风险矩阵使用两个维度来评估风险：风险的总体影响和风险发生的可能性。每个维度都有低（1）、中（2）、高（3）三个等级。在矩阵的每个网格中，将这两个维度的等级数字相乘，得到一个代表该风险的客观数值。数值 1 和 2 被视为低风险（绿色），数值 3 和 4 被视为中等风险（黄色），数值 6 到 9 被视为高风险（红色）。

影响 \ 可能性	低（1）	中（2）	高（3）
低（1）	1（低风险）	2（低风险）	3（中等风险）
中（2）	2（低风险）	4（中等风险）	6（高风险）
高（3）	3（中等风险）	6（高风险）	9（高风险）

例如，对于应用程序中使用的主中央数据库的可用性问题。首先考虑影响维度，如果数据库出现故障或不可用，其总体影响可能被架构师判定为高风险，对应数值可能是 3（中等）、6（高）或 9（高）。但在考虑第二个维度（风险发生的可能性）时，由于数据库部署在高可用性的集群服务器上，其不可用的可能性较低。因此，高影响和低可能性的交叉结果是总体风险评级为 3（中等风险）。

在使用风险矩阵评估风险时，应先考虑影响维度，再考虑可能性维度。

2.2 风险评估

风险矩阵可用于构建风险评估报告。风险评估是对架构总体风险的总结报告，基于某种有意义的评估标准。

风险评估报告通常包含基于应用程序的服务或领域区域的评估标准的风险等级（通过风险矩阵确定）。一般用浅灰色（1 - 2）表示低风险，中灰色（3 - 4）表示中等风险，深灰色（6 - 9）表示高风险，通常也会用绿色（低）、黄色（中等）和红色（高）进行颜色编码，以方便区分。

下面是一个标准风险评估示例：
| 风险标准 \ 领域区域 | 客户注册 | 订单处理 | 数据存储 |
| — | — | — | — |
| 可用性 | 2 | 3 | 5 |
| 可扩展性 | 4 | 2 | 3 |
| 数据完整性 | 6 | 2 | 9 |

从这个示例中可以看出，数据完整性的累积风险最高，达到 17，而可用性的累积风险最低，仅为 10。同时，客户注册领域的风险最高，订单处理领域的风险最低。这些相对数值可以用于跟踪特定风险类别或领域区域的风险改善或恶化情况。

然而，风险评估报告通常不会直接呈现所有的风险分析结果，过滤是突出特定信息的关键。例如，架构师在会议中展示系统的高风险区域时，可以通过过滤只显示高风险部分，提高信息的清晰度。

另外，传统的风险评估报告只是某个时间点的快照，无法显示风险是在改善还是恶化，即没有体现风险的趋势。为了解决这个问题，可以使用加号（+）和减号（ - ）符号，或者带有目标风险等级数字的箭头来表示风险的趋势。例如，客户注册的性能风险为中等（4），但带有减号（红色），表示风险正在逐渐增加并趋向高风险；而目录结账的可扩展性风险为高（6），带有加号（绿色），表示风险正在改善。

3. 风险风暴

没有一个架构师可以独自确定系统的总体风险。一方面，单个架构师可能会遗漏或忽视某些风险区域；另一方面，很少有架构师对系统的每个部分都有全面的了解。风险风暴是一种协作式的活动，可以帮助解决这些问题。

风险风暴是一种用于确定特定维度内架构风险的协作练习。常见的风险维度包括未经验证的技术、性能、可扩展性、可用性（包括传递依赖）、数据丢失、单点故障和安全性等。虽然大多数风险风暴活动由多个架构师参与，但也建议邀请资深开发人员和技术负责人加入，他们不仅能从实现角度提供对架构风险的看法，还能加深对架构的理解。

风险风暴活动包括个人部分和协作部分：
- 个人部分 ：所有参与者独立（不进行协作）使用前面介绍的风险矩阵为架构的各个区域分配风险等级。这一步骤至关重要，可避免参与者相互影响或忽略某些风险区域。
- 协作部分 ：所有参与者共同协作，就风险区域达成共识，讨论风险并制定降低风险的解决方案。

在风险风暴活动中，会使用架构图。对于整体风险评估，通常使用全面的架构图；而对于应用程序特定区域的风险风暴，则使用上下文相关的架构图。架构师负责确保这些架构图是最新的，并可供所有参与者使用。

风险风暴过程可以用以下 mermaid 流程图表示：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([开始风险风暴]):::startend --> B(个人识别风险区域):::process
    B --> C(协作达成风险共识):::process
    C --> D(制定风险缓解方案):::process
    D --> E([结束风险风暴]):::startend

4. 风险风暴的具体活动

4.1 识别

识别活动是风险风暴的第一步，每个参与者独立识别架构中的风险区域。具体步骤如下：
1. 组织风险风暴的架构师在协作活动前 1 - 2 天向所有参与者发出邀请，邀请中包含架构图（或其获取位置）、本次风险风暴要分析的风险维度、协作活动的日期和地点。
2. 参与者使用风险矩阵对架构进行独立分析，并将风险分类为低（1 - 2）、中（3 - 4）或高（6 - 9）。
3. 参与者准备对应颜色（绿色、黄色、红色）的便签，并在上面写下风险矩阵中对应的风险数字。

大多数风险风暴活动只分析一个特定维度（如性能），但在人员可用性或时间安排等特殊情况下，可能会在一次活动中分析多个维度（如性能、可扩展性和数据丢失）。此时，参与者需要在便签上的风险数字旁边注明具体维度。

4.2 共识

共识活动是高度协作的，目标是让所有参与者就架构中的风险达成一致。在活动现场，最好有大幅打印的架构图张贴在墙上，若没有，也可以在大屏幕上展示电子版本。

参与者到达风险风暴会议后，将便签贴在架构图中他们各自发现风险的区域。如果使用电子版本，组织活动的架构师会询问每个参与者，并将风险电子标记在架构图的相应位置。

例如，在一个架构中，出现了以下风险识别情况：
- 两名参与者认为弹性负载均衡器为中等风险（3），一名参与者认为是高风险（6）。
- 一名参与者认为推送扩展服务器为高风险（9）。
- 三名参与者认为 MySQL 数据库为中等风险（3）。
- 一名参与者认为 Redis 缓存为高风险（9）。
- 三名参与者认为 MongoDB 日志记录为低风险（2）。
- 架构的其他区域未被认为存在风险。

对于参与者意见一致的风险区域（如 MySQL 数据库和 MongoDB 日志记录），无需进一步讨论。而对于存在意见分歧或只有单个参与者识别出的风险区域，则需要进行讨论。例如，对于弹性负载均衡器的风险评级差异，其他两名参与者会询问认为是高风险的参与者原因。经过讨论，如果该参与者接受其他两人的观点，风险等级可能会从高（6）降为中（3）。

对于未经验证或未知的技术，应始终分配最高风险评级（9），因为风险矩阵无法用于该维度的评估。这个过程会持续进行，直到所有参与者就识别出的风险区域达成共识。

4.3 缓解

当所有参与者就架构风险区域的评级达成一致后，就进入了最重要的风险缓解阶段。降低架构风险通常需要对架构的某些区域进行更改或增强，可能涉及对原架构的重大修改或简单的架构重构，如添加队列以缓解吞吐量瓶颈问题。

无论架构需要进行何种更改，这个阶段通常都会产生额外的成本。因此，关键利益相关者通常会决定成本是否超过风险。例如，在一次风险风暴活动中，中央数据库被确定为在系统整体可用性方面存在中等风险（4），参与者可能会同意对数据库进行集群化，以降低风险。

架构决策与风险分析全解析

5. 风险风暴案例分析

为了更清晰地理解风险风暴的过程，下面结合一个具体的架构案例进行详细分析。假设有一个架构，其中弹性负载均衡器（Elastic Load Balancer）位于每个包含 Web 服务器（Nginx）和应用服务的 EC2 实例前端。应用服务会调用 MySQL 数据库、Redis 缓存和用于日志记录的 MongoDB 数据库，同时也会与推送扩展服务器（Push Expansion Servers）进行交互，而推送扩展服务器又与 MySQL 数据库、Redis 缓存和 MongoDB 日志记录设施进行接口对接。

在风险风暴活动中，参与者的初始识别结果如下表所示：
| 架构组件 | 参与者 1 风险评级 | 参与者 2 风险评级 | 参与者 3 风险评级 |
| — | — | — | — |
| 弹性负载均衡器 | 3（中） | 3（中） | 6（高） |
| 推送扩展服务器 | - | - | 9（高） |
| MySQL 数据库 | 3（中） | 3（中） | 3（中） |
| Redis 缓存 | - | - | 9（高） |
| MongoDB 日志记录 | 2（低） | 2（低） | 2（低） |

在共识阶段，针对不同的风险识别情况进行了如下讨论：
- 弹性负载均衡器 ：认为是高风险的参与者表示，如果弹性负载均衡器出现故障，整个系统将无法访问，所以给予高风险评级。但其他两名参与者指出，该负载均衡器所在的服务器具有高可用性，出现故障的可能性较低。经过讨论，该参与者接受了其他两人的观点，将风险等级降为中等（3）。
- 推送扩展服务器 ：唯一识别出高风险的参与者分享了自己在高负载情况下该服务器频繁出现故障的经验，而其他参与者之前并未意识到这一问题。通过这次讨论，大家达成共识，将该服务器标记为高风险区域。
- Redis 缓存 ：识别出高风险的参与者表示自己对 Redis 缓存不了解，所以给予最高风险评级。对于这种未经验证或未知的技术，按照规则将其风险评级确定为 9（高）。

在经过共识阶段后，最终的风险评估结果如下表所示：
| 架构组件 | 最终风险评级 |
| — | — |
| 弹性负载均衡器 | 3（中） |
| 推送扩展服务器 | 9（高） |
| MySQL 数据库 | 3（中） |
| Redis 缓存 | 9（高） |
| MongoDB 日志记录 | 2（低） |

根据最终的风险评估结果，进入缓解阶段。对于被确定为高风险的推送扩展服务器和 Redis 缓存，需要制定相应的缓解策略。可能的措施包括对推送扩展服务器进行性能优化、增加资源；对 Redis 缓存进行深入的调研和测试，或者寻找替代技术方案。

6. 风险评估与管理的重要性

风险评估和管理在架构设计中具有至关重要的作用。通过风险矩阵和风险评估报告，可以对架构的风险进行量化和可视化，帮助架构师和利益相关者快速了解架构的风险状况。风险风暴活动则提供了一种协作式的方法，让多个参与者从不同的角度对架构风险进行识别和分析，避免了单个架构师可能出现的遗漏和片面性。

风险评估和管理的好处主要体现在以下几个方面：
- 提前发现问题 ：在架构设计阶段就对可能存在的风险进行识别和评估，能够提前发现潜在的问题，避免在系统上线后才发现风险，从而减少修复成本和对业务的影响。
- 优化资源分配 ：通过对不同风险区域的量化评估，可以确定哪些区域的风险较高，需要投入更多的资源进行改进；哪些区域的风险较低，可以适当减少资源投入，从而实现资源的优化分配。
- 促进团队协作 ：风险风暴活动鼓励架构师、开发人员和技术负责人等不同角色的人员参与，促进了团队成员之间的沟通和协作，加深了大家对架构的理解。
- 支持决策制定 ：量化的风险评估结果为关键利益相关者提供了决策依据，他们可以根据风险和成本的权衡，决定是否对架构进行更改或增强。

7. 总结与建议

架构决策和风险分析是架构设计过程中不可或缺的环节。在进行架构决策时，要确保每个决策都有明确的记录和合理的解释。在评估架构风险时，可以使用风险矩阵和风险评估报告进行量化分析，同时通过风险风暴活动进行协作式的风险识别和管理。

为了更好地进行架构风险分析和管理，提出以下建议：
- 定期进行风险评估 ：架构是一个动态的系统，随着业务的发展和技术的更新，风险状况也会发生变化。因此，建议定期进行风险评估，及时发现新出现的风险。
- 多维度分析风险 ：除了常见的风险维度，还可以根据系统的特点和业务需求，考虑其他可能的风险维度，进行全面的风险分析。
- 加强团队协作 ：风险风暴活动是一种有效的团队协作方式，要鼓励不同角色的人员积极参与，充分发挥各自的专业优势。
- 持续改进架构 ：根据风险评估和管理的结果，及时对架构进行调整和优化，不断降低系统的风险。

通过以上的方法和建议，可以提高架构的可靠性和稳定性，为业务的成功提供有力的支持。

下面是一个总结风险风暴流程的 mermaid 流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([开始架构项目]):::startend --> B(进行架构决策记录):::process
    B --> C(定期开展风险风暴):::process
    C --> D{风险是否可接受?}:::process
    D -->|是| E(继续项目运行):::process
    D -->|否| F(进行架构调整与优化):::process
    F --> C
    E --> G([项目结束]):::startend

这个流程图展示了从架构项目开始到结束的整个过程中，架构决策记录、风险风暴、风险评估和架构调整的循环过程，强调了持续进行风险分析和管理的重要性。