优点总结:

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

方案二:把事务专门独立出一个类出来处理(目前采用这种方案)

版权声明:本文为billmiao原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/billmiao/p/9872178.html