本文是《微服务治理实践》系列篇的第七篇文章，为大家介绍微服务治理+测试：基于服务契约信息，降低云上微服务测试成本。该系列文章基于阿里云商业化产品 MSE 的微服务实践，如果您的团队具备较强的微服务治理+测试能力，那么希望我们在微服务治理+测试方面的实践和背后的思考，可以为您提供一些参考。

前言

随着云原生技术的推广和普及，越来越多的公司开始实现微服务化，与此同时，保障线上微服务接口可靠性的方案却并不完善，当线上微服务接口异常时无法做到实时感知，业务风险较大。因此，为了保证线上服务的稳定运行，除了监控关键服务的资源，还需要监控各服务之间使用的微服务接口。微服务巡检平台的出现正好解决了以上问题，可以让您低成本快速地主动探测服务可用性，做到 1 分钟创建巡检场景，秒级探测服务可用性。

在详细讲述微服务巡检之前，先给大家讲一个场景。

上图是一个典型的企业微服务应用架构图，为了考虑安全性，云上应用通常部署在云上虚拟局域网内，统一通过网关对外暴露服务。在这个典型的企业微服务应用架构图中，Product Service 应用提供查询商品列表和通过 ID 查询商品详情的功能，Business Service 应用提供添加商品到购车的功能。对于负责 Product Service 应用的同学来说，如果想定时验证用户操作的从查询商品列表→通过 ID 查询商品详情→将商品添加至购物车这个业务场景，现在我们一般怎么做呢？

进入 Product Service 应用部署所在的机器（ECS）或者容器（Pod），通过 curl 命令调用查询商品列表，验证返回的商品列表是否不为空并且含有指定商品的内容

把查询商品列表返回值中的 ID 拼接到 curl 命令的入参中，调用通过 ID 查询商品详情，验证详情中的字段是否符合预期

进入 Business Service 应用部署所在的机器（ECS）或者容器（Pod），把 ID 拼接到 curl 命令入参中调用添加该商品至购物车，验证添加是否成功

间隔指定时间重复上面动作

不止要完成多步骤的人肉验证，还要保证多时间的重复操作，至此我们可以总结出云上微服务巡检的几点问题：

云上网络拓扑复杂
业务链路场景验证难
重复繁琐操作验证效率低

明明只想要简单地探测服务可用性，成本却如此之高。因此，我们需要微服务巡检来帮助我们解决这些问题，降低探测的成本。

为什么我们需要微服务巡检

易用且安全

开箱即用，无需关注专有网络 VPC 下的网络拓扑；安全可靠，拥有在办公网下的测试体验。

试想一下，企业为了安全隔离，研发环境、测试环境、预发环境、生产环境部署在不同的专有网络 VPC 内，如果用户自建巡检工具，需要解决巡检工具到不同环境的网络互通问题，企业 IT 人员明明只想要一个简单的巡检工具，却因为上云之后，要解决复杂的云上网络拓扑，远远没有结束，为了能够在办公网使用该巡检工具，还需要保证该巡检工具能够被办公网访问，此时又面临着网络安全的考验。我们希望有一个能够开箱即用且安全可靠的方案，能够让上云的企业 IT 人员拥有在办公网测试体验的巡检工具。

低成本

弹性拉起施压机，用完销毁，能够大幅度降低构建巡检工具需要的机器资源及人力成本。

试想一下，企业上云是为了降低成本，应用托管极大地降低了资源成本和运维成本，但巡检成本并没有降低。企业 IT 人员自建测巡检工具需要准备施压机，该部分机器长期占用且存在闲置，资源成本开销大。除了资源成本外，企业 IT 人员还需要研发巡检工具，人力成本及时间成本非常高，基本上每个企业都需要研发巡检工具。我们希望有一个低成本的方案，不仅提高企业的资源利用率，同时降低企业 IT 人员开发和维护巡检工具的成本。

微服务生态

云上已提供了大量的微服务产品，解决了微服务应用的托管、治理、诊断，微服务测试补齐微服务能力。

试想一下，如何测试一个微服务接口，需要了解接口入参和出参，如果是研发同学-服务提供者，可能比较熟悉该接口，如果是测试同学，甚至是其他研发同学，可能就需要文档，甚至是口口相传，微服务治理已经可视化应用的服务契约信息，结合服务契约信息，只需按照巡检需要，选择应用->框架->服务->方法，配置巡检参数，即可进行巡检，降低了服务契约同步的成本。