微服务实现的条件
理想的前端微服务化，应该是符合如下⼏个特点：
⽆所谓技术栈
不影响⽤户的整体体验
使⽤ HTTP 服务器的路由来重定向多个应⽤，即路由分发使⽤ iFrame 及⾃定义消息传递机制
3. 通过组合多个独⽴应⽤、组件来构建⼀个单体应⽤
4. 在不同的框架之上设计通讯、加载机制，诸如 Single-SPA 和 Mooa
5. 使⽤纯 Web Components 构建应⽤
路由分发
路由分发式微前端，即通过设置路由，将不同的业务分发到不同的、独⽴前端应⽤上。其通常可以通过 HTTP 服务器的反向代理来实现，⼜或者是应⽤框架⾃带的路由来解决。
就当前⽽⾔，通过路由分发式的微前端架构应该是采⽤最多、最易采⽤的 “微前端” ⽅案。但是这种⽅式看上去更像是多个前端应⽤的聚合，即我们只是将这些不同的前端应⽤拼凑到⼀起，使他们看起来像是⼀个完整的整体。但是，它们并不是⼀个完整的整体，每次⽤户从 A 应⽤到 B 应⽤的时候，往往需要刷新⼀下页⾯。
通常可通过 nginx 配置反向代理，来进⾏路由分发，从⽽实现前端微服务。
它适⽤于以下场景：
可以接受应⽤切换时，刷新整个页⾯
不同技术栈之间差异⽐较⼤，难以兼容、迁移、改造
项⽬不想花费⼤量的时间在这个系统的改造上
现有的系统在未来将会被取代
系统功能已经很完善，基本不会有新需求
⽽在满⾜上⾯场景的情况下，如果为了更好的⽤户体验，还可以采⽤ iframe 的⽅式来解决。
使⽤ iFrame 创建容器
iframe 可以创建⼀个全新的独⽴的宿主环境，这意味着我们的前端应⽤之间可以相互独⽴运⾏。
采⽤ iframe 有⼏个重要的前提：
⽹站不需要 SEO ⽀持
需要设置加载机制
需要设置通讯机制
即何时加载、卸载应⽤，如何监听应⽤事件等。
nginx部署前端项目框架之上设计通讯、加载机制
不论是基于 Web Components 的 Angular，或者是 VirtualDOM 的 React 等，现有的前端框架都离不开基本的 HTML 元素 DOM。
那么，我们只需要：
在页⾯合适的地⽅引⼊或者创建 DOM
⽤户操作时，加载对应的应⽤（触发应⽤的启动），并能卸载应⽤。
第⼀个问题，创建 DOM 是⼀个容易解决的问题。⽽第⼆个问题，则⼀点⼉不容易，特别是移除 DOM 和相应应⽤的监听。当我们拥有⼀个不同的技术栈时，我们就需要有针对性设计出⼀套这样的逻辑。现有的框架有single-spa、qiankun、mooa等
通过组合多个独⽴应⽤、组件来构建⼀个单体应⽤
常见的⽅式有：
独⽴构建组件和应⽤，⽣成 chunk ⽂件，构建后再归类⽣成的 chunk ⽂件。（这种⽅式更类似于微服务，但是成本更⾼）
开发时独⽴开发组件或应⽤，集成时合并组件和应⽤，最后⽣成单体的应⽤。
在运⾏时，加载应⽤的 Runtime，随后加载对应的应⽤代码和模板。
但是，⾸先它有⼀个严重的限制：必须使⽤同⼀个框架。
其次，采⽤这种⽅式还有⼀个限制，那就是：规范！规范！规范！。在采⽤这种⽅案时，我们需要：
统⼀依赖。统⼀这些依赖的版本，引⼊新的依赖时都需要⼀⼀加⼊。
规范应⽤的组件及路由。避免不同的应⽤之间，因为这些组件名称发⽣冲突。
构建复杂。在有些⽅案⾥，我们需要修改构建系统，有些⽅案⾥则需要复杂的架构脚本。
共享通⽤代码。这显然是⼀个要经常⾯对的问题。
制定代码规范。
纯 Web Components 技术构建
Web Components 组件可以拥有⾃⼰独⽴的 Scripts 和 Styles，以及对应的⽤于单独部署组件的域名。然⽽它并没有想象中的那么美好，要直接使⽤纯 Web Components 来构建前端应⽤的难度有：
重写现有的前端应⽤。是的，现在我们需要完成使⽤ Web Components 来完成整个系统的功能。
上下游⽣态系统不完善。缺乏相应的⼀些第三⽅控件⽀持，这也是为什么 jQuery 相当流⾏的原因。
系统架构复杂。当应⽤被拆分为⼀个⼜⼀个的组件时，组件间的通讯就成了⼀个特别⼤的⿇烦。
浏览器兼容问题
现有框架
现有的微前端框架有single-spa、qiankun、mooa。其均是在前端框架之上设计通讯、加载机制来实现的。
其中single-spa已经实现了⼤部分框架（vue、react、angular）的启动和卸载处理，但不适⽤于⽣产环境
qiankun是基于spa-single实现的以运⾏在⽣产环境为⽬标的微前端服务框架
Mooa是⼀个仅仅基于angular框架的微前端框架

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