微前端史话：从CS/BS(JSP/PHP)/前后端分离/模板引擎/单页面应用

原创

周陆军博客

发布于 2023-05-14 21:23:31

8060

发布于 2023-05-14 21:23:31

文章被收录于专栏：前端博客

从最初的CS架构，如MFC Java Swing 等，到BS架构，JSP PHP，再到前端后端分离，前端从jquery GWT-Ext 到 Handlebars ，再到angularJS/Vue/React，反观java 世界，学好 Spring MyBatis ,一路无忧，哎……

什么是微前端

为了解决庞大的一整块后端服务带来的变更与扩展方面的限制，出现了微服务架构（Microservices）：

微服务是面向服务架构（SOA）的一种变体，把应用程序设计成一系列松耦合的细粒度服务，并通过轻量级的通信协议组织起来具体地，将应用构建成一组小型服务。这些服务都能够独立部署、独立扩展，每个服务都具有稳固的模块边界，甚至允许使用不同的编程语言来编写不同服务，也可以由不同的团队来管理

Micro frontends, An architectural style where independently deliverable frontend applications are composed into a greater whole.

微前端实际是一种思想，个人觉得并不是新的黑科技，其关键点还是解耦与分治。

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。同时，它们也可以在共享组件的同时进行并行开发——这些组件可以通过 NPM 或者 Git Tag、Git Submodule 来管理。

如同微服务一样，微前端就是把系统拆解，解耦，然后组合。如同iphone的供应链管理。

微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

为什么需要微前端？

遗留系统迁移。解决遗留系统，才是人们采用微前端方案最重要的原因。
聚合前端应用。微服务架构，可以解耦后端服务间依赖。而微前端，则关注于聚合前端应用。
热闹驱动开发。新的技术，既然很热闹，那么就学吧。

微前端的实现，意味着对前端应用的拆分。拆分应用的目的，并不只是为了架构上好看，还为了提升开发效率。

微前端优势：

应用自治。只需要遵循统一的接口规范或者框架，以便于系统集成到一起，相互之间是不存在依赖关系的。
单一职责。每个前端应用可以只关注于自己所需要完成的功能。
技术栈无关。主框架不限制接入应用的技术栈，子应用具备完全自主权。你可以使用 Angular 的同时，又可以使用 React 和 Vue。
项目独立：独立开发、独立部署子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新

微前端缺点：

应用的拆分基础依赖于基础设施的构建，一旦大量应用依赖于同一基础设施，那么维护变成了一个挑战。
拆分的粒度越小，便意味着架构变得复杂、维护成本变高。
技术栈一旦多样化，便意味着技术栈混乱。

前端微服务化

前端微服务化，是微服务架构在前端的实施，每个前端应用都是完全独立（技术栈、开发、部署、构建独立）、自主运行的，最后通过模块化的方式组合出完整的前端应用。其架构如下图所示：

采用这种方式意味着，一个页面上同时存在二个及以上的前端应用在运行。而路由分发式方案，则是一个页面只有唯一一个应用。

如何去拆分应用

技术方式

路由分发式。通过路由将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现，又或者是应用框架自带的路由来解决。
前端微服务化。在不同的框架之上设计通讯、加载机制，通过模块的方式组合出完整的前端应用，以在一个页面内加载对应的应用。
微应用。通过软件工程的方式，在部署构建环境中，组合多个独立应用成一个单体应用。即在开发时，应用都是以单一、微小应用的形式存在，而在运行时，则通过构建系统合并这些应用，组合成一个新的应用。
微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的 chunk 代码(或称SDK)，使用时只需要远程加载即可，如网站加载第三方广告与统计。
前端容器化。通过将 iFrame 作为容器，来容纳其它前端应用。
应用组件化。借助于 Web Components 技术，来构建跨框架的前端应用。
SSR服务端渲染合并。利用SSR服务，渲染不同的HTML片段，然后拼凑成完整的HTML文件，直出。