前端工程化-之微前端和Monorepo的架构设计微前端和Monorepo的架构设计 todo 本文围绕微前端与Monor

一.微前端和Monorepo的架构设计【拆还是分？】

微前端的概念是由ThoughtWorks在2016年提出的，它借鉴了后端-微服务的架构理念，核心在于将一个庞大的前端应用拆分成多个独立灵活的小型应用，每个应用都可以独立开发、独立运行、独立部署，再将这些小型应用融合为一个完整的应用，或者将原本运行已久、没有关联的几个应用融合为一个应用。

微前端既可以将多个项目融合为一，又可以减少项目之间的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更灵活。

它主要解决了两个问题：

1、随着项目迭代应用越来越庞大，难以维护。
2、跨团队或跨部门协作开发项目导致效率低下的问题。

二.前端架构演进【切换全局视角】

应用演进过程：

1.mpa 多页每个功能独立开发【分】

-- user.html

-- portal.html

通过不同功能拆分不同应用，通过nginx 代理路径访问不同页面

2.spa 组件化开发【合】

通过组件拆分不同功能,实现组件复用，页面跳转基于（vue-router ,react-router 等运行时）

3.微前端【分】

单页面逐渐庞大门户,认证,管理后台,流程中心,物联网,低代码,可视化,报表,数据治理..

微前端（Micro Frontend）是从微服务架构（Microservices）中借鉴而来的一种前端架构模式。它的核心思想是将一个大型的前端应用拆分成多个独立的、自治的模块或应用，分别由不同的团队开发、部署和维护。这些子应用（Micro-Apps）虽然是独立构建的，但在用户看来，它们就像一个完整的应用一样协同工作。

微前端通过约定应用协议，把各个子应用统一接入到基础应用中来【基座应用】

总结：整个架构演进过程可类比现实中的水的形态；在不同温度环境下，有固体冰,雾,水气。都是水，只是在不同环境不同阶段的产物形态而已。

对比维度	MPA（多页应用程序）	SPA（单页应用程序）	微前端
概念与架构特点	由多个独立 HTML 页面组成，每个页面有独立 URL，通过超链接或表单提交跳转，后端常采用 MVC 架构	整个应用只有一个 HTML 页面，基于 JavaScript 框架构建，采用前端路由，通过 AJAX 与后端交互，页面加载后局部更新	将大型应用拆分成多个小型、独立服务，各服务有独立业务逻辑、数据存储和运行环境，通过轻量级通信机制协作
性能与用户体验	每次跳转需重新加载整个页面，性能差，网络差时加载时间长，页面切换有明显刷新感	首次加载慢，后续页面切换快，提供流畅交互体验，类似原生应用	各服务可独立扩展优化，能应对高并发，但服务间通信可能有延迟
开发与维护	开发相对简单，对技术要求低，页面多则维护成本高，一致性和交互逻辑维护麻烦	前端工作量大，对前端技术要求高，应用复杂时维护难度增加	开发复杂，需考虑服务间通信等问题，但团队可独立开发各服务，维护时各服务能独立进行，需完善治理监控体系
适用场景	适用于对 SEO 要求高、页面独立、交互性不强的应用，如企业网站、资讯类网站	适用于对交互体验要求高的应用，如 Web 应用、管理后台、移动 Web 应用	微前端的核心目标是将庞大应用拆解成若干可以自治的松耦合子应用

三.微前端优点【优先微前端方案】

1.技术栈无关

主框架不限制接入应用的技术栈，微应用具备完全自主权

2.独立开发、独立部署

微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新

3.增量升级

在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略

4.独立运行时

每个微应用之间状态隔离，运行时状态不共享

四.你问我答环节-现阶段核心包开发发布具体步骤有哪些？

传统工程化架构 VS Monorepo

journey
title 核心包发布时序图
section 开发环节
开发功能: 3: 开发A
验证功能: 5: 开发A
改版本号发布私服: 5: 开发A
section 包引用和验证环节
修改版本号引入: 5: 开发B
安装依赖: 5: 开发B
验证功能: 5: 开发B
联系A重新调整: 3: 开发B

在传统的多仓库结构中（Multirepo），每个项目独立维护，可能会面临以下问题：

代码共享困难为了共享代码，需要额外创建一个共享仓库并发布为包，增加了维护成本。

代码重复各项目可能会重复实现相同功能，导致冗余代码和后期维护困难。

工具不一致不同仓库可能使用不同的工具链（构建、部署、代码规范），增加了协作成本。

构建效率低每个项目独立安装依赖，可能会多次重复构建相同的内容。举个例子：我们之前的前端仓库下，有运维平台和租户平台，技术栈相差不多，相同的依赖会重复安装到磁盘上，分别维护各自的工具配置和公共组件，不仅导致代码重复，还让统一管理和协作变得复杂

Monorepo 初体验-代码演示

pnpm worksapce vs maven module

前端 pnpm worksapce

pnpm-workspace.yaml:
packages:
  - "apps/*"
  - "packages/*"
  # dist 目录不需要作为工作空间
  - "!**/dist/**"

工程结构
* apps
   * portal
   * system
* packages
   * ui
   * lowcode
   * api
   * code

后端 maven module  
<modules>
    <module>netty-mqtt</module>
    <module>common</module>
    <module>rule-engine</module>
    <module>dao</module>
    <module>transport</module>
    <module>ui-ngx</module>
    <module>tools</module>
    <module>application</module>
    <module>msa</module>
    <module>rest-client</module>
    <module>topo</module>
</modules>

Monorepo 解决哪些痛点？

Monorepo（Mono Repository）意为单一仓库。它是指在一个项目仓库中管理多个模块/包的策略。

简化依赖管理：本地包可以直接被引用，无需发布和版本更新

即时生效：对共享包的修改可以立即反映在依赖它的项目中

统一构建：确保所有项目使用相同版本的共享包

简化工作流：减少了发布、更新和重新安装的步骤

这种方法不仅提高了开发效率，还确保了项目间的一致性，是现代大型前端项目开发的推荐实践。

五、微前端与Monorepo的结合实践步骤**

1.包管理方案 pnpm worksapce ,yarn worksapce ，其他...

pnpm workspace

pnpm 在依赖安装速度和磁盘空间占用方面表现较好。由于它采用了共享存储和符号链接的方式，避免了重复安装相同版本的依赖，安装速度通常比npm快，并且可以节省大量磁盘空间，尤其是在处理大型项目和多个依赖重复的工作区场景下。
yarn workspace

yarn workspace 在性能方面也有不错的表现。它的依赖安装速度也比较快，通过扁平化依赖树减少了磁盘空间占用。不过，与pnpm相比，在一些复杂的依赖场景下，可能会因为依赖解析和共享方式的差异而导致性能略有不同。

目前使用最广泛的包管理工具还是基于 pnpm workspace。节省磁盘空间和提升性能

独特的硬链接机制：

pnpm 使用硬链接将依赖统一存储在全局缓存中，避免重复安装，节省磁盘空间。

npm 每个项目都独立存储依赖，导致浪费磁盘空间，特别是在多项目环境下。

安装速度更快：

pnpm 利用缓存机制显著加速依赖安装。

3.无前端框架技术方案选型

选择最适合的微前端框架取决于你的项目需求、团队技术栈以及业务规模。如果你需要多框架共存且追求灵活性，Qiankun 和 Single-SPA 都是不错的选择；也可以考虑 Wujie 或 micro-app 都是不错的选择。

Qiankun：

简单: 任意 js 框架均可使用。微应用接入像使用接入一个 iframe 系统一样简单，但实际不是 iframe。

完备: 几乎包含所有构建微前端系统时所需要的基本能力，如样式隔离、js 沙箱、预加载等。

生产可用: 已在蚂蚁内外经受过足够大量的线上系统的考验及打磨，健壮性值得信赖。

微前端的工作原理：

微前端的核心目标是让多个独立的前端应用能无缝集成并呈现给用户。

常见的实现方式包括：加载多个子应用：主应用负责加载不同的子应用（例如：通过 iframe、Web Components 或 JavaScript 动态加载等技术），让每个子应用在浏览器中独立运行。

共享全局状态：微前端架构通常需要某种方式来共享跨应用的全局状态，比如使用事件总线、共享缓存等技术。

路由与导航管理：主应用通常负责管理整个页面的路由和导航，而各个微应用会根据需求负责自己的路由。

最终选择

包管理工具：pnpm workspace 打包构建工具：pnpm ++turbo 微前端框架：qiankun

下面以一个实际的项目案例来探讨如何结合微前端和Monorepo架构。

项目背景：假设我们有一个大型的前端项目，该项目由多个子项目组成，每个子项目由不同的团队负责。为了提高开发并行度和团队间的协作效率，我们决定采用微前端架构。同时，为了便于代码管理和依赖管理，我们选择使用Monorepo架构。

实施步骤：

初始化Monorepo仓库：使用如pnpm Workspaces或Lerna等工具初始化一个Monorepo仓>库，为每个子项目创建一个独立的包（package）。

配置微前端架构：采用如qiankun、single-spa等微前端框架，实现子项目之间的隔离和通信。每个子项目可以作为一个独立的微前端应用，使用不同的技术栈进行开发。

开发子项目：各个团队在各自的子项目包中进行开发，利用Monorepo架构带来的便利进行依赖管理和代码共享。

构建与部署：使用如Jenkins、GitLab CI/CD等工具，配置自动化构建和部署流程。当某个子项目的代码发生变化时，可以自动触发构建和部署，确保整个应用的持续集成和持续部署。

前端工程化-之微前端和Monorepo的架构设计

一.微前端和Monorepo的架构设计 【拆还是分？】