​

专注于为中小企业提供成都做网站、成都网站设计服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业临夏免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了成百上千企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。

开发一个需求，需要先进行代码的编写和个人验证，验证功能符合预期之后，再提交代码，并进入到集成环境，进行进一步的验证及验收。而这个编码和验证的过程占据了整个需求交付的大部分时间，因此提高这部分工作的效率就显得至关重要。

问题

有什么因素降低了开发调试的效率呢？

给定下面一个系统，其中为了开发某个需求，修改了 A 和 D 这两个应用（这里的应用指的是一个可提供服务的一组独立进程加上可选的负载均衡，比如一个 kubernetes 下的 service 及其后端的 deployment）。

接下来看看为了本地调测这两个应用，会遇到什么问题。

本地难以启动整个系统

我们通常都在开发一个复杂系统中的一个应用，这个应用可能在系统的最前端，也可能在系统的中间位置，有时候为了端到端验证整个流程，需要把相关的应用都启动起来。

比如上图中的应用 A 为最前端应用，应用 D 处在中间位置，而黑框中部分是为了完整的测试这个需求而涉及到的应用，如果是 Java 应用，开发机上启动这样 5 个进程，就已经不堪重负了，而很多时候需要完整启动的应用数量会远大于这个数字。

依赖系统不稳定

既然不能把整个系统都在本地启动起来，那么本地就会一部分依赖于公共测试环境。虽然前面提到应该本地测试符合预期之后再把代码部署到测试环境，但不可避免的还是会出现一些 bug，导致测试环境不可用（这也是测试环境的价值所在，尽早的发现问题）。一旦依赖系统不可用，就无法正常的进行测试。

云原生开发模式下的测试环境的连通性

在基于 Kubernetes 的基础设施下，整个系统中大部分的应用通常不需要通过 Ingress 暴露到公网。如果你的测试环境是独立的 K8S 集群，那就意味着无法从本地无法访问到集群内的应用，那么依赖公共测试环境这件事情都无法进行，比如上图中 A->C，D->E，D->F 的依赖。

还有另外一种依赖，即上游应用对本地应用的依赖，比如 C->D 的依赖。但因为 C 是公共测试环境，不可以将所有的 C 对 D 的请求都打到本地来，这就需要某种机制来保证只有特定规则的请求会路由到开发本地的 D 应用。

外部依赖系统到开发环境的连通性

有一些测试链路需要接受一些外部依赖系统的回调，比如微信或者支付宝的回调等。而本地应用通常没有公网地址，这也给调试带来了一些困难。

中间件的隔离

分布式系统中经常会用到 RocketMQ 等消息中间件，如果使用了公共测试环境，就意味着 MQ 也是共用的，那么 MQ 的消息到底是应该被测试环境消费，还是某个个人的开发环境消费呢，这也是需要解决的问题。

高效本地开发

为了进行全流程的高效开发，应该尽量使用反馈比较快的验证方式，并及早发现问题，逐步进行更加集成，更加真实的测试。

一般来讲，一个开发过程可以经过下面的三个阶段：

1. 编码+单元测试。在小的逻辑单元的层面保证正确性。
2. 针对单个应用的集成测试，可能需要对依赖的应用进行 HTTP 级别的 mock。
3. 结合公共测试环境进行完整的集成测试。

基于上面的三个阶段，可以使用以下的方式来解决前面提到的几个问题。

1. 使用各个语言相应的测试工具（比如 JUnit）来进行单元测试。
2. 使用 moco 等 HTTP Mock 工具来解决本地隔离验证的问题，完成单个应用的集成测试。
3. 使用 kt-connect 和 virtual-environment 等工具来解决云原生基础设施下，本地和测试环境的互相连通性问题，及 http 请求链路的染色和路由。
4. 使用 ngrok 等工具解决外部依赖调用本地应用的问题。
5. 使用“主干稳定环境”作为公共测试环境，提高其稳定性。
6. 使用中间件的染色隔离能力保证 http 请求之外的其它链路（比如消息）的染色和路由。

其中第 1、4 是成熟的技术，这里不再赘述。第 5、6 点会在后面的测试环境相关的章节中我们详细讲解。本文主要就第 2、3 点展开讲解。

单应用的集成测试方案

比如对应用 D 而言，测试范围如下图的橙色框所示：

应用本身的持久化等依赖使用真实的（一般使用本地 DB），但外部应用（应用 E、F）使用基于 HTTP协议的测试替身。这样就可以保证所有的依赖都是稳定的。并且也可以很方便的修改测试替身的行为，以进行特定场景的测试。

应用 D 依赖了两个应用：

1. org-service（应用 F）：提供查询组织信息等能力
2. user-service（应用 E）：提供查询用户信息等能力

这两个应用的访问地址配置在应用 D 的配置项中：

...
org-service-host: org-service
user-service-host: user-service
...