运行效果
5. 优势分析
g) 一次性开发与接入，所有插件按标准开发后适用于所有框架，扩展插件依赖注解配置即可
h) 功能解耦，各个插件之间互相不依赖，对业务系统侵入性近乎为0
i) 支持同步 异步双模式，针对不同插件的功能特点，可以在开发插件之初就决定使用同步还是异步执行的方式来运行插件功能。
j) 自定义插件开发，除插件库中的公共插件可以随便供大家使用外，使用者还可随时开发专属于自己业务的插件放到自己工程中，插件器同样可以自动加载并运行。
k) 最重要的一点，用一行代码来代替之前一两天的工作量，在开发效率和快速迭代上会让人屡试不爽。
性能及影响使用jmh工具，对插件器进行基准性能测试，测试模式为吞吐量。基本总结如下：
1. 空方法性能测试
测试目标：测试aop代理类对比原生类，对性能的影响
测试结果：对于毫秒级的方法调用，插件器不会影响主业务的吞吐量
测试数据：
空方法运行性能测试结果
测试结果说明：
a) milli 参数是模拟主方法实际执行时间，单位毫秒
b) baseline 方法是实例化Demo类，并调用baseline方法
c) noop 方法是使用插件器生成Demo类的代理，并调用noop方法，NoopAnno 插件是异步的空调用
d) noopSerialize 方法是使用插件器生成Demo类的代理，并调用noopSerialize方法，NoopAnnoSerialize 插件是同步的空调用
2. 同步异步性能测试
测试目标：测试插件器在同步和异步模式下，对性能的影响
测试结果：对于毫秒级的方法调用，插件器在异步模式下会提高吞吐量，在同步模式下和原生方法有一样的吞吐量。before after 部分执行时间占总执行时间比例越大，异步模式对吞吐量的提升越大。
测试数据：
同步异步性能测试结果
测试结果说明：
a) consumingTime 参数是模拟各阶段执行时间，单位毫秒。10_20_10 代表 before_invoke_after，即before执行时间10毫秒，invoke执行时间20毫秒，after执行时间10毫秒。
b) baseline 方法是实例化Demo2类，并调用baseline方法
c) test 方法是使用插件器生成Demo2类的代理，并调用test方法，TestAnno 插件是异步调用
d) testSerialize 方法是使用插件器生成Demo2类的代理，并调用testSerialize方法，TestAnnoSerialize 插件是同步调用
落地与实践1. 适用场景
a) 业务性较强的web项目，在入口位置非常适用。
b) 微服务项目，同web项目一样，可在入口位置使用。
c) 所有项目的内部方法直接调用，可细化到普通的get、set方法都可以使用该模式。
2. 现有插件仓库示例（按类别划分）
a) 监控（报警）相关
b) 缓存相关
c) 服务动态降级、熔断相关
d) 动态容灾（灾备）相关
e) 基本参数校验相关
f) 日志打印与收集相关
3. 自定义插件扩展与开发
插件仓库里的插件不够用怎么办？功能不完全符合自己要求怎么办？需要处理特定业务逻辑怎么办？
当然没问题！自定义插件扩展完全能够搞定，只需按照文档规范，分分钟即可开发属于自己的专属插件，且可单独放到自己的业务工程中，其他什么都不用做，工程重启后可自动加载运行，可谓方便之极。如过滤个敏感词、填充个额外信息、增加个权限校验、补充个自己喜欢的监控报警等等，都可以自己来实现。
下面是我们快速演示如何实现一个自己的插件：
a) 编写注解，DefinedPluginImpl引用的类为该注解的实现类，即第二步要编写的内容
插件注解类
b) 编写注解，DefinedPluginImpl引用的类为该注解的实现类，即第二步要编写的内容编写实现类, 需要继承 FPluginAnnotationAbstract，插件默认是以异步方式执行，如果需要以同步方式执行（例如在插件中返回数据等），需要继承IFPluginAnnotationSerial接口。
