前端qiankun微服务单镜像部署方案

阳光穿透心脏的1/2处 2022-09-09 01:54 553阅读 0赞

## 目前状况 ##

目前的部署方式是 5个前端应用都单独打一个docker镜像，单独部署，最后配置kong网关将5个应用连接起来。

## 痛点 ##

由于每个前端都单独打包一个docker镜像，这种做法是非常消耗资源的，首先是5个应用是一个整体，部署时需要全部应用一起上线，5个应用打包5个镜像，每次打镜像都需要操作5次，而且容易出错。每个镜像都是基于nginx镜像来构建，存储每个镜像需要55M，5个应用就是 275M,这是压缩后存储在harbor的容量，真实在服务器中的大小是139M，非常消耗资源。部署时每启动一个应用都相当于启动一个ngixn应用，每页应用占用一个端口，大大浪费了服务器运行内存。  
不像后端应用，前端应用的内容都是静态资源，在运行资源不需要横向扩展，也很少去做高可用的部署方案。  
分离部署的方式只有在修复单个子应用的bug时，再重新部署时会有较轻便的流程。  
但这种分离部署也会造成各种问题，比如各个子应用版本不统一，难以对应。

任何一个实施运维人员去部署前端应用都会感觉吃力，首先他要知道5个应用的镜像名称，然后使用5个端口启动这5个镜像，然后在kong网关里，使用端口和服务名，配置5个route，然后在配置5个service。即使有详细的操作文档，从0部署一整套环境也需要半天时间。更重要的是如果某一个环节出错了，很难调试，运维不懂前端框架，不懂前端资源的调配。前端又不同网关的配置。这个流程很繁琐。  
任何一个优秀的软件都会有良好的用户体验，这个用户体验也包括部署体验，就像rancher，grafana，gitlab，可以只使用一条docker命令就启动整个应用，立即体验所有服务。方便，快捷。让任何小白都能快速启动一个应用。

综上所述，目前单独部署子应用的方式主要存在以下二个痛点

*  构建，部署流程复杂，易出错
 *  资源浪费，浪费存储空间和运行空间，应用维护

## 前端微服务框架qiankun ##

首先需要先补充qiankun框架的知识  
重点要先理解下面这个配置

registerMicroApps([
      { 
        name: 'app',
        entry: 'http://localhost:8080',
        container: '#container',
        activeRule: '/app',
      },
    ]);

这段代码是要运行在基座，就是我们的基础应用里，我们访问应用首先要先访问基座，在点击基座的一些链接时，会根据路由的一定规则来加载相应的资源到配置的dom元素里。  
这个配置包含子应用的所有东西。

*  name 子应用的名称
 *  entry 子应用的入口，首页，访问这个路径，子应用的所有资源都在这个路径下
 *  container 用于显示子应用的页面的容器
 *  activeRule 子应用的路径匹配，当路径中是/app 时，就会装载子应用的资源到页面上

这就是qiankun中子应用注册的核心配置。我们在构建单一镜像需要修改这里，以满足我们的。

有关qiankun微应用的部署，官方是有说到的，提供了二种方式

方案 1：微应用都放在在一个特殊名称（不会和微应用重名）的文件夹下（建议使用）  
方案 2：微应用直接放在二级目录，但是设置特殊的 activeRule

我们使用官方推荐的方案1来实现单一镜像。

方案1的资源存放目录大致如下。

└── html/                     # 根文件夹
        |
        ├── child/                # 存放所有微应用的文件夹
        |   ├── vue-hash/         # 存放微应用 vue-hash 的文件夹
        |   ├── vue-history/      # 存放微应用 vue-history 的文件夹
        |   ├── react-hash/       # 存放微应用 react-hash 的文件夹
        |   ├── react-history/    # 存放微应用 react-history 的文件夹
        |   ├── angular-hash/     # 存放微应用 angular-hash 的文件夹
        |   ├── angular-history/  # 存放微应用 angular-history 的文件夹
        ├── index.html            # 主应用的index.html
        ├── css/                  # 主应用的css文件夹
        ├── js/                   # 主应用的js文件夹

html是根目录，里面存放了主应用（基座应用）的资源，就是build出来的dist目录中的资源。  
然后在根目录创建一个child 文件夹，child 文件夹下，存放这构建出的各个子应用的资源。每一个应用资源一个文件夹。

资源放置的位置是这样的，但需要在构建应用时配置 publicPath ，以及注册子应用是修改为正确的参数。了解了整个流程就开始尝试吧

## CI/CD方案 ##

手动去构建这样一个镜像是及其耗时的，而且很容易出错。所以这种事情交给CI/CD去做。只要流程没问题，最后的结果也不会错。

### 方案一：GitLab CI/CD 的多项目流水线（推荐） ###

在主应用触发，触发各子应用的相同tag的流水线进行构建，将dist制成制品。 最后将各个应用的制品汇总，处理，构建docker镜像。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ou_5oiR5qC85a2Q6KGr5p2l_size_20_color_FFFFFF_t_70_g_se_x_16]

在gitlab ci/cd中， 多项目流水线的制品传递是付费版本才具有的功能，这个我之前调研过了。当我们可以尝试直接通过API来获取特定任务特定分支的的制品下载到当前流水线的上下文中。如果这个路也走不通的话，我们还有备用方案，那就是将应用的制品压缩上传到我们自己的服务器中，最后再下载。或者也可以shell执行器，安装一定规则存放在本地目录中。

### 方案二：在基座的流水线中构建所有应用制品 ###

改方案主要是使用 `Deploy keys`，在基座的流水线中 获取各个子应用的源码，然后进行编译，构建。

方案的思路都是很正确的，但实践起来还是需要一些时间的。

这里还需要考虑一个问题就是，子应用单独打包的问题，  
在运行流水线是，配置一个子应用的分支，表明去哪个分支，tag下取代码进行构建。  
如  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ou_5oiR5qC85a2Q6KGr5p2l_size_20_color_FFFFFF_t_70_g_se_x_16 1]

所有的镜像源文件都会制成一个release发布到gitlab，需要时可以下载，替换部分某个子应用，打包新的镜像。

## 结语 ##

由于该方案是本人在完成紧张的日常工作内容外研究的，搞了二次，前后花了一个多月时间。最终皇天不负有心人。最后成功了，也算是告一段落。

如果你认为是有价值的东西，那就花时间去研究，去学习。无论学什么，做有价值的事情都是值得尊敬的。  
如果你对该方案还有疑问，欢迎找我探讨。  
谢谢遇阅读。

由于涉及到公司的代码，应用，已隐去部分内容。如有突兀，敬请谅解。  
如有问题，欢迎来信与我探讨微服务单镜像的部署方案

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ou_5oiR5qC85a2Q6KGr5p2l_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/0c4f6485469a4c34be5f823046bdd3ce.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ou_5oiR5qC85a2Q6KGr5p2l_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/f2cbb976a374495d8079101f5539655b.png