系统一，鄞州银行、建行远程银行系统

---

• 毕业后接触的第一个系统，简单的单机版，技术框架SSH（spring+springmvc+hibernate）；
• 版本管理工具SVN
• 构建了一个单机系统，应用部署在单台服务器，连单个数据库。应用和数据库有备用机，需手动切
• 当时不知道使用maven依赖，classpath依赖的jar包，在百度上一个个下载放本地，最头疼的是版本号冲突、依赖的jar包不存在，开发新功能引入依赖包不得不花几天时间解决这个问题。

系统二，***账户系统

---

技术框架、部署架构、数据库，一直在变化，系统重构、数据迁移也是家常便饭。总体来说整个系统在朝着更好的方向演进。

• 版本管理工具git，git与svn放一起比较，git真香。

基础版本版本

• N分片 + 中控 部署，技术框架：web应用ssm(spring+sring MVC+mybatis)，批处理程序 springbatch+mybatis。配置和应用分离，修改配置文件，可不发布版本。
• web应用和数据库采用分片部署，因资源紧缺，web、DB、批处理程序部署在同个虚拟机，组成一个分片，总共N个分片，按某个规则，将用户数据分发到不同的分片。分片上的批处理程序跑批，生成文件。
• 分片生成的文件，通过sftp传到中控，中控将N个分片的文件进行合并，再将文件送下游系统。

第二个版本

• 考虑到业务量暂未达到预期，将系统收缩。
• 分布式应用部署，技术框架：web应用ssm(spring+sring MVC+mybatis)，批处理程序springbatch+mybatis，
• 采用分布式应用部署，但数据库是单节点，此时不再使用中控服务器。批处理采用主备部署，跑批产生的单个文件，包含了所有数据，直接送下游。

第三个版本

• 主打技术云架构升级，拥抱容器云做准备，技术框架：springboot+mybatis，配置文件通过spring cloud config配置中心获取。配置和应用完全解耦。
  抛弃了xml配置文件模式，采用注解将新增类注入到spring容器，部署架构仍采用第二个版本架构，但技术升级后，应用可部署到容器云。

第四个版本

• 技术框架不变，容器云部署。
• 考虑到业务量将会变大，同时受中兴华为事件影响，数据库国产化趋势已显现，即将使用某公司得***分布式数据库，此库理论上可无限扩充节点。