简介：为什么测试环境的不稳固是必然的，怎么让它尽量稳固一点？为什么测试环境比生产环境更简单，怎么让它尽量简略一点？本文将就这两点进行分享。同时，还会谈一谈对测试环境和生产环境的区别的了解。
作者 | 史培培 (安辰) 起源 | 阿里开发者公众号这篇文章想要讲的，确实是两件事件：为什么测试环境的不稳固是必然的，怎么让它尽量稳固一点？为什么测试环境比生产环境更简单，怎么让它尽量简略一点？此外，还会谈一谈对测试环境和生产环境的区别的了解。这里是本文的次要观点：测试环境与生产环境是两个不同的场景，测试环境的不稳固是必然的，在没有实现 TiP（Test in Production）之前，以后咱们能做的是尽量让它稳固一点；测试环境比生产环境更为简单，最外围的是要解决共振问题，即做好隔离能力，Mesh 是解决隔离问题的一个将来方向；在 DevOps 畛域，测试环境其实是介于 Dev 和 Ops 两头重叠的局部，一提到测试环境，关上就会说测试环境不够用、测试环境不稳固，尤其是在微服务化了之后，对测试环境的诉求与挑战也愈发显著。
从软件研发过程的角度来说（如上图），从左往右出现一个漏斗模型，随着研发的阶段推动，复杂度和稳定性都在逐渐收敛：在开发和集成阶段，代码等变更是十分频繁的，在这个阶段里研发人员在一直的迭代、联调、验证等，从实质上来说，高复杂度和低稳定性是必然的，对于依赖的中间件等基础设施的不稳固，这是偶尔的；到了预发、灰度和公布阶段，变更曾经趋于稳定，通过了后面阶段的洗礼，复杂度是绝对低的，稳定性也能失去保障；
另一方面，如上图所示，生产环境只有一套，链路和利用间的调用关系比拟清晰，但在测试环境中，因为波及到多个我的项目的自测、联调、验证等，相当于千军万马过独木桥，很容易产生共振效应，影响所有人的研发，在这方面来讲，测试环境比生产环境要简单很多，亟需解决隔离、低成本以及稳固的依赖这几个重要的问题。测试环境不稳固的偶然性测试环境和生产环境的区别是什么？有的人说线下的容量没有线上大，有的人说线下没有实在用户，有的人说线下短少生产的实在数据，等等，各种答案都有。在我看来，测试环境和生产环境的本质区别是：它们是两个不同的场景。对于生产环境，精确与稳定性最重要；对于测试环境，隔离、低成本和稳固的依赖最重要。在日常的研发中，会面临诸多场景，波及的测试环境总结如下：开发环境（dev）：开发或测试同学本人的电脑或服务器，非 Aone 治理的应用服务器我的项目环境（project）：关联到某个变更的环境，仅部署该变更对应的分支单利用测试多利用联调性能测试：对该变更对应的分支做性能测试日常集成环境（daily）：咱们最相熟的 daily 环境，可部署多个变更对应分支的合并代码骨干环境（testing-trunk）：部署最新正式环境公布分支，即正式环境镜像 mirror of production 自动化测试环境（auto-testing）：跑自动化测试用例的环境 … … 大家常常吐槽测试环境的稳定性，提起不稳固的起因，常常会听到如下解释：测试环境都是过保的机器而且超卖了，为了节省成本生产有的配置，在测试环境没有，导致启动失败了监控、告警等能力在测试环境没有配套投入不够，不器重，对问题的响应不及时，流程机制等没建设起来 … … 其实这些起因中大部分都不是实质问题。换句话说，即使狠狠的砸钱、砸人，即便机器不必过保机、硬件不超卖、工具建设好把配置监控自愈等和生产环境放弃对齐、问题响应机制建设起来，测试环境也还是会不稳固的。因为测试环境不稳固的本源在于：测试环境外面有不稳固的代码测试环境不稳固带来的影响小测试环境比生产环境更简单如上文所说，生产环境只有一套，链路和利用间的调用关系比拟清晰，服务也绝对比较稳定，但在测试环境中，因为波及到并行研发，服务间的依赖会变得很简单，比方 A 对 B 强依赖，那么 A 的性能是否胜利取决于 B，而且 B 变动了之后，也要保障不影响 A。首先是环境创立，此处的“环境创立”指的并不只是通过 yaml 创立出一台 pod 部署利用这么简略，而是创立出一套“可测”的环境，“可测”的准则包含：服务可用、链路联通（包含上下游的服务）、申请隔离等。随着分布式系统的演进，微服务的数量也呈指数级增长，整个零碎的复杂度也会随之降级。这些“微服务”可能单个服务很简略，然而交互建设起的零碎将成为复杂性的瓶颈，很有可能成为一个简单的天堂。咱们以一个简略的样例来阐明：
一条链路上有上百的利用数，其中两个利用 A 与 B 有变更，咱们想一想，如果只创立了蕴含两个单利用的环境，那么能不能满足“可测”条件？咱们会面临如下诸多问题：须要将链路上所有的利用都创立一套环境能力将链路跑通，谁能分明整条链路上的利用？多个我的项目 / 变更，每次都将整条链路上的利用从新创立一套环境？保护和排查老本如何？多套环境，势必会带来并行烦扰的问题，如何将申请精确的路由到冀望的服务上？同一套中间件、数据库等基础设施如何软隔离？外表上咱们只是为某个利用创立了我的项目环境，实际上背地波及了一整套环境复用与隔离计划，水静流深。而对于这种场景，生产环境（预发、正式等）之间首先是物理隔离（预发与正式是两套独立的中间件），其次是只须要一套环境即可满足，不存在并行的问题。怎么让测试环境尽量稳固和简略一点“测试环境的复杂度”，归根到底，无外乎来自于三个中央：环境的复用环境的隔离环境的稳定性（骨干环境）咱们先来梳理两个业务视角：下层业务平台视角：对于下层业务而言，他们的痛点及诉求是心愿是底层的中台能更加稳固中台视角：对于中台而言，除了给下层业务提供服务外，本身还有集成诉求环境复用站在一个我的项目中的开发同学的角度，他通常只须要为有变更的利用创立环境即可，其余的利用都复用一套兜底的环境，如下图所示，这就是我的项目环境 + 骨干环境模式：
有一个骨干环境，骨干环境之上“挂着”若干个我的项目环境“骨干环境”，跑的是和正式环境的版本雷同的代码，每次生产环境公布后，骨干环境也会同步更新“我的项目环境”，每个我的项目有本人的我的项目环境，部署的是我的项目的分支代码，这个我的项目上的同学就在这个我的项目环境里做测试联调（集成）我的项目环境不是全量的，例如，交易链路一共有一百个左右的利用，它的骨干环境是全量的，但我的项目环境只蕴含这个我的项目波及的利用，测试发动的流量会被路由机制从骨干环境的利用路由到我的项目环境的利用除了我的项目环境 + 骨干环境模式，还有一种日常集成环境模式，如下图所示：
对不变的服务或基础设施进行复用后，搭建环境无论是从资源老本还是从复杂度上都失去了极大的升高。环境隔离当对环境复用之后，势必会带来并行烦扰的问题，就须要对环境进行隔离来解决，将申请精确的路由到冀望的服务。隔离大抵分为以下几类：服务隔离（RPC）中间件隔离（音讯、配置、缓存等）数据库隔离 HTTP 流量隔离（无线端 + PC 端）以服务隔离为例，如下图，当多个我的项目并行研发时，对于不同的环境如何做到之间相互不烦扰时须要解决的问题：
将来的方向：通过 Service Mesh 实现隔离 Service Mesh 的权威定义如下：“A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.”用一句话来总结就是，Service Mesh 是一组用来解决服务间通信的网络代理，如下图：
从上图能够看到，Sidecar 接管了网络的控制权，在隔离的场景下，所有的事件都能够在 Sidecar 内实现。应用 Service Mesh 实现隔离有如下长处：对利用自身无侵入适配多种协定（web socket、rpc 等）、多种中间件（音讯、配置、DB 等）屏蔽了技术栈的差别降级对利用自身无影响环境稳定性环境的稳定性对应着如下的金字塔模型，越往上层，稳定性越须要保障，以一个经典的案例为例，如果每一层的稳定性只有 99%，那么 0.99 ^ 4 = 0.96，随着影响因素的增多，整体稳定性就会被放大，如 0.99 ^ 365 = 0.03，所以每一层的稳定性都很重要，都必须 100%，或者至多应该是“五个 9”，这样整体的稳定性才有可能进步。
根底服务稳定性这个的根底服务包含基础设施、中间件和数据库，尽管是测试环境的根底服务，但须要依照生产级的规范进行保障，因为根底服务抖一抖，对于下层服务来说能够说是地震。测试环境能够说没什么可用的根底平台，因为生产环境与测试环境的不同，导致很多生产的监控、排查工具、运维平台在测试环境都没有运行，因而须要建设能够被应用的工具来保障根底服务的稳定性。首先对于根底服务而言，须要建设零碎 SLI/SLO 监控指标，稳定性必须达到 100%，或者至多应该是“五个 9”。其次须要建设快恢机制，及时止血，做到“1-5-10”，即 1 分钟发现，5 分钟定位，10 分钟复原。骨干环境稳定性明天咱们研发同学的心智是：当一个同学在测试遇到谬误的时候，他的第一反馈是“肯定是环境问题”。也就是说，他的第一反馈是“他人的问题”，只有当“他人的问题”都排出后他才会认真的去看是不是他本人的问题（包含我的项目的问题）。骨干环境的稳定性治理，最终就是在做一道证明题：拿出数据来，证实骨干环境是稳固的。所以，如果有问题，请先排查你的我的项目。证实骨干环境是稳固的数据分两类，单利用和链路：单利用就是像健康检查和 RPC 查看这类，它验证的是单个利用是可用的，不论业务逻辑对不对，不论配置对不对，至多这个利用、这个服务、这个微服务是失常启动且运行的。单利用稳定性必须达到 100%，或者至多应该是“五个 9”。这个要求是正当的，因为单利用的稳定性是链路稳定性的根底。如果单利用都没有失常启动且运行，链路性能的可用和正确性就基本无从谈起；
链路的稳定性，说白了就是跑脚本、跑测试用例。频率是分钟级也能够，小时级也能够。验证链路的脚本是须要一直的补充丰盛的，当产生了一个骨干环境的问题然而验证脚本没有发现，就要把这个问题的场景补充到链路验证脚本（测试用例）外面去。也能够借用测试用例充沛度的度量伎俩（例如，行覆盖率、业务覆盖率等等），被动的补充链路验证脚本。很多其余测试用例主动生成的技术也能够用上来；最初，达到的成果就是：用数据谈话。用很有说服力的数据谈话：骨干环境的单利用都是好的，链路也都是能跑通的，这时候呈现了问题，就应该先狐疑是我的项目环境的问题。路由准确性对于隔离而言，一旦路由调飞，一方面用户想验证的性能没有验证到，另一方面排查老本也是极其高的，每次排查至多须要半小时起步。路由准确性的治理，最终也是在做一道证明题：拿出数据来，证实路由逻辑是精确的，包含隔离插件、隔离配置等。所以，如果有问题，请先排查你的服务。证实路由是精确的数据分两类，隔离插件笼罩和隔离数据同步：隔离插件笼罩就是保障所有须要隔离的机器上都装置了隔离插件，如 HSF 隔离插件、MetaQ 隔离插件等，不论路由逻辑对不对，如果没有装置隔离插件，必然是会调飞的（随机调用）。隔离插件的覆盖率必须达到 100%，或者至多应该是“五个 9”。这个要求是正当的，因为隔离插件是隔离的根底。如果隔离插件都没有失常装置，隔离的可用和正确性就基本无从谈起；隔离数据同步就是保障隔离数据的正确性以及同步的效率，如 服务上是否打上了隔离标签、音讯是否带上了隔离标签，当环境创立或者变更实现后，隔离数据是否会立刻失效，隔离数据同步的效率必须是秒级，同步的成功率必须达到 100%，或者至多应该是“五个 9”。隔离数据同样是隔离的根底，隔离插件以及整个隔离体系的逻辑都是围绕着隔离数据开展的；咱们通过 StarAgent 在测试环境的每台机器上部署 Metricbeat 采集代理，采集插件装置状况、服务健康检查状况等，分钟级上报 5w+ 机器的巡检数据，并在呈现问题后及时自愈：
结语对于本文的论断，总结如下：测试环境与生产环境是两个不同的场景，测试环境的不稳固是必然的，在没有实现 TiP（Test in Production）之前，以后咱们能做的是尽量让它稳固一点；测试环境比生产环境更为简单，最外围的是要解决共振问题，即做好隔离能力，Mesh 是解决隔离问题的一个将来方向；聊当初谈将来：咱们心愿将环境一站式 / 沉迷式的产品体验，笼罩整个联调验证的生命周期，提供从环境搭建到回归验证的全方位服务，部分的试点优化及改良能造成全局打算，总结出的方法论与工具能逐渐笼罩到全局，使得联调问题往正向循环倒退，最终全面解决联调效力问题。参考：1.《Pattern: Service Mesh》2.《What Is a Service Mesh?》《阿里巴巴 DevOps 实际手册》火遍寰球的 DevOps 到底是什么？如何利用 DevOps 进行高效能研发？如何享受 DevOps 红利，打造本人的精英交付团队？《阿里巴巴 DevOps 实际指南》给你答案！本书分为开篇、麻利研发篇、代码治理篇、继续交付篇和解决方案篇五大篇章，笼罩 DevOps 演进史、核心理念与阿里巴巴最佳实际的全方位解析，从 DevOps 到云效架构师教你搭建 DevOps 平台，想要实现高效研发，读这本书就没错啦！点击这里，查看详情。原文链接：https://click.aliyun.com/m/10… 本文为阿里云原创内容，未经容许不得转载。