高可用架构专用《全栈工程师之路-Node.js》
MIT License
高可用架构专用
原文[高可用架构]
仔细的对比了一遍,感谢 tim yang 和庆丰校长的整理,非常严谨,比我讲的要好,另外感谢霍老板封我是 StuQ 明星讲师[呲牙][呲牙]
持续更新版本,如果有问题请在 Issue 里提问
已参加分享
如果想邀请分享,请邮寄给我[email protected],如果时间ok,我会尽量分享
更多沟通
最近比较火的2016年开发者调查了,Node.js 和全栈、以及和 js 相关的技术都有不错的战绩,这次给大家分享一下《全栈工程师之路-Node.js》,准备的还不够充分,水平也有限,大家见谅啊
http://stackoverflow.com/research/developer-survey-2016
英文版本
Afred Sang(aka i5ting)
Alfred Sang (aka i5ting), CTO of Aircos, top trainer of StuQ, author of the open source project Moa.js, and also an evangelist of Node.js. The uniqueness of his experience makes him a full stack practitioner. He served at Sina, NQ Mobile by playing several major roles, such as Chief Architect, R&D Director. Currently, he is focusing on technical architecture and organization/talent development. A book from him, named as "Smashing Node.js 6: Koa Everywhere", is also on the way.
He will talk about the pros and cons of Node.js, why it is a good choice for startups, and how to make the right architecture for different scenarios. While on the subject, a thorough and in-depth overview of the myth of the full-stack developer will also be covered.
中文版
桑世龙(网名 i5ting),空弦科技 CTO,StuQ 明星讲师,开源项目 Moajs 作者,Node.js 技术布道者 曾就职在新浪、网秦,曾做过前端、后端、数据分析、移动端负责人、做过首席架构师、技术总监,全栈技术实践者,目前主要关注技术架构和团队梯队建设方向,正在写一个本新书《更了不起的 Node 4:将下一代 Web 框架 Koa 进行到底》
他将讲述 Node.js 的优劣势、为什么它适合创业公司以及如何在不同的情况下选择正确的架构。与此同时,一个全面深入的关于全栈开发者秘密的总览也会涵盖其中。
我这里面先问一下,大家有多少人了解 Node.js?有多少做前端的?做前端又有多少了解 Node.js 的?看来还不是很多,其实 Node.js 就是如果做前端不了解Node.js,我觉得在未来就不是一个好的前端了,所以我们这块讲的时候会把相关的内容加进来,第一个讲一下为什么选择 Node.js,这个是从我们公司一个初创企业的角度讲的,之后讲一下 Node.js 核心的东西,然后讲一下实战经验,最后把全栈的展望,一直从前端,后端,移动端,包括我个人的全栈之路,把这整个全栈路径跟大家分享一下。
已经7岁的 Node.js,你还熟悉么?
以前?现在?
http://i5ting.github.io/history-of-node-js/
去年
目前(2016年3月20日)的2个版本
整体来说趋于稳定
Node.js 与生俱来的2个特性
结果,今天。。。各种【异步】。。。烂大街了
异步已经不是明显优势了
官方说
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
babel 作为 es 编译器,已经大量开始使用了,模块做的非常棒,还有人用 babel 写其他语言编译器
Node.js 里在0.12之后才增加 es6 特性,es7 的目前还不支持。
所以在 Node.js 里使用 es 里比较高级的特性,是需要 babel 去编译处理的。
这是 Node 追逐的事实标准
未来 Node.js 不只是基于 chrome v8 引擎,它还可以支持更多其他 js 引擎,对生态、效率提升等非常有好处
蔡伟小兄弟的查克拉 benchmark 的对比
基本结论是 V8 ES5 >> 查克拉 ES6 > 查克拉 ES5 > V8 ES6
先看一下我们的瓶颈在哪里 ?
Node.js 招不到,好多都是从 java 转的,前端也不好找,好多也是从 java 转的,我们相当于从0开始组建团队
创业公司,5分钟要造火箭。。。大家都懂
所以让开发快速进入状态,提高开发速度,对我们来说至关重要
在没有专业运维人员的情况下,如何保证系统可用、稳定
于是就引出了我认为的 Node.js 的好处
go 的缺点是很难够(go)着
总结:适合高端人群,但对团队开发是有门槛的,不适用国内大部分大团队,当然如果你的团队足够牛逼,选go是非常好的选择。
羊和骆驼的故事告诉我们:够得着你牛逼,够不着,累死你也够不着
Node.js 给了我们足够的选择空间
甚至可以用各种编译器 coffee、typescript、babel(es)等
对于从0开始的团队来讲,可以先面向过程、然后随着团队的成熟度,一点一点增加难度
以上这些都做大型软件的基础,Node.js 在这方面做得非常好
很多人把 MEAN 组合(比如 mean.io)起来,这样做的好处是如果熟悉,开发速度确实会非常快,但确定是难度太大,很少有人能搞的定
metetor 模糊了服务端和客户端,是同构的典型应用,对于实时场景是非常高效的。
这种东西都算特定场景的快速,一般不敢轻易上,调优难度非常大,如果有人能 cover 的住,在初期是非常高效的。
还有一个问题就是如果以上不满足咋办?这时就需要架构平衡了
先说技术选型的3个思考点
各自做各自合适的事儿就好,下面分别举例看看
我们很坦然的面对Node.js的优点和缺点
绝大部分需求都可以满足了
稍微解释一下
有很多东西是 Node.js 不擅长,又不在架构范畴里的,咋办?
3)如实在不够,java 补(严格点,应该叫其他语言补)
但凡是 java 或其他语言里比较成熟的库,可以作为独立服务使用的,都可以做 Node.js 的支持。避免过多的时间用在早轮子上,影响开发进度
执行效率:
开发效率:
缺少 rails 一样的大杀器
Node.js 的 WEB 开发框架 express、koa 等,简单,小巧,精致,缺点是集成度不够,目前已有的 MEAN / yo / sails 等总有某种方面的不满意
所以我们需要做的
偏偏 Node.js 提供了2点,可以让你30分钟写一个脚手架
技术栈更新
4.x在内存和性能上都有非常大的提升,新的语言特性上,异步流程和语法上都需要学习,故不急于升级,待人才梯队完善
目前的做法是小步快走
时间原因,接下来稍微介绍一下 MEAN
"Small is beautiful" 是 Unix 哲学9条里的第一条,但对 Node.js 来说,它实在是再合适不过了
http://blog.izs.me/post/48281998870/unix-philosophy-and-nodejs
MEAN 是目前最潮的全栈 javascript 架构
MEAN 是一个 Javascript 平台的现代 Web 开发框架总称,它是 MongoDB + Express + AngularJS + NodeJS 四个框架的第一个字母组合。它与传统 LAMP 一样是一种全套开发工具的简称。
从我的角度看
我为什么选择MEAN架构?
最重要的一件事儿,是当有问题的时候,有人能 cover 住,在创业初期这是最最重要的事儿。
我的一篇爆款文章《Node.js 最新 Web 技术栈(2015年5月)》https://cnodejs.org/topic/55651bf07d4c64752effb4b1 讲的就是我们用的技术栈
js 流程控制的演进过程,分以下5部分
整体来说,对异步流程控制解决的还是比较好的。
各种类型 web 开发都支持的,一般我们采用非 restful 的使用 express、koa 更简单
如果是纯 restful,可以采用 restify、hapi
另外还有快速模拟 api 的 json-server,对 rest 支持超方便
普通模块和 cli 模块只是差 package.json 里的
"preferGlobal": "true",
"bin": {
"kp": "kp.js"
},
脚手架 scaffold = cli + 模板生成,在 Node.js 里这2点都非常容易
在 Node.js 里写 c/c++扩展,有 nan 抽象层,其他就看大家的 c/c++ 水平了
见 mongoose.md
https://github.com/17koa/koa-benchmark
https://cnodejs.org/topic/558df089ebf9c92d17e73358
见 deploy.md
创业公司有很多可变性,要做的系统也无数,如何保证业务系统的边界是非常难的,我们其实走了很多弯路,图-稍后补
当需求和 UE 定下来之后,就开始编写静态 api,这样 app、h5、前端就可以使用静态 api 完成功能,而后端也可以以静态 api 为标准来实现,整体效率还是比较高的。
另外还有基于 api 生成 http 请求的思考(未完成)
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 增加中间件、路由等目录,便于开发
hz-api-cloud-admin
hz-api-cloud-order
hz-api-cloud-stock
hz-api-private
hz-api-private-admin
hz-dao-cloud
hz-dao-private
hz-dao-usercenter
hz-doc-api
hz-frontend
hz-mq
hz-sms
hz-usercenter
xbm-sdk
hz-api-admin
hz-api-crm
hz-api-order
hz-api-statistics
hz-api-stock
hz-config
hz-dao
hz-doc
在 web 开发里,写了 moajs 生成器,类似于 rails
moag order name:string password:string
其他开发,如 iOS 开发里模型校验非常烦,于是写了一个 json2objc 命令行工具,读取 json,生成 OC 代码,可以节省不少时间
即上面讲的生成器 scaffold
技术栈
技术栈
Features
从开发效果上看,还是非常快的,非常稳定的
更多参见我写的《Moajs框架演进之路》
Vuejs 综合 Angular 和 React 的优点,应该是下一个流行趋势
Hybrid 混搭开发是指使用 html5 技术开发的跨浏览器应用,并最终可以将 html5.js.css 等打包成 apk 和 ipa 包的开发方式。它也可以上传到应用商店,提供给移动设备进行安装。它最大的好处是通过 H5 开发一次,就可以在多个平台上安装。
未来的3点判断
这个大部分都清楚,不多说
在浏览器上做文章,把页面生成各个移动端的 app 文件
一样是延续浏览器做文章,不过这次把页面生成各个 PC 平台的可执行文件
目前比较火的编辑器 atom 和 vscode都是基于 Electron 打包的。
React 的出现影响最大的是 jsx 的出现,解决了长久以来组件化的问题,
单纯的 React 只是 View 层面的,还不足以应用,于是又有 Redux
核心概念:Actions、Reducers 和 Store,简单点说就是状态控制
然后再结合打包加壳,变成 app 或可执行文件
总结
这部分其实组件化了前端,那么能否用这样的思想来组件化移动端呢?
再看 react-native
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 工具,前端4阶段,hybrid,各种跨平台,目前就是为了介绍 Node 全栈的各种可能,下面讲一下如何能做到 Node 全栈?
全栈核心
只要打通这2个要点,其他就比较容易了
没有目标就向钱看,自然会找到目标
既然无法逃避,就热爱它,最后变成兴趣
人生不只有代码,但它能让我快乐,终生受益
也曾懵懂,也曾迷茫,但我这人比较傻,一直信奉:“一次只做1件事儿,尽力做到极致”,短时间看这是比较傻的,但一旦你坚持下去,你就会发现技术其实是门手艺,厚积薄发。
我没办法说自己最擅长什么,但在什么场景下用什么技术是我擅长的。或者说,应变是我最大的本事。很多框架,新技术我都没见过,用过,但花一点点过一下,就能拿已有的知识快速的理解它,这其实是长期学习的好处。
现在越来越忙,写代码的时间越来越少,技术又越发展越快,我能做好的就是每日精进,仗着这点已有的知识储备跟年轻人比赛。我不觉得累,相反我很享受这种感觉,没有被时代淘汰,是一件多么幸福的事儿。
做后端的人
4阶段循序渐进,build 与工具齐飞
前端开发4阶段,我的感觉是按照顺序,循序渐进
从前端往后端转,api 接口非常容易学会,像 express、koa 这类框架大部分人一周就能学会,最难的是对 db、er 模型的理解,说直白点,还是业务需求落地的理解
我们来想想一般的前端有什么技能?
那么他们如果想在前端领域做的更深有哪些难点呢?
以上皆是痛点。
所以比较好的办法
从我们的经验看,这样是比较靠谱的。
https://github.com/moajs/moa-frontend
就是最简单前后端分离,里面没有任何和db相关,
技术栈
一般的前端都非常容易学会,基本2周就已经非常熟练了,我的计划是半年后,让他们接触【异步流程处理】和【数据库】相关内容,学习后端代码,就可以全栈了
移动端分
面临的问题:Native 开发是姥姥不疼舅舅不爱,非常尴尬,很明显连培训出的人就业不要工资混经验就很明显了。另外领导们也都在惦记,能不能用 H5 写?这还算是保守的,如果直接激进的就直接上 RN 了,那么 Native开发的程序员就变了
一个写插件的程序员...招谁惹谁了。。。。
没办法,认命吧,温水里舒服了几年,也该学点东西了
原生开发就是 iOS 用 OC/Swift,Android 用 java 或 scala 等,就算偶尔嵌入 webview,能玩js的机会也非常好少
所以移动端转全栈的方法,最好是从 cordova(以前叫 phonegap)开始做 hybrid 开发。
只要入了 H5 的坑,其实就非常好办了。
这个基本上是我走的路,从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进行压测,可惜目前还没精力写
我们团队还是倾向于分工专业化,各个服务粒度非常小,便于轮岗、还有就是可以为以后像 google 那样代码开放做准备
但是有很多情况下,是需要有机动的突击队的(尤其是创业时期),这样可以随便组合,另外就是全栈为 remote 提供了更多便利性。
可以尝试一下淘宝系的 h5 虚拟化,鬼道曾经在 as 大会上讲过的,我们目前还没能力做这么深层次的优化
1)你问的不是 Node.js,而是 Node.js 要操作的数据库。 2)耗性能的计算可以在架构上平衡的
语义上更加清晰
整个返回的 json 就只有 data 和 status,如果 status.code!=0,我取 msg 就好了,如果等于0,处理 data 数据
这种设计不见得多好,不过结构清晰,对于开发者来说,是比较容易接受的
最后祝福大家有一个好身体,做自己喜欢做的事儿,最好都能全栈,加油
全文完
欢迎关注我的公众号【Node 全栈】
更多沟通