Reactive 模式優(yōu)勢(shì)與實(shí)戰(zhàn)

Vert.x 采用 Actor 的模型簡(jiǎn)化了多線程的編程。圖靈獎(jiǎng)得主、面向?qū)ο缶幊?/a>之父 Alan Kay 曾經(jīng)這樣描述面向?qū)ο螅?/p>

我在描述“面向?qū)ο缶幊?/a>”時(shí)使用了“對(duì)象”這個(gè)概念。很抱歉這個(gè)概念讓許多人誤入歧途，他們將學(xué)習(xí)的重心放在了“對(duì)象”這個(gè)次要的方面。真正主要的方面是“消息”。

幾十年前，Carl Hewitt 提出了 Actor 模型，將其作為在高性能網(wǎng)絡(luò)中處理并行任務(wù)的一種方法。如今隨著硬件條件的發(fā)展，產(chǎn)生了很多面向?qū)ο鬅o(wú)法解決的挑戰(zhàn)，Actor 模型的思想重新進(jìn)入人們視野，并以一種新的思路解決了多線程多 cpu 環(huán)境下的并發(fā)問(wèn)題。

Vert.x 是一個(gè)事件驅(qū)動(dòng)的框架，底層使用 Netty 作為 I/O 庫(kù)保證性能 。Vert.x 采用了簡(jiǎn)單的并發(fā)模型，所有代碼都運(yùn)行在單線程中，避免多線程編程可能出現(xiàn)的并發(fā)問(wèn)題、狀態(tài)共享、以及各種鎖的處理，同時(shí)每個(gè) actor 模型獨(dú)立天然符合分布式的部署和支持高可用 (HA)。

與 Node.js 的 Eventloop 類似，在 Vert.x 的線程模型中，同樣也有 Eventloop 的概念。但相比于單線程的 Node.js，Vert.x 設(shè)置了一個(gè) Eventloop 線程池，來(lái)發(fā)揮多核處理器的性能。通過(guò)在代碼中定義 Verticle——一種 actor 的實(shí)現(xiàn)，使業(yè)務(wù)代碼和 Verticle 綁定，而每個(gè) Verticle 會(huì)綁定到一個(gè) Eventloop 線程上，只要不阻塞 Eventloop 線程，就可以源源不斷的處理新事件從而最大程度利用計(jì)算資源。當(dāng)遇到耗時(shí)的長(zhǎng)任務(wù)時(shí)則可以交給額外的 Worker 線程執(zhí)行，避免 Eventloop 線程阻塞。基于 Verticle 來(lái)編寫(xiě)的業(yè)務(wù)代碼始終運(yùn)行在單線程中，加上基于回調(diào)機(jī)制可以實(shí)現(xiàn)天然的異步無(wú)鎖。

vert.x 的 actor 模型

tomcat 的同步線程模型

Java Chassis 的 Reactive 實(shí)踐

Java Chassis 是?Apache Service Comb?的一個(gè)子項(xiàng)目，提供了開(kāi)箱即用的 Java 微服務(wù)開(kāi)發(fā)框架 SDK，并在通信部分采用了基于 Vert.x 的 Reactive 架構(gòu)。目前已經(jīng)在華為應(yīng)用市場(chǎng)業(yè)務(wù)中廣泛應(yīng)用，在生產(chǎn)實(shí)踐中為高達(dá) 60w tps 的業(yè)務(wù)并發(fā)保駕護(hù)航。通過(guò)性能對(duì)比測(cè)試，業(yè)務(wù)采用 Reactive 異步模式之后，TPS 提升 43% 左右、RT 時(shí)延降低 28% 左右，CPU 占用降低 56% 左右，性能收益很大。

使用 Spring MVC 作為 web 框架的 Spring cloud，其底層實(shí)際上基于 Servlet 即采用 DipatcherServlet 來(lái)分發(fā)請(qǐng)求，需要運(yùn)行在 Tomcat 等 web 容器中。雖然 Servlet 3.1 以后的版本提供了對(duì)異步和 NIO 的支持，但也阻止不了最近幾年出現(xiàn)的一些新的 Reactive web 服務(wù)器試圖取代 Servlet 的地位，它們往往更加輕量級(jí)也更加靈活。Spring 也在去年推出了 Spring WebFlux 作為新一代的 Reactive web 框架可以做到代替 Spring MVC，但目前的主要應(yīng)用場(chǎng)景還是在網(wǎng)關(guān)，與 Spring cloud 集成后的表現(xiàn)并沒(méi)有特別搶眼。

Java Chassis 則采用基于 Vert.x 的 reactive 服務(wù)器，更加輕量級(jí)、線程模型更加友好，還提供了大量天然的異步 API、以及更多的協(xié)議支持，同時(shí)性能表現(xiàn)也更加出色。

Java Chassis 原生支持純 Reactive 異步模型，在異步模式下同一個(gè) Enventloop 線程中完成 I/O 以及業(yè)務(wù)的處理。同時(shí)，actor 的模型下代表著更少的線程數(shù)量可以做到更優(yōu)的性能：與 Tomcat 的默認(rèn) 200 個(gè)線程相比，Vert.x 默認(rèn)只開(kāi)啟兩倍 cpu 核數(shù)的 Eventloop 線程。從操作系統(tǒng)的計(jì)算成本角度上講，更少的線程數(shù)量意味著更少的上下文切換時(shí)間開(kāi)銷(xiāo)——在線程切換時(shí)，操作系統(tǒng)從用戶態(tài)切換為內(nèi)核態(tài)再切回用戶態(tài)。同時(shí)更少的線程數(shù)讓內(nèi)存中的線程私有棧信息也更少。

另外，Java Chassis 也為一些特殊需求的開(kāi)發(fā)者提供了對(duì) Tomcat 的兼容，通過(guò)簡(jiǎn)單配置即可部署到 Tomcat。

筆者通過(guò)在 4 核 8g 的機(jī)器壓測(cè)對(duì)比測(cè)試，數(shù)據(jù)結(jié)果顯示：

在調(diào)用鏈為單服務(wù) A->B 時(shí)，對(duì)比 Tomcat 同步模式和切換到基于 Vert.x 的 Reactive 模式，平均時(shí)延和并發(fā)處理能力都有大幅度的提升。理論上在實(shí)際生產(chǎn)環(huán)境中如果服務(wù)調(diào)用鏈更長(zhǎng)，服務(wù)中的同步操作越多，采用 Reactive 模式的優(yōu)勢(shì)會(huì)更大。詳細(xì)測(cè)試代碼以及數(shù)據(jù)已經(jīng)開(kāi)源，有興趣的讀者可以自行了解。

結(jié)論

Reactive 模式構(gòu)建的程序，不僅僅代表的是高 TPS 低 RT(時(shí)延)，其帶來(lái)的更直接的受益就是同等條件下更低廉的硬件成本。Java Chassis 作為 Reactive 在微服務(wù)領(lǐng)域的先行者，已經(jīng)通過(guò)在生產(chǎn)環(huán)境中的應(yīng)用積累了大量經(jīng)驗(yàn)。

但同時(shí)構(gòu)建 Reactive 模式的程序也為開(kāi)發(fā)者帶來(lái)更高的要求，面臨比同步更為復(fù)雜的編程模型，需要更好的處理好阻塞和寫(xiě)出更優(yōu)秀的異步代碼。

容器 架構(gòu)設(shè)計(jì) 運(yùn)維 大數(shù)據(jù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。