1. 全栈工程师之路-Node.js高可用架构专用 原文[高可用架构] 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明星讲师[呲牙][呲牙] 1.1. 主要内容
最近比较火的2016年开发者调查了,Node.js和全栈、以及和js相关的技术都有不错的战绩,这次给大家分享一下《全栈工程师之路-Node.js》,准备的还不够充分,水平也有限,大家见谅啊 http:///research/developer-survey-2016 1.2. 讲师介绍桑世龙,目前在天津创业,空弦科技 CTO,开源项目Moajs作者,StuQ明星讲师 公司目前使用技术主要是Node.js, 技术栈算所谓的MEAN(mongodb + express + angular + node); 曾在新浪,网秦等工作过; 算全栈程序员吧,带过前端、后端、数据分析、移动端负责人、做过首席架构师、技术总监,目前主要从事技术架构 + 招人工作 2. Part 1:为什么选用Node.js ?已经7岁的Node.js,你还熟悉么? 以前?现在? 2.1. 回顾一下2015年Node.js的发展历史http://i5ting./history-of-node-js/ 2.1.1. Q1(1季度)
2.1.2. Q2(2季度)
2.1.3. Q3(3季度)
2.1.4. Q4(4季度)
2.2. 版本帝?去年
目前(2016年3月20日)的2个版本
整体来说趋于稳定
2.3. 以前我们总是喜欢拿异步说事儿Node.js与生俱来的2个特性
结果,今天。。。各种【异步】。。。烂大街了 异步已经不是明显优势了 2.4. 除了性能,其他都是病?
官方说 Node.js' package ecosystem, npm, is the largest ecosystem of open source libraries in the world. 以前我们总是喜欢拿异步说事儿,现在我们拿Node.js的强大的生态来炫耀 2.5. 大事儿记下面介绍点Node.js的大事儿记 2.5.1. 企业级
Node.js基金会的创始成员包括Joyent、IBM、Paypal、微软、Fidelity和Linux基金会 更多参见 https:///en/foundation/members/ 对于企业级开发,Node.js是足够的,无论从性能、安全、稳定性等都是非常棒的。 空弦科技做的是基于云仓储的SaaS服务,给中小卖家提供服务,核心系统是进销存+订单池+WMS。目前来看不存在任何问题,稍后会讲我们为啥选择Node.js 2.5.2. es && babel
http:/// babel作为es编译器,已经大量开始使用了,模块做的非常棒,还有人用babel写其他语言编译器 Node.js里在0.12之后才增加es6特性,es7的目前还不支持。 所以在Node.js里使用es里比较高级的特性,是需要babel去编译处理的。 这是node追逐的事实标准 2.5.3. 微软请求 Node.js 支持 ChakraCore
未来Node.js不只是基于chrome v8引擎,它还可以支持更多其他js引擎,对生态、效率提升等非常有好处 蔡伟小兄弟的查克拉benchmark的对比 基本结论是 V8 ES5 >> 查克拉 ES6 > 查克拉 ES5 > V8 ES6 2.6. 为什么我们选择Node.js ?先看一下我们的瓶颈在哪里 ?
Node.js招不到,好多都是从java转的,前端也不好找,好多也是从java转的,我们相当于从0开始组建团队
创业公司,5分钟要造火箭。。。大家都懂 所以让开发快速进入状态,提高开发速度,对我们来说至关重要
在没有专业运维人员的情况下,如何保证系统可用、稳定 于是就引出了我认为的Node.js的好处
2.7. 黑一下go语言吧go不着
适合高端人群,但对团队开发是有门槛的,不适用大部分团队 2.8. 选择Node.js给了我们足够的选择空间 2.8.1. 1)可难可易
甚至可以用各种编译器coffee、typescript、babel(es)等 对于从0开始的团队来讲,可以先面向过程、然后随着团队的成熟度,一点一点增加难度 2.8.2. 2)提供好的基础和包管理工具
以上这些都做大型软件的基础,Node.js在这方面做得非常好 2.8.3. 3)特定场景的快速很多人把mean组合(比如mean.io)起来,这样做的好处是如果熟悉,开发速度确实会非常快,但确定是难度太大,很少有人能搞的定 metetor模糊了服务端和客户端,是同构的典型应用,对于实时场景是非常高效的。 这种东西都算特定场景的快速,一般不敢轻易上,调优难度非常大,如果有人能cover的住,在初期是非常高效的。 2.8.4. 4)总结
还有一个问题就是如果以上不满足咋办?这时就需要架构平衡了 2.9. 架构平衡先说技术选型的3个思考点
各自做各自合适的事儿就好,下面分别举例看看 我们很坦然的面对Node.js的优点和缺点
绝大部分需求都可以满足了
稍微解释一下
有很多东西是Node.js不擅长,又不在架构范畴里的,咋办? 3)如实在不够,java补(严格点,应该叫其他语言补) - 比如复杂excel生成 - 比如apns推送(go做其实也很好,不过除了我,没人能维护。。。) 但凡是java或其他语言里比较成熟的库,可以作为独立服务使用的,都可以做Node.js的支持。避免过多的时间用在早轮子上,影响开发进度 2.10. 效率问题?执行效率:
开发效率:
缺少rails一样的大杀器
Node.js的web开发框架express、koa等,简单,小巧,精致,缺点是集成度不够,目前已有的mean或yo或sails等总有某种方面的不满意 所以我们需要做的
偏偏Node.js提供了2点,可以让你30分钟写一个脚手架
2.11. 我们用Node.js做什么?
2.12. 目前进度
技术栈更新
4.x在内存和性能上都有非常大的提升,新的语言特性上,异步流程和语法上都需要学习,故不急于升级,待人才梯队完善 目前的做法是小步快走
3. Part 2:我眼中的Node.js核心
时间原因,接下来稍微介绍一下MEAN 3.1. 小而美的哲学"Small is beautiful"是Unix哲学9条里的第一条,但对Node.js来说,它实在是再合适不过了 http://blog./post/48281998870/unix-philosophy-and-nodejs
3.2. 从LAMP到MEANMEAN是目前最潮的全栈javascript架构 MEAN是一个Javascript平台的现代Web开发框架总称,它是MongoDB + Express +AngularJS + NodeJS 四个框架的第一个字母组合。它与传统LAMP一样是一种全套开发工具的简称。 从我的角度看
我为什么选择MEAN架构?
最重要的一件事儿,是当有问题的时候,有人能cover住,在创业初期这是最最重要的事儿。 我的一篇爆款文章《Node.js最新Web技术栈(2015年5月)》https:///topic/55651bf07d4c64752effb4b1 讲的就是我们用的技术栈 3.3. 异步流程控制js流程控制的演进过程,分以下5部分
整体来说,对异步流程控制解决的还是比较好的。 3.4. Node.js Web开发
各种类型web开发都支持的,一般我们采用非restful的使用express、koa更简单 如果是纯restful,可以采用restify、hapi 另外还有快速模拟api的json-server,对rest支持超方便 3.5. Node.js 模块开发
普通模块和cli模块只是差package.json里的 "preferGlobal": "true", "bin": { "kp": "kp.js" }, 脚手架scaffold = cli + 模板生成,在Node.js里这2点都非常容易 在Node.js里写c/c++扩展,有nan抽象层,其他就看大家的c/c++水平了 4. Part 3:快速开发实践4.1. 1、业务边界优化创业公司有很多可变性,要做的系统也无数,如何保证业务系统的边界是非常难的,我们其实走了很多弯路,图-稍后补 4.2. 2、静态api理论当需求和ue定下来之后,就开始编写静态api,这样app、h5、前端就可以使用静态api完成功能,而后端也可以以静态api为标准来实现,整体效率还是比较高的。 另外还有基于api生成http请求的思考(未完成) 4.3. 3、api约定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' }} 4.4. 4、约定结构和java开发里的目录结构类似,该分层的分层,适当的按照express/koa增加中间件、路由等目录,便于开发 4.5. 5、使用npm模块化
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 4.6. 6、编写生成器在web开发里,写了moajs生成器,类似于rails moag order name:string password:string 其他开发,如iOS开发里模型校验非常烦,于是写了一个json2objc命令行工具,读取json,生成oc代码,可以节省不少时间 4.7. 7、Moajs框架和前后端分离
4.7.1. 1)moa生成器即上面讲的生成器scaffold 4.7.2. 2)moa-frontend技术栈
4.7.3. 3)moa-api技术栈 Features
4.7.4. 4)总结从开发效果上看,还是非常快的,非常稳定的 更多参见我写的《Moajs框架演进之路》 4.8. 其他
5. Part 4:全栈 or 全烂 ?5.1. Node.js相关工具
5.2. 前端开发4阶段
Vuejs综合Angular和React的优点,应该是下一个流行趋势 5.3. Hybrid开发Hybrid混搭开发是指使用html5技术开发的跨浏览器应用,并最终可以将html5.js.css等打包成apk和ipa包的开发方式。它也可以上传到应用商店,提供给移动设备进行安装。它最大的好处是通过h5开发一次,就可以在多个平台上安装。 未来的2点
5.4. 跨平台5.4.1. 1)c/s架构到b/s架构这个大部分都清楚,不多说 5.4.2. 2)移动端:加壳在浏览器上做文章,把页面生成各个移动端的app文件 5.4.3. 3)PC端:继续加壳一样是延续浏览器做文章,不过这次把页面生成各个PC平台的可执行文件 目前比较火的编辑器atom和vscode都是基于Electron打包的。 5.4.4. 4) 组件化:统一用法React的出现影响最大的是jsx的出现,解决了长久以来组件化的问题,
单纯的React只是view层面的,还不足以应用,于是又有Redux 核心概念:Actions、Reducers 和 Store,简单点说就是状态控制 然后再结合打包加壳,变成app或可执行文件
总结
这部分其实组件化了前端,那么能否用这样的思想来组件化移动端呢? A framework for building native apps with React. http://facebook./react-native/ 简单点说,就是用React的语法来组件化iOS或Android SDK。 它们都在告诉我们,你们以后就玩这些组件就好了,你不需要知道复杂的SDK是什么 5.4.5. 5)当下流行玩法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. 技术点
亲,你看到未来了么? 5.4.6. 6)总结讲了node工具,前端4阶段,hybrid,各种跨平台,目前就是为了介绍Node全栈的各种可能,下面讲一下如何能做到Node全栈? 5.5. 如何全栈?全栈核心
只要打通这2个要点,其他就比较容易了 5.5.1. 1)从后端转做后端的人
4阶段循序渐进,build与工具齐飞 前端开发4阶段,我的感觉是按照顺序,循序渐进
5.5.2. 2)从前端转从前端往后端转,api接口非常容易学会,像express、koa这类框架大部分人一周就能学会,最难的是对db、er模型的理解,说直白点,还是业务需求落地的理解 我们来想想一般的前端有什么技能?
那么他们如果想在前端领域做的更深有哪些难点呢?
以上皆是痛点。 所以比较好的办法
从我们的经验看,这样是比较靠谱的。 https://github.com/moajs/moa-frontend 就是最简单前后端分离,里面没有任何和db相关, 技术栈
一般的前端都非常容易学会,基本2周就已经非常熟练了,我的计划是半年后,让他们接触【异步流程处理】和【数据库】相关内容,学习后端代码,就可以全栈了 5.5.3. 3)从移动端转移动端分
原生开发就是iOS用oc/swift,Android用java或scala等,就算偶尔嵌入webview,能玩js的机会也非常好少 所以移动端转全栈的方法,最好是从cordova(以前叫phonegap)开始做hybrid开发。
只要入了h5的坑,其实就非常好办了。
这个基本上是我走的路,从2010年写iOS、做phonegap(当时是0.9.3)、一路走到现在的总结吧 6. Part 5:未来可能是一场春梦,也可能一个变革机遇,我们更相信它是变革机遇,拭目以待吧 谢谢大家 7. Q & A7.1. 问题一:在全栈的语言选择上,除了node.js,是否还考虑过其他语言?有的,未来swift和lua是有可能的。swift的语法和性能上有很大优势,lua在openresty的推动下也有机会,不过没有swift大 像WebAssembly之类的就不太看好了 7.2. 问题二:请教桑老师:刚才你说的并发开发流程中静态api指的是api文档?如果是的话谁负责编写?你们目前已经是一个人分模块从前端写到后端了吗? 目前没做到文档即静态api,所以目前是直接提供json和部分json-server 负责是后端开发的leader在写,他的进度会比正常开发要早一周左右 目前不是一个人写所有的前后端,团队成立不久,天津Node.js会的不多,所以还是前后端分离。但是通过moa-frontend可以让前端了解express等后端知识,适当的时候会给予机会,前端转后端 7.3. 问题三:第一贵司在开发协作中提到了静态api,请问是不是有什么比较好的工具可以推荐?nodejs里json-server 比较好 我其实很想围绕静态api,写各种请求的生成器,只要api出来,文档和各平台的http请求代码就生成出来,同时可以对正式api进行压测,可惜目前还没精力写 7.4. 问题四:做hybrid app在移动端会遇到性能问题吧。。有没有什么优化经验可以分享?
7.5. 问题五:如果都全栈了,当前你们团队是如何分工的?我们团队还是倾向于分工专业化,各个服务粒度非常小,便于轮岗、还有就是可以为以后像google那样代码开放做准备 但是有很多情况下,是需要有机动的突击队的(尤其是创业时期),这样可以随便组合,另外就是全栈为remote提供了更多便利性。 7.6. 问题六:h5在手机上用iscroll坑比较多啊 尤其三星打开硬件加速的时候render页面,桑老师怎么看?可以尝试一下淘宝系的h5虚拟化,鬼道曾经在as大会上讲过的,我们目前还没能力做这么深层次的优化 7.7. 问题七:Node.js做业务金额计算的金额性能和精度够吗1)你问的不是Node.js,而是Node.js要操作的数据库。 2)耗性能的计算可以在架构上平衡的 - 如果可以延时,mq就可以了 - 如果是非延时情况,可以采用其他语言编写对应服务,没必要非要一定要Node.js 3)我们目前的场景,还没有在计算遇到瓶颈 7.8. 问题八:关于API返回格式那里,对于status为什么不打平了把code和message放出来?这么设定有什么好处么?语义上更加清晰 整个返回的json就只有data和status,如果status.code!=0,我取msg就好了,如果等于0,处理data数据 这种设计不见得多好,不过结构清晰,对于开发者来说,是比较容易接受的 |
|