微服务讲堂--【6】系统稳定性

稳定性，通常是以可靠性来衡量，即我们常说的几个9，这个主题在之前各个系列文章中已经提到过，本来没有打算单独写一篇。前几天一个老同事在群里发出一个灵魂之问，“如何解决生产环境更新系统后的稳定性问题”。因此，觉得有必要再专门就这个主题做一个论述，也考虑这个主题内容实在太多了，以列举核心内容和纲要为主。

在所有论述之前，必须深刻认识到两个核心原则：

1、任何系统都会出错。要将可靠性从99%提高到99.9%，虽然只提高0.9%可靠性，但故障率降低了10倍，研发成本需要慎重考虑，极大可能也是要增加10倍。

2、只要故障没有被觉察到，那相当于没有。这句话被这么实诚的说出来，估计会有一堆人疯狂DISS，但这是非常魔幻色彩的现实主义实践原则。

一个系统从项目启动到线上运营，都要经历四个阶段，1、设计阶段；2、开发测试阶段；3、发布阶段；4、运维阶段。而系统故障主要出现在运维阶段，而故障根源主要出现在其他三个阶段。因此，为了提高可靠性，需要在每个阶段都要仔细衡量。而更为极端的做法，是把一些设计方案固化成了语言特性，比如早期的erlang，近期的go和rust也有这些特性。

在设计阶段，主要考究的是系统架构，不单是微服务，集群还是分布，还包括组件、语言选型等宏观方面的设计。各种配套工具也需要考虑，对提高可靠性有很大的帮助。这也是一个很大的主题，可以单独成文，由于本篇主要介绍可操作性高的解决方案，所以就不详细介绍理论性较强的架构设计。通常来说，系统可靠性的上限在设计阶段就已经被决定了。

以多年实践经验来看，一个比较成熟的团队，在开发测试阶段就能实现99%的可靠性。大部分公司将开发力量主要集中在业务模块，而工具开发往往忽略，因为没有产生直接的经济利益，所以多直接选用开源工具。开源工具主要着眼于公共领域，解决通用问题，并不能解决自身业务特定领域的问题。

在开发测试阶段要提高系统可靠性，核心就四个字：少写多测。少写就是少写业务代码，少写少犯错，也就是老生常谈的代码复用，公共代码下沉为业务库或者公共服务。这几年很火的中台，也是为了减少业务代码。业务代码通常占系统代码80%以上，而且变化快，需求多样，所以测试资源平均下来就相对变少。虽然单个系统代码比较多，但由于是通用组件，场景单一，被动测试反而更加充分，出现故障概率低。配置管理和自动化构建这两个比较纯粹，网络上资料足以覆盖，无需赘述。多测的核心不是指投入测试资源，在大多数公司里，测试人员比开发人员要少很多。关键是测试案例能够随着时间，而不断累积。自动化测试在这里是一个很重要的解决方案，如果没有健全的自动化测试方案，全回归基本上是奢望。微服务在自动化测试方面有天然的优势，我曾经介绍过《风洞系统》的构想，专门做自动化测试通用解决方案。

自动化部署只解决手工发布可能引发的故障，任何一次发布新系统，会在开发测试阶段引入新的故障点，然后在运维阶段触发这些故障，而不发布也是不可能的。在发布阶段提高系统稳定性的核心是：并行运行，早发现早隔离。他的方法论很多，蓝绿部署，灰度发布，滚动部署等等。K8S是集成环境，不单是解决调度迁移问题，也顺便解决了部署问题。据说，阿里内部有一套系统，借鉴了git原理，可以做增量部署，减少网络传输。这些都是好主意，但现在首先要讨论一般性原理，特别对于金融系统，尤其是交易系统。

除了常见开发、测试、生产环境外，对于可靠性要求高的，还要加入stage环境，我称之为仿真环境。其他环境不需要说太多，基本都会用到，但仿真环境的重要性也经常被忽略的。接过交易所数据的人都知道，在上线之前，一定要先接入到仿真环境，测试到稳定。仿真环境可以加入外面接口模拟器，比如模拟交易所，执行一些会改变数据的危险指令，既可以完成测试功能，又不会造成实际影响。

撇去各种名词概念，发布阶段的操作原则是先多批次少量发布，防止一下子发布太多，无法准确定位故障，即所谓的滚动部署；其实，用户也同样是分批次，即所谓的金丝雀部署。在交易系统中，由于涉及金额巨大，是不存在金丝雀的，所以仿真环境尤为重要。

最后一个运维阶段，除了类似K8S的自动调度迁移之外，最关键的手段是重启，估计说到这里，很多人都要会心一笑，也会有人不以为然，甚至颇为鄙视，但我要强调的是，这是在面对无法快速解决问题的最后保命手段，一定要好好地认真对待。有了这个保命手段，才有可能再考虑其他措施。通常运维都会部署一套监控系统，不论开源或者商业的监控系统，在公共领域，比如网络，内存之类做得比较成熟，但在私有领域，比如具体的业务，一般都不会涉及，这就需要团队自己开发了。这类业务监控的技术难度不高，但开发人员既需要了解业务规则，又需要了解程序的特点，这样就有点难度。多数团队都是在事故之后，补上这样的业务规则。

除了运维监控外，我更多的要强调系统预警。在这里怎么强调都不为过，因为基本上很少有团队能够做到预警，更多的是完全没有意识到预警的重要性。预警更多强调是趋势判断，为解决问题争取更多的时间。比如用户的增长趋势，可能会某个节点直接影响到网络带宽需求。而现有的监控多数基于阈值，而阈值的设定受经验值外，还容易频繁触发，导致监控人员注意力疲劳。在运维阶段，还有全链路追踪、监控、分析等手段，比如阿里的“鹰眼”。

运维是确保系统稳定性的最后一道防线，有很多内容可以探讨。当故障真实发生时，其实没有太多时间去思考，越简单的手段反而越有效。所以，要做事情，都要在上线之前做好，包括系统设计，运维工具，也包括流程管理，故障演练等。