前后端分离方案以及技术选型

r囧r小猫 2021-07-04 20:11 649阅读 0赞

## 一.什么是前后端分离？ ##

理解前后端分离大概可以从3个方面理解：

1.  交互形式
2.  代码组织形式
3.  开发模式与流程

### 1.1 交互形式 ###

**前后端不分离**

后端将数据和页面组装、渲染好了之后，向浏览器输出最终的`html`；浏览器接收到后会解析`html`，解析引入的`css`、执行`js`脚本，完成最终的页面展示。

**前后端分离**

后端只需要和前端约定好接收以及返回的数据格式（一般用`JSON`格式），向前端提供`API`接口。前端就可以通过`HTTP`请求调用`API`的方式进行交互。前端获取到数据后，进行页面组装、渲染，最终在浏览器呈现。

### 1.2 代码组织形式 ###

**前后端不分离**

在web应用早期的时候，前端页面以及后台业务数据处理的代码都放在一个工程下，甚至放在同一目录下，前端页面夹杂着后端代码。前、后端开发工程师都需要把整套代码导入开发工具才能开发。此阶段下前后端代码以及工作耦合度太高，前端不能独立开发和测试，后端人员也要依赖前端完成页面后才能完成开发。最糟糕的情况是前端工程师需要会后端模板技术（`jsp`），后端工程师还要会点前端技术，需要口头说明页面数据接口，才能配合完成开发。否则前端只能当一个“切图仔”，只输出`HTML、CSS`、以及很少量与业务逻辑无关的`js`；然后由后端转化为后端`jsp`，并且还要写业务的`js`代码。

**前后端分离**

前后端代码放在不同的工程下，前端代码可以独立开发，通过`mock/easy-mock`技术模拟后端`API`服务可以独立运行、测试；后端代码也可以独立开发，运行、测试，通过`swagger`技术能自动生成`API`文档供前端阅读，还可以进行自动化接口测试，保证`API`的可用性，降低集成风险。

### 1.3 开发模式与流程 ###

**前后端不分离**

在项目开发阶段，前端根据原型和`UI`设计稿，编写`HTML、CSS`以及少量与业务无关的`js`（纯效果那些），完成后交给后台人员，后台人员将`HTML`转为`jsp`，并通过`JSP`的模板语法进行数据绑定以及一些逻辑操作。后台完成后，将全部代码打包，包含前端代码、后端代码打成一个`war`，然后部署到同一台服务器运行。顶多做一下动静分离，也就是把图片、`css、js`分开部署到`nginx`。

具体开发流程如下：图略

**前后端分离**

实现前后端分离之后，前端根据原型和`UI`设计稿编写`HTML、CSS`以及少量与业务无关的`js`（纯效果那些），后端也同时根据原型进行`API`设计，并与前端协定`API`数据规范。等到后台`API`完成，或仅仅是`API`数据规范设定完成之后。前端即可通过`HTTP`调用`API`，或通过`mock`数据完成数据组装以及业务逻辑编写。前后端可以并行，或者前端先行于后端开发了。

具体开发流程如下：图略

## 二、前后端分离的好处与坏处。 ##

从上面3个方面对比了之后，前后端分离架构和传统的`web`架构相比，有很大的变化，看起来好处多多。到底是分还是不分，我们还是要理性分析是否值得才去做。

**从目前应用软件开发的发展趋势来看，主要有两方面需要注意：**

*  越来越注重用户体验，随着互联网的发展，开始多终端化。
 *  大型应用架构模式正在向云化、微服务化发展。

**我们主要通过前后端分离架构，为我们带来以下四个方面的提升：**

*  为优质产品打造精益团队

通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。

*  提升开发效率

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

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

如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。

*  增强代码可维护性

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

那么前后端分离有什么不好的地方吗？我目前是没有想到，除非你说会增加前端团队的配备，后端工程师会变的不全能。。。

## 三、前后端分离架构方案。 ##

实现前后端分离，主要是前端的技术架构变化较大，后端主要变为`restfull` 风格`API`，然后加上`Swagger`技术自动生成在线接口文档就差不多了。

对于目前用于前后端分离方案的前端技术架构主要有两种：

*  传统SPA
 *  服务端渲染SSR

### 3.1 传统`SPA` ###

传统`SPA`指的是单页面应用，也就是整个网站只有一个页面，所有功能都通过这一个页面来呈现。因为一个人的肉眼，某一个时间点看一个页面，既然如此何必要不同功能做多个页面呢？只保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容不就可以了吗？确实如此，现在通过`reac`全家桶、`vue`全家桶，模块化、路由、`wabpack`等技术轻而易举就能实现一个单页面应用。

单页面应用的运行流程

1.  用户通过浏览器访问网站`url`
2.  单页面的`html`文件（`index.html`）被下载到浏览器，接着下载`html`里面引用的`css，js`。
3.  `css，js`下载到浏览器完成之后，浏览器开始解析执行`js`向后端服务异步请求数据。
4.  请求数据完成后，进行数据绑定、渲染，最终在用户浏览器呈现完整的页面。

### 3.2 服务端渲染 ###

服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的`html`。大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是`NodeJs`服务端。

它的原理其实就是在浏览器与前端代码中间插入了一个`NodeJs`服务端。浏览器请求前端页面时，会先经过`NodeJS`服务端，由`NodeJs`去读取前端页面，并执行异步后端`API`，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的`html`然后返回浏览器，最后浏览器进行展示。

服务端渲染应用的运行流程：

1.  用户通过浏览器访问网站`url`
2.  `NodeJS`服务端接收到请求，读取到对应的前端`html，css，js`。
3.  `NodeJS`解析执行js向后端`API`异步请求数据。
4.  `NodeJs`请求数据完成之后，进行数据绑定、渲染，得到一个最终的`html`。
5.  `NodeJs`向浏览器输出`html`，浏览器进行展示。

PS：其实本质就是把前端编写成一个`nodeJs`的服务端`web`应用。实施服务端渲染后，我们最终运行的是一个`Nodejs`服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。

看到这里，你是否又有疑问，为什么要这么麻烦搞服务端渲染呢？

### 3.3 `SPA`与服务端渲染方案对比 ###

`SPA`的优点是开发简单，部署简单；缺点是首次加载较慢，需要较好的网络，不友好的`SEO`。

so，以下就是使用服务端渲染的理由了（摘取vue官方说法）：

与传统 `SPA` (单页应用程序 (`Single-Page Application`)) 相比，服务器端渲染 (`SSR`) 的优势主要在于：

*  更好的 `SEO`，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。

请注意，截至目前，`Google` 和 `Bing` 可以很好对同步 `JavaScript` 应用程序进行索引。在这里，同步是关键。如果你的应用程序初始展示 `loading` 图，然后通过 `Ajax` 获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 `SEO` 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(`SSR`)解决此问题。

*  更快的内容到达时间 (`time-to-content`)，特别是对于缓慢的网络情况或运行缓慢的设备。

无需等待所有的 `JavaScript` 都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验，并且对于那些「内容到达时间(`time-to-content`) 与转化率直接相关」的应用程序而言，服务器端渲染 (`SSR`) 至关重要。

**使用服务器端渲染 (`SSR`) 时还需要有一些权衡之处：**

*  开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (`lifecycle hook`) 中使用；一些外部扩展库 (`external library`) 可能需要特殊处理，才能在服务器渲染应用程序中运行。
 *  涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (`SPA`) 不同，服务器渲染应用程序，需要处于 `Node.js server` 运行环境。
 *  更多的服务器端负载。在 `Node.js` 中渲染完整的应用程序，显然会比仅仅提供静态文件的 `server` 更加大量占用 `CPU` 资源 (`CPU-intensive` \- CPU 密集)，因此如果你预料在高流量环境 (`high traffic`) 下使用，请准备相应的服务器负载，并明智地采用缓存策略。

以`vue`为例，实施服务端渲染可以查看官方指南：https://ssr.vuejs.org，或选择`Nuxt.js`

### 3.4 预渲染技术 ###

如果你调研服务器端渲染 (`SSR`) 只是用来改善少数营销页面（例如 `/, /about, /contact` 等）的 `SEO`，那么你可能需要预渲染。无需使用 `web` 服务器实时动态编译 `HTML`，而是使用预渲染方式，在构建时 (`build time`) 简单地生成针对特定路由的静态 `HTML` 文件。优点是设置预渲染更简单，并可以将你的前端作为一个完全静态的站点。

如果你使用 `webpack`，你可以使用 `prerender-spa-plugin` 轻松地添加预渲染。它已经被 `Vue` 应用程序广泛测试 - 事实上，作者是 `Vue` 核心团队的成员。

prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin

## 四、前后端分离技术选型 ##

*  `artTemplate` \+ `bootstrap`（不推荐， 不算完全前后端分离）
 *  `vue`全家桶（推荐）
 *  `react`全家桶 （推荐，生态全）