vertx框架文章的翻译和个人批注

Posted 2021-04-12 George的旅行

本文是翻译一篇网上文章，该文章介绍了Vert.x与Spring boot框架的区别，我觉得非常适合入门理解。如果你对vert.x框架很困惑。这篇文章会是很好的入门解惑文章。在翻译的同时，我也增加了一些自己的批注。

文章链接如下，欢迎阅读英语原文。

https://vironit.com/comparison-of-web-frameworks-spring-boot-vs-vert-x/

部分翻译如下：

正如著名的俄国谚语所说，“一切新的东西实际上都是被遗忘的旧的”，异步应用程序就是一个典型的例子。是的，这种方法本身出现在很久以前，当时需要在单核处理器和旧体系结构上模拟任务的并行执行。但异步和并行其实是完全不同的概念。

尽管如此，异步在高负载、高速互联网服务中可以取得很好的应用，也就是当出现成千上万的客户同时请求服务的情况。也许您应该更好地对比一下spring boot和vert.x框架。

SpringBoot：采用多线程模型来处理。

这种模式大家都知道。我们的应用程序创建多个线程（形成线程池），每个线程获取任务和数据进行处理。任务并行执行。如果线程没有共享数据，那么我们就不会有同步的开销，这使得处理速度足够快。（批注：阻塞体系架构是一个请求对应一个线程。多个线程就形成池。这种方式，如果线程没有共享数据，各自处理，那么就会很快，但是如果有共享数据，那么某个线程处理时，另一个线程就会阻塞，那么就会慢）

处理完成后，线程不会被终止，而是位于线程池中，等待下一个任务。线程池避免了创建线程和删除线程的开销。基于这样的系统，web服务器可以与spring boot一起工作。每个请求都在自己的线程中工作。一个线程处理一个请求。

我们有相当多的线程，慢速请求会占用流很长一段时间，快速请求几乎立即被处理，从而释放流进行其他工作。这样慢速请求不会占用所有CPU时间，避免了会阻塞快速请求。

但这样的设计有一定的局限性。当我们遇到大量慢速查询（例如使用数据库或读取文件系统时，可能会出现这种情况），慢请求将覆盖所有线程，这将使执行其他请求变得不可能。（批注：多个线程确实解决了问题。当某个线程处理很慢的话，也就是阻塞的话，那么就会影响整体性能，特别是多个线程读文件的时候，其他线程都需要等待那个慢的线程，才能完成文件的读入）

即使请求只需要1毫秒就可以执行，它也不会被及时处理。这个问题可以通过增加线程的数量来解决，以便它们能够处理足够多的慢速请求。但不幸的是，线程是由操作系统控制的，CPU时间也要分配给操作系统。（批注：增加多个线程确实是很好的解决办法。但是线程需要操作系统创建，来回切换也占用CPU时间）

因此，我们创建的线程越多，处理它们的开销就越大，分配给每个线程的处理器时间就越少。spring框架本身会加剧这种问题：阻塞数据库操作、文件系统、输入输出也会占用cpu时间，而此时不执行任何有用的工作。流越多，成本就越多。因此，会出现宕机情况。宕机的次数取决于对数据库和文件系统的查询持续时间。

为了能够完全利用CPU，最佳解决方案是过渡到使用非阻塞操作的架构。（批注：创建多个线程确实解决了问题，这是很好的解决思路。但是每个线程仍旧是阻塞的结构，单个线程仍然需要等待任务处理完才可以。

阻塞==同步）

vert.x就是异步架构框架，也就是非阻塞操作的架构。