13518219792
专注于为中小企业提供成都做网站、成都网站设计服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业临夏免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了成百上千企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
编者按：本文源自阿里云云效团队出品的《阿里巴巴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、4 是成熟的技术，这里不再赘述。第 5、6 点会在后面的测试环境相关的章节中我们详细讲解。本文主要就第 2、3 点展开讲解。
比如对应用 D 而言，测试范围如下图的橙色框所示：
应用本身的持久化等依赖使用真实的（一般使用本地 DB），但外部应用（应用 E、F）使用基于 HTTP协议的测试替身。这样就可以保证所有的依赖都是稳定的。并且也可以很方便的修改测试替身的行为，以进行特定场景的测试。
应用 D 依赖了两个应用：
这两个应用的访问地址配置在应用 D 的配置项中：
... org-service-host: org-service user-service-host: user-service ...
