我所了解的微服务之间的交互

前言
微服务架构
微服务之间的交互

HTTP/HTTPS形式
RPC形式
消息队列形式
Redis形式
项目内部共享公共方法

总结

前言

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

微服务架构

微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把一个一个的微服务组合管理起来，对外提供一套完整的服务。
在这一架构下，产生这么一个业务场景，譬如订单服务有个订单返现金额计算（拉新活动），由于分库分表，订单服务不知道用户之间的关系，总不能直接跨库查询查出用户与用户的关系吧
跨库查询风险比较大

权限限制（跨库查询会使得敏感数据更加容易被泄露）
查询效率（使用联合查询语句，这会使得查询效率变慢）
事务管理（事务中跨越了多个数据库，将会增加事务的难度和复杂度）

微服务之间的交互

HTTP/HTTPS形式

概述

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

如何测试？

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

RPC形式

概述

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

如何测试？

Dubbo+Zookeeper

「测试调用：」 在Dubbo消费者中调用Dubbo服务提供的接口方法，验证Dubbo微服务之间的通信是否正常。可以测试不同参数情况下的调用，以及处理异常情况的能力。
「性能测试：」 可以使用性能测试工具对Dubbo+Zookeeper微服务进行性能测试，模拟大量并发请求，测试系统的性能和稳定性。
「集成测试：」 对于涉及多个微服务之间的RPC（Dubbo+Zookeeper）通信场景，进行集成测试。在测试环境中模拟真实的RPC（Dubbo+Zookeeper）通信场景（业务场景）。验证微服务之间的通信是否正常，以及对于各种请求情况是否能正确响应。（譬如mh-scs-biz服务调用erp服务提供的Dubbo接口，来进行建单锁库存）

「相关资料」

dubbo工具

Dubbo接口测试(胖虎总结)

dubborequests

Feign+Eurake

「测试调用：」 在消费者微服务中调用Feign接口方法，验证Feign+Eureka微服务之间的通信是否正常。可以测试不同参数情况下的调用，以及处理异常情况的能力。
「性能测试：」 可以使用性能测试工具对Feign+Eureka微服务进行性能测试，模拟大量并发请求，测试系统的性能和稳定性。
「集成测试：」 对于涉及多个微服务之间的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支付完成，绑定推荐关系）

如何测试？

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

「相关资料」

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

学习一下MQ(引用TesterHome)：https://testerhome.com/articles/30382

Redis形式

概述

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

如何测试？

「测试发布消息：」 在发布者微服务中发布消息到Redis频道，检查消息是否成功发布到频道中。
「测试接收消息：」 在订阅者微服务中检查是否能够成功接收到发布者发布的消息。
「测试多个订阅者：」 在测试中增加多个订阅者微服务，检查是否所有订阅者都能够接收到相同的消息。
「测试订阅/取消订阅：」 测试订阅者微服务可以成功订阅和取消订阅Redis频道，检查是否能正确处理订阅和取消订阅操作。
「测试并发订阅：」 模拟多个订阅者同时订阅Redis频道，检查是否能够正确处理并发订阅操作。
「测试消息传递时间：」 测试消息发布后，订阅者能够尽快收到消息，检查消息传递的延迟情况。
「测试错误处理：」 测试异常情况下的处理能力，如网络中断、连接超时等，确保订阅者能够正确处理这些异常情况。
「性能测试：」 可以使用性能测试工具模拟大量消息的发布和订阅，测试Redis发布订阅在高负载情况下的性能和稳定性。
「集成测试：」对于涉及多个微服务之间的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这两个微服务可以调用。

共享公共方法优点

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

如何测试？

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