优点总结：
1.用注解实现输入和输出日志的打印，别人的工程都是显示调用日志打印接口的
2.dubbo接口文件使用分文件管理，provider文件根据自身的业务功能（授信/激活/提额/基础）拆分，consumer文件根据不同的应用来拆分，最大程度避免冲突的发生
3.使用MQ注解（自定义的）来配置mq，使得开发者在MQ接收端，只需要配置一个注解，就可以成为MQ的接收者。别人都是在MQ的启动类里，一个个service的显示注入的。
实现原理：在应用启动的时候，会启动mq，而我们的做法是，在mq启动时，扫描打了MQ注解的所有类，避免了每加一个mq，就要修改mq启动的service文件
4.封装很完善：使用自定义的CacheUtil类来操作redis，便于以后切换不同的Cache类型；不直接使用mybatise提供的接口，而是做一层封装，以便以后切换数据库类型；调外部的dubbo时，不是直接调用，而是做一层封装，避免对方接口修改数据结构后，我方大面积修改代码的问题
5.功能非常灵活：使用配置来定义授信页面配置，如果要下掉某个页面，可以在一分钟之内，下掉该页面
6.可扩展性很好：不同的用户身份我们通过一个算法来确认一个标，通过这个标来确认走哪个流程。如果要新增加用户的逻辑，只需要增加路由层的配置，不会对原流程造成影响
7.有个站点能快速走用户的流程，方便开发和测试造数据
8.使用快速打tag、快速发版、自动生成单元测试，提高开发效率
待完善：
1.页面配置db化，便于运营人员调控
2.高可用性可以提高，例如，一个页面如果底层的系统挂了，可以先采集数据，然后等用户提交审核了，再一个个过节点
遇到的问题和优化方案
1.页面加载耗时严重，用户体验差，导致用户流失
问题的原因：接口耗时严重，最长到达6s。加载列表页时需要过风控节点，风控节点底层调用外部接口，外部接口耗时不可控
优化方案：
方案一：离线跑用户的风控节点，用户访问时直接打中缓存。（脚本解决）
方案二：提交审核时，发送MQ，进行审核
2.在同一个类里，用事务注解，事务使用失败
问题原因：spring的注解使用的是java的动态代理，在同一个对象里互相调用不会新生成代理类，即不会调用注解
方案一：把spring的代理方式调为cglib
方案二：把事务专门独立出一个类出来处理（目前采用这种方案）