EDAS 3.0 微服务测试最佳实践

该文章是基于阿里云商业化产品 EDAS 3.0的微服务实践，如果您的团队具备较强的微服务测试能力，那么希望我们在微服务测试方面的实践和背后的思考，可以为您提供一些参考。

点击这里，观看直播，了解更多 EDAS 3.0 微服务测试相关内容。

前言

随着云原生时代的到来，越来越多的应用生在云上，长在云上，且随着越来越多的企业开始上云，云原生也是企业落地微服务的最佳伴侣。但云上应用易测性受到了很大的挑战，如何提高云上应用易测性，增强DevOps能力，是微服务测试要解决的核心问题。
在详细讲述微服务测试之前，先给大家讲一个场景。

上图是一个典型的企业微服务应用架构图，为了考虑安全性，云上应用通常部署在云上虚拟局域网内，统一通过网关对外暴露服务。对于负责 Product Service 应用的同学来说，我只想测试一下该应用对应的服务是否可用，他会怎么做呢？
方案一：进入该应用部署所在的机器（ECS）或者容器（Pod），通过 curl 命令验证该服务是否可用。
方案二：将该应用暴露给公网访问，通过本地命令行工具或者 Postman 工具验证该服务是否可用。
方案三：拉一条网络专线，打通云上专有网络VPC与办公网网络，通过本地命令行工具或者 Postman 工具验证该服务是否可用。

从以上场景，我们可以总结出云上微服务测试几点问题：
• 云上网络拓扑复杂
• 暴露公网访问，会出现黑客攻击，引发安全风险
• 拉一条网络专线，浪费资源成本
明明只想要一个简单的测试能力，成本缺如此之高。上述场景还仅仅是一个简单的调试功能，如果是压测、自动化回归、巡检等其他测试及稳定性保障手段，不仅仅要解决上述场景遇到的问题，还需要自建工具，脑补一下，都觉得成本太高，因此，我们需要微服务测试来帮助我们解决这些问题，进一步加速软件交付效率。

为什么我们需要微服务测试

产品能力

提供测试、压测、自动化回归、