微前端架构

系统的组织在不断变化的同时，其设计和架构也在不断地调整。

如同数据库的分库分表一样，既然一个组织的部门已经过于庞大，就进一步将它细化。

软件的不同部分又被拆分到不同的部门之下。

随着不同部门的业务发展，技术栈越来越难统一，出现了多样化。

在走向多样化后，用户越来越厌倦一家公司的应用软件分散在多个不同应用上。

应用的获客成本越来越高，应用又一次走向聚合。

在分离了前后端之后，拆分降低了系统的复杂度，并进一步提高了软件的开发效率。

随着业务不断扩张，需求也不断扩张，应用又开始变得臃肿。

既然应用变大了，我们就继续往下拆分，拆分成更小的单位。

　　　　　　　　　　　　　　　　　　　　　　　　-----摘选自《前端架构 从入门到微前端》

　　　“任何物体在没有接受外界能量的条件下，总是朝着熵增（无序）的方向变化。”

　　　分库分表，前后端分离，聚合，拆分到粒度更小的单位等软件架构解决方案，解决的核心问题是，熵减。

　　　应用臃肿，管理成本增加，获客成本增加，组织臃肿等表现形式，表现形式的本质是，熵增。

　　　总的来说，“微前端”这个名词，以及它所带来的一系列策略。都是为了解决软件和组织在某一阶段的，熵增的问题。

一、微前端架构

特点

• 应用自治
• 单一职责
• 技术栈无关　

为什么需要

• 遗留系统迁移
• 后端解耦，前端聚合
• 热闹驱动开发

技术拆分方式

• 路由分发式
• 前端微服务化。不同框架之上设计通信和加载机制，以在一个页面内加载对应应用。
• 微应用。软件工程方式，在部署构建环境中，把多个独立的应用组合成一个单体应用。
• 微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的chunk代码，使用时只需远程加载。
• 前端容器化。将iframe作为容器来容纳其他前端应用。
• 应用组件化内。借助Web Components技术，来构建跨框架的前端应用。

说明：

①微件（Widget），flutter框架作为移动端的解决方案，就是微件化的实践之一。

②Web component技术的推广受限于浏览器的支持程度。

微前端架构设计

• 组件与模式库
• 应用通信机制
• 数据共享机制
• 专用的构建系统（可选）

架构模式

• 基座模式
• 自组织模式

设计理念　　

• 中心化：应用注册表
• 标识化应用
• 应用生命周期管理（微前端框架Single-SPA的基本生命周期，load->bootstrap->mount->unload->unmount）
• 高内聚，低耦合

微架构

• 后端拆分。微服务。
• App拆分。App存在多种容器，有插件化、组件化、小程序等不同的方案。
• 前端拆分。前端微服务、微应用化、微件化等。（前端走向微前端架构的原因，除了庞大的单体应用，还有一部分是要聚合旧的遗留系统）

二、实战篇-前端微服务化

缘起：

• 注册表。应用可以自动加载、运行，并能够与应用注册表进行联系
• 完全隔离。每个应用的开发是完全隔离的，开发时互不影响。它可以接入某个框架，以更好地支持构建

适用性：

• 应用地挂载DOM节点
• 应用的服务地址
• 应用的唯一标识符
• 应用的名称
• 应用所需要加载的脚本文件

设计方案：

• 通用型微前端方案 Single-SPA
• 定制型微前端方案 Mooa

说明：

①Single-SPA官网https://single-spa.js.org/docs/examples/

②Single-SPA参考GitHub-https://github.com/single-spa/single-spa

微前端架构

原文：https://www.cnblogs.com/bearRunning/p/12242179.html