ioGame 请求的处理流程图

[iohao]

更详细的可阅读 ioGame 请求的处理流程

主要介绍从玩家请求进来，并得到响应结果的整个处理流程。通过介绍，可以让开发者更好的理解框架是如何处理请求的、如何响应结果的。

请求处理流程时序图

从玩家发出请求，到玩家接收到响应的流程做了一个大概的介绍；虽然整个处理流程看起来像是过程化的方式，但实际上每个环节的处理都是独立的，并不是过程化的。

当请求从游戏对外服发送到 Broker（游戏网关）后，两者之间就没有任何联系了；这就好比你打电话到某个餐厅订外卖，当你挂了电话后就可以去休息了，直到外卖员按你家门铃时，你才需要动起来；而按门铃就可比作 Broker（游戏网关）给游戏对外服的响应结果。通讯过程中的每个环节都是如此。

换个角度来看，在响应结果的角度，其实就是【游戏逻辑服】主动的请求【游戏对外服】；无论是 action 方法的返回值，还是推送（广播）数据，两者的本质是一样的，都是向游戏网关发送数据；

【4】说明-业务框架相关

在业务框架这篇文档中做了部分介绍了，这里就不重复了；
通常情况下，开发者需要关注只有业务框架这个环节。

ActionCommandFlowExecute 的执行流程编号对应说明

1. 插件前置动作
2. 得到 action bean，也就是我们编写的 ActionController
3. 执行 action 业务逻辑，也就是我们编写的 ActionMethod
4. 将 action 返回值放到响应对象中
5. 将响应结果发送给 Broker（游戏网关）
6. 插件后置动作

ActionCommandFlowExecute 中的每个处理流程的逻辑都是可以替换的；

小结

从玩家发出请求，到玩家接收到响应的流程做了一个大概的介绍；虽然整个处理流程看起来像是过程化的方式，但实际上每个环节的处理都是独立的，并不是过程化的。

当请求从游戏对外服发送到 Broker（游戏网关）后，两者之间就没有任何联系了；这就好比你打电话到某个餐厅订外卖，当你挂了电话后就可以去休息了，直到外卖员按你家门铃时，你才需要动起来；而按门铃就可比作 Broker（游戏网关）给游戏对外服的响应结果。通讯过程中的每个环节都是如此。

换个角度来看，在响应结果的角度，其实就是【游戏逻辑服】主动的请求【游戏对外服】；无论是 action 方法的返回值，还是推送（广播）数据，两者的本质是一样的，都是向游戏网关发送数据；

响应式

从上面的例子我们可以看出，处理流程类似响应式非阻塞的。当我们调用一个 action 获取数据时，无需阻塞等待数据返回，而是当有数据返回时会进行告知。可见我们的处理流程是非阻塞的，意味着调用方法后，CPU 可以去做别的事情，当接收到数据响应时 CPU 再回来处理，这种方式提高了系统的呑吐量。

这么多的环节，对性能有影响吗？

长连接通信在同一内网中，几乎可以忽略。

如果是多服单进程则是在内存中通信传输。

[iohao]

ioGame 消息处理流程

相关文档 ioGame 消息处理流程 (yuque.com)

本篇文档主要讲解：客户端发起的 ExternalMessage 请求到服务器，服务器处理后返回的具体内容的整个消息走向流程。游戏逻辑服处理完 action 后，框架又是如何将业务消息转换为 ExternalMessage 的。

请求流程时序图