4.2 互联网系统运行环境及软件介绍
在开发工程师交付代码并提交测试时，我们需要将代码通过构建工具打包、部署到测试环境中进行各种类型的测试。测试环境除了我们通常所知的硬件环境（如服务器）、网络环境（如路由器、交换机组成的内部互联网络），还包括基于这些基础硬件环境构建的基础软件环境。互联网开发的Web 软件，一般部署时包括反向代理服务、Web 服务等。
4.2.1 Nginx
反向代理是指将从外部收到的请求解析后转发到内部网络的服务上，并将从内部服务得到的响应结果转发到外部请求方，一般外部看到的只是一个代理服务，内部通过配置指定的规则将请求转向具体服务。目前比较流行的反向代理服务包括Apache、Nginx 等。与Apache 相比，Nginx 占用内存和资源更少、支持更多的并发连接、支持高度模块化的设计，同时也支持负载均衡、热部署，处理响应快、易扩展，因此用户量很大。京东目前采用Nginx 作为反向代理服务软件。
日常使用Nginx 时常用的操作包括执行nginx 命令、配置反向代理等。nginx 命令执行比较简单，命令格式为nginx -s signal。signal 代表发给nginx 的指令信号：
stop-快速停止服务；
quit-处理完当前事务后停止服务；
reload-服务运行中重新加载配置文件（即热加载）；
reopen-重新打开日志文件。
Nginx 配置文件存放在conf 目录下，一般默认名为nginx.conf。配置文件采用自定义语法格式。常用的配置节点如代码示例4.2.1 所示。
代码示例4.2.1
#定义HTTP 反向代理服务 http { server { } } |
如代码示例4.2.2 所示，用于定义请求执行的具体服务地址。
代码示例4.2.2
location / { root /data/www; } |
如代码示例4.2.3 所示，配置了多路径解析，代表只将路径的请求转发到localhost8080 端口，将/images/路径的请求指向静态文件路径/data/目录。
代码示例4.2.3
server { location / { proxy_pass http://localhost:8080; } location /images/ { root /data; } } |
生产环境的Nginx 支持负载均衡策略，包括round-robin（轮询调度算法）、least_conn（最少连接算法）、ip_hash、hash、least_time（最少时间花费算法）。一般在测试环境中不会用到。如果请求的域名没有在内部DNS 解析服务配置，则需在本机配置host 信息，Windows 系统修改C:\Windows\System32\drivers\ etc\hosts 文件，Linux 系统修改/etc/hosts 文件。
4.2.2 Docker
Docker 最初是由dotCloud 公司创始人Solomon Hykes 发起的一个公司内部项目，Docker 使用Google 公司推出的Go 语言进行开发实现，基于Linux 内核的CGroup（Control Groups）、namespace，以及AUFS（Another Union FS）技术，对进程进行封装隔离，属于操作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其他隔离的进程，因此也被称为容器。
如图4.2.1 和图4.2.2 所示，是传统虚拟机和Docker 容器技术的比较。虚拟机不仅包括应用也包括虚拟操作系统。操作系统一般要占用几个GB 的磁盘空间，运行后要占用上百兆内存。而Docker 容器共用宿主机的内核，只需安装应用和必要的类库，非常轻量。
如果在测试服务器上使用Docker，则会极大节省硬件资源，降低企业成本。同时性能和使用方面也优于传统的虚拟机。Docker 支持镜像构建和镜像部署，有类似于Github 的Docker hub 的镜像开源仓库hub.docker.com，这上面有100000 多免费镜像资源。目前国内也有很多Docker 镜像网站，读者也可以自行搜索。可以想象我们在安装各种服务软件的过程：下载软件包或者用源码编译构建软件包、修改配置文件、设置环境变量，这些操作非常繁杂。如果使用Docker 容器，则只需获取镜像，一键安装即可。同时，我们也可以将常用的系统软件集构建成镜像后部署到其他容器。目前京东已经开始支持测试环境和线上环境使用Docker 容器技术进行软件的构建发布。常用的方式是在物理机上创建多个Docker 容器供用户作为虚拟服务器使用。
4.3 测试环境分层
用户在京东商城购物，从下单到收货要涉及网站、交易、配送、结算等多个业务领域。一个业务需求的测试工作经常需要跨部门、跨系统分工协作。只有系统间连接、调用畅通才能保证业务上下游数据的正常流转，满足各个业务测试场景。测试环境中各个系统的互联互通非常重要。因此各部门间都需要有稳定的测试环境。
京东的服务器分布于多个机房，各机房之间、机房和办公网之间通过专线连接。生产环境和研发工作中使用的测试环境是相互隔离的，以保障生产环境的绝对安全。如果测试环境的应用服务需要访问生产环境的应用服务则由需求方在运维管理平台上申请网络访问权限，由运维开通。
研发工作主要由产品设计、开发、测试及上线发布组成。开发工程师在迭代开发中常常进行模块集成、阶段交付成果的自测，因此需要有供开发人员使用的测试环境，我们简称开发测试环境。测试在开发人员提测后需要在测试环境上针对相应版本进行系统功能测试。我们将这种测试环境简称为分支测试环境。测试工作包括集成测试、系统测试等。笔者所在的测试团队，采用持续集成的方式进行冒烟测试和核心功能的回归测试。持续集成工作最主要的技术手段是持续稳定的自动化测试。测试工程师针对长期稳定的核心功能和大量反复的业务功能通过编写接口和UI 自动化测试脚本进行回归测试和功能验证测试。如果测试环境不稳定，则会导致自动化测试执行失败，引起误报，从而导致投入较多的人力成本。
京东这种面向消费者，业务量巨大的系统，需要满足高并发、高可用的要求。每个系统、服务需要分布在全国多个节点机房部署。常常采用负载均衡策略进行多实例部署。服务越来越多、服务间依赖关系复杂、服务的状态需要监控，面对这些问题，京东有自己独有的分布式架构服务治理方案。所有的服务不是直接提供给消费者调用，服务启动时首先要将服务的信息加入注册中心。服务调用时需要先通过注册中心分配服务资源，注册中心存储管理服务信息，监控服务的状态。这种服务治理方式我们称为JSF（Jingdong Service Framework，京东服务框架）。它提供了一整套基础开发框架和规范。测试环境也采用同样的服务接入方式。
线上服务有专业的运维团队保障，而测试环境因为它的特殊需求，每个服务随时都可能停止运行。线上服务是基于主干代码部署，而测试环境就没有那么单纯。它容纳了众多分支，存在众多功能和代码差异。测试的服务会依赖其他服务，而依赖的服务也会依赖更外部的服务。注册中心的引入是为了解决服务治理的问题，但如果不能区分主干稳定服务和分支服务，则会导致测试时调用关系混乱，会出现只知道被测服务的分支及版本，而不清楚所依赖的外部服务分支及版本的情况。
综上所述，我们的测试环境实现了测试环境和研发环境的分离。稳定环境一般在没有测试活动的夜间构建部署。分支测试环境供日常测试使用。稳定环境可以有一套供开发自测、手工测试、自动化测试使用。如果资源充足的情况下可以单独提供一套供自动化测试使用。分支测试环境的数量依据项目和需求的数量而定，但需要分组管理，不同的分支服务之间互不依赖，互不干扰。
