持续集成与部署（四）：部署 前后端分离

1. 前后端分离的意义

1.1 分离前的前后端开发

后端程序渲染 HTML 模板，代理 JS / CSS / SVG / PNG 等前端静态资源。

• 前后端不分离的问题

  1. 前后端开发协作困难
  2. 发布频率耦合
  3. 联调效率低
  4. 性能低下：前端资源的请求耗尽连接

1.2 分离后的前后端开发

• 主要包含两个方面

  1. 工程拆分：不在同一工程中开发，有个字独立的开发节奏、构建发布策略
  2. 技术拆分：使用各自熟悉和易用的技术，两者完全通过 RESTFUL API 交流

• 前后端分离的好处

  1. 解耦前后端架构
  2. 分工明确、界限清晰
  3. 提高开发效率
  4. 支持前后端不同的迭代频率
  5. 支持各自更适合的构建发布策略
• 为什么现在可以实现前后端分离

  因为前端技术的工程化、模块化、组件化的方案已经进入成熟期，工具链完善，不需要作为后端的附庸了。

• 现状

  现在前后端分离的方案可以说是百花齐放了。

  从 SSR 同构到 BFF 到 Serverless 到 GraphQL...

2. 前后端分离的实现

2.1 洪荒时代：不分离

在前后端不分离的时代，最典型的就是 MVC 架构了

在 MVC 架构中，前端作为 View 层通过后端的 Controller 去渲染，构建和发布的流程上，前端是后端的复用

2.2 探索时代：Nginx代理静态资源

为了实现前后端分离，有人提出了采用 Nginx 代理静态资源这种方案。

这种方案不使用页面模板，把 HTML 直接作为静态资源，通过 Nginx 或者 Apache HTTP Server 代理 HTML 和静态资源。

如下图的 Nginx 配置，它直接代理了所有对 HTML 、CSS 、JS 的请求，对 /api 的请求会转发到真正的服务上。

Nginx代理静态资源是一个比较激进的方案，这种方式可以实现前后端分离，不过它的问题也不少:

1. 只适合纯客户端渲染（CSR）,只适合 SPA这种单页面应用（页面的本身就是一个空的div，具体内容由js代码在浏览器中生成）
2. 首屏性能差（浏览器下载JS、执行JS都需要过程），对 C 端用户不友好（白屏）
3. SEO 效果约等于0

2.3 探索时代：后端渲染页面 + 静态资源代理

为了解决 SEO 的问题，又有人提出了 后端渲染页面 + 静态资源代理 这种方案。

这种方案的特点是依然由后端渲染 HTML 模板，但是其他静态资源从 CDN 拉取。
前后端工程在构建时组合，后端此时拿到模板，模板中引用的资源的 URL 指向 CDN。

这种方案解决了 SEO 的问题，也成功的拆分了前后端工程，但是依然存在问题:

1. 流程依然耦合，多了一步模板联调
2. 前端发布导致后端发布
3. 前端需要学习后端模板语法（后端如果是 JAVA，那页面模板很可能还是 JSP）

2.4 黄金时代：大前端

直到 Node BFF 的出现，前后端分离才进入了一个比较理想的时代

Node BFF：Backend For Frontend，属于前端的后端。利用 NodeJS 编写 BFF 层，可以用于模板渲染和接口聚合。

• 同构

  同构是利用 Vue/React 这种前端框架提供的服务端渲染能力，在服务端就将页面渲染好，本质上还是一个BFF。
  但是使用 SSR 的好处是，我们可以像普通的 SPA 单页面一样去写应用，并且它还解决了普通的 SPA 单页面首屏性能低、SEO 效果差问题。

  SSR的代表是 Vue 的 NUXTJS 和 React的 NEXTJS