1. 背景
最近在做系统架构升级,本次是讲数据库部分的一些经验。其中数据库(MySQL)部分的现状是数据库同时被多个应用直连,这样有一些弊端,比如:
- 有大量的重复代码,维护成本较高,也不优雅;
- 出现SQL语句质量的问题无法很快定位到是哪个应用导致的;
- 数据库调用方过于分散,不便于统一控制,比如数据读写权限,部分数据屏蔽等;
- 业务的发展,有的表数据量已经到了一定的规模,几百万到几千万不等,数据库存储拆分是必须要进行的事情。
理想的解决问题的方式很简单,就是把各应用中与此业务相关的dao层抽象成为一个单独应用(下文叫internal-rpc-app),同时对读写做一些统一的配置即可。
2. 具体实现
具体的业务应用与internal-rpc-app的内部通信使用公司内部具有服务治理功能的RPC框架JSF,JSF是一款稳定高效的框架,它对服务治理的粒度是接口,接口通过Spring框架做服务的发布和调用。
2.1 标准版本 1.0
接口注册申请
注册接口: com.jd.xx.BizRpcService1
注册接口: com.jd.xx.BizRpcService2
注册接口: com.jd.xx.BizRpcService3
......
注册接口: com.jd.xx.BizRpcServiceN
服务提供方配置
<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"/>
客户端调用方配置
<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 小结
1.0 版本很好的实现了我们的最初的目的,但是哪里不对呢?配置的工作量太高,前面有说到JSF框架的治理维度是接口。这就意味着,每次新增接口的时候要提交申请操作,同时要在consumer和provider做相对应的配置,几个还好,如果数据表很多,重复的工作量就很大。内部接口也不需要做太多细粒度的服务治理。于是有了第二版,主要目的是简化大量重复配置。
2.2 优化调用体验版本 2.0
2.2.1 内部实现 - 客户端
首先定义调用API:
BizRpcService1 bizRpcService1 = InternalPrxoyServices.BizRpcService1;
bizRpcService1.method1(param1, param2);
InternalPrxoyServices关键代码:
public class InternalPrxoyServices {
BizProxyRpcService1 BizRpcService1 = new BizProxyRpcService1();
BizProxyRpcService2 BizRpcService2 = new BizProxyRpcService2();
BizProxyRpcService2 BizRpcService3 = new BizProxyRpcService3();
......
BizProxyRpcServiceN BizRpcServiceN = new BizProxyRpcServiceN();
}
BizProxyRpcService1关键代码:
public class BizProxyRpcService1 extends BaseProxyService implements BizRpcService1 {
@Override
public String method1(String param1, String param2) throws InternalRpcException {
return super.execute(param1, param2);
}
}
BaseProxyService关键代码:
abstract class BaseProxyService implements InternalRpcService {
private InternalRpcService internalRpcService;
private Map<String, String> interfaceMap = new HashMap<String, String>();
BaseProxyService() {
// 已经被注入到一个静态变量中,此处直接获取
internalRpcService = InternalRpcServiceHolder.getInternalRpcService();
}
@Override
<T> T execute(Object... objects) throws InternalRpcException {
StackTraceElement[] stackTraceElements = Thread.currentThread().getStackTrace();
StackTraceElement callerStackTraceElement = stackTraceElements[2];
// 要取代理类实现到具体接口名称和方法名称以此定位具体到逻辑,框架不支持重名,所以重名问题不考虑
String interfaceName = getInterfaceName(callerStackTraceElement.getClass());
String methodName = callerStackTraceElement.getMethodName();
return (T) internalRpcService.execute(interfaceName, methodName, objects);
}
}
InternalRpcService接口定义:
public interface InternalRpcService {
Object execute(String serviceName, String methodName, Object... objects) throws InternalRpcException;
}
2.2.2 内部实现 - 服务端
服务端实现比较简单,直接根据接口传过来当serviceName、methodName、objects即可定位到具体service到方法,直接执行即可。
2.2.3 小结
到这里,我们实现了具体的目标。我们不再需要定义过多的配置了,客户端调用也变得简单明了。
那么,结束了吗?并没有,我们通过在客户端实现了一个代理类层解决了大量配置的问题,但是要写大量的代理类,这并不完美。
2.3 最终版本 3.0
在这一版,我们很自然的引入了动态生成代理。
2.3.1 客户端具体实现
因为引入了动态代理,所以要重新改写InternalPrxoyServices:
public class InternalPrxoyServices {
BizRpcService1 BizRpcService1 = ProxyServiceFactory.create(BizRpcService1.class);
BizRpcService2 BizRpcService2 = ProxyServiceFactory.create(BizRpcService2.class);
BizRpcService3 BizRpcService3 = ProxyServiceFactory.create(BizRpcService3.class);
......
BizRpcServiceN BizRpcServiceN = ProxyServiceFactory.create(BizRpcServiceN.class);
}
ProxyServiceFactory关键代码:
public class ProxyServiceFactory {
public static <T> T create(Class<T> internalInterface) {
final InternalRpcProxy<T> internalRpcProxy = new InternalRpcProxy<T>(internalInterface);
return (T) Proxy.newProxyInstance(internalInterface.getClassLoader(), new Class[] { internalInterface }, internalRpcProxy);
}
}
InternalRpcProxy关键代码:
class InternalRpcProxy<T> implements InvocationHandler, Serializable {
private final Class<T> internalRpcInterface;
InternalRpcProxy(Class<T> internalRpcInterface) {
this.internalRpcInterface = internalRpcInterface;
}
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
return InternalRpcServiceHolder.internalRpcService.execute(internalRpcInterface.getCanonicalName(), method.getName(), args);
}
}
2.4 小结
至此,已经解决了2.2.2提到的大量创建代理类的问题。
当然我们还做了很多文章中没有提及的事情,比如:
- 通过声明哪些接口可以走动态代理
- 方法重名、客户端接口合法性等校验
- 将method存入缓存
3. 总结
通过建立独立的应用,解决了前面数据库被多应用读写所产生的问题,通过开发了统一接口解决了服务端和客户端配置过多的问题。代码经过一点点抽象出来的,最后发现实现了一个简单的RPC雏形,只不过通信层是基于公司的RPC框架。
这引发了一些框架方面的思考:
- 是否应该去掉人工审批类似的流程?
- 是否应该允许更灵活的发布服务,比如:根据注解自动扫描发布服务,根据注解自动获取服务。
这不是技术问题,而是怎么权衡的问题。