下载掌阅APP，畅读海量书库
立即打开
自如的技术架构经过10年发展，达到目前的架构状态，并非一蹴而就，而是跟随业务的增长不断迭代和演化的。在这个迭代过程中，我们总结了许多当时遇到的问题，相信与众多中小型互联网公司有不少相似之处。本节会通过一些数据来解析自如在云原生架构落地之前遇到的3个问题——稳定性问题、研发效率问题和流程体系问题。
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%。稳定性问题终于不再是系统故障的首要原因。
经济学上讲生产力有三要素——劳动对象、劳动者、劳动资料。对应在研发过程中，劳动对象是需求、项目、任务；劳动者是产品、研发、测试、前端、运维；劳动资料是原型、代码、环境、组件库、IDE（Integrated Development Environment，集成开发环境）、硬件资源等，如图2-7所示。
图2-7 研发效率图
在2019年之前，自如研发的全生命周期是没有完全数字化的，一个项目的开发周期、测试周期、上线周期、人员投入等数据是不完整的，90%的项目没有管理，开发人员根据倒排时间进行排期上线。项目的线上质量指标也基本是原始状态，研发效率低下。
研发效率低下，在很大程度上是劳动资料的问题，CI/CD是研发人员的必备工具。2019年，自如想重做CI/CD，对研发人员进行了一次摸底调研，发现研发人员对当前流程体系的满意度平均只有5.76分。
问卷中几个比较典型的用户反馈值得与大家分享。
·编译错误时无法自动发送编译错误提醒邮件。
·“合并”与“发布”的操作过于晦涩、比较难理解。
·发布时效锁定为2分钟有点固化。
·准生产环境经常不稳定，希望有所改善。
·希望可以进行多分支并行发布。
·上线操作烦琐、流程复杂。
·发布报错后无法查看相关的报错信息。
·发布时没有优雅关闭，会有流量损失和启动过程中的流量冲击。
·代码发布过程可视化程度不够，没有任何提示。
·功能很全，但是人工操作过多。
·脚本编写复杂，无法自动化打包、编译。
·浏览器兼容性不足，除了Win10自带浏览器外，使用其他浏览器会报错。
·自动创建发布环境时需要配置的项目过多。
·不同环境的配置可能不一致，导致出问题后的排查与定位非常困难。
·发布权限与审批流程控制不合理。
·非发布窗口发布时，无法收到审批信息。
类似的反馈还有代码发布历史的体验、发布审批流程的问题、版本信息管理、环境配置查看问题等。
同时，问卷也统计了研发人员对新平台的期待。
·建议增加代码检查功能，提升代码质量。
·建议精简审批流程。
·建议增加进度可视化、发布结果状态可检测功能。
·建议增加分组灰度发布功能。
·建议增加预发布环境进行上线前验证。
·建议增加测试环境服务器监控以及恢复机制。
·建议增加日志查询、进度查询、批量发布功能。
·希望是一个高度自动化的平台，人工介入越少越好。
·希望可以自己申请添加机器配置、查看负载情况。
·希望能够更智能、更灵活、更可视、更易用、更高效可靠。
·希望在发布上线前就做代码规范自动化检测，功能更简单易用。
·希望每个环境的项目信息、IP、项目域名能够完全正确匹配。
·希望发布配置更加智能化、简易化。
经过此次调研，我们下定了重建CI/CD流程体系的决心，通过重建体系解决发布部署的效率问题。