阿里微服务质量保障系列：研发环境知多少

​

本文是微服务质量保障系列文章第三篇，主要介绍微服务架构下为什么使用容器技术、阿里的研发环境是怎样的。

单体架构的噩梦

此前的工作经历，负责的产品在技术上大多是单体架构实现，产品的部署方式是直接将应用打包后上传到物理机，然后写个bash指令一键启动应用。

整个项目团队有2套环境，分别是dev环境、uat环境，不同的环境是固定IP的物理机，其中开发和测试共用测试环境。

记得当时整个项目流程大概是下面这张图，当时的开发只要写好代码且代码能跑起来，他们基本上就不测试自己写的代码，会直接扔给测试同学进行测试。测试同学干的活可以看下图中红色线条括弧的部分，可以说测试大量时间投入到了重复且毫无意义的打包、部署等事情上。

此外dev测试和uat回归测试基本上是重复相同的工作：

• 上传代码到服务器
• 部署代码
• 测试代码

当然，单体架构下这种研发模式没问题，可以满足团队的串行迭代，由于测试环境一般不会同时被多个项目占用，适合交付周期长的项目。但是不可否认，使用物理机带来的很多缺点：

• 部署慢。每次部署代码，都要借助于xftp/xshell进行代码上传和程序启动，对于比较大的jar包，上传代码的时间足够你喝杯茶了。
• 成本高。
• 难以迁移。如果将代码迁移到另一台服务器上，则需要先把服务器环境配置好，然后再将代码部署到新服务器上。而每次配置服务器需要耗费大量时间安装各种工具和软件，并且需要保持软件的版本要和之前服务器保持一致。

容器化技术的优点

如果使用单体架构的玩法应用在微服务架构，很显然行不通。微服务的一个优点就是满足团队的协同开发，而且研发周期比较短，如果使用单体架构的玩法，难免会遇到测试同学抢占测试服务器的情况，因为一台机器无法实现不同版本应用代码的环境隔离。当然有的同学可能会说，使用虚拟机啊，例如vmware/kvm，确实这样一台物理机就可以实现不同版本代码的环境隔离，但是使用虚拟机会并非没有任何问题，因为将虚拟机直接运行在物理机上，物理机作为宿主机，自身的硬件资源被分割为N等分，同时虚拟机也会占用大量硬件资源，最终结果是造成物理机自身的硬件资源浪费，此外虚拟机技术仍然无法解决部署效率低的问题。

使用虚拟机技术，其实相当于在宿主机上分割一部分硬件资源，然后在此上安装特定的系统，代码的部署仍需要先启动虚拟机的系统、上传代码等一系列操作。

容器化技术则很好地解决了上述遇到的问题：环境隔离问题、部署效率低问题、开发/测试/生产的代码部署一致性问题。

Docker不同于虚拟机技术，Docker是直接跑在宿主机上的，利用Docker，可以将应用的代码和配置打包成镜像文件，并且不同镜像之间是进程隔离的。

借助 Docker，可以与管理应用程序相同的方式来管理基础架构。利用Docker实现快速交付、测试和部署代码，可以大大减少编写代码和在生产环境中运行代码之间的延迟。

Docker轻巧快速。它为基于虚拟机管理程序的虚拟机提供了经济高效的替代方案，因此可以利用更高效地利用计算机资源，用更少的资源做更多的事情。

可以肯定的是，当前国内大厂亿级流量的应用部署都是基于容器技术的。因此，如果想进入大厂工作，掌握容器技术是必修课。

阿里环境知多少

阿里的环境总体上分为三大类：开发环境、测试环境、线上环境。大家肯定对这么环境比较感兴趣，我下面就重点介绍为什么需要这些环境以及它们分别解决了什么问题。

下面就以项目的整个研发流程为例，介绍下这多环境存在的意义。

开发环境

开发环境有稳定环境、dev环境。为什么分为这两个环境呢？ 其实根据名字就能看出来这个环境的特性，稳定环境的特性肯定是稳定嘛。这个环境是为了满足上下游应用变动、但本应用不变的开发场景，这时候上下游应用需要一个和线上环境代码一致的服务，那么稳定环境的部署和配置就要和线上环境保持一致。

dev环境则是开发和测试进行新功能测试使用的环境，此环境会部署项目新feature。

测试环境

隔离环境和Test环境的区别？

任何一个需求迭代引起的代码变更无非会带来两个结果：实现新功能、(可能)改变老功能。

对于测试同学来说，新功能需要优先保障，老功能也需要全面回归。回归测试的时机，是等当前发布窗口的所有项目分支都合并到主干分支后才开始进行。

这里提一下阿里的开发模式：特性分支开发模式，指当进行多个特定的需求时，开发从主干分支上拉出特性代码分支（branch），在其特性代码分支上完成相应的开发(测试)后，再把它合并（merge）到主干分支发布的开发模式。这里需要注意的是，生产环境部署的代码除了紧急fix代码外，始终是主干分支代码。

此外，回归测试除了从新老功能角度定义外，也可以从 域内自动化回归、端到端回归两个角度定义。 域内自动化回归顾名思义，针对域内的功能进行回归，因此对依赖的外域服务都需要进行mock。那么这时候就需要一个环境，只需要部署本应用服务即可，其他服务都被mock（隔离），所以隔离环境应运而生。

隔离环境的特点也是 稳定，但这个稳定的目的是减少外域的干扰。 隔离环境部署的代码是主干分支代码，它有自动同步主干分支代码的机制。

Test环境则是更多为端到端回归测试服务（因此Test环境发起的请求基本上不使用mock）。微服务架构下，基本上只有大项目才会进行这种端到端的回归测试，因为端到端测试需要协调各个应用团队，成本太高了。

线上环境

线上环境一般分 预发环境、灰度环境、生产环境。 预发环境用于产品同学利用测试账户做功能验收，预发环境有自己的数据库，和其他两个线上环境产生的数据是隔离的。 灰度环境用于灰度发布小流量引流，灰度服务器本身就是生产的服务器，因此其数据库也是和生产环境共用的。

生产环境就不做赘述了。

​