RPC、Dubbo

RPC、Dubbo

底层实现 jdk动态代理

通信双方需要使用的接口

分布式SOA架构涉及到了dubbo，它有2部分，服务的提供方和服务的消费方，官方推荐用zookeeper作为一个注册中心

使用zookeeper的原因

服务命名、服务配置化、负载均衡、分布式锁

首先服务的提供方暴露出他所提供的服务接口，提供给zookeeper注册中心进行注册进行管理，当消费方需要使用的时候，

它会到zookeeper中查询相应的服务接口是否存在，如果找到了，那么zookeeper注册中心把服务消息的提供方的具体IP地址返回给服务的消费方，

然后由你的服务的消费方直接去服务的提供方上去使用，原理就是这么个过程。

dubbo除了可以提供服务之外，还可以实现软负载均衡

dubbo RPC是dubbo体系中最核心的一种高性能、高吞吐量的远程调用方式，我喜欢称之为 多路复用的TCP长连接调用 ，简单的说：

特别适合高并发、小数据的互联网场景

长连接：避免了每次调用新建TCP连接，提高了调用的响应速度

多路复用：单个TCP连接可交替传输多个请求和响应的消息，降低了连接的等待闲置时间，从而减少了同样并发数下的网络连接数，提高了系统吞吐量。

在dubbo RPC中，同时支持多种序列化方式，例如：

dubbo序列化：阿里尚未开发成熟的高效java序列化实现，阿里不建议在生产环境使用它

hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化，而是阿里修改过的hessian lite，它是dubbo RPC默认启用的序列化方式

json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。

java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。