游戏服务器端所完成的事(三).doc

游戏服务端所完成的事情（三） 1.3 游戏服务端中的RPC与Pattern 1.3.1 RPC 定义问题 　　整理一下现状。 　　目前，client可以发送两类消息：一类交由Gate路由，一类交由MQ路由。service也可以接收两类消息：一类由Gate路由过来，一类由MQ路由过来。 　　我们希望的是，应用层只需要关心服务，也就是说发送的消息是希望转到哪个服务上，以及接收的消息是请求自己提供的哪个服务。　　这样对于应用层来说，其看到的协议应该是统一的，而至于应用层协议的底层协议是Gate的协议还是MQ的协议，由具体的适配器（Adaptor）适配。 　　这个应用层的协议就是RPC的一部分。　　RPC一直都是很有争议的。一方面，它能让代码看起来更优雅，省了不少打解包的重复代码；另一方面，程序员能调RPC了，系统就变得很不可控，特别是像某些架构下面RPC底层会绕很多，最后用的时候完全违背设计本意。 ?　　但是总的来说，RPC的优势还是比较明显的，毕竟游戏服务端的整体服务定义都是同一个项目组内做的，副作用严格可控，很少会出现调用一条RPC要绕很多个节点的情况。 RPC解决什么样的问题？ 　　RPC的定位是具体消息路由协议与应用层函数调用的中间层。一个标准的RPC框架要解决两个问题： 第一是协议定义。 第二是调用规范的确立。 　　 RPC的协议定义也可以做个划分： 协议中的一部分用来标识一次调用session，可以用来实现RPC的回调，可以用来实现RPC的超时管理等等。 另一部分用来标识调用的具体方法。这部分其实跟用不用RPC没太大关系，因为不用RPC只是打解包的话也是会用一些协议序列化、反序列化协议包的。采用RPC框架的话，就是希望这部分工作尽可能多的自动化。 　　RPC调用规范的核心设计意图就是让应用层程序员调用起来非常自然、不需要有太多包袱（类bigworld架构的rpc设计通常也是这个原则，尽量让应用层不关注切进程的细节）。调用规范的具体细节就跟语言和平台相关了。在支持异步语法的语言/平台，可以原生集成异步等待、执行完恢复上下文继续执行的语义。在不支持异步语法的语言/平台，那就只能callback。如果是不支持将函数作为参数传递的语言/平台，我想你应该已经离现代游戏开发太远了。 　　通用的部分确定之后，还得解决特定于具体路由方式的、需要适配的部分。 　　我将这部分逻辑称为Adaptor，很好理解，就是RPC到具体消息路由协议、具体消息路由协议到RPC的适配器。 　　下面，结合一种具体的RPC实现方式（下文称为Phial规范），来探讨下如何将上面提出的这几个概念串起来。 　　先通过一个大概的流程来厘清一次RPC流程中涉及的所有角色。 　　RPC既然作为一次远程过程调用，那么，对于调用方来说，其调用的是一个跟普通函数很像的函数（有可能表现为一个异步函数，也有可能表现为一个同步函数）；对于被调用方来说，其被调用的就真的是自己的一个函数了。 　　整个的pipeline也很清晰： 调用方调用某个服务的某个函数，RPC层会根据之前说的RPC层协议将调用信息（invokeId、方法id、参数等）打包，并将打包的消息和函数对应服务的路由规则告诉路由适配层，路由适配层根据路由规则给打包消息加个消息头，然后传给路由层（具体的Gate路由或MQ路由）。 路由层将消息路由到对应节点，该节点上的路由适配层解出消息头和打包消息，根据消息头确定被请求服务，并这些信息传给RPC层，RPC层解打包消息得到调用信息，然后做一次dispatch，被调用方的一开始注册进来的对应函数就会被回调到了。 　　在这个过程中，我们称调用方可以调用的是服务的delegate（可以类比为Stub），被调用方注册进来的是服务的implement（可以类比为Skeleton）。路由适配层就是Adaptor。可以基于不同类型的Adaptor构造服务的delegate。服务的implement也可以注册在不同的Adaptor上。不同的Adaptor只需要针对RPC层提供同样的接口，让RPC层可以发送打包消息和服务特定的路由规则，可以注册implement即可保证RPC层与Adaptor层是完全无关的。 　　我们在示例中实现了多种Adaptor，目前为止涉及到的有MqttAdaptor、GateAdaptor、AmqpAdaptor。 　　除了这整个的数据流之外，示例中还包装了两种异步调用与回调形式。 一种是针对.Net 2.0的callback模式； 一种是针对.Net 4.5的Task await/async模式。 　　第一种专门针对不支持.Net 4.5的平台，比如Unity。但是只要针对这种形式稍加扩展，也能支持.Net 2.0的yield语义，实现简单协程。关于.Net 2