框架升级、服务拆分总结

文章目录

方案思考
- - - 第一次
    - 第二次
    - 第三次
尘埃落定
风波不断
痛定思痛
总结

到了新公司之后，没有休息多长时间，就准备开始干活了，当时我接到这么一个活：即现有项目太过冗余，需要对其进行服务拆分，并且升级现有框架。接到需求之后，大体看了下现有的项目结构：项目比较古老，技术使用的是JSP、SpringMVC、Tomcat那一套，评估了影响范围，萌生出一个大胆的想法。。。

方案思考

第一次

在和客户进行一番交谈后，客户最初的想法很简单，嫌弃现有项目启动速度太慢，想提高启动速度。并且希望此次改动影响能降到最小，不进行大规模的改动

鉴于客户这种需求，我当时第一反应就是不动现有代码，或者少动。这样大致方向就可以确定了，接下来要做的就是：如何在不改代码或者少改代码的前提下，提高项目的启动速度。项目启动慢的原因，要么是类真的很多，加载需要时间。要么就是启动时候加载一堆资源。而这次情况，启动时候只有初始化了数据库、Redis连接，并没有加载太多资源，那么显然是因为项目类太多了导致的启动慢，这就得从底层开始入手了，主要思考方向有三部分：

JVM：是否可以加快 JVM 的加载类的速度，自定义类加载器，多线程扫描之类的
Tomcat：Tomcat 在启动之后，只加载 过滤器 和 Servlet。项目上并没有多少个 过滤器。Servlet就更不用说了。还有可能就是JSP部分，但是 Tomcat 启动时，并不会主动去编译JSP，优化这部分内容，只能优化第一次访问页面的速度，对于启动毫无帮助，Tomcat 不分的优化排除
Spring：Tomcat 启动后，基本把控制权给了 Spring，Spring 去扫描对应的Bean，进行初始化，这部分应该是导致其启动慢的重要原因，为此，可以尝试在编译时候，给相关Bean加上索引，例如：@Index。还有就是加快 Spring 扫描Bean的速度，例如说：多线程扫描。再有就是非核心部分使用懒加载，如@Lazy

大致梳理完处理方式之后，我提出了上述的解决方案，结果遇冷。原因很简单：客户希望不单单是加快启动速度，还有嫌弃现有项目太冗余，希望进行 服务拆分

第二次

好嘛，想进行 服务拆分，那么就不得不动代码了，问题是怎么动才能影响最小。客户的想法是：根据菜单进行拆分，然后不改动业务代码，来实现拆分

听到这个，当时的我心里头只有一个念头：太理想了，典型的既要还要。且不说菜单不一定是按照功能进行划分的，就算是，前面的开发者也注重业务功能的划分。就算是，那么涉及到公共依赖怎么办？A服务有了，B服务还得再复制一份，这就造成了代码冗余了。按理说应该是按功能划分，这样子也能发挥微服务的真正威力

不过客户既然确定，那就这么干吧，只是还有个问题：关于JSP部分，怎么处理，要知道JSP中可是涉及到大量服务调用了。鉴于客户不想承担风险。为此，只能考虑代码改动小的方式，设想加一个 路由器 或者 拦截器，来实现转发的效果，这样原有JSP不做如何改动，把问题和风险控制在 路由器 或者 拦截器 上

第三次

最后一部分就是关于框架升级了，框架升级必然带动着一堆语法上的变更，基于客户不想承担过大的风险，那么方案基本也可以定为 AOP 或者 适配器，通过中间层，来实现升级，这样既不用改变原有代码，也能达到升级的目的，渐进式改动

在这里插入图片描述

尘埃落定

经过一番思考、整理后，我把方案在会上提了出来，因为是站会模式，想必采用的是敏捷项目管理，允许创新和试错。为此，我信心满满的提出了自己的方案。当时的情况是：

我：能否采用 路由器、拦截器 的方式来替换JSP全量改造

项目经理：我还是觉得全量替换改动小

我：路由器、拦截器 可以把风险控制在中间层，全量替换根本不知道改了什么，不知道改了什么，意味着风险完全不可控，只能依赖于测试。不是全局改动就是改动大，局部改动就是改动小

项目经理：这样会让架构变得更复杂。。。

我：增加一个 路由器、拦截器 能把架构变复杂到哪里去？而且可以通过它记录具体转发的请求，等到客户真正想进行重构的时候，一改一个准

项目经理：。。。那框架升级呢？比如说Hibernate升级，将原有SQL语法改成HQL

我：这可以通过 适配器 或者 AOP 进行，只要增加两三个类，就能实现升级了，且完全不用动现有逻辑

项目经理：。。我怕这样改不全

会上巴拉巴拉了一堆，最终我的方案全被否决了，只能采用全量替换的方式来进行此次 框架升级 和 服务拆分

在这里插入图片描述

风波不断

在接受了全量替换之后，只能把技术活干成了体力活，这种活说来简单，实际上在考验心细程度了。动不动就漏掉这个那个。而且改的过程根本不清楚改动了那些东西，影响是什么？

不出所料，改动完的项目要么点点就出现了404，要么就是SQL没改全。思来想去，我不能坐以待毙，既然控不住风险和改动。那就只能通过加强测试来规避了。为此，我向项目经理要求自动化测试，这样可以大幅度降低风险。自动化脚本可以我来写，但是，东西得给我

只是没想到，这个要求还是被拒绝，没有办法，我只能通过提前告知风险，希望他们能引起足够的重视。没想到，他们还是置若罔闻。看到他们这种态度，我就明白了：风险要拖到提测阶段才能暴露出来

在这里插入图片描述

痛定思痛

截止到现在，来来回回改了好几次，也确实容易漏东西。一出问题，客户就在哪里巴拉巴拉一堆。。。

看到这种情况，我心里确实也痛苦，我们最终的目的都是为了项目能顺利完成，为什么认知上却存在这么大的差异？在我看来简单的方案，在项目经理视若毒蝎。在项目经理看来简单的方案，在我看来却是风险完全不可控。是项目管理的角度和技术的角度出现偏差还是其他？或是我给出的理由不够充分？还是方案确实存在问题？如果方案确实存在问题，为什么会上不诘问我呢？

在经历过2、3个月的痛苦时光后，我扪心自问：如果在遇到类似情况，我会怎么处理？如果还是采取同样的方案，我会怎么做？

想来也简单，在项目经理或者是客户坚持采用全量替换的方案时，这时候就不要做无谓的辩驳了，一次两次就能知道他们的心思了，最后的解决方式或许是利用现有工具分析下依赖关系、调用链路。这样就可以提前知道改了什么，影响的范围。不过话说回来，如此刻板的团队，能给我这些工具做前期的准备吗？

在这里插入图片描述