最近给 libatapp 增加了一系列改造，非常多且琐碎，这里简单记录下吧。

首先是重构了配置管理。原来是手写在代码里的，因为原来上层的 libatbus 是不依赖 protobuf 的，现在 既然已经依赖 protobuf 了就转为 protobuf 管理了。同时现在还支持YAML配置，使用 yaml-cpp 来解析YAML文件，这个库也被一些其他知名的大型项目使用了，比如 Envoy proxy 。 原来的conf/ini模式的配置也是支持的，现在加载配置的时候会尝试猜测以下配置文件是yaml还是conf/ini模式。 并且增加了统一的 YAML转protobuf 、 conf/ini转protobuf 和 指定层级配置导出到protobuf 的接口来方便使用。比较特殊的是自定义日志配置后端的接入接口有了一些小变化，问题也不大。

最近零碎的事太多了，拖了好久没写blog。一些小的碎片话的东西也不值得写，另一方面是这次大幅优化了 atframework 的一些流程细节，特别是针对我们这两年来业务的需求，对 libatbus 进行了一次大重构。这里记录一下重构的内容吧。

重构工程配置脚本

为了拥抱Modern CMake，我对 atframework 中所有的项目（当然也包含 libatbus ）进行了重构，主要是一方面重构整理最近几个项目编译和交叉编译 openssl , protobuf 等几个构建流程比较恶心的库的自动化构建流程和工具脚本。如果不追求全部功能的话，还可以用 libressl 来代替 openssl 。也合并适应了给客户端用的交叉编译iOS、Android、Unreal Engine等平台使用的构建流程。

前言

前段时间我尝试给 atframework 的 libatapp 整合进UnrealEngine做Dedicated Server和逻辑server通信的时候碰到了一些问题。主要在于这些客户端引擎一般来说默认都是关闭exception的甚至会关闭RTTI。而 libatapp 所依赖的通信组件 libatbus 里内部协议是msgpack ， 而 msgpack 的官方 C++ 的header only的实现是必须开异常的功能的。所以我近期打算抽空增强一波 libatbus 的功能，增加一些跨版本向前向后兼容功能，和一些简单的验证功能（仅仅是为了防止误操作导致的问题）。具体的变更等我弄完了再发一篇。

前言

最近在抽时间整理之气的游戏服务器框架和解决方案里atsf4g-co，现在的架构是使用etcd的是atproxy。简单得说就是服务集群是分组的，每个分组有分组代理服务atproxy做组间通信。然后atproxy之间使用etcd来做分组服务的服务发现和保活，并且以此来实现平行扩容。

之前做服务间通信组件libatbus的时候也提到了有一个暂时没实现的功能，就是全局路由表的自动通知。但是这个功能的实现主要也是用于后面不同种服务间感知到哪些节点是可用的，哪些是不可用的。而且我的简单实现必然是走心跳的模式，因为心跳的形式肯定不能把心跳设置得太短，同时也要考虑网络异常抖动和断线重连和丢包，所以肯定不是丢一个心跳包就认为丢失。所以故障或者扩缩容期间的感知时间就会比较长一些。另外就是因为可能有网络孤岛问题，所以可能短期内数据不一致（当然肯定会保证最终一致性）。

再加上由于libatbus是支持多级父子节点关系的，所以变化通知和同步包就要考虑自己与父节点、兄弟节点、自己与子节点的不同关系并作不同的同步流向，会比较复杂。比如：子节点下线，既要通知父节点，又要通…

近期仍然在搭建完整的游戏服务器架构。基于atsf4g（asynchronously-tree server framework fo game）的完整解决方案终于接近完成。基本框架之前其实已经做完了，但是之前解决的只是基本的框架层代码，不包含任何特定的交互模型、协议模型、配置服务等等。这回就整理了一个只包含登入登出逻辑的完整工程，另外优化了一些小细节和周边工具的支持。

好久没写blog了。最近空闲时间都在加紧完成atframework框架。总算是搞完了，并且搭建了一个静态介绍页。以后有空慢慢加文档进去。

主页: https://atframe.work/ Github: https://github.com/atframework/

目前这个项目已经是一个小型游戏服务器的完整框架，包括服务器间实例的管理、客户端和服务器的内部协议和通信机制。并且实现了纯C的port。 然后https://github.com/atframework/atsf4g-co/tree/master/sample/atgw_cli_inner_hello里提供了c++的客户度端的代码示例，https://github.com/atframework/AtgwInnerCli-CSharp里提供了C#的客户端代码示例。 使用的都是同一个纯C的协议porting。这样无论cocos还是unity框架接入都不困难了。其他的框架也可以直接用这个纯C的porting来接入。