【系统技术演进】2018-2023-编程知识

引子

2018-2023年，我所在的公司，架构上经历了数次转折、变化，在这个过程中，产生了很多对技术和职业的思考，仅以此来记录，在这个过程中所经历的，以及成长的过程和反思。

故事开始

1.混乱的Dubbo2.5.x时代

始于外包

公司成立之初，初版代码是由一个外包团队开发的。当时，Dubbo重新返厂，引起了不小的反响。不出意外，当时但凡是微服务项目，Dubbo有着绝对的地位。毋庸置疑，我们公司接手到的代码就是基于Dubbo2.5.x版本开发的，项目是Spring2.5-3.0，那个时候开发们都很熟悉xml配置，shiro、dubbo、spring、mybatis等等xml纷繁错杂。

病态出现

随着公司开始正式运营，外包需要离场，项目也要由我们内部全面接管。这就涉及到人员更替，代码交接，此时会体会到代码可读性的重要性。
前面说过了项目的基本情况，下面直接说一下出现的一系列问题：

Dubbo Api的出参入参都是以Map处理的，可读性维护性非常差，甚至不知道一个接口到底返回了哪些参数；
由于外包人员纷杂，Dubbo Api泛滥，毫无统一和复用可言；
代码风格也是参差不齐，开发的水平也是如此；
繁重的底层代码，交接之后很难有人说清楚哪些没用过，哪些是用过的，代码写法也都是1.8之前，许多从未使用过的大量代码，无法理解的一些代码逻辑和设计；
ORM的混乱，Hibernate和Mybatis并存，充斥在代码中；
微服务划分不合理，涉及到大量的相互引用依赖，无论是打包还是部署都起到了很大的问题；
单体应用的拆分，无法支撑SaaS场景，业务无法扩展；

2.统一的开端（微服务升级改造）

迫在眉睫的微服务改造升级

因为上面所说的大量问题，摆在我们面前，一口气无法解决到所有的问题，分清主次，摆清楚前后我们分拨分批处理到了这些问题，同样代价也是可想而知的。

微服务划分

我们花了大量时间，梳理清楚业务，以及支撑这些业务的服务，再一次做了微服务的划分，只能说相对合理，因为稍有不慎我们仍然会收到循环依赖的困扰，这点也在不久的将来再次印证我上面说的问题，后来经过我们分析，仍然是部分开发对于各个服务的定位和依赖仍然不清晰导致的，当然也存在残余不合理的地方。
在这个过程中，我们理清楚了服务的依赖关系，深度思考了他们层级！我们理清了业务关系，那些属于平台服务，哪些属于租户服务，哪些属于基础服务，哪些属于业务服务！通过这段时间的工作，我也从其他同事那里汲取了很多优秀的思想和微服务划分的理念和原则，这对我以后得技术视野和思维有了很大帮助。

orm的统一

面对两种orm框架的混合使用，改造这方面的同事，其实在处理问题上首先考虑的是改动量的影响。没错，就是字面意思，改动代码多少，经过深思熟虑之后，最终他选择独自抗下所有！那就是保证写法都是不变的，hibernate的写法底层用mybatis-plus或者mybatis实现。

多租户改造

因为是保理供应链系统，所以当我们想通过平台收费时，接入多保理商成为了理想业务，那么系统必须进行改造。于是，MyCat出现了，我们使用MyCat做了物理分库。

统一配置中心

接入了Disconf，这是个比较纯粹的配置中心管理平台。当时，nacos、Spring config还没有还没有那么普及，至少没普及到我们，或者是我们公司一直在技术选型上处于比较保守的状态。

3.初版业务中台

业务转型带来的技术突破

       刚刚进行完微服务改造，但是公司供应链业务却因为政策原因无法做了！这是公司的第一次战略转型，有半年时间，出现了外包模式，那就是出去建设金融项目，就我们的保理系统。
       项目由Spring升级为Springboot项目，dubbo版本升级为2.6.x，代码重构了dubbo的filter系列，包括用户信息透传、dubbo异常处理等。封装了新的底层架构，当然这一版很保守，代码几乎是初版底层外包拿过来的，只是做了精简，必要的改动！
       搭建了中台控制台，用来做系统级的配置，比如字典、菜单资源、应用系统维护，单号配置管理等等！接入了网关服务zuul，swagger，重构了几乎所有的基础服务！

防不胜防家贼难防

随着大业务中台（阿里系）唱衰，在我们公司内部也被说成一无是处，不懂技术的上层，听之信之，间接宣判了业务中台死刑。小组也被取消，虽然组织不存在，但是打下的技术底座，基础服务却还需要继续维护，一面说着不行，一面又需要人维护，显然有些驴唇不对马嘴！这是我觉得最尔虞我诈的时期。

改造的痛与乐

兼容还是推倒重建！！！这是我对于本次改造的最大收获，很显然不是那些技法，技术上面的，而是思想上。因为在后续的一段时间内，我仍然深深收到这个思路的影响，当我们在讨论如何处理，老代码，如何兼容旧系统的时候，出现了两个强烈的声音，温和派的平滑升级，兼容为主，激进派的推倒重建！这里不讨论谁对谁错，从长远来看，激进派更合适，兼容派确实更稳稳妥，当下各方人马也最能接受，并且工作量可控，但是长痛不如短痛，后续的改造中也近乎是需要推倒重建，所以，推倒重建确实是需要铁腕的手段和更多的加班才能搞定！但是如果我再选一次当时站队，依然是兼容思想！但是，现在我却更能体会这两种思想以及后果！

4.普惠业务时代

新业务时期

公司经过了短暂的阵痛之后，重新锚定了新方向，普惠金融业务！在这段时期，我们仍然是dubbo+zk+zuul的模式，disconf替换为Spring config，接入了分布式事务tx-lcn这个框架。开发了全新的用户鉴权体系，刨除shiro，接入了Skywalking监控，ELK日志收集。
开发了新的工作流平台服务，合同服务等等。

技术和业务的绑定

技术服务于业务，当然只能是业务主导。由于部门的调整，人员流动，中台服务也慢慢被业务侵蚀，没有人把控，业务逻辑就会慢慢侵蚀基础服务这篇领土，那就成为普惠这一个业务系统的定制化开发的代码！

技术的沉默，业务期平稳进行

平稳的业务期，整个服务就融合为一家，至此，虽然业务服务是业务服务，中台服务是中台服务，但是就是不那么纯粹。也没有太多技术上的变化，只是业务代码的堆砌。

5.Spring Cloud粉墨登场

公司再次转型带来的技术机遇

因为公司一直以来的技术栈，都是以dubbo为主，但是又因为历史原因，dubbo停留在2.6.x版本，受到很大局限，直接略过低版本上2.7.x，倒也可以。不过，很多组件的便利性，考虑到这点，成熟的SpringCloud全家桶成为我们不得不考虑的因素，既然是另起炉灶，尝鲜已经成为难以抵挡的诱惑！也有其他考虑，比如我们可能曾经想过，dubbo和feign并用，feign兼容新业务，dubbo兼容老业务等等！下面可以看看我们的选型和技术架构图。

技术选型

系统架构图

服务架构图

业务架构图
在用Spring Cloud框架开发微服务的时候，确实有了不同的体验。当然也解决了很多新的技术问题，比如feign的异常处理，再比如本地测试负载的问题，还有其他零零散散的技术问题，在这个过程中，又一次深刻体会了，自己选的路，哭着也要走完，哈哈哈哈…

业务牵制下的技术困境

业务公司始终是业务，赚钱永远是第一位的，这点亘古不变！！！当无法换来营收的时候，技术迭代升级是可以抛之脑后的。尤其是，当技术稍微平稳，锐意进取会显得和公司业务步调格格不入。不得以，技术会被业务取代，业务需要取得的成绩和已经取得的成绩，掩盖技术带来的便利，那些维护基础服务的里子，只能成为面子的影子！
作为一个深爱技术的人，甚至会怀疑技术这条路子，到底值不值得坚持？！这个时候那句古话正应景：君子藏器于身待时而动！这个时候，就是需要深耕技术，沉淀自己的时候，因为等待下一次机会来临的时候抓住它！

6.分久必合，合久必分

百花齐放百家争鸣

历史总是惊人的相似，统一大业刚要有所成效，但是计划总是不如变化来得快！种种原因，公司开启了很多产品线，想通过这些产品线打开市场，梦回2019！
原本稍有统一的技术栈，又分散开，被各产品线拿走技术底层，在此基础上又基于自己的业务需求进行扩展封装，所谓百花齐放，百家争鸣。分久必合，合久必分已经是不争的事实。期待下一次合流！