功能标志和预览环境是管理微服务发布和测试的流行方法。了解特定情况下的优缺点。
译自 Microservices Testing: Feature Flags vs. Preview Environments,作者 Arjun Iyer。
微服务架构 改变了现代应用程序的构建方式,使快速的功能开发和可扩展性成为可能。但是,它们也带来了独特的测试挑战。确保新功能在多个微服务中按预期工作,而不会造成意外故障,需要强大的测试策略。在微服务中管理功能发布和测试的两种流行方法是 特性开关 和 预览环境。
每种方法都有其优势和局限性,我将通过一个虚构的微服务应用程序来探讨,该应用程序正在实现新的购物车行为,并与订单服务、支付服务和愿望清单服务交互。

电子商务服务架构示例。(来自“用于微服务及其云和边缘系统硬件软件影响的开源基准套件,” ASPLOS ’19:第 24 届编程语言和操作系统架构支持国际会议论文集。)
在传统的单体应用程序中,测试新功能通常涉及验证整个应用程序。在微服务中,每个服务都是独立开发、部署和测试的,因此更难预测一个服务中的更改可能会如何影响其他服务。例如,对身份验证服务的微小更改可能会意外地破坏支付处理器,如果它们的交互没有经过彻底测试。
为了确保尽早发现此类问题,并在它们影响用户之前解决,测试策略 必须不断发展。这就是特性开关和预览环境发挥作用的地方。
特性开关提供了一种动态的方式来管理功能发布,通过将部署与发布分离。基本思想很简单:新代码部署到生产环境,但只有在特性开关打开后才会激活。这允许逐步发布、目标测试以及在出现问题时轻松回滚。
例如,在我们的微服务应用程序中,我们可以为新的购物车功能实现一个特性开关,如下所示:
if (isFeatureEnabled('newCartFeature')) {
return newCartFunctionality();
} else {
return oldCartFunctionality();
}使用此开关,我们可以为一小部分用户启用该功能,同时在真实环境中测试它与订单、支付和愿望清单服务的交互。
**特性开关不应用于每次更改。**它们最适合用户界面功能、A/B 测试或需要实时回滚的情况。但是,对于更深层的集成或基础设施更改,仅仅依靠特性开关可能很危险,因为这些类型的更改通常需要在到达生产环境之前在隔离的环境中进行全面测试。这就是预览环境大放异彩的地方。
预览环境是一种临时、隔离的环境,可以按需启动,用于隔离测试功能。它可以克隆整个应用程序,也可以选择性地仅部署正在修改的服务。隔离是通过复制基础设施或通过动态路由特定请求到正在测试的服务来实现的。
在我们的微服务应用程序中,预览环境可以让我们在部署到生产环境之前测试新的购物车与其他服务的集成。我们可以运行完整的集成测试,模拟现实世界中的用户场景,尽早发现错误并进行迭代,而不会影响实时系统。
这些考虑因素中的每一个都取决于实现方法——是在预生产环境中隔离完整的基础设施,还是仅隔离正在更改的服务。
虽然功能标志和预览环境都提供了独特的优势,但现实情况是,两者本身都不完美。测试微服务的最佳方法通常是将两者结合起来。
以下是一种实用方法:
这种混合方法使您可以利用两种方法的优势:预览环境的早期错误检测和隔离,以及功能标志的灵活性和实时测试。
有效的微服务测试需要平衡速度和可靠性。功能标志支持在生产环境中进行实时测试,但通常缺乏对复杂集成问题的隔离。预览环境为合并前测试提供隔离,但可能资源密集,并且可能无法完全复制生产流量。
最佳方法?将两者结合起来。 使用预览环境尽早发现错误,然后使用功能标志进行部署以控制生产环境中的发布。这确保了速度而不牺牲质量。