Soul源码阅读系列(六)Sofa插件
15 May 2021 | Soul |本篇文章主要介绍学习使用sofa插件,如何将sofa服务接入到Soul网关,以及sofa的简单介绍。主要内容如下:
- 在
Soul中使用sofa服务- 查看官方样例
- 引入依赖
- 注册
sofa服务 - 运行
sofa服务 - 启动
Soul Admin和Soul Bootstrap - 体验
sofa服务
- 关于
sofasofa是什么sofa基本原理
- Sofa插件执行原理
BodyParamPlugin插件SofaPlugin插件SofaResponsePlugin插件
- Sofa服务及代理对象的生成
今天体验的是Soul中sofa插件,如果业务系统是由sofa构建而成的,当需要Soul网关的支持时,可以将自己的sofa服务接入soul网关。
1. 在Soul中使用sofa服务
1.1 查看官方样例
Soul官方在soul-examples模块提供了测试样例,其中的soul-examples-sofa模块演示的是Soul网关对sofa服务的支持。模块目录及配置信息如下:

soul.sofa是有关Soul对sofa插件支持的配置,adminUrl是Soul的后台管理地址,contextPath是业务系统的请求路径上下文。
1.2 引入依赖
在sofa服务的pom文件中引入soul相关依赖,当前版本是2.2.1。
<properties>
<rpc-sofa-boot-starter.version>6.0.4</rpc-sofa-boot-starter.version>
</properties>
<dependency>
<groupId>com.alipay.sofa</groupId>
<artifactId>rpc-sofa-boot-starter</artifactId>
<version>${rpc-sofa-boot-starter.version}</version>
</dependency>
<dependency>
<groupId>org.dromara</groupId>
<artifactId>soul-spring-boot-starter-client-sofa</artifactId>
<version>${soul.version}</version>
<exclusions>
<exclusion>
<artifactId>guava</artifactId>
<groupId>com.google.guava</groupId>
</exclusion>
</exclusions>
</dependency>
1.3 注册sofa服务
在需要被代理的接口上使用注解@SoulSofaClient,@SoulSofaClient注解会把当前接口注册到soul网关中。使用方式如下:

如果其他接口也想被网关代理,使用方式是一样的。在@SoulSofaClient注解中,指定path即可。
1.4 运行sofa服务
运行TestSofaApplication,启动soul-examples-sofa项目。sofa是需要注册中心的。本文使用的是zookeeper,启动也很简单。在官网下载,然后解压,直接运行zkServer.cmd就可以运行。

1.5 启动Soul Admin和Soul Bootstrap
参考上一篇的Soul入门,启动Soul Admin和Soul Bootstrap。Soul的后台界面如下:

如果sofa插件没有开启,需要手动在管理界面开启一下。

在Soul Bootstrap中,加入相关依赖:
<!--soul sofa plugin start-->
<dependency>
<groupId>com.alipay.sofa</groupId>
<artifactId>sofa-rpc-all</artifactId>
<version>5.7.6</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-client</artifactId>
<version>4.0.1</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>4.0.1</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>4.0.1</version>
</dependency>
<dependency>
<groupId>org.dromara</groupId>
<artifactId>soul-spring-boot-starter-plugin-sofa</artifactId>
<!-- 当前版本是2.2.1-->
<version>${project.version}</version>
</dependency>
<!-- soul sofa plugin end-->
1.6 体验sofa服务
三个系统(本身的业务系统(这里就是soul-examples-sofa),Soul后台管理系统Soul Admin,Soul核心网关Soul Bootstrap)都启动成功后,就能够体验到sofa服务在网关soul中的接入。

//实际sofa提供的服务
@SoulSofaClient(path = "/findAll", desc = "Get all data")
public DubboTest findAll() {
DubboTest dubboTest = new DubboTest();
dubboTest.setName("hello world Soul Sofa , findAll");
dubboTest.setId(String.valueOf(new Random().nextInt()));
return dubboTest;
}
上面向网关发起了一个请求http://localhost:9195/sofa/findAll,实际被调用的是sofa的服务。
2. 关于sofa
2.1 sofa是什么
在之前,我还没有使用过sofa,这里直接引用了官方的介绍:
SOFARPC是蚂蚁金服开源的一款基于Java实现的RPC服务框架,为应用之间提供远程服务调用能力,具有高可伸缩性,高容错性,目前蚂蚁金服所有的业务的相互间的RPC调用都是采用SOFARPC。SOFARPC为用户提供了负载均衡,流量转发,链路追踪,链路数据透传,故障剔除等功能。
SOFARPC还支持不同的协议,目前包括 bolt,RESTful,dubbo,H2C 协议进行通信。其中bolt是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。
个人理解:sofa是一个轻量级的dubbo。
2.2 sofa基本原理

-
- 当一个
SOFARPC的应用启动的时候,如果发现当前应用需要发布RPC服务的话,那么SOFARPC会将这些服务注册到服务注册中心上。如图中Service指向Registry。
- 当一个
-
- 当引用这个服务的
SOFARPC应用启动时,会从服务注册中心订阅到相应服务的元数据信息。服务注册中心收到订阅请求后,会将发布方的元数据列表实时推送给服务引用方。如图中Registry指向Reference。
- 当引用这个服务的
-
- 当服务引用方拿到地址以后,就可以从中选取地址发起调用了。如图中
Reference指向Service。
- 当服务引用方拿到地址以后,就可以从中选取地址发起调用了。如图中
上面主要内容是介绍了Soul对sofa提供的支持,结合实际案例进行了演示。给出了sofa的简单介绍。
3. Sofa插件执行原理
接下来就通过跟踪源码的方式来理解其中的执行原理。
在Soul网关中,Sofa插件负责将http协议转换成sofa协议,涉及到的插件有:BodyParamPlugin,SofaPlugin和SofaResponsePlugin。
BodyParamPlugin:负责将请求的json放到exchange属性中;SofaPlugin:使用Sofa进行请求的泛化调用并返回响应结果;SofaResponsePlugin:包装响应结果。
3.1 BodyParamPlugin插件
该插件在执行链路中是先执行的,负责处理请求类型,比如带有参数的application/json,不带参数的查询请求。
//org.dromara.soul.plugin.sofa.param.BodyParamPlugin#execute
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
//省略了其他代码
if (Objects.nonNull(soulContext) && RpcTypeEnum.SOFA.getName().equals(soulContext.getRpcType())) {
//处理json
if (MediaType.APPLICATION_JSON.isCompatibleWith(mediaType)) {
return body(exchange, serverRequest, chain);
}
//处理x-www-form-urlencoded
if (MediaType.APPLICATION_FORM_URLENCODED.isCompatibleWith(mediaType)) {
return formData(exchange, serverRequest, chain);
}
//处理查询
return query(exchange, serverRequest, chain);
}
return chain.execute(exchange);
}
3.2 SofaPlugin插件
完成SofaDubbo插件的核心处理逻辑:检查元数据 -->检查参数类型-->泛化调用。
//org.dromara.soul.plugin.sofa.SofaPlugin#doExecute
@Override
protected Mono<Void> doExecute(final ServerWebExchange exchange, final SoulPluginChain chain, final SelectorData selector, final RuleData rule) {
//省略了其他代码
//检查元数据
if (!checkMetaData(metaData)) {
//省略了其他代码
}
//检查参数类型
if (StringUtils.isNoneBlank(metaData.getParameterTypes()) && StringUtils.isBlank(body)) {
//省略了其他代码
}
//泛化调用
final Mono<Object> result = sofaProxyService.genericInvoker(body, metaData, exchange);
return result.then(chain.execute(exchange));
}
genericInvoker()方法中参数分别是请求参数body,有关服务信息的metaData,包含web信息的exchange。这里面的主要操作是:
- 根据请求路径从缓存获取服务配置信息;
- 获取代理对象;
- 请求参数转化为
sofa泛化参数; sofa真正的泛化调用;- 返回结果。
public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
//获取服务信息
ConsumerConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());
//获取代理对象
GenericService genericService = reference.refer();
//请求参数转化为泛化调用的参数
Pair<String[], Object[]> pair;
if (null == body || "".equals(body) || "{}".equals(body) || "null".equals(body)) {
pair = new ImmutablePair<>(new String[]{}, new Object[]{});
} else {
pair = sofaParamResolveService.buildParameter(body, metaData.getParameterTypes());
}
//异步返回结果
CompletableFuture<Object> future = new CompletableFuture<>();
//响应回调
RpcInvokeContext.getContext().setResponseCallback(new SofaResponseCallback<Object>() {
@Override
public void onAppResponse(final Object o, final String s, final RequestBase requestBase) {
future.complete(o);
}
@Override
public void onAppException(final Throwable throwable, final String s, final RequestBase requestBase) {
future.completeExceptionally(throwable);
}
@Override
public void onSofaException(final SofaRpcException e, final String s, final RequestBase requestBase) {
future.completeExceptionally(e);
}
});
//真正的泛化调用
genericService.$invoke(metaData.getMethodName(), pair.getLeft(), pair.getRight());
//返回结果
return Mono.fromFuture(future.thenApply(ret -> {
if (Objects.isNull(ret)) {
ret = Constants.SOFA_RPC_RESULT_EMPTY;
}
exchange.getAttributes().put(Constants.SOFA_RPC_RESULT, ret);
exchange.getAttributes().put(Constants.CLIENT_RESPONSE_RESULT_TYPE, ResultEnum.SUCCESS.getName());
return ret;
})).onErrorMap(SoulException::new);
}
真正的sofa泛化调用是genericService.$invoke()。到这里,SofaPlugin插件的主要工作就完了,后面就是返回结果。
3.3 SofaResponsePlugin插件
这个插件就是对结果再一次包装,处理错误信息和成功的结果信息。
//org.dromara.soul.plugin.sofa.response.SofaResponsePlugin#execute
@Override
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
return chain.execute(exchange).then(Mono.defer(() -> {
final Object result = exchange.getAttribute(Constants.SOFA_RPC_RESULT);
//处理错误的信息
if (Objects.isNull(result)) {
Object error = SoulResultWrap.error(SoulResultEnum.SERVICE_RESULT_ERROR.getCode(), SoulResultEnum.SERVICE_RESULT_ERROR.getMsg(), null);
return WebFluxResultUtils.result(exchange, error);
}
//处理成功的信息
Object success = SoulResultWrap.success(SoulResultEnum.SUCCESS.getCode(), SoulResultEnum.SUCCESS.getMsg(), JsonUtils.removeClass(result));
return WebFluxResultUtils.result(exchange, success);
}));
}
至此,就跟踪完了Soul网关中对Sofa插件处理的核心操作:接入sofa服务,将http访问协议转化为sofa协议,通过sofa的泛化调用获取真正的接口服务信息。
4. Sofa服务及代理对象的生成
最后,我们还需要想到的是:服务的配置信息是怎么来的?以及代理对象是怎么得到的?
本文的分析思路和之前的Apache Dubbo是一样的。
public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
//获取服务
ConsumerConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());
if (Objects.isNull(reference) || StringUtils.isEmpty(reference.getInterfaceId())) {
ApplicationConfigCache.getInstance().invalidate(metaData.getServiceName());
reference = ApplicationConfigCache.getInstance().initRef(metaData);
}
//获取代理对象
GenericService genericService = reference.refer();
//省略了其他代码
genericService.$invoke(metaData.getMethodName(), pair.getLeft(), pair.getRight());
return Mono.fromFuture(future.thenApply(ret -> {
//省略了其他代码
})).onErrorMap(SoulException::new);
}
先说结论:服务配置信息的来源是soul-admin同步到网关。
整个流程涉及到的类和方法如下:
soul-admin端:
WebsocketCollector:onMessage();SyncDataServiceImpl:syncAll();MetaDataService:syncData();
soul-bootstrap网关端:
SoulWebsocketClient:onMessage(),handleResult();WebsocketDataHandler:executor();AbstractDataHandler:handle();MetaDataHandler:doRefresh();SofaMetaDataSubscriber:onSubscribe();ApplicationConfigCache:initRef(),build();
在本文的测试中,soul-admin端和soul-bootstrap网关端之间的数据同步是通过websocket进行。所以在网关启动的时候会进行数据同步操作。
在soul-bootstrap网关端前面几个类主要处理同步的数据类型,最终流转到ApplicationConfigCache,在这里面进行构建服务build()。
public ConsumerConfig<GenericService> build(final MetaData metaData) {
ConsumerConfig<GenericService> reference = new ConsumerConfig<>();
reference.setGeneric(true);
reference.setApplication(applicationConfig);
reference.setRegistry(registryConfig); //注册中心地址
reference.setInterfaceId(metaData.getServiceName());
reference.setProtocol(RpcConstants.PROTOCOL_TYPE_BOLT);
reference.setInvokeType(RpcConstants.INVOKER_TYPE_CALLBACK);
reference.setRepeatedReferLimit(-1);
String rpcExt = metaData.getRpcExt();//元数据信息
SofaParamExtInfo sofaParamExtInfo = GsonUtils.getInstance().fromJson(rpcExt, SofaParamExtInfo.class);
if (Objects.nonNull(sofaParamExtInfo)) {
if (StringUtils.isNoneBlank(sofaParamExtInfo.getLoadbalance())) {
final String loadBalance = sofaParamExtInfo.getLoadbalance();
reference.setLoadBalancer(buildLoadBalanceName(loadBalance));
}
Optional.ofNullable(sofaParamExtInfo.getTimeout()).ifPresent(reference::setTimeout);
Optional.ofNullable(sofaParamExtInfo.getRetries()).ifPresent(reference::setRetries);
}
//从注册中心获取代理服务
Object obj = reference.refer();
if (obj != null) {
log.info("init sofa reference success there meteData is :{}", metaData.toString());
cache.put(metaData.getPath(), reference);//将服务信息放到cache中去
}
return reference;
}
在同步过程中,将所有的元数据信息及注册中心的服务放到了cache中,在使用的时候,就会到这个cache中去拿。就是在文章开始的地方提到的泛化调用。
public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
//从缓存的cache中获取服务
ConsumerConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());
if (Objects.isNull(reference) || StringUtils.isEmpty(reference.getInterfaceId())) {
ApplicationConfigCache.getInstance().invalidate(metaData.getServiceName());
reference = ApplicationConfigCache.getInstance().initRef(metaData);
}
//获取代理对象
GenericService genericService = reference.refer();
//省略了其他代码
genericService.$invoke(metaData.getMethodName(), pair.getLeft(), pair.getRight());
return Mono.fromFuture(future.thenApply(ret -> {
//省略了其他代码
})).onErrorMap(SoulException::new);
}
总结:本文结合实际案例演示了Soul网关是如何接入sofa服务,然后通过源码跟踪的方式分析了sofa泛化服务的调用流程,最后分析了Sofa插件里面的服务是如何被加载,包括服务的配置信息和 代理对象的生成。