[dubbo] resteasy 调用流程分析
程序员文章站
2022-07-13 10:55:54
...
在看 dubbo rest 协议的时候,很多东西都不是很懂,特别是看测试用例的时候,例如这个:
public void testRestProtocol() {
URL url = URL.valueOf("rest://127.0.0.1:5342/DemoService1/rest/say?version=1.0.0&interface=org.apache.dubbo.rpc.protocol.rest.DemoService");
DemoServiceImpl server = new DemoServiceImpl();
ProviderModel providerModel = new ProviderModel(url.getPathKey(), server, DemoService.class);
ApplicationModel.initProviderModel(url.getPathKey(), providerModel);
Exporter<DemoService> exporter = protocol.export(proxy.getInvoker(server, DemoService.class, url));
Invoker<DemoService> invoker = protocol.refer(DemoService.class, url);
Assertions.assertFalse(server.isCalled());
DemoService client = proxy.getProxy(invoker);
String result = client.sayHello("haha");
Assertions.assertTrue(server.isCalled());
Assertions.assertEquals("Hello, haha", result);
invoker.destroy();
exporter.unexport();
}
是不是很奇怪?我们一般使用的时候调用路径都是严格按照在@Path 注解上的路径来的,原始的 dubbo 测试用例中的路径是这样的:
rest://127.0.0.1:5342/DemoService/rest/say?version=1.0.0&interface=org.apache.dubbo.rpc.protocol.rest.DemoService
经过测试,发现这两种方式都能调用通,当时我就懵逼了,以为 dubbo 中出现了 bug.
于是开始调试代码,发现 RestProtocol 在调用 refer 方法的时候,使用了代理,这个和我们以前的那种方式不同,以前我也使用过 resteasy,比如说我要访问 http://abc/def,直接这么调用就好了,但是 dubbo 在集成 resteasy 的时候是不一样的.
下面说下结论吧. 经过调试得出的结论是和 /DemoService1 还是 DemoService2,还是3没有关系,最主要的还是 @Path 上的注解. 但是有人是不是想说我们调用的路径中没有 DemoService 啊?那它是如何完成调用的了?
答案还是代理,代理会在最终发起 http 请求的时候,使用的 path 是这样的:
http://127.0.0.1:5342/DemoService1/rest/say/DemoService/say
上面的 url 后面的一节是 resteasy 通过代理自动的帮我们干的,到此就回到了以前使用 resteasy 的流程了.
后面说下比如说我们发起一个调用的时候,例如:
http://127.0.0.1:5342/DemoService1/rest/say/DemoService/say
的时候,resteasy 具体帮我们干了啥
1.首先,在部署的时候,解析实现类实现的接口上的注解,将路径和方法一一对应.
2.在发起http 请求后,通过路径去匹配对应的方法,并完成调用.
其实这一套思路和 dubbo 中的 http 协议本质上是一样的,只是说有人喜欢在骨架上贴上不同的膜.
public void testRestProtocol() {
URL url = URL.valueOf("rest://127.0.0.1:5342/DemoService1/rest/say?version=1.0.0&interface=org.apache.dubbo.rpc.protocol.rest.DemoService");
DemoServiceImpl server = new DemoServiceImpl();
ProviderModel providerModel = new ProviderModel(url.getPathKey(), server, DemoService.class);
ApplicationModel.initProviderModel(url.getPathKey(), providerModel);
Exporter<DemoService> exporter = protocol.export(proxy.getInvoker(server, DemoService.class, url));
Invoker<DemoService> invoker = protocol.refer(DemoService.class, url);
Assertions.assertFalse(server.isCalled());
DemoService client = proxy.getProxy(invoker);
String result = client.sayHello("haha");
Assertions.assertTrue(server.isCalled());
Assertions.assertEquals("Hello, haha", result);
invoker.destroy();
exporter.unexport();
}
是不是很奇怪?我们一般使用的时候调用路径都是严格按照在@Path 注解上的路径来的,原始的 dubbo 测试用例中的路径是这样的:
rest://127.0.0.1:5342/DemoService/rest/say?version=1.0.0&interface=org.apache.dubbo.rpc.protocol.rest.DemoService
经过测试,发现这两种方式都能调用通,当时我就懵逼了,以为 dubbo 中出现了 bug.
于是开始调试代码,发现 RestProtocol 在调用 refer 方法的时候,使用了代理,这个和我们以前的那种方式不同,以前我也使用过 resteasy,比如说我要访问 http://abc/def,直接这么调用就好了,但是 dubbo 在集成 resteasy 的时候是不一样的.
下面说下结论吧. 经过调试得出的结论是和 /DemoService1 还是 DemoService2,还是3没有关系,最主要的还是 @Path 上的注解. 但是有人是不是想说我们调用的路径中没有 DemoService 啊?那它是如何完成调用的了?
答案还是代理,代理会在最终发起 http 请求的时候,使用的 path 是这样的:
http://127.0.0.1:5342/DemoService1/rest/say/DemoService/say
上面的 url 后面的一节是 resteasy 通过代理自动的帮我们干的,到此就回到了以前使用 resteasy 的流程了.
后面说下比如说我们发起一个调用的时候,例如:
http://127.0.0.1:5342/DemoService1/rest/say/DemoService/say
的时候,resteasy 具体帮我们干了啥
1.首先,在部署的时候,解析实现类实现的接口上的注解,将路径和方法一一对应.
2.在发起http 请求后,通过路径去匹配对应的方法,并完成调用.
其实这一套思路和 dubbo 中的 http 协议本质上是一样的,只是说有人喜欢在骨架上贴上不同的膜.
上一篇: Tensorflow实现 Dropout
下一篇: dubbo 监控中心源码分析