Dubbo 基础

RPC远程过程调用

RPC协议(Remote Procedure Call Protocol )，远程过程调用协议 ,它是一种通过网络从远程计算机程序上请求服务 , 而不需要底层网络技术的协议 .RPC协议定义了传输的方式（http协议）和传输数据格式（调用哪个方法）。

RPC OVER HTTP   ，RPC底层使用HTTP传输数据

​ RPC 采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

RPC与HTTP , TCP , UDP ,Socket的区别

​ TCP/UDP : 都是传输协议，主要区别是 tcp 协议连接需要 3 次握手，断开需要四次挥手， 是通过流来传输的，就是确定连接后，一直发送信息，传完后断开。udp 不需要进行连接， 直接把信息封装成多个报文，直接发送。所以 udp 的速度更快写，但是不保证数据的完整 性。

​ Http：超文本传输协议是一种应用层协议，建立在 TCP 协议之上

​ Socket：是在应用程序层面上对 TCP/IP 协议的封装和应用。其实是一个调用接口，方 便程序员使用 TCP/IP 协议栈而已。程序员通过 socket 来使用 tcp/ip 协议。但是 socket 并不 是一定要使用 tcp/ip 协议，Socket 编程接口在设计的时候，就希望也能适应其他的网络协 议。

​ RPC : 是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协 议。 所以 RPC 的实现可以通过不同的协议去实现比如可以使 http、RMI 等。

RPC的运行流程

​ 首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立 TCP 连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉， 也可以是长连接，多个远程过程调用共享同一个连接。

​ 第二，要解决寻址的问题（注册中心），也就是说，A 服务器上的应用怎么告诉底层的 RPC 框架，如 何连接到 B 服务器（如主机或 IP 地址）以及特定的端口，方法的名称名称是什么，这样才 能完成调用。比如基于 Web 服务协议栈的 RPC，就要提供一个 endpoint URI，或者是从 UDDI(一种目录服务，通过该目录服务进行服务注册与搜索)服务上查找。如果是 RMI 调用的 话，还需要一个 RMI Registry 来注册服务的地址。

​ 第三，当 A 服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协 议如 TCP 传递到 B 服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成 二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二 进制发送给 B 服务器。

​ 第四，B 服务器收到请求后，需要对参数进行反序列化，恢复为内 存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。 第五，返回值还要发送回服务器 A 上的应用，也要经过序列化的方式发送，服务器 A 接到后，再反序列化，恢复为内存中的表达方式，交给 A 服务器上的应用

Dubbo 

Dubbo 是由阿里巴巴开源的一个高性能、基于 Java 开源的远程调用框架。正如在许多 RPC 系统中一样，Dubbo 是基于定义服务的概念，指定可以通过参数和返回类型远程调用的方法。在服务器端，服务器实现这个接口，并运行一个 Dubbo 服务器来处理客户端调用。 在客户端，客户机有一个存根，它提供与服务器相同的方法。（使用ZK做注册中心）

​ Dubbo 提供三个核心功能：基于接口的远程调用、集群容错和负载均衡，以及服务的自动注册与发现。Dubbo 框架广泛的在阿里巴巴内部使用，以及京东、当当、去哪儿、考拉等都在使用。

​ 简单的说, dubbo就是个服务框架 ,如果没有分布式的需求 ,其实是不需要用的.只有在分布式的时候, 才有dubbo这样的分布式服务框架的需求 .并且本质上是个服务可调的东西 ,说白了就是个远程服务调用的分布式框架(告别Web Service模式中的WSdl ,以服务者消费者的方式在dubbo上注册)。

DUBBO中文文档

Dubbo 的服务治理图

 

 

Dubbo 技术架构

 

 

节点角色说明：

节点	角色说明
Provider	暴露服务的服务提供方
Consumer	调用远程服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心
Container	服务运行容器

看了这几个概念后似乎发现，其实 Dubbo 的架构也是很简单的（其实现细节是复杂的），为什么这么说呢，有没有发现，其实很像生产者-消费者模型。只是在这种模型上，加上了注册中心和监控中心，用于管理提供方提供的url，以及管理整个过程。

那么，整个发布-订阅的过程就非常的简单了。

• 启动容器，加载，运行服务提供者。
• 服务提供者在启动时，在注册中心发布注册自己提供的服务。
• 服务消费者在启动时，在注册中心订阅自己所需的服务。

如果考虑失败或变更的情况，就需要考虑下面的过程。

• 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 服务消费者，从本地服务提供者地址列表缓存中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用，容错，负载均衡。
• 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

服务治理中心：可以看到所有的服务提供者信息和提供的API，所有的服务消费者信息和消费的API，以及进行Dubbo服务调用。

 

Dubbo的功能：