為什麼響應式程式設計並非一時之勢？

【編者按】本文作者為 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