近期仍然在搭建完整的游戏服务器架构。基于atsf4g（asynchronously-tree server framework fo game）的完整解决方案终于接近完成。基本框架之前其实已经做完了，但是之前解决的只是基本的框架层代码，不包含任何特定的交互模型、协议模型、配置服务等等。这回就整理了一个只包含登入登出逻辑的完整工程，另外优化了一些小细节和周边工具的支持。
完整示例地址： https://github.com/atframework/atsf4g-co/tree/full_sample
完整工程
其实很多游戏服务在具体的通信模型，请求/响应的包装还有资源管理等等方面大同小异，可以复用的部分还是很多的，所以我就按我们上一个游戏的模型写了一个完整的sample，放在了full_sample分支。
所谓完整的sample，就是按照具体项目的设计，保留了主要的通信流程和交互的封装。这里CS协议采用了protobuf（顺便升级到了proto3版本），然后保留了登入逻辑，踢出逻辑，基本信息拉取逻辑和基本的ping/pong逻辑。
指定登入流程
- client->loginsvr: 请求鉴权，生成token
- loginsvr->client: 然后拿token去gamesvr登入。loginsvr仅实现了最基本的鉴权方式（帐号&密码）。由loginsvr负责gamesvr的负载均衡。
- client->gamesvr: 使用token登入
协议实现
- 鉴权和负载均衡：loginsvr仅实现了最基本的鉴权方式（帐号&密码）。由loginsvr负责gamesvr的负载均衡。loginsvr全程无状态。
- 登入流程：保证用户数据只在一处上线，保留踢出逻辑，故障修复功能
- Ping/Pong：保留加速器检测和网络短期拥塞的处理，token续期
- 拉取信息：作为一个典型逻辑处理的流程
资源管理方面：
- 定时自动保存
- 缓存和自动失效管理（配合断线重连）
- Session管理
- 统一配置管理
任务和消息分发：
这个项目指定使用协程，所以会比master多依赖一个libcopp，用来做协程任务管理的封装。然后默认模型是Request/Pesponse的模式，由协程任务管理器管理每个协程的生命周期。
然后在协程任务的基础上包装了消息分发的规则，要求消息分发管理器必须实现一些接口，比如：提取消息ID或提取消息名称、打解包方式、怎么存储和提取关联的协程任务ID等等。然后由统一的方式启动新协程任务或者恢复协程上下文。
因为是最小工程，目前只保留了客户端-服务器（CS）消息dispatcher和、服务器间（SS）消息dispatcher和数据库（DB）消息dispatcher。其他的暂时没移植过来，不过后续因为有一些基本的功能也是蛮通用的，后续有空可能也会再移植一些过来。比如Curl消息dispatcher来处理HTTP消息，再或者websocket。到时候移植的时候都会再重构一次代码，但是对于需要额外依赖的功能会更谨慎一些，因为毕竟是个通用的sample所以不想加一些可能用不到的依赖进来。
C++协程因为暴露了原始地址，并且要切换前后地址不变，所以要专门给每个协程分配栈。我们这里走的是系统接口（Linux走mmap+mprotect,Windows走VirtualAlloc+VirtualProtect）。
虽然gcc在linux下支持动态栈功能，并且动态栈特别适合协程（因为基本可以按需分配栈内存），但是由于并不跨平台并且文档不多，所以只是libcopp底层支持，并没有默认启用。以后等这个功能更成熟一些（主要是可以控制最大栈大小的话）可以尝试默认用动态栈。
数据库
完整游戏服务器sample的话，数据库肯定是不能少的。这方面直接用了redis，并且是redis cluster，由于redis cluster目前并没有一个很好的connector，所以我们自己开发了hiredis-happ（hiredis高可用），基于hiredis实现了对redis cluster的接入并做了自动重连和自动失败重试的功能。所以整个工程比master会再多依赖这两个库。
配置加载
配置加载走的是xresloader的方案，主要流程是：
- 定义配置protobuf结构，转出pb文件。
- 定义excel转换规则
- 用xresloader-gui或xresloader-cli调用xresloader加载pb和转换规则转换出配置数据二进制文件
- 在代码里定义配置的类型，key类型和容器类型（可选key-value，key-list，index-value，index-list）
- 配置管理器里指定加载文件名称和怎么读取key
- [可选] 可以根据需要指定数据过滤规则和如果值是list类型的话可以指定排序规则
数据结构优化
因为是整理框架，所以我们之前项目里有一些非跨平台或者编译器版本限定的东西移植过来前就再优化了一下。比如一些不需要排序的容器改成了根据环境尽量使用hash_map。有些调用（特别是sprintf之类）包了一层，用于解决某些编译器里会有warning的问题。并且尽量使用safe的API。
监控
监控方面目前只是加了个log分类，还没写进去。这个sample基本只会监控协程任务的延迟问题，还有RPC的响应时间。上报的话目前只接入本地日志。因为监控和报警的话不同的项目可以接入不同的系统，差异很大，并且具体的业务逻辑得具体的业务自己加，所以框架也只能监控最基本的东西。
配置生成工具
我们以前的配置生成工具是php写得。当时并不会python，并且是想php刚好本来就是设计来当通过模板生成code的（虽然大部分是Web相关的）。好像很合适做成配置模板然后生成各个服务器的配置。但是慢慢发现，用php一次性生成多个服务器模板并不是很方便。特别是系统信息检测和多个server传递多个参数并且隔离server配置后，服务器间要在配置上建立关系，很不方便。
之前的php的生成系统会通过加载一个服务器组配置，然后通过调用另一个php文件，把输出流重定向到生成目标，以此来实现加载模板脚本生成配置。但是这样的话首先意味着很多php脚本会完全重新加载，并且参数传递只能走命令行。再就是比如loginsvr在开发环境需要知道gamesvr关联的gateway绑定的地址，那么就只能通过统一的算法，然后通过传参加重新计算一次得出来，非常麻烦。
最近看了下python的mako库，似乎拿来做模板生成挺好用，不过麻烦的一点是php的ini读取有纯php的扩展实现可以支持多个层级，但是python的不行。并且python2和python3在解析配置文件的支持度上还是差异比较大。但是这比起php的问题倒不是什么大事儿。而且python比php容易安装，标准库丰富得多，特别是生成配置的时候需要检测系统信息就不需要再借助外部工具了，所以现在就用python重写了配置和脚本生成系统。
脚本生成也像以前一样预留可选预加载jemalloc或者tcmalloc和设置响应的debug配置，还有valgrind支持。
不过截止至写这篇文章的时候，这部分还没有全部完成，只是大体完成。预计很快就会finish并且merge进master。
静态分析
之前我们项目里的静态分析使用的是cppcheck，但是其实cppcheck配置起来比较麻烦，特别是工程项目大了以后，各种选项比较麻烦，并且cppcheck还是有一定的误报率。所以现在clang-analyzer的流程更贴近编译器行为，而且更精确，所以我先接入了clang-analyzer。不过不清楚和cppcheck相比是否有漏报，等再过一段时间有空了我再把cppcheck也接入进来看看。
跨平台适配和工具适配
因为是框架级的整理，所以在周边工具上也是需要适配一下跨平台和多种工具的，就列举一下碰到的问题吧
Clang-analyzer
这个静态分析接入倒是没什么问题，框架已经能做到3.8版本无报警了，但是sample还没有跑，过段时间我会跑跑看，因为hiredis的原因，full_sample在Windows下无法编译出二进制，但是框架可以，所以master分支已经清理了所有的报警，full_sample的话等过段时间在linux上编译一套llvm系工具再fix。不过整体不会有太大的问题。
Bash on windows
适配Bash on windows的时候还是碰到了点问题的，首先不知道是哪些api微软没做完，redis在不设置仅bind ipv4的情况下，redis是起不来的。但是我们自己的框架其实是可以正常listen和使用ipv6。不过在bash on windows里并不能使用共享内存，所以配置生成工具就改成了在检查不到linux共享内存配置的时候就走IP。（Windows下的全局共享内存必须开管理员权限才能创建，为了防止上手困难，和开发环境麻烦，所以默认Windows下也是走tcp而不是共享内存，本身支持Windows也只是为了开发方便）
MinGW64@MSYS2
MinGW64下编译框架和服务器代码是没有问题的，但是由于hiredis不支持windows，而微软自己做的redis系列的porting并没有把hiredis单独开放出来，做自动化工具比较麻烦，暂时也就没花这个时间去搞（理论上自己编译好prebuilt然后设置LIBHIREDIS_ROOT也是可以的）。现在在Mingw64上的状态是master正常，full_sample能编译但是链接不过。目前静态分析我都是在msys2的mingw64里用源里的包跑，所以这也是full_sample暂时还没处理静态分析的原因。
CI
这个是准备最后才会接入的，所以目前也不急。
后续计划
首先当然还是把配置生成解决掉，然后把上面的未完成部分一点一点解决掉。首先当然还是质量优先，所以静态分析是优先级比较高的部分。其他的就看情况吧。
接下来整理出的框架会用于下一个项目。然后再一点一点地在这个框架的基础上搭建出更多的通用服务和配套工具。同时再来调整框架架构。现在完全是以源码的方式提供框架，这会导致很容易需要重新编译框架和一些不太改动的库，头文件分析也会浪费一些时间，所以等到工程更大了以后，必然还是会抽离成库和服务，然后封装成隔离性更好的设计（当然一定会保持开源的）。不过这也是后话了。