背景： 对于存在有问题的项目（包括 代码不规范 数据库表命名不规范 ）需要改造
系统业务架构：
步骤：
1 新建工程 ： 将需要改造的项目拷贝一份 修改项目名称
2 将相应的表结构拷贝到新的数据库中 修改不直观的表名 字段的备注等
3 修改对应的代码 和数据库表字段对应 熟悉接口对应的相关类 找到与之相关的
注意：
1 并发幂等性（重试引起）控制
2 方法设置开关
3 金额存整数（元化为分）
4 解耦 （rocketMQ消息异步解耦）
加入状态机【待完成】
5 分库【垂直拆分 基本的思路就是按照业务模块来划分出不同的数据库】
分表【垂直拆分某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中】
好处： 便于 管理、维护、监控、扩展 ，在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈，是大型分布式系统中优化数据库架构的重要手段。
注意：需要改写以前的查询语句【跨库join，分布式事务等】
跨库Join的几种解决思路
1 全局表【很少发生编号 像数据字典】
系统中所有模块都可能会依赖到的一些表，将这类表在其他每个数据库中均保存一份
2 字段冗余 【最复杂的还是数据一致性问题，这点很难保证】
3 数据同步
定时A库中的tab_a表和B库中tbl_b有关联，可以定时将指定的表做同步，通过ETL工具来实施
4 系统层组装
在系统层面，通过调用不同模块的组件或者服务，获取到数据并进行字段拼装
注意：把循环调用改成一次调用【通常我们都会通过缓存来避免频繁RPC通信和数据库查询的开销】
join 查询带条件过滤的情况
查询出state字段符合/不符合的UserId，在查询问答数据的时候使用in/not in进行过滤，排序，分页等。过滤出有效的问答
数据后，再调用用户服务获取数据进行组装
6 考虑问题转换思路 ： 记得两方面着手 1 数据库层面【善于利用伪列】 2 代码层面
水平分表，能够降低单表的数据量，一定程度上可以缓解查询性能瓶颈。但本质上这些表还保存在同一个库中，所以库级别还是会有IO瓶颈。 所以，一般不建议采用这种做法
忽略配置文件被跟踪的另一种方法：
$ git update-index --assume-unchanged /path/to/file #忽略跟踪
$ git update-index --no-assume-unchanged /path/to/file #恢复跟踪模型： 领域模型 仓储模型
7 记录好追踪日志
eclipse里groovy 插件地址：http://dist.springsource.org/release/GRECLIPSE/e4.7