从RPC开始

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了从RPC开始相关的知识,希望对你有一定的参考价值。

这是一篇关于纯C++RPC框架的文章。所以,我们先看看,我们有什么?

  1、一个什么都能干的C++。(前提是,你什么都干了)

  2、原始的Socket接口,还是C API。还得自己去二次封装...

  3、C++11,这是最令人兴奋的。有了它,才能够有这篇文章;否则,CORBA之类的才是唯一的选择。(因为需要代码生成)

 

那么,我们没有什么,或者需要什么?

  1、一套完善的序列化框架;在不同的进程间传输数据,序列化是第一步,如何可靠且方便地将对象转化为二进制(或者其他格式),在对端则是如何正确且安全地将其从二进制恢复为对象。

  2、完善的底层通信协议;其需要提供合适的语义抽象:服务端支持怎样的并发,是单客户单访问,还是多访问;而客户端的并发模型由服务端决定。当然,还需要健壮且足够的接口抽象,毕竟分布式环境,“一切皆有可能”,需要应对各种问题。

  3、一个可用的反射系统。是的,需要在C++环境下建立一个反射系统。这一步是最为关键的,其由C++11支持。因为,我们需要注册一个类的各种信息,以供RPC调用。

 

当然,本文是提纲式的;也就是,在这里暂时只会讲【目标】——一个可用的C++RPC所需要的全部组件。而更详细的内容,即如何构建这些组件,将由后续篇章回答。

 

一、序列化

  在分布式环境下,序列化是永远绕不过的一个坎;而作为一个支撑性组件,其所需要提供不只是“可用”,而是易用且安全!安全!重要的事说两遍。我们不能够约定从网络传来的内容,代表了什么;而是其本身必须带有信息,告诉我们它是什么。

  在纯C++环境下,要从零开始构建一个序列化框架,是困难的。毕竟语言本身并没有提供什么保证。所幸的是,C++并非完全没有提供,只是需要我们去发掘。template,模板可以给我们所需要的一切;C++中最令人兴奋的部分,其提供了另一个简单且可靠的扩展模型:通过特化模板,能够提供类似面向对象的“接口”。当然,需要的还不止这些,我们需要更强大的工具:模板元编程,由其来提供所需要的类型信息(在我的系统中有两种扩展方式:特化模板和成员函数,后者需要类型信息)。

  下面将是我们需要完成的目标:

Buffer buffer;
Object obj1;
//序列化
Serialize(&buffer, obj1);

Object obj2;
//反序列化
Deserialize(&buffer, obj2);

  其中的buffer,便是我们的成果;其以二进制保存了对象。当然,还有许多的细节需要补充。

 

二、通信

  UDP还是TCP,这是一个需要纠结的问题。但我们的关注点并不在这,我们需要一个完善的、健壮的通信组件。为了完成这个目标,需要付出一些努力:并发模型、中断与超时通知。前者是整个RPC框架的语义保证,我们需要保证调用语义的完整性:客户端的并发访问请求,到了服务端不能变成串行请求;而普通的通信协议,并不能够直接提供这点,我选择了从零开始构建。中断与超时,是整个调用语义,所面临的最大挑战;所以,我们需要合适的通知,以决定如何进行下一步操作。

  当然,UDP与TCP,依旧是一个重要的话题;我的实现,提供了二者的完整实现,所需的只是,选择。

 

三、反射

  在C++的世界里,讲这个话题是不合时宜的。毕竟,无论怎样的努力,在一个没有完整运行时环境的语言里,“反射”这样奢侈的东西,只是一个梦想。但,我们并不是想要重新打造一门语言,而仅仅是给我们的RPC提供一些服务而已。

  在RPC的世界里讲“反射”并不是一件突兀的事。看一看,各种没有IDL的RPC在Java里的实现,无一不是使用了反射这一技术。是的,我的RPC里并没有IDL,我并不打算再创建一门语言(我有一个脚本语言),哪怕只是一个DSL(领域特定语言)。为了“封装”类型的各种信息:构造函数、析构函数以及一些我们需要的方法。反射,提供了最合适的语义。

  我的RPC是非侵入式的,在不改变任何原有的代码的前提下,提供相应的RPC调用。而这一“调用”通过反射来实现。

 

四、RPC

  前面三大组件,和我的RPC并没有什么必然的联系。但没有这三个组件,我的RPC框架,将不复存在。所以,最后再来讲讲我们的主角:RPC。

  其实,RMI(远程方法调用)更合适一点。我的RPC提供了3中“对象”:

    1、由单一客户端独占的,非共享对象;只有该客户端能够访问该对象,其创建和析构,都由一个客户端发起和执行。

    2、服务对象,这在服务端本身是一个“服务”;也就是其本身是一个单例,因此,所有客户都是直接在一个对象上,执行各种请求;该对象的构造和析构,可由服务端的本地服务管理框架(我的另一个东西)管理。这个方式,提供了“服务化”的最佳语义;当然,也就需要面对并发。

    3、注册对象,其也是全局可访问的,所有客户端都可以发送请求;不同的是,其是由服务端的某段代码显示注册的,该对象的所有权也由其持有;客户端只能访问其接口。一旦服务端取消了注册,便也消失在所有的客户端眼前,并且是可能在任何时刻取消注册,即使有请求还在路上(当然,有请求正在执行,需要等待其执行完成)。

  还有一个重要的事情,我只提供了,同步访问;因为,我有一个分布式消息系统,可提供异步服务(这只是托词,懒,而已)。

  其实,在拥有了前面的三个组件后,RPC本身便只剩下,需不需要构建,而不是如何。这样,我们也就可以将重心转向RPC的语义保证上了。一般有三种语义可以提供:至少一次、至多一次,可能一次。分别代表如下3中结果:

    1、该请求被执行,因为我们将重复地发送请求,直到答复。也就意味着,该请求可能被重复执行多次。

    2、该请求被执行,我们会一直发送重复的请求,直到答复。但服务端,将识别这些重复的请求,并只会执行一次。

    3、该请求被发送,但我们并不保证被执行;因为,我们没有等待答复。

  对于通用的RPC,除了“至多一次”,并没有其他的选择。当然,为了完成这点,需要一些努力,所幸并不困难。我的RPC正是提供这样的调用语义。

  我们将要构建的RPC并没有使用IDL。所以,客户端的访问,将会是显示的RPC调用;而非是其他框架所宣传的,能够完全屏蔽本地和分布,但我们是在C++的环境下,要完全屏蔽,是不可能的;所以,我所提供的调用方式,并没有排除原始的方案。其与本地调用的不同是:需要统一从一个RPC客户端对象中传入所需要的对象名字,以及在方法调用时,需要一个额外的方法名字。

  比如:

RPCClient client("Something");
int val = client.Invoke("GetValue", 12, "I Want ...").To<int>();

  当然,如果你不习惯这样的方式(你会习惯的);我还提供了类似IDL的功能:代码生成。其能够将上面的显示访问,封装起来,提供和本地调用完全一样的方式:

#include "Generated\\Something.h"//这个头文件是生成的

Something obj;
int val = obj.GetValue(12, "I Want ...");

  而在服务端则,使用如下方式提供远程对象:

Class<Somthing>* type = GetServiceAs<ReflectionService>()->Register<Something>();//也可以重新命名:Register<Something>("OtherName");
type->AddMethod("GetValue", &Somthing::GetValue);//也可注册重载函数(方式后面再讲)

  总之,本篇,完。

  PS:如需,请期待下一篇——序列化。

  PS:以及,下下篇——通信。

  PS:还有,下下下篇——反射。

以上是关于从RPC开始的主要内容,如果未能解决你的问题,请参考以下文章

后按时从 onCreate() 开始片段

从RPC开始

从RPC开始

片段从一开始就没有显示 |安卓工作室

ForegroundService没有从片段开始?

Seata RPC 模块的重构之路