一、Dubbo的调用流程分析
Dubbo本身主要支持两种调用流程，包括直连提供者和基于注册中心的调用。这两种哪种重要肯定不需要我再声明了 o(￣︶￣)o ，我们一定是基于注册中心的使用方式了， 不过大家是否真的理解基于注册中心的使用方式呢？
首先，我们先来看一下直连提供者是个什么样子？
上述内容是直接截取的Dubbo官方网站的内容，从内容中不难看出，直连提供者一般都是在开发和测试环境下使用，可是为什么呢？ 这件事情我们姑且存个疑问，后面再给大家揭开面纱。现在我们主要看一下内容的图片，可能略微有些凌乱，没关系，我们用Visio图来给他翻译一下。
我们将所有的配置和实现细节过滤，其实他就只是说明一件事， Consumer明确知道Provider的家庭住址，稍不顺心就直接抄家伙去Provider家去找它麻烦，这其实就是直连提供者。
那么问题就来了，在我们的分布式环境中，直连提供者会带来很大的问题 - 动态扩容，设想我们如果每上线一个新的服务都要让Consumer知道producer的地址，是一个非常麻烦的事情，实现的不好的就是将这些写在代码里了。实现的灵活点的会将地址写在配置文件里，但无论哪种形式，都需要重启所有Consumer，是不是很崩溃，所以我们说，这种实现仅仅适用于测试和开发环境。
其次，我们来了解一下注册中心的形式
上图就是Dubbo官方给出的架构图，对这个图建议牢记，真的有面试官会问哦
其实上图就是对直连提供者的演进或补充，我们先来解释一下这个流程：【按照图中标注的1,2，3,4，5,的顺序哦】
0、Container是Dubbo提供的容器，用于承载Provider，这个我们可以暂时忽略。
1、Provider会在启动时，将自己的“家庭地址”注册在注册中心里。
2、Consumer这个私家侦探，会在注册中心留下眼线【subscribe】
3、当注册中心出现变化时，就通知【notify】相关的Consumer，Consumer会将这些地址缓存在本地中，产生一个Provider住址列表
4、当Consumer需要时，就会根据本地缓存的住址列表，抄家伙去对应的家庭住址找Provider的麻烦
5、dubbo本身是有监控的【Monitor】，provider和consumer都会将一些统计信息进行监控。
刨除0和5我们不管，其实我们可以很容易的发现，无论是直连提供者还是注册中心的形式，最终Consumer都会根据详细住址找到的Provider，只不过是获取家庭住址的形式变化了。
Dubbo的注册中心最常见的是Zookeeper和Redis这些常见的分布式中间件，同时Dubbo也支持自定义扩展中心和多注册中心的配置。详情可以参见以下内容：
https://dubbo.gitbooks.io/dubbo-user-book/content/demos/multi-registry.html
https://dubbo.gitbooks.io/dubbo-dev-book/content/impls/registry.html
二、Dubbo协议剖析
Dubbo的协议部分已经被大家总结过很多遍，笔者在这里就不重复造车轮的事了，推荐搭建看一篇博客：
https://blog.csdn.net/fuyuwei2015/article/details/72848310/
但是如果对底层没什么期待的童鞋，可以直接看下面的总结性内容：
Dubbo框架默认支持的阿里的dubbo协议，同时还支持包括rmi、hessian、http、webservice、thrift、redis在内的多种协议，下面我们来了解一下这些协议的区别与适用场景。
如果觉得上面的表单过于难理解，可以忽略 O(∩_∩)O哈哈~，我们直接来点干的。
Dubbo协议特点： 传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串，基于以上描述，我们一般建议Dubbo用于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
RMI协议特点： 传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。基于以上描述，我们一般对传输管道和效率没有那么高的要求，同时又有传输文件这一类的要求时，可以尝试采用RMI协议。【不过笔者不太喜欢这个，o(￣︶￣)o】
Hessian协议特点： 传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。比较适用于需同时给应用程序和浏览器JS使用的服务，Hessian协议的相关内容与HTTP基本差不多，这里就不再赘述了。
WebService协议特点： 基于CXF的frontend-simple和transports-http实现，适用于系统集成，跨语言调用。 不过如非必要，强烈不推荐使用这个方式，WebService是一个相对比较重的协议传输类型，无论从性能、效率和安全性上都不太能满足微服务的需要，如果确实存在异构系统的调用，建议可以采用其他的形式。
其余的memcached、Redis的协议之类的，使用的场景比较少，在这里就不扩展了，大家可以参考上述的博客文件进行查看和测试。
以上，就是本次与大家分析讨论的内容，大家如果有什么意见，可以随时联系我，希望对大家能产生一些帮助。
另外，Dubbo的实战课程刚刚上线，会涉及到Dubbo和微服务的诸多内容，包括异步调用、分布式事务、全链路监控以及与Dubbo、微服务相关的面试题等，也希望可以给大家带来一些收获。
《打造仿猫眼项目 以Dubbo为核心解锁微服务》
再次感谢大家。
随时随地看视频
