谨以此文献给想要或者正在进行项目技术迁移或升级的小伙伴，本文不涉及具体的技术细节，大家了解下思路，工具还是用自己最熟悉的就好，都说架构没有银弹，要我说咱架构师就是银弹（我还不是架构师 T。T）。
首先给出总结，因为思想很重要，有了想法，才有行动。
总结下思路：
剪头去尾留中间，剪掉不要的，留下最重要的业务代码，底层框架都是为业务代码服务的，换个服务员，可以拥有不同的服务体验。英文比较洋气点，Same business logic, different framework.
总结下迁移的方法：
1. 要有大砍刀，不砍掉那些肥肉，就跑不起来，走都困难
2. 能代码自动解决的，坚决不手动，毕竟代码可以重复执行，人力还是留给别的事情吧，例如游个泳啥的
3. 测试不能少，自下而上的不断添加测试，迁移基础模块，越往上就越舒服，越快，从上往下的会被大的目标给累死，心累。测试还可以帮助你理解代码，读源码会睡着，但是测试和异常会帮助你前进。
4. 版本管理工具，大胆实现自己的想法，弄坏了还可以恢复
5. 恒心，要相信自己
PS：我是业余时间干的，因为没人认为我能成功，所以不能再工作时间干。可是现在，这个迁移项目已经可以开始支撑我们的服务了。
故事发生在：
2015年本人突发奇想，在这个spring大行其道的时代，mysql横行的时代，为什么我们还要坚持EJB2和weblogic8。我的时间怎么能够一直定格在20年前，那个EJB, JDK4的年代。我要改变。
首先第一个想法就是，想升级到JDK8（我大JDK8还可以再用个20年）。但是weblogic8是和JDK4绑定的，而且还收费挺贵的，关键是升级了对我的职业发展也没啥好处啊。Tomcat完全可以胜任这个基于Servlet封装的网站。于是我心一横，掏出我四十米长的大刀，把EJB和weblogic相关的代码给砍掉了。最终我当然是跑起来了。但是我也失去了EJB，weblogic自带集群，远程调用RMI等分布式特性。但是我坚信，集群不止这一个方式，负载均衡完全扛起大旗。所以我坚定的完成了第一部分的切割。
下面就来说说切割EJB的方式。
EJB经典之一就是大量的RMI代码，首先就是删掉远程调用的代码，直接保留本地的就行，EJB相关配置都删除，当然，这个删除的过程必须自动的，人力解决会手断眼瞎，利用DOS的del命令，就可以轻松解决这个问题。例子：del /s /q /f N:\es\scd\*.class。不过多模块的项目，最好写上bat脚本来执行。后来我还是改用java来做文件的复制和删除了，因为写不熟悉的bat基本真的拖慢了进度，刚开始都是比较猴急，想看成果的，而且还可以对java io的接口做个复习。
删掉这些代码之后，你会发现，项目瘦成了一道闪电，编译速度贼快，你想原来一个类要写个几份，配置再来几份，得有多累，得有多臃肿。犹如200斤的胖纸瘦成了100斤。这个阶段保证编译通过就行了。想要让代码跑起来，还有很多工作要做。
下面我们就让它跑起来。
项目是基于Servlet封装的，理论上是可以直接丢在Tomcat里的，但是我们这个项目很特殊，所有东西都是前人手动撸出来的，编译工具也是Perl写了一套CLI，Ant负责编译打包。对于现代的我们，真是太不方便了，阻碍了生产力，所以现在要引入maven，前期倒是纠结了下是不是要直接上Gradle，但是还是maven熟悉，我是真的心急，所以还是用自己最擅长的maven，时间不等人，我们现在的首要任务是简化项目，让它起飞。引入maven之后不仅编译打包方便了，这种多模块的项目在maven里就是个标准的多module项目，轻松。成功的集成了maven后，切掉了perl，ant等一系列的CLI代码，换上了新的装备。
现在我们编译，打包都跟玩儿似的，还顺便解决了jar包升级问题，自动下载管理jar包版本。现在我们已经是一个JDK8的项目了。JDK8目标达成。
当我看到第一个login页面的时候，我激动的失眠。
现在项目能跑起来了，但是基本无法使用，因为和数据库对接的EJB Entity的代码都给俺们删掉了。一番学习后，发现JPA就是它的简化版，果断引进来。这里要感谢20年前的大神们，写的自动代码生成工具，这里不是吹，mybatis generator放我们新项目里是好用，但是放在已经写好的旧项目里，就不是银弹了。这里简单说说思路，就是利用XML，XML天生可以无限扩展元素和属性，对于定义一个class的属性，对应数据库的字段，类型，属性啥的，都不是事儿，有了这些定好的规则，直接写java代码生成代码文件就是了。
下面就是不停的启动，修改代码了，对着页面一个一个的测试功能，改bug。
OH NO，这不是我想要的，太痛苦了，必须自动，是时候把集成测试丰富起来了。
这里我们其实已经可以说是进入fix bug阶段了。版本工具怎么能少，Git，有了这个神器，不管我们怎么虐待代码，都可以恢复，重来。这里要做一件简单而又重要的事情，添加单元测试和集成测试代码，从底层模块开始，职责越单一的模块儿越好改。从下而上的不断添加测试和调试。越往上修改，越快，因为基础设施搞得好。所以咱大中华发展快是有原因的，这基建真不是吹的。
好了，断断续续的，已经坚持了八个月，一波波的体力劳动后，我决定休息会儿（放弃了）。
2016年到了，参加了不少前后分离的项目，从这些项目里可以看出，后台渲染的时代已经结束，velocity，freemark什么的都可以退出历史舞台了，所以我又掏出四十米长的大砍刀，把前台代码和velocity相关的代码全给删掉了。删完之后真的是跑的飞快。启动都是30秒以内了，想想过去那个切分支，起个服务要半小时的日子，真的是泪流满面。
这一年，我接触了springboot，也是这一年，我不在以全栈为目标，开始专心学习后台，前台Ant design已经解决我需要的一切UI，就这么愉快的决定了，后台也是果断改成了Restful。
这时候，已经没有任何人可以阻止我换上新的UI，定义好接口规范以后，似乎后续工作又开始变的简单而又枯燥。
这时候，只有我自己可以超越自己了。作为一个有追求的青年，我怎么能够忍受拼接字符串的JDBC代码，前期删掉EJB的时候，已经用JPA替换了EJBEntity。现在是继续使用JPA写JDBC的复杂代码呢？还是用MyBatis呢，答案肯定是MyBatis了，再让我在JPA @Query里拼接字符串，我就和梁非凡一起吃饭。
好了，费了这么久的功夫，我们终于赶上了时代发展，spring boot + jpa + myabtis。是的就是这么简单又枯燥。
作为一个有追求的青年，我们怎么能错过微服务，于是又继续引入spring cloud。
不过跟完风后发现，最新的技术不一定就是最合适的，项目本身的数据量不过是单表亿级的数据，和那些动不动就是PB级别的公司，单体项目配合负载均衡，分布式共享缓存，再配个消息队列，已经稳稳当当了。不过用于对未来的投资也是不错的，万一哪天数据暴涨，服务暴增，我们还是要拆成服务的，至于微不微服务已经没那么重要了。
总结返回顶部看吧！！！
如果想知道一些实现细节，可以留言，我另写一篇补上。
