作者：李旭光
引用请标明出处
背景
前后端分离狭义上来讲是以浏览器为分界，应用在浏览器内部的技术为前端技术，主要负责页面展示的部分，应用在浏览器外的技术为后端技术，主要负责处理业务逻辑和数据准备工作，但是随着近几年NodeJs的崛起，前端的工作范畴明显扩大，前后端分离也不仅仅作为一种开发模式，更是web应用架构层面的一种模式。
认识
- 在开发阶段，前后端工程师要提前约定好数据交互的接口，从而实现并行开发和测试；
- 在运行阶段，前后端分离模式需要对web应用进行分离部署，前后端之前使用HTTP或者其他协议进行交互请求。（NodeJs或Ngnix）
由上述两条可以看出前后端分离分为开发阶段和部署阶段，通常来说我们做到的只是前后端分离开发，并没有做到分离部署。
分解
作为一种全新的架构模式，前后端分离需要从四个方面来比较和认识。
- 交互形式
- 开发模式/流程
- 代码组织方式
- 数据接口规范流程
一、交互形式
在前后端分离架构中，后端只需要负责按照约定的数据格式向前端提供可调用的API服务即可。前后端之间通过HTTP请求进行交互，前端获取到数据后，进行页面的组装和渲染，最终返回给浏览器。
这里有一个经常引起激烈讨论的话题就是，“约定的数据格式”，是后端直接提供给前端可直接使用的数据格式，还是简单的数据库拉取数据不做加工直接推给前端，这个要视具体的项目情况而定，如果后端代码需要支持的不仅仅是一端，比如要同时适配pc端、手机端等多个终端，其多终端数据展现的形式如果各不相同，那后端只需要提供满足多端的基础数据格式即可，但如果只需要满足单个终端，那么建议直接将前后端数据格式进行统一处理，方便前后端协同，数据处理可以放在java端做也可以放在NodeJs端做，视人员配备情况而定，但绝不是后端不做任何处理就将数据返回给前端，完全由前端组织数据。
二、开发模式/流程
在前后端分离模式未诞生之前，前后端属于一个整体，那时使用的是MVC架构模式，前端对应的就是View层，主要通过html/css/js实现静态页面和动态效果，在有后端进行模板变量的嵌套和一些页面逻辑的处理，最终打包成一个整体，部署到同一服务器上，同时会进行简单的动静态分离部署。
此时开发的流程如下：
需求=》前后端并行开发=》前端开发静态页面=》后端套模板=》集成问题=》前后端调整=》再集成=》解决集成问题=》交付上线
// TODO 这里插图
出现前后端分离架构之后，前端工程师只需要编写前端页面+前端数据、业务逻辑处理，之后通过HTTP或其他请求方式调用后端提供的服务接口就可以了，而且除了在开发周期可以进行前后端分离，在部署阶段，前后端也可进行分离部署。
// TODO 这里插图
此时开发的流程如下：
需求=》设计接口、约定数据=》前后端并行开发=》集成=》调整=》集成成功=》交付上线
通过上面的描述及流程，不难发现，前后端分离的开发方式不仅仅从分工上进行了区分，更重要的是在并行开发的问题上解决了反复集成等前后端互相影响的问题，从而降低了开发的难度，简化了开发的流程。
三、代码组织方式
// TODO 这里插图
在传统的开发模式架构下，前端代码是作为项目的静态资源存在于项目工程下，页面中还夹着一些后端代码如jsp、php等技术，前后端开发时需要将整个项目代码完整的引入开发工具才能进行开发，前后端同时维护一份代码，这种开发方式导致前后端代码互相影响，因此前后端分离势在必行。
而前后端分离模式在代码的组织形式上由以下两种形式组成：
- 半分离
前后端仍共用一个代码库，但是代码分别存放在两个工程中。后端不关心或很少 关心前端元素的输出情况，前端不能独立进行开发和测试，项目中缺乏前后端 交互的测试用例。 - 完全分离
完全分离后，前端代码可以通过Mock来模拟后端请求，从此可以独立进行前端开发和测试。后端代码只需要按照跟前端约定好的接口格式写出完整的测试用例，确保接口的可用性。通过上述手段，降低开发集成风险。
四、数据接口规范流程
通过上面三段的描述，我们可以看出前后端分离开发模式最重要也是最初的阶段就是数据接口的确定，因此在项目开发前必需先进行数据和接口的定义，数据接口的定义需要前后端开发共同商定，包括确定的数据格式，交互形式，并生成一份接口文档供前后端开发人员使用。之后才是并行开发。开发期间前后端双方需要严格按照确定的数据接口文档进行开发，前端开发完之后可以利用mock服务独自进行接口测试，后端也可以利用postman或其他接口测试工具进行测试，并提供完整的接口测试用例，然后前后端进行功能联调，最后再提交线上测试，也可进行自动化测试。
// TODO 这里插图
分离后的收益
到底分不分，如何分是个持续讨论的话题，通过上述的内容大家已经了解到了，什么是前后端分离，也知道如何进行前后端分离开发部署，那么前后端分离能带来哪些收益呢？
首先，就目前的软件开发应用趋势来看，越来越注重用户的体验性，而且架构越来越大，服务越来越小，而且终端设备越来越丰富，而原来不分离的方式已经不能支撑现在的发展趋势，因此前后端分离开发及部署将势在必行。
而且采用前后端分离的架构之后，我们将有如下几点提升：
前后端分离后，前后端将不再互相纠缠而是各自在自己熟悉的领域进行开发工作，这将有利于前后端深化优化各自的代码，培养各自独特的技术特性，从而开发出更加优秀的应用，建立起专业精良的全栈开发团队。
通过前后端分离架构可以实现前后端开发从代码及开发流程上的完全解耦，只需要前后端共同商定好接口后，便可完全独立开发，只需要在联调阶段进行好协作，在此之前可以互不影响的进行并行开发，即是需求发生了变动，但只要不影响接口，后端既可以不用修改代码，只需前端进行变动即可，如此整体的开发效率将得到提升。
前后端分离后，能够更好的适应前端日益增多的的终端适配，代码解耦后复用率更高。
4.前后端分离后，前后端代码可以分别管理，代码不再混在一起，代码可维护性也增强了
前后端分离后收益不止以上四点，因为分离而带来的职责上、技术上、代码上、部署上的解耦让开发工作比以往任何时候都要更加专注和轻松。
注意事项
前后端分离误区
- 前端人员不充足，不能进行前后端分离。
此话说来是因为对前后端分离后职责区分不明确导致的问题，因为以往的前端只需要写静态页面就可以了，而前后端分离后前端也不仅仅需要写静态页面，而且还要为页面提供数据和页面逻辑的处理，但实际上可以根据团队情况来区别对待，如果团队前端人员充足，那么可以由前端人员负责多一些的工作，比如API请求后的业务逻辑的处理，页面逻辑的处理、页面数据的准备等，如果后端人员配备充足，那么上述几个环节仍然可由后端人员进行处理，前端开发仍然只是写静态页面，只是内容和逻辑不再写死而是通过js或其他手段如mvvm的框架进行处理。
- 前后端分离后前端任务加重，职责也不清晰。
如第一点描述可知，问题不在前后端分离的模式是否合适，而是任务分配和人员分配上的问题，如果前端能力强且人员比例较多，那么部分任务可以由前端承担，如果后端人员多，那么任务由后端承担。
- 后端开发需要增加接口开发工作，增加任务量。
无论如何后端开发都是需要写接口的，只是前后端分离后需要按照ResetFul风格写接口，或者采用最新的GraphQl的方式进行交互，如果说这个阶段需要前后端进行商量确定接口交互形式和数据格式花费了时间，但是在接下来前后端并行开发及问题解决上省掉的时间是更加可观的。
- 分离后仍出现互相等待的问题，反而不如传统开发模式快。
这个问题的产生其实也是由于对前后端分离后技术缺失导致的，常见情况是前端写完页面逻辑和假数据后后端开发还未完成接口开发导致无法进行联调，实际上前端通过mockserver等方式是可以解决一些问题的。
前后端分离适用场景
现代化的web应用适合用前后端分离的开发方式。
原因有以下几点：
- web应用前端页面交互复杂。
- 页面渲染数据量大。
- 页面包含复杂的业务逻辑。
- 终端适配情况多。
- 分布式架构，微服务化应用场景。
前后端分离具体方案
总体方向
后端专注于：后端控制层（Restful API） & 服务层 & 数据访问层；
前端专注于：前端控制层（Nodejs） & 视图层
项目设计阶段，前后端架构负责人将项目整体进行分析，讨论并确定API风格、职责分配、开发协助模式，确定人员配备；设计确定后，前后端人员共同制定开发接口。
项目开发阶段，前后端分离是各自分工，协同敏捷开发，后端提供Restful API，并给出详细文档说明，前端人员进行页面渲染前台的任务是发送API请(GET,PUT,POST,DELETE等)获取数据（json，xml）后渲染页面。
项目测试阶段，API完成之前，前端人员会使用mock server进行模拟测试，后端人员采用junit进行API单元测试，不用互相等待；API完成之后，前后端再对接测试一下就可以了，当然并不是所有的接口都可以提前定义，有一些是在开发过程中进行调整的。
项目部署阶段，利用nginx 做反向代理，即Java + nodejs + nginx 方式进行。
技术手段
- 前端技术栈：前端代码 + mock服务
- 后端技术栈：postman + 接口 + 后端业务逻辑 + 数据库
- 公共依赖：接口文档/接口测试工具
常用的mock服务为jsonserver
常用的接口测试工具为postman、rap、swagger、doclever
部署方案
- 第一阶段为前后端同一个代码库，同一个服务器，集中部署。
- 第二阶段引入Ngnix服务作为中间件，前端向Ngnix发请求，Ngnix向后端服务发请求，由于Ngnix为静态服务器，所以在seo优化上和页面性能优化上效果不明显，因此前端仍需与后端进行配合才能达到整体的优化。
浏览器 =》 Ngnix（前端机）=》Ngnix（后端机可没有）=》Server服务
- 第三阶段引入nodejs作为中间层，将前端资源部署到Server层。同时实现数据代理服务，负责与提供数据的后端进行通信。
浏览器=》Ngnix（前端机）=》NodeServer =》Server服务
浏览器向前端机发送请求，由Ngnix进行分发，url统一分发至NodeServer，在Node Server中根据请求类型从后端服务器上通过RPC服务请求页面的模板数据，然后进行页面的组装和渲染；API请求则直接转发到后端服务挖成相应。
前后端分离部署方案比较
| 属性字段 | 传统模式 | Ngnix+Server | Node+Server | Ngnix+Node+Server |
|---|---|---|---|---|
| SEO | ok | no | ok | ok |
| 浏览器渲染负担 | ok | no | ok | ok |
| 前后端耦合 | no | ok | ok | ok |
| 请求相应效率 | no | ok | no | ok |
结语
随着前端技术的快速发展和对用户体验日益增长的需求，前后端分离模式势必将会成为主流趋势。无论是从开发模式的角度上来说，还是对团队成长的角度上来说，前后端分离都会带来益处，让我们一同拥抱前后端分离，打造精良的开发团队，迎接日益复杂的web应用开发需求。
参考来源
- 张亚涛（前后端分离实践一）
- 《浅谈架构之路：前后端分离模式》
版权声明
Copyright by lixuguang
未经授权，严禁转载。如需转载，请联系作者。
