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

libatbus

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

《关于BUS通信系统的一些思考(一)》 《关于BUS通信系统的一些思考(二)》 《关于BUS通信系统的一些思考(三)》

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

在实现这个libatbus的过程中,为了能够跨平台并且能有比较高的性能,并且目前只有我一个人用业余时间开发,底层使用了一些开源项目。这样我们就有了性能不输TX的tsf4g::tbus并且支持动态通道+更加节省内存的全异步树形结构通信中间件。接下来就要准备开始折腾服务器app框架啦。并且在使用到的地方对这个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中的内存通道已经被单独抽出来并在生产环境中使用了比较长的时间了。

后续计划

  • CI集成 > 后面会抽空集成Linux和Windows的CI系统,前期没有集成是因为开发中没有完成,代码不一定能编译过或者单元测试不一定能过 > > 单元测试,Windows环境,Linux环境,MinGW环境都有免费的CI可以用,OSX比较麻烦,可能还是得手动跑 >
  • 全局路由表同步 > 目前仅实现基本功能,暂未做全局路由表同步的功能,等后续服务器中需要用这个功能的时候再加。 > > 这也是个比较实用的功能,可以用于把一些静态的工作转为动态的模式。但是目前优先还是跑通基本框架,再加后续扩展功能。 >
  • 广播 > 广播其实就是个函数糖,实际发送底层还是得一个一个发,不过也可以简化一些操作就是了 >

服务器应用框架

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

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

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

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

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

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

协程果然非常爽。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

大型网站的灵魂——性能

Via: http://blog.jobbole.com/84433/ 前言 在前一篇随笔《大型网站系统架构的演化》中,介绍了大型网站的演化过程,期间穿插了一...

3326
来自专栏程序员互动联盟

【专业技术】Node.js 究竟是什么?

简介 如果您听说过 Node,或者阅读过一些文章,宣称 Node 是多么多么的棒,那么您可能会想:“Node 究竟是什么东西?” 即便是在参阅 Node 的主页...

3337
来自专栏恰童鞋骚年

《大型网站技术架构》读书笔记四:瞬时响应之网站的高性能架构

此篇已收录至《大型网站技术架构》读书笔记系列目录贴,点击访问该目录可获取更多内容。

1032
来自专栏java工会

15个顶级Java多线程面试题及答案,快来看看吧

1705
来自专栏魏琼东

DotNET企业架构应用实践-系统架构与性能-缓存技术与ORM中的缓存查询技术

系列回顾       在前面的文章DotNET企业架构应用实践-系统架构与性能-理论依据及相关做法一文中我介绍了系统性能优化的理论做了一个概括的介绍,也简单的介...

2287
来自专栏魏琼东

基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET平台开发指南 - 实现业务

业务分层         依据行业经验来看,分层是解决复杂问题的简单方法,通过分层,可以把一个复杂问题分解为不同层次应用的小问题,解决各层小问题的难度小于总的问...

19510
来自专栏F_Alex

SpringCloud-初识微服务(一)

1503
来自专栏Android 开发者

Android 开发者 | 应用兼容性注意事项

2803
来自专栏FreeBuf

利用HTTP参数污染方式绕过谷歌reCAPTCHA验证机制

今年初,我上报了一个谷歌reCAPTCHA验证码绕过漏洞,该漏洞在于能用一种HTTP参数污染的不安全方式,让Web页面上的reCAPTCHA构造一个针对 /re...

3453
来自专栏顾宇的研习笔记

AWS 上的生产环境架构优化案例

在AWS 上的生产环境性能分析案例一文中,记录了我对客户应用生产环境的一次性能分析。接下来,我们要根据所发现的性能问题进行架构优化,以提升可用性和性能。同时,这...

1571

扫码关注云+社区

领取腾讯云代金券