战斧的博客

前面我们学习了很多理论知识，但一切理论都是为了实践。Dubbo作为一个框架当然有很多配置点，其中有些配置不起眼，但却很重要。笔者曾经分享过一起内存溢出的问题，其中就有接口超时时间配置得太长的原因，因为数据量比较大，三方接口迟迟无法返回结果。而超时时间又很长，最终大量线程阻塞在调用上，资源无法释放，造成内存溢出。由此可见，合理的参数配置是多么的重要

经过前面一系列的铺垫，今天终于迎来Dubbo最最本质的功能了，即服务调用。前面我们不止一次的说过，Dubbo不满足于仅仅作为一个RPC框架。如图，我们甚至可以在官网看见其对自身的定义然而前面不管是服务暴露，还是服务引用，其实都算RPC的组成部分。而Dubbo真正的花活，在服务调用这里开始展现，亦是其自诩超越普通RPC的地方，老规矩，我们先自己构思几个问题，带着问题去学习：服务调用的底层是网络通信，这部分是靠什么实现的?Dubbo超越普通RPC框架的底气究竟是什么?

我们在Dubbo与SpringCloud对比的那一期就说过，Dubbo并不满足于作为RPC框架，除了RPC所需要的内容，还提供了如服务治理等额外的支持。但是无奈，很多人对Dubbo的印象就是RPC框架，因为其核心还是围绕RPC进行的。上一篇我们讲了服务暴露，今天来学习RPC桥梁的另一端：消费者，也就是服务的引用。

今天开始，将正式的进入Dubbo 核心功能的掌握与学习，Dubbo的最核心功能是什么？自然是其RPC功能，而该功能其实分为三个方面：1.服务暴露2.服务引用3.服务调用三者分别专注于服务提供者、服务消费者、服务调用过程。服务暴露有几种？分别是怎么实现的？远程暴露支持什么？注册中心如果服务提供者宕机了，注册中心如何应对？

我们之前介绍了RabbitMQ的五种模型（详见上方系列文章《RabbitMQ灵活运用，怎么理解五种消息模型》），即简单、轮询、主题、发布/订阅、路由、主题五种模式。除此之外，rabbitMQ还提供了一种 RPC 模式，这种模式是怎么回事？真的好用吗？一起来了解下。