严选线下环境治理之路-回归环境篇-InfoQ

严选线下环境治理是一个长期而又复杂的工作，回归环境建设作为一个目前比较紧迫且可落地的任务，在逐步试错和探索过程中开展了几个月，目前得到了一些阶段性的进展和成果。从一开始的量化目标、梳理落地方案。到具体的规划集群、基建梳理、业务梳理、回归环境数据构造等步骤，困难重重也获益良多，并且我们在回归环境建设中，也做到了把核心链路上的已经上云的服务都能扩展到回归环境，其次也带动了部分之前没有上云的服务能进行改造并部署到回归环境。

一、背景

为什么要做线下环境治理：

目前严选线下环境建设有几个比较大的痛点，

第一、联调、测试、回归混用环境，效率低；

第二、环境不稳定导致依赖链路长的服务经常不可用，阻塞测试开展；

第三、现有环境历史操作过多，不标准，无法快速复制还原一套可用环境。

针对以上几个痛点，严选部门在 2020 年中开始规划在目前现有的联调、测试环境基础上再新增一套回归环境，可以保证严选核心服务有一套相对稳定的环境，用于上线前回归流程验证，不会被其他环境的频繁更新所影响。

为什么线下环境要上云：

目前严选线下环境两种部署方式，一种是基于虚拟机的服务部署方式，通俗的说法是云外环境，一种是基于容器的服务部署方式，通俗的说法是云内环境。

其中云内跟云外相比更加容易轻量、更加容易扩缩容和迁移。进行上云改造后，标准化的服务也更容易做到快速复制一套环境以及快速销毁。

但由于严选云内基建适配是从 19 年完整落地，目前云内部署的服务占比还不够，大家普遍对云内的收益还没有真真切切的感受的那么明显。更多的上云收益还是在于基建服务的开发者能感受到的一些基建开发建设的成本降低，例如中间件研发成本的降低、服务治理成本的降低等。总体来说严选团队基础建设对于上云的支持已经具备，因此一套新的回归环境的搭建期望业务方能够优先选择云内环境，而不是舍近求远的仍然使用之前云外的方式部署。

目前拿严选测试环境来举例，上云的服务已经有 360+之多，但对于严选所有的服务的一千多个的量级还是远远不够。回归环境在开展之初就奠定了优先云内环境的原则，首先希望把核心链路上的已经上云的服务都能扩展到回归环境，其次能希望带动之前没有上云的服务能进行改造并部署到回归环境。

二、如何开展回归环境建设：

严选一千多个服务，从哪里开始下手规划回归环境建设呢，回归环境建设又需要哪些准备动作呢。我们梳理了目前最容易被阻塞在回归测试的业务服务，以及梳理了回归环境建设的依赖关系，最终得到一个可量化的目标以及可落地的方案。

得到一个可量化目标：

最容易被阻塞在回归环境的、依赖链路相对较长的目前严选全站范围内是 B 端大供应链的服务（其中核心链路服务 75 个），这部分服务包含采购、计划、库存、品控、配送、包装、供应链管理等一系列服务。并且这部分服务依赖链路长，依赖度高。例如拿商品立项到上线流程举例，就涉及到商品、采购、品控、计划等十几个服务的协同运作。

如下图所示：商品立项全流程各节点及涉及到的服务所属业务

因此我们优先梳理了供应链的核心链路服务以及它所依赖的其他服务。总共梳理出来共 180 个左右的全站核心链路服务。也就是我们得到了量化目标：优先将 B 端及其依赖的核心链路服务建设独立、隔离的回归环境，并投入使用。

梳理可落地的方案

有了目标以后再看下落地问题，在方案建设之初，我们考虑了 2 种方案的选型，

一是建设一个独立且资源数据隔离的环境；

二是建设一个基于原有环境采用流量染色技术建设只包含部分频繁变更服务的动态可扩展集群。

第一个方案优点是数据隔离（不会造成原有环境的脏数据），环境相对稳定（不会由于共用的依赖服务不可用造成环境不可用），缺点是资源占用成本相对高一些（需要把所有依赖的服务、跟业务强相关的基建服务都在回归环境独立部署），资源占用和释放不灵活。

第二个方案依赖于成熟的流量染色技术以及识别服务以及依赖链路的回归场景需求，两方面，流量染色技术决定了混合部署环境能够满足同服务的多个集群的流量标识和数据标识分离，从而使得即使共用依赖服务和基建服务也不会带来回归流程和测试流程的使用冲突。另外如果没有准确的识别到哪些需要作为公共依赖服务，哪些可以作为动态可扩展集群范围内服务则很难去进行方案设计和建设。如果方案合理，它的优点则是资源节约，多环境使用更加灵活。

下图为一个应用了流量染色技术的线下环境模型：

经过分析和讨论，发现第二个方案虽然是大势所趋，但是目前严选的服务架构梳理还未达到可以完全改造成可准确划分哪些属于基础稳定环境服务，哪些数据频繁变更的灵活服务。另外流量染色技术虽然已经在轻舟系统中提供，但是其应用广泛度还不够，如何找到正确的使用姿势还有待探索。

最终我们选择了方案一：建设一套独立且资源数据隔离的环境。当然，回归环境建设不只是业务方的部署而已，还需要回归集群、基建的一系列支撑，因此我们梳理了几个步骤，包含回归集群预置、基建梳理及改造、业务梳理及部署、回归环境数据构造/迁移。

1. 回归集群预置

回归是由严选运维团队主导、杭研轻舟团队提供资源去完成的，包含规划层级关系、申请资源、初始化操作。由于考虑到少量较难进行上云改造的服务，在回归环境内新增了云内和云外的两个 LDC。（LDC 可以简单理解为一组应用、数据和网络的逻辑单元，包含多个集群，集群中包含多个服务实例）。

回归集群除了需要做到环境数据隔离以外，还需要有些特殊的网络打通和白名单配置，因为实际部署过程中可能会存在共用某个基础服务的测试环境，或者需要从线上或测试环境导入某个服务的基础数据，这样就需要回归集群在规划之初就需要考虑到网络打通的方案。

2. 基建梳理改造

严选基建建设分为两类：

一个是跟业务数据强相关的例如bpm工单系统、workflow工作流系统、权限中心、mps消息中心等，这些服务由于涉及到的业务数据需要数据隔离，因此需要独立部署回归环境；
另外一类是多环境共用的基建服务，例如Opera发布系统、网关管理平台、apolloY配置中心、Snet治理平台、消息发送服务、Dschedule调度中心、APM平台、日志平台、fms文件上传服务等。

需要独立部署的基建服务跟业务服务类似，申请资源、部署并且迁移或构造回归环境的数据即可。

共用的基建服务需要评估是否天然支持新增环境的配置，例如 Opera 发布需要增加回归环境的配置数据即可支持回归环境的服务发布动作。而 fms 文件上传服务则不需要增加配置，只需要确认网络连通性即可。

比较复杂的场景就是有少量基建服务前期设计时未考虑到多环境的支持，则需要通过改造进行适配。例如研发工作台需要前端的开发改造才能使得业务方在工作台能提交回归环境相关的运维工单。这些都需要提前识别到。当然如果不能提前识别到的，在部署回归环境过程中发现的一些遗漏待改造或待准备的配置也都一一记录并且逐步落地到位。

以上所有梳理出来的基建服务需要在业务服务部署之前就要部署或改造更新完毕，否则会影响后续业务服务部署的进度。

回归环境依赖到的部分基建服务一览图：

基建经过一系列改造部署、数据准备并确认可用之后，接下来就是真正的业务服务开始部署了。

3. 业务梳理部署

在量化目标分析中，我们已经初步梳理了共 180 个左右可以部署到回归环境的全站核心链路服务，涵盖的业务域有供应链、商品、库存、数据产品、数据中台、财务、技术平台、运维等数十个业务域。

在业务部署之前，核心要务是要先梳理业务之间的强依赖关系，并依据依赖梳理部署排期，并且关注排期与优先级较高需求之间的人力冲突风险。但一百多个的服务如果想梳理清楚所有逻辑的依赖时间周期会非常长，因此我们初步使用 Snet 进行核心关键链路的服务强依赖梳理，经过一轮的梳理，确认主站三个核心服务是部署的前提，供应链服务、库存服务、商品中心服务、财务服务作为核心关键链路的服务并行开展。数据服务、算法等被弱依赖或比较独立的服务依据自己项目进度排期在统一一致的 deadline 之前自由排期。主站其他服务以及 OMS、分销、客售等由于不被供应链核心链路依赖，而且与优先级高的需求时间冲突，暂时不作为第一批回归环境部署的范围。

4. 回归环境数据构造/迁移

服务部署完成后真正想使用起来还依赖于数据构造，例如配置数据的构造、业务数据的构造，其中配置数据在服务部署阶段就大部分已完成，业务数据一般来说有两种方式从无到有的生成。

一是基建服务中的独立部署服务需要跟线上或测试环境保持一致的服务，需要使用数据迁移数据同步的方式生成数据。这里方式是提工单由 DBA 进行数据的迁移。

二是业务服务需要进行数据隔离的业务数据，一般来说可以人工调接口去造数据或者使用造数平台或者自动化去完成造数。

有了以上的基础数据和业务数据，整个回归环境才能达到可用状态。

三、阶段成果展示：

部署服务情况展示：

各业务服务在大约一个多月的紧锣密鼓的部署之后，目前部署个数已基本达到全站核心链路服务的量化目标，如下图所示，各业务域的回归环境入驻情况，其中供应链业务域作为优先级最高的业务域已完成计划内服务 100%部署。

回归环境入驻进度一览：

其中部署到回归环境的服务云内环境达到占比为 90%以上。

可用服务情况说明：

目前核心链路涉及到采购、商品、品控、供应商、库存、财务、数据服务的业务域，QA 已初步完成验证。部分独立服务已达到可以上线前应用于发布分支回归使用。

四、未来和展望：

严选线下环境治理是一个长期而又复杂的工作，回归环境建设作为一个目前比较紧迫且可落地的任务，在逐步试错和探索过程中跌跌撞撞走了几个月，在过程中也踩了不少坑，比如，服务依赖梳理不完全导致的依赖服务漏部署、基建服务改造不完全、非核心链路的基建服务连通性或配置未完全等这样那样的问题，虽然过程比较艰辛，但是通过部署也收获了很多，比如业务之间的依赖关系逐步明晰、造数用例逐步完善等。在未来的建设中，严选环境治理的目标也会提出更高的要求。

近期比较紧迫的目标就是真正把回归环境在 B 端使用起来，能够真正解决环境混用、共用导致的测试阻塞问题。接下来的阶段性目标是能够在全站一千多个服务中梳理有回归环境需求的服务逐步开展落地。

除了回归环境建设，联调、测试、回归环境的职责划分、环境稳定保证、造数自动化等也要并行开展，最终目的就是让人人都能顺畅的使用线下环境进行开发联调、测试验证、测试回归、复现问题等日常工作而不受阻塞。从而进一步提高研发测试效能。

严选线下环境未来还需要再考虑泳道隔离，基础服务复用，流量染色等高级特性的应用，通过一键复制部署环境和一键销毁环境来将多环境应用的更灵活，资源更节省，真正的做到环境随心所用。