[Editor's note] The author of this article is David Buschman. Starting from the development process of program architecture and system, the article gradually demonstrates why reactive programming is not a temporary trend, but a future that can bring faster processing speed and higher hardware utilization. choose. The article is compiled and presented by OneAPM , the domestic ITOM management platform .
There have been many changes in program architecture and systems over the years. In most cases, these changes are closely related to the hardware on which they are based. Where exactly software architecture originates is debated, and there are various definitions of what actually constitutes an architecture. This article will discuss the rise of monolithic applications.
Moore's Law
When all your resources are on a single machine, having all your code in one place makes sense and is the gold standard for software design. This pattern continued until the J2EE era and the emergence of the monolithic application container. J2EE was designed to take full advantage of Moore's Law, as this is the best way to design single-core CPU systems that are getting larger and larger.
Moore's Law refers to the observation that over the history of computer hardware, the number of transistors on a dense integrated circuit has doubled roughly every two years.
This architecture has been the gold standard for decades, because if we were to measure a system, we would "stack" more hardware on it. Add a faster CPU and more memory to increase the speed of your application. This is what Moore's Law calls applications.
The rise of multicore processors
Just a few years ago, CPU makers started running into bottlenecks in CPU design and speed. There's no way they can speed up a single-core CPU. To solve this problem, chip makers began to "play it big", adding several cores to a chip to get more acceleration. This means that the old method of adding a higher clock speed CPU to a J2EE application to speed things up doesn't work anymore. If CPUs can't get any faster, how can applications scale with a new generation of multi-core processors? Changes must be made to how existing applications are designed and run to remain competitive.
而且，事实证明，Java 企业级应用程序的同步和阻塞 IO 构架并不能充分利用这些新处理器的所有核。主要原因是它们的线程模型是“一个请求一个线程”，由于阻塞 I/O 命令，无法工作，这些线程要耗费大量时间来“等待 IO”。
阿姆达尔定律
这时候，阿姆达尔定律就开始发挥作用了。在目前的处理器中，该定律是现代新构架的驱动力。现在有了更多核，就需要找到办法来充分利用我们购置的这些 CPU。要实现这一点，需要减少应用程序使用非阻塞 I/O 命令带来的“IO 等待”时间。这对过去几十年的运行模式而言是一个彻底的改变。
Java 企业级应用程序和一个请求一个线程模型
显然，Java 企业构架是在单核 CPU 盛行时设计的。它对发送到服务器的请求采用“一个请求一个线程”思维方式。一旦你的请求获得一个线程，这个线程就会持续该请求的整个处理过程。在这种空间常用的函数库甚至依赖这种模型才能使用，例如 Hibernate 和 Spring Security。两个库都使用“Thread-local”参数来保持“session”状态，因为它们知道同一个线程会持续一个请求的整个周期。这样做的重大不利影响就是“behavior”不能更改，否则就会破坏现在使用的大部分 JEE 程序的数据持久性和应用安全代码。
Lightbend 和响应式宣言
Lightbend 公司（前身是 Typesafe）发布了响应式宣言，以记录未来软件设计时需求的变化，以及当代多核 CPU 在未来世界的扩展性。这种范式转变太过巨大，因此很难简单说清两种构架风格之间的真正不同，就如同拿苹果跟橙子做对比一样。这种转变在行业内带来了一些混乱，而且还会持续下去，直到完成过渡，找到让多核 CPU 充分发挥潜力的方法。
该宣言列出了构架系统时应该着重考虑的四条原则，以便新系统能够满足所需的处理水平。其中有两个概念直接适用于解决 Java 企业应用程序的问题，就是非阻塞 I/O 和非同步处理。如果两项都做好了，应用程序可以占用更少的 CPU 和内存需求，完成更多任务，从而在任何一个系统、同样的硬件基础上，获得比 Java 企业应用程序更好的处理效果。下图展示了这种并行处理的好处。
更快，更好，成本更低
这种新的软件架构新方法带来了更短的处理时间和更高的硬件利用率，从而降低了运营成本。现在运行的很多大型系统都是基于响应式宣言及其原则打造的。LinkedIn、Twitter、Facebook 等很多企业使用的系统都是基于非同步和非堵塞 I/O 技术架构，因此他们的应用程序得以优化，能够最大化地利用硬件资源。这是打造可扩展型应用程序的新方法，而且正在迅速发展。“响应式方法”并非一时之势——它是编写软件的未来趋势。
OneAPM能为您提供端到端的 Java 应用性能解决方案，我们支持所有常见的 Java 框架及应用服务器，助您快速发现系统瓶颈，定位异常根本原因。分钟级部署，即刻体验，Java 监控从来没有如此简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
原文地址： https://dzone.com/articles/why-reactive-programming-is-not-a-fad