經(jīng)常我們需要一個非常輕量級的框架，來滿足我們很多非常簡單的需求浪腐，同時又要求一定的擴展性、靈活性和松散性顿乒，要求快速開發(fā)议街，又有一定的承載能力，這里設計了一種簡單的解決方案璧榄。
結構
|----------------------------------------|
| web/HTML5 | mobile | ect. |
-----------------------------------------|
| React/Flux/React Native | ^ |
-----------------------------------------|
| rest api/node/express | socket.io |
| -----------------------------|
| | database/redis/storage |
|----------------------------------------|
為了更明晰的分層特漩，這里分為多個服務，因為都是基于nodejs骨杂，所以要整合在一起也是非常簡單涂身。
- Rest Api，提供基礎數(shù)據(jù)服務搓蚪，采用http協(xié)議蛤售，由node/express組成。
- socket妒潭，提供長連接服務悴能，采用socket.io，可以直接連接數(shù)據(jù)層雳灾，也可以通過http協(xié)議連接數(shù)據(jù)層漠酿。
- 表現(xiàn)層，React作為基礎頁面構建方法谎亩，結合原生方法炒嘲，來構建具體應用，或者應用的一部分匈庭。
數(shù)據(jù)層
這里我選擇MySql作為基礎數(shù)據(jù)存儲格式夫凸，redis作為緩存。
大部分時候我們還是需要傳統(tǒng)的關系型數(shù)據(jù)結構嚎花，MySql是最佳的選擇寸痢，同時PostgreSQL, MariaDB也是一種選擇。
作為NoSql的其中之一紊选，mongoDB啼止，也是非常熱門，但是由于資源占用太高兵罢，不太適合小型項目献烦。
Node
為什么會選擇node作為基礎語言來構建整個框架呢？首先讓我們比較比較其他幾種語言卖词。
JAVA / Spring
現(xiàn)在最火熱的spring架構巩那，幾乎所有大型企業(yè)的首選框架吏夯。優(yōu)點多的不用說明了，但是作為我們需要快速開發(fā)以及快速上手的框架并不友好即横，有太多的坑噪生，而且JAVA作為一門強類型的語言，太過于繁瑣东囚。分層明確(Model, DAO, Service, Controller)的同時跺嗽，也降低了開發(fā)速度。
另外一個讓我放棄Spring的原因在于資源占用太高页藻，JAVA的運行環(huán)境就需要非常大的內(nèi)存桨嫁，如果你的開發(fā)機器上需要運行MySql, redis, IDE, tomcat等等，還是有一點壓力的份帐。
Python / django
也是一個比較熱門的開發(fā)框架璃吧，也有挺多的成熟應用，算是一個Ruby On Rail的Python版本废境。但是畢竟Python并不是專門為服務器開發(fā)出來的語言畜挨，而且和C語言有著一些聯(lián)系，所以感覺并不太適合現(xiàn)在的時代彬坏，目前開源社區(qū)的支持也在逐漸下降朦促。
django自己有一套ORM的系統(tǒng)，但是并不夠靈活栓始。
我比較喜歡的是Python的修飾方法务冕，可以非常靈活的配置一些方法的過濾器。(聽說ES7里也要有統(tǒng)一的特性幻赚？)
PHP
感覺PHP是專門為了WEB而設計的語言禀忆，雖然有一些像think php這樣mvc的框架，但是感覺作為一個中間層還是不太穩(wěn)定落恼。
Node.js
Node是一個處理IO密集型業(yè)務非常好的選擇箩退，通常我們的中間層不會有大量的計算，多數(shù)為讀取寫入數(shù)據(jù)佳谦，其他的框架都是選擇等待事務完成戴涝，而且每個請求會生成一個進程，導致一臺機器的并發(fā)數(shù)直接由內(nèi)存決定钻蔑，Node在這方面可以使用更少的資源來獲得同樣的效果啥刻。
Node目前非常的火爆，開源社區(qū)也非尺湫Γ活躍可帽，很多應用或框架都已經(jīng)在node上面開發(fā)，而且開源模塊非常完善窗怒，npm也非常好用映跟。比如我在上層采用的React蓄拣。
同時Javascript作為一門前端語言，簡單易學努隙，可以有很多前端開發(fā)人員進入球恤。
在公布了ES6以后，Javascript感覺已經(jīng)擺脫了腳本語言這一不太好的特性剃法，更像一門專業(yè)面向?qū)ο笳Z言碎捺。不過可惜的是路鹰，到目前為止贷洲，雖然v8已經(jīng)基本支持了所有ES6特性，但是最新的node v6并沒有完全支持晋柱，加上--harmony也只能支持一小部分优构，目前我們還需要借助第三方庫。
只能說雁竞，感謝v8!
同時钦椭，可以看出這個框架的大部分都是由js來組成，所以選擇Node來作為中間層的開發(fā)也是很理所應當?shù)摹?/p>
下一步
整個中間層的構建碑诉。請見下一篇彪腔。
后記
關于Node服務的效率問題，雖然官方說明以及很多自來水的吹捧进栽，感覺非常的優(yōu)秀德挣，但是實際項目中還是需要根據(jù)實際情況來做判斷。
不過如果遇到了效率問題快毛，Node還是可以很方便的和其他語言混編的格嗅，找出最消耗時間的地方，用C/C++改寫也是非尺氲郏快速的屯掖。
穩(wěn)定性是Node比較弱的一個方面。一個線程容易因為一個小錯誤而使整個服務崩潰襟衰，所以除了需要更仔細的錯誤處理贴铜，還需要均衡與熱備來確保服務質(zhì)量。
由于Node的異步語法會導致更多的嵌套關系瀑晒，使用泛濫會導致代碼難以理解绍坝，所以需要統(tǒng)一整個項目的規(guī)范與習慣。（比如使用Promise代替callback函數(shù)）
