️本文为博客园社区首发文章,未获授权禁止转载 大家好,我是aehyok,一个住在深圳城市的佛系码农‍♀️,如果你喜欢我的文章,可以通过点赞帮我聚集灵力️. 个人github仓库地址: https:github.com/aehyok 本文讲解微前端qiankun demo仓库地址 : https:github.com/aehyok/vue-qiankun 目前基于dev分支进行开发和测试 本demo已部署腾讯云 http://139.186.205.7:8080/(服务器配置较低,如有访问比较慢,

10月份换了新的工作,参与完一个月的需求迭代后,接到了项目重构的任务.简单来说,需要在短时间内提出方案设想,同时进行本地验证,最终需要拿出一套技术替换方案来.于是,埋头苦干了一个月,总算干了点成绩出来,今天把当时的思考和实践做个简单总结,就当是个复盘吧. 一.老项目现状 最初接触到的老项目,使用到的前端技术栈主要是(jQuery1.8 + layui-v2.5.4 + ExtJS4.2.1.883),当时拿到这个项目的时候,上手书写起来竟然有点手生,毕竟这几年长时间使用的都是vue和react,

以下实例项目为vue项目,其他项目当然也雷同咯 在项目中建一个这个么脚本文件 不说了,上代码 #!/bin/sh handle=$1; env=$2; # 远程部署机 webhook # 如果用远程机器部署的话就要用到以下方法 # preHandle(){ # git pull orgin master # npm config set registry http://registry.npm.taobao.org/ # npm install # npm run build-prod # }

本次集群部署使用ELK版本统一为6.8.10,kafka为2.12-2.51 均可在官网下载 elasticsearch下载地址:https://www.elastic.co/cn/downloads/elasticsearch logstash下载地址:https://www.elastic.co/cn/downloads/logstash kibana下载地址:https://www.elastic.co/cn/downloads/kibana kafka下载地址:http://kafka.

一,基础篇 先安装nodejs 使用淘宝镜像安装tnpm 安装 cnpm 插件:npm install -g cnpm --registry=https://registry.npm.taobao.org 然后就可以用 cnpm命令从淘宝镜像获取插件包了:当然,你这时候依旧可以用npm命令从官方服务获取插件包. cnpm支持除 publish 之外的原生 npm 所有命令. 1,新建文件夹 gulp 2,切换到gulp目录下,执行 cnpm init,填写相关信息,生成package.json文

作者:vivo 互联网前端团队- Tang Xiao 本文梳理了基于阿里开源微前端框架qiankun,实现多页签及子应用缓存的方案,同时还类比了多个不同方案之间的区别及优劣势,为使用微前端进行多页签开发的同学,提供一些参考. 一.多页签是什么? 我们常见的浏览器多页签.编辑器多页签,从产品角度来说,就是为了能够实现用户访问可记录,快速定位工作区等作用:那对于单页应用,可以通过实现多页签,对用户的访问记录进行缓存,从而提供更好的用户体验. 前端可以通过多种方式实现多页签,常见的方案有两种: 通过C

vivo 互联网前端团队- Jiang Zuohan 一.背景 VAPD是一款专为团队协作办公场景设计的项目管理工具,实践敏捷开发与持续交付,以「项目」为核心,融合需求.任务.缺陷等应用,使用敏捷迭代.小步快跑的方式进行开发及质量跟踪,简化工作流程,帮助团队快速迭代并高效完成产品开发交付. 但早期VAPD以"一切皆可配置"的设计理念开发运行了两年,整个前端代码复杂混乱,组件庞大(需要支持多种配置),状态混乱,前端代码打包出来有50M之巨.这个项目难以为继,bug多.维护困难.新增功能处

转载: iOS动态部署方案 前言 这里讨论的动态部署方案,就是指通过不发版的方式,将新的内容.新的业务流程部署进已发布的App.因为苹果的审核周期比较长,而且苹果的限制比较多,业界在这里也没有特别多的手段来达到动态部署方案的目的.这篇文章主要的目的就是给大家列举一下目前业界做动态部署的手段,以及其对应的优缺点.然后给出一套我比较倾向于使用的方案. 其实单纯就动态部署方案来讲,没什么太多花头可以说的,就是H5.Lua.JS.OC/Swift这几门基本技术的各种组合排列.写到后面觉得,动态部署方案其

我们在single-spa 技术分析 基本实现了一个微前端框架需要具备的各种功能,但是又实现的不够彻底,遗留了很多问题需要解决.虽然官方提供了很多样例和最佳实践,但是总显得过于单薄,总给人一种"问题解决了,但是又没有完全解决"的感觉. qiankun 在 single-spa 的基础上做了二次开发,完善了很多功能,算是一个比较完备的微前端框架了.今天我们来聊一聊 qiankun 的技术原理. 在本系列的开头,我们提到微前端的核心问题其实就是解决如何加载子应用以及如果做好子应用间的隔离问

封面 简介 从 single-spa 的缺陷讲起 -> qiankun 是如何从框架层面解决 single-spa 存在的问题 -> qiankun 源码解读,带你全方位刨析 qiankun 框架. 介绍 qiankun 是基于 single-spa 做了二次封装的微前端框架,通过解决了 single-spa 的一些弊端和不足,来帮助大家实现更简单.无痛的构建一个生产可用的微前端架构系统. 微前端框架 之 single-spa 从入门到精通 通过从 基本使用 -> 部署 -> 框架

背景 在这越来越发达的网络时代,web应用也是越来越复杂,尤其是前端的开发,也是越来越受重视. 所以在我们前端开发完成后,会有一些列的web应用的上线验证,如自测.QA测试.code review 等,以确保 应用能在生产上没有事故. 但是事以愿违,很多时候我们都会接受的客户的一些线上问题,这些问题有时候可能你是自己开发的原因本身存 在的问题,这样的问题一般能够在测试环境重现,我们很快的能定位到问题关键位置.但是,很多时候有一些问题, 我们在测试中并未发现,可是在线上却有部分人出现了,问题确确实

原文团队掘金平台:https://juejin.im/post/6891532248269783054 EMP项目github链接: https://github.com/efoxTeam/emp EMP教程整理: https://github.com/efoxTeam/emp/wiki 目前,EMP微前端方案已经在github开源了,可以立即开箱使用.具体详细的教程文档也在wiki更新,敬请期待. 什么是微前端 做好前端开发不是件容易的事情,而比这更难的是扩展前端开发规模以便于多个团队可以同时

序 这才2月中旬,广州就已经渐渐地进入了夏季,--夏天总是让人焦虑的.过年闲暇时间写下了微前端这系列的终章,欢迎拍砖.如果你习惯直接上手代码,不妨跳到实践一节,直接上代码教程玩一玩. qiankun原理和API介绍 qiankun是基于singlespa框架的一个上层应用,它提供了完整的生命周期,和一些钩子函数,通过路由匹配来动态加载注册微应用,同时提供了一系列api对微应用做管理和预加载等,它相对singlespa来说进步是比较大的. 所以---qiankun实质上是singlespa的一个封

初步认识微前端 微前端是什么 现在的前端应用,功能.交互日益复杂,若只由一个团队负责,随着时间的推进,会越来越庞大,愈发难以维护. 微前端这个名词,第一次提出是在2016年底.它将微服务(将单一应用程序划分成一组小的服务,服务之间相同配合,为用户提供最终价值)这个应用于服务端的技术扩展到前端领域. 微前端背后的想法是:将网站或 web 应用程序视为由独立团队负责的子应用(或模块.功能)的组合. 微前端核心是:拆.和. 拆,即将一个应用拆成多个子应用.每个子应用由单独的团队负责,独立开发.发布 和

Devops 开发运维高级篇之Jenkins+Docker+SpringCloud微服务持续集成--部署方案优化 之前我们做的方案部署都是只能选择一个微服务部署并只有一台生产服务器,每个微服务只有一个实例,容错率低 如何去解决? 在一个Jenkins工程中可以选择多个微服务同时发布 在一个Jenkins工程中可以选择多台生产服务器同时部署 每个微服务都是以集群高可用形式部署 Jenkins+Docker+SpringCloud集群部署流程说明 修改所有微服务配置: 再开一台生产服务器  装有do

前言 最近需要重构一个老项目,定的方案用微前端去改造.主应用是老的项目,微应用是新的项目,由于重构时间比较紧张,子应用还需要使用父应用的一些组件.过程中遇到一些问题,记录一下. 方案 我们知道qiankun,可以通过props通信传递数据,把组件通过props传递过去不就行了.来开始改造我们的代码 主应用 导入组件,通过props共享出去 import { registerMicroApps, start, setDefaultMountApp } from 'qiankun'; // 导入一些

piral有一个微前端开发框架,功能强大,文档比较全,扩展能力也比较好 包含以下特性: 特性 高度模块化 多框架兼容 支持资源文件的拆分 全局状态管理 独立开发和部署 CLI工具 与同类框架的比较 参考资料 https://docs.piral.io/reference/documentation#core-features https://github.com/smapiot/piral

基于 Docker 和 GitLab 的前端自动化部署 实践笔记 随着接触的项目越来越多,在部署测试流程上重复耗时工作也越来越多,所以对前端工作的CI/CD实现愈发迫在眉睫. 前端开发由于三大框架的崛起,基于 webpack 的自动化构建被广大开发者所熟识.而一整套 DevOps 工作流包括 Auto Build.Auto Test.Auto Code Quality.Auto Deploy 等,这里主要是解决 Auto Deploy 部分. 主要实现思路是,指定部署分支,比如 master,每

之前已经用Git实现了自己博客的提交自动部署,并自动提交到GitHub和coding以备不时之需.平时项目代码都托管在Coding或者GitHub上,也已经用上了coding提供的webhook功能,偶尔个别自己玩玩的项目提交了代码之后再SSH到服务器上去 git pull 一次,刚好一起做成了自动部署,方法记录起来备忘. 实现步骤 在服务器上 以Nginx环境为例,Apache请看OverTrue的教程 生成公钥 公钥有两个:1. git用户公钥,2. 部署公钥: git用户公钥 123 ss

前言 前一篇文章介绍了IceGrid的简单应用.这篇文章来介绍一下它的高端玩法-如何将模板,复制组,知名对象应用于部署方案及其作用. 基于模板的部署方案 之前介绍了xml格式的配置文件通过各种描述符如node,server,adaptor等,描述应用部署信息.当服务部署复杂度增加时,书写这些描述符是件头疼的事. 模板(Template)能大大简化描述符的书写:同时参数化使得模板的使用更加灵活.我们可以为描述符server和service定义模板,这个章节主要介绍 Server Template,