2.2 自如的技术发展史
自如是提供租房产品和服务的O2O互联网品牌，成立于2011年10月，目前已为近50万业主、300万自如客提供服务，管理房源超过100万间。自如的主要客群是租房用户，由于租房这个动作并不像电商、社交一样高频，因此自如的互联网属性也很少有高并发、高流量的特征。
针对流量逐步从线下转到线上、业务线从1条到10条、访客从1万到20万的业务场景，我们应该选择什么样的架构呢？本节会为读者呈现一个典型的中型互联网公司的技术架构变迁过程。
2.2.1 业务背景介绍
自如是一家连接业主、房子、租客的C2B2C公司，业务逻辑如图2-4所示。
图2-4 业务逻辑
左侧的C是业主，作为市场的供给方，业主有房源，想要更快捷、更安全、更高收益地出租。业主的痛点是找不到合适的租客、拿不到高的租金，同时，业主也没有精力打理房屋托管租期内的事宜。右侧的C是租客，作为市场的需求方，广大租客的核心痛点是找不到合适的房源、享受不到优质的租房服务。
在以自如为首的品牌公寓出现之前，房屋租赁市场有3个错配。
首先是供需错配，因为信息差异，业主找不到放心的租客，租客找不到诚信的业主。其次是装修错配，业主房子的新旧程度、装修风格差异性极大，对于租客而言，房子品质的可选范围非常有限。最后是服务错配，租客租到房子后，基本上都是“自扫门前雪”，厕所、客厅、厨房等公共区域脏乱差、噪声大等问题非常突出。
自如先把业主的房源收集上来，然后进行精致的装修，为租客打造全新体验的租住和服务产品。同时，自如通过开发App、小程序、线下管家使这一匹配模式更加高效。
2.2.2 自如的技术演进过程
经过10年的发展，自如的业务规模和业务领域都大大增加。在业务规模巨增的背后，是自如业务系统的飞速演进。自如的技术发展大概经历了如下几个阶段。
2015年之前，自如以资产应用为主，管理房源信息、合同信息、客户信息，为了快速迭代业务，主语言以PHP为主，代码仓库以SVN来管理。到目前为止，老应用还存在部分未下线的功能，但是历史代码已经达到了1GB。
2015年到2018年是架构服务化的阶段，这时自如业务蓬勃发展，长租、短租、优品、家装、服务等多条业务线崛起，各个业务线开始构建独立的专属服务，此时Java开始逐步替代PHP，成为新业务线使用的语言。各个服务间开始通过RPC进行通信。这个阶段自如从单体架构迈向了分布式架构，度过爆发性增长的3年。
到了2018年7月，基础平台成立，自如开始对已有的持续交付流程进行重构，引入大量开源技术栈，如Spring Cloud、Nacos、Pinpoint、Graylog、Apollo等，使各个业务线通用的能力得到下沉，同时建设了第二机房，使自如的架构第一次具备了同城灾备的能力。
2019年，自如开始搭建DevOps体系，所有应用运维往SRE（Site Reliability Engineer，站点可靠性工程师）方向转型，开始学习编码，准备为Kubernetes落地储备人才。自如建设了大量的平台功能，如网关、监控报警、配置中心、消息队列平台、权限平台、用户中心等，使技术中台已具雏形。
2020年，伴随着容器、Kubernetes的广泛传播，自如对持续交付流程做了颠覆性重构，完全改变了之前的发布部署方式，对环境、分支模型都进行了重新定义，成为整个自如的技术演进过程中一个新的里程碑。
2.2.3 当前技术架构
经过了10年的技术演进，当前自如的技术架构如图2-5所示。
自如前台有多条业务线，如业主、租住、家装、客服等，每条业务线有独自的产研团队进行信息系统的构建，下方有三大中台进行支撑。
业务中台：主要整合各条业务的通用业务能力，如卡券中心、评价中心、价格中心、消息中心等至少能给2条业务线复用的能力才会抽象成中台能力。自如业务中台的建设还不是很成熟，真正可以复用的核心能力还在不断完善中。
图2-5 自如技术架构图
数据中台：数据中台基本上是最能有效赋能业务的通用能力域集合，核心的能力是自如的定价系统、用户档案、楼盘档案、业主档案、推荐系统，这些核心数据奠定了前台业务快速响应、多维度聚合数据的基础。
技术中台：相比于业务中台和数据中台，技术中台是自如目前能力域最多、最为成熟的中台。技术中台包括两部分：一部分侧重业务能力域，如用户登录、权限系统、敏感词系统、即时通信、推送服务、搜索服务；另一部分侧重基础架构，如配置中心、注册中心、监控报警、混沌工程、网关、熔断限流、业务开关、服务治理、流量染色。技术中台是自如业务研发使用最高频的能力，是工程效能最核心的部分。
2.3 自如技术架构遇到的问题
自如的技术架构经过10年发展，达到目前的架构状态，并非一蹴而就，而是跟随业务的增长不断迭代和演化的。在这个迭代过程中，我们总结了许多当时遇到的问题，相信与众多中小型互联网公司有不少相似之处。本节会通过一些数据来解析自如在云原生架构落地之前遇到的3个问题—稳定性问题、研发效率问题和流程体系问题。
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%。稳定性问题终于不再是系统故障的首要原因。
2.3.2 研发效率问题
经济学上讲生产力有三要素—劳动对象、劳动者、劳动资料。对应在研发过程中，劳动对象是需求、项目、任务；劳动者是产品、研发、测试、前端、运维；劳动资料是原型、代码、环境、组件库、IDE（Integrated Development Environment，集成开发环境）、硬件资源等，如图2-7所示。
图2-7 研发效率图
在2019年之前，自如研发的全生命周期是没有完全数字化的，一个项目的开发周期、测试周期、上线周期、人员投入等数据是不完整的，90%的项目没有管理，开发人员根据倒排时间进行排期上线。项目的线上质量指标也基本是原始状态，研发效率低下。
2.3.3 流程体系问题
研发效率低下，在很大程度上是劳动资料的问题，CI/CD是研发人员的必备工具。2019年，自如想重做CI/CD，对研发人员进行了一次摸底调研，发现研发人员对当前流程体系的满意度平均只有5.76分。
问卷中几个比较典型的用户反馈值得与大家分享。
1.对于“代码发布列表”你有哪些痛点？
□编译错误时无法自动发送编译错误提醒邮件。
□“合并”与“发布”的操作过于晦涩、比较难理解。
□发布时效锁定为2分钟有点固化。
□准生产环境经常不稳定，希望有所改善。
□希望可以进行多分支并行发布。
2.代码发布上线过程你遇到的问题有哪些？
□上线操作烦琐、流程复杂。
□发布报错后无法查看相关的报错信息。
□发布时没有优雅关闭，会有流量损失和启动过程中的流量冲击。
□代码发布过程可视化程度不够，没有任何提示。
□功能很全，但是人工操作过多。
3.在使用操作系统平台打包编译时你遇到过哪些问题？
□脚本编写复杂，无法自动化打包、编译。
□浏览器兼容性不足，除了Win10自带浏览器外，使用其他浏览器会报错。
□自动创建发布环境时需要配置的项目过多。
□不同环境的配置可能不一致，导致出问题后的排查与定位非常困难。
□发布权限与审批流程控制不合理。
□非发布窗口发布时，无法收到审批信息。
□类似的反馈还有代码发布历史的体验、发布审批流程的问题、版本信息管理、环境配置查看问题等。
同时，问卷也统计了研发人员对新平台的期待。
1.你觉得在项目上线流程中还需要添加哪些功能？
□建议增加代码检查功能，提升代码质量。
□建议精简审批流程。
□建议增加进度可视化、发布结果状态可检测功能。
□建议增加分组灰度发布功能。
□建议增加预发布环境进行上线前验证。
□建议增加测试环境服务器监控以及恢复机制。
□建议增加日志查询、进度查询、批量发布功能。
2.你对操作系统自动化平台的愿景是怎样的，希望它是一个怎样的自动化平台？
□希望是一个高度自动化的平台，人工介入越少越好。
□希望可以自己申请添加机器配置、查看负载情况。
□希望能够更智能、更灵活、更可视、更易用、更高效可靠。
□希望在发布上线前就做代码规范自动化检测，功能更简单易用。
□希望每个环境的项目信息、IP、项目域名能够完全正确匹配。
□希望发布配置更加智能化、简易化。
经过此次调研，我们下定了重建CI/CD流程体系的决心，通过重建体系解决发布部署的效率问题。
2.4 本章小结
本章介绍了技术架构的概念，对常见的技术架构定义及分类做了区分，梳理了自如技术架构的演变过程。技术架构是随着企业的发展阶段不断演变的，自如在启动云原生之路时遇到了稳定性、研发效率、流程体系问题，从第3章开始，将介绍自如是如何应对这些问题的。
以上内容摘自《云原生落地：企业级DevOps实践》一书，经出版方授权发布。
