在写这篇文章前，我突然想到以前流行了一段时间的服务器面试题：当一个BUG只有几百万分之一的概率会出现，怎么办？这个问题在这个BUG里只是毛毛雨而已，因为这次的BUG的出现概率是夸张的三亿分之一。

我在好几年前自己开发了一个用于服务器进程间通信的框架，libatbus，以前用在了客户端的模块隔离的通信心痛中。并且现在开始正式用于服务器。但是前两天看了一下服务器的日志，发现了比较奇怪的-202错误。

这两天在做服务器框架的C的接口导出和C#的接入。之所以要做这么个东西是因为之前的服务器框架（atsf4g-co）已经完成了通信层面和基本设计模式的细节部分，而且基本算是最大化性能了吧。但是现在的项目的战斗引擎是从以前Unity游戏上抽象而来的，全部由C#编写。再加上最近再考虑接入实时战斗，这样就不能像之前一样用一个简单的通信方式了，必须使用一个高效并且实时性更高通信机制。需要能够处理好比较高的集中式的组播和容灾的通信方式。于是就有了把之前的C++的框架抽离出API来驱动逻辑的想法。这样也比较容易地兼顾开发成本和性能之间地权衡。

C Binding

那么抽离出框架地目的是抽象出应用底层，这个刚好是atapp做的事，而且atapp的层面对外暴露的接口数量也比较少，使用比较简单，所以索性就直接对它下手了。

让后第一步是把atapp需要使用的基本接口抽离出纯C的导出API。之所以要导出成纯C是因为，不同系统环境和编译器环境在C++层符号规则、入栈出栈顺序、内存布局、对其规则等等都不一样。这种情况要做跨平台就很是困难，然而这些在纯C的ISO里都是有明确规范的。所以最简单的方式就是导出到纯C，然后其他语言导入接口。这里的其他语言目前就只有C#，但是纯C接口的话如果想导出到lua或者其他语言的接口也不困难。

这里导出的时候有一点点小细节，那就是在Linux上的c api是默认导出的，但是在Windows里是默认不导出的，然后再加上不同编译器的导出用法不一样，所以第一步当然是统一导出标记。最终就是下面这一段

起源

现在的手游也开始越来越复杂，以前少量交互线上保存的服务器架构越来越不能满足现在越来越偏向PC端MMORPG的需求。比如现在手游也引入了地图服务、公会服务等等。特别是地图服务需要能够动态切换服务节点、并且由于广播量巨大，导致我们得用更多级的缓存和更复杂的负载均衡。这些缓存和负载均衡都会涉及缓存失效、同步、更新、发现延迟等问题，所以越来越需要一个路由系统来解决这些问题。

最近一直没什么时间整理近期碰到的问题，今天思考了一下之前碰到的一个临时处理的BUG，顺便写点东西清理一下思路。

其实严格来说这个BUG更应该是一个流程试用问题，不过这个问题应该是需要能在协程库里检测并抛出错误来。

近期仍然在搭建完整的游戏服务器架构。基于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来接入。

atbus是我按之前的思路写得服务器消息通信中间件，目标是简化服务器通信的流程，能够自动选择最优路线，自动的断线重连和通信通道维护。能够跨平台并且高效。

近期优化底层库，完成atapp库的基本功能，顺带优化了一下atbus的一些功能，也是对高效的大幅优化。这次的优化起源于某一次的压力测试，先介绍下压力测试的结果吧。

近期跟了一下pbc的lua-binding的一个老BUG，起源是我们客户端报了一个奇怪的问题，我们游戏里的某些功能的optional字段，服务器并没有下发数据，但是客户端竟然能读到。

一开始我去issues里翻，翻到了个这个， https://github.com/cloudwu/pbc/issues/27 。 这是2014年就发现的BUG了，然而云风说考虑到性能问题不想改。大事我觉得吧，就算一些性能损失，也好过容易出BUG，并且协议打解包在游戏中的CPU占用本身就不重。所以这能自己动手，丰衣足食喽。

libatbus

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

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

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

接上文关于bus通信系统的一些思考（二）

之前的文章内容应该要有修订，但是并没有更新到blog里，而是直接写在了libatbus的文档里

目录

前言

好久没写总结啦，最近一段时间比较忙，抽出的空闲时间都在不断完善之前提到的一个进程间通信lib的想法和实现（libatbus）。

因为这个想法从提出来后实现了共享内存通信的实现后，一直没抽出空来继续后面的内容。而且做得过程中发现，这比之前想象的还是要复杂一些，一个人的空闲时间很难做到非常的完善，只能先有个实现，以后再一点点地改善。毕竟人家TX两个人全职做了两年才能做到一个比较完整的解决方案，而且还不跨平台。我这个虽然有一些非核心的部分使用开源组件，能少很多工作量，但是要做到跨平台并且只是业余时间搞的话还是得慢慢来。

接上文

目录

BUS系统的设计思路

虽然我很不愿意再设计一套BUS系统，但是现有的一些确实都没有特别符合我的口味的。所以还是尝试设计一个出来。

结构设计

简单来说，我希望BUS系统可以简单、高效、稳定。

节点标识

首先，在节点标识方面，类似ZeroMQ的用字符串来标识端点的做法我认为是不必要的。这点上可以参照前面两种的设计，但某些情况下32位作类型分割的可能会不够，所以可以使用64位标识。其实还有一个重要的原因是64位数字可以整个存放在CPU寄存器里，可以通过一个汇编指令进行比较操作，无论性能还是可以表示的节点个数都很足够。

目录

概述

如何保证一个进程或线程能安全稳定地把一段消息发送到另一个进程和线程，甚至是另一台机器的进程或线程，再或是要通过代理转发到另一个进程或线程，一直是一个比较麻烦的问题。

最近看了一些和BUS系统有关的东西。对于游戏服务器集群所使用的BUS通信系统有一些想法和思路，但是由于我对其他类型的业务和框架不是很熟悉，有些想法可能仅是站在游戏服务端的立场上，所以可能有些地方还有一些局限性。