• 微前端原理解析


    前言

    微前端将web应用由单一的单体应用转变为多个小型前端应用聚合为一的应用,每个前端应用还可以独立运行、独立开发、独立部署。同时,他们也可以在共享组件的同时进行并行开发–这些组件可以通过Git Tag等来管理。

    使用微前端框架对旧有的服务运行,而使用新框架构建新服务是最好的尝试。

    微前端构建的应用是前后端分离的单页面应用,在此基础上微前端才有意义。

    分类

    微前端架构一般分为以下路线:

    • 使用HTTP服务器的路由来重定向多个应用
    • 自制框架:在不同的框架上设计通讯、加载机制、如Mooa
    • 通过组合多个独立应组件来构建一个单体应用
    • 使用iFrame及自定义消息传递机制
    • 使用纯 Web Components构建应用
    • 结合 Web Components 构建

    在形式上说,单体前端框架的路由和单体后端应用没有太大区别:依据不同的路由,来返回不同页面的模版

    原先单页面应用的路由配置:

    const appRoutes: Routes = [
      { path: 'index', component: IndexComponent },
      { path: 'detail/:id', component: DetailComponent },
    ];
    
    • 1
    • 2
    • 3
    • 4

    当我们将之微服务后,应用A的路由:

    const appRoutes: Routes = [
      { path: 'index', component: IndexComponent },
    ];
    
    • 1
    • 2
    • 3

    以及应用B的路由:

    const appRoutes: Routes = [
      { path: 'detail/:id', component: DetailComponent },
    ];
    
    • 1
    • 2
    • 3

    路由分发式微前端

    使用HTTP服务器的反向代理或应用框架自带的路由,通过路由将不同的业务分发到不同的、独立前端应用上。

    这种方式每跳转到一个应用,相当于刷新一次页面

    如下是一个基于路由分发的Nginx配置:

    http {
      server {
        listen       80;
        server_name  www.phodal.com;
        location /api/ {
          proxy_pass http://http://172.31.25.15:8000/api;
        }
        location /web/admin {
          proxy_pass http://172.31.25.29/web/admin;
        }
        location /web/notifications {
          proxy_pass http://172.31.25.27/web/notifications;
        }
        location / {
          proxy_pass /;
        }
      }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18

    使用iFrame构建容器

    采用iFrame可以创建一个全新的独立的宿主环境,有效地将另一个HTML页面嵌入到当前页面中

    采用iFrame有两个重要的前提:

    • 网站不需要SEO支持
    • 拥有相应的应用管理机制

    自制框架兼容应用

    不论是基于 Web Components 的 Angular,或者是 VirtualDOM 的 React 等,现有的前端框架都离不开基本的 HTML 元素 DOM

    那么,我们只需要:

    1. 在页面合适的地方引入或创建DOM
    2. 用户操作时,加载对应的应用(触发应用的启动),并卸载应用

    第2个问题关键在移除DOM和相应应用的监听。

    尽管如react等Single-Page框架已经拥有启动和卸载处理,但是它仍然不适应生产用途,需要重写一个框架,如Mooa

    组合式集成:将应用微件化

    组合式集成,即通过软件工程的方式在构建前、构建时、构建后等步骤中,对应用进行一步的拆分,并重新组合。

    从这种定义上来看,它可能算不上并不是一种微前端——它可以满足了微前端的三个要素,即:独立运行、独立开发、独立部署。但是,配合上前端框架的组件 Lazyload 功能——即在需要的时候,才加载对应的业务组件或应用,它看上去就是一个微前端应用。

    但是,首先它有一个严重的限制:必须使用同一个框架。对于多数团队来说,这并不是问题。采用微服务的团队里,也不会因为微服务这一个前端,来使用不同的语言和技术来开发。当然了,如果要使用别的框架,也不是问题,我们只需要结合上一步中的自制框架兼容应用就可以满足我们的需求。

    采用这种方式由一些限制,就是规范,我们需要:

    • 统一依赖。统一这些依赖的版本,引入新的依赖时需要一一加入。
    • 规范应用的组件及路由。避免不同应用之间组件名称冲突
    • 构建复杂。在有些方案中,我们需要修改构建系统,有些方案里则需要复杂的构建脚本。
    • 共享通用代码。
    • 制定代码规范

    纯 Web Components 技术构建

    Web Components 是一套不同的技术,允许构建可重用的定制元素(它们封装在您的代码之外)并且在您的web应用中使用它们,它主要由四项技术组件:

    • Custom elements,允许开发者创建自定义的元素
    • Shadow DOM,即影子DOM,通常是将Shadow DOM附加到主文档DOM中,并可以控制其关联的功能。而这个Shadow DOM则是不能直接用其他主文档DOM来控制。
    • HTML templates,即