前端iframe 能指定本地网页吗_微前端的技术拆分方式

路由分发式

• 通过HTTP服务器的反向代理功能，将请求路由到对应的应用上

特点

• 采用的最多、最容易的“微前端”方案
• 并非一个整体，每当用户从A应用转换到B应用的时候，往往需要刷新一下页面，重新加载资源文件
• 缺少了对应用状态的处理，需要用户重新登录，这种体验对用户来说相当不友好

前端微服务化

• 在不同的框架之上设计通信和加载机制，以在一个页面内加载对应的应用

特点

• 一个页面上同时存在两个及以上的前端应用在运行，而路由分发式方案则是，一个页面只有唯一一个应用
• 在页面合适的地方引入或者创建DOM
• 用户操作时，加载对应的应用(触发应用的启动)，并能卸载应用
• 还需要保证应用间的第三方依赖不冲突，可以通过向上游开发者提Pull Request来修复这个问题

微应用

• 通过软件工程的方式，在部署构建环境中，把多个独立的应用组合成一个单体应用

特点

• 大都是以软件工程的方式来完成前端应用的开发的，因此又可以称之为组合式集成
• 通过业务作为主目录，然后在业务目录中放置相关的组件，同时拥有一些通用的共享模板
• 拆分出每个模块之后，便只需要在构建的时候复制所有的模块到一个项目中， 再进行集成构建
• 微应用化就是微前端的一种实践，只是使用微应用化意味着我们只能使用唯一的一种前端框架

微件化

• 开发一个新的构建系统，将部分业务功能构建成一个独立的chunk代码，使用时只需要远程加载即可

特点

• 每个业务团队编写自己的业务代码，并将编译好的代码部署到指定的服务器上，在运行时，我们只需要加载相应的业务模块即可(未来WebComponents)

• 单页应用时代为了支持微件化，需要做：

  • 持有一个完整的框架运行时及编译环境。用于保证微件能正常使用，即可调用框架API等

  • 性能受影响，应用由提前编译变成运行时才编译，会造成一些性能方面的影响，具体视组件的大小而定

  • 提前规划依赖，如果一个新的微件想使用新的依赖，需要从上游编译引入

• 此外还需要一个支持上述功能的构建系统，它用于构建一个独立的微件模块，这个微件的形式如下：

  • 分包构建出来的独立代码，如webpack构建出来的chunk文件

  • 使用DSL的方式编写出来的组件

• 为了实现这种方式，我们需要对前端应用的构建系统进行修改，如webpack，使它可以支持构建出单个的代码段，这种方式的实施成本比微应用化成本高

前端容器化

• 将iframe作为容器来容纳其他前端应用

特点

• 有效地将另一个网页/单页面应用嵌入当前页面中，两个页面间的CSS和JavaScript是相互隔离的，除去iframe父子通信部分的代码，它们之间的代码完全不会相互干扰，类似于沙箱隔离
• 采用iframe的前提是网站不需要SEO支持，设计相应的应用管理机制

应用组件化

• 借助于Web Components技术，来构建跨框架的前端应用

特点

• Web Components是一套不同的技术，允许开发者创建可重用的定制元素(它们的功能封装在代码之外)，并且在Web应用中使用它们
• 离现在的我们还有些距离，是一种面向未来演进的架构
• 只需要在页面中通过Web Components引入业务模块即可，其使用方式类似于微件化的方案
• 目前困扰Web Components技术推广的主要因素在于浏览器的支持程度

- END -