rpc

RPC是远程过程调用的一个框架，在hadoop中基本上各种关系都是采用RPC框架来实现各种方法的调用。 因为hadoop是分布式的存储，存在多个系统，多个集群，例如web层负责实现客户点的请求转发，要实现调用各种方法，但是不同的方法可能在不同的系统上，要想实现这种非本地方式的方法的调用，就需要采用RPC框架来实现。 来源： oschina 链接： https://my.oschina.net/u/4434424/blog/3165063

软件安装 # go get -u github.com/golang/protobuf/{proto,protoc-gen-go} # go get -u google.golang.org/grpc 生成protoc # git clone https://github.com/google/protobuf.git # git checkout v3.4.1 ### 下面的命令在 Developer Command Prompt for VS2012 命令行执行 # cd D:\Project\protobuf\cmake\ # mkdir build # cd build # cmake -Dprotobuf_BUILD_TESTS=OFF .. 使用VS2012打开build目录下的protobuf.sln文件，在protoc上右键->生成，最终生成的protoc.exe位于build的Debug目录下 向PATH添加protoc.exe路径 剩余步骤参考 go RPC官方教程 原生net/rpc 服务端代码 import ( "net" "net/rpc" "time" "math/rand" "fmt" "strconv") type Arith int func (t *Arith) Hello(arg *int, reply *string) error {

1.RPC简介 1.远程过程调用（Remote Procedure Call,RPC）是一个计算机通信协议。 2.该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。 3.如果涉及的软件采用面向对象编程，那么远程过程调用也可称为远程调用或远程方法调用。 2.流行的RPC框架的对比 3.golang中如何实现RPC Golang中实现RPC比较简单，官方提供了封装好的库，还有第三方库。 官方库：net/rpc 1.net/rpc库使用encoding/gob进行编码 2.支持tcp和http数据传输方式 3.由于其他语言不支持gob编解码方式，所以golang的RPC只支持golang开发的服务端与客户端的交互 官方库：net/jsonrpc 1.jsonrpc采用JSON进行数据编解码，因而支持跨语言调用。 2.jsonrpc库是基于tcp协议实现的，暂不支持http传输方式。 golang的RPC必须符合四个条件才可以： 1.结构体字段首字母要大写，要跨域访问，所以大写。 2.函数名必须首字母大写。 3.函数第一个参数是接收参数，第二个参数是返回给客户端参数，必须是指针类型。 4.函数必须有一个返回值err。 3.1示例1 golang实现RPC程序，实现求矩形面积和周长 //rpcClient/server.go package

1、什么是RPC 由于各服务部署在不同的机器，服务间的调用免不了网络通信过程，服务消费方没调用一个服务都要写一坨网络通信相关的代码，不仅负责而且容易出错 RPC(Remote Procedure Call)远程过程调用能让我们像调用本地服务一样调用远程服务，而让调用方对网络通信这些细节透明 常见的RPC框架： 阿里巴巴的hsf、dubbo Facebook的thrift Google的grpc Twitter的finagle等 2、RPC调用过程及涉及到的通信细节 服务消费方（client）调用以本地调用方式调用服务 client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体 client stub找到服务地址，并将消息发送到服务端 server stub收到消息后进行解码 server stub根据解码结果调用本地服务 本地服务执行并将结果返回给server stub server stub将返回结果打包成消息并发送至消费方 client stub接收到消息，并进行解码 服务消费方得到最终结果 RPC的目标就是要将2-8这些步骤都封装起来，让用户对这些细节透明 3、如何做到透明化远程服务调用 怎么封装通信细节才能让用户像以本地调用方式调用远程服务呢？ 对JAVA来说就是使用代理！ Java代理的两种方式： JDK动态代理 CGLIB字节码生成 来源：

问题1：为什么要把系统拆分成分布式的？为啥要用dubbo？ 1.为什么要将系统进行拆分？ 要是不拆分系统，一个大系统几十万行代码，很多人共同维护一份代码，简直是悲剧； 拆分了以后，一个大系统拆分成很多小服务，平均每个系统也就几万行代码，每个服务部署到单独的机器 2.如何进行服务拆分？ ​ 大部分系统，是要进行多轮拆分的，第一次拆分就可能将原来的多个模块拆分开来。 ​ 但是后来可能每个系统都变得很复杂了，每个模块拆分出来的服务又要继续拆分。 3.拆分后可以不用dubbo吗？ ​ 当然可以，大不了各个系统之间，直接基于springmvc，就通过纯httpj接口互相通信。但是这里肯定是由问题的，因为HTTP接口通信维护起来成本很高，要考虑超时重试,负载均衡等各种问题。 所以dubbo说白了，就是一个rpc框架，就是本地就是进行接口调用，但是dubbo会代理这个调用请求，跟远程机器网络通信，处理负载均衡，服务上下线自动感知，超时重试等问题，就不用我们自己做，交给dubbo。 ​ 问题2：说一下dubbo的工作原理，注册中心挂了可以继续通信吗？说一下一次rpc请求的流程？ 1.dubbo工作原理 2.dubbo分层 第一层：service层，需要服务提供方和消费方来实现 第二层：config层，配置层，主要是对dubbo的各种配置 第三层：proxy层，服务代理层

RPC原理 一次完整的RPC调用流程如下（同步调用，异步另说）： 服务消费方（client）调用以本地调用方式调用服务 ； client stub（客户端代理）接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体； client stub找到服务地址，并将消息发送到服务端； server stub收到消息后进行解码（序列化与反序列化）； server stub根据解码结果调用本地的服务； 本地服务执行并将结果返回给server stub； server stub将返回结果打包成消息并发送至消费方； client stub接收到消息，并进行解码； 服务消费方得到最终结果 。 RPC框架的目标就是要将2~8这些步骤都封装起来，这些细节对用户来说是透明的，不可见的。 Netty通信原理 Netty是一个异步事件驱动的网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。它极大地简化了TCP和UDP套接字服务器等网络编程。 Netty基于Java的NIO（Non-Blocking IO）进行通信。 Netty通信原理： 初始化Channel； 注册Channel到Selector； 轮询accept事件； 处理accept建立Channel； 注册Channel 到Selector； 轮询读写事件； 处理读写事件。 来源： CSDN 作者： xingze0516 链接：

在最近一段时间里，通过搜集有关资料加上自己的理解，设计了一款轻量级RPC,起了一个名字 lightWeightRPC 。它拥有一个RPC常见的基本功能。主要功能和特点如下： 利用Spring实现依赖注入与参数配置 利用Netty来实现客户端与服务端的远程通信 利用Hessian来实现序列化 设置Zookeeper作为注册中心 新设监控器，通过心跳机制来判断服务端与监控器的网络连接状况，当出现不稳定时，认为服务端出现了问题，在注册中心删除相关的服务信息。 利用Netty的Promise来实现异步的传送 构建线程池来管理发送的请求线程 添加服务缓存机制，在注册中心宕机的情况下仍能进行服务消费。 支持服务扩展点发现机制（SPI）,对Spring的SPI机制进行改进，解决了依赖注入问题。 在客户端从注册中心获取服务时，添加监听器，当注册中心对应节点发生变化时通知客户端修改本地缓存信息。 以上是 lightWeightRPC 的全部功能，本版本添加的内容就是最后一个功能，为服务节点添加监听器。 因为之前在本地添加了持久化的缓存，当服务消费时会先从缓存中查找信息，查不到再到注册中心查找，但是当服务地址等信息发生变化时，如果不对缓存信息进行修改就可能会发生错误。所以在本版本中为服务节点添加了监听器。 如何添加监听器 当客户端首次从注册中心获取服务信息时，会对有关服务节点添加监听器,具体方法在

在微服务架构中，需要调用很多服务才能完成一项功能。服务之间如何互相调用就变成微服务架构中的一个关键问题。 服务调用有两种方式，一种是RPC方式，另一种是事件驱动（Event-driven）方式，也就是发消息方式。 消息方式是松耦合方式，比紧耦合的RPC方式要优越，但RPC方式如果用在适合的场景也有它的一席之地。 我们总在谈耦合，那么耦合到底意味着什么呢？ 耦合的种类： 时间耦合： 客户端和服务端必须同时上线才能工作。发消息时，接受消息队列必须运行，但后台处理程序暂时不工作也不影响。 容量耦合： 客户端和服务端的处理容量必须匹配。发消息时，如果后台处理能力不足也不要紧，消息队列会起到缓冲的作用。 接口耦合： RPC调用有函数标签，而消息队列只是一个消息。例如买了商品之后要调用发货服务，如果是发消息，那么就只需发送一个商品被买消息。 发送方式耦合： RPC是点对点方式，需要知道对方是谁，它的好处是能够传回返回值。消息既可以点对点，也可以用广播的方式，这样减少了耦合，但也使返回值比较困难。 下面我们来逐一分析这些耦合的影响。第一，时间耦合，对于多数应用来讲，你希望能马上得到回答，因此即使使用消息队列，后台也需要一直工作。 第二，容量耦合，如果你对回复有时间要求，那么消息队列的缓冲功能作用不大，因为你希望及时响应。 真正需要的是自动伸缩（Auto-scaling）

2014-12-19 01:05:42,141 (lifecycleSupervisor-1-1) [WARN - org.apache.flume.sink.AbstractRpcSink.start(AbstractRpcSink.java:294)] Unable to create Rpc client using hostname: xxx.xxx.xxx.xxx, port: 41100 org.apache.flume.FlumeException: NettyAvroRpcClient { host: 121.41.49.51, port: 41100 }: RPC connection error 如果在flume中sinks使用avro来推送数据时，出现这个问题。 那么要看一下Server上有没有监听，如果没有监听，则客户端的RPC当然连接SEVER时会报错啦！ 文章发自： http://www.cnblogs.com/hark0623/p/4175050.html 转发请注明 来源： https://www.cnblogs.com/hark0623/p/4175050.html

转自 http://www.itisedu.com/phrase/200604241155005.html 中间件 (IDC) 定义： 中间件 （ middleware ）是一种独立的系统 软件 或服务 程序 ，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的 操作系统 之上，管理计算资源和网络通信 提出原因： 为解决分布异构问题这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。 也许很难给中间件一个严格的定义，但中间件应具有如下的一些特点： 满足大量应用的需要 运行于多种硬件和 OS 平台 支持分布计算，提供跨网络、硬件和 OS 平台的透明性的应用或服务的交互 支持标准的协议 支持标准的接口 IDC 分类： 终端仿真 / 屏幕转换中间件、数据访问中间件、 远程过程调用 中间件、 消息 中间件、交易中间件、 对 象 中间件。下面，针对几类主要的中间件分别加以简要的介绍。 1 、远程过程调用 远程过程调用是一种广泛使用的分布式应用程序处理方法。一个应用程序使用 RPC 来 “ 远程 ” 执行一个位于不同地址空间里的过程，并且从效果上看和执行本地调用相同。事实上，一个 RPC 应用分为两个部分： server 和 Client 。 server 提供一个或多个远程过程； client 向 server