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 框架,这 些都是久经考验的解决方案。