沙箱包含一个单一的、类似生产的预生产环境，它结合了隔离测试的优势和共享设置的效率。
译自 Why Environment Replication Doesn’t Work for Microservices Testing，作者 Arjun Iyer。
在微服务架构的世界中，有效的测试已成为开发团队面临的一项重大挑战。随着系统变得越来越复杂，团队规模不断扩大，传统的测试方法往往力不从心。让我们来看看常见的测试策略、它们的局限性，并介绍一种很有前景的解决方案：共享环境中的沙箱。
在基于微服务的系统上工作时，开发人员面临着一个关键问题：如何在将代码推送到生产环境之前，确保对一个服务的更改与所有其他组件都能良好地协同工作？
本地复制方法
最初，在每个开发人员的机器上运行系统的完整副本似乎是理想的选择。它承诺了进行更改、运行测试和验证功能的便利性，然后再提交代码。
然而，随着系统的增长，这种方法很快变得不切实际。在本地运行众多服务、数据库和依赖项会占用大量资源，并且经常会导致性能问题。使这些环境与来自所有团队的最新更改保持同步是一个持续的挑战。此外，本地设置与生产环境之间的差异会导致臭名昭著的“在我的机器上可以正常工作”问题。
共享预发布环境
鉴于本地测试的局限性，许多团队选择使用共享预发布环境。这种集中式的、类似生产环境的解决方案似乎解决了本地测试的问题。
然而，在实践中，共享预发布环境也存在着自己的挑战。当多个团队试图同时进行测试时，资源争用成为一个重大问题。开发人员经常发现自己需要等待访问权限，导致开发过程延误。预发布环境的稳定性也成为一个问题，未经测试的代码可能会破坏其他团队的工作。
为了缓解单个共享环境的问题，一些组织实施了多环境策略。这通常涉及一系列环境，例如开发、QA、UAT 和预生产，为代码在到达生产环境之前创建一个管道。
虽然这种方法似乎解决了争用问题，但它往往会带来新的挑战。它不是消除资源冲突，而是将它们分散到多个环境中。在这些环境之间保持一致性变得越来越复杂，导致配置漂移。通过多个环境推广代码的过程可能会显著减慢发布周期，可能会抵消微服务架构的敏捷性优势。
为每个开发人员或团队按需创建环境的概念是某些组织探索的另一种方法。理论上，这消除了争用并提供了隔离的测试环境。
然而，这种策略会导致基础设施为每个实例重复而产生大量成本增加。创建完整环境所需的时间也可能是一个阻碍因素，可能会鼓励开发人员绕过彻底的测试，转而更快地推送代码。
此外，这些按需环境如果没有持续更新，很快就会过时。随着发布频率的增加，这个问题会加剧，这是微服务架构中常见的场景。在快速发展的系统中，昨天还最新的环境今天可能已经过时，导致测试结果的可靠性降低。
鉴于这些常见策略的局限性，一种新方法出现了：共享环境中的沙箱。这种方法被 Uber、Lyft 和 DoorDash 等公司采用，为解决微服务测试的挑战提供了一种有前景的解决方案。
核心概念是维护一个由所有团队共享的、类似生产环境的单一预生产环境。当开发人员需要测试更改时，他们在该共享环境中部署特定服务的修改版本。智能路由机制然后将测试流量定向到这些新版本，同时将常规流量定向到稳定版本。
这种方法将隔离测试的优势与共享环境的效率相结合。它允许进行现实的测试，而无需完全复制环境，从而解决了与其他测试策略相关的许多问题。
共享环境中的沙箱方法提供了几个关键优势：
- 成本效益：通过仅复制更改的服务而不是整个环境，这种方法显着降低了基础设施成本。
- 提高速度和敏捷性： 开发人员可以在类似生产的环境中快速测试更改，从而实现更快的迭代和更短的反馈循环。
- 增强协作和功能预览：这种方法允许团队与产品经理和其他利益相关者共享新功能的早期预览。多个独立的功能可以同时预览，而无需复制整个环境。
- 现实测试：共享环境保持接近生产环境，从而提高了对测试结果的信心。
- 可扩展性：这种方法随着系统复杂性和团队规模的增加而扩展良好。
这种方法对于以下组织特别有利：
- 大型、复杂的微服务架构
- 多个团队同时开发不同的功能
- 高发布频率
- 需要经济高效、可扩展的测试解决方案
虽然在内部实施此类解决方案可能很复杂，但现在有工具可以使这种方法对所有规模和行业的公司都可用。例如，Signadot提供了一种解决方案，使组织能够使用沙箱环境进行微服务测试，而无需进行大量的内部开发。
各个行业的公司都从采用这种方法中获得了显着的好处。Brex，一家金融科技公司，已使用 Signadot 来简化其测试流程并加快功能交付。Earnest，一家学生贷款再融资公司，改进了其开发工作流程，并缩短了新功能的上市时间。ShareChat，一个社交媒体平台，增强了其测试复杂微服务交互的能力。这些案例研究证明了沙箱方法在共享环境中的广泛适用性和益处。