rpc

Dubbo是什么？ Dubbo[ ]是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。 其核心部分包含: 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 Dubbo能做什么？ 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 ---------------------------------------------------------------------------------------------------------------------------------------------------- **********************************

在阿里的平台技术部参与开发了Dubbo（远程调用服务）和Napoli（消息解决方案），又给网站应用支持这2个产品2年，了解了这2个产品的实现及应用对这两个产品的用法。 大部分情况下，“给定场景下应该使用这两个产品中哪个”这个问题，大家都会容易决定，而且不需要多少讨论。 我为什么要拿出来讨论一下： 一些场景会比较模糊，觉得都可以使用。这时需要知道产品缺点，而不是看到优势。 一些新人会觉得产品功能是可以替换的，要给说明一下。 这里简单说一下两者的区别。 系统结构 1 2 3 4 5 6 7 8 9 10 11 12 13 14 RPC系统结构： +----------+ +----------+ | Consumer | <=> | Provider | +----------+ +----------+ Consumer调用的Provider提供的服务。 Message Queue系统结构： +--------+ +-------+ +----------+ | Sender | <=> | Queue | <=> | Receiver | +--------+ +-------+ +----------+ Sender发送消息给Queue；Receiver从Queue拿到消息来处理。 功能特点 在架构上，RPC和Message的差异点是，Message有一个中间结点Message

声明 本文转自 https://developer.51cto.com/art/201906/597963.htm 什么是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 等。 常用的RPC框架 gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。 Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的

思路： 注册中心 首先是要有的，推荐使用 Zookeeper 。 注册中心主要用来保存相关的信息比如远程方法的地址 。 既然要要互相调用方法就要 发请求，推荐nio 的 netty框架 。 发请求发送什么数据呢？我们就要考虑 序列化协议 了。 另外， 动态代理 也是需要的。因为 RPC 的主要目的就是让我们调用远程方法像调用本地方法一样简单，使用动态代理屏蔽远程接口调用的细节比如网络传输。 负载均衡 也是需要的。为啥？举个例子我们的系统中的某个服务的访问量特别大，我们将这个服务部署在了多台服务器上，当客户端发起请求的时候，多台服务器都可以处理这个请求。那么，如何正确选择处理该请求的服务器就很关键。假如，你就要一台服务器来处理该服务的请求，那该服务部署在多台服务器的意义就不复存在了。 负载均衡就是为了避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题 。 来源： oschina 链接： https://my.oschina.net/u/4167465/blog/3217397

RPC介绍 先官方的给大家介绍几句 ：RPC是远程过程调用（Remote Procedure Call）的缩写形式。SAP系统RPC调用的原理其实很简单，有一些类似于三层构架的C/S系统，第三方的客户程序通过接口调用SAP内部的标准或自定义函数，获得函数返回的数据进行处理后显示或打印。 名词解释: 远程过程调用 远程过程 ,调用 名词解释: 远程过程 消费者调用后台提供者方法时,后台的执行业务的过程. 定义:分布式系统中系统之间的通信的方式称之为RPC,远程过程调用。无需关注通信具体协议细节.可以利用RPC工具直接获取远程服务器数据。 通熟的讲就是 ： 本地调用某个函数方法; 本地机器的RPC框架把这个调用信息 封装 起来（调用的函数、入参等）， 序列化 (json、xml等)后，通过网络传输发送给远程服务器; 远程服务器收到调用请求后，远程机器的RPC框架 反序列化获得调用信息 ，并根据调用信息定位到实际要执行的方法，执行完这个方法后，序列化执行结果，通过网络传输把执行结果发送回本地机器; 本地机器的RPC框架反序列化出执行结果，函数 return 这个结果。 服务调用端（本地机器） : 服务提供端（远程机器） ： 当然我这还有一种特通俗的讲法 “老公，什么是RPC呀，为什么你们程序员那么多黑话！”，老婆还是一如既往的好奇。 “RPC，就是Remote Procedure

声明 本文转自https://developer.51cto.com/art/201906/597963.htm 什么是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 等。 常用的RPC框架 gRPC：是 Google 公布的开源软件，基于最新的 HTTP 2.0 协议，并支持常见的众多编程语言。RPC 框架是基于 HTTP 协议实现的，底层使用到了 Netty 框架的支持。 Thrift：是 Facebook 的开源 RPC 框架，主要是一个跨语言的服务开发框架。 用户只要在其之上进行二次开发就行，应用对于底层的 RPC 通讯等都是透明的