游戏服务架构-RPC调用（游戏服务端ecs架构）

在上前面的几章中，我们讲解了不同的场景服务器运用。但是这些场景服务器是之间是怎么交互的呢，这一章我们就详细说明一下RPC 调用。

基本概念

RPC（Remote Procedure Call）远程过程调用，简单的理解是一个节点请求另一个节点提供的服务。

本地调用：

在了解远程调用的时候首先需要了解一下什么叫本地调用。举一个例子，如果需要将本地student对象的socore+1，可以实现一个addScore()方法，将student对象传入，对年龄进行更新之后返回即可，本地方法调用的函数体通过函数指针来指定。

远程调用

上述操作的过程中，如果addScore()这个方法在服务端，执行函数的函数体在远程机器上，如何告诉机器需要调用这个方法呢？

1.首先客户端需要告诉服务器，需要调用的函数，这里函数和进程ID存在一个映射，客户端远程调用时，需要查一下函数，找到对应的ID，然后执行函数的代码。

2.客户端需要把本地参数传给远程函数，本地调用的过程中，直接压栈即可，但是在远程调用过程中不在同一个内存里，无法直接传递函数的参数，因此需要客户端把参数转换成字节流，传给服务端，然后服务端将字节流转换成自身能读取的格式，是一个序列化和反序列化的过程。

3.数据准备好了之后，如何进行传输？网络传输层需要把调用的ID和序列化后的参数传给服务端，然后把计算好的结果序列化传给客户端，因此TCP层即可完成上述过程。

大家可以理解一下HTTP 方式的请求服务的代码。其实原理和这个差不多。那么我们为什么不直接采用HTTP 的方式请求呢？问题是这样因为HTTP 协议太宽松了，这样就要求我在写每一个API接口的时候，需要添加详细的文档。规定输入参数是什么，输出参数是什么。这样在一个小的系统里面是没什么问题的，当项目结构越来越复杂的时候，调用原来越多的时候显然，这样做是不合理的，所以我们要采用一种新的RPC 调用方式来更快的辅助我们开发。

通过上面这张图我们可以看出RPC 的优势，当PRC框架封装好以后，当调用远程方法就像调用本地方法一样，这样是不是很爽，同时我基本就不需要写文档要求你的输入参数，因为RPC 调用就像调用本地方法一样。你在调用方法时候本身就约束好了输入和输出，对于程序员来说，看代码比看文档 了解的更快。

跟语言平台绑定的开源 RPC 框架主要有下面几种。

• Dubbo：国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，仅支持 Java 语言。
• Motan：微博内部使用的 RPC 框架，于 2016 年对外开源，仅支持 Java 语言。
• Tars：腾讯内部使用的 RPC 框架，于 2017 年对外开源，仅支持 C++ 语言。
• Spring Cloud：国外 Pivotal 公司 2014 年对外开源的 RPC 框架，仅支持 Java 语言
• jdk 自带的RMI

而跨语言平台的开源 RPC 框架主要有以下几种。

• gRPC：Google 于 2015 年对外开源的跨语言 RPC 框架，支持多种语言。
• Thrift：最初是由 Facebook 开发的内部系统跨语言的 RPC 框架，2007 年贡献给了 Apache 基金，成为 Apache 开源项目之一，支持多种语言。

如果你的业务场景仅仅局限于一种语言的话，可以选择跟语言绑定的 RPC 框架中的一种;

如果涉及多个语言平台之间的相互调用，就应该选择跨语言平台的 RPC 框架。

至于各个框架的性能，大家可以自行度娘或者谷歌，这里就不展开讨论了。

讲到这里有的人可能就会想到我们前面的中心服务器，对当提供RPC服务启动以后就可以注册到中心服务器上，需要RPC 服务 的场景服务就可以去中心服务器拿到服务地址来发送请求。在这个时候大家就可以愉快的开发了。下一章我们讲解一下为啥需要这些框架。如果有疑问，大家可以私信或者在评论区留言。