春哥的技术成长复盘

春哥的技术成长复盘

之前写过一篇”春哥的软素质复盘“（参见：春哥的软素质复盘），主要讲的是一些通用能力成长的阶段性总结，今天则围绕于技术成长的阶段性总结，做一个阶段性的复盘。

故事从2016年说起，为什么是2016年呢？

因为2016年之前在技术层面不够聚焦，做过前端全栈，深入研究过SPA、MEAN、Angula、React，还写过iOS，做过APP。

一部分原因是兴趣广泛，不学点东西感觉不踏实，而且那段时间公司也不忙，所以有大把的时间去学习，北京的四个图书大厦基本是每周都会去一次，一呆就是一下午。

还有一部分原因是，当时的后端技术远没有今天复杂，虽然移动互联网12年就已经相当火了，比如滴滴、美团、头条都是那个时间创立的，但16年还远没有现在的规模。所以业界的后端架构顶多就是前后端分离的架构，对应的后端技术复杂度也没有什么本质的变化，后端同学除了写crud，顶多就是接触一些nginx、redis、mysql分库分表，还没有那么多卷的概念和卷的机会，时间就很充分。以至于每周五都会和同学跑到北京西站，随便买一张火车票出去玩两天，周一早上回来上班（扯远了）...

2016年的变化是什么呢？

微服务火了。

其实微服务大概在社区是2015年火的，但是真正让大家有机会去落地使用，还是因为SpringCloud、SpringBoot的推出，大大降低了大家落地微服务的成本，以至于很多人把SpringCloud等同于微服务。这也是很多初学者遇到的问题，把一个技术与一个概念等同起来，比如很多人以为SPI只有java有。

SpringCloud出来之后，觉得终于有点新东西可以学了，在社区逛了一段时间后，读了一些SpringCloud源码和文档之后，觉得有必要去实践与使用下，所以做了单体到微服务的拆分，之前写过一篇文章，这里就不赘述了（参见：我的微服务之路）。

在做微服务拆分过程中也接触了新的概念，比如大量的中间件生态，以前做的产品虽然也有千万DAU，但链路比较短，对于分布式系统之间的扩展性、性能、可用性、稳定性没有那么高，接触的中间件体系主要是Nginx、Redis、MySql、RabbitMQ。

当做了服务化拆分之后，势必引入了一堆微服务组件，服务注册与发现、配置中心、事件队列、RPC等，所以那段时间又把时间投入到了大量分布式中间件的学习与实践当中去了，通过看源码和文档的方式了解了Redis、ZK、Kafka、ES、Dubbo、Thrift、MySql、Hbase，基本上把常用的五大类中间件了解了。

而且为了积累更多的最佳实践，基本上把亚马逊上五星以上的计算机方面的书都买了看了，每周买1~2本，以至于和亚马逊快递的小哥混熟了，他说”你买书这么频繁看得完吗“，他说”亚马逊可以一周免理由退货，你先看一周，看完了退后就行“。后来很多书看了一周感觉不会再翻第二遍的，基本都退了，而有些书感觉以后还会看，所以就都留下了，以至于屋里堆满了300多本技术书。

这一段时间应该是技术成长最快的第一个阶段，那时晚上7点下班，8点吃完饭，可以一股脑看书到凌晨，感觉很充足，实践热情很充足。

后来就疯狂的在工作场景中找机会做中间件，比如我们有个日志分析系统，通过采集多台业务服务器上的日志，进行聚合统计，呈现出报表。以前的方案是多台机器抢分布式锁，其中一台机器把多台日志拿过来，做处理，然后汇总好上报，呈现报表，性能很差，一次统计需要30分钟。

考虑引入FileBeat+Flink成本太高，大炮打蚊子，后来我用业余时间参考MapReduce的思想，分布式加多线程又做了一些算法优化。相当于做了个日志持久化方案+MQ+多线程并行处理，提高了稳定性、准确性、可用性。基本可以在30s产出一批次数据，性能有了非常大的提升，成就感还是非常高的。

后来这套架构不只做业务日志分析，还做了扩展，变成了一个trace系统，做链路追踪与可视化。当时对于性能及吞吐提升有很大的热情，所以把能摸得着的系统的系统瓶颈点基本都优化了一波。

还有当时对于DevOps很有兴趣，当时DevOps概念应该刚起来，就去了解。业界还没几家玩的特别好，而且我们那时候基本是自己写Shell脚本，做jar包上传、复制、解析、部署、启停Tomcat，稳定性很差，也不可靠，当时Docker社区比较火了，但容器编排还不成熟，Swarm、Mesos、K8s三分天下。

我们采用的是Mesos+Marathon方案，主要是因为Mesos在Spark体系下比较成熟，资源隔离业界比较火，现在看起来是站错队了。所以又搞了一段时间私有镜像云+DevOps工具链研发吧。

以上应该是技术成长的第二个阶段，对于一个复杂后端架构所涉及到的技术有了一个粗的认识，并且有过相关实践。

当时做的系统虽然也是千万DAU，但由于链路较短，很多场景可用性要求不高，也就是说挂了对用户核心流程使用也没用影响，比如我们只要求两个9，500ms延迟，所以缺少一些分布式事务、数据一致性、可靠性的极致要求。所以就考虑看看有没有千万订单场景，且链路较长、复杂度较高的机会。

后来有机会做核心交易链路的一些系统，接触到了真正的高并发、大流量、高可用的一些挑战。最先做的是广告营销投放链路系统的优化，也是初生牛犊不怕虎，其实那里一旦出现问题就可能是P0故障，拍屁股走人。但还算顺利，从原有的可用性两个9、延迟150ms，优化到了4个9、延迟120，后续广告策略升级延迟升高、曝光量提升了，超出了业务收益。

后续一段时间感觉是技术能力的第二波成长，就是将以前读书懂得知识有机会落地实践了一波，方法论更全面、印象也更深了。后续接触了异地多活、单元化架构，从高可用、高性能、高并发、低延迟、异地多活、线上引流、自动化压测都接触了一波，算是把核心交易链路的技术能力闭环了。

之后又做过一些研发效能提升的事情，涉及移动端、API端、服务端，算是对超级APP端到端的性能优化、协作效能提升解决方案有了一定的认识。

接下来业界就开始唱高中台了，部门内部开始调研中台化解决方案，如何更快的让业务研发接入，如何可以沉淀业务能力，如何做好隔离与扩展，如何提升稳定性，如何做好数字化能力的复用，涉及到流程、标签、字典等一系列的技术方法论，领域驱动再次被拾起来了。

以上应该是技术成长的第三个阶段，真正在高并发、大流量体系下去矫正自己对于分布式、微服务的认识，也因为环境的极高要求，追求技术实现上的极致。

其实会发现从研发效能提升之后，中台化框架、稳定性等事情和具体技术深度没多大关系了，比如涉及不到MQ积压与扩容处理、涉及不到Servlet升级WebFlux、涉及不到Reactor+Nio线程模型，后续的工作内容更多围绕与广度，或者是技术能力的可复制，就是如何从一个有最佳技术实践的系统复制到其他系统，如何从一个最佳实践的团队复制到多个团队。

简单来说就是从带领一个系统成功，变成了到带领一批系统成功。这个阶段心态上是需要调整的，比如并不是每个系统都可以像一个系统做到那么完美，并不是每个同学都可以做的想你心中想要的那个效果，所以有的时候会适当降低要求，保持达到超过及格线一段水平即可。

成长提升更多是围绕于目标设定、组织协调、沟通、协作、项目的管理、进度与风险的把控上面，技术深度上相信是有降低的，毕竟关注不到那么多细节了，技术宽度可能也有所降低，毕竟注意力被分散了，但技术广度应该有一定提升，也就是更关注业务价值而不是技术本身了。

目前在我看来是技术成长的第四个阶段，就是依托于技术去实现业务价值，产生收益，技术不是全部，而是更在于如何的有效利用技术。

这就是这些年春哥的技术成长复盘，希望对你有用。