1、DFX概念介绍
DFX是Design For XXX的缩写。在架构设计中，我们除了要对功能性质量属性进行设计外，还需要对非功能性质量属性进行设计。而且，对最终架构真正影响巨大与深远的是非功能质量属性。比如，可靠性设计（DFA，Design for Reliability）里对于满足在“有状态”或者“无状态”下的高可用性架构设计要求以及实现难度就完全不在一个数量级上。
ISO/IEC的非功能性质量属性定义：
H公司对非功能性质量属性的定义：
本文先暂时重点介绍可靠性方面的DFX知识介绍，关于其他部分DFX知识，欢迎同学们积极补充。
2、可靠性（Reliability）
广义的可靠性除了Reliability外，还包含可维护性（Maintainability）和可用性（Availability）
针对可靠性的几个关键度量指标：
- MTBF（Mean Time Between Failure，平均故障间隔时间）
- MTTR（Mean Time To Recover，平均故障修复时间）
- 可用度指标，一般表现形式是0.99999...或几个9
可靠性设计法则：
| 法则 | 解释 | 设计建议 |
|---|---|---|
| 墨菲法则 | 环境异常（比如硬盘故障、进程退出、通讯异常等）和人为误操作是一定会发生的，所以必须正视这类异常导致的故障存在 | 在设计开始时就要系统性的考虑故障的管理，包括预警、检测、隔离、恢复和修复等 |
| 二八法则 | 80%的问题出现在20%的软件元素（子系统/组件/模块等）或者业务流程中。 | 根据可靠性要求、出错概率和影响，对关键元素或流程做针对性设计。比如，电商领域，在交易、营销以及逆向流程中，容易产生资损。如何防资损的设计或者资损监控，都要做专项设计 |
| 剃刀法则 | 尽量保证系统的简单，提倡够用就行 | 复杂的设计更容易出错，更难以定位，所以提倡简单设计，避免过设计 |
| 桃源法则 | 与外部没有依赖关系的系统才能保持稳定 | 高内聚低耦合的设计不仅方便维护扩展，而且可以减少蝴蝶效应的影响，避免组件/模块的故障引起整个系统故障的严重后果。 近年来的微服务架构，也是这个思路。但微服务架构最需要解决的问题是职责单一化后大量的（成千上万）的微服务如何从整体进行管理。 |
| 门神法则 | 避免单点故障 | 在设计时需要对单点故障提供冗余保护，比如负载均衡接入点需要考虑1+1等。 |
| 日月法则 | 不要臆想多点故障会同时发生 | 在设计时不考虑主备链路同时故障等多故障的异常场景，但关联故障场景除外。 |
| 等级法则 | 优先保证高优先级别的业务 | 举例： 根据签约将客户分为金银铜级，优先保证金级别客户； 根据状态将会话进行打标签（QoS），根据标签做服务质量保证；（比如双十一，优先保证高价值客户的交互体验，识别机器刷单请求并进行限流） * 根据价值将服务分为计费和日志等，优先保证计费业务 |
在可靠性设计中，关于日常的运维保障机制，也是建设内容之一。比如，我们需要考虑并设计一套故障管理流程。故障管理流程一般由以下活动组成，运维保障体系要能对这些活动进行高效支撑：
- 故障预防：将故障消灭在萌芽状态
- 故障检测：系统化、多样化的检测，及时发现故障
- 故障分析：分析故障影响范围，做出决策
- 故障隔离：隔离资源，避免恶化
- 故障恢复：恢复业务
- 故障修复：修复资源
- 故障扩散：深度恢复业务
前面我们提到了故障也可能会由人为导致，人为产生故障虽然不能完全避免，但在设计上应该要考虑到这一点，并尽量预防。 以下这些准则，是能帮助我们的使用者尽可能的避免人为故障：
| 编号 | 准则 | 说明 |
|---|---|---|
| 1 | 采用一致、简明和明确的命名 | 合格的命名可以让用户减轻记忆负担，少出错 |
| 2 | 提供参数范围检测和修复建议 | 及时否定，免得用户浪费时间 |
| 3 | 支持危害操作和信息的突出显示 | 用字体、颜色、声音、消息（短信/邮件/微信）等提醒用户 |
| 4 | 给予删除类命令完全提示 | 只是采用“您是否要删除？”的提示是不够的 |
| 5 | 支持删除类命令的回退 | 回收站式软删除可以留下后悔的余地 |
| 6 | 支持耗时操作的进度提示 | 长时间没有响应容易让人烦躁不安 |
| 7 | 禁用易混淆命令 | 不要故意为用户制造犯低级错误的机会 |
| 8 | 两阶段完成重大影响类的配置 | 放慢节奏，让用户更理智地决定执行还是放弃。 比如，阿里的应用发布系统AONE，在应用变更过程中，有几个关键卡点（甚至要人为审批），及时在流式发布过程中，也有无人值守功能，对典型异常会立即暂停，让人工介入 |
| 9 | 事务完成相关性配置 | 既然不能分开做，那么就只能是集中做 |
| 10 | 模板和向导简化复杂配置 | 好的向导可以免去迷路的风险 |
| 11 | 提供配置依赖的冲突检测和修复建议 | 冲突可能会存在，一旦发生最好当下就解决。比如，业管平台的业务身份优先级配置、业务能力叠加配置、扩展点冲突优先级配置等。 |
| 12 | 允许配置试运行（或者灰度机制） | 试运行（灰度）可以提供发现和纠正错误的机会 |
发表回复