rpc核心实现和原理

RPC，即 Remote Procedure Call（远程过程调用），调用远程计算机上的服务，就像调用本地服务一 样。 RPC 可以很好的解耦系统，如 WebService 就是一种基于 Http 协议的 RPC。这个 RPC 整体框架 如下： 8.1.3.2. 关键技术 1. 服务发布与订阅：服务端使用 Zookeeper 注册服务地址，客户端从 Zookeeper 获取可用的服务 地址。 2. 通信：使用 Netty 作为通信框架。 3. Spring：使用 Spring 配置服务，加载 Bean，扫描注解。 4. 动态代理：客户端使用代理模式透明化服务调用。 5. 消息编解码：使用 Protostuff 序列化和反序列化消息。 8.1.3.3. 核心流程 1. 服务消费方（client）调用以本地调用方式调用服务； 2. client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体； 3. client stub 找到服务地址，并将消息发送到服务端； 4. server stub 收到消息后进行解码； 5. server stub 根据解码结果调用本地的服务； 6. 本地服务执行并将结果返回给 server stub； 7. server stub 将返回结果打包成消息并发送至消费方； 8. client stub 接收到消息，并进行解码； 9. 服务消费方得到最终结果。 RPC 的目标就是要 2~8 这些步骤都封装起来，让用户对这些细节透明。 JAVA 一般使用动态代 理方式实现远程调用。 8.1.3.1. 消息编解码 息数据结构（接口名称 方法名 参数类型和参数值 超时时间 requestID） 客户端的请求消息结构一般需要包括以下内容： 1. 接口名称： 在我们的例子里接口名是“HelloWorldService”，如果不传，服务端就不知道调用哪 个接口了； 2. 方法名：一个接口内可能有很多方法，如果不传方法名服务端也就不知道调用哪个方法； 3. 参数类型和参数值：参数类型有很多，比如有 bool、 int、 long、 double、 string、 map、 list， 甚至如 struct（class）；以及相应的参数值； 4. 超时时间： 5. requestID，标识唯一请求 id，在下面一节会详细描述 requestID 的用处。 6. 服务端返回的消息 ： 一般包括以下内容。返回值 状态 code requestID 序列化    目前互联网公司广泛使用 Protobuf、 Thrift、 Avro 等成熟的序列化解决方案来搭建 RPC 框架，这 些都是久经考验的解决方案。