兩年前在JCConf 2019，欣賞了Josh Long精彩又活潑的演講，主題就是Reactive Spring，成功勾起我對Reactive的興趣，當年曾經有嘗試去了解，發現相關的知識很廣泛，算是有點撞得頭破血流，所以兩年後多累積了一些程式經驗，趁著鐵人賽的機會，打算來完整從最零碎的知識開始學習，因為不常寫文章而且功力薄弱，這個系列前半部分是專有名詞研究，主要目的是更好的了解Reactive的意思而不是要學術性的探究，如果有錯誤麻煩多多見諒，有需要討論的地方，歡迎在留言區討論。
在考慮是否參賽的過程中，infoQ的這張圖算是最後一根稻草，我發現Reactive Programming都已經到了Late Majority我居然還不會，而且學會了還可以牽扯到一點Innovators裡面RSocket & Reactive Streams增加一點潮度，就決定來寫了。
雖然說是從零碎的知識，但多少還是要先有一點基礎，所以建議是至少擁有以下技術背景再來閱讀會好一點。
整個系列的大方向
Reactive Programming 是一種程式的「典範」(Programming paradigm)，最主要是透過減少thread的等待時間（non-blocking非阻斷）來達到充分利用thread的目的，畢竟資源是可貴的，就像是進入到一間餐廳門口，卻沒有人來招待你，你可能就會直接走掉了，但如果有人跟你說聲稍等一下喔，服務人員處理完手邊的事情就會來找你，這樣給人的感覺好多了，同樣的道理，server將事情處理完再通知你來拿，讓thread不用白白的等待。
Reactive Programming 跟微服務(microservices )一樣都是以前就存在的，只是隨著技術、環境的演進後才開始興盛。他的概念與event driven、observer pattern都有重疊的部分，在研究的過程中會讓你覺得他是個熟悉的老朋友，他代表著不斷變化的資料流，某種程度上與Excel中互相依賴的公式很像，會隨資料變動而改變。擅長處理高效能(high-performance)、併發(concurrency)與非同步(asynchronous)，在原本寫程式的習慣上，如果使用了concurrency與asynchronous並伴隨各式各樣的鎖(synchronized)，如果不謹慎常常導致不容易去除錯與維運，或是一個需求需要透過一個又一個API才有辦法完成，也就是需要等待每個服務都完成，這常常會導致效能不彰(大量IO)，以上情況在Reactive Programming都會有比較好的效果。
理解Reactive Programming的初期會被各式各樣的專有名詞轟炸，不要用舊的觀念去思考Reactive Programming，需要有DB的支援、application server、語言本身或是額外的library才能做到，頭昏腦脹是必經的過程，先初步熟悉概念再實作一個DEMO可以更好的去理解。
reactivex.io網站上可以看到Netflix、Microsoft...等大公司都有使用。
Reactive概念對我來說一開始是充滿許多未知的，但隨著不斷閱讀文章與影片，才漸漸的把拼圖一片片補上去，最後才有一個輪廓出來，所以如果看完簡介還是不了解是很正常的，歡迎下一篇文章再回來，下一篇將會介紹Programming paradigm。
大部分有出現的code
rsocket demo code
個人部落格之後可能會整理進去
如果覺得寫得不錯幫忙按個星星或是追蹤，感謝！
資料來源
iThome鐵人賽
看影片追技術