Kubernetes实战指南:零宕机无缝迁移Spring Cloud至k8s
当然k8s给我们带来的便利性和解决的问题远不止上面所说的,容器镜像帮我们解决了依赖环境的问题,服务编排帮我们解决了故障容灾的问题,我们可以使用k8s的包管理工具一键创建一套新的环境,我们可以使用k8s的服务发现让开发人员无需再关注网络部分的开发,我们可以使用k8s的权限控制让运维人员无需再去管理每台服务器的权限,我们可以使用k8s强大的应用程序发布策略让我们无需过多的考虑如何实现零宕机发布应用及应
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核心知识整理
- Spring全家桶(实战系列)
Step3:刷题
既然是要面试,那么就少不了刷题,实际上春节回家后,哪儿也去不了,我自己是刷了不少面试题的,所以在面试过程中才能够做到心中有数,基本上会清楚面试过程中会问到哪些知识点,高频题又有哪些,所以刷题是面试前期准备过程中非常重要的一点。
以下是我私藏的面试题库:
很多人感叹“学习无用”,实际上之所以产生无用论,是因为自己想要的与自己所学的匹配不上,这也就意味着自己学得远远不够。无论是学习还是工作,都应该有主动性,所以如果拥有大厂梦,那么就要自己努力去实现它。
最后祝愿各位身体健康,顺利拿到心仪的offer!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
主动性,所以如果拥有大厂梦,那么就要自己努力去实现它。
最后祝愿各位身体健康,顺利拿到心仪的offer!
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
更多推荐
所有评论(0)