cms前端主题框架-前端框架cms

前言 近年来，微前端一直是前端界的热门话题。 它类似于微服务架构。 主要面向浏览器端。 它可以将一个复杂庞大的单体应用拆分成多个清晰独立的子组件。 应用程序，并一起服务于同一个主应用程序。 每个子应用都可以独立运行、独立开发、独立部署。微前端架构概念的诞生和应用，对于提供复杂应用服务的企业来说显然是机遇，也是挑战。 本文主要对微前端架构的概念和实现做一个总结和回顾，并通过一个实战案例来实践微前端架构，希望能给同样有此需求的朋友提供一些帮助和思路。 您将获得文本

在总结微前端架构之前，我们先了解一下什么是微服务。

1、什么是微服务cms前端主题框架，微服务能给企业带来什么？ 微服务是用于构建应用程序的架构解决方案。 微服务架构通过将应用程序分解为多个核心功能而不同于更传统的单体方法。 每个功能都称为服务，可以独立构建和部署，这意味着服务将工作（和失败）而不会相互干扰。

传统的Web软件开发架构往往如下图所示：

虽然在传统应用中我们可以通过模块化来拆分业务逻辑和开发方式，但最终还是会被打包部署为单体应用。 这种架构往往更适合中小型项目。 开发简单直接，更适合集中管理的应用。 但是，它往往有很多缺点，如可扩展性不足、难以重用相同或相似的服务、部署时间长、服务复杂等。 难以维护等。

对于复杂的系统和业务，我们一般采用微服务架构。 其思想是将一个完整的应用程序分解为相互连接的小的微服务，每个服务完成特定的功能，某些特定的服务还可以为其他服务提供API接口。

从上图中我们可以发现微服务给我们带来的好处：

但是微服务并不是任何场景都适用的。 微服务的目标是将应用充分分解，促进敏捷开发和持续集成部署。 在部署微服务时，我们需要适当划分边界，处理好不同微服务之间的并发问题。 这些都是对整个项目的挑战，需要更多专业的技术人员来把控。 还有Dubbo、Spring Cloud等很多开源的微服务框架，笔者之前所在公司使用的Spring Cloud是一个很好的微服务架构方案。

2. 微前端架构概念及解决方案 2.1 理解微前端架构

以上简单介绍了微服务架构。 接下来进入正题，说说微前端。 微前端和微服务的目的是相似的。 它们都将应用程序从单个单一应用程序转换为多个小的子应用程序。 不同之处在于：

微前端应用于浏览器端，主要是对Web应用进行拆解，最终将不同的子系统（模块）聚合成一个完整的应用。 微前端的主要目的是聚合，即将不同的子系统聚合成一个大系统，而目前微服务架构更多的是解耦cms前端主题框架，即解耦不同服务之间的依赖关系。 让我们来看看微前端的一些思考者。

Michael Geers 先生发表了对微前端的一些思考。 内容大致概括如下：

“微前端”是将微服务的概念延伸到前端领域。 为了构建功能强大的浏览器应用程序（也称为单页应用程序），当前的大趋势是将其构建在微服务架构之上。 但随着时间的推移，通常由独立团队开发的前端层会增长并变得更难维护。 微前端背后的想法是将 Web 应用程序视为独立团队拥有的功能组合。 每个团队都有其关心和擅长的不同业务或任务领域。每个团队都可以跨职能并端到端地开发其功能，从数据库到用户界面。

如以下示例所示：

当我们的系统中有很多不同的子模块，并且子模块之间有相对独立和完整的功能系统时，一旦子模块的数量越来越多，整个应用就会变得非常庞大和臃肿。 和维护成本大大增加。 如果我们在这种场景下使用SPA模式进行开发，那么项目后期会变得难以想象，第一次页面加载会变得很慢（我有经验，第一次开发一个复杂的系统页面会耗费很多时间加载时间，需要20多秒，所以我们必须使用MPA来处理它）； 但是我们使用MPA（多页面应用）模式，虽然解决了应用臃肿的问题，但是还有很多问题需要解决，比如模块切换需要刷新页面，公共组件不能共享，子模块直接，父子模块之间的通信问题，开发部署麻烦等等，这些都是传统开发模式遇到的问题。

试想，如果面对以上问题，如果有一种架构模式可以让我们在主应用中共享公共组件和状态（但要保证子应用运行时的内部状态隔离），以及不同的子模块可以单独开发Deployment，模块之间切换不刷新页面，可以简单的实现模块与父子应用的通信。 这是完美的吗？ 是的，这可能就是微前端需要解决的问题。

往往企业的中后台系统更适合使用微前端架构，因为B端大多是业务驱动的，往往这些业务非常复杂，比如Saas、PaaS等系统。 类似云平台、CRM、ERP系统，往往是微前端架构的救助对象。

笔者曾经接手的ERP系统，由于开发时间比较早，往往会有很多遗留的历史包袱，比如新旧技术栈的结合，前端业务代码庞大没有任何意义的违规。 为了继续迭代开发，重构是必由之路，我认为微前端的另一个重要作用就是解放。 解脱不可逆转的痛苦。

写这篇文章的时候，简单提了一些关于微前端的知识。 这里我回放一张我之前做的简单图，方便大家了解微前端的架构。

但我们看到的并不是全部事实。 文末笔者会总结一张比较全面的图来梳理微前端的一些实际应用。

2.2 微前端架构实现方案

通过以上内容，我们对微前端的概念和作用有了一个大概的了解。 接下来笔者总结一下自己经历过的微前端的实现。

2.2.1. 基于MPA+iframe+requirejs的微前端架构

这是笔者接手最早的一个项目，主要服务于企业内部的ERP系统。 当时使用的技术栈主要是jquery+layui+requirejs。 记得是笔者刚毕业时参与的项目。 重用代码。 当时项目代码庞大复杂。 总体结构如下：

传统的实现方式一般是通过多页面将应用解耦，利用模块化的加载机制引入可重用的组件。 系统间通用类型使用storage+window.opener+iframe。 比如我们这个大系统的首页，可能会有来自不同子系统的页面嵌入到iframe中。 不同的子系统由不同的人维护。 微前端模型虽然实现了，但是还有很多不足。

架构变更的大致分工是，架构组主要负责架构标准和规范的制定，以及公共模块的维护（类似于现在的组件，可以简单描述为公共UI插件的维护，由于到当时的jQuery生态）； 业务组主要负责编写业务代码，实现一个系统的具体交互和功能。

2.2.2 基于MPA+iframe+Webpack的微前端架构

基于MPA+iframe+Webpack的微前端架构的实现与上述传统架构的实现类似，只是采用了更新的技术栈和真正的模块化、组件化技术。 我之前做的Saas系统就是这种方案的典型例子：

上图可以看出不同的子系统可以单独维护，单独打包部署，最后通过node或者nginx进行路由分发。 我们使用公共ui组件库和js类库提取公共组件，但前提是不同的组件库与技术栈强相关。 如果没有历史遗留的新项目，建议使用一致的技术栈。

以上两种方案的缺点是组件库只能复用，不能真正共享，切换路由会导致页面重新渲染刷新。 父子系统之间通信困难，仍然需要iframe作为通信的容器。 （笔者在此介绍iframe父子页面通信的各种方式）

2.2.3. 基于 umi + qiankun 的微前端架构

目前市场上也有非常成熟的微前端架构解决方案，比如美团外卖之前的微前端架构single-spa和蚂蚁金服基于single开发的微前端架构qiankun（乾坤） -spa，是非常好的解决方案。

qiankun主要采用HTML Entry方式，直接打印子应用的HTML作为入口。 主框架可以通过fetch html获取子应用的静态资源，同时将HTML文档作为子节点插入到主框架的容器中。 这样不仅大大降低了主应用的接入成本，基本不需要调整子应用的开发方式和封装方式，也自然而然地解决了子应用之间的风格隔离问题。

其方案具有以下特点：

因为我们的前端项目是基于umi生态开发搭建的（之前都是用webpack搭建的，后来发现umi用起来也很舒服，就直接基于umi开发了），所以自然要选择乾坤作为微前端架构。 具体结构如下：

3、umi下微前端架构方案实战

接下来详细介绍如何使用乾坤搭建我们的微前端架构。 由于我们内部使用umi，这里直接使用它提供的@umijs/plugin-qiankun插件来实现。 （优点是修改成本几乎为零）首先我们来实现这样一个场景：我们有一个主应用作为基础项目，然后有3个子系统，独立创建和维护，可以由不同的 git 仓库。 当我们在主应用中切换路由时，我们会在不刷新页面的情况下切换到对应的子系统，一个完整的SPA体验，接下来我们来具体实现一下。

这里我们使用umi2.0进行开发，如何安装和使用umi，这里不做详细介绍。

创建项目

mkdir mainSystem subSystemA subSystemB subSystemC// 分别进入各系统目录下，执行以下命令创建我们的项目yarn create umi

在每个系统下安装@umijs/plugin-qiankun 插件
yarn add @umijs/plugin-qiankun复制代码主应用下的配置// .umirc.jsexport default {  plugins: [    [      '@umijs/plugin-qiankun',      {        master: {          // 注册子应用信息          jsSandbox: true, // 是否启用 js 沙箱，默认为 false          prefetch: true, // 是否启用 prefetch 特性，默认为 true        },      },    ],  ],};// app.jsconst isDev = process.env.NODE_ENV === 'development'export const qiankun = {  apps: [    {      mountElementId: 'root-subapp-container',  // 洗子应用挂载的节点      name: 'subSystemA', // 唯一 id，和package对应的name字段最好保持一致      entry: isDev ? '//localhost:8001' : '/subSystemA/index.html', // html entry      base: '/subSystemA',  的路由前缀，通过这个前缀判断是否要启动该应用，通常跟子应用的 base 保持一致      history: 'browser', // 子应用的 history 配置，默认为当前主应用 history 配置    },    {      mountElementId: 'root-subapp-container',      name: 'subSystemB',      entry: isDev ? '//localhost:8002' : '/subSystemB/index.html',      base: '/subSystemB',    },    {      mountElementId: 'root-subapp-container',      name: 'subSystemC',      entry: isDev ? '//localhost:8003' : '/subSystemB/index.html',      base: '/subSystemC',    }  ],  fetch: url => {    return fetch(url)  }};

以上是基本配置。 当然我们也可以在app.js中添加lifeCycles等钩子来控制不同生命周期下的行为。
在子应用中，我们还需要引入@umijs/plugin-qiankun 插件，具体配置如下：
export default {  base: `/${appName}`, // 子应用的 base，默认为 package.json 中的 name 字段  plugins: ['@umijs/plugin-qiankun', { slave: true }],};

基础准备工作已经完成，剩下的就是写业务代码了。 如果我们想让整个应用程序一起运行，我们需要先启动基础项目，然后再启动相应的子项目（当然也可以独立运行）。
但是值得注意的是，我们可以在开发环境中使用devServer提供的devServer进行跨域的资源抢夺。 如果应用在线发布，如果不同的子应用使用不同的域名，我们还需要解决跨域问题（跨域解决方案和安全机制也有很多，已经不是问题了）。 在实际的开发环境中，我们需要考虑的问题还有很多。 这里我们只做一个简单的介绍。 不过按照官方的API来看，基本可以满足大部分的需求场景，还是值得一试的。 作者也会写一个微前端的实际案例发布在github上，大家一起交流学习。
4. 程序员的技术回顾与前景
今年由于疫情的影响，工作任务比较紧，复习的时间也比较少，但是笔者还是会坚持每周更新1-2篇文章，总结复习工作中学到的新技术。 是时候把自己写的零散的文章分类整理一下，明确以后的方向，弥补不足。
1.Node相关 2.工程相关 3.设计模式相关 4.React相关 5.Vue/angular相关 6.CSS相关 7.算法相关 8.H5游戏 9.原生javascript类库设计与封装 10.工作问题总结if link如果失败，可以在公众号中搜索相应的内容。最后
如果你想学习更多H5游戏、webpack、node、gulp、css3、javascript、nodeJS、canvas数据可视化等前端知识和实战，欢迎加入我们公众号“趣谈”技术群前端》一起学习讨论，一起探索前端边界。