Soul 网关源码阅读（四）Dubbo请求概览

Soul 网关源码阅读（四）Dubbo请求概览

---

简介

    本次启动一个dubbo服务示例，初步探索Soul网关源码的Dubbo请求处理流程

示例运行

环境配置

    在Soul源码clone下来以后，有一个 soul-example 目录，这个就是示例工程，里面有很多的示例可以运行

    可能初始文件夹不被IDEA识别为Java工程，我们需要点击改工程目录下的 pom.xml 文件，然后在右键，在菜单中选择：add as maven project

    我们选择运行：soul-examples --> soul-examples-apache-dubbo-service

    此次示例需要mysql和zookeeper，我们使用docker启动一下,记得修改 soul-admin 的数据库配置，其他的都不需要懂，猜测zk有默认配置

docker run -dit --name zk -p 2181:2181 zookeepe
docker run --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 -d mysql:latest

测试运行

    然后运行 Soul-admin、Soul-bootstrap,可以参考：Soul 源码阅读（二）代码初步运行

    运行soul-examples-apache-dubbo-service

    登录 soul-admin 管理界面：http://localhost:9095/ ，账号和密码：admin 123456

    进入界面：系统管理 --> 插件管理

    在插件：dubbo，点击编辑，将状态修改为开启（是个开关图标）

    开启成功后，可以在Soul-Bootstrap中看到相关的日志，大致如下：

o.d.s.p.a.d.c.ApplicationConfigCache     : init aliaba dubbo reference success there meteData is :MetaData
o.d.s.p.a.d.c.ApplicationConfigCache     : init aliaba dubbo reference success there meteData is :MetaData
o.d.s.p.a.d.c.ApplicationConfigCache     : init aliaba dubbo reference success there meteData is :MetaData

    进入Soul-admin管理界面：插件管理 --> dubbo ，我们可以看到很多的配置，这些都是soul-examples-apache-dubbo-service的配置

    随便找个查询的接口：http://localhost:9195/dubbo/findAll

    使用浏览器访问得到的结果如下：

{
     
    "code": 200,
    "message": "Access to success!",
    "data": {
     
        "name": "hello world Soul Apache, findAll",
        "id": "-1206394682"
    }
}

    很好，已经成功跑通示例，接下来，进入源码进行debug

源码分析

    基于上篇，我们已经知道了一个HTTP请求的初步处理流程：soul源码阅读3-请求处理概览.md

    基于上篇的熟悉度，我们就开始看看Dubbo的处理流程和Http的有什么区别，顺带看一看各个Plugin都干了啥

    Plugins的链式处理核心类是：SoulWebHandler，我们就从这里开始打上断点，逐步进入每个Plugin进行查看

        public Mono<Void> execute(final ServerWebExchange exchange) {
     
            return Mono.defer(() -> {
     
                if (this.index < plugins.size()) {
     
                    SoulPlugin plugin = plugins.get(this.index++);
                    Boolean skip = plugin.skip(exchange);
                    if (skip) {
     
                        return this.execute(exchange);
                    }
                    return plugin.execute(exchange, this);
                }
                return Mono.empty();
            });
        }

GlobalPlugin

    代码看的不是很懂，猜测有下面的功能：

• 获取请求头的 upgrade，此时为null，进入逻辑
• 另外的分支的MultiValueMap有点像文件上传之类需要的，后面有时间验证一下
• 功能是修改了SoulContext

    这个不是此次分析的目标，到这就跳过

SignPlugin

    这个应该是一个认证相关的插件，但在获取插件信息，没有开启，不进入逻辑，直接跳过，没有进入具体执行

    这里发现有的能需要进入函数：execute，有的直接进入：doExecute。稍微有点好奇，就看了下原因，大致是直接继承SoulPlugin就直接进入doExecute,而 AbstractSoulPlugin需要进入execute，这里不是重点，就不继续研究这个了，有个大概了解即可

WafPlugin、RateLimiterPlugin、HystrixPlugin、Resilience4JPlugin

    上面几个都是获取插件信息，没有开启，不进入逻辑，直接跳过

DividePlugin

    这里是true，有点和自己想的不一样，查看管理界面看到divide是开启的，稍微挖一下这个

    定位到关键函数：Boolean skip = plugin.skip(exchange)，判断是否可以跳过，我们看下具体的代码：

    public Boolean skip(final ServerWebExchange exchange) {
     
        final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
        return !Objects.equals(Objects.requireNonNull(soulContext).getRpcType(), RpcTypeEnum.HTTP.getName());
    }

    好像就是判断类型来返回是否跳过，其他的plugins的判断逻辑，至于这些都是都是怎么来的，今天就不分析了，保留体力，留待下次进行分析

WebClientPulugin、WebsocketPlugin

    skip 为 true，直接跳过,跳过的判断的和DividePlugin基本相同，通过类型判断

BodyParamPlugin

    对soulContext进行了操作，和GlobalPlugin有一些联动，还看到了MediaType等关键字，感觉很像文件上传之类的，但细节不太清楚，这个也不是本次分析的目的，不要陷入细节，这次放过它，下次有时间再仔细研究

AlibabaDubblePlugin

    这个插件是本次的核心，大致干了下面三个事情

• 进入了并且匹配上了规则，发现这个plugin是dubbo总插件，同样能处理Apache dubbo，也就是他们是相同的或者复用的
• 进入到doExecute函数：获取body，soulContext，查看soulContext发现已经有方法、路径等信息（猜测是前面加的），获得关键的metaData
• 获取请求的结果，并且放到exchange中：Object result = alibabaDubboProxyService.genericInvoker(body, metaData)

    代码大致如下：

    protected Mono<Void> doExecute(final ServerWebExchange exchange, final SoulPluginChain chain, final SelectorData selector, final RuleData rule) {
     
        String body = exchange.getAttribute(Constants.DUBBO_PARAMS);
        SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
        assert soulContext != null;
        // dubbo 请求的相关数据
        MetaData metaData = exchange.getAttribute(Constants.META_DATA);
        if (!checkMetaData(metaData)) {
     
            assert metaData != null;
            log.error(" path is :{}, meta data have error.... {}", soulContext.getPath(), metaData.toString());
            exchange.getResponse().setStatusCode(HttpStatus.INTERNAL_SERVER_ERROR);
            Object error = SoulResultWrap.error(SoulResultEnum.META_DATA_ERROR.getCode(), SoulResultEnum.META_DATA_ERROR.getMsg(), null);
            return WebFluxResultUtils.result(exchange, error);
        }
        if (StringUtils.isNoneBlank(metaData.getParameterTypes()) && StringUtils.isBlank(body)) {
     
            exchange.getResponse().setStatusCode(HttpStatus.INTERNAL_SERVER_ERROR);
            Object error = SoulResultWrap.error(SoulResultEnum.DUBBO_HAVE_BODY_PARAM.getCode(), SoulResultEnum.DUBBO_HAVE_BODY_PARAM.getMsg(), null);
            return WebFluxResultUtils.result(exchange, error);
        }
        // 获取请求结果
        Object result = alibabaDubboProxyService.genericInvoker(body, metaData);
        if (Objects.nonNull(result)) {
     
            // 将结果放到exchange中
            exchange.getAttributes().put(Constants.DUBBO_RPC_RESULT, result);
        } else {
     
            exchange.getAttributes().put(Constants.DUBBO_RPC_RESULT, Constants.DUBBO_RPC_RESULT_EMPTY);
        }
        exchange.getAttributes().put(Constants.CLIENT_RESPONSE_RESULT_TYPE, ResultEnum.SUCCESS.getName());
        return chain.execute(exchange);
    }

    继续跟踪查看获取result的那个函数，通过下面的代码可以明显看出确实是rpc调用，并得到结果

    public Object genericInvoker(final String body, final MetaData metaData) throws SoulException {
     
        // 通过rpc和dubbo的相关知识，这里的reference相当于consumer，metaData.getPath()==/dubbo/findAll
        // ApplicationConfigCache.getInstance().get 的逻辑感觉比较复杂，先不看了，大体感觉是初始化的时候使用 path 作为了 key
        ReferenceConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());
        if (Objects.isNull(reference) || StringUtils.isEmpty(reference.getInterface())) {
     
            ApplicationConfigCache.getInstance().invalidate(metaData.getPath());
            reference = ApplicationConfigCache.getInstance().initRef(metaData);
        }
        // 这段很像RPC Demo中的获取字节码生成的对象
        GenericService genericService = reference.get();
        try {
     
            Pair<String[], Object[]> pair;
            if (ParamCheckUtils.dubboBodyIsEmpty(body)) {
     
                pair = new ImmutablePair<>(new String[]{
     }, new Object[]{
     });
            } else {
     
                pair = dubboParamResolveService.buildParameter(body, metaData.getParameterTypes());
            }
            // 传入方法名、参数名、参数？Dubbo还没用的熟练，暂时这样猜一猜，不影响此次分析的大局
            return genericService.$invoke(metaData.getMethodName(), pair.getLeft(), pair.getRight());
        } catch (GenericException e) {
     
            log.error("dubbo invoker have exception", e);
            throw new SoulException(e.getExceptionMessage());
        }
    }

    对reference.get()，有点好奇，稍微看下 ReferenceConfig

    public synchronized T get() {
     
        // 判断是否能用
        if (this.destroyed) {
     
            throw new IllegalStateException("Already destroyed!");
        } else {
     
            // 有延迟加载的作用
            if (this.ref == null) {
     
                this.init();
            }

            return this.ref;
        }
    }

    看到它这用法还是挺巧妙的，有一个延迟加载的效果，好像可以按照这个思路去改一改自己的RPC Demo的客户端代理生成，哈哈

MonitorPlugin

    获取插件信息，没有开启，不进入逻辑，直接跳过

WebClientResponsePlugin

    skip = true，直接跳过

DubboResponsePlugin

    看名字就知道是个核心类，我们在then后执行的代码段打个断点（这种需要单独打个端口，后面才能跳进去）

    public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
     
        return chain.execute(exchange).then(Mono.defer(() -> {
     
            // 从exchange中拿到结果
            final Object result = exchange.getAttribute(Constants.DUBBO_RPC_RESULT);
            try {
     
                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));
                // 进入后使用之前熟悉的：exchange.getResponse().writeWith，返回响应给客户端
                return WebFluxResultUtils.result(exchange, success);
            } catch (SoulException e) {
     
                return Mono.empty();
            }
        }));
    }

    执行完plugins链后进入到这个断点：大致是获取结果result，加工得到success

    然后WebFluxResultUtils.result(exchange, success)，进入后是：exchange.getResponse().writeWith，返回响应给客户端

    到这里，一个Dubbo请求的处理流程大致展示在我们面前了，有了前面几篇的分析基础，还是挺流畅的

总结

    此次分析验证了在上篇中的一些猜想，也得到了一些新的东西，请求处理的大致流程图如下：

• HttpServerOperations : 明显的netty的请求接收的地方，请求入口
• ReactorHttpHandlerAdapter ：生成response和request
• HttpWebHandlerAdapter ：exchange 的生成
• FilteringWebHandler : filter 操作
• SoulWebHandler ：plugins调用

    可以参考下上篇分析： Soul 源码阅读（三）HTTP请求处理概览

    这篇中我们详细分析各个Dubbo 经过的 Plugin 的相关处理，有些复杂的就没有看了，但也得到我们此次分析想要的结果，脑海中对一个RPC请求如果进行处理，设计那些组件有了一定的了解，基于这些了解也能进行更近一步的分析

    我们收获和HTTP请求调用、RPC请求调用、Websocket请求调用是互斥的，通过判断请求的类型来进行选择其中一个，而HTTP相应、RPC响应都会转为HTTP响应，然后返回给客户端，exchange里面估计是绑定了一个socket，然后直接调用即可（Netty网关Demo又可以进行借鉴了）

    此次分析有了下面新的疑问：

• Websocket的响应的返回时怎样的？是长连接吗？因为没有看到Websocket响应相关的处理类
• exchange中的请求类型是怎么绑定，如何生成的？
• 限流等插件也是需要进行匹配吗？具体执行逻辑是怎样的？

    上面这些问题就留待以后分析了，慢慢来才能可持续发展

Soul网关源码分析文章列表

• Soul 源码阅读（一） 概览
• Soul 源码阅读（二）代码初步运行
• Soul 源码阅读（三）HTTP请求处理概览