Dubbo 、Springcloud? 这两有关系？
前言
提到Dubbo，很多人都并不陌生，也是这些年来的热点面试内容。笔者也有很深的印象，在n年前的一场面试中，面试官问了一个问题：请至少说出Dubbo的六个包名，笔者当时虽然看过部分源码，但从未关注过包名，内心五味杂陈，当场就懵了。当然了，除开这种角度奇怪的提问，Dubbo也有一些看起来比较"正常"的面试题，比如著名的:
Dubbo 和 Springcloud 有什么区别？
时至今日，这个问题已经成了面试八股之一，我们就从这开始，讲述一下Dubbo 这个框架吧，喜欢的别忘记关注 + 收藏
一、RPC 框架的概念
1. 什么是RPC框架
我们在 《真的好用吗？鲜有人提的 RabbitMQ-RPC模式》 一文中，其实提到过RPC 的概念，今天我们正式介绍下所谓的RPC框架:
RPC（Remote Procedure Call - 远程调用） 是一种客户端和服务器端之间远程通信的模式，通过这种模式可以使得不同的进程、甚至不同的机器之间可以像调用本地函数一样调用远程函数。RPC框架就是一套实现RPC协议的软件框架，用于简化远程调用的过程，让开发者可以更方便地进行远程调用操作。
RPC框架通常包含以下组件：
- 远程调用接口定义：定义远程调用的函数、参数和返回值，通常使用IDL（接口定义语言）进行定义。
- 远程调用代理：用于将本地调用转化为远程调用，同时负责处理对远程调用的参数的序列化和反序列化。
- 传输协议：用于在客户端和服务器之间传输远程调用的请求和响应，通常使用TCP或HTTP协议。
- 服务注册与发现：用于将服务注册到注册中心，并让客户端发现可用的服务。
- 负载均衡：用于管理多个服务提供者，并将请求均衡地分配给它们，以提高系统的稳定性和可用性
2. RPC 和 普通通信 的区别
为什么我们会有RPC 这种说法，”前台访问后台“ 这种模式算不算 RPC？
确实，一般前台调用后台也是将请求和参数，通过HTTP请求协议传输到后台，后台进行处理后返回结果。
从流程看二者较为相像，但是RPC其实是一种思想，集中在后台服务之间的调用，主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。从这个角度看，就不是所有的调用都能叫做RPC调用了。
而且两者一般有以下区别：
-
技术实现方式不同：
RPC是一种远程调用的方式，通常使用二进制协议（如Protocol Buffers、Thrift等）或者文本协议（如JSON、XML等）进行数据传输。而前台访问后台通常使用HTTP协议进行数据传输。 -
调用方式不同：
RPC的调用方式类似于本地方法调用，客户端通过编程语言提供的API直接调用服务端的方法。而前台访问后台通常是通过发送HTTP请求来访问服务器的接口，接口返回的数据可以通过AJAX等方式进行处理。 -
服务定位方式不同：
RPC通常使用服务地址（IP地址+端口号）来定位服务，客户端需要知道服务地址才能调用服务。而前台访问后台通常使用URL地址来定位服务，客户端可以通过URL地址来访问服务器的接口。 -
数据传输方式不同：
RPC通常使用高效的二进制协议或者文本协议进行数据传输，可以减少数据传输时间和网络带宽，适合在高并发或者低带宽的环境下使用。而前台访问后台通常使用HTTP协议进行数据传输，数据传输效率较低，不适合在高并发或者低带宽的环境下使用。
需要注意的是，还是那句话，RPC是手段，更是思想，并不规定其具体的实现方式，上述也只是通常情况下RPC的特征。
二、常用 RPC 框架
1. Dubbo
阿里巴巴开源的高性能、轻量级的RPC框架，支持多种协议和序列化方式，并提供了丰富的服务治理能力。
特点：轻量级、高性能、多协议、多语言、丰富的治理能力
2. gRPC
Google开源的高性能、跨语言的RPC框架，采用Protocol Buffers作为数据传输格式，支持多种语言和多种平台。
特点：跨语言、高性能、基于Protocol Buffers数据格式、支持多种平台、支持流式数据传输
3. Thrift
Facebook开源的高性能、跨语言的RPC框架，支持多种协议和多种语言，在分布式系统、大规模数据处理等领域得到广泛应用。
特点：跨语言、高性能、多协议、多语言、支持异步调用、支持服务发现和负载均衡
4. Feign
Netflix的轻量级HTTP请求框架，用于简化服务之间的调用。使用注解方式定义服务接口，自动集成了Ribbon负载均衡和Hystrix熔断器。通过声明式的方式，简化了服务调用的代码编写。
特点：高性能、基于接口定义、多种编码方式、集成负载均衡、支持断路器
三、dubbo 与 Springcloud
1. Dubbo 的模型
我们再来看一张图，这是经典的RPC原理图，这张图解释了RPC的调用流程，所以按理说，如果不考虑协议层的内容，这是很容易实现的，那为什么还会有像Dubbo这样专门的RPC框架呢
其实，简单的RPC是容易实现的，但也仅有最基础的功能，我们在远程调用时往往还会遇到很多问题，比如
- 调用者先部署，怎么能拿到被调用方的IP并配置呢
- 调用的序列化协议、传输协议怎么确定
- 被调用方是集群，该怎么处理调用的逻辑
- 被调用方宕机，怎么自动切换另一台
- 同步或非同步的调用都需要自己实现
而 Dubbo 则支持多协议、多语言。同时选择引入了注册中心，使得调用方和被调用方能互相得到对方整体的情况
而且其内部设定了容错机制，负载均衡机制，使得调用可靠性大大增强，开发者省心很多，下图就是其内部实现的模型，这张图以后在Dubbo专栏还会多次出现，所以暂时看不明白也不用担心。
我们再来看下那个让我记了N年的问题：Dubbo的六个包名，其实当时就可以回答RPC层级下的几个级别就可以了
本次我们不展开讲，你只需要知道dubbo是一款帮助你实现RPC功能的省心框架即可。
2. Springcloud
如果你之前接触过SpringCloud，应该能明白它与Spring家族其他产品的显著不同，打个比方，如果说 Spring或 SpringBoot 是住房设计图，那SpringCloud就是一套城市指导方案，包含住房及道路设计、人员管理、安全控制等等。其官方介绍如下
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
Spring Cloud 为开发人员提供了在分布式系统中快速构建一些常见模式的工具（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态）。分布式系统的协调导致了样板模式，使用 Spring Cloud 开发人员可以快速建立实现这些模式的服务和应用程序。它们可以在任何分布式环> > 境中很好地工作，包括开发人员自己的笔记本电脑、裸机数据中心和托管平台，如Cloud Foundry。
Spring Cloud 主要包含这些特性：
- 分布式/版本化配置
- 服务注册和发现
- 路由
- 服务到服务呼叫
- 负载平衡
- 断路器
- 全局锁
- 领导层选举和集群状态
- 分布式消息传递
如果你想了解更多，可以直接点击Spring-Cloud官网
3. dubbo 与 Springcloud 的区别
让我们回到开篇提到那个常见的面试题：
Dubbo 和 Springcloud 有什么区别？
在论坛看过很多人提出这个问题，评论区一般则是对这个问题嗤之以鼻，这是为什么呢？ 因为本质上 dubbo 与 Springcloud 并不在一个赛道上，就好像问 地球 和 M78星云 有什么区别一样。
Spring Cloud是一个开源的分布式系统开发框架，它提供了一系列的工具和组件，用于构建和管理分布式应用程序。然而，Spring Cloud本身并不是一个用于实现RPC（远程过程调用）的框架。
当然，两者并不是毫无联系，Spring Cloud 推荐将 Netflix Feign 作为RPC框架配合使用，这倒是一个RPC框架，可以拿来与 Dubbo 作对比。当然，Spring Cloud也可以配合Dubbo一起使用，使得服务之间的调用更加方便和高效。
那么，如果真有人问出了这种问题，笔者还是建议不必嗤笑，不要触面试官的霉头，还是该认真地回答:
答：两者关注的点不一样，Dubbo 原本是专业的RPC框架，关注高性能的RPC调用；Spring Cloud则是致力于提供大规模微服务架构方案，并非一个单一的组件。硬要对比的话，SpringCloud框架囊括的功能更多，其中包括了RPC功能，而除了RPC，SpringCloud还涉及网关、分布式配置、消息总线等模块，这些则是Dubbo所不具备的。
而关于RPC功能实现，官方推荐的是使用Feign组件
但我们也要注意到，Dubbo本身的功能十分强劲，其实已经超出了一般RPC框架的范畴，甚至在官方文档中，我们能看见其不满目前的RPC框架称谓，而自称为一款微服务开发框架
Dubbo自带的服务发现、限流降级的能力也确实和SpringCloud里的内容有所重合，从这个角度来说，实际上Dubbo已经同时完成了SpringCloud内多个组件的功能。所以，现在SpringCloud下有Spring Cloud Alibaba方案，适用于一站式的分布式开发，其中就使用的dubbo来作为核心组件