从前端架构的出现到微前端架构设计

写在前面的话

对于大前端开发岗位，在技术实现上各行业以及应用体系区域完善，也建立了统一的技术栈和规范，这就意味着如果想要从编码为主的开发岗位进一步越迁到架构设计岗位，开发者需要具备完整的技术视野和架构设计思想，完全掌控从抽象的设计层面到具体的落地层面，能帮助前端开发者在行业内走向一个新的高度。

1. 大前端的架构变迁

随着互联网技术的演进，大前端岗位逐渐成为IT行业的一大不可或缺的岗位，大前端从酝酿到出现经历了几代技术的演进。

1.1 切图仔时代

早期的前端并不是单独的编程岗位，它更贴近于设计岗位。国内早期的互联网或软件项目大多以MVC架构为主，通过服务端技术实现的MVC架构几乎都是基于个平台的动态网页技术实现的。动态网页技术是通过静态网页结合服务端渲染模版进行网页绘制，该时代的前端不需要使用模版引擎或大量的JavaScript编程，而通常的解决方案便是UI设计将设计稿完成后，通过HTML+CSS+少量成熟的JavaScript库变成网页，而数据采用服务端模版引擎，如JSP、ASP、Smarty等进行渲染，所以当时的前端以设计岗位为主。

1.2 基于AJAX技术的前后交互时代

1.2.1 MVC架构的疲软期

随着互联网网民的不断增加，推动互联网应用架构提升规模和复杂度。这个时代的Web应用不在满足于提供基础服务，更注重交互、性能和用户体验，此时基于WebMVC架构实现的应用在大量用户群体上逐渐显得心有余而力不足，其具体原因，如图。

MVC架构应用之所以难以支撑发展的较快的用户基数，其原因是MVC架构的视图解析引擎在服务端，所有的网络请求压力均由服务器承受，这就导致了访问频繁的Web应用会经常出现访问阻塞的情况导致应用界面完全打不开。其具体原因，如图。

观察图片可以得知，该架构中所有的计算步骤都由Server处理，这意味着，若10000人访问该Web应用，会导致Server必须为这10000人分别计算其所请求的视图结果，否则用户无法获取正确的页面展示，而这个过程中还会包含Server->DB的访问时间，并且这个过程是一个同步操作，虽然Server是多线程处理客户端请求的，但整个过程中只要渲染逻辑没有跑完，则用户在浏览器中看到的只有空白的网页，因为自始至终MVC架构的动态网页项目中，浏览器只作为结果的展示容器存在。

1.2.2 前后分离的雏形

当部分应用架构师意识到该问题的严重性后，发现了客户端性能过剩的问题，便有了前后分离架构的雏形。该思想是将Server端处理的视图渲染逻辑搬运到Browser中处理，应用中将视图部分转移到了单纯的静态资源服务中，这样会使得访问应用的用户无需等待服务端处理业务，便可以直接加载大部分静态视图，视图中所包含的动态数据通过AJAX技术与Server交互，最终通过JavaScript执行模版的渲染，如图。

此架构更加符合当时的互联网基础建设情况以及大多数的用户需求，举个简单的例子，当参加完高考的考生迫不及待的查询高考成绩时，若该场景使用MVC架构处理则其流程为：

1. 考生访问成绩查询页面（触发一次服务端渲染）
2. 考生在查询成绩页面中输入个人信息准考证号并提交一次表单
3. 服务器根据考生数据连接DB进行考生成绩查询
4. 服务器将DB返回的数据保存到合适的变量中如List、Map等
5. 服务器将数据通过JSP或ASP等模版引擎进行计算生成考生成绩视图
6. 服务器将完整的成绩单页面代码返回给Browser

此架构场景下，必须进行到第6步，考生才能在浏览器中查看到自己的考试结果，若当前访问服务器的人数较多，服务器压力巨大，此时计算网页结果或连接DB部分就会消耗更大量的时间，导致查询成绩时出现网页超时的情况。而当使用前后分离模式后其步骤为：

1. 考生访问成绩查询页面（从静态资源中直接加载HTML）
2. 考生在查询成绩页面中输入个人信息准考证号并通过AJAX提交数据（此时网页不需要重新加载）
3. 服务器根据考生数据连接DB进行考生成绩查询
4. 服务器将DB返回的数据封装成JSON或XML对象返回
5. 浏览器将收到的成绩数据通过JavaScript加载到网页需要展示的位置

使用此步骤会发现，服务器无需处理视图解析，并且也不需要返回大量的数据，从处理过程到整个交互产生的流量上都实现了较好的优化。

1.2.3 基于前端MVVM架构的前后分离架构

此架构典型存在于现在的Web应用开发场景中，遂本文并不多做介绍，通过1.2.1和1.2.2的介绍便可以明确的解释，为什么当今大量的Web应用采用JavaScript的模版引擎（Vue、React或Angular等）来进行视图数据的渲染，以及为何大量的Web应用都是钱后分离架构的。当然，前后分离架构也对服务端在另外一个层面上造成了巨大的压力。虽然前后分离技术使得服务端在处理每一个请求的工作量大大的减小，增量获取数据的客户端会在同一个网页中瞬间产生大量的AJAX请求，会在数量上对Server产生另一种冲击。所以现今的前后分离架构的Server端都是分布式+集群模式（此部分由于非前端主题本节进行掠过，对服务端架构演进感兴趣的同学可以期待后续的内容，提前种草～）。

1.2.4 基于服务端分布式概念的微前端

大前端架构形态演进至今已经趋于一个阶段的成熟，但它并没有停止演进，目前的分布式微前端技术就是下一代前端架构的一个基础雏形。该技术思路源于服务端的分布式思想，可以实现应用的纵向拆分、微应用化、云组件化等等好处。微前端架构思想之所以出现，是因为在前端架构发展历程中，历代架构体系泾渭分明，同期架构中不同技术栈的生态又造成了应用间的生殖隔离，这就导致若想将上一代或近代遗留的成熟技术产品做统一入口形成大平台就不得不将其重新开发，这个发展路线显然是不对的，上面描述的现状，如图。

当面对以上需求时，由于各技术栈存在生殖层面的隔离，无法统一到同一个页面或路由系统中，这就导致了想要将现有资源整合，通过传统的工程化开发模式也难以对其实现良好的解决方案。若重新开发必将面临着巨大的成本和试错挑战，若真的重新开发也势必要统一技术栈，并针对该技术栈制定长远的技术方针，这种方式显然是风险极大的。综合以上问题，微前端思想便是未来混合技术栈实现前端微应用化的出路。微前端可以实现解决应用隔离，同一个大型应用下可以采用多种技术栈和生态进行开发，其沙箱运行模式的思想可以很好的实现技术栈隔离，并提供了完善的跨技术栈通信系统。当然微前端架构也存在多种设计思路和呈现模式并不是一种，后文会对其做完整的介绍。

2.架构设计思想篇

学架构先学思想，好的设计思想决定架