Go游戏服务器开发的一些思考（二十八）：登录流程（一）

过程与不确定因素

帐号登录是一个跨多个服务进程的一段持续的交互过程。

如IO游戏，会涉及到的游戏服务器有：

登录服务器

数据库服务器

缓存服务器

中心服务器（很多别名，如CenterServer、WorldServer；也可能是redis、etcd之类的）

游戏服务器（很多别名，如RoomServer、CellServer、GameServer）

网关服务器

在这个过程中，可能会有很多意外、或者恶意行为：

同个帐号在多个终端登录

同个帐号登录报文被持续多次发送

登录过程中，某服务进程失效

登录过程中，终端连接已断开

因此不严谨的登录逻辑会出各种问题。

这里提供了3种方法来确保登录过程健壮：

多段登录

服务无状态化

时序图推导

多段登录

显然，登录过程越长、涉及的服务进程越多，那么不确定因素风险越大。

仔细观察这些服务进程，如果服务器架构合理，那么通常可以把服务器架构按功能区块化（俗称“微服化”）。

那么根据“分而治之”的原理，如果能把整个登录过程拆成多块，每块登录相对独立，做成多段式登录。则有下面的好处：

登录复杂度被降幂，登录过程变简单了

多段登录后，即使某段登录不成功，也只会让某部分游戏功能失效

这里举例下IO游戏的多段登录，通常会这样做划分：

游戏大厅段登录（该段保证了能正常进游戏大厅）

游戏房间段登录（该段保证了能正常进房间游戏）

跨服网关段登录（该段保证了能正常跨服操作，如跨服聊天等）

服务无状态化

多服务进程间通信，之所以容易产生BUG。其中的一大原因为，差的代码实现，会在多个进程中保存同一个帐号相关的数据。因此容易发生服务进程间数据不同步。

所有类型服务器都是可以做成无状态化的，这样登录过程的复杂度又降了一个幂次。

时序图推导

涉及到多服务进程交互过程的，如果直接编码，从代码上Review这个过程是否正常。通常会很困难。

如果有工具能把整个过程清晰的描绘出来，那么检查其中的错误，会方便很多。整个过程的流程都确定OK后，再做编码，可以事半功倍。

这个工具就是时序图

后续文章介绍

接下来的文章，将根据上面分析的3段登录，给每段设计一个严谨完整的登录过程。