对已有多个同类功能实现的集成经验总结

    经人提醒这一年写的文章不多，一方面是因为同类的技术如果没有自己的体会不写，太我简单的也不写。去年多在学习各种各样的新接触的技术，还没有足够的经验与体会总结。最近对各种已有技术的集成方面，总结点个人经验。

一、问题来源

    比如当我们的系统需要引入日志产品时，已经有多种日志的实现了，比如log4j，logback，还有日志门面slfj等，我们不需要自己会开发，但我们需要根据不同的条件，或者配置，或者参数，使用其中某一个具体的实现。而对上使用日志的上层，需要屏蔽具体产品的不同，需要抽象出一个通用的日志对象模型。

二、解决思路

    如下图所示：    

•     对产品A，B所涉及到的类进行了适配，简单的说就是持有对应的类，每一个都进行了代理，从而有了产品A、B的适配。（绿色）
•     由于调用客户端对具体实现的变化无感，所以要把适配的类都实现相同的接口，这样客户端只调用接口就行了。（绿色）
•     需要一个类对不同的适配进行管理，一般就有一个manager类。（红色）

三、示例

1. dubbo作为微核心架构，具体实现都进行了集成，并通过extension进行加载。这里是比较简单的log部分。

• 左边目录有4个具体的实现，每一个里面都包含两个适配类，包装了我们单独用时的logFactory与log
• 外层目录主要有3个类，Logger/LoggerAdapter分别是上面说的两个类的接口。
• LoggerFactory类似上图中的manager类。它根据配置加载具体的实现的适配类。

其实我更愿意把每个实现中的叫*logAdapter/*logFactory，把外层的LoggerFactory叫LoggerManager。

• logFactory的适配类中得到一个log还是用具体原产品中的实现，再包装成自己的log适配类
• log适配类的各种操作，都用的原产品中的实现。

 



2. dubbo中另一个例子

• 同样有一个适配包，里面有所有类的适配类，通常叫api包
• 这里的manager是一个@SPI加载的适配类，它会动态从源码编译并加载到系统中，会根据URL中的参数，选择真正的序列化管理类Serialization。

• hessian2的Serialize会产生一个适配了Hessian2Output（原产品类，是阿里改良的）的类。各种write操作，实际都是用内部原产品的类来做。

四、其它关联的情况

• dubbo中进行了全面的集成，其它地方还没看到这么多，非常有学习价值。
• 除了人家做好各种产品，我们来适配，不如先做好标准api，大家按标准实现。这方面就比如java.sql标准了。DriverManager就是一个总的管理，通过getConnection()得到一个实现Connection接口的具体实现，进而得到各种其它接口的实现。
• 阿里的druid连接池，为了做监控，要在sql的所有api的接口上，再包装一层，内外层之间再加上过滤器（责任链模式）。执行外层的时候，先执行过滤再执行内层。过滤器这种模式用的很多，web应用的filter就是最常用的。做重要业务中，要考虑到未来的扩展，中间加上可配置的过滤器，未来有新功能就改动很少。spring中的bean的生命周期中，也都会插入一些用户可配置的额外处理，所以满足各种特殊的变化要求。
• 当然过滤器是静态的链条，常用的interceptor也是静态的。如果是动态代理，那也可以在代理类与真正类之间做很多事情，比如真正类前用缓存，比如真正类执行后，根据结果降级，或者进行TCC（分布式事务方案之一）补偿。
• 适配后的manager中经常要缓存一下用到的适配类。
• 一些代理中间件，比如代理读写分离的估计原理都差不多。大的功能完善的就是更动态选择，或者多种选择策略，中间再插入用户可配置的处理，比如性能统计，时间统计，校验...。

    后面提到的一些关联情况，因为有些也没有细看，凭着经验写的，如有错误欢迎指正。