稳定为王的保障方法

架构师都希望自己的系统是稳定的，那么如何保障系统的稳定性呢？

一 合理拒绝

当架构师收到一个需求的时候，不应该马上去想如何实现，而是先对需求进行评审。

了解需求的真正目的，并且评审是否是合理需求——对产品是否有帮助，对系统的稳定性是否有影响，如果都是否定的，则要合理拒绝。

二 理清主次关系

在设计系统的时候，要理清主次关系。首先把系统主要逻辑画出来，然后添加依赖模块，针对主次关系设置不同的优先级，以及提供不同的解决方案。

我们需要从以下方面去思考。

1 了解系统的全貌

知道哪些功能是调用外部服务来实现的，哪些地方是互相依赖，把系统的架构图清晰、完整地画出来。

2 针对业务场景，梳理模块间的调用关系

3 利用 MECE 原则，相互独立、完全穷尽地把各种异常情况的全集划分出来，不要遗漏，也不要重复。

4 确定系统的边界，了解服务的最大能力。

5 评估影响

对于不能自愈、没有能力预防的点，要评估好影响——如果这些情况发生了，最坏的情况是什么，对系统会造成什么样的影响。

6 设计预案

针对上面的影响，有很多技术和非技术的工作要做，要提前做好预案。

7 验证想法，真实演习

故意把依赖的系统弄得不可用，验证是否会影响业务流程。

8 做好监控

在可能出现问题的地方都要做好监控和上报，所有因为逻辑原因不能执行但实际存在的地方，都要做好监控。

三 容量量化

1 评估量化

评估时要根据架构模型，测算出一个机器或一个 set 能处理的容量，根据容量评估做好管理。监控反映容量的参数，当超过警戒线的时候，能够及时扩容，或者提供降级服务。

一个出色的架构师，对于系统的容量，不是测出来的，而是计算出来的，架构师心中要有一张系统能力的表格。

影响系统性能的操作和性能指标如下表所示。

操作	性能指标
磁盘随机访问	3ms
SSD 随机读取	16us
在内存中顺序读取 1MB 数据	4us
从 SSD 硬盘顺序读取 1MB 数据	62us
从机械磁盘顺序读取 1MB 数据	1ms
一个网络包跨大洋传输耗时	150ms以上
一个网络包在同一个 IDC 内传输耗时	500us
...	...

随着硬件和系统的发展，要定期更新上面表格中的数据。

2 快速扩容

容量评估是实现快速扩容、自动扩容的基础，这样系统才能真正做到弹性可用，快速应对互联网访问量变化的情况。

实现紧急扩容最好的方式是系统能够自动扩容，当使用容量超过警戒范围时，系统直接扩充容量，不需要人为干预。

人工接入决策是否进行扩容操作也是一个好办法。设置一个开关，人工评估是否需要进行扩容，然后决定是否启动开关。

扩容时需要注意以下几点：

• 收归权限

• 让尽量少的人参与

• 平时做好准备

• 自动验证

• 自动执行

• 一切尽在控制

总之，架构师对系统能力有量化的评估，做到一切尽在控制。当系统的服务能力出现瓶颈，能够在预期的时间内完成系统扩容，从而应对突如其来的流量。

四 预先准备

针对可能出现的异常点，我们要先明确影响的范围，列出一个表，把可能出现的问题都列出来，然后针对问题，再列出出现这些问题后造成的影响。先对最坏的情况有一个预期，明确哪些影响是能够承受的，哪些影响是致命的、不可接受的。最后按照影响的重要程度，对可能的风险——设计应对预案。

有了提前做好的预案，才能在系统真正出现问题的时候不至于慌张；尽早明确最坏打算，也能够提前管理预期，做好资源投入管理工作。

五 注重监控

系统的监控数据和告警是架构师的“眼睛”和“耳朵”。完善的数据可以指导我们更好地运营系统，也可以帮助我们第一时间发现问题，还可以通过监控数据评估产品的特性效果。

了解监控数据是一个例行的事情，不是在系统涉及之初才需要关注。通过监控数据推断系统的运行状态，主动发现问题，这是根本要求。

我们需要经常观察监控和告警

1 告警要勤梳理

2 监控要设置得全面，尽量密集、完整

针对正确量、错误量、超时量、处理时延都有分级别的设置

3 告警要达到一定比例，防患于未然

要设定好监控的正常范围、程序执行到的分支，对超过正常执行次数的值设置告警。对于逻辑上程序不可能执行到的地方，也要设置告警。一般上报属性中至少 30 % 的属性需要设置告警。

4 定期查看告警视图

通过定期查看视图、梳理视图属性来优化告警频率。

5 熟悉运营数据，根据运营数据来指导开发工作

根据运营数据，了解用户关注哪些服务，主要使用哪些功能，对相应的功能进行重点建设。对于访问量逐步增大的系统进行扩容准备。对于性能消耗较大的模块，提前做好优化预案。

6 在架构设计之初，想好数据指标，做好数据建设

在未进行架构设计的时候，就要思考系统做好后要上报哪些数据、关注哪些数据。把如何获取这些数据也加入架构设计中。放在在系统开发工作结束后，发现不易获取想要关注的数据，对已写好的代码造成返工式的修改。

六 敬畏之心

对运营环境是否有敬畏之心，也是衡量一个架构师责任心的标准。

1 日常维护时，运营人员应减少登录服务器并在服务器上进行运维的操作，而应该在运营系统上进行操作

对线上环境要有敬畏之心，不要轻易修改线上环境。凡是不需要在线上环境中进行的操作，都不要在线上环境中试验。

2 对数据修改的操作，要做好评审、备份和回滚的准备

例如，临时修改线上数据库中的数据，如果没有相应的工具，就需要提前写好 SQL语句，并有人评审，在测试环境中测试。

3 敏感场景，要小心再小心，审核和评审都不能缺少

4 防止疏忽

在对线上环境进行修改，要谨慎。简单的变更可能产生重大的 bug。