<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Libatbus on I'm OWenT</title><link>//owent.net/tags/libatbus.html</link><description>Recent content in Libatbus on I'm OWenT</description><generator>Hugo</generator><language>zh-cn</language><copyright>&lt;a rel="license" href="https://github.com/owent/blog-hugo/blob/master/LICENSE.md"&gt;&lt;img alt="知识共享许可协议" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-sa/4.0/80x15.png" /&gt;&lt;/a&gt;</copyright><lastBuildDate>Fri, 27 Mar 2026 16:45:45 +0000</lastBuildDate><atom:link href="//owent.net/tags/libatbus/index.xml" rel="self" type="application/rss+xml"/><item><title>新版本libatapp的连接管理——从etcd服务发现到拓扑驱动的自动重连</title><link>//owent.net/2026/2605.html</link><pubDate>Fri, 27 Mar 2026 16:45:45 +0000</pubDate><guid>//owent.net/2026/2605.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;&#10;&lt;p&gt;在&lt;a href="../2604"&gt;上一篇文章&lt;/a&gt;中，介绍了 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 从静态子网树到动态拓扑注册表的路由设计变更。新的拓扑模型解决了代理层无法弹性伸缩和跨区域隔离的问题，但路由只是底层基座——上层应用框架 &lt;a href="https://github.com/atframework/libatapp"&gt;libatapp&lt;/a&gt; 才是真正面对业务开发者的接口。&lt;/p&gt;&#10;&lt;p&gt;这篇文章聚焦于 &lt;a href="https://github.com/atframework/libatapp"&gt;libatapp&lt;/a&gt; 在新架构下的连接管理层设计，涵盖以下核心问题：&lt;/p&gt;</description></item><item><title>新版本libatbus的设计变更——从树形路由到拓扑驱动</title><link>//owent.net/2026/2604.html</link><pubDate>Fri, 27 Mar 2026 16:08:45 +0000</pubDate><guid>//owent.net/2026/2604.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;&#10;&lt;p&gt;很久很久以前，我为了解决以前项目中bus通信膨胀的问题设计了 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt;, 当时主要解决的核心问题是解决大量服务器节点互通时服务器间两两建立通道时的大量内存浪费问题。也同时使用跨进程的无锁队列避免了多写单读场景下的加锁以提高性能。&lt;/p&gt;</description></item><item><title>近期对libatapp的一些优化调整(增加服务发现和连接管理,支持yaml等)</title><link>//owent.net/2020/2007.html</link><pubDate>Sun, 04 Oct 2020 15:43:17 +0000</pubDate><guid>//owent.net/2020/2007.html</guid><description>&lt;p&gt;最近给 &lt;a href="https://github.com/atframework/libatapp"&gt;libatapp&lt;/a&gt; 增加了一系列改造，非常多且琐碎，这里简单记录下吧。&lt;/p&gt;&#10;&lt;p&gt;首先是重构了配置管理。原来是手写在代码里的，因为原来上层的 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 是不依赖 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 的，现在 既然已经依赖 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 了就转为 &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 管理了。同时现在还支持YAML配置，使用 &lt;a href="https://github.com/jbeder/yaml-cpp"&gt;yaml-cpp&lt;/a&gt; 来解析YAML文件，这个库也被一些其他知名的大型项目使用了，比如 &lt;a href="https://www.envoyproxy.io/"&gt;Envoy proxy&lt;/a&gt; 。 原来的conf/ini模式的配置也是支持的，现在加载配置的时候会尝试猜测以下配置文件是yaml还是conf/ini模式。 并且增加了统一的 &lt;em&gt;YAML转&lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt;&lt;/em&gt; 、 &lt;em&gt;conf/ini转&lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt;&lt;/em&gt; 和 &lt;em&gt;指定层级配置导出到&lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt;&lt;/em&gt; 的接口来方便使用。比较特殊的是自定义日志配置后端的接入接口有了一些小变化，问题也不大。&lt;/p&gt;</description></item><item><title>libatbus 的大幅优化</title><link>//owent.net/2020/2003.html</link><pubDate>Thu, 16 Apr 2020 20:51:58 +0000</pubDate><guid>//owent.net/2020/2003.html</guid><description>&lt;p&gt;最近零碎的事太多了，拖了好久没写blog。一些小的碎片话的东西也不值得写，另一方面是这次大幅优化了 &lt;a href="https://github.com/atframework/"&gt;atframework&lt;/a&gt; 的一些流程细节，特别是针对我们这两年来业务的需求，对 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 进行了一次大重构。这里记录一下重构的内容吧。&lt;/p&gt;&#10;&lt;h2 id="重构工程配置脚本"&gt;重构工程配置脚本&lt;/h2&gt;&#10;&lt;p&gt;为了拥抱Modern CMake，我对 &lt;a href="https://github.com/atframework/"&gt;atframework&lt;/a&gt; 中所有的项目（当然也包含 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; ）进行了重构，主要是一方面重构整理最近几个项目编译和交叉编译 &lt;a href="https://www.openssl.org/"&gt;openssl&lt;/a&gt; , &lt;a href="https://github.com/protocolbuffers/protobuf"&gt;protobuf&lt;/a&gt; 等几个构建流程比较恶心的库的自动化构建流程和工具脚本。如果不追求全部功能的话，还可以用 &lt;a href="https://www.libressl.org/"&gt;libressl&lt;/a&gt; 来代替 &lt;a href="https://www.openssl.org/"&gt;openssl&lt;/a&gt; 。也合并适应了给客户端用的交叉编译iOS、Android、&lt;a href="https://www.unrealengine.com"&gt;Unreal Engine&lt;/a&gt;等平台使用的构建流程。&lt;/p&gt;</description></item><item><title>protobuf、flatbuffer、msgpack 针对小数据包的简单对比</title><link>//owent.net/2019/1908.html</link><pubDate>Sat, 03 Aug 2019 10:59:58 +0000</pubDate><guid>//owent.net/2019/1908.html</guid><description>&lt;h2 id="前言"&gt;前言&lt;/h2&gt;&#10;&lt;p&gt;前段时间我尝试给 &lt;a href="https://github.com/atframework/"&gt;atframework&lt;/a&gt; 的 &lt;a href="https://github.com/atframework/libatapp"&gt;libatapp&lt;/a&gt; 整合进UnrealEngine做Dedicated Server和逻辑server通信的时候碰到了一些问题。主要在于这些客户端引擎一般来说默认都是关闭exception的甚至会关闭RTTI。而 &lt;a href="https://github.com/atframework/libatapp"&gt;libatapp&lt;/a&gt; 所依赖的通信组件 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 里内部协议是&lt;a href="https://msgpack.org/"&gt;msgpack&lt;/a&gt; ， 而 &lt;a href="https://msgpack.org/"&gt;msgpack&lt;/a&gt; 的官方 C++ 的header only的实现是必须开异常的功能的。所以我近期打算抽空增强一波 &lt;a href="https://github.com/atframework/libatbus"&gt;libatbus&lt;/a&gt; 的功能，增加一些跨版本向前向后兼容功能，和一些简单的验证功能（仅仅是为了防止误操作导致的问题）。具体的变更等我弄完了再发一篇。&lt;/p&gt;</description></item></channel></rss>