rpc详解rpc框架

时间：2024-03-22 07:27:55

文章目录

    • 概述
    • rpc的优点
    • 组件
    • 工作流程&RPC的底层原理
      • RPC的底层原理
    • RPC框架
    • rpc框架优点
    • RPC 的实现基础
    • RPC的应用场景
    • RPC使用了哪些关键技术
    • rpc 调用异常一般怎么处理
    • rpc和http的区别
    • 为什么RPC要比HTTP更快一些
    • Dubbo和openfeign 区别
    • 远程调用
    • RPC框架传输协议传输速度

概述

在互联网应用开发中，随着业务的复杂度增加，一般都会采用分布式架构。分布式架构的核心，就是利用多台普通的计算机组成一个庞大的复杂计算网络，提供高并发、高性能、高可用的系统能力支撑。在分布式架构中，原本的单体应用服务被拆分成多个独立部署的服务，分布式在计算机网络上，这些服务必然，需要通过网络进行数据通信和交互。而RPC框架，就是解决在分布式架构中，各个服务之间的网络通信问题的框架。在Java应用中，JDK 1.1版本的时候就提供了对RPC的支持框架，叫做RMI。由于RMI不能实现跨域语言的远程调用。后面，广发采用WebService来实现远程调用，但是，WebService需要定义非常复杂的Scheme文件，导致无效数据内容过于臃肿。之后，就被HTTP加JSON的方案所代替了。
RPC发展到现在，实现的方式也非常多样，但是基本都实现了跨语言的远程调用。一般来说，RPC框架都应用于大型企业，只有在业务复杂度和用户体量都比较大的时候，需要对服务进行解耦，从而达到扩展性强、部署灵活的目的。目前比较流行的开源RPC框架有Goole的gRPC、Facebook的Thrift、Alibaba的Dubbo。这些框架除了提供基础的远程通信功能以外，还会在系统性能、传输效率、服务治理等方面做出一些优化设计。比如，阿里开源的RPC框架Dubbo就提供了非常丰富的服务治理功能。
RPC（远程过程调用）是一种计算机通信协议，用于在不同的进程或者计算机之间实现远程通信，使得一个进程可以调用另一个进程（通常是运行在不同机器上）的函数或方法，就像调用本地函数一样。
rpc的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的。为实现该目标，rpc框架器提供一种透明调用机制，让使用者不必是式的区分本地调用和远程调用。
基本原理：

  1. 客户端调用： 客户端调用远程服务的方法，就像调用本地函数一样，传递参数并等待结果。
  2. 远程过程执行： 远程过程在远程服务器上执行，接收客户端发送的参数，执行相应的计算或操作。
  3. 结果返回： 执行完成后，远程过程将结果返回给客户端。

rpc的优点

分布式设计
部署灵活
解耦服务
扩展性强

组件

  1. 客户端（Client）： 发起RPC调用的应用程序部分。
  2. 服务端（Server）： 提供RPC服务的应用程序部分。
  3. RPC协议（Protocol）： 定义了客户端和服务端之间通信的规则、格式和消息交换方式。
  4. 序列化/反序列化（Serialization/Deserialization）： 将数据结构或对象转换成字节流以便在网络上传输，并在接收端重新构造成相应的数据结构或对象。
  5. 网络传输（Network Transport）： 用于在客户端和服务端之间传输数据的通信机制，通常使用TCP/IP或者HTTP等协议。

工作流程&RPC的底层原理

在这里插入图片描述

  1. 客户端调用： 客户端调用本地的Stub（存根）方法，传递参数。
  2. 参数序列化： 客户端将参数序列化成字节流。
  3. 网络传输： 序列化后的数据通过网络传输到远程服务端。
  4. 服务端接收： 远程服务端接收到请求，进行反序列化得到参数。
  5. 服务端处理： 服务端执行相应的方法或过程，传入参数，执行计算或操作。
  6. 结果序列化： 服务端将执行结果序列化成字节流。
  7. 网络传输： 序列化后的结果通过网络传输到客户端。
  8. 客户端接收： 客户端接收到结果，进行反序列化得到返回值。
  9. 客户端处理： 客户端处理返回值，完成RPC调用。

RPC的底层原理

RPC（Remote Procedure Call，远程过程调用）是一种用于在不同的计算机之间进行通信的技术，允许一个程序调用另一个程序中的函数或方法，就像调用本地函数一样，而无需程序员显式地编写通信代码。RPC的底层原理涉及通信协议、序列化和反序列化、网络传输、服务注册与发现等方面。

下面是RPC的一般工作原理：

  1. 定义接口: RPC的第一步是定义客户端和服务端之间通信的接口。这些接口中包含需要在远程服务器上调用的方法。
  2. 序列化: 当客户端调用远程方法时，客户端程序将方法的参数序列化为字节流。序列化是将对象转换为字节流的过程，以便在网络上传输。
  3. 网络传输: 序列化后的请求被传输到远程服务器，这通常通过网络协议（如HTTP、TCP等）实现。
  4. 反序列化: 一旦请求到达远程服务器，服务器程序将接收到的字节流反序列化为方法调用所需的参数。
  5. 调用远程方法: 远程服务器根据反序列化后的参数调用相应的方法或函数。
  6. 序列化结果: 服务器程序将方法执行的结果序列化为字节流。
  7. 网络传输结果: 序列化后的结果通过网络传输回客户端。
  8. 反序列化结果: 客户端程序接收到结果后，将结果字节流反序列化为方法调用的返回值。
  9. 返回结果: 最终，客户端程序将调用远程方法的返回值返回给调用方。
    在实际的RPC实现中，还可能涉及到一些额外的步骤，如：
    ● 服务注册与发现: RPC框架通常会提供服务注册与发现的功能，允许服务提供者将其提供的服务注册到注册中心，并允许服务消费者从注册中心获取可用的服务地址。
    ● 负载均衡与容错: RPC框架通常还包括负载均衡和容错机制，以确保请求能够被均匀分布到不同的服务节点，并在某些节点发生故障时能够进行故障转移或重试。
    ● 连接管理: RPC框架通常会管理与远程服务之间的连接，包括连接的建立、保持和释放等。

总的来说，RPC的底层原理涉及到将方法调用的参数序列化、通过网络传输、反序列化、调用远程方法、序列化结果、再次通过网络传输、反序列化结果的过程。各种RPC框架会根据具体需求和场景进行优化和扩展。

RPC框架

RPC（Remote Procedure Call）框架是一种用于实现远程调用的技术，它可以让不同的进程或计算机之间通过网络进行通信和调用远程方法。以下是一些常见的 RPC 框架：

  1. Dubbo：阿里开源的高性能 Java RPC 框架，提供了完整的服务治理功能，支持多种协议和序列化方式。 Dubbo是 阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服 务的输出和输入功能，可以和 Spring框架无缝集成。提供了丰富的特性，包括负载均衡、服务注册与发现、容错处理等，广泛应用于大型分布式系统中
  2. gRPC：Google 开源的跨语言 RPC 框架，基于 HTTP/2 协议和 Protocol Buffers，性能高效，它支持多种编程语言，如C、C++、Java、Go、Python等，适用于跨语言的服务通信
  3. Thrift：Facebook 开源的跨语言 RPC 框架，支持多种语言和数据格式，性能优秀，包括C++、Java、Python等，适用于异构系统的集成
  4. Spring Cloud：基于 Spring Boot 的微服务架构框架，提供了丰富的分布式系统解决方案，包括 RPC 调用，提供了对RPC调用的支持，通过集成Ribbon、Feign等组件实现服务之间的远程调用
  5. Apache Avro：Apache 开源的跨语言数据序列化系统，同时也支持 RPC 框架。
  6. Apache Dubbo：原名 Apache Dubbox，是一款高性能 Java RPC 框架，提供了完善的服务治理功能。
  7. Apache Thrift：Apache 开源的跨语言 RPC 框架，支持多种语言，包括 C++, Java, Python 等。
  8. ZeroC ICE：一种面向对象的跨语言通信框架，适用于构建大规模分布式系统。基于对象代理的RPC框架，支持C++、Java、Python等多种语言，适用于大规模分布式系统的构建。

这些RPC框架在不同的场景和需求下有着各自的优势和特点，选择适合自己业务需求的RPC框架是非常重要的。每种框架都有其独特的特性和适用范围，因此在选择时需要综合考虑技术栈、性能需求、跨语言支持等因素，这些都是比较流行的 RPC 框架，每个框架都有其独特的特点和适用场景。选择合适的 RPC 框架取决于具体的需求、技术栈和团队经验。
1、RMI
利用java.rmi包实现，基于Java远程方法协议(Java Remote Method Protocol) 和java的原生序列 化。
2、Hessian
是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。 基于HTTP协议，采 用二进制编解码。
3、protobuf-rpc-pro
是一个Java类库，提供了基于 Google 的 Protocol Buffffers 协议的远程方法调用的框架。基于
Netty 底层的 NIO 技术。支持 TCP 重用/ keep-alive、SSL加密、RPC 调用取消操作、嵌入式日志 等功能。
4、Thrift
是一种可伸缩的跨语言服务的软件框架。它拥有功能强大的代码生成引擎，无缝地支持C + +，
C#，Java，Python和PHP和Ruby。thrift允许你定义一个描述文件，描述数据类型和服务接口。
依据该文件，编译器方便地生成RPC客户端和服务器通信代码。
最初由facebook开发用做系统内个语言之间的RPC通信，2007年由facebook贡献到apache基金 ，现 在是apache下的opensource之一 。支持多种语言之间的RPC方式的通信：php语言client可以构造一 个对象，调用相应的服务方法来调用java语言的服务，跨越语言的C/S RPC调用。底层通讯基于 SOCKET
5、Avro
出自Hadoop之父Doug Cutting, 在Thrift已经相当流行的情况下推出Avro的目标不仅是提供一套类 似Thrift的通讯中间件,更是要建立一个新的，标准性的云计算的数据交换和存储的Protocol。支持 HTTP，TCP两种协议。Apache Avro：一个数据序列化系统，也提供了RPC框架的支持，具有快速、紧凑的特点，支持多种编程语言。

rpc框架优点

rpc框架一般使用长链接，不必每次通信都要3次握手，减少网络开销。
rpc框架一般都有注册中心，有丰富的监控管理，发布，下线接口，动态扩展等，对调用方来说是无感知，统一化的操作，协议私密，安全性较高
rpc协议更简单内容更小，效率更高，服务化架构，服务化治理，rpc框架是一个强力的支撑。
rpc基于tcp实现，也可以基于http2实现

  1. 简化远程调用：RPC 框架可以使远程服务的调用过程像本地调用一样简单，隐藏了底层网络通信细节，提供了更高层次的抽象。
  2. 跨语言支持：许多 RPC 框架支持跨多种编程语言进行通信，这使得不同语言编写的服务可以轻松地相互调用。
  3. 性能高效：RPC 框架通常针对高性能进行优化，能够在网络通信中提供低延迟和高吞吐量。
  4. 服务治理：许多 RPC 框架提供了完善的服务注册、发现、负载均衡、容错处理等服务治理功能，帮助管理和监控分布式系统中的服务。
  5. 扩展性：RPC 框架通常具有良好的扩展性，能够满足不断变化的业务需求和规模扩展。
  6. 代码生成：许多 RPC 框架支持自动生成客户端和服务端的代码，减少了开发人员的工作量。
  7. 安全性：RPC 框架通常提供了安全机制，包括数据传输加密、身份认证和授权等功能。
  8. 透明性：RPC 框架可以提供透明的远程调用，使得调用方无需关心调用的具体实现细节，从而降低了系统的耦合度。
    总的来说，RPC 框架可以帮助开发人员构建可靠、高效、易于管理的分布式系统，使得不同服务之间的通信变得更加简单和可靠。

RPC 的实现基础

需要有非常高效的网络通信，比如一般选择 Netty 作为网络通信框架；
需要有比较高效的序列化框架，比如谷歌的 Protobuf 序列化框架；
可靠的寻址方式（主要是提供服务的发现），比如可以使用 Zookeeper 来注册服务等；
如果是带会话（状态）的 RPC 调用，还需要有会话和状态保持的功能；
跨进程，可以理解为同一台计算上的多个进程、多个JVM或者多台计算之间的进程。
那什么是RPC呢？RPC的全称是Remote Procedure Call，翻译过来叫远程过程调用。
它是一种通过网络从远程计算机程序上获取服务，而不需要了解代码网络技术实现的一种协议。凡是符合这种协议的框架，都可以称之为RPC框架。
通俗理解就是，A计算机提供一个服务，B计算机可以像调用本地服务一样去调用A计算机提供的服务，这就是RPC的主要作用。
其实，RPC的应用在很早之前就出现了。在40年以前，也就是1981年的时候，由一家叫做Nelson的公司提出，并把它应用到了分布式系统之间的通信协议。
RPC协议
要实现RPC，需要通过网络进行数据传输，并且对调用的过程进行封装。现在比较流行的RPC框架一般都是采用TCP协议作为底层的传输协议。当然，其他协议也是可以的，比如UDP。
RPC协议，强调的是过程调用，调用的过程对于用户来说是完全透明的，用户不需要关心调用细节。可以像调用本地服务一样去调用远程服务。
一个完整的RPC协议包含了四个组件，分别是Client、Server、Client Stub和Sever Stub。
Client客户端表示服务的调用方；
Sever服务端是真正的服务提供方；
Client Stub表示客户端存根，专门用来存放服务端的地址信息，再将客户端的请求参数打包成网络消息，也就是序列化，然后通过网络远程发送给服务提供方。
Server Stub表示服务端存根，用来接收客户端发送过来的消息，然后，解析消息内容，也就是反序列化，并且调用本地方法。

RPC的应用场景

1、分布式系统网络通讯
2、分布式子系统之间的服务治理
3、分布式负载均衡和流控
4、服务发现与注册
5、构建分布式调试环境

RPC使用了哪些关键技术

1、动态代理
生成Client Stub（客户端存根）和Server Stub（服务端存根）的时候需要用到Java动态代理技术，可
以使用JDK提供的原生的动态代理机制，也可以使用开源的：CGLib代理，Javassist字节码生成技术。
2、序列化和反序列化
在网络中，所有的数据都将会被转化为字节进行传送，所以为了能够使参数对象在网络中进行传输，需
要对这些参数进行序列化和反序列化操作。
序列化：把对象转换为字节序列的过程称为对象的序列化，也就是编码的过程。反序列化：把字节
序列恢复为对象的过程称为对象的反序列化，也就是解码的过程。 目前比较高效的开源序列化框架：如Kryo、FastJson和Protobuf等。
反序列化：把字节序列恢复为对象的过程称为对象的反序列化，也就是解码的过程。 目前比较高
效的开源序列化框架：如Kryo、FastJson和Protobuf等。
3、NIO通信
出于并发性能的考虑，传统的阻塞式 IO 显然不太合适，因此我们需要异步的 IO，即 NIO。Java 提供 了 NIO 的解决方案，Java 7 也提供了更优秀的 NIO.2 支持。可以选择Netty或者MINA来解决NIO数据传输的问题。
4、服务注册中心
可选：Redis、Zookeeper、Consul 、Etcd。一般使用ZooKeeper提供服务注册与发现功能，解决单 点故障以及分布式部署的问题(注册中心)。

rpc 调用异常一般怎么处理

一般超时容错 、重试、超时处理、
处理远程过程调用（RPC）异常的方法取决于您使用的RPC框架和编程语言。一般来说，以下是一些处理RPC调用异常的常见方法：

  1. 捕获异常：在进行RPC调用时，使用try-catch语句捕获可能抛出的异常。这样可以在异常发生时捕获并处理异常情况。
  2. 重试机制：对于临时性的网络问题或服务端问题，可以考虑实现重试机制，当RPC调用失败时，自动尝试再次调用，直至达到最大重试次数或成功为止。
  3. 超时处理：设置合理的超时时间，并在超时发生时进行适当的处理，比如记录日志、返回错误信息或者进行重试。
  4. 回退策略：当发生异常时，可以考虑采用回退策略，例如切换到备用服务或者采用备用数据源。
  5. 错误信息传递：在捕获异常后，将错误信息传递给调用方，以便上层代码能够根据具体情况做出相应的处理。
  6. 断路器模式：引入断路器模式，当RPC调用失败次数达到一定阈值时，暂时关闭对该服务的访问，避免连锁故障。
  7. 监控和日志：建立完善的监控和日志系统，及时发现RPC调用异常，从而进行故障排查和修复。
    以上方法并非孤立的，通常会结合多种方法来处理RPC调用异常，以实现系统的稳定性和容错能力。同时，针对不同的业务场景和需求，可能需要进一步细化和定制化异常处理策略。
    处理Feign RPC调用异常时，可以采取以下常见策略：
  8. 使用Feign的ErrorDecoder：Feign提供了ErrorDecoder接口，可以自定义处理HTTP错误状态码和异常信息。通过实现ErrorDecoder接口，可以对Feign调用返回的异常进行统一处理，例如将异常信息转换成特定格式并返回给调用方。
  9. 定义Fallback方法：在Feign接口中可以定义fallback方法，当RPC调用出现异常时，可以执行fallback方法来返回一个默认值或者进行其他补偿性操作，避免将异常抛给调用方。
  10. 超时处理：在Feign客户端接口中可以设置连接和读取超时时间，以及对应的超时处理策略，如重试、降级等。
  11. 熔断机制：对于频繁出现异常或错误的RPC调用，可以引入熔断机制，防止故障扩散，这可以通过Hystrix等框架来实现。
  12. 监控和日志：建立完善的监控和日志系统，及时发现RPC调用异常，从而进行故障排查和修复。Feign本身并不提供监控和管理功能，通常需要结合其他监控系统进行监控。
  13. 全局异常处理器：在应用程序中可以编写全局异常处理器来捕获Feign调用产生的异常，然后进行统一的异常处理和记录日志。
    综合利用上述策略，可以有效地处理Feign RPC调用过程中可能出现的异常，提高系统的稳定性和容错能力。同时，根据具体业务需求，还可以进一步细化和定制化异常处理策略。

rpc和http的区别

传输协议
RPC，可以基于TCP协议，也可以基于HTTP协议
HTTP，基于HTTP协议传输效率
RPC，使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以很好的减少报文的体积，提高传输效率
HTTP，如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装以下是可以作为⼀个RPC来使用的，这时标准RPC框架更多的是服务治理
性能消耗，主要在于序列化和反序列化的耗时
RPC，可以基于thrift实现高效的二进制传输
HTTP，大部分是通过json来实现的，字节大小和序列化耗时都比thrift要更消耗性能
负载均衡
RPC，基本都自带了负载均衡策略
HTTP，需要配置Nginx，HAProxy来实现
服务治理（下游服务新增，重启，下线时如何不影响上游调用者）
RPC，能做到自动动通知，不影响上游
HTTP，需要事先通知，修改Nginx/HAProxy配 置
b. 总结：RPC主要⽤于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。HTTP主要⽤于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用等。

为什么RPC要比HTTP更快一些

RPC（Remote Procedure Call）相比于HTTP在一些情况下可能更快，这主要是由于以下几个原因：

  1. 二进制传输协议：RPC框架通常使用二进制传输协议，如Protocol Buffers、Thrift等，而HTTP使用文本传输协议，如JSON、XML。二进制传输协议的数据体积更小，序列化和反序列化的速度更快，可以减少网络传输的时间和带宽消耗。
  2. 定制化协议：RPC框架通常可以定制自己的通信协议，针对特定的场景进行优化，如连接复用、请求批处理、压缩等。相比之下，HTTP是通用的应用层协议，有一定的通用性，但不一定能满足特定场景的需求。
  3. 底层传输协议：RPC框架通常使用TCP或UDP等底层传输协议进行通信，而HTTP基于TCP协议。TCP相较于HTTP具有更低的开销和更高的效率，能够提供更快的数据传输速度。
  4. 连接管理：RPC框架通常会维护长连接，避免频繁地建立和关闭连接，减少了连接建立和关闭的开销。而HTTP每次请求都需要建立连接，增加了额外的开销。
    虽然RPC在性能上可能会比HTTP更快，但也要考虑到RPC框架的复杂性和学习成本较高，以及对网络环境和部署的要求较高。在选择RPC还是HTTP时，需要根据具体的应用场景和需求来权衡两者之间的优劣，并选择合适的技术方案。

Dubbo和openfeign 区别

Dubbo 和 OpenFeign 是两种常用的远程服务调用框架，它们在实现远程服务调用时有一些不同之处：

  1. 通信协议：
    ○ Dubbo 通常使用自定义的 Dubbo 协议进行远程调用，该协议基于 TCP 传输。
    ○ OpenFeign 则是基于 HTTP 协议进行远程调用，通常使用 RESTful 风格的 API。
  2. 服务注册与发现：
    ○ Dubbo 依赖于 ZooKeeper 或其他注册中心来进行服务的注册和发现。
    ○ OpenFeign 在默认情况下通常与服务发现和注册无关，需要额外集成服务发现组件（如 Eureka、Consul 等）来实现服务的注册和发现。
  3. 接口定义方式：
    ○ 在 Dubbo 中，通常需要通过 Dubbo 提供的接口定义语言（IDL）来定义服务接口，然后生成客户端和服务器端的代理类。
    ○ OpenFeign 则通常使用接口的方式来定义远程服务，通过注解来标识远程服务的调用方式。
  4. 负载均衡和容错机制：
    ○ Dubbo 内置了丰富的负载均衡和容错机制，包括轮询、随机、一致性哈希等负载均衡算法，以及失败自动切换、快速失败等容错机制。
    ○ OpenFeign 在默认情况下通常需要结合 Ribbon 来实现负载均衡，同时也可以集成 Hystrix 等容错机制。
  5. 附加功能：
    ○ Dubbo 提供了更多的企业级功能支持，如监控、治理、降级、熔断等，适用于复杂的微服务架构。
    ○ OpenFeign 更侧重于简化 REST 客户端的开发，提供了更直观的声明式 API 定义和使用。
    总的来说，Dubbo 更适用于企业级的微服务架构，提供了更多的功能和配置选项；而 OpenFeign 更适合于简单的 RESTful 服务调用，提供了更便捷的声明式 API 调用方式。选择使用哪种框架取决于具体的业务需求和技术场景。

远程调用

rmi
http
hessian
webservice
socket
网络通信
负载均衡
注册中心
远程通讯协议的基本原理
网络通信需要做的就是将流从一台计算机传输到另外一台计算机，基于传输协议和网络 IO 来实现，其中传输协议比较出名的有 http 、 tcp 、 udp 等等， http 、 tcp 、 udp 都是在基于 Socket 概念上为某类应用场景而扩展出的传输协议，网络 IO ，主要有 bio 、 nio 、 aio 三种方式，所有的分布式应用通讯都基于这个原理而实现，只是为了应用的易用，各种语言通常都会提供一些更为贴近应用易用的应用层协议。
应用级协议Binary-RPC
Binary-RPC(Remote Procedure Call Protocol，远程过程调用协议)是一种和RMI(Remote Method Invocation，远程方法调用)类似的远程调用的协议，它和RMI 的不同之处在于它以标准的二进制格式来定义请求的信息 ( 请求的对象、方法、参数等 ) ，这样的好处是什么呢，就是在跨语言通讯的时候也可以使用。
Binary -RPC 协议的一次远程通信过程：
1 、客户端发起请求，按照 Binary -RPC 协议将请求信息进行填充；
2 、填充完毕后将二进制格式文件转化为流，通过传输协议进行传输；
3 、接收到在接收到流后转换为二进制格式文件，按照 Binary -RPC 协议获取请求的信息并进行处理；
4 、处理完毕后将结果按照 Binary -RPC 协议写入二进制格式文件中并返回。
问题总结：
1 、传输的标准格式是：标准格式的二进制文件。
2 、怎么样将请求转化为传输的流？将二进制格式文件转化为流。
3 、怎么接收和处理流？通过监听的端口获取到请求的流，转化为二进制文件，根据协议获取请求的信息，进行处理并将结果写入 XML 中返回。
4 、传输协议是？http

RPC框架传输协议传输速度

RMI 是 java 语言本身提供的远程通讯协议，稳定高效，是 EJB 的基础。但它只能用于 JAVA 程序之间的通讯。
Hessian 和 Burlap 是 caucho 公司提供的开源协议，基于 HTTP 传输，服务端不用开防火墙端口。协议的规范公开，可以用于任意语言。跨平台有点小问题。
Httpinvoker 是 SpringFramework 提供的远程通讯协议，只能用于 JAVA 程序间的通讯，且服务端和客户端必须使用 SpringFramework。
Web service 是连接异构系统或异构语言的首选协议，它使用 SOAP 形式通讯，可以用于任何语言，目前的许多开发工具对其的支持也很好。
效率相比：RMI > Httpinvoker >= Hessian >> Burlap >> web service。
RMI （Remote Method Invocation）
RMI 采用 stubs 和 skeletons 来进行远程对象(remote object)的通讯。stub 充当
远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用
该对象的客户端代理对象stub来完成的，通过该机制RMI就好比它是本地工作，采用tcp/ip
协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只
能基于 JAVA 语言，客户机与服务器紧耦合。
JMS（Java Messaging Service）
JMS 是 Java 的消息服务，JMS 的客户端之间可以通过 JMS 服务进行异步的消息传输。
JMS 支持两种消息模型：Point-to-Point（P2P）和 Publish/Subscribe（Pub/Sub），即
点对点和发布订阅模型。

相关文章