极客时间已完结课程限时免费阅读

15 | 开发和测试争抢环境？是时候进行多环境建设了

15 | 开发和测试争抢环境？是时候进行多环境建设了-极客时间

15 | 开发和测试争抢环境？是时候进行多环境建设了

2018-01-31 赵成 来自北京
《赵成的运维体系管理课》
课程介绍

讲述：黄洲君

时长11:30大小5.26M

在上一期文章里，我们介绍了多环境下的应用配置管理问题，从这期开始，我们会分两期文章详细聊聊多环境建设的问题：就是我们到底需要哪些环境？这些环境都有什么作用？环境建设的思路和方式是怎样的？
今天我就结合自己的经验和理解与你聊一聊持续交付中的线下多环境建设。

环境分类

通常，我们主要按照环境所起到的作用，将环境分为两大类：
线下环境：测试验收用。
线上环境：为用户提供服务。
从建设角度来说，线下环境和线上环境，在网段上是要严格隔离的。这一点在做环境建设时就要确定网络规划，同时在网络设备或者虚拟网络的访问策略上要严格限定两个环境的互通，如果限制不严格，就极易引起线上故障，甚至是信息安全问题。
如果你维护过这样两套环境，我想你一定在这方面有过深刻的感受，甚至是痛苦的经历。
所以，从规划上，线上环境和线下环境是两套独立的区域，所有的应用、基础服务都是全套独立部署的。但是线下环境所需的资源往往是要少于线上环境，毕竟只有负责开发测试的少数人使用，不会有线上流量进来。如下图所示：
但是，在实际情况中，这两个环境远远满足不了我们日常开发、测试和运维方面的需求。从保障软件质量和系统稳定的角度出发，我们在实际操作中还需要在这两个大的环境区域中，建立细分的小环境，来满足不同阶段和不同角色的工作需求。

线下环境分类建设

线下环境最初建设的时候，主要是提供给测试使用，帮助其建立一个模拟环境，在软件发布上线前进行需求功能验证，保障业务流程顺畅，以确保应用在上线前达到最低质量要求。
所以，我们在线下环境区域内，建设的第一个环境就是集成测试环境。甚至在一开始，线下环境 = 集成测试环境，这个环境下的应用和各类基础服务必须跟线上保持一致，但是集群规模不用这么大（如我们上图所示）。
所以，集成测试环境极其重要，这个环境中的应用有严格的发布标准，并且要求环境稳定，不能随意发生变更，否则将会大大影响测试的效率。
不过，随着集成测试环境建设起来，业务需求迭代越来越快，应用和开发人员数量也越来越多，软件发布和变更也会更加频繁，这个时候就会出现开发和测试人员争抢集成测试环境的问题。
比较典型的场景就是，测试人员正在验证一个功能，突然发现应用停止运行了，原来开发为了验证和尽快发布新功能，更新了代码，这样就阻塞了测试的正常工作，但是不更新代码，开发的工作又会停滞下来。
后来这个矛盾越来越严重。这时，我们就需要考虑多建设一套给开发用的环境来解决这个问题。
于是，我们就开始建设线下的第二套环境：开发测试环境。这个环境主要是让开发同学能够尽快发布自己开发完的代码，并在一个具备完整业务应用和基础服务的环境下，验证自己的代码功能。
但是，是否需要跟集成测试环境一样，再建设一套独立完整的线下环境出来呢？答案是否定的。因为这时的应用变化范围相对独立，变化也较小，周边依赖需要同时变化的应用也不会太多，就像上面说的，只要能把它们放到一个完整的环境中进行验证即可。
所以，这个环境只要按照最小化原则建设即可，如果有依赖，可以直接访问到集成测试环境。在这里，我们以简单的模型展示开发测试环境跟集成测试环境的关系：
再往后，开发测试环境上，又会出现开发和测试的冲突和争抢，因为从场景上，业务开发团队可能要同时承担多个并行项目的研发，而且可能会有多个业务开发团队一起参与进来。
比如对于电商来说，到了年底，就集中会有“双 11”、“双 12”、“双旦节”以及“年货节”等等这样的大型营销项目，因为时间非常紧凑，所以就必须多项目并行。
这个时候，分解下来，对于我们的应用软件来说，有可能是存在多个开发分支的。到了项目联调和验证环节，就必然会存在同一个应用有多个版本需要同时发布和测试的情况，但是开发测试环境却只有一个，这就必然导致双方激烈的争抢。
所以这个时候，就必须建立解决冲突的方案，开始建设线下的第三套环境：项目环境。
项目环境可能有多套，一个项目对应一套环境，但是无论从资源成本还是维护成本方面考虑，项目环境仍然不会像集成测试环境那样形成一套完整的开发测试体系。
所以项目环境同开发测试环境一样，仍然是以最小化为原则来建设，也就是说，在这个环境里面，只部署同一项目中涉及变更的应用，而对于基础服务和不涉及项目需求变更的应用不做重复建设。如果对项目环境中不存在的应用有依赖，那么访问集成测试环境中对应的应用就可以了。
在这里，我们同样以简单的模型展示多个项目测试环境、开发测试环境与集成测试环境的关系：
不过，如果说随项目的增加就需要分别建设对应的项目环境，那么这对于开发、测试和运维来说都会有非常大的维护负担。所以通常情况下，我们会严格限制建设项目环境的起步线。
比如只有公司级大促、公司战略级的项目，或者超过一定人日的跨团队项目，才允许建立独立的项目环境。一般情况下，还是引导优先使用开发测试环境。

环境建设上的关键技术点

线下环境细分出集成测试环境、开发测试环境以及多个项目环境之后，带来的最大的成本其实不在资源上，而是在管理和维护上，而且单单就线下维护的工作量来说，甚至要超过线上维护的工作。
复杂度和涉及到的技术点有以下四个方面。
第一是网段规划。每个环境都要有独立的网段，比如整个线下环境要独立占用一个 B 段，项目环境和开发测试环境相对较小，可以独立占用一个 C 段。虽然不需要做网络策略上的隔离，但是为了便于管理，如分配回收资源以及部署应用，还是要在逻辑上区分出来。同时，网段规划也是为下面的单元化调用做准备。
第二是服务化框架的单元化调用。这一点需要服务化框架支持，比如上面我们提到的项目环境，到了联调阶段就需要一组应用单独联调，而不能跨项目环境调用。同时，对于项目中依赖的未变化的应用，就需要调用集成测试环境中稳定版本的应用。这个服务调用的基本规则就是基于上述网段的规划来建立的，规则要放到服务化的注册中心，也就是 ConfigServer 这个部件中保存，同时需要服务化框架支持规则调用，优先支持本单元调用，本单元不存在可以调用集成测试环境单元。
第三是环境的域名访问策略。这么多的环境 ，内外部 DNS 域名是保持一套还是多套，比如访问蘑菇街主页（www.mogujie.com），首页域名就一个，但是怎么能确保访问到我们所期望的环境上呢。这里有几种方式：
第一种，DNS 服务保持一套，域名，特别是外部域名多套，每个环境分别配置一个不同的域名，比如开发测试环境，dev.mogujie.com。但是如果这样，下层的二级域名和二级目录等等都要跟着变动，而且对于项目环境来说，数量不固定，每次都换一个也不方便记忆和管理，所以这个方案基本不可行。
第二种，DNS 服务保持一套，域名保持一套，但是做域名的 hosts 绑定，也就是自己来设置要访问域名所对应的环境。这样一来，如果相对固定的开发测试环境和集成测试环境所对应的 hosts 相对固定，那么只需要绑定一次就可以通用。但是项目环境始终在不断的变化中，绑定规则可能随时在变化，所以这种方案的复杂度在于对 hosts 配置的管理上。
第三种，DNS 服务多套，也就是不同的环境中配置独立的 DNS 服务，这样可以减少繁琐的 hosts 绑定，但是也会提高多套 DNS 服务管理上的复杂度，而且对于项目环境有可能依赖集成测试环境中的服务，这时仍然会涉及本地 DNS 服务的 hosts 绑定。
第四种，对于公网域名，可以直接通过无线路由劫持的方式访问，可以在无线路由器上配置多个接入点，这样一来，连接不同的接入点，就会自动对应到不同环境的域名 IP 地址上去。
通常，对于公网域名来说，如果具备稳定的环境，如集成测试环境，直接通过第四种劫持方式指定到对应环境中去，这样最方便，这种方案在后续线上多环境建设中还会使用。
对于内部域名，则有多种方案，没有优劣，主要看场景和管理成本。我们选择的是第二 种，即绑定 hosts 的方式。每个环境会对应一套 hosts 配置，当选择不同环境进行联调或访问时，就将 hosts 配置下发到对应部署应用的主机上。
在这里，我们仍然以模型展示第二、四种方案和多种线下环境之间的运行逻辑：
但是，无论采取哪种方式，我们可以看到，这个管理过程仍然是比较复杂繁琐的，必须要非常仔细地规划和部署，同时还需要配套的自动化工具支持，否则靠人管理是不现实的，所以最后一点就是自动化的配套。
第四是自动化管理。按照我们之前分享的管理模式，这里虽然有这么多的线下环境，但我还是会把它们以应用为核心给管理起来，即应用的开发测试环境，应用的集成测试环境，应用的项目环境。这样一来，上面提到的不同环境的网段信息、配置信息、资源分配回收以及软件部署发布，都能够以应用为出发点去做，这一点我们在后面的文章会详细分享。

总结

最后，不知道你有没有感受到，单单一个线下环境就要如此复杂和繁琐，整个持续交付体系建设是多么的有挑战性，就可想而知了。
我们对线下环境稍微做个总结：
集成测试环境，主要供测试使用，这个环境会最大程度与线上版本保持同步。作为对应用的功能、需求、业务流程等在正式发布上线进行验证的主要环境，集成测试环境的稳定性和可测试需要加强保障，进行全套建设。同时，作为整个线下环境的中心节点，也要为开发测试环境和项目环境提供部分依赖服务。
开发测试环境，主要供开发人员使用，针对偏日常的需求开发、联调和功能验证，以最小化原则进行建设，但是一般情况下不对资源进行回收。
项目环境，供开发和测试共同使用，针对多团队多人员协作的项目型场景，可以同时存在多个项目环境，在这个环境中针对项目需求进行独立开发、联调和验证。测试也需要提前介入这个环境进行基本功能的验收，并遵循最小化的建设原则，但是要有生命周期，即项目启动时分配资源，项目结束回收资源，不能无限期占用。
最后，在实际操作中，仍然会很多细节问题，这些问题会跟业务场景有关，针对这些场景又有可能有不同的建设要求，比如消息的消费问题会涉及全业务流程验证等等。
所以，留几个问题给你思考：在线下环境的建设过程中，你通常会遇到哪些问题？会有哪些独立环境？或者你有什么更好的经验和建议分享？
欢迎你留言与我讨论。
如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 5

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
14 | 如何做好持续交付中的多环境配置管理？
下一篇
16 | 线上环境建设，要扛得住真刀真枪的考验
 写留言

精选留言(13)

  • manatee
    2019-10-31
    详情问一下项目环境中的消息与数据如何隔离呢
    4
  • 牧野静风
    2019-07-26
    我们一般存在一个项目多个分支开发的情况，而且还依赖其他项目，联调是个痛苦的事情；其次，想问下老师，各环境的数据库如何配置较好，用生产覆盖还是制造测试数据的方式，很多数据不允许放到测试
    2
  • ArnoYe
    2019-02-15
    在进行多环境维护时，往往需要跟线上一致的数据，有些时候对线上数据进行完全克隆这样会比较麻烦，也不能做到持续克隆，所以因为数据问题，导致集成测试环境，开发环境，不能很好的利用，出现直接上预发环境的情况，针对测试环境的数据问题，老师有什么好的建议吗？
    2
  • 极客达人
    2018-10-08
    老师，问个问题。比如两个项目环境依赖集成环境的支付服务，如果支付完成会触发支付完成回调，请问这个时候支付服务怎么来判断是回调通知项目1环境，还是项目2环境呢？
    共 1 条评论
    1
  • 持续交付实践指南
    2018-03-10
    请问老师，你们用什么自动化工具？

    作者回复: 这个问题太大了，可以具体点吗？比如哪方面的自动化工具。

    1
  • 黄无由
    2018-02-01
    有docker是不是可以解决多环境的问题

    作者回复: Docker可以帮助高效解决这个问题，但是怎么解决，还是要靠我们的思路和方案，docker只是工具而已。

    1
  • manatee
    2018-01-31
    老师这个线下多项目环境按最小化部署我不太理解啊，比如一个a应用部署了两个开发环境，但是如果依赖的dubbo都是一套的话这个调用如何分离呢

    作者回复: 服务化框架要支持本单元（环境）调用优先，在框架能力强要做一些改造。不然就会出现你说的问题

    1
  • kubxy
    2021-01-20
    "每个环境分别配置一个不同的域名...但是如果这样，下层的二级域名和二级目录等等都要跟着变动"。这句话理解起来有点抽象，能否举一个具体的例子？
  • 符亮
    2020-07-22
    启发很大，特别是项目环境那块。我们目前是开发，测试完整两套环境，利用k8s的命名空间隔离开，内部的configmap作为应用配置载体注入容器内的环境变量。我也在头疼一个服务好几个开发，测试增强环境的问题，原来还有项目环境这一说，我们体量不大，基于k8s去实现项目环境应该可行，非常感谢。

    作者回复: 但是也要注意，项目环境多了，带来的管理复杂度也会提高，非关键核心项目建议不要用。 也可以分享下你的经验

  • 約等于零
    2020-06-08
    想问下 各个环境应该由谁负责维护

    作者回复: 谁使用谁维护，当然有一个前提条件是，自动化运维的条件要足够成熟，这样才能降低维护成本，不然，换谁都不会轻松

  • 刘平
    2020-04-07
    我们一开始也是绑定hosts，后来发现人越来越多，测试成本有点高，就开始实行一套DNS，多个域名，比如对外正式域名是www.mogujie.com，预发是www.pre.mogujie.com，预发统一二级域名pre.mogujie.com，这个可以泛解析，只要解析一次就行，测试环境同理

    作者回复: 但如果有二级域名就会比较麻烦，特别是跳转逻辑这块

  • 每天晒白牙
    2020-03-22
    我们现在就有环境问题，并行开发部署环境老争环境

    作者回复: 环境上解决不了，也可以尝试下管理方式，比如排队。

  • 老衲只吃肉
    2019-07-23
    我认为最小化开发测试环境部署会遇到很多问题，下面留言就很多人反馈了，我们实际使用也遇到很多问题，因为环境的依赖等原因，代码上做很多调整，尤其数据层有变更，例如项目A对order库的order_base表做了变更，但项目B是不需要变更的（兼容问题），如果最小化部署包含独立的关联的库，又会因为项目库和集成测试库的数据一致关联问题。为了降低开发围绕着环境去做的一些调整，就干脆每次部署环境就是完整的一套。虽然在资源成本上升了，但运维自动化如果做的好，耗时在5分钟内就可以完整克隆一套环境出来了。[我们一套环境超150个应用和80个库]。 个人感觉最小化部署只适合业务上拆的很细，逻辑划分清晰，耦合非常小的项目。
    展开
    1