摘要：編者按本文作者為，文章從程序架構與系統的發展歷程出發，逐步論證了為什么響應式編程并非一時之勢，而是能帶來更快處理速度，更高硬件利用率的未來選擇。這就是摩爾定律所說的應用程序。響應式方法并非一時之勢它是編寫軟件的未來趨勢。

【編者按】本文作者為 David Buschman，文章從程序架構與系統的發展歷程出發，逐步論證了為什么響應式編程并非一時之勢，而是能帶來更快處理速度，更高硬件利用率的未來選擇。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。

這些年來，程序架構和系統發生了不少變化。大部分情況下，這些變化都跟它們依托的硬件密切相關。軟件架構到底是從何處起源，眾說紛紜，而且對構架的實際構成部分也有各種定義。本文將從整體化應用的興起來展開討論。

當你的所有資源都在單機上時，把所有的代碼存在一個地方很合理，而且是軟件設計的黃金標準。這種模式一直持續到 J2EE 時代，整體化應用容器的出現。J2EE 的設計初衷就是為了能充分利用摩爾定律，因為這是變得越來越龐大的單核 CPU 系統的最佳設計方法。

摩爾定律指的是一個觀察發現：在計算機硬件發展史上，密集的集成電路上的晶體管數量大概每兩年就會翻一倍。

這種構架作為黃金標準持續了幾十年，因為如果我們要衡量一個系統，就會往它身上“堆”更多硬件。添加更快的 CPU 和更多內存來提高應用程序的速度。這就是摩爾定律所說的應用程序。

就在幾年前，CPU 制造商開始在 CPU 設計和速度方面遭遇瓶頸。他們怎么都沒辦法給單核 CPU 提速了。為了解決這個問題，芯片制造商開始“盡情發揮”，在一個芯片上加了好幾個核，以便獲得更多加速的能力。這意味著過去那種給 J2EE 應用程序添加一個時鐘速度更高的 CPU 來提速的老方法行不通了。如果 CPU 無法再提速，應用程序如何通過新一代的多核處理器來擴大規模呢？必須改變現有的應用程序設計和運行方式，才能保持競爭力。

而且，事實證明，Java 企業級應用程序的同步和阻塞 IO 構架并不能充分利用這些新處理器的所有核。主要原因是它們的線程模型是“一個請求一個線程”，由于阻塞 I/O 命令，無法工作，這些線程要耗費大量時間來“等待 IO”。

這時候，阿姆達爾定律就開始發揮作用了。在目前的處理器中，該定律是現代新構架的驅動力。現在有了更多核，就需要找到辦法來充分利用我們購置的這些 CPU。要實現這一點，需要減少應用程序使用非阻塞 I/O 命令帶來的“IO 等待”時間。這對過去幾十年的運行模式而言是一個徹底的改變。

顯然，Java 企業構架是在單核 CPU 盛行時設計的。它對發送到服務器的請求采用“一個請求一個線程”思維方式。一旦你的請求獲得一個線程，這個線程就會持續該請求的整個處理過程。在這種空間常用的函數庫甚至依賴這種模型才能使用，例如 Hibernate 和 Spring Security。兩個庫都使用“Thread-local”參數來保持“session”狀態，因為它們知道同一個線程會持續一個請求的整個周期。這樣做的重大不利影響就是“behavior”不能更改，否則就會破壞現在使用的大部分 JEE 程序的數據持久性和應用安全代碼。

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