又好久没写blog啦。诶最近好懒啊。正好过年在家里有点空，写完我那些lib的patch之后还有一点时间写一下2016年的总结吧。

之前两年的总结有点流水账，我还是写得随意一点好了，也没必要凑字数。

关于创业失败

2016年最大的一个事件应该算是创业失败吧，所以从之前的公司退出了。这两年的努力和经历让人感触良多，虽然是失败了，也不算是一无所得吧。接触到了如果呆在腾讯，永远也不可能接触到的东西。

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

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

由于之前整理的服务器框架已经完成了，就需要用各种静态分析工具跑一遍。原来的llvm+clang的编译脚本是从GCC那个脚本copy过来然后改的，使用的时候各种问题。所以干醋重新折腾一遍，重写了。

之前的脚本，每次升级版本都要折腾下，一开始是编译的默认静态库巨大无比，后来改成动态库后一会儿好一会儿不好。 目测3.9.0版本的问题是开启动态库的编译模式以后有些子工程还是静态库，并且会漏掉加-fPIC，即便我在cmake的选项里加了也没用。 而且有时候是用gcc编译正常，用clang自举编译的时候失败。 然后每次测试一次都要花费巨量的时间，巨慢无比。我只是编译出来玩+当某些工具使用啊喂。要不要这么折腾我啊喂。

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

我们目前的游戏第一次测试的时候笔记送匆忙，导致上线之后频繁更新。 比如BOSS战由于大区的人数和预期不一样导致的难度调整，或者是任务链或者数值调整，再加上一些BUG。

但是每次停服更新的话用户体验是比较伤的，所以后来就采取了一些措施来减少更新的停服时间。最后基本实现了不停服更新。

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

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

这个问题起源于以前给客户端写的一个log模块，然后里面为了线程安全且多线程下不互相写乱，并且因为这些系统基本都用比较高版本的编译器，都支持C++11了，所以就用了C++11的TLS功能。

但是Android的默认std库并不是libstdc++或者libc++，而是Bionic。IOS不知道是什么版本的标准库都不支持thread_local的关键字。 这个之前写过一个记录提到过 Android NDK undefined reference to ___tls_get_addr 错误。如果使用这个关键字，链接的时候会报错说找不到符号。

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

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

前言

之前写了个C++的协程框架libcopp，底层使用的是boost.context实现，然后剥离了对boost的依赖。然而这样意味着我必须时常跟进boost.context的更新。

顺带提一下这个协程库已经在我们线上服务器版本中使用了。

从最初的boost版本（我忘了从哪个版本开始了）一直到1.60版本，boost.context的变化都不大，都只是补全一些新的架构和体系结构，还有就是修复一些小细节的BUG，再就是增加了对valgrind的支持（之前写过一个Merge记录提到过）。新增的功能也只有execution_context(现在叫execution_context_v1)，这个东西我的libcopp里其实包含了这个功能，并且本身做得比它要功能丰富，所以没有接入的必要。另外在1.60版本的时候尝试使用Windows里的fiber（当然默认是关闭的），在1.61版本里被移除了。这些细节都不是特别重要，主要还是1.61版本的变化。

然而这次变化就比较大了，首先所有的API都变更了，汇编代码里的参数和返回值也都发生了变化，当然语义也不一样了，另外还增加了新的APIontop_fcontext。这些变化使得libcopp的逻辑关系也必须有一些相应的调整，为了理清思路，这些都在后面分析。

之前我的域名只有owent.net和www.owent.net买了SSL证书，现在有letsencrypt可以拿到免费的SSL签证，就稍微花了点时间把我的域名的其他部分接入了letsencrypt签证系统。另外根据其他人的一些配置建议，提高了HTTPS的安全性配置和性能配置（主要是缓存）。另外原本我的blog就已经启用了spdy，然而现在新版本的nginx（1.10）已经release，原先的spdy模块被取消，新增了http/2模块。但是直接换nginx掉包是不行滴（后面有说原因），所以顺带自己处理了一下HTTP/2和nginx新版本的问题。

并且也对公司里的域名和webserver也这么搞了一下。全面启用HTTPS。

接入letsencrypt

letsencrypt是Mozilla发起的一个提倡大家用加密的HTTP连接的项目，它允许大家申请到免费的SSL证书，用于HTTPS的证书认证。并且现在它的CA已经被大部分浏览器所接受。我这里本地Win10里使用的IE11，Edge，Firefox 46，Chrome 50全部都能认证通过了。当然手机上也可以。

前言

最近在分布式系统一致性方面，Raft算法比较火啊。所以就抽时间看了下这个算法。

之前已经有Paxos算法，用于解决分布式系统最终一致性问题，而且已经有了zookeeper这个成熟的开源实现。那么这个Raft算法有啥用呢？按照Raft官网的说法，这个算法的错误容忍和性能和Paxos算法类似，但是拥有更加简单易懂的设计。

看过Paxos算法的童鞋们都知道，这货复杂地和屎一样，为了实现去中心化而考虑了各种复杂的边界条件和时序下的可靠性。而Raft算法则根据实际应用中的需要，简化了设计模型，不采用去中心化设计，而是自动选举中心节点，并且在各种情况和时序下可以保证能够正确的选举出中心节点并保证数据的一致性。而且也正是由于能够选举出唯一的主节点（Leader）使得整个通信流程非常地简单，并且易于理解和维护。

那么它是如何做到这些的呢？

基本算法设计

Raft的基本设计可以参照官网介绍 https://raft.github.io/

官方网站上的图例可以点击节点，然后模拟节点crash或者超时或者收到请求时的通信流程。其实也是一个javascript的简单实现，有利于我们理解Raft算法的流程。

libatbus

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

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

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

使用_Markdown_写blog已经很久了，近期接触并且看了下流传已久的gitbook平台，感觉做得确实不错。、

之前写blog的时候一直用得是stackedit，是因为stackedit的对_Markdown_做了很多扩展，功能很强大，有自动目录、流程图、时序图等等，然后可以浏览器直接开很方便。但实际上这些功能写出的东西虽然不错，但是放到比如github上的时候，github不支持。目前大多数平台对_Mardown_的扩展都只是到了和github差不多的地步，没有到stackedit的程度。这也导致同样写得东西，复制到github或者其他的平台的时候还得过一遍样式，比较麻烦。而且这些扩展的功能也用得不太多。另外stackedit时不时被墙然后访问很不稳定也是挺麻烦的一件事儿。

再来说这个gitbook，看中他是觉得它做了一个可持续集成的功能。就是github _push_完以后可以通知gitbook然后让gitbook自动构建文档内容。这点和比如jenkins和travis等等的CI系统很像。然后支持构建成pdf、epub（开源电子书格式）、mobi（kindle电子书格式）和在线书籍。然后版式也挺漂亮，还支持模板，引用等等，感觉确实蛮适合出版发行的。虽然目前为止_Markdown_的功能丰富程度比起Latex还差不少，但是上手难度也比Latex低不少。还是非常有潜力的，而且gitbook支持用javascript写得插件，以后变数也可以很多。

所以我决定也尝尝鲜，首先是吧blog里的文章记录转移过来，然后后面的开源项目的wiki或者文档也用这玩意构建。因为我用_Markdown_写博文的时候本来就备份了一份在github，所以有现成的仓库，然后把目录结构和配置调整成gitbook所支持的就可以了。话说好像已经很多国内的文档和开源书籍用这个生成了。

使用Markdown写blog已经很久了，近期接触并且看了下流传已久的gitbook平台，感觉做得确实不错。、

之前写blog的时候一直用得是stackedit，是因为stackedit的对Markdown做了很多扩展，功能很强大，有自动目录、流程图、时序图等等，然后可以浏览器直接开很方便。但实际上这些功能写出的东西虽然不错，但是放到比如github上的时候，github不支持。目前大多数平台对Mardown的扩展都只是到了和github差不多的地步，没有到stackedit的程度。这也导致同样写得东西，复制到github或者其他的平台的时候还得过一遍样式，比较麻烦。而且这些扩展的功能也用得不太多。另外stackedit时不时被墙然后访问很不稳定也是挺麻烦的一件事儿。

再来说这个gitbook，看中他是觉得它做了一个可持续集成的功能。就是github push完以后可以通知gitbook然后让gitbook自动构建文档内容。这点和比如jenkins和travis等等的CI系统很像。然后支持构建成pdf、epub（开源电子书格式）、mobi（kindle电子书格式）和在线书籍。然后版式也挺漂亮，还支持模板，引用等等，感觉确实蛮适合出版发行的。虽然目前为止Markdown的功能丰富程度比起Latex还差不少，但是上手难度也比Latex低不少。还是非常有潜力的，而且gitbook支持用javascript写得插件，以后变数也可以很多。

所以我决定也尝尝鲜，首先是吧blog里的文章记录转移过来，然后后面的开源项目的wiki或者文档也用这玩意构建。因为我用Markdown写博文的时候本来就备份了一份在github，所以有现成的仓库，然后把目录结构和配置调整成gitbook所支持的就可以了。话说好像已经很多国内的文档和开源书籍用这个生成了。

前言

由于我们的客户端的元素和资源比较多，cocos框架的各种库质量参差不齐，导致了有些地方加载速度实在很慢。并且没有一个统一的内存管理机制导致了整个内存占用不太好控制。

同时手机的硬件环境实在是千差万别，在IOS上，由于CPU和IO比较好，很多东西重算代价倒不大。 但是在Android上，CPU本来就偏弱，然后很多国产性价比机器，零件都缩水在IO设备上，还附加了各种用于节能和降低发热的降频策略，锁CPU策略。导致了很多数据重建的延迟比较高。 然而我们很容易发现，大多数Android的机器的内存都非常高，动辄2-3GB。 所以就希望说我们的应用能够最大化的利用内存作为缓存，在IOS上内存不够时重算，在Android上就拼命地用内存坐缓存，加载loading速度。

近期的活动比较零散，主要的业余精力都放在了libatbus上了。但是这个一时半会也写不完，所以能整理出来的东西不多。就说下最近跟进的开源代码吧。

首先是，跨平台协程框架 libcopp 跟进merge了boost 1.60 的context组件，这部分改动不多。仅仅是例行合并。

然后是wordpress的代码高亮插件，WP-Code-Highlight.js，跟进使用了highlight.js 9.0.0版本，同样的我提交了以一个pull request到百度CDN，但是百度CDN都不会自动拉取cdnjs的仓库而且需要2-4周才会接受，所以到时候还要为这个百度的CDN额外加一个版本号。另外一个重要的变更就是highlight.js 9.0.0改变了文件名命名方式，这个比较麻烦，会导致新的主题名称和老的不一致。我没有花太多时间去处理这个问题，先简单地在升级完成后把无效的主题设置都改成了default。另外就是如果用的CDN只有老的highlight.js版本，可能生成的新的主题名称会404。涉及的主题主要是文件名里带减号（-）和点（.）的。我自己用的googlecode的style问题倒是不大。

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

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

目录

前言

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

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

之前做了一个转Excel表到lua/二进制/json/xml的工具-xresloader。目的一方面是方便策划。另一方面是统一客户端和服务器的转表模式，并且要灵活适应环境变化。

最初做的时候考虑到既要方便Windows下策划和前端使用，又要方便后台部署在服务器上使用，甚至要集成在一些自动化的系统里。所以必须要跨平台。

libcopp更新 (merge boost 1.59 context)

之前由于兴趣写了一个协程框架，目前这个框架已经投入项目中使用。

这个框架的上下文部分是使用了boost.context，但是从开始写libcopp到现在，boost.context也更新了几个版本。而之前几次merge基本都是简单地跟进了make_fcontext和jump_fcontext两个函数，这次就再稍微翻了一遍其他部分的代码。

boost.context的变化

首先是它在非windows栈分配的时候，增加了valgrind的适配。不过boost.context里的不同平台的栈缓冲区其实结构差不多，但是boost的实现里给复制粘贴了很多遍，所以我就干脆把这些地方合并啦。减少了一些重复代码。