我曾经在1月底的时候因为一个随意的想法，去了解了下关于『响应式编程』的一些概念，并且无意间看到了Vert.x
当时的想法也比较简单，看下能不能给自己在后端找到一种新的编程模式，因为这几年我的工作重心其实是在移动端及前端上，再返回后端对我来说，是仍然使用Java+Spring的传统编程风格，还是重新选择实现一套全新的模式，都是可选项。
所幸，由于这些年自己不断的在各种开发语言及框架中打转，早已不抗拒任何新技术并欢迎及愿意尝试更好的技术，于是便决定基于Kotlin+Vert.x写一套基础框架尝试下。
这便是我与Vert.x的相遇。
在2月初时就完成myddd-vertx的雏形，于是在年初给自己定的2021年的个人技术目标的几点中就包括这一点：
在实际的项目中验证并使用myddd-vertx
于是大约从3月初起，正式开始使用myddd-vertx来实现这个项目。我把它在这里称之为网关X
网关X的背景简述
但两者的API并不一致，项目X就是用来屏蔽两者API的差异，提供一套一致的API给小应用调用，以便开发一次，支持在不同的平台上运行。
所以，它有点网关的概念。这就是网关X
我是在3月初开始这个项目，3月底就其实已经编码结束，本周对这个完成编码的项目做性能测试，其结果确实有点超出我的预料之外。
虽然之前在国外知名的性能比拼网站TeahEmpower中看过它的数据，知道它很好，但真正自己编写一个项目再来跑一下性能测试，感觉还是完全不同的。有一种耳听为虚，眼见为实的感觉
网关X的项目的性能测试其实应该包括两个维度：
一个维度是对其本身数据读写，也就是数据库存储这一块做性能测试另一个维度是对其的请求转发，类似网关性质的这个点做性能测试
这周，我对这两个维度都做了性能测试。
在对数据库写入做性能测试中，我使用了自己的myddd-backend框架（基于Java及SpringBoot的领域驱动框架）写了一个一模一样的数据写入业务，表结构，API请求，响应都一模一样。这是为了对比测试。
因为：没有对比，就没有伤害
背景说明：
1.两个服务都部署在相同的服务器上，配置一模一样2.数据库使用Docker安装，未进行任何配置上的优化，这个对两种模式都是一样的3.Java+Spring部署时做了一些优化：基于传统线程模式，将系统最大允许线程数设置的足够大使用数据库连接池配置，连接池数为1500（事实上在连接池为50的时候，压力测试无法进行，一压就全是报错）将日志级别调整为error，减少日志输出
压测部署图
网关X性能数据(基于Kotlin+Vert.x)
*并发数：200000(20万)*（以每秒发送2000个请求，不断循环的模式产生的总并发数）
TPS/秒：4931.1/s
成功率：100%
并发数：280000(28万)
TPS/秒：3926.6/s
*并发数：360000(36万)*
TPS/秒：4933.9/s
模拟项目的性能测试（基于Java+SpringBoot)
并发数：20000(2万)*（以每秒发送2000个请求，不断循环的模式产生的总并发数）
TPS/秒：593.6/s
*并发数：30000(3万)*
TPS/秒：634.0/s
并发数：40000(4万)
TPS/秒：618.8/s
事实上，从压测数据上可以看出，两者的性能都不在同一个数量级上。压测Vert.x是从20万起步压测，而传统的Spring做不到，只能从2万起步。20万整个程序直接无响应。
性能数据(基于Kotlin+Vert.x)
并发数：120002（12万）*（以每秒发送2000个请求，不断循环的模式产生的总并发数）
TPS/秒：3762
并发数：240002
TPS/秒：4015
并发数：360002（36万）
TPS/秒：3994
...
并发数：1200002(120万)
TPS/秒：4019
当然，我的测试并一定全面，只是抽取了项目中的几个点来测试，但我认为基于自己的测试数据与TeahEmpower的权威测试结合来说，已经足以说明Vert.x强大的性能表现了。
相比传统的Java+Spring同步编程模式，Vert.x这种异步编程模式的性能优势是难以置信的。不要说传统TOB项目，就算是TOC互联网项目应对也绰绰有余。
当然，软件的世界没有银弹，凡事有利就有弊，你有没有做好迎接异步编程的挑战呢？
经过这个项目的实战，我的myddd-vert.x也增加及完善了挺多功能。也将孵化出第一个版本了。