前言：分离模式研究前后端分离有一段时间了。刚好公司有一个大项目，决定尝试使用前后端分离的模式，所以就参与了进去。项目自2016年初立项以来，一路顺风顺水，但问题也越来越多。绝对不是前后端分离的模式不好，而是很多公司在前后端分离的时候没有做好。得准备网上介绍前后端分离的文章并不少见。接下来，我就用一点肤浅的语言来谈谈这个，很遗憾。为什么分开？如果你只问“前后端分离有意义吗？”这是废话，因为从软件架构的角度来说，Web的前后端从一开始就一直是分离的，浏览器和服务器可能永远分离下去。为了理解这个问题，我们有必要了解一下Web研发模式的演进过程。关于这个话题，下面这篇博文写的很好，这里就不做搬运工了。https://github.com/lifesinger/blog/issues/184我们不能“为了分离而分离”，而是应该“为了真正理解web开发，更好的完成需求而分离”。前后端分离的误区？1、前端人员配置是否充足？由于公司之前的项目采用传统的开发方式，即后端基于MVC的开发模式，前端人员只提供静态html页面，其余工作由后端开发人员完成.采用前后端分离模式，可以减轻后台负担，加快研发效率。当然，前提是前端能做好。以往只需要提供静态页面的前端人员以前后端分离的方式负责项目的view+controller部分，即除了静态页面，还需要负责页面所有的交互代码，以及nodejs、view层、后端API的交互工作，无疑会增加前端人员的学习成本。没有足够的知识和人才储备，前端人员只能加班加点。结果导致大量前端人员离职（PS：做这么多事，工资肯定要涨！）2、前后端职责分配？很多公司认为，前后端分离后，前后端只需要通过指定的API进行交互，前端负责页面渲染，Nodejs负责路由分发，后端提供API。一大批重点工作被忽视，职责分工和细化处理没有相应的文件规定，缓存机制、图片上传下载、数据校验、语言国际化等方面也没有出台相应的信息。另外，很大程度上忽略了nodejs层的作用，只把nodejs当作路由中转。这也是对nodejs技术不熟悉造成的。其实nodejs可以负责很多事情，除了复杂的业务逻辑处理和数据操作由java来处理。很多工作完全可以在nodejs层处理。（PS：还是基础不够造成的！）3、后端API是Restful风格的吗？是前后端分离的最佳实践。ResultFul推荐每个URL都可以操作特定的资源，能够准确描述服务器对资源的处理动作。通常，服务器支持get/post/put/delete/etc。如果前后端分离的话，这些api-url就是对接的桥梁，resultFul接口的地址的含义就更加清晰明了。（PS：用了Spring4.x，没有用rest风格，不合理。）4、前后端协同模式？前后端分离后，前后端配合弱，相互等待，开发效率低，不如传统开发模式。比如：当后端API没有写的时候，前端无法调试，导致前端会被后端阻塞的情况。其实这种等待模式还有待改进，MockServer或许可以解决一些问题。前后端如何分离？前后端如何分离？大方向是后端侧重于：后端控制层（RestfulAPI）&服务层&数据访问层；前端侧重于：前端控制层（Nodejs）&视图层我觉得前后端分离模式应该是这样的，当然这不一定是正确的：1.在项目设计中阶段，前后端架构负责人对项目进行整体分析，讨论确定API风格、职责分工、开发辅助方式，确定人员配置；设计确认后，前后端人员共同制定开发接口。2.在项目开发阶段，前后端分离，各自分工，协同敏捷开发，后端提供RestfulAPI，并给出详细的文档说明，前端人员执行页面渲染的任务前端是获取数据（json、xml）后，发送API请求（GET、PUT、POST、DELETE等）渲染页面。3、项目测试阶段，API完成前，前端人员使用mockserver进行模拟测试，后端人员使用junit进行API单元测试，互不等待；并不是所有的接口都可以预先定义，有些是在开发过程中调整的。4.在项目部署阶段，使用nginx作为反向代理，即Java+nodejs+nginx。从JSP+Servlet+JavaBean的经典MVC时代，到SSM（Spring+SpringMVC+Mybatis）和SSH（Spring+Struts+Hibernate）的Java框架时代，再到前端框架（KnockoutJS、AngularJS、vueJS、ReactJS）)统治了MV*时代，然后是Nodejs***的全栈时代，技术和架构一直在进步。虽然“基于NodeJS的全栈开发”模式很精彩，但是要让基于Node的全栈开发成为稳定的、被大家接受的东西，还有很长的路要走。创新之路不会停歇。无论是前后端分离模式还是其他模式，都是为了更方便的解决需求，但都只是一个“中转站”。穿越的“中转站”可能会越来越多，但不要随波逐流。
