tags: [组件]
categories: 前端工程化

前言

前后端分离为什么出现？
本质上是什么？
前后端分离运动对 web 应用的架构带来了怎么样的变化？
前后端分离怎么分离？
为什么是 Node.js?
前后端分离的未来怎样？

互联网分层架构，为啥要前后端分离？

Why

传统的后段服务支撑不了现代化的前端开发。平时工作中用到的工具链、开发框架、规范协议、浏览器等在不断涌现，这些新的技术在给开发环境、开发流程提了更多新需求。Node.js 在这个背景下能够把这些工具串联起来。

How

模板层的分工

最早的 Java 开发阶段需要一个包含所有内容的 war 包，整个前端的编排，像 HTML 页面、CSS、JS 很多时候包含在 HTML 页面，也会出现脚本复用、样式复用抽离出来。所以前端开发当时是围绕著名的 velocity 模版。这一层最大的问题是，后端的同学看前端资源像看天书，前端同学看后端模版也像是看天书，融合效率非常低。

静态资源独立部署

Web 前端体验最大的改进就是副客户端，客户端资源非常庞大，代码不再是直接发布到线上，而是要编译，做预处理，可能还要做 CDN 的加速。整个应用被分割成两部分，后端服务发布之后，前端服务要独立更新，这样就给应用的更新带来了便利。这里存在一个问题是接口的协调，前端的需求变更，数据的要求也会变化，需要后端去协调资源的编排。另外一个问题是测试，前端持有脚本，样式资源，而模版却在应用层，应用层的开发、发布也是很复杂的。

独立应用层（BFF）

Node.js 提供 mock 数据开始，前端代码的预编译，资源编排，这些动作都合并到一个应用里面，前端形成 UI 应用层。在这一层，前端具备了更灵活、强大的能力，在数据编排这一层，Node.js 可以做轻量的粘合，服务端的开发也在往微服务方向发展，提升了开发效率。

后端相关的接口回退到 API，或者云端。

BFF 层

业务层的需求很多，在流程控制、数据转换、数据安全、分析展现等方面需要有大量的组件沉淀。最大的特点是有众多独立的功能模块。

在 server 层
Babeljs 可以做代码转换的事情，
Bigpipe 可以优化服务端的内存，可以缩减渲染时间，提升体验优化。
在数据流里可以有很多的 filter，给数据链中插入 processor，来定义处理微小的数据。
用户在原始的数据到完整的可视化展现不需要再搭建一个产品去支持，只需要搭几个 filter，配几个数据源，拖几个组件就可以完成。

定制应用框架

通过“定制应用框架”解决前端的编译，工程管理，数据 mock 等问题

微应用分割

把各自独立的模块应用切割成微应用，一个微应用解决一个问题，便于分工和隔离处理。

具体做法是微服务拆分，搭建微应用服务，承载大量的小服务，同时也会出现很多域名的问题，很多访问入口。这里做了一些小创新，在入口可以定义端口，sever name，访问 path，当把一个场景分成 10 个应用发布，发布之后再根据不同的路径拼接成一个应用，对体验没有影响。

除了路由自动化规划之后，对应用的发布做到上下平滑，不会影响流量。前端人员自己打包发布就可以了。

运维工程化

当这些应用被分割的很细致之后，随之而来的是如何管理这些小应用。

比如有两台机器做互备，把所有小 App 都发布到上面之后，由一个个小颗粒组成一个大应用，看上去很像一个蜂巢，因此命名 honeycomb，这些蜂巢组成一个大蜂窝，完成一个主功能。在应用推进过程中，有些应用压力大，需要把应用集群隔离开，把有不同业务需求场景环境，例如开发环境、预发环境、线上环境隔离开来，不同环境配置的集群资源和机器数量都不一样。随着业务发展，隔离的事情会交给容器去执行。

密集计算问题

密集计算分成两层，
第一层绿色部分会接收用户请求，
第二层浅蓝色会处理用户请求，写很多的 processor，提供大量的进程去提供密集计算。

主要问题在于 CPU 容量是恒定的，当有很多并发请求的时候，如何保证在服务层去很好的分配计算任务。
拆成两层之后，保证用户请求不会被 block 掉。
如果第一层大量的密集计算，会导致用户的请求或者连接的需求被挡住，接收不到响应，所以要往后堆，做成队列，可扩容的大集群。整个结果在 Java 里就可以理解为 Java 庞大线程的处理过程。

社区里在线程库里还有一些尝试，Napa.js 是微软开源的线程库，前端同构的需求可以探索使用 Napa.js 这个工具。