本篇文章是Dubbo源码分析的第一讲，主要介绍Dubbo源码中重要的组件。还是小编的风格,以提问的方式讲解。各位看官可以自行跳跃,找到自己想要的部分。为什么RPC要单独一节说呢? 因为感觉现在网络上关于RPC的描述都是有问题的。既然我们是要对Dubbo做全面的剖析，而Dubbo又是一款RPC框架，那么我们必须要对RPC有一个正确的认识。在这里小编谈谈我的理解!

什么是RPC?

RPC到底是风格还是协议? 这个问题不好回答，小编把两种的论点和论据都描述出来，并给出自己的理解，

但是最终由你来判断! 也可以在下面提出意见,我们共同探讨交流。

上图示百度百科里面的描述,RPC（Remote Procedure Call）—远程过程调用，很多网上文章都是说rpc是一种协议

那么RPC到底是一种协议吗? 观点一(小编的观点) 观点二(网络上大多数描述)

观点一:

RPC 风格对应的是 Restful风格

出发点: RPC 的含义来看(远程过程调用)

RPC全称远程过程调用,认为只要实现远程调用即可，实现的方式可以是HTTP基于应用层的协议，也可以是Socket基于传输层协议

因为Socket编程是比较复杂的，所以Dubbo在Socket编程方面是用的Netty来实现。同样也可以用WebService来实现，所以我认为RPC只是一种风格。

举一个例子: Google的grpc框架，底层就是基于Http2.0 来实现

观点二

认为RPC是一个协议的是这样理解的

出发点: OSI网络模型

HTTP基于应用层

RPC只是基于传输层

看了这两个观点相信你应该也有自己的判断,再后面的章节,小编会讲到Dubbo到底是如何用Netty和Http来实现远程调用的。

这点先不要着急。先对RPC有一个自己的认识。

Dubbo-RPC和传统服务的区别是什么?

传统: 调用远程服务,需要开发者①先创建Http客户端连接远程服务器，②封装请求参数 ③收到处理结果

Dubbo-RPC:

因为Dubbo是配置Spring来使用的，所以只要配置好了，远程服务的调用，就可以像本地服务那样调用。

就像本地服务一样调用。直接从IOC容器拿出来，就可以用。

看了上面的例子，应该都了解了。那么我们在分析分析那么的优劣点。

Dubbo分析

因为Dubbo默认是基于Netty来实现，基于传输层协议，所以性能比传统方式自然强了很多。单单从这点看Dubbo和Http没有可比性，碾压的优势。但是Dubbo配置的比较多，好再是只要配置一次就可以了。不过唯一不好的是，对客户端和服务端都有要求要求都要使用Dubbo来通讯，而且都是Java服务(现在也可以通过中间件，来支持其他语言)。

传统SpringMVC分析

传统方式理论上在Http1.x的时代，每一次方法的调用，都要重新创建一次Http客户端，一次http请求(三握四挥)不过基于http的服务，是没有任何约束的，没有语言的约束。这也是为什么小公司都选择传统方式的原因。不用Dubbo还有一个重要的原因是SpringBoot和SpringCloud都非常好用简单，Spring全家桶提供了一系列的解决方案，从,集群性能,容错,负载,监控都有方便的解决方案（想了解SpringBoot和Spring的小伙伴可以看小编其他文章）。

附上SpringBoot博客地址: https://blog.springlearn.cn/categories/Spring-Boot/