[TOC]

前言

上次我们已经大概介绍过微服务的一些概念，但是这么多的微服务，它们之间是怎样一个交互呢？作为测试人员，我们又有哪些方法可以测试微服务之间的交互场景呢？下面我们来浅谈一下微服务之间的交互场景以及测试方法吧···

微服务架构

1. 微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把一个一个的微服务组合管理起来，对外提供一套完整的服务。
2. 在这一架构下，产生这么一个业务场景，譬如订单服务有个订单返现金额计算（拉新活动），由于分库分表，订单服务不知道用户之间的关系，总不能直接跨库查询查出用户与用户的关系吧
3. 跨库查询风险比较大
   • 权限限制（跨库查询会使得敏感数据更加容易被泄露）
   • 查询效率（使用联合查询语句，这会使得查询效率变慢）
   • 事务管理（事务中跨越了多个数据库，将会增加事务的难度和复杂度）

微服务之间的交互

HTTP/HTTPS 形式

概述

使用 HTTP 协议进行通信是微服务架构中最常见的方式。服务之间可以通过 HTTP 请求和响应进行通信。这种方式简单、通用且易于实现，可以使用 RESTful API 或 GraphQL 等方式进行交互

如何测试？

1. 单元测试： 对于每个微服务中的 HTTP/HTTPS 请求处理逻辑，编写单元测试来验证其正确性。使用测试框架和模拟工具，模拟 HTTP 请求和响应，测试处理逻辑是否符合预期。（接口测试）
2. 集成测试： 对于涉及多个微服务之间的 HTTP/HTTPS 通信场景，进行集成测试。在测试环境中模拟真实的 HTTP/HTTPS 请求与响应，验证微服务之间的通信是否正常，以及对于各种请求情况是否能正确响应。（譬如 mh-scs-admin 服务调用 mh-scs-biz 提供的 HTTP/HTTPS 接口，来获取申领单状态，来进行业务处理）
3. 端到端测试： 在端到端测试中，通过模拟完整的用户场景，测试整个微服务系统的 HTTP/HTTPS 通信流程。从客户端发出请求，经过各个微服务的处理，最终返回响应给客户端，验证系统在真实环境下的工作情况。（譬如从 H 端购买洁净服务，生成用户订单，推送交付端生成服务单，交付端服务单派单后推送调度供应端生成物料需求单）
4. 压力测试： 使用压力测试工具模拟大量并发请求，来评估微服务在 HTTP/HTTPS 通信下的性能和稳定性。通过压力测试，可以找出系统的瓶颈和性能问题，进一步优化系统性能。

RPC 形式

概述

RPC（Remote Procedure Call）是一种远程过程调用，允许一个服务像调用本地函数一样调用远程服务的函数，通常 RPC 都会配合注册中心（服务注册和服务发现）进行使用。公司所用到 RPC 主要有两种：Dubbo+Zookeeper，Feign+Eurake

如何测试？

Dubbo+Zookeeper

1. 测试调用： 在 Dubbo 消费者中调用 Dubbo 服务提供的接口方法，验证 Dubbo 微服务之间的通信是否正常。可以测试不同参数情况下的调用，以及处理异常情况的能力。

2. 性能测试： 可以使用性能测试工具对 Dubbo+Zookeeper 微服务进行性能测试，模拟大量并发请求，测试系统的性能和稳定性。

3. 集成测试： 对于涉及多个微服务之间的 RPC（Dubbo+Zookeeper）通信场景，进行集成测试。在测试环境中模拟真实的 RPC（Dubbo+Zookeeper）通信场景（业务场景）。验证微服务之间的通信是否正常，以及对于各种请求情况是否能正确响应。（譬如 mh-scs-biz 服务调用 erp 服务提供的 Dubbo 接口，来进行建单锁库存）

相关资料

dubbo 工具

Dubbo 接口测试 (胖虎总结)

dubborequests

Feign+Eurake

1. 测试调用： 在消费者微服务中调用 Feign 接口方法，验证 Feign+Eureka 微服务之间的通信是否正常。可以测试不同参数情况下的调用，以及处理异常情况的能力。

2. 性能测试： 可以使用性能测试工具对 Feign+Eureka 微服务进行性能测试，模拟大量并发请求，测试系统的性能和稳定性。

3. 集成测试： 对于涉及多个微服务之间的 RPC（Feign+Eurake）通信场景，进行集成测试。在测试环境中模拟真实的 RPC（Feign+Eurake）通信场景（业务场景）。验证微服务之间的通信是否正常，以及对于各种请求情况是否能正确响应。（譬如 mh-scs-admin 服务需要同步 PDM 数据，调用 MH-PDM-GOODSBIZ 服务提供的 Feign 接口，获取商品数据）

相关资料

Feign 接口测试 (后面再分享)

消息队列形式

概述

消息队列：使用消息队列可以实现异步通信，将消息发送到队列，其他服务可以从队列中获取消息进行处理。常见的消息队列包括 Apache Kafka、RabbitMQ 和 ActiveMQ 等。公司所用到的消息队列主要是 kafka(发布 - 订阅模式)，业务场景：拉新活动，用户 A 推荐用户 B 下单，用户 B 支付完成后，支付服务生产消息（告知用户 B 支付成功）用户服务消费消息（得知用户 B 支付完成，绑定推荐关系）

如何测试？

1. 测试生产消息： 在生产者微服务中发送测试消息到消息队列，检查是否能够成功发送消息，并且消息是否按预期进入消息队列。
2. 测试消费消息： 在消费者微服务中检查是否能够成功接收消息，并且消息的处理逻辑是否正确。
3. 测试并发处理： 在生产者微服务中发送多个并发消息，检查消费者微服务是否能够正确地处理并发消息，并且不会出现消息丢失或重复处理的情况。
4. 测试异常情况： 模拟消息队列连接中断、消息发送失败等异常情况，确保微服务能够正确处理这些异常，并具备消息重试和错误处理的能力。
5. 性能测试： 可以使用性能测试工具模拟大量消息的发送和接收，测试消息队列在高负载情况下的性能和稳定性。
6. 可靠性测试： 测试消息队列的可靠性，确保消息在不丢失和不重复的情况下进行传递。
7. 集成测试： 对于涉及多个微服务之间的消息队列通信场景，进行集成测试。在测试环境中模拟真实的消息队列通信场景（业务场景）。验证微服务之间的通信是否正常，以及对于各种请求情况是否能正确响应。（譬如WMS 对接 UMSMH-WMS 系统提交装箱记录时，发送 UMS 消息，在小屋 APP 展示卡片 - 工具已安排，这里我们可以模拟生产消息给 UMS 或者在页面上直接操作生产消息）

相关资料

模拟生产消息工具 (后面再分享)

学习一下 MQ(引用 TesterHome)

Redis 形式

概述

Redis 发布订阅（Publish/Subscribe）是一种消息传递模式，允许不同的微服务之间通过 Redis 作为消息中间件进行通信。在这种模式下，一个微服务（发布者）可以向特定的频道（Channel）发布消息，而其他微服务（订阅者）可以订阅这些频道，接收并处理发布者发送的消息。业务场景：司机承运物料进行出库，mh-scs-biz 服务，司机端操作承运出车之后，mh-scs-biz 服务作为发布者，往 Redis 中推送承运出车的物料申领单单号，mh-scs-admin 服务作为订阅者，订阅该消息，有数据就执行逻辑，进行自动出库。

如何测试？

1. 测试发布消息： 在发布者微服务中发布消息到 Redis 频道，检查消息是否成功发布到频道中。
2. 测试接收消息： 在订阅者微服务中检查是否能够成功接收到发布者发布的消息。
3. 测试多个订阅者： 在测试中增加多个订阅者微服务，检查是否所有订阅者都能够接收到相同的消息。
4. 测试订阅/取消订阅： 测试订阅者微服务可以成功订阅和取消订阅 Redis 频道，检查是否能正确处理订阅和取消订阅操作。
5. 测试并发订阅： 模拟多个订阅者同时订阅 Redis 频道，检查是否能够正确处理并发订阅操作。
6. 测试消息传递时间： 测试消息发布后，订阅者能够尽快收到消息，检查消息传递的延迟情况。
7. 测试错误处理： 测试异常情况下的处理能力，如网络中断、连接超时等，确保订阅者能够正确处理这些异常情况。
8. 性能测试： 可以使用性能测试工具模拟大量消息的发布和订阅，测试 Redis 发布订阅在高负载情况下的性能和稳定性。
9. 集成测试：对于涉及多个微服务之间的 Redis 发布订阅通信场景，进行集成测试，在测试环境中模拟真实的 Redis 发布订阅通信场景（业务场景）。验证微服务之间的通信是否正常，以及对于各种请求情况是否能正确响应。（譬如上述说的业务场景，司机端操作承运出车后，物料申领单自动出库，状态变更）

项目内部共享公共方法

概述

看到上图，其实供应链系统是一整个项目工程（mh-scs-parent）里面拆分了三个微服务（mh-scs-admin、mh-scs-biz、mh-scs-wms）因为在同一个项目工程里（同一个库表），所以这三个微服务之间的交互，可以通过公共方法进行交互，譬如 mh-scs-wms 服务需要计算配置物料的数量，但是计算配置物料这段逻辑是写在 mh-scs-admin 里面的，那我们需要把计算配置物料这段逻辑抽取到 mh-scs-common 公共包，这样就实现了 mh-scs-admin、mh-scs-wms 这两个微服务可以调用。

共享公共方法优点

1. 代码重用： 不同的微服务可以共享相同的功能代码，避免重复编写相同的逻辑，提高代码复用率。
2. 一致性： 共享公共方法可以保证相同的功能在不同微服务中实现的一致性，避免了因为不同开发团队开发不同实现而导致的功能不一致性。
3. 维护性： 将公共方法独立出来，可以更方便地对公共功能进行维护和升级，降低维护成本。
4. 开发效率： 开发人员可以专注于业务特定的功能，而不用关注公共功能的实现，从而提高开发效率。

如何测试？

1. 编写单元测试：针对每个公共方法编写单元测试。单元测试是针对代码的最小可测试单元，可以独立运行，并且对公共方法的各个功能进行测试。确保公共方法在不同输入情况下都能正确运行，并返回预期的结果。
2. 集成测试： 如果公共方法涉及与其他服务或组件的交互，可以进行集成测试，确保公共方法与其他部分正常协作。（这里需要盘点影响范围、所涉及功能模块、进行回归测试）

总结

在测试微服务之间的交互场景时，需要考虑正常场景和异常场景，并尽可能覆盖各种情况，确保系统在真实环境中能够稳定运行。同时，对于涉及多个微服务的集成测试，需要仔细评估影响范围，并进行适当的回归测试，以保证整个系统的稳定性和一致性。