2024：成长和学习之旅

前言

    不知不觉，2024年已经悄然远去，2025年第一个月份也快结束了。。。我本身也不是什么名牌大学毕业，更不是什么知名博主，没有什么证书好展现的，有的仅仅是对技术的热忱之心。想把自己平时工作中所思所悟，所感所念，以博客的形式体现出来，这样可以更清晰的认识到自身的不足。当然，如果能帮助到大家，那就更加喜闻乐见了

2024，既是学习，又是总结

    在2024上半年，由于工作上的原因，主要精力放在了学习 DevOps、云原生 上了。正所谓：骐骥一跃，不能十步。驽马十驾，功在不舍。为此，我在 CSDN 查阅了大量的博客

在系统学习完成后，逐渐在开发、测试环境上实践部署完整的云原生环境。等到2024年中，生产环境趋于稳定，这才慢慢把精力放在研究在 Spring 上，也是由于之前在面试官提问之时，项目改造之际。发现了自己对 Spring 理解其实并不到位，很多时候只是知其然，不知所以然。每一次扪心自问，如果自己是面试官，面对面试者自吹自擂，说自己会这个会那个，读过XXX源码，结果却是一问就倒。这样子如何让人肯信？所以才下定决心对 Spring 进行更为系统、深入的了解

学习并实践云原生

    说来也惭愧，虽然出来工作了好几年了，但是对于 DevOps、云原生 一直都是处于只闻其名，未见其面的状态。每次跟别人吹牛皮时，都觉得很厉害的样子，有心想要实践，但是工作上却一直没有机会。直到2024年，接到了个双活改造的需求，这才让我的想法有了真正的实践机会。当然，本着技术并不是为了新而新，变而变。在真正实施的过程中，有所取舍。不忘初心，真正的追求永远都是减少无意义的重复劳动，能做到少加班、甚至不加班。为此，我总结了工作中的几个弊病，并尝试引入新技术进行解决：

• 代码管理混乱，甚至存在人员离职后，代码找不到的问题

• 打包麻烦，由于代码不全，所以无法直接进行编译打包，还得一个个反编译进行对比

• 没有相应的代码审查，无法保证代码质量

• 没有专门的运维，开发常常兼职运维的工作，导致无法专心于开发，时间浪费在部署环境、查找问题上

• 生产上要搭建双活环境。再加上现在已有的集群，动辄几十台机子。所有机子都要安装一遍Redis、Nginx，这工作量简直不可想象

• 各个机子的配置，软件版本存在差异，把测试环境的软件包拿过去安装，发现版本对不上，导致安装失败，简直让人崩溃

• 现在系统已经多达十几个，新老系统交错，各类技术混用。这么对这些系统进行统一管理、服务治理、服务发现也是个很头疼的问题

• 因为系统多，导致整个调用链路很长，日志分散。之后出现生产问题，无法快速定位问题

• 日志存在大报文，容易磁盘预警

• 现在发布版本，常出现生产问题，虽然有版验环境，但实际上效果不佳，生产需要有灰度环境，以及快速回滚的方式

• 定时任务分散，无法发挥集群的优势，无法监控，无法终止，无法手动调用

针对以上问题，我在 CSDN 查阅了大量的资料，发现业内已经有现成的解决方案：

• 代码管理、编译打包、代码审查其实都属于相同问题，或者说都是因为代码不全、管理不当导致的问题，那就毫无疑问了，引入 Git 就能解决，毕竟代码管理是后面一系列操作的根本

• 针对开发兼职运维的工作，可以通过CI/CD来实现，开发只需要提交代码，而后自动触发自动部署流程。即开发提交代码到CVS，Jenkins主动拉取最新代码，触发部署流程

• 对于十几台机子要重复安装环境，这方面也有专门的部署工具，如：Ansible。通过Ansible编写剧本达到部署整个集群的目的

• 至于环境之间存在差异，可以通过容器化解决，通过 Docker 来屏蔽系统之间的差异，实现移植的目的

• 在基于 容器化 的前提下，不同系统的之间的 统一管理、服务治理、服务发现 也方便实现了，可以通过 k8s 和 istio 进行实现。至于为什么采用 服务网格 而不是SpringCloud，是因为现有系统不全是SpringBoot项目，有些老项目直接用 SSH（ Struts2、Spring，Hibernate），有些甚至更古老，改造起来非常麻烦，风险也大。还有些项目用的是 Python 实现，这样子 SpringCloud 就更不适用了。基于以上种种，故而选择 服务网格 的方式

• 针对日志分散、占用空间大、链路长的问题，势必要引入 ELK 进行统一管理，链路长可以通过 链路追踪 进行解决

• 对于灰度环境的需求，实际上可以通过 istio 和 Flagger 进行灰度发布，以及动态部署

• 定时任务的问题，也很典型，业内也有了对此的思考，那就是 XXL

    设想是很美好的，现实却是很骨感的。在实践的过程中，发现项目人员最初并没有代码管理的意识、也没有提交代码的习惯，所以虽然引入了 Git，却还要在花时间进行熟悉、学习。一下子引入这么多东西，虽然可以提高项目整体的管理、部署效率，但是随之增加的是服务器成本、学习成本。对于一个项目来说，这种代价或许太沉重了。实际的实施和美好的设想总会有出入，照本宣科总是要付出血的代价，我也深刻体会到了：纸上得来终觉前，绝知此事要躬行。虽然计划并没有完全实现，但是我对 云原生、DevOps 这些东西不再陌生了，因为我曾经参与并实践过

研究并总结Spring

    在完成项目上的事情后，反思了下自己的所作所为，发现自己对底层的东西还有点缺漏，于是逐渐把重心放在了 Spring 源码上了。准备从 IOC、AOP、事务、MVC、Boot 这几方面入手，逐步解开 Spring 神秘的面纱。幸运的是，现在前面几部分基本上都已经完成了，只剩 Boot 还在负隅顽抗，不过，我相信他也坚持不了多久了。

    在写作的过程中，发现很多地方看似简单，实际上另有乾坤，很多地方都是自己想当然了。这也许就是写博客的好处之一了吧。在此期间，也收获了一些粉丝，也有人会私信鼓励我，也有人会评论提意见或是指出错误的地方，相比于之前自己闭门造车，这样子的学习方式显然是可持续的，能有人一起讨论，一起研究。孔子曰：三人行，必有我师。说的就是这种情况吧。虽然，现在的粉丝、阅读量还不是很多，但是还是希望我能够把写作发展成一个习惯，把自己的理解、感悟勇敢的发表出来，过则改，无则加勉。这里也感谢粉丝长久以来的支持了

回顾2024年度报告，每一组数据都记录着过去一年的努力与进步，它们见证了我在技术道路上的成长轨迹，也是对未来继续前行的最大动力。所谓：九层之台，起于累土；千里之行，始于足下。未来怎么样我没法知道，但是既然选择了远方，便只顾风雨兼程

展望未来

    原本计划的 Spring 源码，现在基本上也进入了尾声。估计再有一个月，就能把 Boot 篇章完成了，不要嫌弃我更新太慢了，毕竟只有在工作之余，闲暇之时才能开始写，期间还要不断地验证，勘校避免自己有理解错误的地方，困难重重

    等到把 Spring 相关章节完成后，估计也会开启新的篇章，也许是 Mybatis，也许是 Tomcat，也有可能是 JVM。预计就是这几个技术了，期间如果有变故，那就只能视情况而定了。可能前路也会有很多的困难，但有了研究 Spring 源码的经验，相信其他技术也差不多了，只要明白其思想，代码也就不是事了。2025年与诸君共勉

总结

    好啦，废话也不多说了。在这里再次感谢支持我的同行，无论是你们的批评、还是鼓励，都是我前行的动力（当然，批评的时候轻点喷，不然道心都要给干碎了）。新的一年里，希望大家心想事成、阖家欢乐、升职加薪。无论遇到什么困难都能克服，勇往直前，到达梦想的彼岸。最后让我们一起在日新月异的信息时代，一起探索技术的本质，享受科技带来的便捷