先后端分离实践【转】

前言前端

为了解决传统Web开发模式带来的各类问题,咱们进行了许多尝试,但因为前/后端的物理鸿沟,尝试的方案都大同小异。痛定思痛,今天咱们从新思考了“先后端”的定义,引入前端同窗都熟悉的NodeJS,试图探索一条全新的先后端分离模式。java

随着不一样终端(Pad/Mobile/PC)的兴起,对开发人员的要求愈来愈高,纯浏览器端的响应式已经不能知足用户体验的高要求,咱们每每须要针对不一样的终端开发定制的版本。为了提高开发效率,先后端分离的需求愈来愈被重视,后端负责业务/数据接口,前端负责展示/交互逻辑,同一份数据接口,咱们能够定制开发多个版本。web

这个话题最近被讨论得比较多,阿里有些BU也在进行一些尝试。讨论了好久以后,咱们团队决定探索一套基于NodeJS的先后端分离方案,过程当中有一些不断变化的认识以及思考,记录在这里,也但愿看到的同窗参与讨论,帮咱们完善。
1、什么是先后端分离?express

最开始组内讨论的过程当中我发现,每一个人对先后端分离的理解不同,为了保证能在同一个频道讨论,先就什么是”先后端分离”达成一致。json

你们一致认同的先后端分离的例子就是SPA(Single-page application),全部用到的展示数据都是后端经过异步接口(AJAX/JSONP)的方式提供的,前端只管展示。
从某种意义上来讲,SPA确实作到了先后端分离,但这种方式存在两个问题:后端

    WEB服务中,SPA类占的比例不多。不少场景下还有同步/同步+异步混合的模式,SPA不能做为一种通用的解决方案。
    现阶段的SPA开发模式,接口一般是按照展示逻辑来提供的,有时候为了提升效率,后端会帮咱们处理一些展示逻辑,这就意味着后端仍是涉足了View层的工做,不是真正的先后端分离。浏览器

SPA式的先后端分离,是从物理层作区分(认为只要是客户端的就是前端,服务器端的就是后端),这种分法已经没法知足咱们先后端分离的需求,咱们认为从职责上划分才能知足目前咱们的使用场景:安全

    前端:负责View和Controller层。
    后端:只负责Model层,业务处理/数据等。性能优化

为何去作这种职责的划分,后面会继续探讨。
2、为何要先后端分离?服务器

关于这个问题,玉伯的文章Web研发模式演变中解释得很是全面,咱们再大概理一下:
2.1 现有开发模式的适用场景

玉伯提到的几种开发模式,各有各的适用场景,没有哪种彻底取代另一种。

    好比后端为主的MVC,作一些同步展示的业务效率很高,可是遇到同步异步结合的页面,与后端开发沟通起来就会比较麻烦。
    Ajax为主SPA型开发模式,比较适合开发APP类型的场景,可是只适合作APP,由于SEO等问题很差解决,对于不少类型的系统,这种开发方式也太重。

2.2 先后端职责不清

在业务逻辑复杂的系统里,咱们最怕维护先后端混杂在一块儿的代码,由于没有约束,M-V-C每一层均可能出现别的层的代码,日积月累,彻底没有维护性可言。
虽然先后端分离没办法彻底解决这种问题,可是能够大大缓解。由于从物理层次上保证了你不可能这么作。
2.3 开发效率问题

淘宝的Web基本上都是基于MVC框架webx,架构决定了前端只能依赖后端。
因此咱们的开发模式依然是,前端写好静态demo,后端翻译成VM模版,这种模式的问题就不说了,被吐槽了好久。
直接基于后端环境开发也很痛苦,配置安装使用都很麻烦。为了解决这个问题,咱们发明了各类工具,好比VMarket,可是前端仍是要写VM,并且依赖后端数据,效率依然不高。
另外,后端也无法摆脱对展示的强关注,从而专心于业务逻辑层的开发。
2.4 对前端发挥的局限

性能优化若是只在前端作空间很是有限,因而咱们常常须要后端合做才能碰撞出火花,但因为后端框架限制,咱们很难使用Comet、Bigpipe等技术方案来优化性能。

为了解决以上提到的一些问题,咱们进行了不少尝试,开发了各类工具,但始终没有太多转机,主要是由于咱们只能在后端给咱们划分的那一小块空间去发挥。只有真正作到先后端分离,咱们才能完全解决以上问题。
3、怎么作先后端分离?

怎么作先后端分离,其实第一节中已经有了答案:

    前端:负责View和Controller层。
    后端:负责Model层,业务处理/数据等。

试想一下,若是前端掌握了Controller,咱们能够作url design,咱们能够根据场景决定在服务端同步渲染,仍是根据view层数据输出json数据,咱们还能够根据表现层需求很容易的作Bigpipe,Comet,Socket等等,彻底是需求决定使用方式。
3.1 基于NodeJS“全栈”式开发

若是想实现上图的分层,就必然须要一种web服务帮咱们实现之前后端作的事情,因而就有了标题提到的“基于NodeJS的全栈式开发”

这张图看起来简单并且很好理解,但没尝试过,会有不少疑问。

    SPA模式中,后端已供了所需的数据接口,view前端已经能够控制,为何要多加NodeJS这一层?
    多加一层,性能怎么样?
    多加一层,前端的工做量是否是增长了?
    多加一层就多一层风险,怎么破?
    NodeJS什么都能作,为何还要JAVA?

这些问题要说清楚不容易,下面说下个人认识过程。
3.2 为何要增长一层NodeJS?

现阶段咱们主要之后端MVC的模式进行开发,这种模式严重阻碍了前端开发效率,也让后端不能专一于业务开发。
解决方案是让前端能控制Controller层,可是若是在现有技术体系下很难作到,由于不可能让全部前端都学java,安装后端的开发环境,写VM。
NodeJS就能很好的解决这个问题,咱们无需学习一门新的语言,就能作到之前开发帮咱们作的事情,一切都显得那么天然。
3.3 性能问题

分层就涉及每层之间的通信,确定会有必定的性能损耗。可是合理的分层能让职责清晰、也方便协做,会大大提升开发效率。分层带来的损失,必定能在其余方面的收益弥补回来。
另外,一旦决定分层,咱们能够经过优化通信方式、通信协议,尽量把损耗降到最低。

举个例子:
淘宝宝贝详情页静态化以后,仍是有很多须要实时获取的信息,好比物流、促销等等,由于这些信息在不一样业务系统中,因此须要前端发送5,6个异步请求来回填这些内容。
有了NodeJS以后,前端能够在NodeJS中去代理这5个异步请求,还能很容易的作Bigpipe,这块的优化能让整个渲染效率提高不少。
可能在PC上你以为发5,6个异步请求也没什么,可是在无线端,在客户手机上创建一个HTTP请求开销很大,有了这个优化,性能一下提高好几倍。

淘宝详情基于NodeJS的优化咱们正在进行中,上线以后我会分享一下优化的过程。
3.4 前端的工做量是否增长了?

相对于只切页面/作demo,确定是增长了一点,可是当前模式下有联调、沟通环节,这个过程很是花时间,也容易出bug,还很难维护。
因此,虽然工做量会增长一点,可是整体开发效率会提高不少。

另外,测试成本能够节省不少。之前开发的接口都是针对表现层的,很难写测试用例。若是作了先后端分离,甚至测试均可以分开,一拨人专门测试接口,一拨人专一测试UI(这部分工做甚至能够用工具代替)。
3.5 增长Node层带来的风险怎么控制?

随着Node大规模使用,系统/运维/安所有门的同窗也必定会加入到基础建设中,他们会帮助咱们去完善各个环节可能出现的问题,保障系的稳定性。
3.6 Node什么都能作,为何还要JAVA?

咱们的初衷是作先后端分离,若是考虑这个问题就有点违背咱们的初衷了。即便用Node替代Java,咱们也没办法保证不出现今天遇到的种种问题,好比职责不清。咱们的目的是分层开发,专业的人,专一作专业的事。基于JAVA的基础架构已经很是强大并且稳定,并且更适合作如今架构的事情。
4、淘宝基于Node的先后端分离

上图是我理解的淘宝基于Node的先后端分离分层,以及Node的职责范围。简单解释下:

    最上端是服务端,就是咱们常说的后端。后端对于咱们来讲,就是一个接口的集合,服务端提供各类各样的接口供咱们使用。由于有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,只是把本该就前端控制的部分交由前端掌控。

这种模式咱们已经有两个项目在开发中,虽然还没上线,可是不管是在开发效率,仍是在性能优化方面,咱们都已经尝到了甜头。
5、咱们还须要要作什么?

    把Node的开发流程集成到淘宝现有的SCM流程中。
    基础设施建设,好比session,logger等通用模块。
    最佳开发实践
    线上成功案例
    你们对Node先后端分离概念的认识
    安全
    性能
    …

技术上不会有太多须要去创新和研究的,已经有很是多现成的积累。其实关键是一些流程的打通和通用解决方案的积累,相信随着更多的项目实践,这块慢慢会变成一个稳定的流程。
6、“中途岛”

虽然“基于NodeJS的全栈式开发”模式很让人兴奋,可是把基于Node的全栈开发变成一个稳定,让你们都能接受的东西还有不少路要走,咱们正在进行的“中途岛”项目就是为了解决这个问题。虽然咱们起步不久,可是离目标已经愈来愈近!!

相关文章
相关标签/搜索