由於 NodeJS 能夠處理大量網路連線，最近廣泛被使用在 API Service 的實作上。最近剛好研究了 NodeJS 底層的 Event-Base, Non-blocking, Asynchronous I/O (非同步I/O) 等等機制，決定記錄一下學習心得。以前對於 NodeJS 的運作機制只是知道 Non-blocking，但對於實作的細節還是一知半解，深入研究才發現 NodeJS 底層實作為了效能問題，有很多很棒的設計，蠻有趣的，因此記錄一下心得。本來是略懂略懂，了解之後還是略懂略懂，還請神人能夠指導指導。
傳統的服務請求模型
我想先用一個例子來描述傳統 HTTP Service 的Blocking 工作方式，先讓我說個故事先...
假設有一間快餐店，裡頭有著一個櫃台 (執行程序) 與大廳 (系統資源)，這間店雇用了數位服務生 (Thread)。客人進來店裡之後會走向櫃檯和服務生進行點餐 (HTTP Request)，點餐完成的同時服務生走向廚房替客人製作餐點 (執行運算或 I/O 處理)，這時客人在櫃檯旁邊等待自己的餐點。當餐點製作完成時，服務人員會走到大廳尋找點餐的客人 (Content Switch)，並將餐點交給他，最後客人離開大廳完成交易。有個問題，由於在服務人員準備餐點的期間，此時櫃檯並沒有多餘的服務生可以招呼下一位客戶 (Blocking)，為了能夠持續服務更多的客人，老闆雇用了更多的服務生 (開了很多 Thread)，好讓足夠的服務生可以持續在櫃檯服務新來的客人。
我們想像一下，假設現在碰到旅行團用餐，瞬間湧入大量客人，但一個櫃台只能同時服務一位客人處理點餐手續。這時候老闆為了舒緩客人的等待時間，於是增加了許多櫃台 (Process) 數量，暫時解決了客人等待的問題。
隨著時間的演進，店裡生意越來越好，常常旅行團的遊覽車一次來了好幾台，大廳擠滿了排隊與等待餐點的客人。點餐的服務生除了招呼客戶，還要排除客人插隊所產生的糾紛 (Lock)，客人太多太吵，服務生製作完餐點也需要好長一段才可以送到客人手上 (Content Switch)。最後，老闆只好多開幾間店 (Server)，投入越來越多的資金，結局你懂 der.......
NodeJS Event-Base 請求模型
那麼 NodeJS 對於大量連線是如何運作的？我們想像一下...
這時對面街上開了一間叫做「諾得接屎」的快餐店，他們的服務流程是這樣的。這間店只有一個櫃檯 (Process)，裡頭也只有一位點餐的服務生 (Thread)，沒有大廳只有類似「得來速」快速點餐服務。店裡有一個規矩，就是客人要自己填寫菜單與送餐地址 (Callback)，點餐時客人會將單子交給櫃檯人員，定餐過程就結束了，客人可以回到自己喜歡的地方等待餐點，快吧？
當點餐服務生拿到點餐單後，會將單子放在一個新的托盤上，接著將托盤放置於等待製作的大桌子上，這個帶著點菜單的托盤我們稱為請求物件 (Request Object)。這時櫃檯服務生可以立馬處理下一位客人，不管來多少人都是要排隊，但是每個客人停留在櫃檯的時間非常短。
那麼廚房如何製作餐點呢？是這樣子的，廚房養了一批廚師 (執行續池)，有空的廚師就會到大桌子拿起一個托盤，依照上頭的菜單開始製作餐點 (執行運算或 I/O 處理)，並將製作好的餐點 (執行結果) 放置於托盤上，製作完後將托盤放置於另一個等待派送的大桌子上。這時還有另一批負責送餐的服務員，有空就到這個大桌子上拿起一個完成製作的托盤，看看要送到哪裡就將餐點送到客人的手上 (Invoke Callback)。
由於整個過程中工作都是非同步執行，因此過程會充滿很多的變數，不一定先點餐的就會先拿到餐點，但是對於客戶的點餐體驗就快多了。
由了解架構到實務應用
但由於 NodeJS 運作時只能開啟一個程序進行運算 (我猜測這樣的設計是避免過多的 Content Switch)，上文描述許多的角色人員只是程序中不同的 Thread，實際上利用 CPU 分時處理的技巧來達成，可別忘了實際上只有一個程序在運作。這個觀念告訴我們，避免程式佔用太長的 CPU 運算時間是很重要的，不然會造成 NodeJS 無法快速接應新的連線請求。
此外，在實務上最大的問題就是 NodeJS 僅能用到 CPU 的一顆核心進行運算 (因為單一程序的緣故)，但其實可以透過像是 cluster 或 webworker-threads (實作 HTML5 Worker 機制) 之類的模組來分散工作到其他的 CPU 上。了解 NodeJS 運作的原理與特性相當重要，錯誤的設計 NodeJS 程式碼將可能帶來反效果，無法發揮 NodeJS 的最大功效。
上述描述的故事對於 NodeJS 的實際運作機制其實有些出入，我想僅能讓各位了解 NodeJS 大致的運作概念，不好意思獻醜了.......哈