2018,我的年终总结

前言

本文实际上是昨天我在公司里写的一篇年终总结,我想了想,发到博客里吧,去掉了敏感信息,另外做了其他的一些适当的改动。

正文

我自己总结了一下,从入职到现在,我的工作逐步形成了四条路线:业务开发、技术探索、工程探索以及性能优化。我大致总结一下四条线我都做了哪些事,遇到了哪些挑战,以及未来的规划。

业务开发

此段为了脱敏,删掉。

技术探索

技术一直是我关注的点,无论是在58还是在之前的公司。在入职后到现在,我在技术探索方面做了以下几件事:

  • 我逐渐理解了58集团的基础架构中间件 SCF 和 WF,阅读了 SCF 的部分源码,并和部门同事做了分享,我个人认为,理解手中工具的原理,是极其重要的,不理解,在出现问题后会是盲目的,因此未来的计划中,我仍会继续阅读基础架构组件的源码(不限于SCF,只要是日常会用到的都可以),并将阅读和理解的所得总结成文章分享出来,同时带动同事共同参与。

  • 在实践过程中,我发现了 SCF/WF 的一些痛点,想要缓解这些痛点,我认为,拥抱开源是一个解决方案,我尝试将 spring-boot 引入进来,(不会取代 SCF 的,而会想办法结合),并在具体业务中进行了实践。在这个过程中,遇到的挑战是,你替换掉了集团的标准实现,就意味着放弃了一部分集团提供的基础能力,比如监控。事情总是有代价的,有一得就有一失,很多事说到底无非都是取舍。在未来的计划中,我会尝试研究怎样继续兼容集团提供的能力,并且尝试引入开源的能力。

  • 反应式编程模型的探索。在我手头负责的业务中,我正在尝试为其引入新的编程模型 - 反应式编程模型(具体承载者为 spring-webflux)。现在我已将基本的业务逻辑架构用新的编程模型实现完成(摒弃了旧的基于模版方法的架构模式,改为灵活度更高的 service-provider 模式),并且完成了一小部分具体业务。在将来的计划中,我会逐步完善,并上线测试,最终实现用新的架构彻底取代旧的架构。

  • 在实践中我发现,现有 SCF/WF 工程中缺少 IOC 以及 AOP 这样的基本结构,因此我尝试在工程中接入了 Dagger2 和 AspectJ 这两个框架,来为工程引入 IOC 和 AOP 的能力,并在业务工程中进行了实践。

  • 在实践中逐步了解了集团的容器平台以及其他的,诸如大数据、工程效率,等等平台的玩法,并积极发现其高级玩法,如容器平台的自有日志采集,通过接入云平台自有日志采集,将日志采集逻辑从具体业务中彻底去掉,业务逻辑不需要在关心底层的逻辑,只需要关心其自身。

  • 我个人一直相信一个观点,新的总是好的(新,实际上就是旧版本修复 bugs,增加 features),因此,我尝试将我负责的业务工程的 Java 版本升级到了 8,事实证明,这一升级带来的好处是相当巨大的,Java8 中引入了革命性的函数式的编程模型,其 lambdastream 能将代码量减少大致 40% 左右(工程实践所得),更重要的是 Java8 的 stream 能够提供一种‘无中断’的编码过程,思路会像河流一样是顺序的,而不是像以前 for 循环那样停顿的(stream 本身的意思即为 ‘流’)。在将来的计划中,我会尝试与集团运维同学沟通,尝试为工程引入 Java11,以用起来更高级的特性,从而解放生产力。

工程探索

如果说架构是灵魂,那么工程就是血肉,架构是需要工程来实现的,在我的职业生涯中,工程,一直也是我关注的点。入职后,我积极的发现工程中的痛点,尝试给出解决方案。

  • SCF/WF 工程本地调试能力的引入。在入职后我做的第一件事就是尝试为 SCF/WF 工程引入断点调试的能力,我通过 maven 实现了它,并且将方法共享给了同事(同时,在研究过程中我初步了解了 SCF 的启动流程的原理,在研究工程的同时,你也会逐步的理解架构,他们是相辅相承的)。

  • spring-boot 工程在 58工程效率平台 和 58容器平台 的部署实践。由于我们想要引入 spring-boot ,所以,我们必须要让 spring-boot 能够落地于工程,我通过和同事共同研究了 58工程效率平台 和 58容器平台 的构建部署原理后,总结出了 spring-boot 工程在 58工程效率平台 和 58容器平台 落地的实践方法,并写成文章发布于集团技术大群,影响了集团其他业务线的同事(先后有3位其他业务线同事找过我,并且应用了我提供的工程实践),在将来的计划中,我会持续优化工程结构,实现工程效率最大化。

性能优化

性能优化可以说是我职业生涯中的新挑战。在性能优化方面我主要做了以下工作。

  • 业务的性能优化。由于我负责的业务的特性,性能优化是其很重要的一个点。在接手业务以来,比较重要的的优化是通过阅读 SCF 源码了解了其执行部分的抽象模型,进而和同事一起优化了业务 SCF 线程池总数。在将来的计划中,我计划继续进行优化,最终达到缩减集群实例规模,提升响应时间的目标。

  • SCF 启动速度优化。通过 火焰图 分析,我了解到,SCF 的序列化部分的逻辑占了整个 SCF 启动的大部分时间,同时结合我在公司知识共享平台上看到的外部门同事写的 SCF 启动速度调优经验文章,我在部门某工程中实践了 SCF 启动速度优化的办法,有效降低了 40% 左右的启动时间。

综述

以上就是我入职以来的工作总结以及未来的计划。在整体上,我计划未来的工作仍然会按照这四条路线开展,同时在工作之余积极参与开源社区交流,并将收获分享于团队。