转载

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

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

AOP能干什么？

日志

新增的日志

有必要打印。
查询的日志

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

传统的AOP的弊端

不够灵活

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

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

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

解决方法

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

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

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