前言 在上一篇文章中，介绍了 libatbus 从静态子网树到动态拓扑注册表的路由设计变更。新的拓扑模型解决了代理层无法弹性伸缩和跨区域隔离的问题，但路由只是底层基座——上层应用框架 libatapp 才是真正面对业务开发者的接口。 这篇文章聚焦于 libatapp 在新架构下的连接管理层设计，涵盖以下核心问题：

前言 很久很久以前，我为了解决以前项目中bus通信膨胀的问题设计了 libatbus, 当时主要解决的核心问题是解决大量服务器节点互通时服务器间两两建立通道时的大量内存浪费问题。也同时使用跨进程的无锁队列避免了多写单读场景下的加锁以提高性能。

最近给 libatapp 增加了一系列改造，非常多且琐碎，这里简单记录下吧。 首先是重构了配置管理。原来是手写在代码里的，因为原来上层的 libatbus 是不依赖 protobuf 的，现在 既然已经依赖 protobuf 了就转为 protobuf 管理了。同时现在还支持YAML配置，使用 yaml-cpp 来解析YAML文件，这个库也被一些其他知名的大型项目使用了，比如 Envoy proxy 。 原来的conf/ini模式的配置也是支持的，现在加载配置的时候会尝试猜测…

最近零碎的事太多了，拖了好久没写blog。一些小的碎片话的东西也不值得写，另一方面是这次大幅优化了 atframework 的一些流程细节，特别是针对我们这两年来业务的需求，对 libatbus 进行了一次大重构。这里记录一下重构的内容吧。 重构工程配置脚本 为了拥抱Modern CMake，我对 atframework 中所有的项目（当然也包含 libatbus ）进行了重构，主要是一方面重构整理最近几个项目编译和交叉编译 openssl , protobuf 等几个构建流…

前言 前段时间我尝试给 atframework 的 libatapp 整合进UnrealEngine做Dedicated Server和逻辑server通信的时候碰到了一些问题。主要在于这些客户端引擎一般来说默认都是关闭exception的甚至会关闭RTTI。而 libatapp 所依赖的通信组件 libatbus 里内部协议是msgpack ， 而 msgpack 的官方 C++ 的header only的实现是必须开异常的功能的。所以我近期打算抽空增强一波…