也是上文中的项目，在前面也有介绍，这个项目是一个C/S项目，客户端是C#+Devexpress，因为涉及到某公司的核心框架，所以框架部分的代码是没有给我们，只是给了业务部分的源码，服务端也是，基于其公司核心框架开发，所以能拿到是也只有业务代码。
现有项目分析
想要做二次开发，当然得对其框架的思想有所了解才行，不然会无从下手，所以，这里我们先来大概探究一下。
客户端核心库的探索
经过我分析，在C#端是插件动态加载机制，这里涉及到两个核心的exe程序，第一个exe程序是启动程序，在启动时会对服务端的DLL和本地的DLL进行比对，它本地的DLL版本信息存储在一个SQLite本地库中，每次启动时就会去读取来对比，如果本地不是最新的，则通过HTTP启动去下载最新DLL文件，并更新本地版本信息。版本检测更新完毕后，回去启动另外一个exe程序。
这个exe程序是登录界面，他在启动的时候会去初始化本地配置，它的初始化过程是，先在本地SQLite库中读取HTTP要访问的地址、端口、路径等，初始化完成后，便进程登录操作，它的登录流程是模拟发起HTTP请求->登录成功后获取服务端的SessionId。这时候会把SessionId保存在本地，在每次发起HTTP请求的时候，都带上这个SessionId,这样一来就会使得当前登录用户有状态。
其他的就是一个自定义的C#控件，也是基于Devexpress封装的，主要是为了方便使用控件，比如增加一些自动绑定事件，为给控件绑定数据显得更加方便，直接一句SQL语句便可将数据绑定在控件上，这一块就不多说了。另外一个比较核心的就是Mes.Core.dll，它里面维护了全局配置类，Http请求类等，在我们要调用服务端数据时，直接一行代码即可解决。这里它调用方式有两种：
- 客户端发送SQL去服务端统一接口调用。
- 客户端先通过命令名获取服务端接口路径，再向接口路径发送请求获取数据。
服务端分析
服务端目前是用的Spring MVC来提供HTTP接口，其核心部分就是封装了一些统一的操作，比如mybatis增强操作、特有的用户认证、定时任务等。在我通过Maven安装包时，着实花费了不少功夫，包真的太多了，非常臃肿。其实服务端现有功能也是非常简单，就是一些增删改查的功能，但是jar包有数百个，足足下载了近300M。虽然代码可以反编译，但是真正要弄清楚的话，还是需要花费时间，公司显然不会把精力花费在这个上面。
项目风险评估
到目前为止，两个接手这个项目的同事都未能了解其中的原理，和项目中的功能代码以及业务流程，现在新二次开发大概有80%需要新做，而且时间也比较紧。所以，我们最终决定是，客户端沿用原来的方式，服务端另外新建一个Spring Boot项目来开发新业务。由于涉及到客户端针对们的服务端框架封装了一些特有的东西，为了降低风险。我们想到，将现有的Srping MVC作为服务消费者，所以请求任然直接向原项目处理，原项目将新功能请求再转发到新服务中，这样一来，认证这块和客户端都可以沿用原来的方式，大大降低了项目风险。但是呢，同事的请求转发采用原来的HTTP请求方式，这里我们觉得基于Nacos作为服务注册，新服务为上游服务，原Spring MVC作为下游给客户端提供服务。
基于Nacos的服务注册与发现
这里我打算使用Nacos+Dubbo来处理我们的接口注册与发现，相关信息可以先看看Spring Boot整合Dubbo和Nacos,这里也不再详述，我们直接开撸吧。服务的提供者这里就不重新做了，直接沿用上文的代码，就新建一个Spring MVC来消费即可。
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>[latest version]</version>
</dependency>
<!-- 使用Spring装配方式时可选: -->
<dependency>
<groupId>com.alibaba.spring</groupId>
<artifactId>spring-context-support</artifactId>
<version>[latest version]</version>
</dependency>``` –>
