rpc :分布式服务框架发展过程

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

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

 

rpc 前世今生 详细解说：

0：最开始服务之间没有远程调用，

1：发展着就发现，需要调用其它机器上的服务了，怎么调用呢？

不同的语言就有了各自的实现方式，

• ONC RPC （开放网络计算的远程过程调用），OSF RPC（开放软件基金会的远程过程调用）
• CORBA（Common Object Request Broker Architecture公共对象请求代理体系结构）
• DCOM（分布式组件对象模型），COM+
• Java RMI
• .NET Remoting

2：但是问题也来了，不同语言构造的系统之间如何互相调用呢？

2.1.0：这时候就出现了一种新思想 webservice ,他想的是把一个服务发布到某个特定的地方，其他各种语言的系统都可以调用，如何实现的呢？

他的想法是不同系统之间交互数据的时候，采用同一种数据格式xml,这样A服务请求b服务的时候，把特定格式的数据传递过去就可以了，

b服务就可以正确解析，并且可以正确解析了，这样就可以跨语言了，这个约定 或者协议称为 soap 协议。

soap 协议 可以基于http 协议传输数据，也可以基于ftp smtp 等其他协议传递数据，但是大多数都是基于http 。

2.1.1 ：但是问题又来了，客户端怎么知道该传递什么参数，远程服务器有哪些提供好的服务啊？

这就出现了另外一种接口说明文档 wsdl,用这种文档来说明  接口的详情。

• XML-RPC，SOAP，Web Service

web service 出现了一些优秀框架： 

Axis1 Axis2  Xfire cxf  

2.2.0 除了webservice 的思想，还有一部分的想法是，不同的语言之间 可以建立一种 第三方语言，大家可以建立自己的语言到这第三方语言的映射，

这样之后， 服务端和客户端 定义接口就可以用 第三方语言来定义 ， 然后 在通过 这个 第三方语言 （接口描述语言idl） 生成服务器端 和客户端的代码。

包括底层通信的代码，然后服务端部署到某个位置上，客户端就可以直接调用了。

• PHPRPC，Hessian，JSON-RPC

之后出现了一些更优秀的框架　：

• Microsoft WCF，WebAPI
• ZeroC Ice，Thrift，GRPC protocol buffer
• Hprose 

两种思想的优缺点比较：

首先，都实现了跨语言，这是可以称赞的。

webservice 的缺点： soap 协议 消息封装太复杂，采用xml 传输数据，网络消耗和 cpu 解析消耗都特别大，不适合传递大量数据，客户端需要生成很多stub 类。

rpc 框架 ：  传输数据多采用二进制格式 ，消息序列化和反序列化都比较快，网络消耗小，缺点是 客户端和服务端都要生成很多stub类。

如果 idl 做了修改， 还要重新生成一遍 stub 类。

 

3 后来出现soa 思想，所有的系统都开始大规模的服务化，随之而来的问题就是 服务越来越多，服务和服务之间调用越来越频繁，

对系统效率的要求 和 开发的简便性 要求越来越高，怎么解决这个问题？

 

服务越来越多问题：需要专门的注册中心做管理，服务之间的关系也需要做管理，服务治理成为了重中之重。

效率问题：　服务之间的数据传输格式，传输协议 都需要做 最优的选择，

开发怎么做到简单性 ：服务端书写了 服务 ，直接发布就行了，客户端也不用生成stub类就可以调用。

 

４　要求开发简单性　：

这时候出现了另外一种思想rest 

  REST特点：
     1. Rest是一种设计风格，不是一个标准。
     2. Rest通常使用HTTP,URI，XML，HTML等流行的协议和标准
     3. Rest是从资源的角度来观察网络的，而资源是由URI来指定的。
     4. Rest对资源的操作类型通常包括：获取，创建，删除和修改，这四种操作分别对应着HTTP协议请求的GET,POST,DELETE和PUT方法。
     5. 资源的表现形式可以为:XML,HTML,JSON的文本。
     6. Rest是服务端-客户端结构中的一种应用方法。
     7. Rest使用的是HTTP协议，因此是无状态的。

 

rest 想法很简单，我们用   客户端请求服务只需要 http协议　json 做数据格式, http原有的get post delete put 四个方法 做请求动作，

客户端只要有浏览器就可以获取到数据了，其他什么额外的协议都不需要。

传输的数据易于人们阅读，方便构造。

 

 

然后就出现了 restfull webservice ， 一些rpc 框架里也对rest 协议做了支持。

restfull webservice 和原来的soap webservice 相比 ，在性能，安全性 和开发简便性上都有了较大提高。

 

dubbox 框架 支持rest 协议，可以方便的实现rest　协议接口的发布和引用。

 

 

5 前瞻：

一个优秀的分布式服务框架应该是什么样的？

1 底层rpc速度快，可以nio 

2 协议选择 多样化  

3  数据格式多样 （如何二进制，则数据序列化和反序列化速度快，并且支持json,xml 等简单易读的格式 ）

4 服务治理 （服务监控，服务负载均衡，服务灰度升级，路由透明等。）+ 方便开发

5 容易部署，容易调用，不需要引入第三方包，或者生成stub 类。

 

总之 效率高，安全，简单，并且有服务治理的功能，这样的rpc 框架才是未来的选择。

 

 

早期的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 的规范太过复杂，以至于在 .NET 和 Java 平台以外没有真正好用的实现，甚至没有可用的实现。

PHPRPC

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

Hessian

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

 

protocol buffer

protocol buffer 是 google 的一种数据交换的格式，它独立于语言，独立于平台。google 提供了多种语言的实现：java、c++ 和 python等，每一种实现都包含了相应语言的编译器以及库文件。由于它是一种二进制的格式，比使用 xml 进行数据交换快许多。可以把它用于分布式应用之间的数据通信或者异构环境下的数据交换。
Protobuf只有一种序列化和反序列化的手段，并不涉及传输层
Protobuf序列化效率业界最高！

 

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 甚至支持推送。
• 具有良好的可扩展性，可以通过过滤器和中间件实现加密、压缩、缓存、代理等各种功能性扩展。
• 兼容的无差别跨语言调用
• 支持更多的常用语言和平台
• 支持浏览器端的跨域调用
• 没有中间语言，无需学习成本
• 性能卓越，使用简单