对已有多个同类功能产品,进行集成的经验总结

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

一、问题来源

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

二、解决思路

如下图所示:    

  1. 对产品A,B所涉及到的类进行了适配,简单的说就是持有对应的类,每一个都进行了代理,从而有了产品A、B的适配。(绿色)
  2. 由于调用客户端对具体实现的变化无感,所以要把适配的类都实现相同的接口,这样客户端只调用接口就行了。(绿色)
  3. 需要一个类对不同的适配进行管理,一般就有一个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操作,实际都是用内部原产品的类来做。

 

四、其它关联的情况

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

 

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值