微服务接口测试工具（服务端接口测试）

本篇文章给大家谈谈微服务接口测试工具，以及服务端接口测试对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务接口测试工具的知识，其中也会对服务端接口测试进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、红河java培训学校告诉你微服务架构开发的工具都有哪些？
• 2、微服务接口测试之mock测试
• 3、什么是 Mock 测试？
• 4、微服务基准测试：Chronicle Queue比Kafka快750倍？
• 5、微服务初体验（二）：使用Nacos作为配置中心并集成Dubbo

红河java培训学校告诉你微服务架构开发的工具都有哪些？

关于微服务架构的文章相信大家应该看过不少了，其中关于微服务的架构技巧以及开发工具的介绍也有很多。今天，红河电脑培训http://www.kmbdqn.cn/就给大家汇总了一下，其中适合微服务架构的工具都有哪些种类，一起来了解一下吧。

API管理和测试

1.APIFortress

APIFortress是API测试和健康检测工具，为企业级API提供自动化的功能测试、健康检测和负载测试。它的设计原则是无代码，完全基于现代API架构实践和模式而构建。

2.Postman

Postman是面向个体开发者和团队的API开发套件，可让你轻松运行UI驱动的API测试。Postman还是一个功能强大的HTTP客户端，让RESTfulAPI探索变得轻而易举。用户可以将简单和复杂的HTTP请求组合在一起，实现快速的API测试、开发和文档化。

3.Tyk

Tyk是一款开箱即用的开源API管理平台，速度快，可伸缩。无论是部署在内部，还是部署在云端，或者使用两者的混合，对Tyk来说都不在话下。除了可以降低管理成本，Tyk还将为你带来高可用性和低延迟。

消息服务

4.RabbitMQ

RabbitMQ可作为微服务之间的通信桥梁，它支持各种模式，可提高应用程序的可伸缩性，并解决大多数分布式系统都存在的问题。RabbitMQ可用在微服务环境或任何其他分布式系统中。你还可以使用这个工具在服务之间交换事件。

5.亚马逊简单队列服务(SQS)

亚马逊SQS提供了强大、灵活且可靠的微服务通信机制。作为一种基于发布订阅的微服务通信模型，亚马逊SQS可以帮助开发人员解决很多问题。除了更好的安全性之外，队列还通过为待处理消息提供储存来增强可靠性。

6.ApacheKafka

消息队列对于微服务架构来说是非常重要的，可用来处理微服务之间的通信以及微服务与外部源之间的通信，不管是密集型的数据处理还是API调用。ApacheKafka是一个具有高容错和弹性的分布式流处理平台。

微服务接口测试之mock测试

微服务微服务接口测试工具的接口测试微服务接口测试工具，一般都是使用restful接口。微服务的接口测试主要是通过调用各个服务的接口进行测试。Mock服务想要达到的目的就是微服务接口测试工具：被测服务A不被其微服务接口测试工具他服务所限制，只要被测服务A能走完流程，就可以完成这个接口测试。这个时候就需要用到mock服务，把其他服务用mock服务来替代。

python有个关于mock服务的框架：mock框架。
初学者： https://github.com/dreamhead/moco
mock框架： https://pypi.org/project/mock/

在选择好mock框架后，需要的注意事项：

什么是 Mock 测试？

作为动词，Mock 是模拟、模仿的意思。

作为名词，Mock 是能够模仿真实对象行为的模拟对象。

那么，在软件测试中，Mock 所模拟的对象是什么呢？

模拟的是 SUT（System Under Test：被测系统） 的依赖，而不是其本身。

比如，我要测试 A，但 A 依赖 B，要模拟的对象就是 B。

为什么要模拟 B 呢？

提高 A 的测试覆盖率： 通过 Mock 模拟 B 返回的正常和异常的结果，使用 A 的测试更充分。

避免 B 的因素对 A 产生影响： 当 B 因各种原因无法正常使用时，导致 A 无法测试。

提高 A 的测试效率： B 的真实行为可能很慢，但模拟可以很快。

Mock 的两大功能：

记录真实的调用信息

生成模拟的返回信息

使用 Mock 的问题是什么？

可能导致问题遗漏： 毕竟是模拟的，是理想可预见的情况，真实的情况可能更复杂。

可能导致维护成本变高： 接口变更 Mock 用例要跟着改，改错和漏改都可能出问题。

常见的 Mock 类型：

方法级别： Mock的对象是一个函数调用，例如：获取系统环境变量。

类级别： Mock 的对象是一个类，例如：一个 HTTP server。

接口级别： Mock 的对象是一个 API 接口。

服务级别： Mock 的对象是整个服务。

使用 Mock 做接口测试时，一般分二步：

1. 打桩： 创建 Mock 桩，指定 API 请求内容及其映射的响应内容。

2 . 调桩： 被测服务来请求 Mock 桩并接收 Mock 响应。

在这二步之间还有一个 Mock 桩的注入 ， 啥是 Mock 注入？

Mock 的本质就是用模拟桩来替换真实的依赖。所谓 Mock 桩注入 就是 阻断被测服务与真实服务之间的链路，建立被测服务与 Mock 之间的链路过程。

如下图所示：
常见的方式包括但不限于以下五种：

API 请求构造

客户端 Mock：在被测服务 内部 工作，直接拦截被测服务的 API 请求方法，直接从方法内部返回预定义的 Mock 响应。

服务端 Mock：在被测服务 外部 工作，作为 HTTP 服务器接收被测服务发送的 API 请求，并返回预定义的 Mock 响应。

本地配置：

对于服务端 Mock，打桩之后会生成唯一的 Mock 桩地址，被测服务提供一个依赖服务地址配置项，在需要使用 Mock 时将依赖服务地址修改成 Mock 地址。

配置中心

对于服务端 Mock，为了避免修改依赖服务地址配置项导致被测服务重启，可以采用配置中心存储和管理依赖服务地址配置，或者使用注册中心记录服务与服务地址的映射关系。

反向代理

在微服务架构下，被测服务与依赖服务之间可能不是直连的，而是经过了一层反向代理，例如 API 网关。在这种情况下，被测服务是通过调用 API 网关来间接调用依赖服务的接口。

前向代理

服务端 Mock 除了作为 HTTP 服务器，还可以兼备 HTTP 代理的功能，这种架构又叫做 Mock 代理。

对比：
常用 Mock 工具：

单元测试级别：

easymock、jMock、Mockito、Unitils Mock、PowerMock、JMockit..

接口测试级别

Wiremock、Mockserver、Moco、Mock.js、RAP...

微服务基准测试：Chronicle Queue比Kafka快750倍？

比较 Chronicle Queue 和 Apache Kafka 的一个有趣的基准测试，请注意：对于极其重视低延迟应用程序，kafka 可能不是最佳适合工具，Kafka适合高吞吐量和大数据可扩展的应用。

Apache Kafka 是服务间通信的常见选择。Kafka便于消息的并行处理，是日志聚合的不错选择。Kafka号称是低延迟、高吞吐量。但是，对于云中的许多 微服务 应用程序，Kafka 是否足够快？

当我编写Chronicle Queue Open Source时，我的目标是开发一个具有微秒延迟的消息传递框架，世界各地的银行都将其用于延迟敏感的交易系统。

在本文中，我将描述 Kafka 如何在吞吐量方面不像微服务应用程序的 Chronicle Queue 那样容易扩展。即使在吞吐量较低的情况下，Chronicle Queue 的速度也提高了大约 750 倍。

使用 Chronicle 的微服务延迟 ： 在 500 kmsg/s 时，Chronicle Queue Enterprise 的 99%ile 单个微服务端到端延迟为 3.69 微秒

使用 Kafka 的微服务延迟：使用 Kafka 进行相同的测试，但在 100 kmsg/s 的较低吞吐量下，99%ile 单阶段微服务端到端延迟约为 2633 微秒（从 150kmsg/s 开始，延迟急剧增加）。

Kafka 最初是为日志聚合而设计的。它有许多连接器，对于这个用例，它做得很好。我测量了良好的结果，表明使用 Kafka 代替典型系统中的日志文件写入可以提高性能并显着提高可管理性。

测试场景

在每种情况下，使用相同的测试硬度。一切都部署在运行 Ubuntu 21.04 的 Ryzen 9 5950X 上。所有测试均使用相同的 MP600 PRO XT 2TB M.2 NVMe 驱动器。基准测试的来源可在此处获得。https://github.com/OpenHFT/Microservice-Benchmark

对于微服务基准测试：

注意：生成的每条消息都会创建第二条消息作为响应，因此与单跳消息传递基准相比，实际消息数量翻了一番。

.....

更多点击标题见原文图表

结论：

虽然 Kafka 是日志聚合的不错选择，但由于其相对较高的端到端延迟，对于许多涉及微服务的用例而言，它的延迟可能不够低。

Chronicle Queue 开源在超过 99.99% 的时间内实现了低于 100 微秒的一致延迟，而 Kafka 即使在吞吐量的 1/5 时也有 7 毫秒的异常值。

Chronicle Queue Enterprise 具有其他功能，可在超过 99.99% 的情况下将延迟与低于 10 微秒的延迟保持一致。

原文链接在下面链接中寻找：

Chronicle Queue比Kafka比快750倍？

微服务初体验（二）：使用Nacos作为配置中心并集成Dubbo

首先启动Nacos，按照上篇文章的步骤，启动Nacos服务和项目，访问Nacos的web页面。确保项目中的服务都注册到注册中心当中了。在application.yml同级目录下添加bootstrap.yml，在Spring boot项目中bootstrap.yml会比application.yml优先初始化，所以我们需要在bootstrap.yml中引入Nacos官方指定的配置文件即可（上篇文章中已经把Nacos作为配置中心的配置写入了application.yml，现在只需要把它从applicaiton.yml中剪切出来即可， 其中的spring:application:name会作为Nacos中新增配置时的Data ID，需要留意 ），再新增属性gorup进行分组测试，如下图

接着打开Nacos的服务的web页面，打开配置管理-配置列表，点击右侧新增按钮，进行新增。
Data ID： bootstrap.yml配置文件中spring:application:name对应的名称 ；
Group：指定分组（便于不同环境下的项目配置管理，因为笔者这里属于测试，所以填写的是和上文中的配置文件中group对应的test一致）；
描述：针对于该配置的描述；
配置格式：配置文件的格式，要和Data ID中的后缀格式一致（这里笔者用的是yml，那么下面就选择yaml，注意该位置也可以选择properties，但是必须和上面bootstrap.yml文件中的file-extension的值相匹配）；
配置内容：具体的配置内容（这里笔者将项目中的application.yml中的配置全部拷贝至其中）；

测试启动consumer服务，在application.yml中为空的时候，项目启动端口还是如Nacos配置中的9011，说明项目依赖Nacos的配置中心成功，其他服务如法炮制即可：

新增一个测试Controller，然后加上@RefreshScope注解，表明该Controller中的配置数据为自动刷新 。

编辑Nacos中的配置文件consumer新增相关参数type: test，访问Controller，返回test。效果如下图：

将Nacos中consumer.yml文件的type: test修改为type: prod，在不重启项目的情况下重新访问对应的controller，效果如下图：

因为Dubbo是属于各个服务之间都要公用的依赖，所以将其引入cloud-common当中，详细的版本可以去 mvnrepository 搜索合适自己项目的

引入依赖后需要编写消费者服务中的配置文件，将Dubbo服务注册至Nacos，新增如下内容，其中subscribed-services指的是生产者服务，prot：-1指的是端口随机，registry:address:指的是Dubbo对应的注册中心那这里就应该设置为Nacos

接下来新增接口服务，项目类型为Maven项目，在项目中新增一个接口。并在cloud-provider（生产者）和cloud-consumer（消费者）pom.xml文件中都引入该模块

在生产者实际服务中实现该接口对应的方法

在服务消费者的Controller中引入该Service，并在该Service上加入@Reference注解，注意在引入jar包的时候选择带有Dubbo的，不要使用Jdk原生的

编写消费者服务中测试Dubbo调用的接口，进行测试，测试结果如下图：

关于微服务接口测试工具和服务端接口测试的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务接口测试工具的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于服务端接口测试、微服务接口测试工具的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。