随着Web标准的发展，前端应用程序的性能和更快的开发效率更高。但是，应用程序的复杂性更高，所涉及的团队的规模是更大且更高的性能要求。该应用程序的复杂性已成为阻止业务发展的重要瓶颈。
传统的战略部门无法应付现代Web应用程序的复杂性。因此，得出了一个新的体系结构模型，例如微型前端。相同的微服务与后端微服务相同。要实现的方法。主流解决方案包括单SPA，Qiankun和其他框架。
平台翻新之前：
随着现有平台系统的促销和开发，更多的项目可以访问。
早期的子项目访问转换的主要内容：
结果：子项目成为整个平台系统的一部分，该系统具有登录的能力，并且可以使用与助手相关的小型功能。
现有现象：n项目需要访问转换n次，随后的相关功能升级和维护，工作量也是n次，转型又大且重复性，同时增加了人力投资的成本。
问题结论：
如果它是在传统的前端研发模型中开发的，则有两种项目设计策略：
大型的Web应用程序面对高度复杂性并参与团队成员，他们不能同时确保开发经验和用户体验的困境。传统的策略划分不再能够应对现代Web应用程序的复杂性从整体平台系统的前端项目的实际情况来看，上述两种方法的转换成本太大。
思考：是否有可以解决现有问题的新体系结构？
现有问题：
为了解决对整个背部末端服务造成的变化和扩展的限制，已经出现了微服务。但是，越来越重的前端项目也正面临着同样的问题。自然地，将微服务（复制）应用于前端，因此存在“微额定”的概念：一个由独立交付独立交付的独立交付，形成了整体体系结构样式。
重建计划研究和分析：
SPA1，更好的代码重用，可以解决公共容量升级和管理问题
2.水疗中心具有本地更新，操作经验流程，可以解决用户经验的问题1.无法解决技术堆栈差异的问题，转换和维护的成本很高
2.很难通过隔离机制进行渐进式转换1，3iframe1，这可以解决技术堆栈差异的问题。
2.由于其自身的特征，无法解决用户体验的问题。2微型前端1.良好的代码重用可以解决升级和管理公共能力的问题
2.它与技术堆栈无关，这可以解决技术堆栈差异的问题
3.基于水疗中心，它可以改善用户体验1.有一定的学习成本，以及改变成本的成本
2.基础设施复杂性提高了计划1、2和3的选择原理：
微正面 - 端是类似于微服务的架构。这是一种整体架构样式，由独立交付的多个前端应用程序提供。前端应用程序分解为一些可以独立开发，测试和部署的较小，更简单的应用程序。根据用户的条件，它仍然是内部收集的单一产品。
用于构建具有多个团队的现代网络应用程序的技术，策略和食谱，可以独立运输功能。- 微端前端微端前端。这是一种构建现代方式的基于多团体的方式。
Micro前端架构具有以下核心值：
技术选择是指以下纬度：
基于上述纬度，我们选择了两个微型前端框架，即单SPA和Qiankun。
微观 - 前方案调查
单SPA与技术堆栈，盒子的使用，解决方案成熟，CSS隔离，未处理CSS隔离，JS执行隔离和其他问题Qiankun基于单SPA包装，这提供了一个，这提供了一个，该问题提供更多使用API打开盒子。
样式隔离
JS沙盒调试复杂性增加了上述两个方案比较：
总而言之，最终选择微型前端转换的Qiankun框架
根据Qiankun Micro Front -End体系结构，我们将整个系统平台分为一个主要应用程序和多个子应用程序。主要应用程序主要集成公共能力模块。子申请主要是每个子平台的单页应用程序。
相关关键字简介：
转型期间遇到了一些问题：
重建问题1：主要设计和资源部署
现象：着陆页占据了根目录。子应用程序无法在主应用程序中获得入口，也无法加载。
原因：通过主应用程序执行对子申请资源的访问。主应用程序用于通过Activerule识别子申请，并通过获取来请求相应的HTML文件以激活sub -application.in root Directory。
解决方案：
提案一个主应用程序和子应用程序被部署到两个域名，以增强高膨胀的网关配置和转换成本。前端访问路径需要添加到一层路径上，这会影响用户的原始用法解决方案。移民到根目录网关转换低成本
选择用户使用最小前端的最小前端的原则可以增加成本方案，最大程度地减少变更成本并降低人工成本。最后，选择了两个方案
重建问题2：子申请资源无法正常访问
现象：不应通过提取触发主人。
原因：由于路由配置的不一致规格，子申请路由被网关的配置截获了
解决方案：
一个孩子的应用程序更改了扩展网关配置的域名增强和转换的高成本，从而影响了后端API访问解决方案。
选择用户使用最小前端的最小前端的原则可以增加成本方案，最大程度地减少变更成本并降低人工成本。最后，选择了两个方案
重建结果：
成就1：解决升级和管理整体系统公共能力，简化访问过程并提高转型工作的发展效率的问题。转换工作时间从4小时缩短到大约1小时
成就2：通过Qiankun的微型前端框架能力，解决了小型助理公共模块技术堆栈的适应问题
作为平台的公众依赖性，小型助理模块由微观 - 末端转换进行转换，并且只有需要适应主要应用程序的技术系统，并且不再需要适应各种子应用的技术堆栈。
成就三：第一次加载页面后，主应用程序将添加预载sub -application资源，然后在sub -platforms之间切换，这可以实现作为访问单页应用程序的平滑体验。
微观前端概念的出现是前端发展的必然阶段。在移动互联网时代的PC Internet时代，PC场景并未完全消除。相应的建筑模型应响应这些应用程序的增长。
微型前端不是银炸弹。微型前端的复杂性并未消失在稀薄的空气中。取而代之的是，它从代码转变为基础架构，这给建筑设计带来了更大的挑战。执行工具和生态学以帮助这种新的研发模型。
可以看到特定的代码实现：https：//juejin.cn/post/7073481273183830052
原始：https：//juejin.cn/post/70990319585226760