帮助phper理解RPC是怎么回事儿

1.什么是rpc

RPC全称为Remote Procedure Call，翻译过来为“远程过程调用”。

目前，主流的平台中都支持各类远程调用技术，以知足分布式系统架构中不一样的系统之间的远程通讯和相互调用。远程调用的应用场景极其普遍，实现的方式也各式各样。

2.从通讯协议的层面

基于HTTP协议的（例如基于文本的SOAP（XML）、Rest（JSON），基于二进制Hessian（Binary））

基于TCP协议的（一般会借助Mina、Netty等高性能网络框架）

RPC(远程过程调用)是什么

• 简单的说，RPC就是从一台机器（客户端）上经过参数传递的方式调用另外一台机器（服务器）上的一个函数或方法（能够统称为服务）并获得返回的结果。
• RPC 会隐藏底层的通信细节（不须要直接处理Socket通信或Http通信）
• RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（相似于Http的工做方式）
• RPC 在使用形式上像调用本地函数（或方法）同样去调用远程的函数（或方法）。

远程过程调用发展历程

• ONC RPC （开放网络计算的远程过程调用），OSF RPC（开放软件基金会的远程过程调用）
• CORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）
• DCOM（分布式组件对象模型），COM+
• Java RMI
• .NET Remoting
• XML-RPC，SOAP，Web Service
• PHPRPC，Hessian，JSON-RPC
• Microsoft WCF，WebAPI
• ZeroC Ice，Thrift，GRPC
• Hprose

早期的 RPC

• 第一代 RPC（ONC RPC，OSF RPC）不支持对象的传递。
• CORBA 太复杂，各类不一样实现不兼容，通常程序员也玩不转。
• DCOM，COM+ 逃不出 Windows 的手掌心。
• RMI 只能在 Java 里面玩。
• .NET Remoting 只能在 .NET 平台上玩。

XML-RPC，SOAP，WebService

• 冗余数据太多，处理速度太慢。
• RPC 风格的 Web Service 跨语言性不佳，而 Document 风格的 Web Service 又太过难用。
• Web Service 没有解决用户的真正问题，只是把一个问题变成了另外一个问题。
• Web Service 的规范太过复杂，以致于在 .NET 和 Java 平台之外没有真正好用的实现，甚至没有可用的实现。
• 跨语言跨平台只是 Web Service 的一个口号，虽然不少人迷信这一点，但事实上它并无真正实现。

PHPRPC

• 基于 PHP 内置的序列化格式，在跨语言的类型映射上存在硬伤。
• 通信上依赖于 HTTP 协议，没有其它底层通信方式的选择。
• 内置的加密传输既是特色，也是缺点。
• 虽然比基于 XML 的 RPC 速度快，但还不是足够快。

Hessian

• 二进制的数据格式彻底不具备可读性。
• 官方只提供了两个半语言的实现（Java，ActionScript 和不怎么完美的 Python 实现），其它语言的第三方实现参差不齐。
• 支持的语言不够多，对 Web 前端的 JavaScript 彻底无视。
• 虽然是动态 RPC，但动态性仍然欠佳。
• 虽然比基于 XML 的 RPC 速度快，但还不是足够快。

JSON-RPC

• JSON 具备文本可读性，且比 XML 更简洁。
• JSON 受 JavaScript 语言子集的限制，可表示的数据类型不够多。
• JSON 格式没法表示数据内的自引用，互引用和循环引用。
• 某些语言具备多种版本的实现，但在类型影射上没有统一标准，存在兼容性问题。
• JSON-RPC 虽然有规范，可是却没有统一的实现。在不一样语言中的各自实现存在兼容性问题，没法真正互通。

Microsoft WCF，WebAPI

• 它们是微软对已有技术的一个 .NET 平台上的统一封装，是对 .NET Remoting、WebService 和基于 JSON 、XML 等数据格式的 REST 风格的服务等技术的一个整合。
• 虽然号称能够在 .NET 平台之外来调用它的这些服务，但实际上跟在 .NET 平台内调用彻底是两码事。它没有提供任何在其余平台的语言中可使用的任何工具。

ZeroC Ice，Thrift，GRPC

• 初代 RPC 技术的跨语言面向对象的回归。
• 仍然须要经过中间语言来编写类型和接口定义。
• 仍然须要用代码生成器来将中间语言编写的类型和接口定义翻译成你所使用的编程语言的客户端和服务器端的占位程序（stub）。
• 你必需要基于生成的服务器代码来单独编写服务，而不能将已有代码直接做为服务发布。
• 你必需要用生成的客户端代码来调用服务，而没有其它更灵活的方式。
• 若是你的中间代码作了修改，以上全部步骤你都要至少重复一遍。

Hprose

• 无侵入式设计，不须要单独定义类型，不须要单独编写服务，已有代码能够直接发布为服务。
• 具备丰富的数据类型和完美的跨语言类型映射，支持自引用，互引用和循环引用数据。
• 支持众多传输方式，如 HTTP、TCP、Websocket 等。
• 客户端具备更灵活的调用方式，支持同步调用，异步调用，动态参数，可变参数，引用参数传递，多结果返回（Golang）等语言特征，Hprose 2.0 甚至支持推送。
• 具备良好的可扩展性，能够经过过滤器和中间件实现加密、压缩、缓存、代理等各类功能性扩展。
• 兼容的无差异跨语言调用
• 支持更多的经常使用语言和平台
• 支持浏览器端的跨域调用
• 没有中间语言，无需学习成本
• 性能卓越，使用简单

RPC与Socket有什么区别？

二者都是调用远程的方法，都是client/server模式。

RPC（远程过程调用）采用客户机/服务器模式实现两个进程之间相互通讯。socket是RPC常常采用的通讯手段之一，RPC是在Socket的基础上实现的，它比socket须要更多的网络和系统资源。除了Socket，RPC还有其余的通讯方法，好比：http、操做系统自带的管道等技术来实现对于远程程序的调用。微软的Windows系统中，RPC就是采用命名管道进行通讯。

RPC与REST有什么区别？

经过了解RPC后，咱们知道是RPC是client/server模式的，调用远程的方法，REST也是咱们熟悉的一套API调用协议方法，它也是基于client/server模式的，调用远程的方法的，那他俩又有啥区别呢？

REST API 和 RPC 都是在 Server端 把一个个函数封装成接口暴露出去，以供 Client端 调用，不过 REST API 是基于HTTP协议的，REST致力于经过http协议中的POST/GET/PUT/DELETE等方法和一个可读性强的URL来提供一个http请求。而 RPC 则能够不基于 HTTP协议

所以，若是是后端两种语言互相调用，用 RPC 能够得到更好的性能（省去了 HTTP 报头等一系列东西），应该也更容易配置。若是是前端经过 AJAX 调用后端，那么用 REST API 的形式比较好（由于不管如何也避不开 HTTP 这道坎）。

一、HTTP和RPC同一级别，仍是被RPC包含？

二、Restful也属于RPC么？

上图是一个比较完整的关系图，这时咱们发现HTTP（图中蓝色框）出现了两次。其中一个是和RPC并列的，都是跨应用调用方法的解决方案；另外一个则是被RPC包含的，是RPC通讯过程的可选协议之一。

所以，第一个问题的答案是都对。看指的是哪个蓝色框。从题主的提问看，既然题主在纠结这二者，应该是指与RPC并列的蓝色框。

第二个问题是在问远程过程调用（红色框）是否是包含了Restful（黄色框），这种理解的关键在于对RPC的理解。

RPC字面理解是远程过程调用，即在一个应用中调用另外一个应用的方法。那Restful是知足的，经过它能够实如今一个应用中调用另外一个应用的方法。

可是，上述理解使得RPC的定义过于宽泛。RPC一般特指在一个应用中调用另外一个应用的接口而实现的远程调用，即红色框所指的范围。这样，RPC是不包含Restful的。

所以，第二个问题的答案是Restful不属于RPC，除非对RPC有着很是规的宽泛理解。

RPC的英文全称是Remote Procedure Call，翻译为中文叫“远程过程调用”。其中稍显晦涩的其实就是“过程”，过程其实就是方法。因此，能够把RPC理解为“远程方法调用”。

要了解远程过程调用，那先理解过程调用。很是简单，以下图，就是调用一个方法。这太常见了，很少解释。

而在分布式系统中，由于每一个服务的边界都很小，颇有可能调用别的服务提供的方法。这就出现了服务A调用服务B中方法的需求，即远程过程调用。

要想让服务A调用服务B中的方法，最早想到的就是经过HTTP请求实现。是的，这是很常见的，例如服务B暴露Restful接口，而后让服务A调用它的接口。基于Restful的调用方式由于可读性好（服务B暴露出的是Restful接口，可读性固然好）并且HTTP请求能够经过各类防火墙，所以很是不错。

然而，如前面所述，基于Restful的远程过程调用有着明显的缺点，主要是效率低、封装调用复杂。当存在大量的服务间调用时，这些缺点变得更为突出。

服务A调用服务B的过程是应用间的内部过程，牺牲可读性提高效率、易用性是可取的。基于这种思路，RPC产生了。

经过hprose实现rpc

HPROSE 是 High Performance Remote Object Service Engine 的缩写，翻译成中文就是“高性能远程对象服务引擎”。

它是一个先进的轻量级的跨语言跨平台面向对象的高性能远程动态通信中间件。它不只简单易用，并且功能强大。你只须要稍许的时间去学习，就能用它轻松构建跨语言跨平台的分布式应用系统了。

Hprose 支持众多流行的编程语言，例如：

• AAuto Quicker
• ActionScript
• ASP
• C++
• Delphi/Free Pascal
• dotNET(C#, Visual Basic...)
• Golang
• Java
• JavaScript
• Node.js
• Objective-C
• Perl
• PHP
• Python
• Ruby

经过 Hprose，你就能够在这些语言之间方便高效的实现互通了。

基础实现

在同一个文件夹下，执行一下操做，分别是拉取组建的命令，建立两个文件和执行php文件。

拉取hprose组件

composer require hprose/hprose

创建server.php

<?php

require_once "./vendor/autoload.php";

use HproseSocketServer;

function hello($name) {

return "Hello $name!";

}

$server = new Server("tcp://0.0.0.0:1314");

$server->setErrorTypes(E_ALL);

$server->setDebugEnabled();

$server->addFunction('hello');

$server->start();

创建client.php

<?php

require_once "./vendor/autoload.php";

use HproseFuture;

use HproseSocketClient;

$test = new Client("tcp://127.0.0.1:1314");

$test->fullDuplex = true;

Futureco(function() use ($test) {

try {

var_dump((yield $test->hello("yield world1")));

var_dump((yield $test->hello("yield world2")));

var_dump((yield $test->hello("yield world3")));

var_dump((yield $test->hello("yield world4")));

var_dump((yield $test->hello("yield world5")));

var_dump((yield $test->hello("yield world6")));

}

catch (Exception $e) {

echo ($e);

}

});

执行

php server.php

php client.php

结果

string(19) "Hello yield world1!"

string(19) "Hello yield world2!"

string(19) "Hello yield world3!"

string(19) "Hello yield world4!"

string(19) "Hello yield world5!"

string(19) "Hello yield world6!"

可继续学习：

Hprose for PHP 用户手册

本文摘自：
https://www.kancloud.cn/marti...