乐趣区

关于前端:软件架构之前后端分离与前端模块化发展史

jiezi

在现行的软件架构中，前端和后端是拆散的，即前端只专一于页面渲染，而后盾专一于业务逻辑，前端和后端是两个不同的工种，而前后端交互最常见的形式就是通过接口。

前后端拆散架构

在正式阐明前后台架构拆散之前，咱们来看一下多年之前，传统软件开发的架构模式。

为什么要前后端拆散

还记得零几年我上大学的时候，在初学 Java Web 开发时，课本上介绍的还是 JSP + Servlet 这种很传统的架构模式，这时候前端和后端业务逻辑代码都在一个工程外面，还没有拆散开来，这种开发模式属于 Model1 模式，尽管实现了逻辑性能和显示性能的拆散，然而因为视图层和管制层都是由 JSP 页面实现的，即视图层和管制层并没有实现拆散。

随着学习的深刻以及慢慢风行的企业应用开发，咱们慢慢的摈弃这种技术选型，并开始在我的项目中应用了若干开源框架，罕用的框架组合有 Spring +Struts/Spring MVC + Hibernate/Mybatis 等等，因为框架的优越性以及良好的封装性使得这套开发框架组合迅速成为各个企业开发中的不二之选，这些框架的呈现也缩小了开发者的反复编码工作，简化开发，放慢开发进度，升高保护难度，随之而炽热的是这套技术框架背地的开发模式，即 MVC 开发模式，它是为了克服 Model1 存在的有余而设计的。

MVC 的具体含意是：Model + View + Controller，即模型 + 视图 + 控制器，

  • Model 模型层：它经常应用 JavaBean 来编写，它承受视图层申请的数据，而后进行相应的业务解决并返回最终的处理结果，它累赘的责任最为外围，并利用 JavaBean 具备的个性实现了代码的重用和扩大以及给保护带来了不便。
  • View 视图层：代表和用户交互的界面，负责数据的采集和展现，通常由 JSP 实现。
  • Controller 管制层：管制层是从用户端接管申请，而后将申请传递给模型层并通知模型层应该调用什么功能模块来解决该申请，它将协调视图层和模型层之间的工作，起到两头枢纽的作用，它个别交由 Servlet 来实现。

MVC 的工作流程如下图所示。


同时，我的项目开发在进行模块分层时也会划分为三层：管制层，业务层，长久层。管制层负责接管参数，调用相干业务层，封装数据，以及路由并将数据渲染到 JSP 页面，而后在 JSP 页面中将后盾的数据展示进去，置信大家对这种开发模式都非常相熟，不论是企业开发或者是集体我的项目的搭建，这种开发模式都是大家的首选，不过，随着开发团队的扩充和我的项目架构的一直演进，这套开发模式慢慢有些力不从心。

接下来，咱们来剖析下这套开发模式的痛点。

痛点一：JSP 效率问题

首先，JSP 必须要在 Servlet 容器中运行（例如 Tomcat，jetty 等），在申请 JSP 时也须要进行一次编译过程，最初被译成 Java 类和 class 文件，这些都会占用 PermGen 空间，同时也须要一个新的类加载器加载，JSP 技术与 Java 语言和 Servlet 有强关联，在解耦上无奈与模板引擎或者纯 html 页面相媲美。其次每次申请 JSP 后失去的响应都是 Servlet 通过输入流输入的 html 页面，效率上也没有间接应用 html 高。因为 JSP 与 Servlet 容器的强关联，在我的项目优化时也无奈间接应用 Nginx 作为 JSP 的 web 服务器，性能晋升不高。

痛点二：人员分工不明

在这种开发模式下的工作流程通常是：设计人员给出页面原型设计后，前端工程师只负责将设计图切成 html 页面，之后则须要由后端开发工程师来将 html 转为 JSP 页面进行逻辑解决和数据展现。在这种工作模式下，人为出错率较高，后端开发人员工作更重，批改问题时须要单方协同开发，效率低下，一旦呈现问题后，前端开发人员面对的是充斥标签和表达式的 JSP 页面，后端人员在面对款式或者交互的问题时本就造诣不高的前端技术也会顾此失彼。

在某些紧急情况下也会呈现前端人员调试后端代码，后端开发人员调试前端代码这些让人捧腹的景象，分工不明确，且沟通老本大，一旦某些性能须要返工则须要前后端开发人员，这种状况下，对于前后端人员的前期技术成长也不利，后端谋求的是高并发、高可用、高性能、平安、架构优化等，前端谋求的是模块化、组件整合、速度晦涩、兼容性、用户体验等等，然而在 MVC 这种开发模式下显然会对这些技术人员都有肯定的掣肘。

痛点三：不利于我的项目迭代

我的项目初期，为了疾速上线利用，抉择应用这种开发模式来进行 Java Web 我的项目的开发是十分正确的抉择，此时流量不大，用户量也不高，并不会有十分刻薄的性能要求，然而随着我的项目的一直成长，用户量和申请压力也会不断扩大，对于互联网我的项目的性能要求是越来越高，如果此时的前后端模块仍旧耦合在一起是十分不利于后续扩大的。举例说明一下，为了进步负载能力，咱们会抉择做集群来分担单个利用的压力，然而模块的耦合会使得性能的优化空间越来越低，因为单个我的项目会越来越大，不进行正当的拆分无奈做到最好的优化，又或者在发版部署上线的时候，明明只改了后端的代码，前端也须要从新公布，或者明明只改了局部页面或者局部款式，后端代码也须要一起公布上线，这些都是耦合较重大时常见的不良现象，因而原始的前后端耦合在一起的架构模式曾经逐步不能满足我的项目的演进方向，须要需找一种解耦的形式代替以后的开发模式。

痛点四：不满足业务需要

随着公司业务的一直倒退，仅仅只有浏览器端的 Web 利用曾经逐步显得有些不够用了，目前又是挪动互联网急剧增长的时代，手机端的原生 App 利用曾经十分成熟，随着 App 软件的大量遍及越来越多的企业也退出到 App 软件开发当中来，为了尽可能的抢占商机和晋升用户体验，你所在的公司可能也不会把所有的开发资源都放在 web 利用上，而是多端利用同时开发，此时公司的业务线可能就是如下的几种或者其中一部分：

浏览器端的 Web 利用、iOS 原生 App、安卓端原生 App、微信小程序等等，可能只是开发其中的一部分产品，然而除了 web 利用可能应用传统的 MVC 模式开发外，其余的都无奈应用该模式进行开发，像原生 App 或者微信小程序都是通过调用 RESTful api 的形式与后端进行数据交互。

随着互联网技术的倒退，更多的技术框架被提了进去，其中最革命性的就是前后端拆散概念的提出。

什么是前后端拆散

何为前后端拆散，我认为应该从以下几个方面来了解。

前后端拆散是一种我的项目开发模式

当业务变得越来越简单或者产品线越来越多，原有的开发模式曾经无奈满足业务需要，当端上的产品越来越多，展示层的变动越来越快、越来越多，此时就应该进行前后端拆散分层形象，简化数据获取过程，比方目前比拟罕用的就是前端人员自行实现跳转逻辑和页面交互，后端只负责提供接口数据，二者之间通过调用 RESTful api 的形式来进行数据交互，如下图所示：


此时就不会呈现 HTML 代码须要转成 JSP 进行开发的状况，前端我的项目只负责前端局部，并不会掺杂任何后端代码，这样的话代码不再耦合。同时，前端我的项目与后端我的项目也不会再呈现耦合重大的景象，只有前后端协商和定义好接口标准及数据交互标准，单方就能够并行开发，互不烦扰，业务也不会耦合，两端只通过接口来进行交互。

在 MVC 模式开发我的项目时，往往后端过重，“控制权”也比拟大，既要负责解决业务逻辑、权限治理等后端操作，也须要解决页面跳转等逻辑，在前后端拆散的模式中，后端由原来的大包大揽似的独裁者变成了接口提供者，而前端也不仅仅是原来那样仅解决小局部业务，页面跳转也不再由后端来解决和决定，整个我的项目的控制权曾经由后端过渡至前端来掌控，前端须要解决的更多。

前端我的项目和后端我的项目隔离开来、互不干涉，通过接口和数据标准来实现我的项目性能需要，这也是目前比拟风行的一种开发方式。

前后端拆散是一种人员分工

在前后端拆散的架构模式下，后盾负责数据提供，前端负责显示交互，在这种开发模式下，前端开发人员和后端开发人员分工明确，职责划分非常清晰，单方各司其职，不会存在边界不清晰的中央，并且从业人员也各司其职。

前端开发人员包含 Web 开发人员、原生 App 开发人员，后端开发则是指 Java 开发人员 (以 Java 语言为例)，不同的开发人员只须要重视本人所负责的我的项目即可。后端专一于管制层（RESTful API）、服务层、数据拜访层，前端专一于前端管制层、视图层，不会再呈现前端人员须要保护局部后端代码，或者后端开发人员须要去调试款式等等职责不清和前后端耦合的状况，咱们通过两张我的项目开发流程简图来比照：


此时，开发过程中会存在前后端耦合的状况，如果呈现问题前端须要返工、后端也须要返工，开发效率会有所影响。当初，前后端拆散后流程简图如下：


前后端拆散后，服务器端开发人员和前端开发人员各干各的，大家互不烦扰，。在设计实现后，Web 端开发人员、App 端开发人员、后端开发人员都能够投入到开发工作当中，可能做到并行开发，前端开发人员与后端开发人员职责拆散，即便呈现问题，也是修复各自的问题不会相互影响和耦合，开发效率高且满足企业对于多产品线的开发需要。

前后端拆散是一种架构模式

前后端拆散后，各端利用能够独立打包部署，并针对性的对部署形式进行优化，不再是前后端一个对立的工程最终打成一个部署包进行部署。以 Web 利用为例，前端我的项目部署后，不再依赖于 Servlet 容器，能够应用吞吐量更大的 Nginx 服务器，采纳动静拆散的部署形式，既晋升了前端的拜访体验，也加重了后端服务器的压力，再进一步优化的话，能够应用页面缓存、浏览器缓存等设置，也能够应用 CDN 等产品晋升动态资源的拜访效率。对于后端服务而言，能够进行集群部署晋升服务的响应效率，也能够进一步的进行服务化的拆分等等。前后端拆散后的独立部署保护以及针对性的优化，能够放慢整体响应速度和吞吐量。

前端倒退历程

当咱们去理解某个事物的时候，首先咱们须要去理解它的历史，能力更好的把握它的将来。

原始时代

世界上第一款浏览器 NCSAMosaic，是网景公司（Netscape）在 1994 年开发进去的，它的初衷是为了不便科研人员查阅材料、文档（这个时候的文档大多是图片模式的）。那个时代的每一个交互，按钮点击、表单提交，都须要期待浏览器响应很长时间，而后从新下载一个新页面。

同年 PHP（超文本预处理器）脚本语言被开发进去，开启了数据嵌入模板的 MVC 模式，同期间比拟相似的做法有以下几种：

  • PHP 间接将数据内嵌到 HTML 中。
  • ASP 的 ASPX，在 HTML 中嵌入 C# 代码。
  • Java 的 JSP 间接将数据嵌入到网页中。

这个期间，浏览器的开发者，当前台开发人员居多，大部分前后端开发是一体的，大抵开发流程是：后端收到浏览器的申请 —> 发送动态页面 —> 发送到浏览器。即便是有专门的前端开发，也只是用 HTML 写写页面模板、CSS 给页面排个难看点的版式。在这一时期，前端的作用无限，往往只是切图仔的角色。

铁器时代

1995 年，网景公司的一位叫布兰登·艾奇的大佬，心愿开发出一个相似 Java 的脚本语言，用来晋升浏览器的展现成果，加强动静交互能力。后果大佬喝着啤酒抽着烟，十来天就把这个脚本语言写进去了，性能很弱小，就是语法一点都不像 Java。这样就慢慢造成了前端的雏形：HTML 为骨架，CSS 为外貌，JavaScript 为交互。

同期间微软等一些公司也针对自家浏览器开发出了本人的脚本语言。浏览器形形色色，尽管有了比拟对立的 ECMA 规范，然而浏览器先于规范在市场上风行开来，成为了事实标准。导致，当初前端工程师还要在做一些政府古老我的项目的时候，还要去解决浏览器兼容（万恶的 IE 系列）。

不管怎么说，前端开发也算是能写点逻辑代码了，不再是只能画画页面的低端开发了。随着 1998 年 AJax 的呈现，前端开发从 Web1.0 迈向了 Web2.0，前端从纯内容的动态展现，倒退到了动静网页，富交互，前端数据处理的新期间。这一时期，比拟出名的两个富交互动静的浏览器产品是。

  • Gmail（2004 年）
  • Google 地图（2005 年）

因为动静交互、数据交互的需要增多，还衍生出了 jQuery（2006）这样优良的跨浏览器的 js 工具库，次要用于 DOM 操作，数据交互。有些古老的我的项目，甚至近几年开发的大型项目当初还在应用 jQuery，以至于 jQuery 库当初还在更新，尽管体量上曾经远远不迭 React、Vue 这些优良的前端库。

信息时代

自 2003 当前，前端倒退度过了一段比拟安稳的期间，各大浏览器厂商除了循序渐进的更新本人的浏览器产品之外，没有再作妖搞点其余事件。然而咱们程序员们耐不住寂寞啊，工业化推动了信息化的疾速到来，浏览器出现的数据量越来越大，网页动静交互的需要越来越多，JavaScript 通过操作 DOM 的弊病和瓶颈越来越显著（频繁的交互操作，导致页面会很卡顿），仅仅从代码层面去晋升页面性能，变得越来越难。于是优良的大佬们又干了点惊天动地的小事儿：

  • 2008 年，谷歌 V8 引擎公布，终结微软 IE 时代。
  • 2009 年 AngularJS 诞生、Node 诞生。
  • 2011 年 ReactJS 诞生。
  • 2014 年 VueJS 诞生。

其中，V8 和 Node.JS 的呈现，使前端开发人员能够用相熟的语法糖编写后盾零碎，为前端提供了应用同一语言的实现全栈开发的机会（JavaScript 不再是一个被讥笑只能写写页面交互的脚本语言）。React、Angular、Vue 等 MVVM 前端框架的呈现，使前端实现了我的项目真正的利用化（SPA 单页面利用），不再依赖后盾开发人员解决页面路由 Controller，实现页面跳转的自我管理。同时也推动了前后端的彻底拆散（前端我的项目独立部署，不再依赖相似的 template 文件目录）。

至于为啥 MVVM 框架能晋升前端的渲染性能，这里简略的说一下原理，因为大量的 DOM 操作是性能瓶颈的罪魁祸首，那通过肯定的剖析比拟算法，实现等同成果下的最小 DOM 开销是可行的。React、Vue 这类框架大都是通过这类思维实现的，具体实现能够去看一下相干材料。前后端拆散也导致前端的分工产生了一些变动。

而后端开发更加关注数据服务，前端则负责展现和交互。当然相应的学习老本也越来越大，Node.JS 的呈现也使得前端前后端一起开发成为可能，好多大公司在 2015 年前后就进行了尝试，用 Node.JS 作为两头数据转接层，让后端更加专一于数据服务和治理。

前端模块化倒退历程

自 2009 年 5 月 Node.js 公布以来，前端无能的事件越来越多。短短 10 来年的工夫，前端便从刀耕火种的年代走向了模块化、工程化的时代。各种前端框架百家争鸣，前端赢来了真正属于本人的时代。

原始时代

工夫回到 2009 年，记得那时候还没有风行前后端拆散，很多我的项目还是混在一起，而那时候的前端开发人员大多数也都是“切图仔”。前端实现动态页面，由服务端共事实现数据的嵌入，也就是所谓的套页面操作，每当有相似的性能，都会回到之前的页面去复制粘贴，因为处于不同的页面，类名须要更换，然而换汤不换药。

长此以往，反复代码越来越多，凡是改变一个小的中央，都须要改变很多代码，显得极不不便，也不利于大规模的进行工程化开发。尽管市面上也缓缓呈现了 Angular、Avalon 等优良的前端框架，然而思考到 SEO 和保护人员并不好招，很多公司还是抉择求稳，用套页面的模式制作网页，这对前端的工程化、模块化是一个不小的妨碍。

构建工具的呈现

不过，随着 Node 被鼎力推崇，市面上涌现出大量的构建工具，如 Npm Scripts、Grunt、Gulp、FIS、Webpack、Rollup、Parcel 等等。构建工具解放了咱们的双手，帮咱们解决一些反复的机械劳动。

举个简略的例子：咱们用 ES6 写了一段代码，须要在浏览器执行。然而因为浏览器厂商对浏览器的更新十分激进，使得很多 ES6 的代码并不能间接在浏览器上运行。这个时候咱们总不能手动将 ES6 代码改成 ES5 的代码。于是乎就有了上面的转换。

// 编译前
[1,2,3].map(item => console.log(item))
// 编译后
[1, 2, 3].map(function (item) {return console.log(item);
});
// 代码压缩后
[1,2,3].map(function(a){return console.log(a)});

就是做了上述的操作，能力使得咱们在写前端代码的时候，应用最新的 ECMAScript 语法，并且尽可能的压缩代码的体积，使得浏览器加载动态脚本时能更加疾速。

传统的模块化

随着 Ajax 的风行，前端工程师能做的事件就不只是“切图”这么简略，当初前端工程师能做的越来越多，开始呈现了明确的分工，并且可能与服务端工程师进行数据联调。这里说的传统模块化还不是后现代的模块化，晚期的模块化是不借助任何工具的，纯属由 JavaScript 实现代码的结构化。在传统的模块化中咱们次要是将一些可能复用的代码抽成公共办法，以便对立保护和治理，比方上面代码。

function show(id) {document.getElementById(id).setAttribute('style', "display: block")
}
function hide(id) {document.getElementById(id).setAttribute('style', "display: none")
}

而后，咱们将这些工具函数封装到一个 JS 脚本文件里，在须要应用它们的中央进行引入。

<script scr="./utils.js"></script>

然而，这种做法会衍生出两个很大的问题，一个是全局变量的净化，另一个是人工保护模块之间的依赖关系会造成代码的凌乱。

例如，当咱们的我的项目有十几个甚至几十个人保护的时候，难免会有人在专用组件中增加新的办法，比方 show 这个办法一旦被笼罩了，应用它的人会失去和预期不同的后果，这样就造成的全局变量的净化。另一个问题，因为实在我的项目中的专用脚本之间的依赖关系是比较复杂的，比方 c 脚本依赖 b 脚本，a 脚本依赖 b 脚本，那么咱们在引入的时候就要留神必须要这样引入。

<script scr="c.js"></script>
<script scr="b.js"></script>
<script scr="a.js"></script>

要这样引入能力保障 a 脚本的失常运行，否则就会报错。对于这类问题，咱们该如何解决这样的问题呢？

全局变量的净化

解决这个问题有两种，先说说治标不治本的办法，咱们通过团队标准开发文档，比如说我有个办法，是在购物车模块中应用的，能够如下书写。

var shop.cart.utils = {show: function(id) {document.getElementById(id).setAttribute('style', "display: block")
  },
  hide: function(id) {document.getElementById(id).setAttribute('style', "display: none")
  }
}

这样就能比拟无效的避开全局变量的净化，把办法写到对象里，再通过对象去调用。专业术语上这叫命名空间的标准，然而这样模块多了变量名会比拟累赘，一写就是一长串，所以我叫它治标不治本。

还有一种比拟业余的办法技术通过立刻执行函数实现闭包封装，为了解决封装内变量的问题，立刻执行函数是个很好的方法，这也是晚期很多开发正在应用的形式，如下所示。

(function() {var Cart = Cart || {};
   function show (id) {document.getElementById(id).setAttribute('style', "display: block")
   }
   function hide (id) {document.getElementById(id).setAttribute('style', "display: none")
   }
   Cart.Util = {
     show: show,
     hide: hide
   }
})();

上述代码，通过一个立刻执行函数，给予了模块的独立作用域，同时通过全局变量配置了咱们的模块，达到了模块化的目标。

以后的模块化计划

先来说说 CommonJS 标准，在 Node.JS 公布之后，CommonJS 模块化标准就被用在了我的项目开发中，它有几个概念给大家解释一下。

  • 每个文件都是一个模块，它都有属于本人的作用域，外部定义的变量、函数都是公有的，对外是不可见的；
  • 每个模块外部的 module 变量代表以后模块，这个变量是一个对象；
  • module 的 exports 属性是对外的接口，加载某个模块其实就是在加载模块的 module.exports 属性；
  • 应用 require 关键字加载对应的模块，require 的基本功能就是读入并执行一个 JavaScript 文件，而后返回改模块的 exports 对象，如果没有的话会报错的；

上面来看一下示例，咱们就将下面提到过的代码通过 CommonJS 模块化。

module.exports = {show: function (id) {document.getElementById(id).setAttribute('style', "display: block")
  },
  hide: function (id) {document.getElementById(id).setAttribute('style', "display: none")
  }
}
// 也能够输入单个办法
module.exports.show = function (id) {document.getElementById(id).setAttribute('style', "display: block")
}

// 引入的形式
var utils = require('./utils')
// 应用它
utils.show("body")

除了 CommonJS 标准外，还有几个当初只能在老我的项目里能力看到的模块化模式，比方以 require.js 为代表的 AMD（Asynchronous Module Definition）标准 和 玉伯团队写的 sea.js 为代表的 CMD（Common Module Definition）标准。
AMD 的特点：是一步加载模块，然而前提是一开始就要将所有的依赖项加载齐全。CMD 的特点是：依赖提早，在须要的时候才去加载。

AMD

首先，咱们来看一下如何通过 AMD 标准的 require.js 书写上述模块化代码。

define(['home'], function(){function show(id) {document.getElementById(id).setAttribute('style', "display: block")
  }
    function hide(id) {document.getElementById(id).setAttribute('style', "display: none")
  }
  return {
    show: show,
    hide: hide
  };
});

// 加载模块
require(['utils'], function (cart){cart.show('body');
});

require.js 定义了一个函数 define，它是全局变量，用来定义模块，它的语法标准如下：

define(id, dependencies, factory)

  • id：它是可选参数，用于标识模块；
  • dependencies：以后模块所依赖的模块名称数组，如上述模块依赖 home 模块，这就解决了之前说的模块之间依赖关系换乱的问题，通过这个参数能够将前置依赖模块加载进来；
  • factory：模块初始化要执行的函数或对象。

require([dependencies], function(){})

而后，在其余文件中应用 require 进行引入，第一个参数为须要依赖的模块数组，第二个参数为一个回调函数，当后面的依赖模块被加载胜利之后，回调函数会被执行，加载进来的模块将会以参数的模式传入函数内，以便进行其余操作。

CMD

sea.js 和 require.js 解决的问题其实是一样的，只是运行的机制不同，遵循的是就近依赖，来看下应用 CMD 形式实现的模块化代码。

define(function(require, exports, module) {function show(id) {document.getElementById(id).setAttribute('style', "display: block")
  }
  exports.show = show
});

<script type="text/javascript" src="sea.js"></script>
<script type="text/javascript">
  // 引入模块通过 seajs.use，而后能够在回调函数内应用下面模块导出的办法
  seajs.use('./utils.js',function (show) {show('#box');
  }); 
</script>

首先是引入 sea.js 库，定义和导出模块别离是 define() 和 exports，能够在定义模块的时候通过 require 参数手动引入须要依赖的模块，应用模块通过 seajs.use。

ES6

ES6 提出了最新的模块化计划，并且引入了类的机制，让 JavaScript 从晚期的表单验证脚本语言摇身一变成了一个面向对象的语言了。ES6 的模块化应用的是 import/export 关键字来实现导入和导出，并且主动采纳的是严格模式（use strict），思考到都是运行在模块之中，所以 ES6 实际上把整个语言都升到了严格模式。

在 ES6 中每一个模块即是一个文件，在文件中定义变量、函数、对象在内部是无奈获取的。如果想要获取模块内的内容，就必须应用 export 关键字来对其进行裸露。咱们把之前的专用脚本用 ES6 的模式再重构一遍。

// utils.js
const show = () => {document.getElementById(id).setAttribute('style', 'display: block');
}
const hide = () => {document.getElementById(id).setAttribute('style', 'display: none');
}

export {
    show,
  hide
}
// 或者间接抛出办法
export const show = (id) => {document.getElementById(id).setAttribute('style', 'display: block');
}
export const hide = (id) => {document.getElementById(id).setAttribute('style', 'display: none');
}

// 内部引入模块
import {show, hide} from './utils'

能够发现，ES6 的写法更加清晰。具备了面向对象和面向函数的特色，可读性更强。

退出移动版