阿里巴巴Dubbo实现的源码分析

好像不太完整阿
应该是这样的

AbstractProxyInvoker---(这里的URL是Registry URL,里面放置了 Provider URL )---RegistryProtocol--(export)-- 生成InvokerDelegete --(这里的URL 是 从Register URL 取出Provider URL)-- Provider Protocol--(export)-- Exporter

字节码生成的AdaptiveClass 严重依赖URL（主要是依赖URL里面的 protocol）。。看起来不那么优雅。

ExtensionLoader 作为 系统核心Loader模式，不应该过分只为Protocol 服务。

其实，写这篇文章主要是对Dubbo这个团队开源态度的高度认可，大家可以看看它官网分享出来的资料，哪怕你不用Dubbo，你都可以从中受益匪浅。看了大家的回帖，对Dubbo应该是非常关注的，很多朋友研究的已经非常深入了。我个人觉得一个好的开源项目，社区的建设是非常重要的，只有不断有新生力量的进入，产品才会持续的发展。Dubbo值得大家为它做点事情，编写文档、开发新功能、修复bug、提交bug任何方式的都可以。

赞，我在考虑jms&activemq protocol，
但明显，jms跟rpc还是差别比较大的。

写的很好，非常感谢你对Dubbo的支持。