先后端分离，是为了彼此更好

 

1、被误解的先后端分离

 

在Web应用开发过程当中，业界对先后端的分界线彷佛一直都没有肯定的概念，不过大多数人以浏览器做为先后端的分界线。将浏览器中为用户进行页面展现的部分称为前端，而将运行于服务器，为前端提供业务逻辑和数据准备的全部代码统称为后端。

 

虽然先后端分离在数年前就已经开始受到关注，但不少人对它倒是只闻其声，未见其形，因此对它产生了一些误解，误觉得先后段分离只是一种Web应用的开发模式，只要在Web应用的开发期进行了先后端开发工做的分工就是先后端分离。

 

其实并不是如此，准确的说，先后端分离并不仅是开发模式，而是Web应用的一种架构模式。在开发期，先后端工程师能够经过约定好交互接口，实现并行开发；在运行期，先后端分离模式须要对Web应用进行分离部署，先后端之间使用HTTP请求进行交互。然而做为应用的架构模式，先后端分离并非经过这样一句话就能一律而谈的，咱们能够从交互形式、代码组织方式、开发模式三个方面对先后端分离进行认识。

 

一、交互形式

在先后端分离架构中，后端只须要负责按照约定的数据格式向前端提供可调用的API服务便可。先后端之间经过HTTP请求进行交互，前端获取到数据后，进行页面的装配和渲染。

 

二、代码组织方式

 

在传统架构模式中，先后端代码存放于同一个代码库中，甚至是同一工程目录下。页面中还夹杂着后端代码。先后端工程师进行开发时，都必须把整个项目导入到开发工具中。

 

而先后端分离模式在代码组织形式上有如下两种：

 

半分离

先后端共用一个代码库，可是代码分别存放在两个工程中。后端不关心或不多关心前端元素的输出状况，前端不能独立进行开发和测试，项目中缺少先后端交互的测试用例。

分离

先后端代码库分离，前端代码中有能够进行Mock测试（经过构造虚拟测试对象以简化测试环境的方法）的伪后端，能支持前端的独立开发和测试。然后端代码中除了功能实现外，还有着详细的测试用例，以保证API的可用性，下降集成风险。

 

三、开发模式

 

传统的MVC架构开发，没有进行先后端分离，前端工程师负责编写HTML，完成前端页面设计，而后给后端工程师员套界面，使用模板技术将前端代码转换成JSP页面，同时内嵌java代码。应用运行期，将所有代码进行打包，部署到同一服务器上，或者进行简单的动静态分离部署。

 

此时，应用的开发流程以下图所示。

 

在先后端分离架构中，前端工程师只须要编写HTML、js、CSS等前端资源，而后经过HTTP请求调用后端提供的服务便可。除了开发期的分离，在运行期先后端资源也会进行分离部署。

 

先后端分离以后，开发流程将以下图所示。

 

经过上面的两幅流程图，不难发现，在开发模式上，先后段分离不只仅只是工程师的分工开发，更重要的意义在于实现了先后端的并行开发，和简化了开发流程。

 

 

2、为何要“离”：4个好处

 

 

从新认识先后端分离以后，想必你们内心都会有疑问，先后端分离模式与以前的Web应用架构相比可谓是截然不同，咱们为何要进行先后端分离呢？正如莎士比亚在《哈姆雷特》中的经典名句同样，分仍是不分，这是个问题。

 

从目前应用软件的发展趋势来看，一方面，用户愈来愈注重软件的体验感，随着互联网的蓬勃发展，应用开始走向多终端化；另外一方面，大型应用的架构模式正纷纷向着云化、微服务化发展。

 

虽然过去的应用架构暂时还能支撑起当下应用的开发，可是各类弊端已经开始浮出水面，几年前能带来开发便捷优点的先后端代码混合模式，在当下已经成为了拖慢咱们前进步伐的泥沼，让咱们屡屡吃痛。咱们之因此开始尝试先后端分离，是为了能在将来得到更好的发展，指望经过先后端分离架构，来为咱们带来如下4个方面的提高。

 

为孵化优质产品打造精益团队

 

正如康威定律所述，产品是组织沟通结构的缩影，软件开发团队想要孵化出优质的产品，必须先打造一个精益的开发团队。开发团队的组织划分是如何影响产品的孵化呢，咱们经过下面的示例来进行说明。

 

若是开发团队是按照业务边界进行划分的，开发出来的产品将可能会是微服务的架构。

 

 

若是开发团队分为前端团队、后台服务团队和DBA团队，产品将会成长为下面的架构。

 

 

应用不断迭代，功能日趋完善，开发团队也随之壮大。虽然如今有些人比较推崇全栈工程师，一位全栈工程师就能支持先后端的全部开发。可是试想一下，若是在开发团队中先后端开发分隔不清，职责边界模糊不明，代码均由相同的工程师完成，久而久之先后端代码的耦合程度可想而知。

 

经过将开发团队先后端分离化，让先后端工程师只须要专一于前端或后端的开发工做，使得先后端工程师分别自治，培养其独特的技术特性，而后构建出一个全栈式的精益开发团队。这样的开发团队可以快速应对需求的变动以及市场的复杂多变，打造出架构清晰、先后端并重的优质产品。

 

提高开发效率

 

传统开发模式中，先后端开发强依赖。须要前端工程师先完成静态页面的Demo，后端工程师才能将页面Demo翻译成VM模板，若是前端页面出现变更，又会须要先后端工程师再走一次开发流程，如此一来开发效率将会变得很低。

 

先后端分离之后，能够实现先后端代码的解耦，只要先后端沟通约定好应用所需接口以及接口参数，即可以开始并行开发，无需等待对方的开发工做结束。与此同时，即便需求发生变动，只要接口与数据格式不变，后端开发人员就不须要修改代码，只要前端进行变更便可。如此一来整个应用的开发效率必然会有质的提高。

 

完美应对复杂多变的前端需求

 

Web应用的用户体验关注度与日俱增，使得应用的前端界面须要有华丽酷炫的外观，简单易用的操做，变化多样的界面设计和个性化的自定义展现。这使得前端开始变重，逻辑复杂程度加大，渲染效果多样化加重。

 

移动终端的大范围普及，让应用向着多终端化发展，这就要求前端页面须要对不一样终端的显示都能进行配适。

 

传统开发模式中，先后端工程师开发职责不明确，面对复杂多变的前端需求，开发团队势必会变得捉襟见肘、不堪重负。

 

若是开发团队能完成先后端分离的转型，打造优秀的先后端团队，开发独立化，让开发人员作到专一专精，开发能力必然会有所提高，可以完美应对各类复杂多变的前端需求。

 

加强代码可维护性

 

先后端分离后，应用的代码再也不是先后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不管是代码阅读仍是代码维护都会比之前轻松。

 

 

 

3、我要不要“离”：4种场景

 

 

然而任何一项技术都不是银弹，先后端分离也是如此。虽然先后端分离架构能带来众多优点，但终究得创建在开发团队适合的基础之上。咱们暂且之前端页面的渲染效果与逻辑复杂程度把Web应用大体分为轻前端、重前端、先后均衡三种类型，而后加上如今热门的微服务架构应用，一块儿探讨一下什么样的Web应用适合进行先后端分离。

 

轻前端

页面布局简单，颜色、字体类型较少

对前端界面的渲染效果没有高要求，无动画效果

只有少许、简单的业务逻辑

只须要在不一样终端上布局能适应

 

对于这样对前端渲染要求不高，业务逻辑简单的轻前端应用来讲，由于涉及到的前端技术并不复杂，因此不必追求先后端分离。将先后端代码放到一块儿，反而更方便进行开发，可是在开发过程当中须要作到关注点分离（Separate Concern）。

 

重前端

页面布局复杂，使用了多种颜色和字体

须要有较高的页面渲染效果，有大量动画

前端页面中包含有复杂业务逻辑

须要在不一样终端和浏览器上保证布局适应和渲染效果

 

对于重前端应用，建议采用先后端分离架构，若是开发团队中前端工程师不足，须要尽早完善前端团队的建设，确保先后端并重。

 

先后均衡

页面布局适中，使用的颜色和字体种类很少

页面中使用了少量动画效果

业务逻辑较为简单，可下沉到后端实现

只须要在不一样终端上布局能适应

 

对于先后端均衡应用，建议综合团队的人员结构和将来发展方向进行考虑。若是在团队中前端工程师的占比不高，后续也没有继续发展前端的计划，那么就不建议过于追求先后端分离。若是对将来有更高指望，即便在前端工程师占比不高的状况下，依然建议团队尝试先后端分离转型，开始着手培养合适的前端工程师。若是团队中已经有了至关规模的前端工程师，建议当即转向先后端分离，而且尽早作到先后端代码分离，为前端提供一个能够进行开发调试的伪后端。

 

微服务架构应用

 

 

微服务架构应用由大量微服务提供者构成，共同为用户提供服务。在微服务架构中，不少微服务提供者都是基于SpringBoot实现的，经过API Getway（API网关）进行微服务的整合，而后在一个统一的前端门户上为用户提供所需服务。

 

微服务基于SpringBoot开发，要达到快速交付的目的，而且每一个微服务的粒度都比较小，这必然须要微服务的先后端由不一样的工程师分别实现，而后相互之间使用Restful进行通信。若是仍是沿用以前的开发模式，将会增大微服务架构应用的构建难度。而先后段分离模式正是解决这一难题的良药。

 

 

4、分离部署方案浅析

 

先后端开发分离以后，应用在部署时也须要进行先后端分离。在进行先后端分离方案选择的时候，须要结合项目的需求状况和用户群体来考虑。目前业内较为经常使用的先后端分离部署方案有以下几种。

 

一、Nginx+Server

 

将前端资源部署在Nginx上，后端服务部署在常规的服务器。当浏览器发起访问请求的时候，若是请求的是页面资源，Nginx直接把资源返回到前端；若是请求是调用后端服务，则通过Nginx转发到后端服务器，完成响应后经Nginx返回到浏览器。

 

 

这个方案比较简单，易于实现，并且能达到先后端解耦的目的。

 

可是对于页面量比较大，须要有良好SEO的应用来讲，此方案缺点也较为明显。由于Nginx只是向浏览器返回页面静态资源，而国内的搜索引擎爬虫只会抓取静态数据，不会解析页面中的js，这使得应用得不到良好的搜索引擎支持。同时由于Nginx不会进行页面的组装渲染，须要把静态页面返回到浏览器，而后完成渲染工做，这加剧了浏览器的渲染负担。

 

二、Node+Server

 

这是淘宝所使用的先后端分离模式，在浏览器与后端服务器之间增长一个了Node Server做为中间层，将前端资源部署到Node Server中。Node Server中还包含了一层Model Proxy，负责与服务端进行通讯。

浏览器发出的请求都被Node Server接收，而后经过Model Proxy调用后端服务器提供的服务。Node Server获得后端服务器反馈，接着在Node Server中完成页面的组装渲染，把最终页面返回给浏览器。

 

如此一来不只达到了先后端解耦的目的，还解决了浏览器渲染负担太重的问题，为SEO提供了比较好的支持。

 

但在这样的模式中，浏览器全部发出的请求都须要通过Node Server进行中转，而后才能到达后端服务器。在实际的应用中，并非全部的请求都须要页面渲染，只要在页面上直接调用后端服务器提供的服务便可。因此这个模式必然会对请求性能有所消耗

 

三、Nginx+Node+Server

 

为了能解决方案2中请求性能损失的问题，咱们能够考虑在其基础之上增长Nginx。浏览器发起的请求通过Nginx进行分发，URL请求统一分发到Node Server，在Node Server中进行页面组装渲染；API请求则直接发送到后端服务器，完成响应。

 

目前在已经有一个名为Goku的Go语言框架提供了这样的先后端分离解决方案。

 

 

经过对三种先后端分离方案的对比能够看出：

 

若是是企业级应用，不须要考虑对SEO的支持，浏览器渲染也能够忽略不计，Nginx+Server的模式无疑是最好的选择，实施成本相对来讲比较低；

 

若是是互联网应用，须要有良好的SEO支持，页面渲染工做量大，那应该选择Nginx+Node+Server的方案，各个方面都能获得比较好的兼顾。

 

 

5、总结

 

先后端分离并不是仅仅只是先后端开发的分工，而是在开发期进行代码存放分离、先后端开发职责分离，先后端可以独立进行开发测试；在运行期进行应用部署分离，先后端之间经过HTTP请求进行通信。先后端分离的开发模式与传统模式相比，能为咱们提高开发效率、加强代码可维护性，让咱们有规划地打造一个先后端并重的精益开发团队，更好地应对愈来愈复杂多变的Web应用开发需求。

 

传统的先后端混合开发模式，虽然久经考验，到如今依然仍是能支撑起应用的开发。可是放眼将来，应用的云化、微服务化势不可挡。同社会分工精细化同样，先后端开发的精细化也是必然趋势。技术在持续进步，架构在不断演进，只有紧跟发展的脚步，不断调整项目管理方式，软件开发模式，才能在互联网浪潮中把握机会，乘风破浪。

 

先后端分离，是为了让彼此更好。