rpc

很长时间以来都没有怎么好好搞清楚RPC（即Remote Procedure Call，远程过程调用）和HTTP调用的区别，不都是写一个服务然后在客户端调用么？这里请允许我迷之一笑~Naive！本文简单地介绍一下两种形式的C/S架构，先说一下他们最本质的区别，就是RPC主要是基于TCP/IP协议的，而HTTP服务主要是基于HTTP协议的，我们都知道HTTP协议是在传输层协议TCP之上的，所以效率来看的话，RPC当然是要更胜一筹啦！下面来具体说一说RPC服务和HTTP服务。 OSI网络七层模型 在说RPC和HTTP的区别之前，我觉的有必要了解一下OSI的七层网络结构模型（虽然实际应用中基本上都是五层），它可以分为以下几层： （从上到下） 第一层：应用层。定义了用于在网络中进行通信和传输数据的接口； 第二层：表示层。定义不同的系统中数据的传输格式，编码和解码规范等； 第三层：会话层。管理用户的会话，控制用户间逻辑连接的建立和中断； 第四层：传输层。管理着网络中的端到端的数据传输； 第五层：网络层。定义网络设备间如何传输数据； 第六层：链路层。将上面的网络层的数据包封装成数据帧，便于物理层传输； 第七层：物理层。这一层主要就是传输这些二进制数据。 实际应用过程中，五层协议结构里面是没有表示层和会话层的。应该说它们和应用层合并了。我们应该将重点放在应用层和传输层这两个层面

跨语言的rpc框架 新建一个thrift文件 # ping service demoservice PingService { string ping(), ping函数的返回类型是字符串}server.py # -*- coding: utf-8 -*- import thriftpy from thriftpy.rpc import make_server pp_thrift = thriftpy.load("pingpong.thrift", module_name="pp_thrift") class Dispatcher(object): def ping(self): print("ping pong!") return 'pong' def main(): server = make_server(pp_thrift.PingService, Dispatcher(), '0.0.0.0', 6000) print("serving...") server.serve() if __name__ == '__main__': main() client.py # -*- coding: utf-8 -*- import thriftpy from thriftpy.rpc import client_context pp_thrift = thriftpy.load(

一： wiki：https://zh.wikipedia.org/wiki/Thrift 二： 来自IBM的介绍：https://www.ibm.com/developerworks/cn/java/j-lo-apachethrift/ 都是框架原理，不适合快速上手应用。 摘要： 　　1： thritf 即不是 SOAP，也不是JSON。 目前流行的服务调用方式有很多种，例如基于 SOAP 消息格式的 Web Service，基于 JSON 消息格式的 RESTful 服务等。 三： tutorial https://thrift.apache.org/tutorial/ 很奇怪，还有一个tutorial从官网链接不到：http://thrift-tutorial.readthedocs.io/en/latest/intro.html 摘要： Thrift was originally developed by Facebook and now it is open sourced as an Apache project. 开发动因，以及设计时的思路选择： http://thrift.apache.org/static/files/thrift-20070401.pdf 在设计上，分类为五个方面的问题：　type, transport, protocol, versioning,

-------客户端程序 ------ 下载 下载 thrift 源代码包 下载 thrift 的bin包 准备描述文件（使用源代码包的示例文件） \thrift-0.10.0\tutorial\shared.thrift \thrift-0.10.0\tutorial\tutorial.thrift 根据描述文件生成代码 thrift-0.10.0.exe -r -o lib_client --gen php idl-dir/tutorial.thrift 从thrift源代码包中拷贝 php的库 \thrift-0.10.0\lib\php\lib 编写客户端代码 （使用源代码包的示例文件、并修改） \thrift-0.10.0\tutorial\php\PhpClient.php 来源： https://www.cnblogs.com/xiaoyaogege/p/6567394.html

-------服务端程序 ------ 下载 下载 thrift 源代码包 下载 thrift 的bin包 准备描述文件（使用源代码包的示例文件） \thrift-0.10.0\tutorial\shared.thrift \thrift-0.10.0\tutorial\tutorial.thrift 根据描述文件生成代码 thrift-0.10.0.exe -r -o lib_server --gen php:server idl-dir/tutorial.thrift 从thrift源代码包中拷贝 php的库 \thrift-0.10.0\lib\php\lib 编写服务端代码（使用源代码包的示例文件、并修改） \thrift-0.10.0\tutorial\php\PhpServer.php 来源： https://www.cnblogs.com/xiaoyaogege/p/6567386.html

1. 环境搭建 1.1 拷贝源码 git clone https://github.com/sofastack/sofa-rpc.git 1.2 编译源码 在源码目录执行 mvn clean install -DskipTests 注意，安装java的版本为1.8，用java11编译会报错 1.3 运行样例 1.3.1 启动服务器 找到类 com.alipay.sofa.rpc.bolt.start.BoltServerMain 运行main方法 public static void main(String[] args) { ApplicationConfig application = new ApplicationConfig().setAppName("test-server"); ServerConfig serverConfig = new ServerConfig() .setPort(22000) .setDaemon(false); ProviderConfig<HelloService> providerConfig = new ProviderConfig<HelloService>() .setInterfaceId(HelloService.class.getName()) .setApplication(application) .setRef(new

摘自： https://www.cnblogs.com/yangyuanhu/p/12439106.html Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 2 | 0 什么是RPC RPC全称(Remote Procedure Call)远程过程调用 过程指的是某个代码片段的执行,远程调用则意味着我们可以在其他进程,甚至其他机器上去调用这段代码,当然也能获取到其执行后的返回值,按照这个定义,我们请求某个http地址得到相应数据其实也算一次RPC,但是这样的方式太过麻烦,(数据要先打包成http请求格式,在调用相关的请求库,拿到的结果也是文本格式的需要在进行转换),执行效率,和开发效率相比RPC则低一些; 我们需要一种更简单的方式来完成分布式开发中的RPC环节,这也是Dubbo的核心所在,有多简单呢? 调用远程服务器上的某个服务时就像是调用本地的某个方法一样简单,就像下面这样 2 | 1 为什么需要rpc RPC是用来实现分布式构架的基石,分布式构架将同一个系统中的不同模块拆分到不同的子系统中,而子系统又分布在不同的服务器上,这时就需要RPC在来完成子系统之间的相互访问; 可以这么说分布式少不了RPC,RPC也要在分布式系统中才能发挥其核心价值; 2 | 2 rpc的实现原理

1.Dubbo介绍 Dubbo,一个是一款高性能Java RPC框架.私以为有 中文官方文档 ，就不再重复介绍了 2.RPC扩展-本地存根stub RPC扩展功能：提前效验参数，缓存调用结果，日志记录等等，可以使用AOP织入这些扩展功能，但Dubbo提供了更灵活简单的实现-本地存根stub。 3.本地Mock-本地伪装mock RPC在服务异常时，请求返回mock的(假)数据，而不是简单的抛出异常，达到服务降级和本地mock的效果.只有在服务抛出异常时才会调用。 4.调用流程 服务消费者发起调用 如果服务消费者端存在本地存根 Stub 的话，会先执行本地存根 本地存根 Stub 持有远程服务的 Proxy 对象，Stub 在执行的时候，会先执行自己的逻辑 (before)，然后通过 Proxy 发起远程调用，最后在返回过程之前也会执行自己的逻辑 (after-returning) 如果远程服务的 Proxy 对象在执行过程中抛出了 exception，会执行服务消费端的本地伪装 Mock 的逻辑 (after-throwing)，返回容错数据，从而达到服务降级的目的 5.本地存根实例 定义一个demo接口 public interface DemoService { String sayHello(String name); } 根据约定大于配置原则，实现一个demo的stub实例

这两天研究了一下，OpenStack的工作原理，并着重调研了一下RabbitMQ在OpenStack中扮演的角色。 首先，OpenStack中模块Volume Control、Network Controller、ComputeController以及Scheduler之间的通信是通过AMQP协议实现，消息由RabbitMQ作为中间件转发，以一种RPC（Remote Process Call）的方式进行的。具体可见图 其中用户在dashboard中进行的操作通过Nova.api、Glance.api等调用Volume、Network、ComputeController等模块，上图中是一个逻辑结构，可以看出这种基于RPC的松耦合调用可以不用关心某些模块是否在本机，Openstack的多个模块间可以轻易以分布式的方式解决。 以Nova为例，每一个Nova服务都会在初期建立两个队列，两个队列同时与相同的exchange（名称叫做Nova、类型为Topic）绑定，但是二者的RoutingKey不同也就是Topic不同，格式分别为NODE-TYPE.NODE-ID以及NODE-TYPE，其二者功能也有所不同，并且由于采用RPC结构，所以当操作完成，结果会以Direct的方式回复给服务调用方。该流程是RabbitMQ在Openstack中实现的核心思想，具体图示如下：

这两天研究了一下，OpenStack的工作原理，并着重调研了一下RabbitMQ在OpenStack中扮演的角色。 首先，OpenStack中模块Volume Control、Network Controller、ComputeController以及Scheduler之间的通信是通过AMQP协议实现，消息由RabbitMQ作为中间件转发，以一种RPC（Remote Process Call）的方式进行的。具体可见图 其中用户在dashboard中进行的操作通过Nova.api、Glance.api等调用Volume、Network、ComputeController等模块，上图中是一个逻辑结构，可以看出这种基于RPC的松耦合调用可以不用关心某些模块是否在本机，Openstack的多个模块间可以轻易以分布式的方式解决。 以Nova为例，每一个Nova服务都会在初期建立两个队列，两个队列同时与相同的exchange（名称叫做Nova、类型为Topic）绑定，但是二者的RoutingKey不同也就是Topic不同，格式分别为NODE-TYPE.NODE-ID以及NODE-TYPE，其二者功能也有所不同，并且由于采用RPC结构，所以当操作完成，结果会以Direct的方式回复给服务调用方。该流程是RabbitMQ在Openstack中实现的核心思想，具体图示如下：