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

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

AOP能干什么？

• 日志

1. 新增的日志
   

   有必要打印。

2. 查询的日志
   

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

传统的AOP的弊端

• 不够灵活
  

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

• 对业务造成侵入
  

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

• 发布困难
  

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

解决方法

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

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

• 非常的灵活
  

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

源码结构图

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

已是最新文章