运维开发网

『互联网架构』软件架构-spring之AOP场景实战(11)

运维开发网 https://www.qedev.com 2020-10-20 08:13 出处:51CTO 作者:IT人故事
面试的时候,经常被面试官问到AOP在你的项目中用到了那些场景,我一般的回答是日志,权限,事务处理,方法的统计,性能的监控。其实权限和事务都是跟业务相关的,咱们一起来想想针对其他几个如何来设计。重点是设计的思路。源码:https://github.com/limingios/netFuture/tree/master/tuling-enhance-plugin-masterAOP能干什么?日志新增的

面试的时候,经常被面试官问到AOP在你的项目中用到了那些场景,我一般的回答是日志,权限,事务处理,方法的统计,性能的监控。其实权限和事务都是跟业务相关的,咱们一起来想想针对其他几个如何来设计。重点是设计的思路。源码:https://github.com/limingios/netFuture/tree/master/tuling-enhance-plugin-master

『互联网架构』软件架构-spring之AOP场景实战(11)

AOP能干什么?

  • 日志
    1. 新增的日志

      有必要打印。

  1. 查询的日志

    对于系统来说基本都是写少,读多的,是不是所有的日志都有必要打。是不是打印很多无用的日志,其实看日志就是看传递的参数有没有问题,也就是说有问题了才看日志,是不是可以这样理解其实百分之90以上的日志是无用日志,打印其实是无用的,我说的场景,其实如果是日志分析工作,可能所有的日志都有必要,但是可能有些日志不需要埋点,没有必要埋点对吧。也就是日志是特定日志需要打印,根据业务来说。

传统的AOP的弊端

  • 不够灵活

    一般都是通用功能,基本无人做定制化。想打印那些,就打印那些。代码写死了,如果需要改必须重启系统来完成。

  • 对业务造成侵入

    代码写在业务功能里面了,根据业务功能一起发布一起升级。写在了业务功能里面了。耦合进去了。

  • 发布困难

    要针对某个增加,需要写代码,进行业务的发布和升级。很麻烦,如果一个系统改就改了,如果有成百上千的业务,都需要增加。成本高。太重了。性能监控可能都需要写,10个项目写10次。

解决方法

  • 可以低成本的介入非业务功能

    比传统的写AOP成本更低,可以远程的装载插件。不重启的项目。我们之前的方式每次设计一张表,表里设计了很多个参数,每次过业务方法其实都需要读一遍数据库,因为很慢后来换成了redis,但是更改了值后,需要删除redis内的内容。这种方法也不是最好的。不重启的状态下,保证了灵活性。

  • 非常的灵活

    动态的更新插件,启用和停止插件。自动下载插件,就算重启应用也有本地缓存,保存之前的设置。

源码结构图

『互联网架构』软件架构-spring之AOP场景实战(11)

『互联网架构』软件架构-spring之AOP场景实战(11)

『互联网架构』软件架构-spring之AOP场景实战(11)

PS:详细得我不多说了,直接看源码把,主要理解这个思路里面有classload加载对应的class,通过spring的IOC加载bean的方式获取Advice,进行控制。

扫码领视频副本.gif

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号