前两篇文章为大家带来了HSF容器启动和Porvider的分享。这篇来分析下consumer端的运行机制。
一. Consumer的启动
1. 服务代理
在HSFSpringConsumer的启动中会返回一个HSFServiceProxy的jdk动态代理,后续调用其实都是通过这个代理类来实现的。
InvocationHandler handler = newHSFServiceProxy(metadata);
Object proxyObj =Proxy.newProxyInstance(getClass().getClassLoader(), new Class[] {interfaceClass }, handler);
2. 服务订阅
通过metadataService的subscribe订阅服务的信息,主要是接口的所有地址,路由规则和机房流量规则
a. 路由规则
通过diamond订阅路由规则
DiamondManager diamondManager = newDefaultDiamondManager(group, dataId, new ManagerListenerAdapter() {
@Override
public voidreceiveConfigInfo(String configInfo) {
registerRule(serviceUniqueName, configInfo);
}
});
.......
registerRule(serviceUniqueName,configInfo);
当consumer端会有定时线程去diamond端获取单个服务的配置信息,默认周期15s,同时diamond使用了pushit进行实时通知,当有变更时会实时拿到变更信息,当有规则变更时都会刷新本地规则。
b. 路由规则注册
主要分2部分,路由规则(机器路由),机房流量规则(是否本地机房优先)
b.1 路由规则注册
b.1.1规则解析
代码:
// 处理路由规则
if (splitter.has(HSFConstants.HEADER_ROUTING_RULE)) {
final String routingRule =splitter.get(HSFConstants.HEADER_ROUTING_RULE);
addressService.setServiceRouteRule(serviceUniqueName, routingRule);
}
当在diamond里配置了路由规则时触发更新,规则内容类似于
Groovy_v200907@package hqm.test.groovy
public class RoutingRule{
Map> routingRuleMap(){
return[
"DETAIL":[
"172.23.172.101:*",
"172.24.165.63:*",
"172.23.204.170:*",
"172.23.204.185:*",
……
]
];
}
String interfaceRoutingRule(){
return null;
}
String mathodRoutingRule(String methodName, String[] paramTypeStrs){
return "DETAIL";
}
Object argsRoutingRule(String methodName, String[] paramTypeStrs){
return null;
}
}
在setServiceRouteRule中,hsf会调用parser来解析这些规则,上面那个规则将被GroovyRouteRuleParser解析成RouteRule实体,代码:
RouteRule rule = null;
for (RouteRuleParser parser : this.ruleParsers) {
...
rule =parser.parse(rawRouteRuleObj, allMethodSigs);
...
}
具体parse过程:
1. 拿到Groovy的Classloader:GroovyClassLoader loader = newGroovyClassLoader(GroovyRouteRuleParser.class.getClassLoader());
2. 将规则加载成Class实例 c_groovy = loader.parseClass(groovyRule);
3. 反射生成实例 ruleObj = c_groovy.newInstance();
4. 反射调用routingRuleMap方法,拿到规则索引的Map,后续的类级,方法级规则等的处理都是基于这个规则索引的
5. 反射调用interfaceRoutingRule方法,拿到接口级别的规则名称
6. 反射调用mathodRoutingRule方法,拿到方法级别的规则名称
7. 反射调用argsRoutingRule方法,拿到参数级别的规则名称
8. 组装RouteRule实体对象,返回之
b.1.2 地址结果更新
规则实体解析之后,就需要对现有的地址进行更新了,这样就可以让配置在调用方起效。代码:
RouteResultCacheaddressCache = getRouteResultCache(serviceUniqueName);
addressCache.setRouteRule(rule);
addressCache.reset();
RouteResultCache对象是对调用方直接可见的路由结果,也是规则生效所需要刷新的数据实体。为了方便进行并发控制,其实现使用了RefHolder的方式来更新,就是把所有数据对象都包了一层refer,刷新的时候直接修改refer的引用即可。具体reset过程:
1. 对规则索引的map进行规则过滤,从规则map生成一个结果map,其value不再是规则(正则表达式),而是过滤之后的具体机器地址了,规则过滤的源是当前所有可用的服务器列表
2. 重新计算接口级地址列表。从之前的规则索引中拿到具体规则,对当前所有可用的服务器列表进行过滤,得到接口级别的地址列表
3. 同样方法计算方法级别的地址列表
4. 引用切换
b.2机房流量规则
代码:
// 处理机房流量规则
if (splitter.has(HSFConstants.HEADER_FLOW_CONTROL_RULE)){
StringflowControlRule = splitter.get(HSFConstants.HEADER_FLOW_CONTROL_RULE);
addressService.setFlowControlRule(serviceUniqueName, flowControlRule);
}
Diamond中的规则定义:
flowControl@on 0.2
具体set过程:
1. 使用FlowControlRuleParser解析规则xml,生成FlowControlRule实体
2. 刷新该服务对应的AddressBucket实体中的可用服务列表,实现如下
3. 拿到所有地址
4. 通过过滤拿到所有可用的本机房地址列表
5. 如果本地优先,则设置可用服务地址列表为本地可用地址列表
6. 否则设置可用服务地址列表为所有可用地址列表(所有地址列表中过滤掉invalid的地址)
7. 地址结果更新,和路由规则一样将计算后的结果更新到RouteResultCache
c. 服务地址信息注册
通过configserver的推送,更新本地的所有地址列表,当有机器重新注册时,就会推送,这里是异步的。代码:
// 订阅服务地址信息
final String cs_subscriberId = SUBSCRIBER_PREFIX + serviceUniqueName;
SubscriberRegistration cs_registration = newSubscriberRegistration(cs_subscriberId, serviceUniqueName);
cs_registration.setGroup(group);
Subscriber subscriber = SubscriberRegistrar.register(cs_registration);
subscriber.setDataObserver(new SubscriberDataObserver() {
@Override
public void handleData(StringdataId, List
具体set过程:
1. 设置服务地址列表全集并重新计算服务地址列表,修改服务对应的AddressBucket实体中的所有地址列表
2. 从所有地址类表中筛选出和本机同处一个机房的机器列表,方式是比较ip前2段。。。
3. 刷新可用服务地址列表,和机房流量规则解析时一样
4. 地址结果更新,和路由规则一样将计算后的结果更新到RouteResultCache
二. Consumer的执行
调用consumer时,直接调用HSFServiceProxy的invoke方法,其最终会使用RPCProtocolTemplateComponent进行rpc调用。过程:
1. 组装请求对象
// 组装HSFRequest
final HSFRequest request = new HSFRequest();
request.setTargetServiceUniqueName(serviceUniqueName);
request.setMethodName(methodName);
request.setMethodArgSigs(paramTypeStrs);
request.setMethodArgs(args);
2. 是否需要发起远程调用,这里如果本地就有provider的话,直接调用本地service,我们常用的同步调用是需要发起远程调用的
3. 如果需要发起远程调用,则寻找调用目标地址,如为测试模式,则以配置的target为优先
4. 调用addressService的getServiceAddress寻址,寻址过程为单亲委派模式:参数级 -> 方法级 -> 接口级 -> 全部可用地址
5. 从计算后的地址列表中选一台机器作为调用对象
6. 校验目标机器是否可用,尝试创建连接,如果成功则认为可用,否则不可用
7. 如果不可用,将目标添加到invalid地址中,继续重试,重试最多2次
8. 如果重试之后还是找不到,则抛出异常,报找不到目标。。
9. 寻址代码:
// 当target不为null,或者重试次数已到达最大重试次数时,退出寻找可用的目标服务地址的过程
for (int i = 0;(isBlank(targetURL)) && (i < RETRY_TIMES); i++) {
...
targetURL =addressService.getServiceAddress(serviceUniqueName, methodName, paramTypeStrs,args);
if(!rpcService.validTarget(targetURL)) {
...
addressProfiler.addInvalidAddress(serviceUniqueName, targetURL);
...
targetURL = null;
}
}
// 如这个时候targetURL仍然为null,抛出异常
if (isBlank(targetURL)) {
throw newHSFServiceAddressNotFoundException("[HSF-Consumer] 未找到需要调用的服务的目标地址", MessageFormat.format(
"需要调用的目标服务为:{0} 组别为:{1}", new Object[] { serviceUniqueName, metadata.getGroup() }));
}
10. 找到地址后,使用tbremoting发起调用
11. 构造一个client,注意之前判断是否目标可用时,其实已经创建好连接,这里直接使用
client =ClientManager.getImpl().get(HSFConstants.APPTYPE_FORREMOTING,
HSFServiceTargetUtil.formatTargetURL(targetURL));
12. Future方式发起调用,调用线程一直等待,直到超时或有返回,timeout为Long.MAX_VALUE
Object rawResponse =future.get().get(timeout);
…
synchronized (this) {
while (!isDone&& waitTime > 0) {
wait(waitTime);
waitTime = end -System.currentTimeMillis();
}
}
13. IO线程将请求发送成功之后,启动一个timer,在超时时间点运行,返回等待线程一个异常信息,说明是超时了
// On written of APP request, addPendingRequest and start timeout trigger
if (wf.isWritten()) {
..
TimeoutHandle timeoutHandle =new TimeoutHandle();
timeoutFuture =DefaultClientManager.timer.schedule(timeoutHandle,connRequest.getRespTimeout(), TimeUnit.MILLISECONDS);
}
14. 如果provider端成功返回,则mina线程会调用DefaultMsgListener的messageReceived的方法,
DefaultClient client = (DefaultClient)connection.getClient();
client.putResponse((ConnectionResponse) message);
15. 写回响应,
DefaultRespFuture respFuture =(DefaultRespFuture) connRequest.getRespFuture();
respFuture.setResponse(connResp);
16. 唤醒等待的业务线程
synchronized (this) {
connResponse = resp;
isDone = true;
notifyAll();
}
17. 业务线程被唤醒后,处理provider返回的结果
private Object getResponseAfterDone()throws RemotingException {
int errorCode = connResponse.getResult();
switch (errorCode) {
case TRConstants.RESULT_SUCCESS:
returnconnResponse.getAppResponse();
case TRConstants.RESULT_TIMEOUT:
String log = LogResources.getLog(LogResources.RESP_TIMEOUT);
throw new TimeoutException(log);
case TRConstants.RESULT_OVERFLOW:
throw newWriteOverFlowException(connResponse.getErrorMsg(), (OverFlowWriteFuture)connResponse
.getErrorCause());
default:
throw newRemotingException(connResponse.getErrorMsg());
}
}
三. 小结
以上简单分析的consumer端的运行机制。Consumer端是服务治理的重点,其核心是寻址过程。Hsf使用了diamond动态规则来自定义规则,还是比较灵活的。
常见的找不到target的原因:
1. 对方机器不可用,invalid失败,比如发布的时候
2. 调用发起太快,configserver推送地址是异步的,有延时,如果调用很快发起,则有可能拿不到地址
3. 配置了特殊规则,把正常的机器过滤掉的
寻址类图如下: