图书管理系统html前端_微前端⼀⼆事⼉
作者 : 写代码的⽐熊君
如果盘点2019年最⽕的前端技术，那么微前端肯定占有⼀席之地。 但是⼤部分⼈对于微前端这个架构新贵的了解还是处于懵懵懂懂的状态，本⽂将会详细介绍微前端的前⽣今世，带⼤家了解微前端架构是如何⼀步步从实际需求中演化⽽来，以及⼩桔车服基于微前端所提炼的⼀套中后台体系建设实践。
什么是微前端
微前端这个概念最初是对应于微服务这个概念提出的，微服务的核⼼思想就是将⼀个⼤的单体应⽤基于业务能⼒拆分为⼀组⼩的服务，每个服务都是独⽴的进程且能独⽴部署，⽆需统⼀的技术栈进⾏集中化管理，只需要进⾏轻量级的通信就可以完成业务诉求。微前端就是这样⼀种类似于微服务的架构模式，它将微服务的核⼼思想应⽤于浏览器端，即将单个复杂（⼤规模）的前端应⽤转换成多个⼩型前端应⽤，每个⼩型前端应⽤都与技术栈⽆关，可以独⽴开发、独⽴部署，当然拆分还需要⼀套成熟的通信机制串联起所有的应⽤，既能保证应⽤⾃治⼜能保证应⽤联系，以更好的协同度共同提升开发效率。
总结来说，微前端就是在前端⼀体化的⼤背景下，利⽤技术⼿段达到业务层应⽤聚合、技术层应⽤⾃治的⼯程架构⽅案，实现⼀个功能丰富且强⼤的前端应⽤。
为什么需要微前端
是不是还是感觉有些朦朦胧胧，没关系，基于任何技术都需要依托于业务的原则，我们举⼀个浅显易懂的例⼦来帮助你理解⼀下前端为什么需要微前端架构：
在很多年前，⼩红和⼩兰决定创业，开⼀家⽹上商城，两个⼈⼀拍即合，快速设计出原型1.0版本，使⽤最原始的Jquery以及Html产出了⼀套⾯向⽤户展现的购物⽹站以及⾯向运营展现的管理后台：
为了⽅便理解，我们先不管前台的购物系统，只专注后台管理系统，因为项⽬前期只需要满⾜最基本的购物需求，所以当时所有的管理需求都集中在⼀个管理系统，代码收拢在⼀个仓库，具体架构如下：
⼩红和⼩兰迅速将1.0版本的⽹上商城推向市场，由于抢占了先机，⼤家很喜欢这种⾜不出门就可以购物的感觉，两⼈迅速赚到了⼀笔钱。
后来随着业务越做越⼤，商品管理逐渐分成了精选商品管理和普通商品管理，库存管理分成了合作商库存和⾃营库存，订单管理和⽤户管理也愈发的庞⼤，成了这个样⼦：
可以明显看出，随着业务的繁杂，每个模块的管理变的愈发臃肿，所有团队都在⼀个系统中维护不同的功能变的越来越⿇烦，因此⼩红和⼩兰决定了上线2.0版本，将整个后台管理系统解耦拆分，由不同的团队维护不同的模块，A团队只负责商品管理这块，B团队只负责库存管理这块，其余模块也类似，这样⼤家各⾃部署，各⾃开发，互不⼲涉。
在2.0模式下，当业务越做越⼤，⼩红和⼩兰决定再成⽴营销和渠道两个团队，分别开展⼀些营销活动和渠道活动时，后台管理系统也需要增加⼀个渠道管理和营销管理模块，沿⽤上⾯解耦的逻辑，这俩团队再新建⼀个渠道系统和营销系统分别管理，⼤家各⾃产出⾃⼰的代码，各⾃维护各⾃的系统，扩展性⼤⼤增强。
同时随着前端技术的发展，Jquery以及Html的框架逐步落后， Angular、 React、Vue等单页⾯应⽤异军突起成为主⼒，各个团队都逐渐开始重构各⾃的系统，商品管理系统⽤了React框架，订单管理系统⽤了Vue框架等等，⼤家各⾃朝着⾃⼰感兴趣的框架上发⼒，各⾃为政的状态让⼤家都互不⼲扰，这样做就满⾜了最开始代码解耦的需求。
2.0模式的⼀切看起来都挺完美，但是真的很完美么，很快问题就出来了：
⾸先，苦了真正使⽤后台系统的运营同学和产品同学，这些同学想要使⽤后台系统的各种功能，⽇常操作就变成了不断的切换、切换、再切换系统。例如他们想要上架⼀个新的商品，需要先去商品管理系统配置⼀系列信息，再去库存管理系统查询相应的商品库存，最后再去营销系统配置这个商品的营销活动，整个过程需要不断的切换系统，运营效率⼤⼤降低。
然后，开发效率也⼤⼤降低，⽐如所有的系统都是基于同⼀套登录权限模块，但由于部署在不同的域名环境，每个系统都重复开发⼀遍，类似的⽹关模块、⽇志模块等等也是如此。⽽且不同系统之间存在⼤量的耦合功能，单独的代码环境并不能复⽤⼀些其他系统已有的代码，就会造成各种重复造轮⼦的⾏为。
有什么样的⽅式既可以让各个系统既能单独开发部署，各⾃选择技术栈，⼜能紧密联系聚合成⼀个系统供运营同学和产品同学使⽤呢，微前端的架构思想应运⽽⽣。
微前端的核⼼思想就是将⼀个完整的前端应⽤分解成⼀些更⼩的、微粒化的、能够独⽴开发测试部署的⼦应⽤，⼦应⽤之间通过弱通信机制互相联系，在⽤户看来仍然是内聚的单个产品。
那么整个电⼦商城的后台管理系统可以使⽤微前端的思想重新架构⼀番，也就是3.0模式：
这样，从产品维度来看，所有的系统都内聚在⼀个基系统中，⽤户只需要⼀次登录就可以不刷新的切换各个系统，所有功能都内聚在⼀起，有效提⾼了运营效率；从技术维度来看，各个系统并不需要进⾏技术栈的重构，依然可以沿⽤原有技术栈，每个团队依然各⾃维护各⾃的代码库，独⽴部署独⽴上线，且可以共⽤⼀些通⽤的能⼒如登录、鉴权、打点、⽇志分析等，即保证了遗留系统的迁移，⼜聚合了前端应⽤，完美解决应⽤臃肿情况下如何各⾃治理的问题。
相信通过上⾯例⼦，在⼀个虚拟电⼦商务后台系统架构的逐渐演化中，你应该了解了前端为什么需要微前端架构，总结来说，微前端具备下⾯优势：
灵活聚合业务成系统：产品功能耦合，⾯向⽤户时多个不同的业务功能耦合成⼀个业务系统。
灵活聚合业务成系统
兼容多技术栈：⽆论技术栈是Vue，还是React，或者Angular，都可以完美的在⼀个系统中运⾏。
html导航源码兼容多技术栈
独⽴开发部署：⼦应⽤之间仓库独⽴，可以各⾃开发，部署后容器层会完成⾃动的同步更新。
独⽴开发部署
依赖资源复⽤：抽离不同应⽤中所依赖的公共资源，⼀次性加载多⽅复⽤，从⽽提升性能。
依赖资源复⽤
微前端的技术选型
前⾯介绍了为什么需要微前端架构，那么接下来介绍⼀下技术选型，⾸先需要明确⼀个概念，微前端是⼀种架构思想，并不具体指某个技术，它是当前端业务在发展到⼀定规模之后，⼀种⽤来分解复杂度的架构模式，具体可以考虑以下⼏种选型：
1.路由式分发
这是最古⽼的微前端技术实现⽅式之⼀，也是最容易的实现⽅式，通过HTTP的反向代理功能，经过路由判断将请求转发到响应的服务上去，优点就是⼏乎不需要做任何改造，配置⼀下nginx服务即可，缺点也很明显，完全没有性能优化，切换系统仍需刷新页⾯重新加载资源⽂件，只是从表层将不同应⽤拼凑到⼀起。
2.iframe容器
这是最古⽼的微前端技术实现⽅式之⼆，虽然简单但是确实有效，iframe⼀直是浏览器规范之⼀，除
了某些化⽯级别的版本，⼏乎所有的浏览器都可以完全兼容。Iframe的页⾯与⽗页⾯分开，完全不受⽗页⾯css或者全局的javascript 影响，在⼀定程度上类似于“沙箱隔离”，但⼀个系统如果加载过多的iframe体验会很不友好，重复加载相同的依赖，影响⽹页加载速度。
3.微件式服务
微件化是指某个应⽤由开发⼈员提前将完整的、闭环的所有功能提前编译好，其他应⽤可以直接嵌⼊到⽹页中⽽不需要做任何的修改或者编译就可以直接运⾏展⽰。早期很多应⽤的引⼊都是这样做的，将本⾝应⽤封装成sdk包，使⽤者远程加载javascipt代码就能⽣成对应的组件嵌⼊到页⾯，后续随着npm的流⾏，逐渐发展成将应⽤以NPM包的形式发布源码，这样做的优势是发布灵活单独部署打包，缺点就是如果引⼊多个应⽤微件，可能存在互相⼲扰的问题，且应⽤间通信困难，对遗留应⽤需要做过多改造。
4.Web Components
Web Components是⼀个Web组件标准，它提供了浏览器底层的⽀持，不依赖各种框架的⽀持和webpack的编译，让⼈们也可以使⽤组件。Web Components通过⼀种标准化的⾮侵⼊的⽅式封装⼀个组件，每个组件能组织好它⾃⾝的HTML、CSS、JavaScript，并且不会⼲扰页⾯上的其他代码。使⽤⽅式与iframe⽐较类似，组件拥有⾃⼰独⽴的 Scripts 和 Styles，以及对应的⽤于单独部署组件的域
名，内部资源⾼内聚，作⽤域独⽴，加载由⾃⾝控制。看上去Web Components确实是⼀种⽐较好的微前端架构选型，但遗憾的是⽬前浏览器的⽀持程度尚不完善，在Safari、ie和⽕狐上⽀持并不理想，如果不考虑多浏览器的兼容，Web Components是⼀个不错的选择。
5.⾃制框架的微应⽤式服务
微应⽤式服务是指系统在开始都是以单⼀微⼩应⽤的形式存在，只有当运⾏时才由系统框架将这些应⽤加载合并，组合成⼀个完整系统。⽆论是基于虚拟树的react和vue框架，还是基于Web Components的Angular框架，所有框架的原型都离不开在html⾥加载元素，那么，我们只需要提前将单个系统打包编译成⼀个微应⽤，在页⾯合适的地⽅引⼊或者创建 DOM，这样当⽤户操作时触发应⽤的启动，并能在⽤户切换时卸载应⽤，所以这个微应⽤式服务的核⼼在于加载器的设计，既能实时加载切换不同应⽤，⼜能有效隔离应⽤防⽌互相⼲扰。
Single-SPA是现在较为成熟的⼀个开源框架，可以实现在⼀个页⾯将多个不同的框架整合，甚⾄在切换的时候都不需要刷新页⾯，已⽀持React、Vue、Angular 1、Angular 2、Ember 等等，如果想要简单的将⼯程微应⽤化，可以考虑使⽤这个框架。
当然，没有银弹可⾔，微前端并不是万⾦油，⽆论是哪⼀种实现⽅式，我们在考虑采⽤微前端架构之前，除了考虑它带来的好处，还要考量存在的⼤量风险和技术挑战，例如：
使⽤之后如何区分开发环境和线上环境
如何隔离 JS，避免 CSS 冲突
应⽤间共享公共资源的机制
第三⽅模块重叠
处理数据获取并考虑⽤户的初始化加载状态
权限如何接⼊
如何减少初始 Loading 时间
如何有效测试
所以，微前端与微服务⼀样，要真正进⼊实践，还需要做好⼀系列的技术储备。⽬前⼩桔车服结合实际业务形态，构建出⼀套全链路的的产品接⼊平台，解决了上述微前端中的技术卡点，为中后台体系建设提供了⼀套通⽤的解决⽅案。
微前端在车服中的实践
先介绍下背景，车服租车业务线有⾮常⾼的业务复杂度，并经历了多次商业模式探索整合优化。在业务不断探索调整的过程中，租车商⽤和MIS系统形成了多个系统分治的局⾯，同时林林总总的诸如采购、营销、企业车队等独⽴系统也都因业务侧的诉求纷纷进⾏了新建，且有更多的新的独⽴系统在业务侧筹划构建的路上，这极⼤加剧了开发和维护这些中后台系统的成本。
为此，团队决定以整合当前集团和车服环境内LASS能⼒为基点，提供⼀套微前端的架构体系，从页⾯资源到微应⽤再到系统级的搭建和管理的统⼀能⼒，即Midway平台。
如上，Midway平台以微前端架构思想为基础，采⽤基座模式，提供⼀个主应⽤即基座作为系统的统⼀⼊⼝，管理⼦应⽤的⽣命周期以及应⽤间的通信，提供核⼼部分的业务功能如⽤户登录、统⼀鉴权、导航菜单、路由管理等功能，并将对应的请求指向对应的服务，⼦应⽤则是具体负责⼦模块的业务实现，⽆视技术栈，由各个团队独⽴开发部署。
Midway 底层以single-spa为基础，隔离⼦应⽤间的样式与作⽤域，通过应⽤注册、钩⼦引⽤等⽅法，对接⼊的应⽤进⾏完整的⽣命周期控制，同时提供了应⽤通讯、公共资源加载、应⽤按需加载、应⽤预加载、⽇志监控等多种底层功能，下⾯捡重点介绍⼀下：
1.应⽤注册
Midway 调⽤ single-spa 的registerApplication⽅法注册微应⽤，⽀持传⼊异步函数 loadApp（返回 Promise 即可）及⾮函数类型值。如果是⾮函数类型，它会主动转换，在钩⼦返回前后及返回的钩⼦做了⼀些功能建设：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。