rpc框架有哪些（rpc框架都有哪些rmi dubbo）

本文目录

• rpc框架都有哪些rmi dubbo
• 谁能用通俗的语言解释一下什么是RPC框架
• 分析JAVA中几种常用的RPC框架
• 什么是rpc框架，及其作用，在php方向上的使用

rpc框架都有哪些rmi dubbo

Dubbo分层

config（配置层 ）

proxy（服务代理层）

registry（ 注册中心层）

cluster（ 路由层）

monitor（ 监控层）

protocol（ 远程调用层）

exchange（ 信息交换层）

transport（ 网络传输层）

serialize（ 数据序列化层）

对外配置接口
以ServiceConfig, ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类
Javassist ProxyFactory
Jdk ProxyFactory
服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton
以ServiceProxy为中心，扩展接口为ProxyFactory
选择

Zookeeper

Redis

Multicast

Simple

支持基于网络的集群方式，有广泛周边开源产品，建议使用dubbo-2.3.3以上版本（推荐使用）
依赖于Zookeeper的稳定性
支持基于客户端双写的集群方式，性能高
要求服务器时间同步，用于检查心跳过期脏数据
去中心化，不需要安装注册中心
依赖于网络拓普和路由，跨机房有风险
Dogfooding，注册中心本身也是一个标准的RPC服务
没有集群支持，可能单点故障
封装服务地址的注册与发现
以服务URL为中心，扩展接口为RegistryFactory, Registry, RegistryService
选择

Spring

Jetty

Log4j

自动加载META-INF/spring目录下的所有Spring配置
启动一个内嵌Jetty，用于汇报状态
大量访问页面时，会影响服务器的线程和内存
自动配置log4j的配置，在多进程启动时，自动给日志文件按进程分目录
用户不能控制log4j的配置，不灵活
条件路由

脚本路由

基于条件表达式的路由规则，功能简单易用
有些复杂多分支条件情况，规则很难描述
基于脚本引擎的路由规则，功能强大
没有运行沙箱，脚本能力过于强大，可能成为后门
Random

RoundRobin

LeastActive

ConsistentHash

随机，按权重设置随机概率（推荐使用）
在一个截面上碰撞的概率高，重试时，可能出现瞬间压力不均
轮循，按公约后的权重设置轮循比率
存在慢的机器累积请求问题，极端情况可能产生雪崩
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差，使慢的机器收到更少请求
不支持权重，在容量规划时，不能通过权重把压力导向一台机器压测容量
一致性Hash，相同参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动
压力分摊不均
Failover

Failfast

Failsafe

Failback

Forking

Broadcast

失败自动切换，当出现失败，重试其它服务器，通常用于读操作（推荐使用）
重试会带来更长延迟
快速失败，只发起一次调用，失败立即报错,通常用于非幂等性的写操作
如果有机器正在重启，可能会出现调用失败
失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作
调用信息丢失
失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作
不可靠，重启丢失
并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作
需要浪费更多服务资源
广播调用所有提供者，逐个调用，任意一台报错则报错，通常用于更新提供方本地状态
速度慢，任意一台报错则报错
封装多个提供者的路由及负载均衡，并桥接注册中心
以Invoker为中心，扩展接口为Cluster, Directory, Router, LoadBalance
Cluster选择

Router选择

路由规则

容器

RPC调用次数和调用时间监控
以Statistics为中心，扩展接口为MonitorFactory, Monitor, MonitorService
Dubbo协议

Rmi协议

Hessian协议

连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
适用场景：常规远程服务方法调用
采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用）
适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
Dubbo缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低
Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接
为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护
在大文件传输时，单一连接会成为瓶颈
总结

可与原生RMI互操作，基于TCP协议
偶尔会连接失败，需重建Stub
参数及返回值需实现Serializable接口
参数及返回值不能自定义实现List, Map, Number, Date, Calendar等接口，只能用JDK自带的实现，因为hessian会做特殊处理，自定义实现类中的属性值都会丢失
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件
适用场景：页面传输，文件传输，或与原生hessian服务互操作
提供者用Dubbo的Hessian协议暴露服务，消费者直接用标准Hessian接口调用
或者提供方用标准Hessian暴露服务，消费方用Dubbo的Hessian协议调用
基于Hessian的远程调用协议
可与原生Hessian互操作，基于HTTP协议
需hessian.jar支持，

谁能用通俗的语言解释一下什么是RPC框架

早期单机时代，一台电脑上运行多个进程，大家各干各的，老死不相往来。假如A进程需要一个画图的功能，B进程也需要一个画图的功能，程序员就必须为两个进程都写一个画图的功能。这不是整人么？于是就出现了IPC（Inter-process communication，单机中运行的进程之间的相互通信）。OK，现在A既然有了画图的功能，B就调用A进程上的画图功能好了，程序员终于可以偷下懒了。

到了网络时代，大家的电脑都连起来了。以前程序只能调用自己电脑上的进程，能不能调用其他机器上的进程呢？于是就程序员就把IPC扩展到网络上，这就是RPC（远程过程调用）了。现在不仅单机上的进程可以相互通信，多机器中的进程也可以相互通信了。

要知道实现RPC很麻烦呀，什么多线程、什么Socket、什么I/O，都是让咱们普通程序员很头疼的事情。于是就有牛人开发出RPC框架（比如，CORBA、RMI、Web Services、RESTful Web Services等等）。

OK，现在可以定义RPC框架的概念了。简单点讲，RPC框架就是可以让程序员来调用远程进程上的代码一套工具。有了RPC框架，咱程序员就轻松很多了，终于可以逃离多线程、Socket、I/O的苦海了。

至于最近Java中流行的Netty，没玩过。但是大致了解过，Netty、Mina是游戏行业做服务器开发的Java程序员用的比较多的PRC框架（我们学生主要是Java方向的，有不少人毕业后从事游戏开发）。据说互联网公司用的也比较多。这两行业都有高并发量的、长连接、分布式、异步通讯、大数据量等特点。Netty这种RPC框架封装和优化了Java NIO和异步网络编程的一些繁琐的细节，一方面可以让开发者专注于业务逻辑的实现，一方面只需要调用Netty封装的API就可以很快编写出高性能的服务器。

分析JAVA中几种常用的RPC框架

HTTP/1.1 协议规定的 HTTP 请求方法有 OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT 这几种。其中，POST 一般用来向服务端提交数据，本文主要讨论 POST 提交数据的几种方式。
我们知道，HTTP 协议是以 ASCII 码传输，建立在 TCP/IP 协议之上的应用层规范。规范把 HTTP 请求分为三个部分：状态行、请求头、消息主体。类似于下面形式：
《method》 《request-URL》 《version》 《headers》 《entity-body》
协议规定，POST 提交的数据必须放在消息主体（entity-body）中，但协议并没有规定数据必须使用什么编码方式。实际上，开发者完全可以自己决定消息主体的格式，只要最后发送的 HTTP 请求满足上面的格式就可以。

什么是rpc框架，及其作用，在php方向上的使用

远程调用”
通常我们调用一个方法，譬如: localAdd(10, 20)，localAdd方法的具体实现要么是用户自己定义，要么存在于该语言的库函数中，也就说在localAdd方法的代码实现在本地，它是一个本地调用！

“远程调用”意思就是：被调用方法的具体实现不在程序运行本地，而是在别的某个地方；

远程调用原理
譬如 A调用B提供的remoteAdd方法：,

首先A与B之间建立一个TCP连接；
然后A把需要调用的方法名（这里是remoteAdd）以及方法参数（10， 20）序列化成字节流发送出去；
B接受A发送过来的字节流，然后反序列化得到目标方法名，方法参数，接着执行相应的方法调用（可能是localAdd）并把结果30返回；
A接受远程调用结果
RPC框架无非就是把我刚才说的那些细节通通封装起来，给用户暴露简单友好的API使用（ps：有些远程调用选择比较底层的socket协议，有些远程调用选择比较上层的HTTP协议）；

远程调用好处：
解耦：当方法提供者需要对方法内实现修改时，调用者完全感知不到，不用做任何变更；这种方式在跨部门，跨公司合作的时候经常用到，并且方法的提供者我们通常称为：服务的暴露方
至于soap，yar，phprpc,thrift这几样的东西，一个都没用过，所以不好评价