强哥叨逼叨

点击关注强哥，查看更多精彩文章呀 哈喽，大家好，我是强哥。 大家知道，强哥之前有一篇推文Dubbo也支持基于应用粒度的服务发现机制啦中说到，Dubbo2.x版本目前大都还是使用接口粒度的服务发现机制。 强哥的朋友最近就遇到一个问题。有如下情况：代码仓库中有一套使用Dubbo2.x编写的微服务代码CodeW，其中有一个接口方法algoCompute(Map map)，这个方法可以根据传入的Map内部信息的不同，加载不同的算法模型进行计算，以此来达到同一套代码可以根据请求参数的不同处理不同需求的目的。

查看强哥更多最新文章，点我 大家都知道，Spring Cloud和Dubbo早期版本在服务发现以及服务间通信方式上有很大的不同：Spring Cloud使用的是应用粒度的服务发现机制，而Dubbo则使用的是接口粒度的服务发现机制；Spring Cloud使用的是Http的协议进行服务间通信，而Dubbo则使用的是RPC的方式进行通信。 而这两点，在很大程度上，影响了这两大微服务框架的使用性和扩展性。 服务间的通信方式这方面，强哥认为HTTP和RPC方式各有自己的应用场景和优缺点。新版本Dubbo3定义

我们在使用 Dubbo 调用远程服务时，在不设置Service属性async=true时，默认情况下，使用的是一种阻塞式调用方式，即 Consumer 端代码发起请求后，一直阻塞等待，直到 Provider 端返回为止。 但是，由于 Dubbo 底层基于 Netty 发送网络请求，而Netty又是一个异步事件驱动的模型，所以理论上来说，请求应该是一个异步的过程。不会像上面所说的Consumer需要阻塞等待才对。 那么为什么我们使用Dubbo的时候，它的RPC调用会是同步的呢？ 其实很容易想到，既然底层

转自：https://www.cnblogs.com/binarylei/p/14110008.html 目录 Dubbo 架构演进：从 RMI 到 Dubbo 1. 自定义 RPC 2. RMI 架构 2.1 整体架构 2.2 RPC 调用 3. Dubbo 架构 3.1 整体架构 3.2 RPC 调用 3.3 服务治理 4. 总结时刻 推荐阅读 谈谈你对 Dubbo 的认知？对于这个问题，你是怎么回答的呢？ 我们知道 Dub.