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工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《Java开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以扫码领取!
总结
三个工作日收到了offer,头条面试体验还是很棒的,这次的头条面试好像每面技术都问了我算法,然后就是中间件、MySQL、Redis、Kafka、网络等等。
- 第一个是算法
关于算法,我觉得最好的是刷题,作死的刷的,多做多练习,加上自己的理解,还是比较容易拿下的。
而且,我貌似是将《算法刷题LeetCode中文版》、《算法的乐趣》大概都过了一遍,尤其是这本
《算法刷题LeetCode中文版》总共有15个章节:编程技巧、线性表、字符串、栈和队列、树、排序、查找、暴力枚举法、广度优先搜索、深度优先搜索、分治法、贪心法、动态规划、图、细节实现题
《算法的乐趣》共有23个章节:
- 第二个是Redis、MySQL、kafka(给大家看下我都有哪些复习笔记)
基本上都是面试真题解析、笔记和学习大纲图,感觉复习也就需要这些吧(个人意见)
- 第三个是网络(给大家看一本我之前得到的《JAVA核心知识整理》包括30个章节分类,这本283页的JAVA核心知识整理还是很不错的,一次性总结了30个分享的大知识点)
片转存中…(img-jK8te4d6-1711394903153)]
- 第三个是网络(给大家看一本我之前得到的《JAVA核心知识整理》包括30个章节分类,这本283页的JAVA核心知识整理还是很不错的,一次性总结了30个分享的大知识点)
[外链图片转存中…(img-ul1l08HS-1711394903153)]
需要更多Java资料的小伙伴可以帮忙点赞+关注,点击传送门,即可免费领取!