故事的结尾
- 从微前端的
qiankun去年开始火的时候，我就留神到了，咱们公司的Saas零碎是能够用这个去解决 UI、体验上的一些问题，以及让技术栈平滑过渡迁徙，然而奈何机会不够成熟 -
往年抓住了机会，感觉是时候推动微前端了，加上公司外部的
星舟平台（Devops 平台）也开始推广，我开始寻思革新这个事革新不为了炫技，仅仅为了晋升开发、用户体验！当你须要微前端的时候，再用它
我在公司外部做了一个技术分享
- 我的微前端革新是利用 k8s + qiankun + ingress(path)的配置，达到疾速部署的目标，齐全无跨域问题
革新背景
- 目前存在几个站点，然而站点之间的 UI 展示不一样，咱们看起来很不业余
- 不同站点明明都所属于咱们部门的零碎，然而跳转时却须要整体的跳转并且出全副的白屏，用户体验很差
- 无奈承接全局性的需要，例如：多个站点技术栈版本不一样，这里要做一个需要，须要去几个不同的版本技术栈中实现一次，还很难放弃成果统一
why not iframe
- 为什么不必 iframe，这简直是所有微前端计划第一个会被 diss 的问题。
- 然而大部分微前端计划又不谋而合放弃了 iframe 计划，天然是有起因的，并不是为了 “ 炫技 ” 或者刻意追求 “ 特立独行 ”。
- 如果不思考体验问题，iframe 简直是最完满的微前端解决方案了。
- iframe 最大的个性就是提供了浏览器原生的硬隔离计划，不论是款式隔离、js 隔离这类问题通通都能被完满解决。但他的最大问题也在于他的隔离性无奈被冲破，导致利用间上下文无奈被共享，随之带来的开发体验、产品体验的问题。
- url 不同步。浏览器刷新 iframe url 状态失落、后退后退按钮无奈应用。
UI 不同步，DOM 构造不共享。设想一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时咱们要求这个弹框要浏览器居中显示，还要浏览器 resize 时主动居中.. - 全局上下文齐全隔离，内存变量不共享。iframe 内外零碎的通信、数据同步等需要，主利用的 cookie 要透传到根域名都不同的子利用中实现免登成果。慢。每次子利用进入都是一次浏览器上下文重建、资源从新加载的过程。
- 其中有的问题比拟好解决 (问题 1)，有的问题咱们能够睁一只眼闭一只眼(问题 4)，但有的问题咱们则很难解决(问题 3) 甚至无奈解决(问题 2)，而这些无奈解决的问题恰好又会给产品带来十分重大的体验问题，最终导致咱们舍弃了 iframe 计划。
下面抄的阿里的对于 qiankun 的介绍，我感觉挺好，曾经拿小本本记下来默默背诵了
微前端对我来说它的外围价值
- 技术栈无关 – 解构巨石利用
- 计划上跟应用 iframe 做微前端一样简略，同时又解决了 iframe 带来的各种体验上的问题。现实状态下，以此为指标的微前端利用，是主动具备流通能力的，且这个流通能力不会因为主利用的实现降级而丢失（也就是说在 21 年能接入主利用的微前端利用，到了 2025 年也应该能失常接入失常运行，并同样保有在不同主利用间流通的能力）
- B 端产品生命周期长, 确保咱们的祖传代码能平滑的迁徙，以及如何确保我在若干年后还能用上时下热门的技术栈
-
增强咱们平台、产品的集成能力，企业级我的项目十分须要这个
正式开始
什么是微前端？
微前端是一种多个团队通过独立公布性能的形式来独特构建现代化 web 利用的技术手段及办法策略
- 微前端架构旨在解决单体利用在一个绝对长的时间跨度下，因为参加的人员、团队的增多、变迁，从一个一般利用演变成一个巨石利用后，随之而来的利用不可保护的问题。
-
这类问题在企业级 Web 利用中尤其常见
微前端原理
子利用通信机制
多方思考, 抉择了业内支流成熟的 微前端框架：qiankun
qiankun 的外围设计理念
- 🥄 简略 因为主利用微利用都能做到技术栈无关，qiankun 对于用户而言只是一个相似 jQuery 的库，你须要调用几个 qiankun 的 API 即可实现利用的微前端革新。同时因为 qiankun 的 HTML entry 及沙箱的设计，使得微利用的接入像应用 iframe 一样简略。
- 🍡 解耦 / 技术栈无关 微前端的外围指标是将巨石利用拆解成若干能够自治的松耦合微利用，而 qiankun 的诸多设计均是秉持这一准则，如 HTML entry、沙箱、利用间通信等。这样能力确保微利用真正具备 独立开发、独立运行 的能力。
革新前的部署
- 革新前的部署，解析域名的
path, 依据path的不同，例如:myfuwu.com.cn/A 就指向了 我的项目 1
革新后的部署
- 因为
k8s有配置多个ingress path的能力，所以我将之前的A B C D的path全副指向了微前端的基座我的项目，这样用户拜访的时候，只会先拜访到基座我的项目 -
基座我的项目再解析 url, 依据 url 去匹配加载真正的子利用。（此时有一个保护的注册表，例如当
path为A的时候，就去申请部署在F的我的项目）这样就做到了，微前端不跨域，不改任何代码外面的跳转门路，就实现了部署。
- 从开始部署到部署胜利，我仅仅用了 20 分钟，所以业余的 Devops 平台很重要
遇到的问题
- 微前端模式再去通过 iframe 嵌套某个微前端模式下子利用页面的时候，写在子利用外面的 window.xx 办法会找不到，这个时候须要写在基座的 window 外面
- 倡议通过 script 等加载的依赖对立放到 oss 或者本人的文件服务上，这样不便设置跨域等
- 如果有可能加载两次的 script, 要加上 ignore 属性，不然会报错
- 款式隔离很重要，倡议用 class 辨别
- 开发模式不必开启预加载，生产模式开启预加载体验好很多
总结
- 整体来说，微前端的难点在于最低老本的实现革新，像我这样不改我的项目外面的代码，做到最低的老本，让其余小伙伴既能独自开发部署子利用，也能够被集成到微前端模式下
- 过后我遇到最奇葩的问题是 OSS，阿里云的 OSS 常常返回不带跨域的 cors 头，导致用户可能白屏，我间接把 OSS 去掉，本人做了一个文件服务，专门寄存动态资源（这个问题，真的很重大，咱们是企业级利用，白屏能够说是超级重大的问题，然而还好及时把流量切走了，前面解决了这个问题）
顺便吐槽一下明天客户应用咱们的零碎，一个小姐姐，电话外面我跟她说：您好，我是 xxx 的研发，请问您明天是登录不了了吗？能够近程帮您看看吗？
- 后果小姐姐让咱们排查了一天，最初发现，她的账号是小写，后果她填了大写导致登录不上，差点让咱们连夜买火车站票跑路
如果感觉写得不错，帮我点个
星标 / 在看 / 赞 / 关注 / 转发吧
或者你须要微前端更多材料也能够 加我微信 ， 关注公众号 后菜单栏有分割我的形式～