摘要：構(gòu)建于四個(gè)指導(dǎo)性的原則。在這個(gè)文章的其余部分我們將繼續(xù)深入異步邊界的概念。電商領(lǐng)域的一致性的重要性并不是碰巧出現(xiàn)的。性能持久性安全都是的方面。來(lái)見(jiàn)識(shí)下騎士資本集團(tuán)在年發(fā)生軟件故障的經(jīng)歷。接下來(lái)的分鐘發(fā)生的事情是一場(chǎng)惡夢(mèng)。

What is Reactive Programming?
為了了解Reactive——從編程范式至其背后的動(dòng)機(jī)，有必要了解現(xiàn)在的開(kāi)發(fā)者和公司在十年前不曾面對(duì)的挑戰(zhàn)。

游戲的改變主要有兩大方面：

硬件的提升
因特網(wǎng)
Why things are different now?
（原文對(duì)比了一遍2005年和2014年因特用戶的增長(zhǎng)：10億至29.5億；Facebook用戶的增長(zhǎng)：550萬(wàn)至13億； twitter從無(wú)至有，0至2.7億用戶）

時(shí)代改變了，現(xiàn)在一個(gè)網(wǎng)站就需要處理十年前整個(gè)因特網(wǎng)的流量。實(shí)下，容易發(fā)現(xiàn)軟件對(duì)于日常生活越來(lái)越重要。也容易發(fā)現(xiàn)，以前的一些范式并不再適用于現(xiàn)在，更不適用于將來(lái)。

The four Reactive principles
Reactive applications 構(gòu)建于四個(gè)指導(dǎo)性的原則。

目標(biāo)是一個(gè)responsive的程序
一個(gè)responsive的程序一定既scalable又resilent.responsiveness離開(kāi)了scalability和resilence是不可能實(shí)現(xiàn)的
一個(gè)message-driven的架構(gòu)是scalale, resilent以及最終實(shí)現(xiàn)responsive系統(tǒng)的基礎(chǔ)
讓我們?cè)诟邔恿私庀旅恳粋€(gè)原則，理解為了開(kāi)發(fā)一個(gè)適用于現(xiàn)在環(huán)境的軟件，為什么它們是缺一不可的。

Responsive
當(dāng)我們說(shuō)一個(gè)程序是"responsive"的時(shí)候，是在說(shuō)什么？

A responsive system is quick to react to all users — under blue skies and grey skies—in order to ensure a consistently positive user experience.

一個(gè)responsive的系統(tǒng)是對(duì)所有用戶都能快速反應(yīng)的——不管晴天陰天——來(lái)保證一個(gè)始終積極的用戶體驗(yàn)。

在各種條件下都“快速”而“積級(jí)”的用戶體驗(yàn)，比如外部系統(tǒng)出問(wèn)題或者流量激增，依賴于Reactive application的兩個(gè)特質(zhì)：resilence，以及scalability。一個(gè)消息驅(qū)動(dòng)架構(gòu)提供了一個(gè)responsive系統(tǒng)的基礎(chǔ)。

為什么消息驅(qū)動(dòng)架構(gòu)對(duì)于responsiveness如此重要？

這個(gè)世界是異步的。

假如你現(xiàn)在來(lái)杯咖啡，卻發(fā)現(xiàn)糖和奶油沒(méi)了。

一種做法是：

開(kāi)始煮咖啡
去商店買(mǎi)糖和奶沒(méi)
回家
啥都齊了，開(kāi)始喝咖啡
享受生活
另一種做法是：

去商店買(mǎi)糖和奶油
回家
煮咖啡
等著咖啡煮好
忍受咖啡因短缺
崩潰
就像你看到的，一個(gè)消息驅(qū)動(dòng)的架構(gòu)提供給你異步邊界(asynchronous boundary)，使你從時(shí)間和空間中解放出來(lái)。在這個(gè)文章的其余部分我們將繼續(xù)深入異步邊界的概念。（這段舉的例子挺好，可是看不出這個(gè)例子跟消息驅(qū)動(dòng)有啥關(guān)系呀）

Consistency at Walmart Canada 一致性之于加拿大亞馬遜
（譯注：這個(gè)一致性和分布式系統(tǒng)的一致性不一樣……）

在加入Typesafe公司之前，我是負(fù)責(zé)構(gòu)建亞馬遜加拿大的新電商平臺(tái)的Play和Scala團(tuán)隊(duì)的技術(shù)leader。

我們的目標(biāo)是提供一致的積極的用戶體驗(yàn)，不管：

無(wú)論什么類型的物理設(shè)備被用來(lái)訪問(wèn)walmart.ca，不設(shè)它是桌面電腦，平板還是移動(dòng)設(shè)備
當(dāng)前的流量峰值，不管它是由于激增才出來(lái)的，還是持久的
一個(gè)主要的基礎(chǔ)設(shè)施不可用，比如一整個(gè)數(shù)據(jù)中心。
響應(yīng)時(shí)間和整體的用戶體驗(yàn)必須保持一致，不管上面的情況是否發(fā)生。一致性對(duì)于你的網(wǎng)站是至關(guān)重要的，因?yàn)楫?dāng)下，這就是你的品牌。一個(gè)不好的用戶體驗(yàn)是難以被忘記或者忽略的，不管是發(fā)生在線上還是在一個(gè)線下的商店。

Responsive retail at Gilt
Gilt的Responsive零售。電商領(lǐng)域的一致性（的重要性）并不是碰巧出現(xiàn)的。比如Gilt也是一樣，Gilt是一個(gè)閃購(gòu)網(wǎng)站，每天中午當(dāng)他們發(fā)布了當(dāng)日的銷售商品時(shí)流量就會(huì)激增。

讓我考慮下一個(gè)閃購(gòu)網(wǎng)站的用戶體驗(yàn)。如果你在11：58訪問(wèn)了Gilt，12:01又訪問(wèn)了它。那么你希望兩次訪問(wèn)都有積極的體驗(yàn)，不管是不是Gilt在12:01那時(shí)候流量突增。

Gilt提供始終積極、responsive的用戶體驗(yàn)，并且通過(guò)Reactive來(lái)實(shí)現(xiàn)這一切。通過(guò)這篇ReadWrite interview with Eric Bowman of Gilt 了解Gilt向基于Scala的微服務(wù)架構(gòu)(Scala-based microservices architecture)的遷移。

Resilient
大部分的程序都被設(shè)計(jì)和開(kāi)發(fā)成適用于“晴天”，但是事情可能往壞的方面發(fā)展。每隔幾天就會(huì)有報(bào)告說(shuō)一個(gè)主要的應(yīng)用不可用，或者由于黑客的攻擊造成服務(wù)不可用、數(shù)據(jù)丟失、或者儲(chǔ)譽(yù)受損。

A resilient system applies proper design and architecture principles in order to ensure responsiveness under grey skies as well as blue.

一個(gè)彈性的系統(tǒng)采用了一些設(shè)計(jì)和架構(gòu)的原則，使得不管外部情況的好壞，都是responsive的

Java和JVM都是用來(lái)把一個(gè)程序無(wú)縫地布署到多個(gè)操作系統(tǒng)，類似的是，201x年的內(nèi)部互聯(lián)的應(yīng)用程序都是關(guān)于應(yīng)用程序?qū)蛹?jí)的組合、連接和安全。（注：這句有點(diǎn)繞……忽略，看下邊的）

現(xiàn)在的程序大都由一定數(shù)量的其它程序組裝而成，通過(guò)web service和其它網(wǎng)絡(luò)協(xié)議整合在一起?，F(xiàn)在一個(gè)應(yīng)用可能依賴于大量的其它服務(wù)——10，20或者更多，它所依賴的這些服務(wù)在自己的信賴防火墻(trust firewall)之外。它可能同時(shí)在為大量外部用戶提供服務(wù)——既包含人，也包括其它系統(tǒng)。

考慮到整合的復(fù)雜性，有多少開(kāi)發(fā)人員：

分析和建模所有外在的依賴
把整合進(jìn)的每個(gè)服務(wù)的理想響應(yīng)時(shí)間整理成文檔，進(jìn)行性能測(cè)試——在峰值和平?！獊?lái)全面評(píng)估最初的期望
把所有的預(yù)期，失敗情況和其它非功能的需求編碼到系統(tǒng)的核心邏輯中
分析和測(cè)試每個(gè)服務(wù)的失敗情形的影響
分析每個(gè)外部依賴的安全，識(shí)別是否整合這個(gè)外部依賴是否給系統(tǒng)帶來(lái)最的安全隱患
Resiliency is one of the weakest links of even the most sophisticated application, 但是Resilency作為一種事后的思考的情況很快就會(huì)終結(jié)。現(xiàn)代的程序必須在其核心就是resilent的，以保持在現(xiàn)實(shí)世界多變的環(huán)境下，而不只是理想情況下，保持responsive。 性能、持久性、安全都是resilency的方面。你的應(yīng)用必須在各個(gè)層次都是resilent的。

Message-driven resiliency
在一個(gè)消息驅(qū)動(dòng)的內(nèi)核之上構(gòu)建應(yīng)用的美妙之處在于你自然地得到了很多有價(jià)值的構(gòu)造模塊。

Isolation 隔離性是一個(gè)自愈(self-heal)的系統(tǒng)所需要的。當(dāng)隔離性在被恰當(dāng)?shù)厥褂?，我們可以依?jù)一些因素把不同類型的工作進(jìn)行分離，比如失效的風(fēng)險(xiǎn)、不同的性能、CPU和內(nèi)存的使用，等。一個(gè)isolation的組件的失效并不會(huì)影響整個(gè)系統(tǒng)的responsiveness, 并且給予了失效的那個(gè)系統(tǒng)一個(gè)被治愈的機(jī)會(huì)。

Location transparency 位置透明性使得我們與不同集群結(jié)點(diǎn)上的不同進(jìn)程間的通信就像與同一個(gè)VM的進(jìn)程內(nèi)通信一樣。

A dedicated separate error channel 一個(gè)精心設(shè)計(jì)的分離的錯(cuò)誤信息通道使得我們可以把錯(cuò)誤信號(hào)重定向到其它地方，而不是拋回到調(diào)用者面前。（注：這個(gè)作用應(yīng)該類型于Akka中的event stream這種東西，使得某些失敗的信息可以被訂閱，使得不光在當(dāng)前是調(diào)用了某個(gè)失敗組件的組件可以知道它失敗了，而是所有相關(guān)的組件都可以了解到這個(gè)情況，便于他們即是作出響應(yīng)）

這些因素幫助我們把健壯的錯(cuò)誤處理和容錯(cuò)合并進(jìn)我們的系統(tǒng)中。Akka的supervisor hierarchies的實(shí)現(xiàn)展示了這點(diǎn)。

消息驅(qū)動(dòng)架構(gòu)提供的這些核心的構(gòu)建模塊有助于resiliency，進(jìn)而有助于responsiveness——不僅在理想情況下，而且在各種并非理想的、現(xiàn)實(shí)世界的情況下。

The 440 million dollar resiliency mistake
來(lái)見(jiàn)識(shí)下騎士資本集團(tuán)在2012年發(fā)生軟件故障的經(jīng)歷（software glitch experienced by Knight Capital Group)。在一次軟件升級(jí)中，另一個(gè)休眠的、被整合在一起程序被不經(jīng)意地喚醒，并且開(kāi)始放大交易量。

接下來(lái)的45分鐘發(fā)生的事情是一場(chǎng)惡夢(mèng)。

騎士資本的自動(dòng)交易系統(tǒng)洪水般地向NASDAQ（注：納斯達(dá)克）進(jìn)行錯(cuò)誤交易，使得公司進(jìn)入了一個(gè)需要付出數(shù)十億美元代價(jià)的位置。事后，這家公司花了4.4億美元來(lái)扭轉(zhuǎn)局勢(shì)。在這個(gè)故障中，騎士資本不能停止泛水般的錯(cuò)誤交易，NASDAQ不得不終止騎士資本來(lái)停止這一切。騎士資本的股票在一天跌了63%, 幾乎不能做為一個(gè)公司存活了下來(lái)，只能等著它的股票恢復(fù)了一些價(jià)值之后被一些投資者接管。

騎士資本的系統(tǒng)是高性能的，但是不是resilent的。高性能但是沒(méi)有resilience使得問(wèn)題被放大，就像騎士資本發(fā)現(xiàn)的那樣。他們甚至沒(méi)有一個(gè)停止開(kāi)關(guān)來(lái)使得自己的系統(tǒng)在出現(xiàn)嚴(yán)重問(wèn)題時(shí)停止交易， 所以，當(dāng)真的出了問(wèn)題時(shí)，他們的自動(dòng)交易系統(tǒng)在45分鐘內(nèi)耗盡了整個(gè)公司的資本。

這就是設(shè)計(jì)和開(kāi)發(fā)只能用于"晴天“的程序的結(jié)果。如今，軟件是我們的私人生活和生意的關(guān)鍵組成。如果我們沒(méi)有為”陰天“的情況提前設(shè)計(jì)和準(zhǔn)備，那么即使這種情況只存在了不到一個(gè)小時(shí)，也會(huì)給我們?cè)斐删薮蟮膿p失。

Scalable
Resililency和Scalability手拉手，一起共建始終responsive的程序。

A scalable system is easily upgraded on demand in order to ensure responsiveness under varioius load conditions.

一個(gè)可擴(kuò)展的系統(tǒng)可以在面對(duì)不同的負(fù)載時(shí)輕松地進(jìn)行升級(jí)，來(lái)保證respnsiveness

任何一個(gè)在網(wǎng)上賣(mài)過(guò)東西的人都明白一個(gè)事實(shí)：你的流量最大的時(shí)候就是你賣(mài)的東西最多的時(shí)候。除非流量的突增是由于故意的黑客襲擊，不然期望流量突增是挺好的一件事。在一個(gè)突增的流量中，人們?cè)敢饣ㄥX(qián)給你。

那么如何面對(duì)這種流量突增，或者是一個(gè)長(zhǎng)久的但是大量的流量增長(zhǎng)。

首先選擇你的范式(paradigm)，然后選擇擁抱這種范式的語(yǔ)言和工具。很多情況下，開(kāi)發(fā)者只是簡(jiǎn)單地選擇語(yǔ)言和框架……。一旦選擇了工具，就很難改回來(lái). 所以，就像你在處理任何一個(gè)重大的投資一樣進(jìn)行這些決定。如果你的技術(shù)選擇基于一些原則和分析，那么你就已經(jīng)領(lǐng)先一步了。

Thread-based limitations to concurrency 基于線程的并發(fā)的不足
一個(gè)至關(guān)重要的技術(shù)選擇就是框架的并發(fā)模型。在較高的層次，有兩種并發(fā)模型：

傳統(tǒng)的基于線程的并發(fā)模型，基于調(diào)用棧和共享內(nèi)存
消息驅(qū)動(dòng)的并發(fā)
一些流行的MVC框架，比如Rails，是蔡于線程的。這類框架的典型特點(diǎn)包括：

共享的可變狀態(tài)
每個(gè)請(qǐng)求一個(gè)線程
對(duì)于可變狀態(tài)的并發(fā)訪問(wèn)——變量以及對(duì)象實(shí)例——使用鎖和其它復(fù)雜的同步結(jié)構(gòu)來(lái)進(jìn)行管理
這些特點(diǎn)結(jié)合動(dòng)態(tài)類型、解釋型語(yǔ)言比如Ruby，會(huì)迅速達(dá)到性能和擴(kuò)展性的上限。你可以認(rèn)為所有本質(zhì)是腳本語(yǔ)言的語(yǔ)言都是如此。

Out or up?
讓我們考慮擴(kuò)展一個(gè)應(yīng)用的不同方式。

向上擴(kuò)展(scaling up)是關(guān)于最大化的利用一個(gè)CPU/服務(wù)器的資源，通常需要購(gòu)買(mǎi)更強(qiáng)大的，專用的、更貴的機(jī)器。

向外擴(kuò)展(scaling out)是關(guān)于把計(jì)算分布到由廉價(jià)的commdity機(jī)器組成的集群中。這樣在成本上更劃算，但是如果你的系統(tǒng)是基于時(shí)間和空間概念的(注：”基于時(shí)間的“可以認(rèn)為程序的各個(gè)動(dòng)作是同步的，需要阻塞，等待，”基于空間的“可以認(rèn)為是基于一個(gè)進(jìn)程內(nèi)部的內(nèi)存共享，比如不線程間共享的變量)，那么向外擴(kuò)展就非常困難。 就像我們之前提到的那樣，一個(gè)消息驅(qū)動(dòng)的架構(gòu)提供了與時(shí)間和空間解耦合所需要的異步邊界(asynchronous boundary)，提供了按需向外擴(kuò)展(scale out on demand)的能力，這種能力也被叫做elasticity. Scaling up是關(guān)于更高效地利用已有的資源，而elasticity是關(guān)于在系統(tǒng)需要改變時(shí)按需增加新資源。能夠”scale out, on demand"的能力，就是Reactive programming在擴(kuò)展性方面的終極目標(biāo)。

Reactive應(yīng)用程序很難構(gòu)建于基于線程的框架之上，想想就知道把一個(gè)基于可變狀態(tài)，線程和鎖的的程序進(jìn)行scale out有多困難。開(kāi)發(fā)人員不僅需要利用單個(gè)機(jī)器上多核的優(yōu)劣，在某些時(shí)候，開(kāi)發(fā)者也需要利用計(jì)算機(jī)集群的力量。共享可變狀態(tài)也使得scale up變得困難，即使不是不可能。任何曾嘗試操作兩個(gè)線程共享的可變狀態(tài)的人都能夠理解保證線程安全有多復(fù)雜，并且也能夠理解為了確保線程安全所需要花費(fèi)的多余努力所帶來(lái)的性能上的懲罰。

Message-driven
一個(gè)消息驅(qū)動(dòng)的架構(gòu)是Reactive應(yīng)用程序的基礎(chǔ)。一個(gè)消息驅(qū)動(dòng)的程序可以是事件驅(qū)動(dòng)的(event-driven)，基于actor的(actor-based)，或者兩者的結(jié)合。

一個(gè)事件驅(qū)動(dòng)的系統(tǒng)基于事件，這些事件被一個(gè)或更多監(jiān)聽(tīng)者監(jiān)聽(tīng)。這和imperative programming不同，因此調(diào)用者不需要阻塞以等待被調(diào)用的例程的響應(yīng)。事件并不是被導(dǎo)向特定的地址，而是被監(jiān)聽(tīng)，我們將會(huì)更深入地討論其隱含的意義。

基于actor的并發(fā)是消息傳遞架構(gòu)的一種延伸，在基于actor的并發(fā)架構(gòu)中，消息可以跨越線程的邊界或者被傳遞到不同物理機(jī)器上的另一個(gè)actor的郵箱(mailbox)中。這使得elasticity——scale out on demand——變得可能，因?yàn)閍ctor可以被分布到網(wǎng)絡(luò)的各處，但是仍然可以像他們?cè)谕粋€(gè)VM里一樣通信。

消息和事件的不同在于消息是有方向的，而事件只是”發(fā)生“并沒(méi)有方向。消息有一個(gè)清晰的目的的，而event可以被一個(gè)或者多的監(jiān)聽(tīng)者監(jiān)聽(tīng)。

讓我們深入探討下事件驅(qū)動(dòng)和基于消息的并發(fā)。

Evnt-driven concurrency
典型的程序用命令的風(fēng)格開(kāi)發(fā)—一個(gè)命令的線性序列—并且是基于調(diào)用棧(call stack)的。調(diào)用棧的主要功能是追蹤例程(routine，感覺(jué)應(yīng)該是函數(shù)呀)的調(diào)用者，在阻塞調(diào)用者的同時(shí)執(zhí)行被調(diào)用的例程，當(dāng)執(zhí)行完畢后把控制流交還給調(diào)用者，并且返回執(zhí)行結(jié)果的值（或者不返回）

事件驅(qū)動(dòng)的程序并不關(guān)注于調(diào)用棧，而是關(guān)注于觸發(fā)事件。事件可以被編碼成消息，放在隊(duì)列里，被一個(gè)或者更多監(jiān)聽(tīng)者監(jiān)聽(tīng)。事件驅(qū)動(dòng)和命令式的巨大區(qū)別在于調(diào)用者不被阻塞，不用在等待響應(yīng)的時(shí)候占據(jù)一個(gè)線程(caller does not block and hold onto a thread while waiting for a response)。事件循環(huán)本身可以是單線程的，但是仍然可以實(shí)現(xiàn)并發(fā)，因?yàn)榭梢栽冢ㄓ袝r(shí)是單線程 的）事件循環(huán)處理新的請(qǐng)求的同時(shí)調(diào)用例程來(lái)完成工作（注：因?yàn)閷?duì)例程的調(diào)用被搞成了非阻塞的，即不會(huì)阻塞event-loop）。不再是阻塞于一個(gè)請(qǐng)求，等待它被處理完，現(xiàn)在調(diào)用者的標(biāo)識(shí)可以和請(qǐng)求消息本身一起被傳遞，使得（如果被調(diào)用的例程選擇這么做）調(diào)用者可以被回調(diào)，在回調(diào)時(shí)傳遞響應(yīng)(the caller can be called back with a response)。

選擇一個(gè)事件驅(qū)動(dòng)架構(gòu)的主要結(jié)果是他們可有會(huì)遇到一個(gè)現(xiàn)象，叫做回調(diào)地獄(callback hell)http://callbackhell.com 。 回調(diào)地獄之所以發(fā)生，是因?yàn)橄⒌慕邮苷呤悄涿瘮?shù)而不是可尋址的接受者(addressable recipients).通常的解決方案僅僅關(guān)注于句法—aka, the Pyramid of Doom—而忽略了推導(dǎo)和調(diào)試代碼中表達(dá)的event所產(chǎn)生的后續(xù)事件的困難。

Actor-based concurrency
基于actor的程序以在多個(gè)actor之間異步的消息傳遞為中心。

一個(gè)Actor由以下的屬性組成：

用于接收消息的mailbox
actor的邏輯，它依賴于模式匹配(pattern matching)來(lái)決定這個(gè)actor如何處理不同類型的消息
隔離的狀態(tài)(isolated state)，而不是共享的狀態(tài)。使用隔離的狀態(tài)來(lái)存儲(chǔ)請(qǐng)求之間的上下文。
像事件驅(qū)動(dòng)的并發(fā)一樣，基于actor的并發(fā)也避開(kāi)了調(diào)用棧，轉(zhuǎn)向輕量級(jí)的消息傳遞。actor可以返回以及發(fā)送消息，甚至傳遞消息給自己。一個(gè)消息可以傳遞給自己消息，使得它先處理隊(duì)列里的其它消息，然后再去結(jié)束一個(gè)長(zhǎng)時(shí)間運(yùn)行的請(qǐng)求?；赼ctor的并發(fā)的一個(gè)巨大好處是，它不僅可以有事件驅(qū)動(dòng)的并發(fā)的優(yōu)點(diǎn)，而且可以讓計(jì)算跨越網(wǎng)絡(luò)邊界變得更容易，并且可以避免callback hell，因?yàn)橄⒈欢ㄏ虻絘ctor。這是一個(gè)強(qiáng)大的概念，有助于構(gòu)造易于設(shè)計(jì)、實(shí)施、維護(hù)的高可擴(kuò)展性的程序。不用考慮“空間”和“時(shí)間”，也不用考慮深度嵌套的回調(diào)函數(shù)，你只需要考慮actor之間的消息流動(dòng)。

另一個(gè)基于actor的架構(gòu)的主要好處是組件之間解耦合。調(diào)用者不用阻塞自己的線程等待響應(yīng)，因此調(diào)用者可以迅速地轉(zhuǎn)去進(jìn)行其它工作。被調(diào)用的例程，封裝在一個(gè)actor中，只需在必須的回復(fù)調(diào)用者。這開(kāi)啟了很多可能性，比如分布例程(routines)到一個(gè)集群中，因?yàn)椴辉儆姓{(diào)用棧把程序耦合在單一的內(nèi)存中，actor模型可以使布署一個(gè)拓?fù)?topology)只是一個(gè)虛擬的配置而不再是編碼在程序里。

Akka是一個(gè)基于actor的工具箱和運(yùn)行時(shí)- Typesafe Reactive Platform的一部分，用來(lái)構(gòu)造并發(fā)的、分布式的、容錯(cuò)的，基于actor的程序，運(yùn)行于JVM。Akka還有其它的一些用于構(gòu)造Reactive application的不可思憶的特性，像是用于rsilience的supervisor hierarchies，以及可以把分布工作來(lái)實(shí)現(xiàn)擴(kuò)展性。對(duì)Akka的深入研究超出了本文的范圍，但是我強(qiáng)烈推薦訪問(wèn)Let it Crash blog 獲取更多關(guān)于Akka的內(nèi)容。

我也強(qiáng)烈推薦閱讀Benjamin Erb’s Diploma Thesis,Concurrent Programming for Scalable Web Architectures, 被用于本節(jié)的參考。

Conclusion
以上的內(nèi)容描述了時(shí)下軟件開(kāi)發(fā)的的表面，引導(dǎo)我們認(rèn)識(shí)到為什么Reactive programming不僅僅是一個(gè)潮流，而且是現(xiàn)在的軟件開(kāi)發(fā)者需要學(xué)習(xí)的范式。不管你選擇什么語(yǔ)言和工具，優(yōu)先考慮scalability和resilient來(lái)實(shí)現(xiàn)responsiveness是唯一能滿足用戶需求的方式。每過(guò)一年，這點(diǎn)就會(huì)變得更加重要。