前后端分离 - 为什么用Node.js搭建中间层
转自:https://2014.jsconfchina.com/slides/herman-taobaoweb/index.html#/ https://mp.weixin.qq.com/s/KzumZwo3ITX0TZvTIhq4vg
为什么用Node.js搭建中间层
什么是中间层
在翻看很多技术文章时,大家都提到“中间层”,在很多大型企业中,Node确实承担了“中间层”的角色,那么,Node为什么被广泛的应用在“中间层”呢?
要回答这个问题,先来陈述下什么是中间层。
通常我们把Web领域分为客户端和服务端,也就是前端和后端,这里的后端就包含了网关,静态资源,接口,缓存,数据库等。而中间层呢,就是在后端这里再抽离一层出来,在业务上处理和客户端衔接更紧密的部分,比如页面渲染(SSR),数据聚合,接口转发等等。
以SSR来说,在服务端将页面渲染好,可以加快用户的首屏加载速度,避免请求时白屏,还有利于网站做SEO,他的好处是比较好理解的。那么对于数据的聚合,接口转发来说,这样做有什么意义呢?
用Node的4点意义
业务驱动
Node有个突出的优势,他的开发者可以是前端。
前端对于页面所需要的数据有更好的理解,每个页面要用到哪些接口,每个接口要用到哪些字段前端是最清楚的。再加上实际业务开发中,前端页面需求经常会发生变化,需要修改字段或者数据结构,所以对接页面的这部分接口由前端直接开发非常合适,可以显著的减少沟通成本。
架构需要
面向用户的接口由Node中间层负责以后,真正的服务端可以专注于提供基于领域模型的对内接口,做微服务。
比如可以基于Goods模型,提供所有商品相关的接口;基于Users模型,提供所有用户相关接口。当一个接口需要商品+用户信息时,由Node分别查询组装。从整体业务代码维护角度来说,变得更容易,不会因为业务发展使得每个接口都异常繁杂。
性能满足
如果仅仅是架构层面的需求,需要有一个中间层来沉淀业务,那用Java,PHP也可以做到,为什么说Node更适合做呢?
因为Node天生异步!
众所周知,js是一门单线程语言,所以Node在实现的时候,需要借助libuv来实现异步。
如图所示,libuv为Node提供了线程池,事件池,异步I/O等能力。正是因为其中网络I/O的异步能力,可以让Node做接口聚合时,能够更高效的异步并发处理。
成本较低
Node使用js开发,只需要学习简单的api,前端开发者就可以无障碍使用,学习成本很低。
而且,Node具有活跃的社区和丰富的模块池,拥有很多现成的功能实现。框架方面,也有成熟的koa,express等基本框架和egg等二次封装框架,可根据需求选择上手也比较方便。
案例:淘宝前后端分离实践
为什么要前后端分离
- 关注点分离
- 职责分离
- 对的人做对的事
- 更好的共建模式
- 快速的反应变化
阶段一:后端MVC
VIEW层的两种维护方式
1.前端写Demo,后端套页面
问题:后端需要写HTML,且前端仍然需要确认后端写的HTML。
2.前端写View层,后端只管数据
问题:前端需要熟悉后端语言,且前端需要了解后端架构。
问题1:前端代码越来越复杂
- 无法统一协作模式,代码充满了约定
- JS跟CSS,依赖于后段产出的HTML
- 有的数据來自AJAX,有的数据印在DOM上
- 有的业务逻辑在前端,有的在Model层,更多的是在View层
问题2:前后端依旧高度耦合
- 前端依赖服务端开发环境
- 在服务端View层高度耦合
- 沟通成本高
- 职责不清晰
问题3:无法良好的支持跨终端
- 业务逻辑散落在应用中
- 渲染逻辑强依赖后端页面
- 只能用responsive design硬来
问题4:高度耦合的前后端分工
- 沟通成本上升
- 维护成本上升
- 无法正确且快速的响应变化
- 代码的腐烂只是迟早的问题
阶段二:CLIENT-SIDE MV*
接口分离, 后端提供数据, 前端自己搞
- MODEL层 - JAVASCRIPT OBJECT
- VIEW层 - JAVASCRIPT TEMPLATE
业界满坑满谷的优秀方案:Backbone, EmberJS, KnockoutJS, AngularJS, React, etc.
前后端职责清晰了
后端 | 前端 |
---|---|
|
|
问题1:各层职责重叠,并且各玩各的
- Client-side Model是Server-side Model 的加工
- Client-side View跟Server-side是不同层次的东西
- Client-side的Controller跟Sever-side的Controller各搞各的
- Client-side的Route在Server-side可能没有
问题2:性能问题
- 渲染,取值都在客户端进行,有性能的问题
- 需要等待资源到齐才能进行,会有短暂白屏与闪动
- 在移动设备低速网路的体验奇差无比
问题3:重用问题
- 模版无法重用,造成维护上的麻烦与不一致
- 逻辑无法重用,前端的校验后端仍须在做一次
- 路由无法重用,前端的路由在后端未必存在
问题4:跨终端问题
- 业务太靠前,导致不同端重复实现
- 逻辑太靠前,造成维护上的不易
问题5:SEO问题
- 渲染都在客户端,模版无法重用,SEO实现麻烦
阶段三:重新定义前后端
是依照工作职责来划分的前后端,还是依照硬体环境划分的前后端?
传统认知的前后端(按硬体环境划分)
重新定义的前后端(按工作指责划分)
在服务器(JAVA)与浏览器(JS)的中间架了一个中间层(NODEJS)
WHY NODEJS
- 前端熟悉的语言,学习成本低
- 都是JS,可以前后端复用
- 体质适合:事件驱动、非阻塞I/O
- 适合IO密集型业务
- 执行速度也不差
指责划分
后端 |
前端 | |
---|---|---|
服务器 | 浏览器 | |
JAVA | NodeJS | JS + HTML + CSS |
|
|
|
职责清晰的架构 + 前端范围的扩展 = 更多的可能
实际示例1:淘宝首页优化
需求
- 静态资料展示,方便运营管理
- 更好的承载密集且庞大的流量
解决方案
- 页面缓存与定时刷新,返回缓存资料
- NodeJS产出静态页面到CDN,定时刷新
实际示例2:淘宝详情页优化
需求
- 单日四亿PV,页面数据来自各个不同接口
- 为了不影响体验,先产生页面框架后再发起多个异步请求取数据更新页面。这些多出来的请求带来的影响不小,尤其在无线端
解决方案
在NodeJS端使用Bigpiper技术,合并请求,降低负担,分批输出,不影响体验。
其他优化:
页面渲染优化
- 前后端共享模版
- 首屏服务器渲染
- 次屏浏览器渲染
- 局部刷新浏览器渲染
单页面应用优化
- 前后端共享路由与模版
- 前端换页,浏览器端渲染
- 直接输入网址,服务器渲染
- SEO问题迎刃而解
可靠性优化
单元测试,页面测试,回归测试,持续集成。
接口性能优化
拆分大接口为独立小接口,并发请求。串行 => 并行,大幅缩短请求时间。
部署优化
一台NodeJS对多台JAVA服务器,合理的分配服务器带来最大的产出。
优化时秉承的思想:接口服务化 代码模块化 功能组件化