高可用架構專用
原文[高可用架構]
https://mp.weixin.qq.com/s?_biz=MzAwMDU1MTE1OQ==&mid=405001493&idx=1&sn=f0ecab9b31bad83fb065ac37bb728245&scene=1&srcid=0324iTRH12WbXL5VDxXnEhH8&key=710a5d99946419d938a0ffc16a3c72118eefbe33f3f8312ed218bccbde126b60e818c8eb1068a9b07bdc8116a077b911&ascene=0&uin=NDIzMjM3MDk1&devicetype=iMac+MacBookPro11%2C1+OSX+OSX+10.10.5+build(14F27)&version=11000006&passticket=xdp3crkTJPuOH6ggUMKnwvfDGKEnMUvwC5V%2FdxlW%2FKdNO9R8zI1xsDFSR4ZJECUU
仔細的對比了一遍，感謝tim yang和慶豐校長的整理，非常嚴謹，比我講的要好，另外感謝霍老板封我是StuQ明星講師[呲牙][呲牙]
Why Node.js ？
歷史
槽點
架構平衡和選擇
企業級
我眼中的Node.js核心
快速開發實踐
全棧 or 全爛 ？
工具鏈
前端開發4階段
Hybrid開發
跨平臺
全棧的可能
未來
最近比較火的2016年開發者調查了，Node.js和全棧、以及和js相關的技術都有不錯的戰績，這次給大家分享一下《全棧工程師之路-Node.js》，準備的還不夠充分，水平也有限，大家見諒啊
http://stackoverflow.com/research/developer-survey-2016
桑世龍，目前在天津創業，空弦科技 CTO，開源項目Moajs作者，StuQ明星講師 公司目前使用技術主要是Node.js， 技術棧算所謂的MEAN（mongodb + express + angular + node）； 曾在新浪，網秦等工作過； 算全棧程序員吧，帶過前端、后端、數據分析、移動端負責人、做過首席架構師、技術總監，目前主要從事技術架構 + 招人工作
已經7歲的Node.js，你還熟悉么？
以前？現在？
http://i5ting.github.io/history-of-node-js/
IO.js 1.0.0 發布
Joyent 推進建立 Node.js 基金會
Joyent, IBM, Microsoft, PayPal, Fidelity, SAP and The Linux Foundation Join Forces to Support Node.js Community With Neutral and Open Governance
IO.js 和 Node.js 和解提案
npm 支持私有模塊
Node 項目領導人 TJ Fontaine 逐步解除核心身份并離開 Joyent 公司
A changing of the guard in Nodeland.
Node.js 和 io.js 在 Node 基金會下合并情況
4.0 版本發布，即新的 1.0 版本
Node v4.2.0，首個長期支持版本（LTS）
Apigee，RisingStack 和 Yahoo 加入 Node.js 基金會
Node Interactive
The first annual Node.js conference by the Node.js Foundation
去年
從v0.10.35 開始
2015-01-14發布了v1.0.0版本（io.js）
2.x（io.js）
3.x（io.js）
2015年09月Node.js基金會已發布Node.js V4.0版 與io.js合并后的第一個版本
2015年10月Node.jsv4.2.0將是首個lts長期支持版本
年底發布到4.2.4 && 5.4.0
目前（2016年3月20日）的2個版本
v4.4.0 LTS（長期支持版本）
v5.9.0 Stable（穩定版本）
整體來說趨于穩定
成立了nodejs基金會，能夠讓nodejs在未來有更好的開源社區支持
發布了LTS版本，意味著api穩定
快速發版本，很多人吐槽這個，其實換個角度看，這也是社區活躍的一個體現，但如果大家真的看CHANGELOG，其實都是小改進，而且是邊邊角角的改進，也就是說nodejs的core（核心）已經非常穩定了，可以大規模使用
Node.js與生俱來的2個特性
event-driven
non-blocking I/O
結果，今天。。。各種【異步】。。。爛大街了
異步已經不是明顯優勢了
第一、callback hell問題，目前已經很好的解決了，promise/generator/async后面會講
第二、npm已經是開源世界里最大的包管理器了，模塊非常豐富（25.6萬+）
官方說
Node.js' package ecosystem, npm, is the largest ecosystem of open source libraries in the world.
以前我們總是喜歡拿異步說事兒，現在我們拿Node.js的強大的生態來炫耀
下面介紹點Node.js的大事兒記
2014年 nearform NODE.JS為什么會成為企業中的首選技術
2015年 IBM 收購 StrongLoop，拓展云服務業務
Node.js基金會的創始成員包括Joyent、IBM、Paypal、微軟、Fidelity和Linux基金會
更多參見 https://nodejs.org/en/foundation/members/
對于企業級開發，Node.js是足夠的，無論從性能、安全、穩定性等都是非常棒的。
空弦科技做的是基于云倉儲的SaaS服務，給中小賣家提供服務，核心系統是進銷存+訂單池+WMS。目前來看不存在任何問題，稍后會講我們為啥選擇Node.js
2015年 Ecma國際大會宣布正式批準ECMA-262第6版，亦即ECMAScript 2015（曾用名：ECMAScript 6、ES6）的語言規范
http://babeljs.io/
babel作為es編譯器，已經大量開始使用了，模塊做的非常棒，還有人用babel寫其他語言編譯器
Node.js里在0.12之后才增加es6特性，es7的目前還不支持。
所以在Node.js里使用es里比較高級的特性，是需要babel去編譯處理的。
這是node追逐的事實標準
2016年01月22日，微軟請求 Node.js 支持 ChakraCore
未來Node.js不只是基于chrome v8引擎，它還可以支持更多其他js引擎，對生態、效率提升等非常有好處
蔡偉小兄弟的查克拉benchmark的對比
基本結論是 V8 ES5 >> 查克拉 ES6 > 查克拉 ES5 > V8 ES6
先看一下我們的瓶頸在哪里 ？
1）人（天津不好招人）
Node.js招不到，好多都是從java轉的，前端也不好找，好多也是從java轉的，我們相當于從0開始組建團隊
2）開發速度
創業公司，5分鐘要造火箭。。。大家都懂
所以讓開發快速進入狀態，提高開發速度，對我們來說至關重要
3）穩定
在沒有專業運維人員的情況下，如何保證系統可用、穩定
于是就引出了我認為的Node.js的好處
1）即同樣不優化，性能比大部分語言好(天生被黑的優越感，沒辦法)
2）即使優化，也比其他語言簡單，比如java
3）有足夠多的選擇和架構的平衡
4）如實在不夠，java補
go不著
沒有好的包管理
沒有好的調試工具
語法較難
適合高端人群，但對團隊開發是有門檻的，不適用大部分團隊
Node.js給了我們足夠的選擇空間
可以采用面向過程
可以面向對象
可以函數式
甚至可以用各種編譯器coffee、typescript、babel（es）等
對于從0開始的團隊來講，可以先面向過程、然后隨著團隊的成熟度，一點一點增加難度
測試相關 tdd/bdd/測試覆蓋率
規范化 standard、各種lint、hint
構建相關 gulp、grunt、webpack，大量插件
生成器 yo等
包管理工具npm足夠簡單易用
以上這些都做大型軟件的基礎，Node.js在這方面做得非常好
很多人把mean組合（比如mean.io）起來，這樣做的好處是如果熟悉，開發速度確實會非常快，但確定是難度太大，很少有人能搞的定
metetor模糊了服務端和客戶端，是同構的典型應用，對于實時場景是非常高效的。
這種東西都算特定場景的快速，一般不敢輕易上，調優難度非常大，如果有人能cover的住，在初期是非常高效的。
可以簡單，可以難
可以快、也可以慢
可以開發大型軟件
還有一個問題就是如果以上不滿足咋辦？這時就需要架構平衡了
先說技術選型的3個思考點
在語言層面可以做，那語言層面做
如果語言層面搞不定，那就架構層面做
如果架構層面也搞不定，這東西就不能用了
各自做各自合適的事兒就好，下面分別舉例看看
我們很坦然的面對Node.js的優點和缺點
1）語言層面能解決的
已有大量npm上的模塊(目前在25.6萬個以上)
自己造輪子(站在海量包上+簡單語法+npm=快速)
使用Node.js里的nan自己包裝c/c++輪子
絕大部分需求都可以滿足了
2）架構層面能解決的
業務邊界、模塊拆分、面向服務
mq、rpc、cache
運維、監控、自動化
稍微解釋一下
首先，架構和是不是Node.js寫的沒關系，是獨立的
其次，架構師常用的東東有足夠的Node.js模塊支持，比如mq，像rabbitmq有比較好的node模塊支持，像rpc里thrift、grpc、tchannel支持的都不錯，我們使用的senecajs，比如redis，我們使用的ioredis，后面做ha都是一樣的。
合適的場景用合適的東西
有很多東西是Node.js不擅長，又不在架構范疇里的，咋辦？
3）如實在不夠，java補（嚴格點，應該叫其他語言補） - 比如復雜excel生成 - 比如apns推送（go做其實也很好，不過除了我，沒人能維護。。。）
但凡是java或其他語言里比較成熟的庫，可以作為獨立服務使用的，都可以做Node.js的支持。避免過多的時間用在早輪子上，影響開發進度
執行效率：
同樣不優化，性能比大部分語言好
開發效率：
Node.js本身比較簡單，開發效率還是比較高的
完善的生態，比如測試、工具、npm大量模塊
缺少rails一樣的大殺器
scaffold腳手架
orm太弱
Node.js的web開發框架express、koa等，簡單，小巧，精致，缺點是集成度不夠，目前已有的mean或yo或sails等總有某種方面的不滿意
所以我們需要做的
固化項目結構
限定orm
自定義腳手架
偏偏Node.js提供了2點，可以讓你30分鐘寫一個腳手架
cli命令模塊，編寫非常容易
基于js的模板引擎（知名的30+）
api服務
前端（moa-frontend）
SDK（OAuth Provider）
輔助開發cli工具
使用0.10.38，開發moajs框架
express/mongodb
pm2部署
阿里云的slb負載
alinode監控
前后端分離
moa-api
moa-frontend
moa-h5(未能用)
上redis緩存
上rabbitmq
上senaca作為rpc
上kong作為api gateway（todo）
上consul做服務發現和配置（todo）
上elk作為日志分析處理（todo）
使用docker compose作為本地開發環境（todo）
線上docker（todo）
技術棧更新
nodejs 4.x（預計今年6月份）
koa（generator/co）
es6/es7(babel)
4.x在內存和性能上都有非常大的提升，新的語言特性上，異步流程和語法上都需要學習，故不急于升級，待人才梯隊完善
目前的做法是小步快走
一次只上一樣新技術
形成梯隊，即可準備上新東西
善用npm，實現3化
模塊化
最小化
服務化
1）小而美的哲學
2）從LAMP到MEAN
3）異步流程控制
4）Node.js Web開發
5）Node.js 模塊開發
時間原因，接下來稍微介紹一下MEAN
"Small is beautiful"是Unix哲學9條里的第一條，但對Node.js來說，它實在是再合適不過了
http://blog.izs.me/post/48281998870/unix-philosophy-and-nodejs
Write modules that do one thing well. Write a new module rather than complicate an old one.
Write modules that encourage composition rather than extension.
Write modules that handle data Streams, because that is the universal interface.
Write modules that are agnostic about the source of their input or the destination of their output.
Write modules that solve a problem you know, so you can learn about the ones you don’t.
Write modules that are small. Iterate quickly. Refactor ruthlessly. Rewrite bravely.
Write modules quickly, to meet your needs, with just a few tests for compliance. Avoid extensive specifications. Add a test for each bug you fix.
Write modules for publication, even if you only use them privately. You will appreciate documentation in the future.
MEAN是目前最潮的全棧javascript架構
MEAN是一個Javascript平臺的現代Web開發框架總稱，它是MongoDB + Express +AngularJS + NodeJS 四個框架的第一個字母組合。它與傳統LAMP一樣是一種全套開發工具的簡稱。
從我的角度看
mysql用mongodb替換，nosql里最像rdbms的，從開發和性能都是有優勢的（老畢已經講過了）
angular的出現是一個時代，ioc，雙向綁定，指令等都曾讓無數熱血沸騰
nodejs提供了完全的生態和工具鏈，你要的它基本都有，感謝npm，早些年nodejs的性能甩php幾條街的
express作為nodejs示范項目，它非常精簡，是比較合適的web框架
我為什么選擇MEAN架構？
成熟、穩定，簡單，有問題我們能cover住，所以我們選了nodejs
把握趨勢，以后nodejs的前景非常看好，尤其先后端統一，全棧方向
在架構上可以屏蔽可能風險，不孤注一擲，也不會一葉障目，合理的使用其他語言，只要每個功能都以服務出現，至于它是什么語言寫的，并不重要
招人成本的性價比相對較高，技術棧新，容易吸引人才
最重要的一件事兒，是當有問題的時候，有人能cover住，在創業初期這是最最重要的事兒。
我的一篇爆款文章《Node.js最新Web技術棧（2015年5月）》https://cnodejs.org/topic/55651bf07d4c64752effb4b1 講的就是我們用的技術棧
js流程控制的演進過程，分以下5部分
1) 回調函數Callbacks
2) 異步JavaScript
3) Promise/a+規范
4) 生成器Generators/ yield(es6)
5) Async/ await(es7)
目前所有版本都支持Promise/a+規范
目前Node.js 4.0 + 支持Generators/ yield
目前不支持ES7里的Async/await，但可以通過babel實現
整體來說，對異步流程控制解決的還是比較好的。
Node.js Web開發
express、koa
restify、hapi
其他框架sails、meteor
各種類型web開發都支持的，一般我們采用非restful的使用express、koa更簡單
如果是純restful，可以采用restify、hapi
另外還有快速模擬api的json-server，對rest支持超方便
Node.js模塊開發
普通模塊
cli
腳手架scaffold
c/c++ addons
普通模塊和cli模塊只是差package.json里的
"preferGlobal": "true", "bin": { "kp": "kp.js" },腳手架scaffold = cli + 模板生成，在Node.js里這2點都非常容易
在Node.js里寫c/c++擴展，有nan抽象層，其他就看大家的c/c++水平了
創業公司有很多可變性，要做的系統也無數，如何保證業務系統的邊界是非常難的，我們其實走了很多彎路，圖-稍后補
當需求和ue定下來之后，就開始編寫靜態api，這樣app、h5、前端就可以使用靜態api完成功能，而后端也可以以靜態api為標準來實現，整體效率還是比較高的。
另外還有基于api生成http請求的思考（未完成）
api的最佳實踐
http://developer.github.com/v3/ （嚴格的restful）
微博API (可讀性強，相對比較傳統)
我們采用的微博API類似的，約定結構也是類似的
res.api is an express middleware for render json api , it convention over api format like this :
{ data: { }, status: { code : x, msg : 'some message' }}和java開發里的目錄結構類似，該分層的分層，適當的按照express/koa增加中間件、路由等目錄，便于開發
使用npmjs的private私有模塊（目前做法）
使用npm的本地模塊開發方法（測試和部署都非?？欤?/p>
搭建npm私服（todo）
hz-api-cloud-adminhz-api-cloud-orderhz-api-cloud-stockhz-api-privatehz-api-private-adminhz-dao-cloudhz-dao-privatehz-dao-usercenterhz-doc-apihz-frontendhz-mq hz-smshz-usercenterxbm-sdkhz-api-adminhz-api-crmhz-api-orderhz-api-statisticshz-api-stockhz-confighz-daohz-doc
在web開發里，寫了moajs生成器，類似于rails
moag order name:string password:string
其他開發，如iOS開發里模型校驗非常煩,于是寫了一個json2objc命令行工具，讀取json，生成oc代碼，可以節省不少時間
前端：moa-frontend
public下面的采用nginx做反向代理
其他的采用express+jade精簡代碼（ajax與后端交互）
后端：moa-api
即上面講的生成器scaffold
技術棧
express
jade
bootstrap、bootstrap-table
jquery
gulp
nginx
技術棧
Features
自動加載路由
支持mongodb配置
集成mongoosedao，快速寫crud等dao接口
自帶用戶管理
使用jsonwebtoken做用戶鑒權
支持migrate測試
支持mocha測試
默認集成res.api，便于寫接口
集成supervisor，代碼變動，自動重載
gulp自動監控文件變動，跑測試
gulp routes生成路由說明
使用log4js記錄日志
從開發效果上看，還是非?？斓?，非常穩定的
更多參見我寫的《Moajs框架演進之路》
《從0開始寫Node.js框架》
grunt/gulp/fis/webpack
bower/spm/npm
tdd/bdd cucumber/mocha
standard
babel/typescript/coffee
html/css/js（基礎）
jQuery、jQuery-ui，Extjs（曾經流行）
Backbone（mvc），Angularjs、Vuejs（當前流行）
React組件化（未來趨勢）、Vuejs
Vuejs綜合Angular和React的優點，應該是下一個流行趨勢
Hybrid混搭開發是指使用html5技術開發的跨瀏覽器應用，并最終可以將html5.js.css等打包成apk和ipa包的開發方式。它也可以上傳到應用商店，提供給移動設備進行安裝。它最大的好處是通過h5開發一次，就可以在多個平臺上安裝。
未來的2點
js一統天下（nodejs做后端，傳統web和h5使用javasctipt，更智能的工具如gulp，更簡單的寫法如coffeescript等）
h5大行其道（網速變快，硬件內存增長）
這個大部分都清楚，不多說
在瀏覽器上做文章，把頁面生成各個移動端的app文件
一樣是延續瀏覽器做文章，不過這次把頁面生成各個PC平臺的可執行文件
目前比較火的編輯器atom和vscode都是基于Electron打包的。
React的出現影響最大的是jsx的出現，解決了長久以來組件化的問題，
我們反復的折騰js，依然無法搞定
我們嘗試OO，比如extjs
我們最終還是找個中間格式jsx
單純的React只是view層面的，還不足以應用，于是又有Redux
核心概念：Actions、Reducers 和 Store，簡單點說就是狀態控制
然后再結合打包加殼，變成app或可執行文件
iOS、Android上用Cordova
PC上使用Electron
總結
組件定義好（React）
控制好組件之間的狀態切換（Redux）
打包或加殼（Cordova or Electron）
這部分其實組件化了前端，那么能否用這樣的思想來組件化移動端呢？
A framework for building native apps with React. http://facebook.github.io/react-native/
簡單點說，就是用React的語法來組件化iOS或Android SDK。
它們都在告訴我們，你們以后就玩這些組件就好了，你不需要知道復雜的SDK是什么
Medis is a beautiful, easy-to-use Redis management application built on the modern web with Electron, React, and Redux. It's powered by many awesome Node.js modules, especially ioredis and ssh2.
技術點
使用Node.js模塊
使用Webpack構建
使用React（視圖） + Redux（控制邏輯）
使用Electron加殼打包
親，你看到未來了么？
講了node工具，前端4階段，hybrid，各種跨平臺，目前就是為了介紹Node全棧的各種可能，下面講一下如何能做到Node全棧？
全棧核心
后端不會的ui（界面相關）
前端不會的db（業務相關）
只要打通這2個要點，其他就比較容易了
做后端的人
對數據庫是比較熟悉，無論mongodb，還是mysql、postgres
對前端理解比較弱，會基本的html，css，模板引擎等比較熟悉
4階段循序漸進，build與工具齊飛
前端開發4階段，我的感覺是按照順序，循序漸進
html/css/js（基礎）
jQuery、jQuery-ui，Extjs（曾經流行）
Backbone，Angularjs（當前流行）、Vuejs
React（未來趨勢）、Vuejs
從前端往后端轉，api接口非常容易學會，像express、koa這類框架大部分人一周就能學會，最難的是對db、er模型的理解，說直白點，還是業務需求落地的理解
我們來想想一般的前端有什么技能？
html
css（兼容瀏覽器）
js會點（可能更多的是會點jquery）
ps切圖
firebug和chrome debuger會的人都不太多
用過幾個框架，大部分人是僅僅會用
英語一般
svn/git會一點
那么他們如果想在前端領域做的更深有哪些難點呢？
基礎：oo，dp，命令，shell，構建等
編程思想上的理解（mvc、ioc，規約等）
區分概念
外圍驗收，如h5和hybird等
追趕趨勢，如何學習新東西
以上皆是痛點。
所以比較好的辦法
玩轉npm、gulp這樣的前端工具類（此時還是前端）
使用node做前后端分離（此時還是前端）
express、koa這類框架
jade、ejs等模板引擎
nginx
玩轉【后端】異步流程處理（promise/es6的(generator|yield)/es7(async|await)）
玩轉【后端】mongodb、mysql對應的node模塊
從我們的經驗看，這樣是比較靠譜的。
https://github.com/moajs/moa-frontend
就是最簡單前后端分離，里面沒有任何和db相關，
技術棧
express
jade
bootstrap，bootstrap-table
jquery
gulp
nginx
一般的前端都非常容易學會，基本2周就已經非常熟練了，我的計劃是半年后，讓他們接觸【異步流程處理】和【數據庫】相關內容，學習后端代碼，就可以全棧了
移動端分
native原生開發
hybrid混搭式開發
原生開發就是iOS用oc/swift,Android用java或scala等，就算偶爾嵌入webview，能玩js的機會也非常好少
所以移動端轉全棧的方法，最好是從cordova（以前叫phonegap）開始做hybrid開發。
只要關注www目錄里的h5即可，比較簡單
如果h5不足以完成的情況下，可以編寫cordova插件，即通過插件讓js調用原生sdk里功能
cordova的cli可以通過npm安裝，學習npm的好方法
學習gulp構建工具
只要入了h5的坑，其實就非常好辦了。
然后h5、zeptojs、iscroll、fastclick等
然后微信常用的，如weui、vux（vue+weui）、jmui（react+weui）
然后可以玩點框架，比如jquery mobile，sencha touch
然后可以玩點高級貨，ionicframework（基于angularjs、cordova）
然后前端4階段，依次打怪升級
然后node
這個基本上是我走的路，從2010年寫iOS、做phonegap（當時是0.9.3）、一路走到現在的總結吧
可能是一場春夢，也可能一個變革機遇，我們更相信它是變革機遇，拭目以待吧
謝謝大家
有的，未來swift和lua是有可能的。swift的語法和性能上有很大優勢，lua在openresty的推動下也有機會，不過沒有swift大
像WebAssembly之類的就不太看好了
如果是的話誰負責編寫？你們目前已經是一個人分模塊從前端寫到后端了嗎？
目前沒做到文檔即靜態api，所以目前是直接提供json和部分json-server
負責是后端開發的leader在寫，他的進度會比正常開發要早一周左右
目前不是一個人寫所有的前后端，團隊成立不久，天津Node.js會的不多，所以還是前后端分離。但是通過moa-frontend可以讓前端了解express等后端知識，適當的時候會給予機會，前端轉后端
nodejs里json-server 比較好
我其實很想圍繞靜態api，寫各種請求的生成器，只要api出來，文檔和各平臺的http請求代碼就生成出來，同時可以對正式api進行壓測，可惜目前還沒精力寫
足夠輕量級，少選大框架，做好前端該有的優化
注意touch和click的區別，比如fastclick或zeptojs的tap手勢
Chrome profile（css3動畫）
使用weinre真機測試
我們團隊還是傾向于分工專業化，各個服務粒度非常小，便于輪崗、還有就是可以為以后像google那樣代碼開放做準備
但是有很多情況下，是需要有機動的突擊隊的（尤其是創業時期），這樣可以隨便組合，另外就是全棧為remote提供了更多便利性。
可以嘗試一下淘寶系的h5虛擬化，鬼道曾經在as大會上講過的，我們目前還沒能力做這么深層次的優化
1）你問的不是Node.js，而是Node.js要操作的數據庫。 2）耗性能的計算可以在架構上平衡的 - 如果可以延時，mq就可以了 - 如果是非延時情況，可以采用其他語言編寫對應服務，沒必要非要一定要Node.js 3）我們目前的場景，還沒有在計算遇到瓶頸
語義上更加清晰
整個返回的json就只有data和status，如果status.code!=0,我取msg就好了，如果等于0，處理data數據
這種設計不見得多好，不過結構清晰，對于開發者來說，是比較容易接受的
