转载

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

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

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

AOP能干什么?

  • 日志
  1. 新增的日志

    有必要打印。

  2. 查询的日志

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

传统的AOP的弊端

  • 不够灵活

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

  • 对业务造成侵入

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

  • 发布困难

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

解决方法

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

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

  • 非常的灵活

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

源码结构图

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

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

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

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

>>原创文章,欢迎转载。转载请注明:转载自,谢谢!>>原文链接地址:上一篇:

已是最新文章

原文  https://idig8.com/2019/02/19/hulianwangjiagouruanjianjiagou-springzhiaopchangjingshizhan11/
正文到此结束
Loading...