24 | 紧跟时代步伐:微服务模式下API测试要怎么做?

微服务架构(Microservice Architecture)

微服务是一种架构风格。在微服务架构下,一个大型复杂软件系统不再由一个单体组成,而是由一系列相互独立的微服务组成。其中,各个微服务运行在自己的进程中,开发和部署都没有依赖。

微服务架构具有以下特点:

  • 每个服务运行在其独立的进程中,开发采用的技术栈也是独立的;
  • 服务间采用轻量级通信机制进行沟通,通常是基于 HTTP 协议的 RESTful API;
  • 每个服务都围绕着具体的业务进行构建,并且能够被独立开发、独立部署、独立发布;
  • 对运维提出了非常高的要求,促进了 CI/CD 的发展与落地。

微服务架构测试挑战

微服务之间的耦合关系

假定我们的被测对象是 Service T,但是 Service T 的内部又调用了 Service X 和 Service Y。此时,如果 Service X 和 Service Y 由于各种原因处于不可用的状态,那么此时就无法对 Service T 进行完整的测试。

解耦的方式通常就是实现 Mock Service 来代替被依赖的真实 Service。实现这个 Mock Service 的关键点就是要能够模拟真实 Service 的 Request 和 Response。

基于消费者契约的 API 测试

下图中 Service T 是被测试对象,进一步假定 Service T 的消费者(也就是使用者)一共有两个,分别是 Service A 和 Service B。

Service T 可以对外提供的服务的契约,所以我们把这个测试用例的集合称为"基于消费者契约的 API 测试"。

收集消费者契约的逻辑原理

在 Service T 前放置一个代理,所有进出 Service T 的 Request 和 Response 都会经过这个代理,并被记录成 JSON 文件,也就构成了 Service T 的契约。

微服务架构中往往会存在一个叫作 API Gateway 的组件,用于记录所有 API 之间相互调用关系的日志,我们可以通过解析 API Gateway 的日志分析得到每个 Service 的契约。但是API Gateway 只有面向客户端的服务才会有这一层。内部调用主要靠splunk来获取。

微服务测试的依赖解耦和 Mock Service

实现 Mock Service 的关键,就是要能够模拟被替代 Service 的 Request 和 Response。

契约的本质就是 Request 和 Response 的组合,具体的表现形式往往是 JSON 文件,此时我们就可以用该契约的 JSON 文件作为 Mock Service 的依据,也就是在收到什么 Request 的时候应该回复什么 Response。

如下图,当用 Service X 的契约启动 Mock Service X 后,原本真实的 Service X 将被 Mock Service X 替代,也就解耦了服务之间的依赖

相关推荐
武子康1 小时前
Java-80 深入浅出 RPC Dubbo 动态服务降级:从雪崩防护到配置中心秒级生效
java·分布式·后端·spring·微服务·rpc·dubbo
guojl12 小时前
MyBatis最佳实践
后端·微服务·mybatis
小裕哥略帅14 小时前
架构师--基于常见组件的微服务场景实战
微服务·云原生·架构
鼠鼠我捏,要死了捏16 小时前
高并发微服务限流算法方案对比与实践指南
微服务·高并发·限流
武子康1 天前
Java-82 深入浅出 MySQL 内部架构:服务层、存储引擎与文件系统全覆盖
java·开发语言·数据库·学习·mysql·spring·微服务
慧都小项1 天前
自动化UI测试工具TestComplete的AI双引擎:即时数据集 + 自愈测试
自动化测试·测试工具·llm·数据驱动测试·hipaa标准
曾经的三心草1 天前
微服务的编程测评系统6-管理员登录前端-前端路由优化
前端·微服务·状态模式
程序员小远2 天前
Pytest+Selenium UI自动化测试实战实例
自动化测试·软件测试·python·selenium·测试工具·ui·pytest
失散132 天前
大型微服务项目:听书——10 缓存+分布式锁优化根据专辑id查询专辑详情接口
redis·分布式·缓存·微服务