为何响应式编程并不是一时之势？

【编者按】本文做者为 David Buschman，文章从程序架构与系统的发展历程出发，逐步论证了为何响应式编程并不是一时之势，而是能带来更快处理速度，更高硬件利用率的将来选择。文章系国内 ITOM 管理平台 OneAPM 编译呈现。

这些年来，程序架构和系统发生了很多变化。大部分状况下，这些变化都跟它们依托的硬件密切相关。软件架构究竟是从何处起源，众说纷纭，并且对构架的实际构成部分也有各类定义。本文将从总体化应用的兴起来展开讨论。

##摩尔定律 当你的全部资源都在单机上时，把全部的代码存在一个地方很合理，并且是软件设计的黄金标准。这种模式一直持续到 J2EE 时代，总体化应用容器的出现。J2EE 的设计初衷就是为了能充分利用摩尔定律，由于这是变得愈来愈庞大的单核 CPU 系统的最佳设计方法。

摩尔定律指的是一个观察发现：在计算机硬件发展史上，密集的集成电路上的晶体管数量大概每两年就会翻一倍。

这种构架做为黄金标准持续了几十年，由于若是咱们要衡量一个系统，就会往它身上“堆”更多硬件。添加更快的 CPU 和更多内存来提升应用程序的速度。这就是摩尔定律所说的应用程序。

##多核处理器的兴起 就在几年前，CPU 制造商开始在 CPU 设计和速度方面遭遇瓶颈。他们怎么都没办法给单核 CPU 提速了。为了解决这个问题，芯片制造商开始“尽情发挥”，在一个芯片上加了好几个核，以便得到更多加速的能力。这意味着过去那种给 J2EE 应用程序添加一个时钟速度更高的 CPU 来提速的老方法行不通了。若是 CPU 没法再提速，应用程序如何经过新一代的多核处理器来扩大规模呢？必须改变现有的应用程序设计和运行方式，才能保持竞争力。

并且，事实证实，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