rpc

前言 架构服务化后，需要实现一套方便调用各服务的框架，现在开源如日中天，优先会寻找开源实现，如果没有合适自家公司业务的，才会考虑从零开发，尤其是一切以KPI为准绳的公司，谁会跟钱过不去？N个月之前，公司大神就开始调研了，最后选中了Thrift这个RPC服务框架。使用不熟悉的技术，我会感到很恐惧，它就相当于一个黑盒，我对它一无所知，它是如何运转的？出了问题该如何解决？带着一丝不安，查阅了相关技术文档。 RPC 很早之前听说过soap,restful api,rpc之类的服务协议，一直都没有机会深入实践，对它们理解的不够深。它们的目的都是提供本地调用远程服务的能力，只是实现方式不同而已。RPC(remote procedure call)意思是远程过程调用，编码时可以把它当作本地方法一样调用，无需关心内部的实现细节，对于调用方很友好很简单。我查阅资料，发现RPC之类的东西很早很早以前就出现了，存在即是合理的，肯定有它的理由。跟本地调用相比有什么优点缺点呢？根据查阅的资料以及自己的理解总结如下： 优势 1 提高系统吞吐能力 2 业务服务解耦 3 更易构建服务分布式集群 4 基础服务重用更方便 劣势 1 因网络开销方法执行时间更长 2 系统更复杂对运维挑战很大 3 排错成本增加 4 数据序列化消耗CPU资源 现在是移动互联时代，数据无时无刻不在产生着，随着时间的推移，随着用户数的增加

主要抽象 Flink RPC 框架主要抽象了 RpcService , RpcEndpoint , RpcGateway , RpcServer 这几个接口，具体实现可以采用多种方式，比如： akka , netty RpcService 我理解为RPC框架的引擎，可以用来启动、停止、连接一个 RpcEndpoint ，以及执行某些异步任务或者周期性调度任务。 主要方法: connect :连接到一个 RpcEndpoint ,返回一个 RpcGateway ,然后调用者可以使用此gateway进行远程方法调用。 startServer :启动一个 RpcEndpoint ,返回一个 RpcServer 。 fenceRpcServer :获取新的 RpcServer ,可用于重新选主后，更新fencingToken。 stopServer : 停止某个 RpcEndpoint 。 scheduleRunnable :延迟调度执行某任务。 execute :异步执行某任务。 RpcEndpoint 所有提供远程调用的组件都会继承此抽象类并实现组件自身提供的业务方法，并且保证同一个 RpcEndpoint 上的所有远程调用都在同一个线程中执行。 RpcGateway 用于远程调用 RpcEndpoint 的某些方法。可以理解为客服端代理。 RpcServer RpcService 的

1、RPC概述 　　RPC(Remote Procedure Call)即远程过程调用，允许一台计算机调用另一台计算机上的程序得到结果，而代码中不需要做额外的编程，就像在本地调用一样。主要是为了应对当前互联网项目量级越来越大而出现的。 2、Broker模式介绍 　　 3、RPC结构拆解 　　 4、RPC客户端组件与职责 　　-RpcClient：负责导入远程接口的代理实现 　　-RpcProxy：远程接口的代理实现 　　-RpcInvoker：负责编码和发送调用请求到服务方并等待结果 　　-RpcProtocol：负责协议的编/解码 　　-RpcConnector：负责维护客户/服务方连接通道和发送数据到服务方 　　-RpcChannel：数据传输通道 5、RPC服务端组件与职责 　　-RpcServer：负责导出远程接口 　　-RpcInvoker：负责调用服务端接口的具体实现并返回结果 　　-RpcProtocol：负责协议的编/解码 　　-RpcAcceptor：负责接收客户方请求并返回请求结果 　　-RpcProcessor：负责在服务方控制调用过程，包括线程池、超时等 　　-RpcChannel：数据传输通道 6、RPC导出/导入远程接口 7、RPC数据传输 　　-传输协议：建议选择稳定性较强的连接协议（HTTP、TCP），像UDP就不建议选择 　　-连接：长连接、短连接

为什么会有dubbo的出现: 随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。 在大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。 　　(1) 当服务越来越多时，服务URL配置管理变得非常困难

服务间，系统间信息交互，简单的方式可以是http，但比http更为高效的是RPC，gRPC是比较流行的RPC工具了，使用上也比较简单。那么，我们不妨也了解一下RabbitMQ实现RPC又是怎样一番风味。 RabbitMQ是单向的消息传递，生产者将消息发送给消费者之后就不再管后续的业务处理了。实际业务中，有的时候我们还需要等待消费者返回结果给我们，或者是说我们需要消费者上的一个功能、一个方法或是一个接口返回给我们相应的值，而往往大型的系统软件，生产者跟消费者之间都是相互独立的两个系统，部署在两个不同的电脑上，不能通过直接对象.方法的形式获取想要的结果，这时候我们就需要用到RPC（Remote Procedure Call）远程过程调用方式。 RabbitMQ实现RPC的方式很简单，生产者发送一条带有标签（消息ID（correlation_id）+回调队列名称）的消息到发送队列，消费者（也称RPC服务端）从发送队列获取消息并处理业务，解析标签的信息将业务结果发送到指定的回调队列，生产者从回调队列中根据标签的信息获取发送消息的返回结果。 如图，客户端C发送消息，指定消息的ID=rpc_id，回调响应的队列名称为rpc_resp，消息从C发送到rpc_request队列，服务端S获取消息业务处理之后，将correlation_id附加到响应的结果发送到指定的回调队列rpc_resp中

SOFARPC源码解析系列： 1. 源码分析---SOFARPC可扩展的机制SPI 2. 源码分析---SOFARPC客户端服务引用 3. 源码分析---SOFARPC客户端服务调用 4. 源码分析---SOFARPC服务端暴露 5.源码分析---SOFARPC调用服务 6.源码分析---和dubbo相比SOFARPC是如何实现负载均衡的？ 7.源码分析---SOFARPC是如何实现连接管理与心跳？ 8.源码分析---从设计模式中看SOFARPC中的EventBus？ 9.源码分析---SOFARPC是如何实现故障剔除的？ 大家在看链路追踪之前可以先去看看官方的这篇文章 SOFARPC 链路追踪剖析 ，有助于理解。 我先把官方的一个图拿过来，这张图表示的是整个RPC调用框架的一个事件发送的先后顺序。 图中分别对应的事件是： ClientStartInvokeEvent ClientBeforeSendEvent ClientAfterSendEvent ServerReceiveEvent ServerSendEvent ServerEndHandleEvent ClientSyncReceiveEvent ClientAsyncReceiveEvent ClientEndInvokeEvent 其中因为ClientAfterSendEvent

rpc的用法是客户端直接调用服务端的函数，其实他就是把数据传给服务端，服务端处理完以后返回给客户端， websocket是把数据发出去,他是在tcp之上一层的，他有发送结束标志，就是一次ws.send的结束，服务器会知道，服务器按照协定可以拿出完整的一次ws.send那么区别就出来了：websocket并不关系对方拿到数据后处理的过程是否完成，而rpc是和处理过程相关的，其实他们不是同一个级别的东西。如果是 短连接的 话， rpc更像是http, rpc适合 做数据同步 ，websocket适合 做流 ，当然也可以用websocket实现rpc https://www.jianshu.com/p/3b5955940998 这个问题其实是有理解误区的，首先 http 和 rpc 并不是一个并行概念。 rpc是远端调用协议, 包含 传输协议和编码协议。 传输协议包含: 如著名的 [gRPC]( grpc / grpc.io** ) 使用的 http2 协议，也有如dubbo一类的自定义报文的tcp协议。 编码协议包含: 如基于文本编码的 xml json，也有二进制编码的 protobuf binpack 等。 因此我理解的你想问的问题应该是： 为什么要使用自定义 tcp 协议的 rpc 做后端进程通信？ 要解决这个问题就应该搞清楚 http 使用的 tcp 协议，和我们自定义的