现在大家都陆续开工了。因为疫情，多数人最近一段时间只能在家办公。这段时间，除了做好个人防护，大家可以利用在家办公的优势，阅读充电，总结过去，规划未来。
在这新年开工之际，我也简单总结一下年前的工作，介绍一下新一年的文章和工作计划。
年前工作
春节大促
年前文章断更了很久，最大原因是工作繁忙。逢年过节，业务线总少不了搞一些大促。对技术来说，大促就是一块试金石。服务治理、系统伸缩性和弹性、全链路压测等等，这些方面的技术能力如何，都能被大促试出来。通过一系列春节活动，我们确实发现了很多技术短板。技术团队上上下下也提高了对系统伸缩性、全链路压测自动化等方面的重视程度。而从技术管理的角度来说，大促可让业务与技术相结合，从而更高效地推进技术优化工作的落地。
中间件研发
除了准备大促，年前我还在推动中间件研发工作。其实我所在的团队是负责业务系统研发，并不负责中间件研发，那为何还要推动中间件研发？
其实像服务治理、消息中间件、全链路监控等技术能力，并非将 Dubbo、RocketMQ、Skywalking 等开源技术引入即可。简单采用这些开源技术只算技术集成，离真正的服务治理、云原生还有相当距离。优秀的开源技术提供了成熟稳定的基础功能、强大灵活的扩展机制，以及积极活跃的技术社区。但是对于大中型分布式系统，并没有多少开源技术能提供开箱即用的能力。开源技术是一个基础，在这个基础之上，通过扩展和定制，使其适配于特定环境，满足特定需求。
而这些扩展和定制，不单是中间件或基础平台团队的工作，也需要业务团队的参与。业务团队成员需要熟练掌握这些开源技术的使用，甚至精通其原理，并发挥贴近实际技术需求的优势，发现现有技术存在的不足，与基础平台团队一起，推进开源技术扩展和改进工作的落地，并将成果反馈给开源社区。这样，可以形成了一个由开源社区、公司内基础平台团队、业务团队共同参与的良性循环。
中台
中台是我们目前业务团队努力的方向。中台背后的思想是复用，包括业务和技术的复用。中台将复用的思想提升到了超越单纯技术，达到组织人员复用的水平，因此真正的中台往往涉及组织架构的调整。我们目前的工作，尚不涉及组织架构的改变。所以，从这个角度讲，我们做的不算是真正的中台。但在现有的组织架构（系统架构）下，我们其实也有非常多的工作要做：仅就目前已明确规划的工作而言，我们需要将涉及核心业务的近十大类场景的 功能实现改造成由一个接口、一套流程支持，工作量和挑战不可谓不大。如果能够实现这个目标，我相信从技术的角度讲可以说我们为真正的中台已经积累了足够经验，做好了准备。
新年计划
文章计划
今年写文章的计划将分为两部分：一个是以反应式编程、协程、Kotlin 等技术为主的技术线；另一个是以介绍工作相关内容为主的实战线，这部分将会结合我所负责的具体工作，介绍业务架构、分布式系统设计、中间件研发等方面的内容。
反应式编程目前还是曲高和寡的状态，虽然 Spring 5 发布已经有两年多了，但至少我负责的系统还没有真正用上。因此，我一方面继续写更多的关于反应式编程的文章，另一方面会推进相关技术在业务系统上的落地。
在实际落地时，反应式编程还是有非常高的技术门槛，Kotlin 协程技术能够帮助降低反应式编程技术门槛。同时，R2DBC、RSocket 技术也在丰富完善反应式编程技术生态。另一方面，Project Loom 虽然还是不知何时能正式发布，但至少这个方向已是非常明确，这也增加了 Java 社区的信心。虽然 Project Loom 和反应式编程所解决的问题有一些重叠，但两者并不冲突。协程和反应式编程能相互补充，共同帮助系统伸缩性等方面的提升改进。
而在实战线方面，年前曾计划发表一篇介绍我所负责系统架构的文章，但因涉及较多细节，最终未能发表。这是很多关于业务系统架构的文章通病：粗写显得没有干货，细写又很有可能不能公开发表。今后为避免文章因此类原因导致无法发表，会将实践经验进行提炼，去除具体工作细节，总结归纳思想和理论，最终形成文章。
这里立一个 Flag，目标是今年能发表至少12篇文章，平均一个月一篇（去年只有7篇）。
工作计划
在工作方面，抛开具体的业务工作不谈。在中间件研发方面将继续从业务需求角度入手，推进相关特性的研发落地，并希望能将成果回馈社区。同时，解决年底大促发现的诸多技术瓶颈和提升业务系统通用性也是新年工作的重点。希望能和技术文章介绍的内容结合起来，使对新技术的介绍能包含更多实践内容。
网友评论