资讯专栏INFORMATION COLUMN

基于 Webpack4 的可插拔式微前端架构 - Puzzle

jsliang / 3439人阅读

项目地址

什么是 Puzzle

Puzzle 是基于 Vue 和 Webpack4 实现的一种项目结构;业务模块可以像拼图一样与架构模块组合,形成不同的系统,而这一切都是可以在生产环境热插拔的;这意味着你可以随时向你的系统添加新的功能模块,甚至改版整个系统,而不需要全量替换整个项目。

此外当多个项目使用此架构开发,即使模块是由不同的项目打包出来的,也可以在生成环境进行快速组合,模块可以非常简单的进行复用。

特点

核心:支持生产环境模块热插拔

支持业务模块的灵活组合

基座作为基座模块,也支持多个并存(这意味着你可以很轻松的进行灰度测试)

如何做到的

将基座/业务模块以umd模块的方式用 webpack 打包出来

通过 LoadJS 对这些模块进行挂载,会在 window 对象上附加该模块对象

通过动态路由的方式将该对象加载到架构中

运行项目 开发环境

安装依赖

npm install

构建第三方依赖

npm run dll

运行

npm start
生产环境

安装依赖

npm install

构建第三方依赖

npm run dll

构建,在这步你可以选择需要打包的基座模块和业务模块方便进行灵活组合

npm run build
热插拔相关

前端项目根据后端菜单请求进行模块加载,如本项目中后端请求返回格式为(数据来自阿里云):

[
  {
    id: "elastic",
    name: "弹性计算",
    leaf: false,
    children: [
      {
        id: "ecs",
        name: "云服务器 ECS",
        leaf: true,
        page: "/ecs",
        puzzle: "elastic"
      },
      // ...
    ],
    icon: "aperture",
    puzzle: "elastic"
  },
  {
    id: "database",
    name: "数据库",
    leaf: false,
    children: [
        // ...
    ],
    icon: "aperture",
    puzzle: "database"
  },
  // ...
]

规定以第一级目录为模块目录(这里看自己的需求可以对项目进行修改)

固模块 ID 为 elastic、database 等,系统会在生产环境对所有子系统的入口文件进行请求,尝试加载模块,并生成路由;

所以通过不同用户的不同业务模块返回结果,可以进行不同模块的加载,从而进行权限控制;

同理通过不同用户的不同基座模块返回结果,可以进行不同基座的加载,从而进行灰度测试等操作(目前系统所用基座是写在public/config.js中,固此条仅作参考,项目本身可以自由发挥);

多带带打包架构
npm run core
多带带打包基座模块
npm run frame --name="xxx"
多带带打包业务模块
npm run puzzle --name="xxx"

通过上述操作打包出的模块,可以直接新增到生产环境或者替换生产环境对应应模块

代码结构 开发环境结构

config

此文件夹内包含webpack所有打包配置文件

public

config.js:项目配置,用于生产环境配置

index.html:HTML 模版

src -> core

架构代码

src -> frames

基座模块代码,多个基座模块并列放置

src -> puzzles

业务模块代码,多个业务模块并列放置

static

主要用于放置静态资源,将会直接复制到生产环境static文件夹

static -> dll

npm run dll生成的第三方库和公共代码等

生产环境结构

生产环境代码按照一定结构放置,可以自由升级替换对应模块

core

npm run core 生成的架构代码

frames

npm run frame 生成的基座模块代码

puzzles

npm run puzzle 生成的业务模块代码

static

静态资源,包含打包生成的第三方库和公共代码等

PS

此架构仅作为日常工作的一个总结,具体业务场景,可以进行修改,基座模块等可以进行自由发挥;业务模块返回的信息也可以按照需求增加;只要各个模块遵循一定标准,并在core中进行统一处理,均可以达到可插拔的效果。

具体可以看项目代码,方便的话可以给个star 项目地址

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/104369.html

相关文章

  • 基于 Netty 的可插拔业务通信协议的实现「3」业务注册及实际工作流程

    摘要:本文仍以该实例为例,探讨该自定义通信协议的具体工作流程,以及如何以注册的形式灵活插拔通信消息对象。进行二进制数据帧的解码操作时,数据帧中已包含了消息的功能位,据此可获取相应的编解码器,而后可以对该数据帧进行解析,生成相应的消息对象。 本文为该系列的第三篇文章,设计需求为:服务端程序和众多客户端程序通过 TCP 协议进行通信,通信双方需通信的消息种类众多。上一篇文章以一个具体的需求为例,...

    LdhAndroid 评论0 收藏0
  • Hyperledger Fabric(介绍)

    摘要:比特币和以太币属于一类区块链,我们将其归类为公共无许可的区块链技术。例如,在单个企业中部署时,或由受信任的权威机构运作,完全拜占庭容错的共识可能被认为是不必要的,并且对性能和吞吐量造成过度的拖累。 介绍 一般而言,区块链是一个不可变的交易分类账,维护在一个分布式对等节点网络中。这些节点通过应用已经由共识协议验证的交易来维护分类帐的副本,该交易被分组为包括将每个块绑定到前一个块的散列的块...

    yunhao 评论0 收藏0
  • 基于 Netty 的可插拔业务通信协议的实现「2」特定业务消息对象的设计

    摘要:而实际两者之间的通信使用的是基于的自定义二进制数据帧,对象与数据帧之间需进行转换。该类实现了编码解码方法,故可对消息对象进行编码或对数据帧进行解码。该类的静态方法可通过指定功能消息对象生成相应的回复对象。 本文为该系列的第二篇文章,设计需求为:服务端程序和众多客户端程序通过 TCP 协议进行通信,通信双方需通信的消息种类众多。上一篇文章详细描述了该通信协议的二进制数据帧格式以及基本 J...

    Yuqi 评论0 收藏0
  • 基于 Netty 的可插拔业务通信协议的实现「1」协议描述及基本消息对象设计

    摘要:基本消息对象的设计消息对象的设计主要由两部分组成特定数据帧对应的特定消息对象。该类包含上节数据帧主帧及子帧的所有公共信息,仅仅未包含子帧中的数据体信息,该需求由基本消息对象的子类实现。 开发工程中,有一个常见的需求:服务端程序和多个客户端程序通过 TCP 协议进行通信,通信双方需通信的消息种类众多,并且客户端的数量可能有数万个。为此,双方需要约定尽可能丰富、灵活的数据帧「数据包」协议,...

    Barry_Ng 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<