1.2.1 多分支并行开发问题

===============

当多分支并行开发或者能够发版到生产环境的分支较多时，很容易在手动部署的阶段点错，或者看串行，当然这种概率很小。

但是我们可以看到另外一个问题，每次提交或者合并，都会触发构建，当我们使用Git Flow分支流时，可能同时有很多分支都在并行开发、并行测试、并行构建，如果Git Runner是基于虚机创建的，很有可能会出现构建排队的情况，当然这个排队的问题，也是能解决的。

1.2.2 多微服务配置维护问题

================

其次，如果一个项目稍微大一些，维护起来也不是很方便。比如这个准备要迁移的项目，一个前端和二十多个业务应用，再加上Zuul、ConfigServer、Eureka将近三十个服务，每个服务对应一个Git仓库，然后每个服务同时在开发的分支又有很多，如果想要升级GitLab CI脚本或者微服务的机器想要添加节点，这将是一个枯燥乏味的工作。

1.2.3 安全问题

==========

最后，还有一个安全的问题，GitLab的CI脚本一般都是内置在代码仓库里面的，这就意味着任何有Push或者Merge权限的人都可以随意的修改CI脚本，这会导致意想不到的结果，同时也会威胁到服务器和业务安全，针对发版而言，可能任何的开发者都可以点击发版按钮，这些可能一直都是一个安全隐患。

但是这些并不意味着Git Runner是一个不被推荐的工具，新版的GitLab内置的Auto DevOps和集成Kubernetes依旧很香。但是可能对于我们而言，使用Git Runner进行发版的项目并不多，所以我们想要统一发版工具、统一管理CI脚本，所以可能其它的CI工具更为合适。

1.3 为什么要容器化？

============

1.3.1 端口冲突问题

============

容器化之前这个项目采用虚机部署的，每个虚拟机交叉的启动了两个或者三个微服务，这会遇到一个问题，就是端口冲突的问题，在项目加入新应用时，需要考虑服务器之间端口冲突问题的，还要考虑每个微服务的端口不能一样，因为使用虚拟机部署应用时，可能会有机器节点故障需要手动迁移应用的情况，如果部分微服务端口一样，迁移的过程可能会受阻。

另外，当一个项目只有几个应用时，端口维护起来可能没有什么问题，像本项目，涉及三十多个微服务，这就会成为一件很痛苦的事情。而使用容器部署时，每个容器相互隔离，所有应用可以采用同样的端口，就无需再去关心端口的问题。

1.3.2 程序健康问题

============

使用过Java程序的人大部分都遇到过程序假死的情况，比如端口明明是通的，但是请求就是不处理，这就是一种程序假死的现象。而我们在使用虚机部署时，往往不能把健康检查做的很好，或许在虚机上面并没有做接口级的健康检查，这就会造成程序假死无法自动处理的问题，并且在虚机上面做一些接口级的健康检查及处理操作并不是一件简单的事情，同样也是一件枯燥乏味的事情，尤其是当一个项目微服务过多，健康检查接口不一致时更为痛苦。

但在k8s上面，自带的Read和Live探针用以处理上面的问题就极其简单，如图所示，我们可以看到目前支持三种方式的健康检查：

• tcpSocket: 端口健康检查

• exec: 根据指定命令的返回值

• httpGet: 接口级健康检查

同时这些健康检查的灵活性也很高，可以自定义检查间隔、错误次数、成功次数、检查Host等参数，而且上面提到的接口级健康检查httpGet也支持自定义主机名、请求头、检查路径以及HTTP或者HTTPS等配置，可以看到用k8s自带的健康检查可以省去我们很大一部分工作，不用再去维护非常多令人讨厌的脚本。

1.3.3 故障恢复问题

============

在使用虚机部署应用时，有时可能会碰到宿主机故障，单节点的应用无法使用，或者多节点部署的应用由于其他副本不可用，导致自身压力大出现服务延迟的情况。而恰恰宿主机无法很快恢复，这时可能就需要手动添加节点或者需要新加服务器才能解决这类问题，这个过程可能会很漫长，或许也很痛苦。因为需要去准备依赖环境，然后才能去部署自己的应用，并且有时候你可能还需要更改CI脚本。。。

而使用k8s编排时，我们无需关心这类问题，一切的故障恢复、容灾机制都由强大的k8s负责，你可以去喝杯咖啡，或者你刚打开电脑去处理这个问题时，一切都已经恢复如初。

1.3.4 其他小问题

===========

当然k8s给我们带来的便利性和解决的问题远不止上面所说的，容器镜像帮我们解决了依赖环境的问题，服务编排帮我们解决了故障容灾的问题，我们可以使用k8s的包管理工具一键创建一套新的环境，我们可以使用k8s的服务发现让开发人员无需再关注网络部分的开发，我们可以使用k8s的权限控制让运维人员无需再去管理每台服务器的权限，我们可以使用k8s强大的应用程序发布策略让我们无需过多的考虑如何实现零宕机发布应用及应用回滚，等等，这一切的便利性正在悄悄的改变着我们的行为。

2. 迁移计划

========

2.1 蓝绿迁移

========

首先来看一下迁移之前的架构

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

结尾

这不止是一份面试清单，更是一种”被期望的责任“，因为有无数个待面试者，希望从这篇文章中，找出通往期望公司的”钥匙“，所以上面每道选题都是结合我自身的经验于千万个面试题中经过艰辛的两周，一个题一个题筛选出来再次对好答案和格式做出来的，面试的答案也是再三斟酌，深怕误人子弟是小，影响他人仕途才是大过，也希望您能把这篇文章分享给更多的朋友，让他帮助更多的人，帮助他人，快乐自己，最后，感谢您的阅读。

由于细节内容实在太多啦，在这里我花了两周的时间把这些答案整理成一份文档了，在这里只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！
时间把这些答案整理成一份文档了，在这里只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！**
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！