2.3.1　稳定性问题

2019年之前，自如某业务线的系统在30天内出现了13次线上故障，基本达到2天一次的故障频率，面对如此高频的线上问题，开发工程师疲于奔命，根本无暇迭代新功能，一线业务人员对系统也怨声载道。如何保证系统稳定性、功能可用是当时开发团队最为困扰的问题。

2018年年底，基础平台团队的成立是自如系统从“易变”走向“稳定”的转折点。基础平台重新盘点了线上故障类型，抓住核心短板，发现当时最迫切的问题是中间件的治理。

首先是版本问题，各中心使用的MQ、Elasticsearch、Redis版本都极其老旧。以Elasticsearch为例，当时最新版本已经到了6.x，生产集群使用的还是2.x版本，导致许多陈旧、低效的语法仍在使用，一些中间件新的特性没有用于生产。

其次是集群耦合太大，数个中心共用一个MQ、一个Redis实例，经常发生业务部门A的队列拥堵导致业务部门B的业务不可用，一个中间件瘫痪，整个公司的业务停转。经排查发现，这个情形与2.1.2小节介绍到的单体架构相似，原因是历史研发人员为了方便，直接复制中间件配置代码，导致业务应用虽然做了解耦和独立，中间件的依赖却没有分开。

最后是环境问题，代码分支、环境变量、开关配置经常出现测试环境与生产环境不一致等问题；人工参与过多，很多人为问题导致线上代码污染，进而引发故障。

经过2年的治理，因中间件、人为配置导致的故障率大大降低，我们重新盘点了一下2019年的故障情况，大体分布如图2-6所示。

图2-6　故障分布图

可以发现，占比最高的3个问题变成了代码错误、产品设计缺陷、数据原因，其中代码错误占比45%。稳定性问题终于不再是系统故障的首要原因。