“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请求，响应都一模一样。这是为了对比测试。
因为：没有对比，就没有伤害
背景说明：
-
两个服务都部署在相同的服务器上，配置一模一样
-
数据库使用Docker安装，未进行任何配置上的优化，这个对两种模式都是一样的
-
Java + Spring部署时做了一些优化：
-
基于传统线程模式，将系统最大允许线程数设置的足够大
-
使用数据库连接池配置，连接池数为1500 （事实上在连接池为50的时候，压力测试无法进行，一压就全是报错）
-
·将日志级别调整为error，减少日志输出
-
数据写入性能测试对比
所有性能测试都是在Vultr云服务器上完成的。因为它的按使用时间计费比较方便，用完就销毁。
压测部署图
网关X性能数据 (基于Kotlin + Vert.x)
**并发数：200000 (20万) ** （以每秒发送2000个请求，不断循环的模式产生的总并发数）
TPS/秒： 4931.1/s
平均响应时间： 333ms
成功率： 100%
并发数：280000 (28万)
TPS/秒： 3926.6/s
平均响应时间： 466ms
成功率： 100%
**并发数：360000 (36万) **
TPS/秒： 4933.9/s
平均响应时间： 549ms
成功率： 100%
模拟项目的性能测试（基于Java + Spring Boot)
并发数：20000 (2万)* （以每秒发送2000个请求，不断循环的模式产生的总并发数）
TPS/秒： 593.6/s
平均响应时间： 1423ms
成功率： 100%
**并发数：30000 (3万) **
TPS/秒：634.0/s
平均响应时间：2091ms
成功率：100%
并发数：40000 (4万)
TPS/秒： 618.8/s
平均响应时间：2875ms
成功率： 100%
事实上，从压测数据上可以看出，两者的性能都不在同一个数量级上。压测Vert.x是从20万起步压测，而传统的Spring做不到，只能从2万起步。20万整个程序直接无响应。
网络请求性能测试数据
这个测试，只针对 myddd+vert.x模式做了测试，因为有了前面的测试，也没有必要再整个传统模式来对比了。（主要是懒，要时间）
注：
为了真实有效的反馈网关X的性能，远程服务并未使用真实的企业微信或我们的产品等，而是MOCK了一个实现，在保障其性能足够高效的情况下以验证网关X项目的性能
性能数据 (基于Kotlin + Vert.x)
**并发数：120002 （12万） *** （以每秒发送2000个请求，不断循环的模式产生的总并发数）
TPS/秒： 3762
平均响应时间： 391
成功率： 100%
并发数：240002
TPS/秒： 4015
平均响应时间： 435
成功率： 100%
并发数：360002 （36万）
TPS/秒： 3994
平均响应时间：451
成功率： 100%
...
并发数：1200002 (120万)
TPS/秒： 4019
平均响应时间：484
成功率： 100%
省略了中间一些数据，因为大致差不多，性能测试的过程中并发数从小到大增加，但其TPS与平均响应时间都在稳定的范围内。
初步结论
当然，我的测试并一定全面，只是抽取了项目中的几个点来测试，但我认为基于自己的测试数据与TeahEmpower的权威测试结合来说，已经足以说明Vert.x强大的性能表现了。
相比传统的Java + Spring同步编程模式，Vert.x这种异步编程模式的性能优势是难以置信的。不要说传统TO B项目，就算是TO C互联网项目应对也绰绰有余。
当然，软件的世界没有银弹，凡事有利就有弊，你有没有做好迎接异步编程的挑战呢？
相伴，未来的前行
经过这个项目的实战，我的myddd-vert.x也增加及完善了挺多功能。也将孵化出第一个版本了。
当前阶段的框架的Sonar数据
我相信未来很长一段的时间内，我都将与其相伴。
