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年与诸君共勉

---

总结

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。