rpc协议

Hbase的RPC主要由HBaseRPC、RpcEngine、HBaseClient、HBaseServer、VersionedProtocol 5个概念组成。 1、HBaseRPC是hbase RPC的实现类，核心方法： 　　1）、RpcEngine getProtocolEngine()：返回RpcEngine对象 　　2）、<T extends VersionedProtocol> T waitForProxy()：调用RpcEngine的getProxy()方法，返回一个远程代理对象，比如：第一次访问HRegionServer时需要执行该方法，设置代理后，会缓存该对象到HConnectionImplementation中。 2、RpcEngine接口 ，其实现类：WritableRpcEngine，核心方法： 　　1）、VersionedProtocol getProxy()：返回代理对象，HRegionServer和HMaster均是VersionedProtocol的实现类，即返回的对象可代理执行HRegionServer和HMaster的方法； 　　2）、Object[] call()：调用程序接口，最终是经过HBaseClient的内部类Connection通过socket方式完成； 　　3）、RpcServer getServer()

原文: ASP.NET Core 3.0 入门 课程简介 与2.x相比发生的一些变化，项目结构、Blazor、SignalR、gRPC等 课程预计结构 ASP.NET Core 3.0项目架构简介 ASP.NET Core MVC 简介 Blazor SignalR Web API gRPC 发布 一. 创建项目 dotnet core 本质上是控制台应用 1. DI 依赖注入（Dependency Injection） IoC 容器（Inversion of Control）控制反转 注册（服务） 请求实例 实例的生命周期 生命周期 Transient（每次被请求都会生成一个新的实例，最短） Scoped（一次 Web 请求产生一次实例，较长） Singleton（从应用程序启动到停止，只创建一次，最长） 2. ConfigureServices services.AddControllersWithViews(); services.AddControllers(); // 别的类每次请求 IClock 这个接口时，都会返回一个 ChinaClock 类的实例 // services.AddSingleton<IClock, ChinaClock>(); services.AddSingleton<IClock, UtcClock>(); 当需要更改接口的实现类的时候

NFS 概述 NFS（Network File System）即网络文件系统，它允许网络中的计算机之间通过TCP/IP网络共享资源。在NFS的应用中，本地NFS的客户端应用可以透明地读写位于远端NFS服务器上的文件，就像访问本地文件一样。 最早由sun公司开发，是类unix系统间实现磁盘共享的一种方法 工作原理 如上图，当我们在NFS服务器设置好一个共享目录/data/share后，其他的有权限访问NFS服务器的NFS客户端就可以讲这个目录挂载到自己的本地，并且能看到服务端/data/share下的所有数据，NFS是通过网络来进行Server端和Client端之间的数据传输，既然走网络，双方肯定都要有端口,哪NFS Server怎么知道使用哪个端口来进行数据传输，NFS其实会随机选择端口来进行数据传输，NFS服务器是通过远程过程调用RPC（Remote Procedure Call）协议来实现的，所以，RPC管理服务端的NFS端口分配，客户端要传数据，那么客户端的RPC会先跟服务端的RPC去要服务器的端口，要到端口后，再建立连接，然后传输数据 RPC（Remote Procedure Call）——远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据

NFS 概述 NFS（Network File System）即网络文件系统，它允许网络中的计算机之间通过TCP/IP网络共享资源。在NFS的应用中，本地NFS的客户端应用可以透明地读写位于远端NFS服务器上的文件，就像访问本地文件一样。 最早由sun公司开发，是类unix系统间实现磁盘共享的一种方法 工作原理 如上图，当我们在NFS服务器设置好一个共享目录/data/share后，其他的有权限访问NFS服务器的NFS客户端就可以讲这个目录挂载到自己的本地，并且能看到服务端/data/share下的所有数据，NFS是通过网络来进行Server端和Client端之间的数据传输，既然走网络，双方肯定都要有端口,哪NFS Server怎么知道使用哪个端口来进行数据传输，NFS其实会随机选择端口来进行数据传输，NFS服务器是通过远程过程调用RPC（Remote Procedure Call）协议来实现的，所以，RPC管理服务端的NFS端口分配，客户端要传数据，那么客户端的RPC会先跟服务端的RPC去要服务器的端口，要到端口后，再建立连接，然后传输数据 RPC（Remote Procedure Call）——远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据

在我看来，集成是微服务相关技术中最重要的一个。做得好的话，你的微服务可以保持自 治性，你也可以独立地修改和发布它们；但做得不好的话会带来灾难。希望本章能够帮助 你在微服务之旅中，避免曾经在SOA中遇到的那些问题。 4.1寻找理想的集成技术 微服务之间通信方式的选择非常多样化，但哪个是正确的呢？ SOAP? XML-RPC ? REST? Protocol Buffers ?后面会逐一讨论，但是在此之前需要考虑的是，我们到底希望 从这些技术中得到什么。 4.1.1避免破坏性修改 有时候，对某个服务做的一些修改会导致该服务的消费方也随之发生改变。后面会讨论如 何处理这种情形，但是我们希望选用的技术可以尽量避免这种情况的发生。比如，如果一 个微服务在一个响应中添加了一个字段，那么已有的消费方不应该受到影响。 4.1.2保证API的技术无关性 我很喜欢保持开放的心态，这也正是我喜欢微服务的原因。因此我认为，保证微服务之间 通信方式的技术无关性是非常重要的。这就意味着，不应该选择那种对微服务的具体实现 技术有限制的集成方式。 4.1.3使你的服务易于消费方使用 消费方应该能很容易地使用我们的服务。如果消费方使用该服务比登天还难，那么无论该 微服务多漂亮都没有任何意义。所以让我们考虑一下，如何让消费方简便地使用美妙的新 服务。理想情况下，消费方应该可以使用任何技术来实现，从另一方面来说

作者：洪春涛 链接：https://www.zhihu.com/question/25536695/answer/221638079 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 本地过程调用 RPC就是要像调用本地的函数一样去调远程函数。在研究RPC前，我们先看看本地调用是怎么调的。假设我们要调用函数Multiply来计算lvalue * rvalue的结果: 1 int Multiply(int l, int r) { 2 int y = l * r; 3 return y; 4 } 5 6 int lvalue = 10; 7 int rvalue = 20; 8 int l_times_r = Multiply(lvalue, rvalue); 那么在第8行时，我们实际上执行了以下操作： 将 lvalue 和 rvalue 的值压栈 进入Multiply函数，取出栈中的值10 和 20，将其赋予 l 和 r 执行第2行代码，计算 l * r ，并将结果存在 y 将 y 的值压栈，然后从Multiply返回 第8行，从栈中取出返回值 200 ，并赋值给 l_times_r 以上5步就是执行本地调用的过程。（20190116注：以上步骤只是为了说明原理。事实上编译器经常会做优化，对于参数和返回值少的情况会直接将其存放在寄存器

1.RPC： 远程过程调用，电脑A调用电脑B里面的程序即为RPC 广义上来讲：HTTP请求即为一种RPC 狭义上来讲：区别于http请求，使用自定义格式（自定义请求头请求体，响应头响应体）的二进制方式。我们更多谈到的RPC就是狭义的RPC。 2.RPC优缺点： 相比于传统的http： 优点：A.效率高；B.发起RPC调用的一方，在编写代码时可忽略RPC的具体实现，如同编写本地函数调用一样 缺点：通用性不如http好，因为传输的数据不是http协议格式，所以调用双方需要专门实现的通信库，对于不同的编程开发语言，都要有相关实现。而http作为一个标准协议，大部分的语言都已有相关的实现，通用性更好。 http更多的是面向用户与产品服务器的通讯；而RPC更多的是面向产品内部服务器间的通讯。 调用过程：client-sever----client stub--(network service)--server stub----server 红色部分是需要我们去实现的，看起来就像是客户端直接调用服务器那样子 RPC消息协议 实现RPC调用时，通讯双方传输的数据如何表达描述，设计时一般考虑2个目标 1.性能高：将原始数据转换为消息数据的速度快，转换后消息数据的体积小 2.跨语言：客户机可以用Python 服务器端可以用java 边界： 分隔符法：message body \r\n message

1. RPC 要求使用 POST 请求 2. 交互协议为 Json 格式 3. 请求地址组成 　　http://[节点 ip]:[rpc 端口号]，如：http://172.30.143.249:8336 4. 添加接口认证 5. 请求参数 {"jsonrpc":"2.0", "method": "omni_getinfo", "params":[283729]} jsonrpc：也可不用管（参数可有可无）。 method：请求的接口名（参数必须有），如：omni_getinfo、omni_listblocktransactions、omni_gettransaction ......。 params：接口参数（接口有参数时必须有对应参数输入，可有可无） 6. rpc 接口实现示例 使用工具 ApiPost 接口相关使用说明：https://github.com/OmniLayer/omnicore/blob/master/src/omnicore/doc/rpc-api.md 6.1 获取节点详情 参数：{"jsonrpc":"2.0", "method": "omni_getinfo", "params":[]} 或 {"method": "omni_getinfo"} 6.2 获取块中所有交易 hash 参数：{"method": "omni

分布式RPC框架 dubbo常见问题： 1. 问dubbo的工作原理：服务注册，注册中心，服务生产者，消费者，代理通信，负载均衡 2. 问网络通信，序列化： dubbo协议，长连接，NIO，hessian序列化协议 3. 问负载均衡策略，集群容错策略，动态策略：dubbo跑起来后一些功能是如何运转，怎么做复制均衡，怎么做容错，怎么生成动态代理？ 4. 问dubbo SPI机制：是否了解SPI机制？如何基于SPI机制对dubbo进行扩展？ 5. dubbo服务治理，超时，降级，重试等。 1. 为什么要进行系统拆分？ 项目大了，代码多了，很多代码冲突，代码合并维护困难。改一个地方，回归测试工作量很大。 大项目发布上线依赖很多外部东西，发布特别麻烦。 2. 如何进行拆分？ 系统拆分需要经过多轮拆分，不可能一次就拆分好了。考虑多少个人维护多少个服务。 3. 拆分后为什么要用 Dubbo, 不用 Dubbo 可以吗？ Dubbo 和 Thrift 有什么区别？ 可以不用。可以用纯基于Spring MVC，纯http接口相互通信，但是维护成本很高。 Dubbo已经在RPC做得很好了，成熟的RPC框架，本地就是进行接口调用，Dubbo代理调用请求，跟远程网络通信，处理负载均衡，超时重试等等功能。 4. 说一下的 Dubbo 的工作原理？注册中心挂了可以继续通信吗？说说发起一次 RPC 请求的流程

RPC（Remote Procedure Call）：远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想RPC 是一种技术思想而非一种规范或协议，常见 RPC 技术和框架有： 应用级的服务框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。 远程通信协议：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。 通信框架：MINA 和 Netty。 目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。 下面重点介绍三种： gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。 Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的。不过这个对于用户来说需要学习特定领域语言这个特性，还是有一定成本的。 Dubbo：是阿里集团开源的一个极为出名的 RPC 框架，在很多互联网公司和企业应用中广泛使用