转载

记一次 Java 动态代理实践

导语：在Java生态中，我们经常直接或者间接的用到动态代理，比如通过动态代理调用远程服务，再比如通过动态代理实现解耦。本文结合京东服务框架JSF，讲述京东使用动态代理进行抽象的一次实践，以达到升级数据库访问层的目的。

刘世杰，京东商城Java高级开发工程师，一直从服务端研发工作，目前主要负责京东海外站商品主数据基础服务。个人喜欢读源码，注重细节，有些许代码洁癖。对高可用、高性能、高并发方面的技术保持持续关注。

1. 背景

最近在做数据库（MySQL）方面的升级改造。现状是数据库同时被多个应用直连，存在了一些问题：

有大量的重复代码，维护成本较高，也不优雅；
出现SQL语句质量的问题无法很快定位到是哪个应用导致的；
数据库调用方过于分散，不便于统一控制，比如部分业务数据的读写、屏蔽等；
业务的发展，有的表数据量已经到了一定的规模，几百万到几千万不等，数据库存储拆分是必须要进行的事情。

解决问题的方式很简单，就是把各应用中与此业务相关的dao层抽象成为一个单独应用（以下称为internal-rpc-app），进行统一管理。

2. 具体实现

具体的业务应用与internal-rpc-app的内部通信使用公司内部具有服务治理功能的RPC框架JSF，JSF是一款稳定高效的框架，它对服务治理的粒度是接口，接口通过Spring做服务的发布和调用配置。每个接口对应一个数据表的CURD及特殊业务。

2.1 标准版本 1.0

2.1.1. 接口注册申请

注册接口： com.jd.xx.BizRpcService1

注册接口： com.jd.xx.BizRpcService2

注册接口： com.jd.xx.BizRpcService3

......

注册接口： com.jd.xx.BizRpcServiceN

2.1.2. 服务提供方配置

<jsf:provider id="rpc1" interface="com.jd.xx.BizRpcService1"/>
<jsf:provider id="rpc2" interface="com.jd.xx.BizRpcService2"/>
<jsf:provider id="rpc3" interface="com.jd.xx.BizRpcService3"/>
......
<jsf:provider id="rpcN" interface="com.jd.xx.BizRpcServiceN"/>

2.1.3. 客户端调用方配置

<jsf:consumer id="rpc1" interface="com.jd.xx.BizRpcService1"/>
<jsf:consumer id="rpc2" interface="com.jd.xx.BizRpcService2"/>
<jsf:consumer id="rpc3" interface="com.jd.xx.BizRpcService3"/>
......
<jsf:consumer id="rpcN" interface="com.jd.xx.BizRpcServiceN"/>

2.1.4 小结

此版本实现了我们的最初的目的，但是有一个不太好的地方，就是配置的工作量太高，前面有说到JSF框架的治理维度是接口。这也意味着，每次新增接口都要提交申请操作，同时要在consumer和provider做相对应的配置，几个还好，如果数据表有几十个上百个，重复的工作量就很大。同时内部接口也不需要做太细粒度的服务治理。于是有了第二版，主要目的是简化大量重复配置。