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

目前状况

目前的部署方式是 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',
  },
]);

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
 

这段代码是要运行在基座，就是我们的基础应用里，我们访问应用首先要先访问基座，在点击基座的一些链接时，会根据路由的一定规则来加载相应的资源到配置的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文件夹

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
 

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

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

CI/CD方案

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

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

在主应用触发，触发各子应用的相同tag的流水线进行构建，将dist制成制品。 最后将各个应用的制品汇总，处理，构建docker镜像。

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

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

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

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

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

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

结语

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

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

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

文章来源: fizzz.blog.csdn.net，作者：拿我格子衫来，版权归原作者所有，如需转载，请联系作者。

原文链接：fizzz.blog.csdn.net/article/details/119964726