难以置信的性能优势，来自myddd-vert.x的性能测试报告

“Talk is cheap. Show me the code.” -- 英文版
事实胜于雄辩 -- 中文版

缘起，与Vert.x的相遇

我曾经在1月底的时候因为一个随意的想法，去了解了下关于『响应式编程』的一些概念，并且无意间看到了Vert.x

当时只是花了2天不到的时间，把官方文档大致从头到尾阅读了下，从文档上就觉得这个玩意非常好。第一印象是：简洁高效，又足够优雅。

当时的想法也比较简单，看下能不能给自己在后端找到一种新的编程模式，因为这几年我的工作重心其实是在移动端及前端上，再返回后端对我来说，是仍然使用Java Spring的传统编程风格，还是重新选择实现一套全新的模式，都是可选项。

所幸，由于这些年自己不断的在各种开发语言及框架中打转，早已不抗拒任何新技术并欢迎及愿意尝试更好的技术，于是便决定基于Kotlin Vert.x写一套基础框架尝试下。

由于是遵循DDD领域驱动编码理念而实现的，于是把它命名为myddd-vertx，myddd-vertx的第一个版本在年前休假的的时间中可能2周不到就出来了。

这便是我与Vert.x的相遇。

我在1月写过一篇文章为什么我会选择Vertx与Kotlin讲述了自己当时选择它们的心路历程，末尾我会附上文章链接

相知，在实际项目中的应用

在2月初时就完成myddd-vertx的雏形，于是在年初给自己定的2021年的个人技术目标的几点中就包括这一点：

•在实际的项目中验证并使用myddd-vertx

但我并没有意料到能在这么短的时间内能在公司的项目中用上myddd-vertx。对我而言，这真是一个绝佳的机会，因为这能够极快的验证与完善myddd-vertx

于是大约从3月初起，正式开始使用myddd-vertx来实现这个项目。我把它在这里称之为网关X

网关X的背景简述

我们公司有一套类似企业微信的产品WorkPlus，事实上我们的产品早于企业微信及钉钉等互联网产品，只是我们的知名度远不及上述公司。我们的产品主要是TO B。

企业微信与我们的产品类似，都有一套提供给第三方服务接入自己产品的API，举例来说：你可以基于我们的API或企业微信的API编写一个考勤的小应用。

但两者的API并不一致，项目X就是用来屏蔽两者API的差异，提供一套一致的API给小应用调用，以便开发一次，支持在不同的平台上运行。

所以，它有点网关的概念。这就是网关X

我是在3月初开始这个项目，3月底就其实已经编码结束，本周对这个完成编码的项目做性能测试，其结果确实有点超出我的预料之外。

虽然之前在国外知名的性能比拼网站TeahEmpower中看过它的数据，知道它很好，但真正自己编写一个项目再来跑一下性能测试，感觉还是完全不同的。有一种耳听为虚，眼见为实的感觉

题外话：关于性能测试这个事，我也有一些感触，因为感觉这个事首先在开发人员中不普遍，甚至我认定大多数公司可能从上到下都不太重视这个事情。所以我准备后续写篇文章: 性能测试这个事，谁的责任？ 敬请期待！！！

惊鸿一瞥，性能测试大比拼

网关X的项目的性能测试其实应该包括两个维度：

•一个维度是对其本身数据读写，也就是数据库存储这一块做性能测试•另一个维度是对其的请求转发，类似网关性质的这个点做性能测试

这周，我对这两个维度都做了性能测试。

在对数据库写入做性能测试中，我使用了自己的myddd-backend框架（基于Java及Spring Boot的领域驱动框架）写了一个一模一样的数据写入业务，表结构，API请求，响应都一模一样。这是为了对比测试。

因为：没有对比，就没有伤害

背景说明：

1.两个服务都部署在相同的服务器上，配置一模一样2.数据库使用Docker安装，未进行任何配置上的优化，这个对两种模式都是一样的3. Java Spring部署时做了一些优化： •基于传统线程模式，将系统最大允许线程数设置的足够大 • 使用数据库连接池配置，连接池数为1500 （事实上在连接池为50的时候，压力测试无法进行，一压就全是报错） • 将日志级别调整为error，减少日志输出