关于环境搭建:应用环境能力-阿里巴巴DevOps实践指南

编者按：本文源自阿里云云效团队出品的《阿里巴巴 DevOps 实际指南》，扫描上方二维码或返回：https://developer.aliyun.com/…，下载完整版电子书，理解阿里十年 DevOps 实践经验。

每个软件都无奈来到其依赖的运行环境。从代码的编写、调试、测试、上线、运维，每个步骤都离不开对应环境的反对。对于测试环境的争用、环境各阶段须要满足不同利用场景、软件品质的守护、老本与效率优化等诸多诉求，是环境治理和基于环境的变更交付流程规范化的原始需要。

软件行业对效率的要求是十分高的，如何能在现有条件下，进步开发测试的效率是一个很有意义的问题。而在这个问题中，环境，又是一个避不开的话题。如果每个开发都能在本人专属的环境里进行开发调试，不受内部人和物的因素烦扰，天然会比拟高效。然而，在微服务大行其道的明天，在同个软件模块多人多我的项目并行开发的状况下，为每个开发都调配一整套蕴含所有服务的环境，从硬件老本和保护老本上说，都不是一个理智的抉择，无效的对环境进行隔离和编排，能够在保障开发效率的同时，优化硬件老本和保护老本。

软件开发通常须要经验多阶段的重复测试验证，是从无到有，从简到丰，从不稳固到稳固的一个过程。正是因为这样的特点，不同阶段中对应的环境个性也会不一样，例如最开始的开发环境，用处就是集体测试；线下集成环境，用于线下的集成测试；预发环境，用于上线前的回归测试及验收；正式环境，用于真正给用户提供服务等等。

用流程将不同的环境串联，能将原来涣散凌乱的开发流程变得规范化，再加上适合的测试、验证及准入卡点等伎俩，实现满足准入条件（如质量标准等）能力交付下一阶段环境部署。通过零碎流程化的形式疏导开发者来实现平安、高效、可信的变更交付，防止交付过程无规则导致的凌乱及安全隐患，同时能够让整个研发流程做到可视化、可追溯、可度量。

总而言之，基于应用环境的变更交付，须要具备两大能力：

1. 单利用多开发者并行开发互不烦扰的测试环境隔离能力
2. 基于环境的变更交付过程规范化的流程治理能力

解决方案

在微服务架构的大背景下，服务的数量大大增加，使得本来大利用外部模块的复杂性转化为了多个小应用服务之间的调用复杂性。在理论业务场景下，一个整体业务通常会由多个小的应用服务组成，因而，在开发整体业务的过程中，通常波及到上下游一系列的微服务利用的批改，并且在多个不同业务的开发过程中，会导致同个微服务利用有不同的服务版本，大大增加了微服务之间的联调复杂性，给开发测试过程带来了除开发业务自身外的额定老本。

如何加重联调的零碎老本，让研发专一于本身的业务，是环境治理亟待解决的问题。为了更好的反对研发工作，通过将环境进行专职分类、编排隔离域、交付过程规范化，帮忙研发更高效的交付软件产品，阿里积淀出了一系列在测试环境治理方面的最佳实际。这些实际包含：

代码变更在环境上的递进机制

环境分为两大类：线上环境和线下环境。线上环境是那些操作和数据会真正影响到理论用户服务的环境，例如预发、beta、灰度、生产等。线下环境是次要提供给研发进行开发测试的，目前按应用形式次要分为我的项目环境、集成环境、根底环境三大类，本篇着重介绍线下环境，其中：

1. 我的项目环境：单个利用的单个开发中个性独占的环境，不受其余开发中个性的影响，也不会影响到其余环境的应用。用户能够在这个环境上进行任意的占用调试或破坏性测试。
2. 集成环境：一个利用的多个开发中个性共享的环境。这个环境次要用来验证多开发中个性在集成当前是否会在业务上产生新的问题或是引入新的抵触。
3. 根底环境：提供上述我的项目环境和集成环境的服务依赖，通过在生产环境部署后立刻部署根底环境，来保障根底环境提供的服务都是最新的生产环境运行版本，从而保障上述我的项目环境和集成环境可能稳固的进行开发测试。

流程上，从拉取个性分支开始，主动调配我的项目环境，在个性分支线下测试根本实现后，将我的项目环境转为集成环境，同其余个性分支一起测试，在集成环境测试通过后，部署至线上环境，最初在个性分支合并至骨干后，用最新的生产版本更新根底环境。

编排隔离域

随着业务的一直增长，以后的测试环境须要反对数万开发工程师的同时应用，对于某些外围业务，有数百个开发中的业务个性同时进行开发测试，而大部分的业务个性都波及到多个不同微服务的批改，如何保障多个并行业务之间能互相独立，不会相互影响？解决方案是隔离。将同个业务个性的多个不同微服务的环境圈定为一个隔离域，保障相干调用在隔离域内进行，这样就能断绝其余的业务个性提供的服务对这个业务个性开发测试的烦扰，在用户看起来，这个业务个性好像领有了一套残缺的环境。

然而，在微服务大行其道的明天，一个业务个性的运行通常依赖着许许多多其余的服务，如果每个隔离域内都将这些服务全副部署作为撑持，是一件老本十分高的事件。咱们的解决方案是共享。从路由维度登程，所有隔离域共享根底环境，而保留隔离域本身的我的项目和集成环境，来达到尽可能的复用公共服务的目标，大量缩小了资源老本和环境保护老本。

如图，我的项目环境 1 的用户和我的项目环境 2 用户别离拉起隔离域进行联调，相互之间流量隔离互不烦扰，隔离域不存在的服务都复用根底环境进行服务兜底，待个性开发分支通过集成、预发验证并公布生产环境后，会自动更新根底环境的基线版本，所以根底环境会持续保持跟生产环境雷同的稳固版本，以提供稳固的撑持服务。

根底环境建设

微服务架构场景下从端发动的一次调用，会波及到调用链路上多个利用提供的服务，但在理论的开发联调中，一条链路上只有少部分的利用须要变更，如果面向开发者须要拉起整个链路进行开发联调，那么会带来低效和老本的问题，所以其中非变更利用能够采纳根底环境作为服务撑持。如何保障根底环境的稳固可用就是隔离环境建设的重点。为了保障根底环境的可用性，次要做了三方面的工作：

1. 升高接入根底环境老本：创立环境通常是一个比拟让开发头疼的工作，通常波及到上下游一系列配置工作，例如批改公布流程、减少 Dockerfile、下发环境隔离文件、筹备测试域名、申请相应资源等，为了实现根底环境解决方案的落地，须要实现批量的根底环境搭建，过程中须要具备用户一键搭建根底环境及相应配套的能力，升高根底环境的接入老本。
2. 代码层面保障服务稳固：根底环境只部署最新的骨干代码版本，而且通过零碎流程保障每当线上部署实现，公布个性分支代码合入主干分支后，将基线版本主动部署到根底环境，用户无奈间接部署开发中的个性到根底环境上，从代码版本治理层面来保障根底环境服务的稳定性。
3. 可继续流量与自愈、监控保障：为了保障根底环境稳固服务的可持续性，根底环境须要稳固的全链路测试流量及监控，实时监测根底环境的可用性，在发现根底环境服务不可用时，首先通过无人值守的零碎伎俩自愈，如果还是不可用，通过自动工单机制告诉并跟踪根底环境的复原过程。

基于环境的交付流程

从拉取变更代码个性分支，到最终个性分支交付正式公布大抵分为几个阶段：创立变更个性分支、变更个性分支性能开发、分支性能调试及自动化验证、多分支集成验证、准入卡点、提交预发验证、正式公布上线（如下图所示）。

其中预发准入卡点是为了保障达到肯定品质要求的代码能力进入预发验收，把低质量的代码拦在测试环境继续验证，而主动部署环境则是为了加重准入卡点给开发者带来的累赘，通过自动化伎俩来对个性分支代码继续验证，收集并积淀品质数据，为准入卡点提供判断根据。

主动部署环境

当用户通过零碎创立个性分支时，会主动为用户的新创建分支申请一个我的项目环境，该我的项目环境的配置与根底环境雷同，并主动进行资源分配、部署操作。同时，这个我的项目环境的调用和音讯同其余环境互相隔离，它的服务并不会影响到其余环境的调用。

每当用户所创立的个性分支提交了新的代码，都会主动触发零碎去进行一次部署及自动化测试验证，通过继续的变更提交 + 反馈，缩短个性分支变更缺点的反馈周期，帮忙开发尽早修复代码缺点。

分支版本准入卡点

在研发交付的过程中，通过凋谢配置流程的能力，能够让业务方灵便的依据业务须要，配置所需的流程步骤，通过流水线步骤的主动推动，实现从测试到上线的整个交付过程。流水线是由一个个组件组成的，每个流水线都能够串联一到多个组件，在阿里巴巴的最佳实际中，在某些环境的部署组件后配置代码品质管控的组件，能够让环境在部署后，马上主动触发测试组件，来验证最新的部署版本是否合乎品质要求，从而倒推出最新变动的代码是否合乎品质要求。

应用中，为了保障线上环境的平安和稳固，在提交预发环境集成部署之前，会判断所要公布的分支的最新版本是否都通过了准入品质要求，没有达到品质要求的代码变更会被拦在测试环境持续修复验证以保障生产环境的平安。

环境与测试技术的联合

自动化测试始终作为无效的验证伎俩被宽泛应用，然而，在理论应用过程中，用户对于自动化测试用例的诟病并不少，例如：

1. 测试用例自身有问题，而不是被测试的代码有问题，导致破费了大量工夫排查后，在确定自身代码没有问题，能力反查测试用例的正确性，排查老本较高。
2. 破窗效应显著，一个开发的懈怠导致测试用例失败，其余开发人员并没有足够的能源将测试用例修复，同时因为别人的起因导致测试用例无奈通过，也就升高了本身对测试用例的要求，几次下来就会导致测试用例的状况越来越蹩脚。
3. 责任排查难，大多数测试用例只会通知你这次失败还是胜利，然而无奈关联比拟屡次测试用例之间的代码变动状况，当测试用例失败时，用户并不知道上次测试用例胜利到这次测试用例失败之间，变动的是哪些代码，带来昂扬的定位老本。

针对这样的状况，咱们须要从更高纬度的视角去关联代码版本与测试用例，次要分为两点：

1. 常态化代码骨干测试用例回归：在每天夜里零碎主动依据骨干代码创立应用环境并隔离、部署，而后跑对应的测试用例，因为是骨干代码，因而受到的代码烦扰较小，如果通过，示意该测试用例无效开释环境，如果不通过，则保留现场，并主动创立发送音讯到用例负责人。通过常态化的跑测试，能比照上一天的后果来疾速定位问题，并能保障“测试用例自身有问题”时能尽快失去解决。
2. 测试用例比照迅速定位代码：零碎将每次跑测试用例的各个分支代码版本、集成分支代码版本都保留下来并进行关联，当测试用例失败时，能间接定位到上次这些分支测试通过时候的代码版本，将提交记录间接展现给用户，帮忙用户定位测试用例失败的起因。

上述过程须要联合环境的一键拉起和流量隔离能力，通过这两点措施，能够让测试用例失败时做到后果可比照、起因可回溯，避免测试用例失败的破窗效应呈现。

总结

应用环境解决方案并不仅仅是将利用的开发环境、根底环境搭建起来即可，还波及到环境的稳定性如何保障，基于环境如何标准变更的流程，基于环境如何晋升开发效率等等。环境治理须要站在更高的角度，综合对待上述问题，否则就会陷入环境问题年年治理、年年被吐槽的怪圈。