rpc

　　RPC是什么？远程过程调用，过程就是业务处理、计算任务，像调用本地方法一样调用远程的过程。 　　RMI和RPC的区别是什么？RMI是远程方法调用，是oop领域中RPC的一种实现，我们熟悉的restfull和webservice都是RPC，仅仅消息的组织方式和消息协议不同。 　　RPC调用过程 ： 　　 1、客户端处理过程中调用client sub(像调用本地方法一样)，传递参数 　　2、client sub将参数编组为消息，然后通过系统调用想服务端发送消息 　　3、客户端本地操作系统将消息发送给服务端 　　4、服务端操作系统将收到的消息包传给server sub， 　　5、server sub解组消息为参数 　　6、server sub 调用本地服务，执行结果以反方向相同步骤返回给客户端 　　RPC协议 消息由哪些部分构成及消息的表示形式就构成了消息协议，RPC调用过程中采用的消息协议称为RPC协议，可以使用通用的协议(http、https)，也可以自定义协议 　　RPC框架 封装好参数编组、消息解组、底层通信的RPC程序开发框架，可以在其基础上只需专注于过程代码编写，例如常用的dubbo和springcloud。 　　实现RPC的要点有：消息编组解组、服务注册发现和底层通信，本次基于JDK序列化编组解组消息

1. NFS I/O性能测试工具 1.1 dd dd 只能测试连续读写性能 dd 测试写性能的命令(连续写16384个16KB的块到nfs目录下的testfile文件) # time dd if=/dev/zero of=/nfsfolder/testfile bs=16k count=16384 dd 测试读性能的命令 # time dd if=/nfsfolder/testfile of=/dev/null bs=16k 1.2 nfsstat 在NFS客户端运行 nfsstat -4 --all (对于NFSv4) Client packet stats: packets udp tcp tcpconn 0 0 0 0 Client rpc stats: calls retrans authrefrsh 24932703 9 0 Client nfs v4: null read write commit open open_conf 0 0% 19359418 77% 513478 2% 513295 2% 1880475 7% 9 0% open_noat open_dgrd close setattr fsinfo renew 0 0% 0 0% 1209733 4% 0 0% 4 0% 0 0% setclntid confirm lock lockt locku

最近，开源社区发生了一件大事，那个全国 Java 开发者使用最广的开源服务框架 Dubbo 低调重启维护，并且 3 个月连续发布了 4 个维护版本。 我上次在写 放弃Dubbo，选择最流行的Spring Cloud微服务架构实践与经验总结 这篇文章的时候，就有很多的网友给我留言说，Dubbo 又开始更新了。我当然是清楚的，我也一直在关注着 Dubbo 的走向，在几个月前技术圈里面就有一个消息说是 Dubbo 又开始更新了，大家议论纷纷不知真伪。我还专门跑到 GitHub 上面进行了留言询问，最后在 Dubbo 的 gitter 聊天室里面找到了确信的答案，说是正在组建团队。虽然稍稍有所期待，但也不知道阿里这次拿出了多少的诚意来做这件事，于是我昨天又到 GitHub 逛了一下，发现从 9 月开始，阿里三个月连着发布了四个版本，还是非常有诚意的，值得关注。 Dubbo简介 Dubbo 是阿里巴巴公司一个开源的高性能服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案，使得应用可通过高性能 RPC 实现服务的输出、输入功能和 Spring 框架无缝集成。Dubbo 包含远程通讯、集群容错和自动发现三个核心部分。 它提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何 API 侵入。同时它具备软负载均衡及容错机制

某厂面试归来，发现自己落伍了！>>> RPC 简介 RPC（Remote Procedure Call）——远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的细节的技术。 通过RPC我们可以充分利用非共享内存的多处理器环境（例如通过局域网连接得多台工作站）,这样可以简便地将你的应用分布在多台工作站上，应用程序就像运行在一个多处理器的计算机上一样。你可以方便的实现过程代码共享，提高系统资源的利用率，也可以将以大量数值处理的操作放在处理能力较强的系统上运行，从而减轻前端机的负担。 在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。 RPC 的主要目的是为组件提供一种相互通信的方式，使这些组件之间能够相互发出请求并传递这些请求的结果。 RPC 调用过程 客户机对服务器的一次RPC调用,其内部操作大致有如下十步： 1.调用客户端句柄；执行传送参数 2.调用本地系统内核发送网络消息 3.消息传送到远程主机 4.服务器句柄得到消息并取得参数 5.执行远程过程 6.执行的过程将结果返回服务器句柄 7.服务器句柄返回结果，调用远程系统内核 8.消息传回本地主机 9.客户句柄由内核接收消息 10.客户接收句柄返回的数据 RPC 的应用场景 RPC 在分布式系统中的系统环境建设和应用程序设计中有着广泛韵应用

某厂面试归来，发现自己落伍了！>>> Spark的RPC 一步一步走下去： RpcAddress RpcEndPointRef 当我们需要向一个具体的RpcEndpoint发送消息时，一般我们需要获取到该RpcEndpoint的引用，然后通过该应用发送消息。 部分方法： RpcEnv RpcEnv的部分方法： RpcEndpoint 正如他所说我们前去看他的生命周期： 那么RpcEndpoint表示一个个需要通信的个体都有哪些？如master，worker，driver Driver这里就不在做演示了，有兴趣的可以自行进入源码中查看。 在调用中，我们发现了一个RpcCallContext的特性，在receiveAndReply被作为参数。 所以关注了一下他： 整片博客中由许多方法，类并未列出，看时做一个参考即可。在自己的idea中查看源码。仅做一个引导。 瞎琢磨一阵，做个小总结： 打个比喻：若是将Spark类比为一个人的话，Spark RPC无疑就是它的血液部分。所以说Spark RPC可以说是Spark分布式集群的基础。 在整个RPC中： RpcEnv为RpcEndpoint提供处理消息的环境。RpcEnv负责RpcEndpoint整个生命周期的管理，包括：注册endpoint，endpoint之间消息的路由，以及停止endpoint。

在 微服务集成——《微服务设计》读书笔记 文章中，我们说过服务间的消息传递有几种方式，一种是请求/响应技术，另一种是基于事件的机制。 RPC（远程过程调用） RPC是Remote Procedure Call的简称。 这是请求/响应技术的一种，它使用本地调用的方式和远程进行交互，如SOAP、Thrift等，比如我们常使用的WebService和Java RMI，就是这种类型。它先在本地生成桩代码，然后通过桩代码进行远程调用。 RPC会带来一些问题，如Java RMI，其耦合性较紧，同时RPC会对调用进行大量的封装和解封装，同时修改接口时会造成服务的提供方和调用方都要修改。 REST REST是受Web启发而产生的一种架构风格，REST风格包含的内容很多，Richardson的成熟度模型（http://martinfowler.com/articles/richardsonMaturityModel.html），其中有对REST不同风格的比较。 REST本身并没有提到底层应该使用什么协议，最常用的是HTTP，HTTP本身提供了很多功能，这些功能对于实现REST风格非常有用，比如HTTP的动词（GET、POST、PUT等）就能很好地和资源一起使用。 在使用REST时，传输的数据格式是XML还是JSON，这个没有一个定论。 基于HTTP的REST也有缺点：1.它无法帮你生成桩代码，2

RESTful 是目前最为流行的一种互联网软件结构。因为它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。 什么是 REST REST（REpresentational State Transfer），首次出现在 2000 年 Roy Thomas Fielding 的博士论文中，它指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful 的。 资源（Resources），REST 是“表现层状态转化”，其实它省略了主语。“表现层”其实指的是“资源”的“表现层”。那么什么是资源呢？我们平时网上访问到图片、文字、文档、多媒体等就是资源，一般通过 URI 来定位。也就是说，一个 URI 就表示一个资源。 表现层（Representation），资源是作为一个具体的实体信息，它可以有多种的展现方式。而把实体展现出来就是表现层。例如一个 txt 文本信息，它可以输出成 html、json 等。 状态转化（State Transfer），访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，就涉及到数据和状态的变化。而 HTTP 协议是无状态的，那么这些状态肯定保存在服务器端，所以如果客户端想要通知服务器端改变数据和状态的变化，就要通过某种方式来通知它。客户端能通知服务器端的手段，只能是 HTTP 协议。具体来说，就是

最近，开源社区发生了一件大事，那个全国 Java 开发者使用最广的开源服务框架 Dubbo 低调重启维护，并且 3 个月连续发布了 4 个维护版本。 我上次在写 放弃Dubbo，选择最流行的Spring Cloud微服务架构实践与经验总结 这篇文章的时候，就有很多的网友给我留言说，Dubbo 又开始更新了。我当然是清楚的，我也一直在关注着 Dubbo 的走向，在几个月前技术圈里面就有一个消息说是 Dubbo 又开始更新了，大家议论纷纷不知真伪。我还专门跑到 GitHub 上面进行了留言询问，最后在 Dubbo 的 gitter 聊天室里面找到了确信的答案，说是正在组建团队。虽然稍稍有所期待，但也不知道阿里这次拿出了多少的诚意来做这件事，于是我昨天又到 GitHub 逛了一下，发现从 9 月开始，阿里三个月连着发布了四个版本，还是非常有诚意的，值得关注。 Dubbo简介 Dubbo 是阿里巴巴公司一个开源的高性能服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案，使得应用可通过高性能 RPC 实现服务的输出、输入功能和 Spring 框架无缝集成。Dubbo 包含远程通讯、集群容错和自动发现三个核心部分。 它提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何 API 侵入。同时它具备软负载均衡及容错机制

　　新项目推送到服务器时报错： error: RPC failed; result=22, HTTP code = 413| 7.66 MiB/s fatal: The remote end hung up unexpectedly 　　查了下，属于项目中有大文件，而http推送限制造成的，需要修改服务器配置。因为git服务器是通过nginx做反向代理之后实现的，因此需要修改nginx和appache（git服务器）： 1、nginx服务器配置：/etc/nginx/conf.d/default.conf中的server小节加入：client_max_body_size 100m; 2、apache配置：/etc/httpd/conf.d/git.conf中对应Location小节中加入：LimitRequestBody 52428800 来源： https://www.cnblogs.com/badwood316/p/6600991.html

手写一个高性能的rpc框架 模拟服务端，运行main函数，相当于启动服务器 public class ServerApplication { public static void main(String[] args) throws Exception { //开启服务端，然后等待客户端发出请求，然后给客户端响应数据，但如果这些操作都写在，会使代码不好维护，因此，将其抽象化，抽象出 //一个工厂类，专门来做这样的操作。 //因此需要一个专门来处理提供者类的工厂类,此类需要提供一个初始化方法、一个开始/停止服务的方法、（如果要加注册中心的话还需要一个添加服务的方法） } } 提供者工厂类 public class XxlRpcProviderFactory { //初始化方法（相当于一个构造器）里面的参数，就是开启服务需要的参数 /** * * @param netType 网络通信方式 * @param serializer 序列化方式 * @param ip ip地址 * @param port 端口号 * @param accessToken 接收token（如果有） * @param serviceRegistryClass 注册中心类 （可先不要） * @param serviceRegistryParam 注册中心参数 （可先不要） */ public void init