创建5a 网站建设要求,手机网站建设怎样,wordpress 前端 修改,缅甸最新新闻文章目录 微前端的发展历史微前端的定义微前端的特点使用微前端面临的挑战微前端常用技术方案及优缺点路由分发式微前端iframesingle-spaqiankunwebpack5: module federationWeb Component 微前端的发展历史
微前端在2016年首次出现在TWTR#xff08;ThoughtWorks Technology… 文章目录 微前端的发展历史微前端的定义微前端的特点使用微前端面临的挑战微前端常用技术方案及优缺点路由分发式微前端iframesingle-spaqiankunwebpack5: module federationWeb Component 微前端的发展历史
微前端在2016年首次出现在TWTRThoughtWorks Technology Radar上把后端微服务的概念扩展到了前端世界。
微前端的定义
维基百科上对微服务的定义**一种软件开发技术面向服务的体系结构架构样式的一种变体将应用程序构造为一组松散耦合的服务并通过轻量级的通信协议组合起来。**具体来说就是将一个单体应用按照一定的规则拆分为一组服务。这些服务各自拥有自己的仓库可以独立开发、独立部署有独立的边界可以由不同的团队进行管理甚至可以使用不同的编程语言来编写。但对前端来说仍然是一个完整的服务。
面对越来越重的前端应用可将微服务的思想照搬到前端就有了微前端的概念。像微服务一样一个前端应用也可以按照一定的规则拆分为不同的子应用独立开发独立部署然后聚合成一个完整的应用面对客户。 微前端的结构一般如下
微前端的特点
简单、分离、松耦合的代码仓库。 对比应用“一大坨”的代码仓库微前端架构下的代码仓库更加简单、轻量。各个仓库的代码可以基于业务、权限、变更的频率、组织结构、后端微服务等原则拆分界限明确降低耦合便于开发人员在开发过程重快速定位源代码降低维护成本。独立开发、独立部署 代码库拆分后我们可以基于各个代码仓库独立开发。由于代码体积的缩小项目构建时间变短极大提升开发效率。 各个项目都有自己的交付流水线构建、测试、上线并且能够独立部署不需要考虑其他项目的情况。技术栈无关 在实际的开发中各个项目会因为各种各样的原因导致使用的技术栈不一样。比如开发框架有react、vue、angluar等构建工具有webpack、rollup、parcel 等而且版本还可能不一样。使用微前端架构可以将使用不同的技术栈不同版本的子应用聚合起来。遗留系统迁移 在公司中多多少少会有一些应用使用的是老的技术栈开发的比如Backbone、Vue1.0、JQuery、Angluar2等。这些应用已经在线上稳定运行而且也没有新的功能。对于这样的应用我们没有理由去浪费时间和额外的经历可以通过微前端方案直接整合到新的应用中。 当然使用微前端很大一部分原因就是为了解决遗留系统的迁移问题。技术栈升级 除了遗留系统迁移微前端在技术栈版本升级方面也能提供帮助。 除了遗留系统迁移微前端在技术栈升级方面也能提供帮助ant-design已经更新到了5但是项目因为一直在迭代还是使用antd2。如果直接重构肯定是不现实的不仅费事费力而且风险也比较大。 对于这种情况我们可以重起一个应用使用antd4 循序渐进的重构应用然后使用微前端方案将新旧应用聚合起来。团队技术成长 和微前端技术栈无关的优点可以让团队获得更多的机会在项目中尝试新的技术Vue3、Webpack5 等有助于整个团队的成长。
使用微前端面临的挑战
微前端方案给我们带来巨大便利的同时也给我们带来了一些挑战。在实现微前端的同时我们必须要考虑的问题
子应用切换应用相互隔离互不干扰子应用之间通信多个子应用并存用户状态的存储 - 免登
微前端常用技术方案及优缺点
目前主流的微前端实现方案主要有
路由分发式微前端iframesingle-spaqiankunwebpack5module federationWeb Component
路由分发式微前端
路由分发式微前端就是通过路由将不同的业务分发到不同的独立前端应用上。最常用的方案是通过 http服务的反向代理来实现。
栗子(▽)/一个基于路由分发的Nginx配置
http {server {listen 80;server_name xxx.xxx.com;location /api/ {proxy_pass http://localhost:3001/api;}location /web/admin {proxy_pass http://localhost:3002/api;}location / {proxy_pass /;}}
}通过上述配置不同页面的请求就可以分发到不同的服务器上。 优点
实现简单不需要对现有应用进行改造完全技术栈无关 缺点用户体验不好每次切换应用时浏览器都需要重新加载页面多个字应用无法并存局限性较大子应用之间的通信比较困难子应用切换时需要重新登录
iframe
iframe作为一项非常古老的技术也可以用于实现微前端、通过iframe我们可以很方便的将一个应用嵌入到另一个应用中而且两个应用之间的 css 和 js 是相互隔离的不会互相干扰。 优点
用户体验不好每次切换应用时浏览器需要重新加载页面。UI不同步DOM结构不共享全局上下文完全隔离内存变量不共享子应用之间通信、数据同步过程较复杂。对SEO不友好子应用切换时可能需要重新登录体验不好。
single-spa
路由转发模式、iframe模式尽管可以实现微前端但是体验不好。每次切换已经访问过的子应用时都需要重新加载子应用对性能有很大影响。
现在前端应用开发的主流模式为基于vue、react、angluar 的单页面应用开发模式。在这种模式下我们需要维护一个路由注册表每个路由对应各自的页面组件url。切换路由时如果是一个新的页面需要动态获取路由对应的js脚本然后执行脚本并渲染出对应的页面如果是一个已经访问过的页面那么直接从缓存中获取已缓存的页面方法执行并渲染出对应的页面。
微前端也有类似的实现方案来获得和单页应用一样的用户体验。
在single-spa方案中应用被分为两类基座应用和子应用。其中子应用就是需要聚合的子应用而基座应用是另外一个单独的应用用于聚合子应用。
和单页应用的实现原理类似single-spa 会在基座应用中维护一个路由注册表每个路由对应一个子应用。基座应用启动后当我们切换路由时如果是一个新的子应用会动态获取子应用的js脚本然后执行脚本并渲染出相应的页面如果是一个访问过的子应用那么就会从缓存中获取已经缓存的子应用激活子应用并渲染出对应的页面。
优点
切换应用时浏览器不用重载页面提供和单页应用一样的用户体验完全技术栈无关多个子应用可并存生态丰富 缺点需要对原有应用进行改造应用要兼容接入single-spa 和独立使用有额外的学习成本使用复杂关于子应用加载、应用隔离、子应用通信等问题需要框架使用者自己实现。子应用间相同资源重复加载启动应用时要先启动基座应用
qiankun
和 single-spa 一样qiankun 也能提供类似单页应用的用户体验。qiankun 是在 single-spa的基础上做了二次开发在框架层面解决了使用single-spa 时需要开发人员自己编写子应用加载、通信、隔离等逻辑的问题是一种比 single-spa 更优秀的微前端方案。
优点
切换应用时浏览器不用重载页面提供和单页面一样的用户体验相比single-spa解决了子应用加载、应用隔离、子应用通信等问题使用起来相对简单。完全和技术栈无关多个子应用可并存 缺点需要对原有应用进行改造应用要兼容接入qiankun和独立使用有额外的学习成本相同资源重复加载启动应用时要先启动基座应用
webpack5: module federation
webpack5 提供一个新特性 module fedaration 。基于这个特性我们可以在一个 js 应用中动态加载并运行另一个js 应用的代码并实现应用之间的依赖共享。
通过module federation我们可以在一个应用里动态渲染另一个应用的页面这样也就实现了多个子应用的聚合。
module federation我们可以在一个应用里动态渲染另一个应用的页面这样也就实现了多个子应用的聚合。
优点
不需要对原有应用进行改造只需改造打包脚本切换应用时浏览器不用重载页面提供和单页应用一样的用户体验。多个子应用可并存相同资源不需要重复加载开发技术栈无关应用启动后无需加载与自己无关的资源免登友好 缺点构建工具只能使用 webpack5有额外的学习成本对有项目不友好需要对webpack 进行改造
Web Component
基于Web Component 的 Shadow Dom 能力我们也可以实现微前端将多个子应用聚合起来。 Shadow Dom 的应用如下 const shadow document.querySelector(#hostElement).attachShadow({mode: open});
// fetch 为应用的地址基于fetch可以获取应用html模版添加到指定节点下
fetch(url).then(res {shadow.innerHTML res;
});优点
实现简单css和js天然隔离互不干扰完全技术栈无关多个子应用可以并存不需要对现有应用进行改造 缺点主要是浏览器兼容性问题开发成本较高
