微前端学习笔记（1）：微前端总体架构概述，从微服务发微

从最初的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 应用中尤其常见。

微前端

微前端是一种类似于微服务的架构，是一种由独立交付的多个前端应用组成整体的架构风格，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，而在用户看来仍然是内聚的单个产品。

Web 应用开发速度快、用完即走等特性，导致的一个最终结果就是「能用 Web 技术实现的应用，最终都会通过 Web 来实现」。在近几年涌现了一大批之前只能在传统 PC 软件中才能看到的优秀产品，例如：Photoshop、Web Office、Web IDE。尽管随着 Web 标准的演进，前端工程化也在不断演变，从模块化到组件化在到现在的工程化，但在面对跨团队大规模开发、跨团队企业级应用协作，现有的分治设计模式仍然显得有心无力。

比如复杂的系统，由于整个系统涉及范围较广，在实际的研发过程中必然会以功能或业务需求垂直的切分成更小的子系统，切分成各种小系统后尽管由于分治的设计理念提升了开发者体验，但是一定程度上降低了用户体验。那能否以一种新的架构模式，既保开发者体验，又能提升用户体验呢。

微前端主要是用于解决：应用增量升级、多技术体系并存、构建大规模企业级 Web 应用而诞生的。

目前微前端主要是采用应用分而治之 + 动态加载 + SPA 应用的模式来解决大规模应用带来的一系列问题。

为什么需要微前端？

• 遗留系统迁移。解决遗留系统，才是人们采用微前端方案最重要的原因。

• 聚合前端应用。微服务架构，可以解耦后端服务间依赖。而微前端，则关注于聚合前端应用。

• 热闹驱动开发。新的技术，既然很热闹，那么就学吧。

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

微前端优势：

• 应用自治。只需要遵循统一的接口规范或者框架，以便于系统集成到一起，相互之间是不存在依赖关系的。

• 单一职责。每个前端应用可以只关注于自己所需要完成的功能。

• 技术栈无关。主框架不限制接入应用的技术栈，子应用具备完全自主权。你可以使用 Angular 的同时，又可以使用 React 和 Vue。

• 项目独立：独立开发、独立部署 子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
  

微前端缺点：

• 应用的拆分基础依赖于基础设施的构建，一旦大量应用依赖于同一基础设施，那么维护变成了一个挑战。

• 拆分的粒度越小，便意味着架构变得复杂、维护成本变高。

• 技术栈一旦多样化，便意味着技术栈混乱。

前端微服务化

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

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

如何去拆分应用

技术方式

• 路由分发式。通过路由将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现，又或者是应用框架自带的路由来解决。

• 前端微服务化。在不同的框架之上设计通讯、加载机制，通过模块的方式组合出完整的前端应用，以在一个页面内加载对应的应用。

• 微应用。通过软件工程的方式，在部署构建环境中，组合多个独立应用成一个单体应用。即在开发时，应用都是以单一、微小应用的形式存在，而在运行时，则通过构建系统合并这些应用，组合成一个新的应用。

• 微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的 chunk 代码(或称SDK)，使用时只需要远程加载即可，如网站加载第三方广告与统计。

• 前端容器化。通过将 iFrame 作为容器，来容纳其它前端应用。

• 应用组件化。借助于 Web Components 技术，来构建跨框架的前端应用。

• SSR服务端渲染合并。利用SSR服务，渲染不同的HTML片段，然后拼凑成完整的HTML文件，直出。
  

业务拆分

• 按照业务拆分。

• 按照权限拆分。

• 按照变更的频率拆分。

• 按照组织结构拆分。利用康威定律来进一步拆分前端应用。

• 跟随后端微服务划分。实践证明， DDD 与事件风暴是一种颇为有效的后端微前端拆分模式，对于前端来说，它也颇有有效——直接跟踪后端服务。

微前端的整体架构

微前端部署平台

目前较成熟的微前方案有 qiankun、micro-app、EMP 方案，但是它们与MF有着本质的不同，那就是对“微前端”的定义：

定义上的不同决定了技术实现的不同：

技术实现的不同又决定了使用场景的不同：

MF的实现其实并没有魔法，仅仅是异步chunk罢了。即便在MF中，不管是共享模块还是远端模块，其实还是使用的require.ensure去加载一些异步chunk罢了。只不过稍有不同的是，因为牵扯到依赖共享的逻辑，会有一个shared-scope的概念，用来实现依赖共享的相关逻辑。

这整个过程跟webpack5是没有绑定关系的，也就是说MF并非webpack5的专属功能，Rollup和webpack4都可以实现MF。更多的推荐查看：

• Module Federation 没有魔法仅仅是异步chunk https://zhuanlan.zhihu.com/p/352936804
  

• Webpack Module Federation 核心原理 https://juejin.cn/post/7045211570716016676

转载本站文章《微前端学习笔记（1）：微前端总体架构概述，从微服务发微》,
请注明出处：https://www.zhoulujun.cn/html/webfront/engineer/Architecture/9029.html