nodeJS(前后端分离、优势、不足

文章阅读，来自 前端之巅 去哪儿网 部分摘录

1.项目分离，页面分离

第一种是项目分离，承载页面分离。他的特点是简单，快速，前端只关注浏览器方面，除浏览器端之外都是后端负责。

缺点 ：

沟通成本高，前期，前端需要使用 ng 或者代理工具调试，后期，还要把页面给到后端，并且新建一个对应的路由。

2.项目分离，只是后端的页面，放到了前端项目里

后端只需要配置路由，最终上线时，由发布系统负责把前端中的页面，自动同步到后端相应的目录中。其中相应的目录需要前后端提前约定，不然后端在渲染页面的时候，就会找不到相应的文件。相比第一种方案，稍微有点进步。沟通成本会有一定的降低。

缺点 ：

不过如果需要在页面里做一些业务逻辑处理，还需要前端同学掌握和学习 velocity 语法，对于新同学而言看似掌握的了一门新语法，但实际操作起来并非想象中的流畅。

3.第三种方案是使用 Nodejs 作为页面渲染层，后端只负责数据的生产工作

这也是目前阶段主要的使用方式。它的优点是前端同学对于整个页面的生命周期有完全的控制权，包括开发，调试，部署，上线以及后期的性能监控，应用监控等等。可做的事情也更多，比如使用 React SSR 做同构渲染。

缺点 ：

对于前端同学的要求也会很高，除学习前端知识外，还要学习后端知识。

整个应用都是由前端统一负责，所以还需要接收报警电话或者短信，7*24 小时，都在待命状态。

1.一些前端开发，只关注浏览器端，服务器端开发关注很少，或者根本就不关注

2.认为 Node.js 只适合开发一些工具类的功能，相对于后端开发来看它只是个玩具

3.Node.js 的生态不如其他后端语言生态健全

4.涉及到后端开发的知识面比较广，在没有这些基础知识或者经验积累的基础上，考虑问题比较片面，最终做出的系统问题比较多，容易被后端鄙视

看似问题很多，但实质上只有两个原因，

1，自身知识储备不够。

2，对 Node.js 了解不深，不敢应用在生成环境中，即使应用到生产环境，一旦出现问题，不能快速及时的处理，导致高层认为还不如其他后端语言稳定，降低了我们的话语权。 (很中肯，不摸底，不敢用于项目)

1，提高开发效率，因为有了 Node 之后就不需要配置 Nginx 了，也不需要配置一些代理工具了，所有的页面生命周期都是由前端统一去管理的，这时候不需要其他人进行合作。

2，降低沟通成本，除了接口格式外，不需要和后端进行交互了；

3，前后端职责也更为清晰，因为这时候，界限更为清晰了，后端只负责生产数据，它只提供数据就可以了，至于数据怎么消费，以及怎么用，都由前端去做；

4，可以同时使用 React SSR 技术，做到首屏渲染，提高用户体验，除了首屏之外，还可以做异步的加载、SEO 等操作。

5，Node.js 可提供一些服务，不仅能让我们使用，还可以对外使用，如 RESTful API，这样就不用有求于后端了。

/---------------------------------------------文章摘录结束-------------------------------------------------/

除了号称nodejs界jQuery的express，

另外两个比较不错的

一个是 360 团队的 Thinkjs ，

一个是阿里的 Eggjs

随着互联网的不断发展，越来越多的消费者都开始通过移动端来访问网络接收自己需要的信息。而这些信息的传播都是需要通过移动端网页来实现的，所以，昆明北大青鸟http://www.kmbdqn.cn/今天就一起来了解一下关于移动端web网页的优化方法。

WEB服务端优化

有货的WEB端主要使用了nodejs，基于后端服务提供的HTTP接口服务来实现的前后端分离，这里的服务端优化主要是指在nodejs实现的web服务端进行优化。

优化的目的是提升服务端的响应和并发能力，充分发挥nodejs的异步非阻塞的特性，主要从以下几个方面去优化。

接口服务调用的优化

对于一个页面展示的路由，要处理这个路由，可能需要调用多个接口并且进行进行界面逻辑的处理。

接口合并我们对于一个页面调用可以合并的接口，进行接口合并，减少接口调用次数，如：以商品详情页为例，商品的一些特性，可以在一个接口返回，尽可能的减少接口调用的个数，因为每次接口的处理都有网络IO,对象序列化，压缩和解压的过程。

接口异步调用但是并不是所有的接口都可以合并，对于无法合并的接口，我们尽量使用node的异步非阻塞的特性，进行异步调用，同时调取多个接口，而调用耗时取决于较慢的接口。

这里要说明一点：对于接口依赖，如A接口依赖B接口的返回结果，像这种情况，我们最好梳理下接口设计，减少这样的串行调用，因为这样，调用耗时是多个接口耗时的总和。

减少接口交互数据返回的数据较多的情况下，会导致JSON序列化，数据批量对象处理，产生额外的性能损耗。可以做下接口返回数据结构的精简，返回必要的字段(页面会展示用到的数据)以及可以调整返回item个数。从而达到减少数据的返回消息体的大小。此外请求接口时需要gzip压缩，可以大大的减少网络传输的时间，尽管需要解压会消耗一部分CPU的时间，但是对接网络IO的损耗，还是值得的。

业务处理的优化

现在我们主要的服务端业务处理，主要对于页面逻辑的处理，如路由控制，会话处理，视图对象处理，模板渲染。我们在这些处理过程中进行了一些优化。

模板渲染的优化

我们在实际使用过程中，发现模板的渲染是十分消耗性能的，特别的模板的预处理过程，如果预处理过程是在用户访问过程中去处理，会慢不止一个数量级，所以我们把预处理的过程提前了(改造了hbs)，在启动web应用时，已经预编译完成。同时我们发现handlebars的一些默认配置属性，如缩减处理，在字符串拼接过程中会损耗一定的性能，所以可以关闭html片段的缩减。

nodejs优势在于原型开发快，学习门槛低，简单业务运行效率高于java等后台脚本语言的vm。

劣势同样明显，javascript引擎基于事件的函数回调模型既是优势又是劣势：导致复杂逻辑失控，不能用于生产环境。此架构并非新兴事物，早年的windows 3的消息模型类似：所谓的协同式多任务（不展开）。最终不得不让步于抢占多任务。导致入门易，优化难，难调试，大型业务框架不易成型

---