# libatbus基本功能及单元测试终于写完啦

## [libatbus](https://github.com/atframework/libatbus)

经过茫茫长时间的编写+过年在家无聊补充和修正单元测试，再加上这两天的整理，终于把以前的这个关于服务器通信中间件的基本功能和相应的单元测试完成啦。还是可以热烈庆祝一下的。

[《关于BUS通信系统的一些思考（一）》](https://www.owent.net/2014/1090.html) [《关于BUS通信系统的一些思考（二）》](https://www.owent.net/2014/1099.html) [《关于BUS通信系统的一些思考（三）》](https://www.owent.net/2015/1201.html)

主要的思路还是在自动选择**共享内存**或是**tcp**或是**unix socket**进行通信。使用节点ID，屏蔽底层通信细节，屏蔽自动重连细节和节点之间自动建立直连的细节。同时基于目前的游戏服务器架构设计方式预留了一些拓展性的设计，以便于后续服务器框架的实现。主要是指全异步，树形结构，自动化的容灾设计和动态扩容缩容，不停服更新，统计等等。

在实现这个[libatbus](https://github.com/atframework/libatbus)的过程中，为了能够跨平台并且能有比较高的性能，并且目前只有我一个人用业余时间开发，底层使用了一些开源项目。这样我们就有了性能不输TX的**tsf4g::tbus**并且支持动态通道+更加节省内存的全异步树形结构通信中间件。接下来就要准备开始折腾服务器app框架啦。并且在使用到的地方对这个[libatbus](https://github.com/atframework/libatbus)还会有后续的扩充。

写单元测试确实花了不少时间，但是也发现了不少细节问题。目前单元测试虽说没有覆盖到100%的代码流程，但是基本上也覆盖到了80-90%。后续碰到遗漏的BUG再想方法追加单元测试吧。

## 目前状态

* **Github仓库地址**： <https://github.com/atframework/libatbus>
* **CentOS 7.1 + GCC 4.8.4** 无warning，单元测试全部pass
* **MSVC 1900(VS 2015社区版)** 两处类型转换warning（无影响），单元测试除unix socket外全部pass
* **OSX + Clang(7.0)** 无warning，单元测试全部pass
* **valgrind**: 无内存泄露
* **cppcheck**: libatbus无error报告，其他类型的报告都是误报或功能预留。单元测试和压力测试工具有3处error报告，已经确认全部都是误报。

早期的压力测试，大约每个端点（单线程）内存通道大约1.2GB/s，socket大约200MB/s。近期尚未压力测试。

目前[libatbus](https://github.com/atframework/libatbus)中的内存通道已经被单独抽出来并在生产环境中使用了比较长的时间了。

## 后续计划

* CI集成

  > 后面会抽空集成Linux和Windows的CI系统，前期没有集成是因为开发中没有完成，代码不一定能编译过或者单元测试不一定能过
  >
  > 单元测试，Windows环境，Linux环境，MinGW环境都有免费的CI可以用，OSX比较麻烦，可能还是得手动跑
* 全局路由表同步

  > 目前仅实现基本功能，暂未做全局路由表同步的功能，等后续服务器中需要用这个功能的时候再加。
  >
  > 这也是个比较实用的功能，可以用于把一些静态的工作转为动态的模式。但是目前优先还是跑通基本框架，再加后续扩展功能。
* 广播

  > 广播其实就是个函数糖，实际发送底层还是得一个一个发，不过也可以简化一些操作就是了

## 服务器应用框架

接下来我会开始抽时间搞游戏服务器的框架，大体上还是和现有的系统差不多，但是模块分离会做得更好一些。再加上[libatbus](https://github.com/atframework/libatbus)性能也会更好一些。并且会比现有的框架更简洁。

主要的思路就是，proxy-services的方式。每个逻辑服务器组由一个proxy和多个服务组成，proxy和proxy之间直接直接通过zookeeper维护状态并实现去中心化。

proxy和proxy之间为[libatbus](https://github.com/atframework/libatbus)的兄弟节点，proxy和其下属的服务之间是父子关系。这样，在同一个proxy下的服务之间互相访问时，就会建立直接连接，而跨proxy的通信会经过proxy转发。这点和现有的服务器一样，并且额外还预留了多级的服务分层的策略。

由于使用zookeeper做去中心化并维护proxy组状态，所以各种服务之间可以很容易做到平行扩容。初步的想法当然还是主要针对游戏服务器，前期是手游、页游，后期可以扩展到MMO。

另外，框架中优先也会提供C++的协程模式的RPC行为，这涉及我写得另一个库[libcopp](https://github.com/owt5008137/libcopp)。同样跨平台，但是这个库在不支持TLS的系统上无法使用类似this\_xxx的功能（目前仅发现Android和IOS下不支持TLS）。并且这个库在目前的生产环境中已经使用了比较长的时间。

另外，由于我们的现有的服务器框架使用了[libcopp](https://github.com/owt5008137/libcopp)，近期测试期间花了几分钟随手做了一个响应时间的统计，可以用来查看是否有响应过长需要优化的协议接口。以前看到微信可以精确到函数级别的响应，感觉似乎很NB的样子。实际做的时候发现其实也很简单，如果把我这个响应时间的统计上报到某个监控系统里，就变成微信那样的RPC级别的响应延迟监控了。

协程果然非常爽。