这是学习笔记的第 1878 篇文章

今天认真思考了下2018年的一些工作情况,客观的讲,需要做的事情很多,想做的事情更多,最后的完成度算是打了个折扣。从我的繁忙程度来说,是接近150%的节奏,整体来说,还是之前的技术债太多,而后期要去补充和改进,这个代价和周期会被放大。

我举几个例子来阐述一下在这个过程中的我的实践总结,然后再给出我的结论。

今年的一个工作重点是把核心系统迁移到MySQL上面,根据已有的计划和测试情况,这个进度被延后了,这是意料之中也是值得反思的一件事情。

关于核心系统迁移到MySQL的理解和认知偏差,其实从我来到公司的时候,有些主观的认为,这样一个事情,是大家都重视的,既然要做,就不需要我给出理由了,但是实际上哪怕是名正言顺,事情要能够持续性的推动下去,这些都是逃不掉的阶段,甚至要做的前置工作会更多,需要的一种责任感和掌控能力,打个比方,你是这件事情的负责人,但是如果你也没法决定这个事情能不能按照这个方案来走,按照既定的时间计划来完成,从质量和进度上都是需要打上问号的。前期的接入过程,我们更多的是在对接功能,做功能的平移,然后开始讨论架构的扩展和分布式改造,这个过程的迭代是相当痛苦的,我们反反复复讨论了多次,大家在一种保守的态度中希望能够保持已有的实现方式同时又能够支持分布式,当然最终就是在不断的平衡之中走过来,直到一个分布式的改造过程,必须要这样改动的时候,突然发现原本的困境一下子明朗起来,而同时让应用的同学也感受到了方便。这个时候架构阶段的事情总算有了着落,然后就是性能的落实,性能的事情上是最不能马虎的,有一种牵一发而动全身的感觉,在改造不够彻底的情况下,能够实现强大的扩展能力,性能在这个事情上是不会妥协的。所以我们自然会再次遇到瓶颈,这个阶段被我称为改革的深水区,也就是不得不改的阶段,而到了这个阶段,其实我的内心也是焦灼的,因为一旦到了这个阶段会存在一些模糊的结果状态,一旦模糊不可控,时间和周期就难以保证了。

总体回顾下来,如果让我再来一次,我觉得这些前置的工作还是会重新走一遭,只是周期会缩短,对团队来说,这就是一个难得的经验磨炼的过程,后续的改造就可以直接从功能阶段跳步到架构阶段,改造的周期和难度也会小很多。

有时候就在想,从过来人的角度来看,这个过程中我们是不是也走了一些弯路呢。

第一,对于应用方来说,成果难以体现,我们做这个事情的时候,其实我们的共同目标是有的,但是还是不够清晰。如果目标是从一个商业数据库迁移到MySQL,那么我们的目标应该是更加高效,支持水平扩展,而不是功能支持的程度。在这一点上,我们觉得我们走的一些弯路就在于此,最后大量的性能测试都是在说明同一个问题,现有的架构情况下是无法支撑扩展的,那么这样的一个结果对我们都是一种很难以接受的状态。

第二,对于系统的性能边界存在理论和实践的偏差。我们在早期的改造中存在的一个疑问就是流量带宽会因为和数据库的交互次数增加而有较大的的改变,基于这样一个未经测试论证的理念,很多的测试和架构改造都做了取舍,直到我们在后期才开始做了全面的测试,而充分的测试论证了,不会有大的变化,增长的比例几乎可以忽略,这样一来原来的顾虑就打消了。

第三,在做与不做中纠结的其实是我们的目标是否明确

我们的很多事情都是介于做和不做不做之间,就是在这样的一个模糊状态下,我们的结果也是模糊的。

总之,我们可以找出很多的依据和参考,但是这些过程都是难得的实践经验,也是我们走向成功的一个必经之路。