1 环境建设背景

首先介绍下酷家乐的前后端架构，后端架构和大部分的互联网公司类似，分为前台、中台、基础设施，是一套微服务的架构体系，服务间依赖关系错综复杂，并且随着业务的发展服务粒度也逐渐细化，数量在增多，同时相对于线上环境，线下环境更加复杂，并且环境有多套，也加大了环境维护和治理的难度。

再来看下我们的工具前端架构，工具前端承载了大量的业务逻辑和算法，非常复杂，它有这么几部分组成

kaf框架，它包含了公共组件和通用操作
业务微应用，各业务微应用间的依赖错综复杂

整体表现是层级多、依赖呈现环状、且高度耦合，这个复杂的依赖也加大了我们对环境治理的难度。

业界对线下环境的认知：整个产品研发周期中一个重要的基石。线下环境在整个研发迭代周期中有着非常重要作用，一般的研发周期可以从需求分析开始中间经历各种环节，最终上线发布，从代码开发阶段开始，各种活动就已经和线下环境紧密相关联，它直接关系到我们整个迭代周期是否顺畅。

随着业务的发展，服务数量持续性增长，线下测试环境的数量剧增，环境日常维护的难度也在上升，同时我们对线下测试环境稳定性的要求也上升到新的高度。

2 线下环境标准化建设

在环境治理早期，容器化在酷家乐还没推开来，要构建一套环境非常复杂，各种配置、资源申请等等。同时存在链路依赖长且不稳定、没有统一的使用规范，大家都在一套环境上开发测试，导致并行问题，相互影响、相互阻塞。为什么会有这些问题？一个原因是受限于基础中间件和基础设施的能力，另一个原因是规范标准的不明确不统一。

我们线下环境的建设和治理是随着基础设施、中间件的演进而逐步进行的。当我们具备soa路由的能力后，对线下环境做了标准化的定义。首先，我们定义了一套基线环境，基线（stable）环境的version是default，当其他版本进行请求的时候，没有找到对应的版本，会默认路由到default上。功能和项目测试环境也叫fe环境，是基于基线构建各自的测试服务，其余都是基于基线环境，包括服务、数据库等。集成测试环境（sit），也是有一套全量的服务，数据库、中间件和基线（stable）环境共用一套。

定义了各环境后，我们对各环境的流转也做了规范。其中fe作为功能测试环境，sit是集成测试环境。当完成功能测试后代码会流转到sit环境，完成集成测试后再流转到beta环境，prod是生产环境，代码部署到prod后会会自动流转到stable，这样从流程上保证了stable环境的代码稳定性。数据库和中间件线上线下分为两套，好处是维护方便，没有数据同步的问题。

基于我们定义的环境流转标准化，在各环境阶段，配套定义了我们的研发活动，比如feature环境需要做什么事情、要达到什么程度才能进行流转，sit环境需要做哪些准备，bug如何修复流转等

在这一套环境标准、对应的流程、卡点落地后，基本上解决了并行测试、相互影响、相互阻塞、以及一些环境使用的规范性问题。

3 线下环境稳定性建设

线下环境标准化建设完成后，按照这套标准，已经能较好的支持日常的研发测试活动。随着业务的发展和架构的变化，渐渐的暴露出一些新问题，线下环境前面也提到过复杂度高，比线上环境更加复杂，我们没有一个人或团队去做日常运维，出了问题去定位、解决效率比较低，基线环境由于是自动化部署的，关注度比较低，经常性会有服务挂了或缺失的情况。随着这些问题的积累，终于在21年底爆发了，一会网站挂了全崩、一会是工具进不去，近3个月的时间，测试环境挂了近30次，其中最严重的是我们的注册中心（zk）间歇性抖动，导致批量服务的掉注册的情况，要恢复得全量重启对应的问题服务，开发测试疲于本命，已经严重影响了日常开发测试的进度，也是借着这个契机我们展开了新一轮的线下环境稳定性治理工作。

那么我们该如何进行治理呢？上万的pod稳定性如何保障？首先我们先对问题进行分析，环境的组成可以大体上分为这几类：服务、基础中间件、硬件设施。他们出问题后影响面是依次提升的。硬件设施问题：基于成本问题考虑，我们线下环境是在自建机房搭建的，且自建机房的硬件设施稳定性不高，遍地都是过保的机器，机器经常会挂。基础中间件：出了问题难恢复、基本不能自愈、且数据库数据缺少备份，有数据丢失风险。业务服务：影响面小，但出问题的频繁高，比如代码问题导致的业务不可用、针对业务服务的线下监控也非常混乱，基于成本考虑，线下环境pod配置较低，也导致了经常性的性能问题。

剖析完问题后，下一步就是进行治理，我们整体的治理思路是：从问题出发，不局限于问题本身，进行拓展和体系化的治理。线下环境特性就决定了：他肯定会出问题。那么我们要考虑的是如何降低出问题的频率，出了问题如何快速恢复，并且在做到这些的前提下如何形成一套长效机制。针对硬件设施、基础中间件、业务服务，我们分别从基础建设、事前预防、事发应急、日常运营这几个方面入手进行治理。比如事发应急，在出问题后，如何快速定位、快速恢复，解决问题三板斧重启、回滚、扩容？我们在这几方面做了一些能力的拓展。

3.1 基础建设

自愈和高可用：我们主要是利用了k8s提供的能力，我们把数据库也都统一迁移到了k8s上，实现数据库出问题也能分钟级恢复。启用Probe：Probe是用于检测和监控应用程序容器健康状态的一种机制，它可以通过定期执行预定义的检查来确定容器是否正常运行，并根据检查结果采取相应的操作。Kubernetes提供了三种类型的Probe：Readiness Probe（就绪探针）、Startup Probe（启动探针）、Liveness Probe（存活探针），应用了这三种probe后，服务存活能力大大提升。启用HPA：水平Pod自动伸缩器，通过检测应用cpu使用率判断是否进行动态扩缩容，这个很好的解决了因为服务性能问题导致的环境问题。关键节点防单点：核心服务和关键节点做到至少两个pod，防止单点的情况，这个点看着简单，但确实非常的有效。

在同步方面，prod环境部署后会自动部署到stable环境，同时对stable环境部署做了限制，除了prod环境流转的代码外，只允许部署release分支。除了代码同步部署，相对应的配置也会进行同步，确保基线（stable环境的稳定）。在备份方面，我们利用了Ceph的能力，Ceph是一个开源的分布式存储系统，将数据复制到多个节点上，并提供故障检测和自动恢复机制，确保数据的可靠性和持久性。

3.2 事前预防

前面也提到了，线下环境肯定会出问题，那么如何进行事前预防，尽快、尽早的去发现问题或者扼杀在萌芽之中呢？我们对业务核心链路做了梳理定义，并针对每个环境（这里指sit、stable）做了自动化巡检，第一时间发现问题并处理。除了自动化巡检，还建设了中间件存活检查、业务服务的存活检查。

我们把线下环境相关的变更接入了变更管控系统，在发生问题的时候协助快速定位。卡点建设方面：结合我们的分支管控的规范，后端服务部署sit只允许部署release分支的代码，从一定程度上保证了sit环境的稳定性；这里重点讲一下前端的部署，前端微应用在集成后，会有一些运行时的错误，这类错误在构建的时候发现不了，在各自的测试环境也可能发现不了，只有当代码都集成到一个环境的时候会发现，当出现运行时报错后，前端页面也就挂了，为了避免这类问题，在sit的default版本前面新增了一个prepare版本，要流转sit的default版本只能从prepare进行流转，这样就可以提前把问题暴露在prepare，我们在prepare上会进行一些核心功能的巡检，巡检挂了就会在prepare流转default的时候进行卡点，只有解决了问题并通过巡检才能进行流转。

3.3 事发应急

当出现问题时，时间是非常宝贵的，解决问题需要争分夺秒。但因为前端微应用间的高耦合，当出现前端问题时，单个微应用的回滚可能解决不了问题，且问题定位时间也比较久，基于这个原因，我们建设了前段批量回滚的能力，当前端出现问题时，可以一键批量回滚到指定的版本，做到分钟级恢复。

我们利用k8s的能力，实现不拉镜像的原地重启，可以选择性批量重启，分钟级就能重启完上千个pod。它可以很好的解决zk出现问题或抖动批量掉服务注册信息的问题，同时一些配置变更、数据库迁移需要批量重启时也能很好应对。解决问题首先要定位到问题，结合前面提到的变更管控我们可以快速知道是哪些变更引起的问题，但是还不能定位到具体的问题点，因此我们利用了应急大盘的能力，它对应的警报进行了分层，包括api层、应用层、主机层、基础中间件层，涵盖的范围非常广，通过这个大盘可以快速的知道当下我们的环境发生了什么，快速定位问题。