先后端分离概述

一 先后端分离的目的和做用
       作Web开发也能够说是B/S架构开发，B端和S端从技术体系角度而言异构性很大，换而言之就是B端使用的技术和S端使用的技术不适于同一个体系，这样的结果致使实际开发中，很难作到专业分工，若是项目开发过程当中管控不到位，这样的问题可能会影响到整个项目的开发质量，所以先后端分离的目的之一就是要作到专业化分工，提升项目的质量和开发效率。
       随着技术的发展，当下的Web开发形势已经和之前有了很大的不一样，早期的Web项目是一个封闭的项目，用户从浏览器里看到的页面直到后台数据库都是在一个项目里集成的，而如今Web系统的规模愈来愈大，中大型的Web系统是一个开放式的系统，开放型的系统用户在浏览器发起的请求可能会转发到外部的系统里进行处理，或者是本地的系统和外部系统一块儿完成请求的处理，此外有的请求可能不会直接请求数据库，而是请求缓存服务器，这些变化几乎都是发生在Web系统的服务端，先后端耦合度很高的Web系统服务端的复杂度提高必然带来了Web前端的复杂度的提高。所以Web前端从系统架构的角度也须要更加专业的管控，管控的做用之一就是先后端进行分离，下降前端对服务端的依耐性。
      富客户端应用的普及致使Web前端技术开发更加专业化，Web前端工程师成为一个独立的技术岗位，Web前端开发技术的难度也愈来愈高，先后端的分离就是为Web前端开发营造一个良好的开发环境，不要让前端工程师被一些不可控的外在因素所影响（例如：先后端的耦合性），最后致使前端不能专心致志作出更加好的做品。因此，先后端分离是让先后端更加专业化，在技术和管理上将前端角色更加明确，更深刻的挖掘前端开发的价值。

二 现有系统架构给先后端带来的问题以及解决方法

       上图是目前大部分系统的架构图，虽然有些系统采用分布式架构，层与层之间使用了远程调用框架，可是本质上都逃不开上面这个架构设计。这张图是一张比较合理的图，在实际开发里最常发生的事情就是控制层（Control）越过服务层（Service）直接处理下面的资源。

　　先后端耦合的问题主要发生在控制层（Control），控制层是前端和服务端交互的边界，可是在开发过程当中控制层（Control）和服务层（Service）经常混淆不清，这就是先后端耦合度高的重要缘由。

　　所以要先后端解耦，就是要划清控制层的边界，控制层到底该属于前端仍是服务端，在MVC模式里控制层做用是调度，控制层不是写业务逻辑的地方，所以将大量业务逻辑写到控制层实际上是违背了MVC模式的思想，同时控制层是前端和服务端通信的桥梁，其实控制层是参入了前端的工做任务，既然控制层要剥离业务操做同时控制层也要参入前端应用的开发，那么将控制层归为前端的一部分是彻底合情合理合规的。

　　把控制层剥离了业务逻辑处理可能会让人不知道如何开发了，我以为有这种想法的人是开发时候没有理解透MVC模式思想，编程随意性大养成了坏习惯，这个就须要这些人一点点去适应技术新趋势的发展。

　　先后端分离的终极目标应该是前端和服务端是彻底独立的项目，前端项目包含上图里的浏览器和控制层，服务端项目包括服务层、DAO层等等，前端项目和服务端项目以高效的远程调用框架作通信介质，项目开发时候前端项目作前端的事情，服务项目作服务端的事情，这样就让服务端开发的人员没有机会在控制层乱写代码了，保证了Web前端环境的纯粹性，最后生产发布也要独立部署，这样就达到了先后端真正解耦，可是先后端的沟通机制也是不可或缺的，我以为它们之间的沟通使用高性能的远程调用框架，先后端相互约定通信报文格式。.

　　其实无论服务端仍是前端宏观流程无非是输入数据à数据处理à输出数据，可是服务端要把心思花在数据处理上，前端要更多关心的是输入输出数据时候的用户体验操做，服务端开发最大的问题就是违背MVC原则，代码编写的随意性，而前端无论出于安全仍是性能考虑，最好是尽可能少牵涉业务。前端和后端通信层的独立，会将先后端进行真正的解耦，前面我讲到先后真正问题就是前端和后端技术路线不一致，可是传统Web开发里先后端又要融为一体，这就致使先后端很难作到专业化分工，对于前端应该尽可能弱化通信级别的开发工做，前端通信编程只要知道调用哪一个接口，传什么参数，怎么处理响应信息就好了。这样就能让前端和后端实现真正的专业化。

 

 

       为何要分离？
　　若是只问“先后端分离的意义大么？”这是废话，由于从软件架构的角度 Web 的先后端从一开始不就一直是分离的么，并且 browser、server 可能将永远分离下去。
　　为了了解这个问题，咱们有必要先了解一下 Web的研发模式演变，关于这个题材，下面这篇博文说得不错，这边就不作搬运工了。
　　https://github.com/lifesinger/blog/issues/184
　　咱们不能“为了分离而分离”，而应该“为了真正理解web开发、为了更好完成需求而分离”

     

    先后端分离的误区？

　　一、前端人员配备是否充足？

　　因为所在公司以往项目采用传统开发风格，即之后端MVC为主的开发模式，前端人员仅仅提供静态html页面，其他工做皆由后端开发人员完成。采用先后端分离模式能够减后台负担，加快研发效率，固然，前提是前端能作好的话。以往只须要提供静态页面的前端人员，在先后端分离模式中要负责项目的view+controller部分，即除了静态页面，还须要负责页面的全部交互代码、以及nodejs与视图层以及后端API的交互工做，无疑增长了前端人员的学习成本，在没有足够知识和人才储备的状况下，只能让前端人员加班加点。结果是大量前端人员离职（PS：作这么多事，工资总得加吧！）

　　二、先后端职责分配？

　　不少公司认为采用先后端分离以后，先后端只须要经过指定API进行交互便可，前端负责页面渲染，Nodejs负责路由分配，后端提供API。忽视了大量关键工做，职责分配和细节处理没有相应文档规定，缓存机制、图片上传下载、数据校验、语言国际化等等并无出具相应信息。另外，大量忽视了nodejs层的做用，仅仅把nodejs当成一个路由中转，这一方面也是对nodejs技术的不熟悉致使的，其实nodejs能负责不少事，除了复杂业务逻辑处理和数据操做由Java 负责，大量工做彻底能够在nodejs层处理。（PS：仍是基础不够致使的！）

　　三、后端API是否Restful风格？

　　不少公司采用了先后端分离模式后，后端API仍然采用以往的传统风格，这是不合理的，Restful风格的API应该是先后端分离的最佳实践。ResultFul推荐每一个URL能操做具体的资源,并且能准确描述服务器对资源的处理动做，一般服务器对资源支持get/post/put/delete/等，用来实现资源的增删改查。先后端分离的话，这些api-url是对接的桥梁，采用resultFul接口地址含义才更清晰、见名知意。（PS：用了Spring4.x 居然还不用rest风格，说不过去啊）

　　 四、先后端协做模式？

　　先后端分离后，不管是API接口的对接仍是测试工做，都涉及到先后端人员的沟通，不少公司采用先后端分离后，先后端协做模式配协力度底，互相等待，开发效率低下，反而不如传统的开发模式。例如：当后端 API 没有编写完成时，前端没法进行调试，这就致使了前端会被后端阻塞的状况。其实像这种互相等待的模式须要改进， Mock Server 可能能够解决一些问题。

如何先后端分离？

　　怎么作先后端分离？大方向就是

　　后端专一于：后端控制层（Restful API） & 服务层 & 数据访问层；

　　前端专一于：前端控制层（Nodejs） & 视图层

　　本人认为的先后端分离模式应该是这样，固然这不必定正确：

　　一、项目设计阶段，先后端架构负责人将项目总体进行分析，讨论并肯定API风格、职责分配、开发协助模式，肯定人员配备；设计肯定后，先后端人员共同制定开发接口。

　　二、项目开发阶段，先后端分离是各自分工，协同敏捷开发，后端提供Restful API，并给出详细文档说明，前端人员进行页面渲染前台的任务是发送API请(GET,PUT,POST,DELETE等)获取数据（json，xml）后渲染页面。

　　三、项目测试阶段，API完成以前，前端人员会使用mock server进行模拟测试，后端人员采用junit进行API单元测试，不用互相等待；API完成以后，先后端再对接测试一下就能够了，固然并非全部的接口均可以提早定义，有一些是在开发过程当中进行调整的。

　　四、项目部署阶段，利用nginx 作反向代理，即Java + nodejs + nginx 方式进行。

能够在深刻理解一下：http://itindex.net/detail/55771

https://github.com/lifesinger/blog/issues/184

 

本文参考：https://www.cnblogs.com/sharpxiajun/p/3531665.html

https://www.cnblogs.com/shanrengo/p/6397734.html