【文章內(nèi)容簡(jiǎn)介】 異步式 I/O 與事件驅(qū)動(dòng)的架構(gòu)設(shè)計(jì)。傳統(tǒng)架構(gòu)對(duì)于高并發(fā)的解決方案是采用多線程模型，也就是一個(gè)系統(tǒng)線程處理一個(gè)業(yè)務(wù)邏輯，通過系統(tǒng)線程切方式彌補(bǔ)同步式 I/O 的時(shí)間開銷。 采用的是單線程模型通過異步式的請(qǐng)求方式處理 I/O 調(diào)用，減少了切換上下文次數(shù)所造成的 開銷。 運(yùn)行的過程中將管理一個(gè)事件堆棧，不斷地循環(huán)執(zhí)行事件然后等待下一個(gè)事件的觸發(fā)。異步式 I/O 請(qǐng)求完成后將被推送到事件隊(duì)列，等待主進(jìn)程進(jìn)行處理?；谑录漠惒教幚頇C(jī)制的 對(duì)于所有的網(wǎng)絡(luò)通信、磁盤讀寫、數(shù)據(jù)庫操作等都以異步請(qǐng)求的方式實(shí)現(xiàn)，最后將執(zhí)行得到的結(jié)果交給事件循環(huán)進(jìn)行處理。 下圖 描述了這個(gè)機(jī)制。 圖 進(jìn)程在進(jìn)行事件處理時(shí)具有時(shí)間的唯一性，它不會(huì)同時(shí)處理多個(gè)事件請(qǐng)求，在處理完一個(gè)事件后就進(jìn)程就進(jìn)入下一個(gè)事件循環(huán)，檢查 并繼續(xù)處理后面的 第 3 頁 共 81 頁 事件。這樣做優(yōu)點(diǎn)在于能夠集中 CPU 和內(nèi)存資源快速處理某個(gè)事件，并且盡量讓耗費(fèi)資源的 I/O 操作并行執(zhí)行。在應(yīng)對(duì)惡意訪問方面， 對(duì)于低速的 DOS 攻擊， 只增加事件堆棧中的請(qǐng)求請(qǐng)求樹立，而不會(huì)馬上給出請(qǐng)求應(yīng)答，這樣有效的減少了線程資源的開銷，很大程度上提高了 Web 應(yīng)用的健壯性和安全性。 由于 采用事件驅(qū)動(dòng)與異步式 I/O 代替多線程，較大幅度的提升性能。此外 除了使用 Google 的 Chrome V8 作為 JavaScript 引擎，它還 使用了高效的 libeio 和庫 libev 支持事件驅(qū)動(dòng)和異步式 I/O。 架構(gòu)的示意圖如下 圖 12 設(shè)計(jì) 的開發(fā)者從 libev 和 libeio 庫中進(jìn)一步封裝出來出 libuv 層。在 Windows 下， libuv 使用了 Windows 的 IOCP（ Input/Output Completion Port，輸入輸出完成端口）機(jī)制，實(shí)現(xiàn)高性能，而對(duì)于 Linux、 UNIX,Mac OS X 等操作系統(tǒng)， 的 libuv 庫通過使用 libeio 和 libev 的封裝來利用 kqueue 或 epoll。 以上簡(jiǎn)單介紹了 。那么為網(wǎng)絡(luò)而生的 能夠做一下事情。 (1)大規(guī)模的社交網(wǎng)絡(luò) Web 應(yīng)用，如微博， FaceBook 等。 (2)具有復(fù)雜邏輯的網(wǎng)站；如一般的 MIS系統(tǒng)。 (3)Web Socket 服務(wù)器；如游戲引擎。 (6)TCP/UDP 套接字應(yīng)用程序，即時(shí)通信系統(tǒng)； 第 4 頁 共 81 頁 (7)客戶端 JavaScript 編譯器。 由于 具有以上優(yōu)點(diǎn)，所以對(duì)于 web 應(yīng)用來說 是優(yōu)秀的開發(fā)平臺(tái) 。 平臺(tái)的非擅長(zhǎng)領(lǐng)域 一個(gè)優(yōu)秀的平臺(tái)能夠吸引大量開發(fā)者的關(guān)注。 有許多傳統(tǒng)架構(gòu)不具備的優(yōu)點(diǎn)，以至于開發(fā)者愿意用 來做應(yīng)用開發(fā)。但是 與其他任何平臺(tái)一樣，都存在優(yōu)點(diǎn)和缺點(diǎn)，如果非要使用它的缺點(diǎn)來完成業(yè)務(wù)需求，那么同樣會(huì)遇到困難和僵局。盡管它是高性能的，新穎的，但也不得不寫出難以理解的邏輯代碼。與大多數(shù)新語言平臺(tái)本質(zhì)一樣， 也是舊瓶裝新酒。只不過概念比較新潮 ,它不能完成所有的業(yè)務(wù)邏輯，或者說它不是萬能的。前一節(jié)提到 的平臺(tái)優(yōu)點(diǎn) ，本節(jié)則簡(jiǎn)要介紹下 的短板所在。 （ 1）多任務(wù)的單用戶應(yīng)用 前面介紹的都是服務(wù)器端編程，設(shè)計(jì)時(shí)的情況是用戶數(shù)量很多。但如果面對(duì)的是單用戶，譬如本地的命令行工具或者圖形界面，那么就不存在所謂的大量并發(fā)請(qǐng)求。于是另一個(gè)問題出現(xiàn)了，盡管是單用戶，卻不一定是執(zhí)行單任務(wù)。例如在給用戶提供界面的時(shí)候后臺(tái)需要進(jìn)行某個(gè)計(jì)算，為了使用戶界面不出現(xiàn)阻塞狀態(tài)，不得不開啟多線程或多進(jìn)程。而到目前為止 的線程或進(jìn)程之間的通信還不方便，因?yàn)樗緵]有資源鎖，所以號(hào)稱不會(huì) 死鎖。多進(jìn)程的 往往是 在執(zhí)行同一任務(wù)，通過多進(jìn)程利用多處理器的資源，但遇到多進(jìn)程相互協(xié)作時(shí)， 的短板就出現(xiàn)了。 （ 2）編碼與國(guó)際化 不支持完整的 UTF8 字符編碼，很多字符無法用 string 表示。實(shí)際上來說這不是 本身造成的，問題而是出在 JavaScript 標(biāo)準(zhǔn)上。目前JavaScript 支持的是雙字節(jié)的 UCS2 字符集，即兩個(gè)字節(jié)來表示一個(gè) Unicode 字符，這樣能表示出來的字符數(shù)是 65536。明顯，漢字就不止這個(gè)數(shù)目。因此無法表示某些生僻漢字，以及一些較為罕見語言的文字。這是 設(shè)計(jì)的問題，源于當(dāng)時(shí)設(shè)計(jì)者的主觀判斷。最初的 Unicode 設(shè)計(jì)者認(rèn)為 65536 個(gè)字符足以表示全世界所有的文字，因 第 5 頁 共 81 頁 此那個(gè)時(shí)候兼容 Unicode 的系統(tǒng)或平臺(tái)，如 Windows、 Java 和 JavaScript 在后來都遇到這個(gè)問題。隨后 Unicode 意識(shí)到用 2 個(gè)字節(jié)表示所有字符是遠(yuǎn)遠(yuǎn)不夠的，隨后推出了 UCS4 編碼，即用 4 個(gè)字節(jié)來表示一個(gè) Unicode 字符。原有的定長(zhǎng)編碼的UCS2 系統(tǒng)為了變長(zhǎng)的 UTF16 編碼進(jìn)行了升級(jí)處理，所以只有它向下兼容 UCS2。UTF16 編碼采用定長(zhǎng)的雙字節(jié)編碼處理 UCS2 以內(nèi)的 字符，對(duì)于以外的部分則使用多字節(jié)的變長(zhǎng)編碼。這樣在通常情況下它的編碼是定長(zhǎng)的，有利于提高運(yùn)算效率并且且兼容了 UCS2 編碼，缺點(diǎn)是它本質(zhì)還是變長(zhǎng)編碼，在應(yīng)用程序中處理起來還是存在不便之處。 JavaScript 當(dāng)下支持的仍是定長(zhǎng)的 UCS2 編碼 而不是 UTF16，因此對(duì)于處理使用 UCS4 進(jìn)行編碼 的字符無能為力。這個(gè)缺陷存在于現(xiàn)有的所有 JavaScript 引擎。包括 Chrome 的 V8 引擎在內(nèi)。因此你無法處理罕見的字符的時(shí)候，想用 實(shí)現(xiàn)一個(gè)多語言的字典工具是不可能做到的，除非放棄使用 javascript 原有的 string 數(shù)據(jù)類型，將所有的字符當(dāng)作二進(jìn)制的 Buffer 數(shù)據(jù)來處理。 （ 3）復(fù)雜邏輯的事務(wù) 的控制流是非線性的，它由一個(gè)個(gè)事件響應(yīng)組成，但人的思維卻是線性的，當(dāng)試圖轉(zhuǎn)換思維來適應(yīng)語言或編譯器時(shí)，就得付出性能或者編碼方面的代價(jià)。舉個(gè)例子，如要實(shí)現(xiàn)以下邏輯：從銀行取錢，用錢去購買一個(gè)虛擬商品，買完以后加入庫存數(shù)據(jù)庫，這中間的任何一步都會(huì)涉及數(shù)十次甚至更多的的 I/O 操作，而且任何一次操作失敗以后都需要進(jìn)行回滾操作。這個(gè)過程是復(fù)雜的線性的，假如拆分為非線性的邏輯，那么其復(fù)雜 程度將提升幾個(gè)數(shù)量級(jí)。 更善于處理那些邏輯簡(jiǎn)單但訪問頻繁的任務(wù)，而不適合完成邏輯十分復(fù)雜的工作。 （ 4）需要大量計(jì)算的程序 （在 版本以前）不支持多線程。 的設(shè)計(jì)者和追隨其的開發(fā)者堅(jiān)信單線程和事件驅(qū)動(dòng)的異步式編程比傳統(tǒng)的多線程編程運(yùn)行效率更高。但實(shí)際上多線程通過較大的開銷也能達(dá)到同樣的吞吐量，而且不必為多核環(huán)境進(jìn)行特殊的配置。對(duì)比而言， 其單線程性的特性，如果需要充分利用多核資源則需要使用多進(jìn)程的方法才能達(dá)到 理想情況下的單線程執(zhí)行過程會(huì) 將 100%利用 CPU 核心資源，所有請(qǐng)求須等待當(dāng)前請(qǐng)求處理完畢后才進(jìn)入事件循環(huán)才能響應(yīng)。如果應(yīng)用是需要進(jìn)行大量的 第 6 頁 共 81 頁 計(jì)算除非人為地分開計(jì)算，否則將會(huì)有相當(dāng)大的請(qǐng)求響應(yīng)延遲。不過在實(shí)際使用中的 Web 服務(wù)器中，很少需要大量計(jì)算的部分很少，即使存在，那么不應(yīng)該被實(shí)現(xiàn)為即時(shí)的響應(yīng)。一般的處理辦法是后臺(tái)處理完成后給前臺(tái)客戶端異同處理完成的通知。 開發(fā)框架的原因 剛推廣不久，國(guó)內(nèi)還缺少使用 做應(yīng)用開發(fā)的框架。 只提供底層的 接口。缺少豐富的上層應(yīng)用接口。直接使用底層接口做開發(fā)需要分析大量的 協(xié)議內(nèi)容。對(duì)于開發(fā)效率有著嚴(yán)重的制約。基于此點(diǎn)，本論文開發(fā)設(shè)計(jì)一個(gè)簡(jiǎn)單小型的 MVC 框架，簡(jiǎn)化 的使用難度的同時(shí)提高開發(fā)效率。 目前 web 應(yīng)用中，普遍使用了 MVC 模式（即 ModelViewController,模型，視圖，控制器）。如基于 JAVA EE 的 Struts2 + Spring3 + jsp MVC 模式等 。借鑒這些其他平臺(tái)上現(xiàn)有的框架結(jié)構(gòu)和功能，設(shè)計(jì)開發(fā) FastJsonWeb 框架。本框架將封裝 的底層接口，對(duì)請(qǐng)求數(shù)據(jù)等提供統(tǒng)一簡(jiǎn)潔的方 式，從而較大幅度的提升開發(fā)效率?；趯?duì)不同平臺(tái)現(xiàn)有框架分析提取出本框架的功能點(diǎn)。這些功能點(diǎn)包括 路由轉(zhuǎn)發(fā)與映射，屬性注入， Cookie 實(shí)現(xiàn)， Sesison 實(shí)現(xiàn)等。 小型的 MVC 框架意味著該框架應(yīng)具有易用性和高效性，能夠很大程度上滿足大多數(shù)業(yè)務(wù)的邏輯。在現(xiàn)有的已存在的 Node 的 MVC 框架中，如 Express,已經(jīng)能夠滿足大多數(shù)業(yè)務(wù)邏輯 ，但是因?yàn)槭菄?guó)外開發(fā)，其文檔資料大多數(shù)是英文編寫，需要高昂的學(xué)習(xí)成本，而且大多數(shù)功能對(duì)于一般的應(yīng)用是冗余的，加之配置復(fù)雜，遇到問題無法得到有效快速的解 決途徑，貿(mào)然采用存在大的風(fēng)險(xiǎn)。而自己開發(fā)，雖然時(shí)間周期長(zhǎng)但因?yàn)槠淇芍赜眯?，還是具有較高的價(jià)值。由于平臺(tái)的新穎性，多數(shù) API 還處在變化之中，因此設(shè)計(jì)開發(fā)該框架主要存在以下一些問題。 (1) 還處于高速發(fā)展階段， API 不穩(wěn)定，處在不斷更新變化中，如果采用某個(gè)固定版本，則可能存在 bug 或者無法使用新特性。如果跟隨版本變化則框架的穩(wěn)定性無法保證。 第 7 頁 共 81 頁 (2) 平臺(tái)資料困乏。主要表現(xiàn)在兩個(gè)方面 ,一是新平臺(tái)國(guó)內(nèi)研究使用的人暫時(shí)不多，遇到問題無法立馬得到咨詢有效的解決 。二是缺乏中文資料，有關(guān)資料只能 去 的官方文檔查詢而且是英文。問題的交流只能在 Stack Overflow 等國(guó)外論壇但是是英文環(huán)境，交流存在一定的困難。 (3) 對(duì)于 Window 平臺(tái)支持不是好，一些常用工具無法安裝。缺乏良好的桌面開發(fā)環(huán)境，對(duì)于類 Unix 系統(tǒng)的使用，如 Linux 的發(fā)行版 Ubuntu 有生疏性，無法得心應(yīng)手。 (4)缺乏有效的開發(fā)工具。如今不管哪個(gè)系統(tǒng)平臺(tái)下， javascript 開發(fā) IDE 都很少，或者難以使用，缺乏有效的調(diào)試工具，編碼效率得不到提高。 （ 5）由于 基于事件驅(qū)動(dòng)和異步 I/O,對(duì) 于業(yè)務(wù)邏輯的處理往往不同于一般線性編程，難以打破線性編程的思維僵局。 （ 6） 封裝性非常低，對(duì)于一些常用操作，如 Cookie,Seesion 等都需要根據(jù) Http 頭信息重新實(shí)現(xiàn)，難度較大。 （ 7）目前沒有任何一個(gè)官方文檔規(guī)定 的代碼風(fēng)格，為了保持框架代碼的可讀性和可維護(hù)性，需要定制某一標(biāo)準(zhǔn)，方便今后的維護(hù)。 以上七點(diǎn)主要是分析了 平臺(tái)存在的不足和一些設(shè)計(jì)實(shí)現(xiàn)的困難之處。 該章簡(jiǎn)單的介紹了 平臺(tái)架構(gòu)，使用 的局限性和其優(yōu)點(diǎn)以及框架進(jìn) 行設(shè)計(jì)與開發(fā)存在的難點(diǎn)。 第 8 頁 共 81 頁 第二章 開發(fā)工具及技術(shù)綜述 本章主要是介紹框架設(shè)計(jì)與實(shí)現(xiàn)過程中主要使用到的設(shè)計(jì)工具、開發(fā)工具、開發(fā)平臺(tái)以及 javascript 的一些高級(jí)語言特性。工具有 vim 和 git，平臺(tái)主要是 github與 Ubuntu。除此以外，還將介紹在 Ubutun 下如何搭建 開發(fā)平臺(tái)。 文本編輯器 Vim 簡(jiǎn)介 Vim 是從 vi 發(fā)展出來的一個(gè)文本編輯器。具有代碼補(bǔ)全、終端編譯及錯(cuò)誤跳轉(zhuǎn)等提供編程效率的功能。 Vim 在程序員中被廣泛使用，與 Emacs 并列成為類 Unix 系統(tǒng)用戶最受歡迎的編輯器。 設(shè)計(jì)理念 vim 的設(shè)計(jì)理念是組合。包括命令組合和模式間的組合。命令組合 : Vim 強(qiáng)大的編輯能力中很大部分是來自于其普通模式命令。 vim 的設(shè)計(jì)理念是命令的組合。例如普通模式命令 dd刪除當(dāng)前行， dj代表刪除下一行 ,因?yàn)槭堑谝粋€(gè) d含義是刪除 ,j鍵代表移動(dòng)到下一行 ,組合后 dj刪除當(dāng)前行和下一行。類似的命令組合非常豐富，只要擁有足夠的創(chuàng)造力就可以靈活的組合各種命令進(jìn)行使用，這樣就能更加高效的進(jìn)行文本編輯。 vim 針對(duì)程序語言代碼編寫者。寫代碼 的時(shí)候手需要時(shí)刻保持在鍵盤上 ,隨機(jī)定位代碼、隨機(jī)刪除代碼、移動(dòng)代碼、插入代碼的操作大大多于閱讀、翻頁操作，中間卡頓一下效率就大大降低了 。但對(duì)普通用戶而言 ,順序?qū)憽⒃O(shè)置字體格式、翻頁讀多于隨機(jī)寫刪除操作 , 且每個(gè)動(dòng)作之間本身就有很多的停頓 ,用其他 UI 編輯器(word,notePad++等 )效率反而比 VIM 高效 ,使用 vim 進(jìn)行操作只會(huì)徒增代碼編寫的難度。 主要功能： 第 9 頁 共 81 頁 vi ，分成多個(gè)編輯視圖 6. 文本編輯歷史記憶功能 三種編輯模式 Vim 編輯器具有三種模式，分別是常規(guī)模式，插入模式，命令模式，如下圖 所示 圖 Vim 三種模式的相互轉(zhuǎn)換如下： 常規(guī)模式進(jìn)入命令模式： 在常規(guī)模式下輸入“ :” . 常規(guī)模式進(jìn)入插入模式： a 光標(biāo)后插入文本 A 當(dāng)前行插入文本 i 光標(biāo)前插入文本 I 當(dāng)前行前插入文本 o 當(dāng)前行的下邊插入新行 O當(dāng)前行的上邊插入新行 第 10 頁 共 81 頁 s 刪除光標(biāo)所在處字符，并進(jìn)入插入模式 S 刪除光標(biāo)所在的行，并進(jìn)入插入模式 插入模式進(jìn)入常規(guī)模式：按下 ESC 鍵即可。其中插入模式和命令模式之