•1 node.js简介                                                                                             原创者:文思

node.js：js版本的jvm

是一个基于Chrome JavaScript运行时建立的平台， 用于方便地搭建响应速度快、易于扩展的网络应用。 node.js使用事件驱动， 非阻塞I/O 模型而得以轻量和高效，非常适合在分布式设备上运行数据密集型的实时应用。

node.js与java都是服务器语言，但是两者存在很大区别：

（1）node.js比Java更快 ： node.js开发快，运行的效率也算比较高，但是如果项目大了就容易乱，而且javascript不是静态类型的语言，要到运行时才知道类型错误,java开发慢，但是如果项目大、复杂的话，用java就不容易乱，管理起来比node.js省

（2） node.js 前后端都采用Javascript

（3） node.js和Java EE——一种是解释语言，一种是编译语言

优点：

node真正的亮点在于建设高性能，高扩展性的互联网应用——因为它能够处理庞大的并且高吞吐量的并发连接,Node.js从来不是用于解决大规模计算问题而创建的。它的出现是为了解决大规模I/O的问题,项目需求中不包含CPU密集型操作，也不需要访问任何阻塞的资源，那么你就可以利用的node.js的优点：

RESTfulAPI

单线程：node.js可以在不新增额外线程的情况下，依然可以对任务进行并发处理(node.js是单线程的)。它通过事件轮询（event loop）来实现并发操作，我们应该要充分利用这一点(尽可能的避免阻塞操作，取而代之，多使用非阻塞操作)

非阻塞IO：阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。

(你打电话问书店老板有没有《分布式系统》这本书，你如果是阻塞式调用，你会一直把自己“挂起”，直到得到这本书有没有的结果，如果是非阻塞式调用，你不管老板有没有告诉你，你自己先一边去玩了，当然你也要偶尔过几分钟check一下老板有没有返回结果)

事件驱动：所谓事件驱动，简单地说就是你点什么按钮（即产生什么事件），电脑执行什么操作（即调用什么函数）

传统的网络服务技术，是每个新增一个连接（请求）便生成一个新的线程，这个新的线程会占用系统内存，最终会占掉所有的可用内存。而node.js仅仅只运行在一个单线程中，使用非阻塞的异步I/O调用，所有连接都由该线程处理，在libuv的加分下，可以允许其支持数万并发连接（全部挂在该线程的事件循环中）

node.js的应用：

•2 基于nodeJS技术的前后端分离方案

对为何前后端分离的思考：

1 现有开发模式的适用场景？

2 前后端职责不清？

3 开发效率问题？

4 对前端发挥的局限？

5 更多...

在此之前，你需要知道什么是前后端分离？

传统的物理层面前后端分离

此架构是不是觉得很熟悉?

1、所有用到的展现数据都是后端通过异步接口(AJAX/JSONP)的方式提供的，前端只管展现。WEB服务中，SPA(Single-page application)类占的比例很少。很多场景下还有同步/同步+异步混合的模式，SPA不能作为一种通用的解决方案。

2、现阶段的SPA开发模式，接口通常是按照展现逻辑来提供的，有时候为了提高效率，后端会帮我们处理一些展现逻辑，这就意味着后端还是涉足了View层的工作，不是真正的前后端分离。

业务与职责层面的前后端分离

前端：负责View和Controller层。

后端：只负责Model层，业务处理/数据等。

非node.js中间层的架构方案(比如采用Backbone,EmberJS, KnockoutJS, Angular框架)：

但是，世上就怕但是二字：

各层职责重叠：

Client-side Model是Server-side Model的加工

Client-side View跟Server-side是 不同层次的东西

Client-side的Controller跟Sever-side的Controller各搞各的

Client-side的Route但是Server-side可能没有

性能问题：

渲染，取值都在客户端进行，有性能的问题

在移动设备低速网路的体验奇差无比

重用问题：

模版无法重用，造成维护上的麻烦与不一致

逻辑无法重用，前端的校验后端仍须在做一次

路由无法重用，前端的路由在后端未必存在

跨终端问题：

业务太靠前，导致不同端重复实现

逻辑太靠前，造成维护上的不易

node.js在哪里，职责清晰的架構 + 前端范围的扩展 =重新定义前后端基于node.js中间层分离方案

nodeJS作为中间层开发方的优势：

前端可以更加专注于视图层，而让更多的数据逻辑放在Node层处理

转发数据，串接服务

路由设计，控制逻辑

渲染页面，体验优化

中间层带来的性能问题，

在异步ajax转成同步渲染过程中得到

平衡

更多的可能

node.js角色:中转和前端控制

node.js作为中间层开发方案职责划分：

钉是钉,卯是卯,清晰,层次分明有没有

还有疑惑？1为什么要多加NodeJS这一层？2多加一层，性能怎么样？3多加一层，前端的工作量是不是增加了？4多加一层就多一层风险，怎么破？5 nodeJS什么都能做，为什么还要JAVA

1 (传统MVC的模式进行开发，这种模式严重阻碍了前端开发效率，也让后端不能专注于业务开发），解决方案是让前端能控制Controller层，但是如果在现有技术体系下很难做到，因为不可能让所有前端都学java，nodeJS就能很好的解决这个问题

2 分层就涉及每层之间的通讯，肯定会有一定的性能损耗。但是合理的分层能让职责清晰、也方便协作，会大大提高开发效率。分层带来的损失，一定能在其他方面的收益弥补回来

3 相对于只切页面/做demo，肯定是增加了一点，但是总体开发效率会提升很多

4 读者自己思考吧，不要忘了百度

5 JAVA的基础架构已经非常强大而且稳定，而且更适合做现在架构的事情

让我们来看看先行者是怎么做的，淘宝基于nodeJS的前后端分离方案(引用自百度淘宝)：

�

最上端是服务端，就是我们常说的后端。后端对于我们来说，就是一个接口的集合，

服务端提供各种各样的接口供我们使用。因为有node层，也不用局限是什么形式的服务。对后端开发来说，他们只用关心业务代码的接口实现。

服务端下面是node应用。

node应用中有一层Model Proxy与服务端进行通讯。这一层主要目前是抹平我们对不同接口的调用方式，封装一些view层需要的Model。

node层还能直接轻松实现原来vmcommon,tms（淘宝内容管理系统）等需求。node层要使用什么框架由开发者自己决定。不过推荐使用express+xTemplate的组合，xTemplate能做到前后端公用。

怎么用node大家自己决定，但是令人兴奋的是，我们终于可以使用Node轻松实现我们想要的输出方式，比如：:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、异步。想怎么整就怎么整，完全根据你的场景决定。

浏览器层在我们这个架构中没有变化，也不希望因为引入node改变你以前在浏览器中开发的认知。引入node，只是把本该就前端控制的部分交由前端掌控。

场景举例，其中淘宝基于node的首页前后端分离优化：

需求：

静态资料展示，方便运营管理。更好的承载密集且庞大的流量

解决方案：

页面缓存与定时刷新，返回缓存资料。nodeJS产出静态页面到CDN，定时刷新

淘宝基于node的详情页前后端分离优化：

需求：

单日四亿PV，页面数据来自各个不同接口。为了不影响体验，先产生页面框架后。在发起多个异步请求取数据更新页面。这些多出来的请求带来的影响不小，尤其在无线端。

解决方案：

在nodeJS端使用Bigpiper技术，合并请求，降低负担，分批输出，不影响体验

接口性能优化：

拆分大接口为独立小接口，并发请求，串行=>并行，大幅缩短请求时间

部属优化：

一台NodeJS对多台JAVA服务器，合理的分配服务器带来最大的产出

页面渲染优化：

前后端共享模版，首屏服务器渲染，次屏浏览器渲染，局部刷新浏览器渲染

单页面应用优化：

前后端共享路由与模版。前端换页，浏览器端渲染。直接输入网址，服务器渲染

可靠性优化：

单元测试，页面测试，回归测试，持续集成

开发过程中的设计思考点：

接口服务化

代码模块化

功能组件化

待续...