爲何響應式編程並不是一時之勢？

【編者按】本文做者爲 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