【正文】 庫操作等都以異步請(qǐng)求的方式實(shí)現(xiàn)，最后將執(zhí)行得到的結(jié)果交給事件循環(huán)進(jìn)行處理。 進(jìn)程在進(jìn)行事件處理時(shí)具有時(shí)間的唯一性，它不會(huì)同時(shí)處理多個(gè)事件請(qǐng)求，在處理完一個(gè)事件后就進(jìn)程就進(jìn)入下一個(gè)事件循環(huán)，檢查并繼續(xù)處理后面的事件。這樣做優(yōu)點(diǎn)在于能夠集中CPU 和內(nèi)存資源快速處理某個(gè)事件，并且盡量讓耗費(fèi)資源的 I/O 操作并行執(zhí)行。在應(yīng)對(duì)惡意訪問方面， 只增加事件堆棧中的請(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 的開發(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)， 庫通過使用libeio和libev 的封裝來利用 kqueue 或 epoll。(1)大規(guī)模的社交網(wǎng)絡(luò) Web 應(yīng)用，如微博，F(xiàn)aceBook等。(2)具有復(fù)雜邏輯的網(wǎng)站；如一般的MIS系統(tǒng)。(3)Web Socket 服務(wù)器；如游戲引擎。(6)TCP/UDP 套接字應(yīng)用程序，即時(shí)通信系統(tǒng)；(7)客戶端 JavaScript 編譯器。 一個(gè)優(yōu)秀的平臺(tái)能夠吸引大量開發(fā)者的關(guān)注。 與其他任何平臺(tái)一樣，都存在優(yōu)點(diǎn)和缺點(diǎn)，如果非要使用它的缺點(diǎn)來完成業(yè)務(wù)需求，那么同樣會(huì)遇到困難和僵局。盡管它是高性能的，新穎的，但也不得不寫出難以理解的邏輯代碼。與大多數(shù)新語言平臺(tái)本質(zhì)一樣， 也是舊瓶裝新酒。只不過概念比較新潮,它不能完成所有的業(yè)務(wù)邏輯，或者說它不是萬能的。（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ì)死鎖。 往往是在執(zhí)行同一任務(wù)，通過多進(jìn)程利用多處理器的資源，但遇到多進(jìn)程相互協(xié)作時(shí)。（2）編碼與國(guó)際化 不支持完整的UTF8字符編碼，很多字符無法用string 表示。 本身造成的，問題而是出在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è)字符足以表示全世界所有的文字，因此那個(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í)。，而不適合完成邏輯十分復(fù)雜的工作。（4）需要大量計(jì)算的程序 （）不支持多線程。但實(shí)際上多線程通過較大的開銷也能達(dá)到同樣的吞吐量，而且不必為多核環(huán)境進(jìn)行特殊的配置。對(duì)比而言，如果需要充分利用多核資源則需要使用多進(jìn)程的方法才能達(dá)到%利用CPU核心資源，所有請(qǐng)求須等待當(dāng)前請(qǐng)求處理完畢后才進(jìn)入事件循環(huán)才能響應(yīng)。如果應(yīng)用是需要進(jìn)行大量的計(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ā)框架的原因。缺少豐富的上層應(yīng)用接口。直接使用底層接口做開發(fā)需要分析大量的協(xié)議內(nèi)容。對(duì)于開發(fā)效率有著嚴(yán)重的制約?；诖它c(diǎn)，本論文開發(fā)設(shè)計(jì)一個(gè)簡(jiǎn)單小型的MVC框架。目前 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)，API不穩(wěn)定，處在不斷更新變化中，如果采用某個(gè)固定版本，則可能存在bug或者無法使用新特性。如果跟隨版本變化則框架的穩(wěn)定性無法保證。(2)。主要表現(xiàn)在兩個(gè)方面,一是新平臺(tái)國(guó)內(nèi)研究使用的人暫時(shí)不多，遇到問題無法立馬得到咨詢有效的解決。二是缺乏中文資料。問題的交流只能在Stack Overflow等國(guó)外論壇但是是英文環(huán)境，交流存在一定的困難。(3)，一些常用工具無法安裝。缺乏良好的桌面開發(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）,對(duì)于業(yè)務(wù)邏輯的處理往往不同于一般線性編程，難以打破線性編程的思維僵局。（6），對(duì)于一些常用操作，如Cookie,Seesion等都需要根據(jù)Http頭信息重新實(shí)現(xiàn)，難度較大。（7），為了保持框架代碼的可讀性和可維護(hù)性，需要定制某一標(biāo)準(zhǔn)，方便今后的維護(hù)。 。第二章 開發(fā)工具及技術(shù)綜述本章主要是介紹框架設(shè)計(jì)與實(shí)現(xiàn)過程中主要使用到的設(shè)計(jì)工具、開發(fā)工具、開發(fā)平臺(tái)以及javascript的一些高級(jí)語言特性。工具有vim和git，平臺(tái)主要是github與Ubuntu。除此以外。 文本編輯器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ū)?、設(shè)置字體格式、翻頁讀多于隨機(jī)寫刪除操作, 且每個(gè)動(dòng)作之間本身就有很多的停頓,用其他UI編輯器(word,notePad++等)效率反而比VIM高效,使用vim進(jìn)行操作只會(huì)徒增代碼編寫的難度。主要功能：，分成多個(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)前行的上邊插入新行s 刪除光標(biāo)所在處字符，并進(jìn)入插入模式S 刪除光標(biāo)所在的行，并進(jìn)入插入模式 插入模式進(jìn)入常規(guī)模式：按下ESC鍵即可。其中插入模式和命令模式之間無法直接轉(zhuǎn)換。優(yōu)點(diǎn)總結(jié) 相對(duì)于傳統(tǒng)的IDE，VIM具有安裝包小，啟動(dòng)快，支持純終端編輯等優(yōu)點(diǎn)。運(yùn)用各種插件幾乎能提供所有IDE所具備的功能。拋開鼠標(biāo)僅通過鍵盤就可以完成任何文本操作，非常的方便快捷。能夠大大加強(qiáng)對(duì)代碼的掌握程度。 git簡(jiǎn)介源代碼版本控制系統(tǒng)介紹源代碼版本控制是用來記錄若干源碼文件內(nèi)容變化，方便以后用來查看修改某特定版本代碼的系統(tǒng)。程序員經(jīng)常需要保存系統(tǒng)代碼的所有修訂版本用來查找bug。對(duì)此一般的做法都是采用版本控制系統(tǒng) （VCS）。版本控制系統(tǒng)的好處在于它可以將一個(gè)或者多個(gè)代碼文件恢復(fù)到以前的某個(gè)狀態(tài)，不僅如此它還可以將整個(gè)工程都回溯到過去的某個(gè)時(shí)間點(diǎn)。版本控制系統(tǒng)可以通過比較文件細(xì)節(jié)變化找出該文件的最后修改人，同時(shí)還可以通過對(duì)比找出導(dǎo)致出現(xiàn)怪異問題所在或者某個(gè)功能缺陷等等。一旦使用版本控制系統(tǒng)關(guān)于工程，那么不管整個(gè)項(xiàng)目中的文件如何改動(dòng)刪除，最后也可以完整的恢復(fù)原來的某個(gè)版本。完成這個(gè)需求所做的工作量非常少。 Git介紹Git也是眾多版本控制系統(tǒng)中的一員。它當(dāng)初誕生的原因是為了更好的維護(hù)Linux內(nèi)核源代碼。它不同于其他的版本控制器，如svn，cvs等之類的，它具有速度快、設(shè)計(jì)簡(jiǎn)單、對(duì)非線性開發(fā)模式支持強(qiáng)（允許上千個(gè)并行開發(fā)的分支）、完全分布式、能高效管理超大規(guī)模工程項(xiàng)目（速度和數(shù)據(jù)量）等。git原理在Git 版本控制系統(tǒng)內(nèi)。每一個(gè)文件都只有存在三種狀態(tài)：已提交，已修改和已暫存。已提交表示該文件已經(jīng)被安全地保存在本地?cái)?shù)據(jù)庫中了；已修改表示修改了某個(gè)文件，但還沒有提交保存；已暫存表示把已修改的文件放在下次提交時(shí)要保存的清單中。因此用Git 管理項(xiàng)目工程時(shí)時(shí)，代碼文件在三個(gè)工作區(qū)域內(nèi)循環(huán)存在，它們分別是：Git 的工作目錄，暫存區(qū)域，以及本地倉