前端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:'localhost:8080',
container:'#container',
activeRule:'/app',
},
]);
这段代码是要运⾏在基座，就是我们的基础应⽤⾥，我们访问应⽤⾸先要先访问基座，在点击基座的⼀些链接时，会根据路由的⼀定规则来加载相应的资源到配置的dom元素⾥。
这个配置包含⼦应⽤的所有东西。
name ⼦应⽤的名称
entry ⼦应⽤的⼊⼝，⾸页，访问这个路径，⼦应⽤的所有资源都在这个路径下
nginx部署前端项目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镜像。
在gitlab ci/cd中， 多项⽬流⽔线的制品传递是付费版本才具有的功能，这个我之前调研过了。当我们可以尝试直接通过API来获取特定任务特定分⽀的的制品下载到当前流⽔线的上下⽂中。如果这个路也⾛不通的话，我们还有备⽤⽅案，那就是将应⽤的制品压缩上传到我们⾃⼰的服务器中，最后再下载。或者也可以shell执⾏器，安装⼀定规则存放在本地⽬录中。
⽅案⼆：在基座的流⽔线中构建所有应⽤制品
改⽅案主要是使⽤ Deploy keys，在基座的流⽔线中 获取各个⼦应⽤的源码，然后进⾏编译，构建。
⽅案的思路都是很正确的，但实践起来还是需要⼀些时间的。
这⾥还需要考虑⼀个问题就是，⼦应⽤单独打包的问题，
在运⾏流⽔线是，配置⼀个⼦应⽤的分⽀，表明去哪个分⽀，tag下取代码进⾏构建。
如
所有的镜像源⽂件都会制成⼀个release发布到gitlab，需要时可以下载，替换部分某个⼦应⽤，打包新的镜像。
结语
由于该⽅案是本⼈在完成紧张的⽇常⼯作内容外研究的，搞了⼆次，前后花了⼀个多⽉时间。最终皇天不负有⼼⼈。最后成功了，也算是告⼀段落。
如果你认为是有价值的东西，那就花时间去研究，去学习。⽆论学什么，做有价值的事情都是值得尊敬的。
如果你对该⽅案还有疑问，欢迎我探讨。
谢谢遇阅读。
由于涉及到公司的代码，应⽤，已隐去部分内容。如有突兀，敬请谅解。
如有问题，欢迎来信与我探讨微服务单镜像的部署⽅案

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