在北京郁闷的半年

 

北京呆了半年，在郁闷中结束了，做了半年CTO，但大部分时间还是在编码或review代码，别的也没什么好总结的，只好对这半年里面的技术决策做个简短总结：

1、  修改原基于openfire（java）为基础的服务器为基于c++的服务器程序，修改原基于xmpp的xml形式协议为json，由此节省带宽2/3，提高server端计算能力一个量级以上。其实我一开始是计划全做成二进制协议的，但发现这些同事们对二进制操作数据块都不熟悉，要教会他们这些要费很多时间，而老板给的时间很短，只要做个这种决策，采用json为主，混合二进制协议，最后也只在传输文件等很少的情况使用了二进制协议，其他基本都是json协议。

2、  规划了后端三台服务器各自的进程部署。

3、  将后端服务器程序分离为多个，主要由一个入口服务器gate接入，另外的server程序都为内部计算服务器，由gate统一管理，在gate上实现了cache、加密、压缩、转发、重发等操作，为后端服务器热升级提供了支持，热升级如果在设定的限定时间内完成，用户将只感觉某些调用慢了一点，如果超过设定时间，则会返回超时错误信息。

4、  修改原来一些基于数据库的极慢查询为基于内存的查询，将原来最长差不多要5分钟一次的查询优化到只需要40ms左右，提高了好近2个量级。

5、  在客户端网络库上增加了cache处理，由此，整个cache完备为3级缓存，客户端缓存，gate缓存，业务服务器缓存，有此三级缓存，节省了带宽，提高了用户的响应速度。

6、  将后端数据存储格式从netcdf修改为sqlite，容量减少到原来的1/6，一周一个文件，原来一周21（3*7）个文件，由此查询速度提高了一个数量级以上，而且很容易管理，可将一周的数据整体加载到内存处理，将速度提高更多。Netcdf作为一个相当于使用了聚集索引的存储格式，由于产生年代过于久远，完全无视其他索引，所以应该彻底摒弃，使用sqlite还可使得维护特别方便，工具轻易可找到，而且是标准sql维护，一学就会，节省大量的维护成本。也不知道为何之前他们采用了netcdf格式，而且还对这种格式很推崇，估计主要因为决策人对索引技术和存储不够了解吧。

7、  建立了完备的后端服务器监控体系，提出并实现了对os环境（os版本、磁盘剩余空间、cpu占用率）、进程、线程的监控，并实现了触发报警条件后的短信和email报警。

8、  将客户端的异步消息和异步定时器用统一的方式处理，复用了server端的多线程消息队列，能方便的控制这些线程的退出。

9、  修改了后端服务器使用memcached的方式，将部分使用memcached的应用修改为进程内缓存，提高计算一个量级，之前memcached传输+数据格式化等占用了90%以上的时间。

10、             实现了64位server程序框架，并将gate和一些需要大内存的服务采用了64位进程，其他采用32位进程(节省一点内存)。

11、             为排查客户端bug，提出了1）、建立统一编译环境。2）、release带pdb编译并引入crashreport。3）、辅助log机制。据此三点定位并解决客户端bug。可笑的是我提出这几点老板看不出它的价值，等我离开了却在按照我的规划部署实施，可笑可气可恨。

 

其实一直想研究一下memdb技术，并计划对上面提及的3和其他大数据量的查询等采用memdb实现，但由于时间紧迫，也没有深入去研究，曾计划采用fastdb等实现，但由于没有深入研究，最终也没有采用。Memdb技术如果研究深入，应该是可以实现更简单的使用，几乎不需要考虑线程同步的问题，并可提高多个线程并发使用的效率，该功能有待今后再研究吧。

Gate由于是刚过去的时候在很紧迫的情况下实现的，所以采用了较简单的线程策略，事实上还有一定的优化空间，另外对同一个功能的多个实现也没有做更复杂的选择器，只选择最先出现的一个实现，此处还需要做更多处理，以便可支持更复杂的调度。

关于公共库的实现，头文件等包含的细节太多，以后如果要公开头文件要考虑pimpl等方式隐藏部分实现细节，提高编译速度减少编译依赖等。

       还有一些优化速度和内存的方式，虽然给同事讲过多遍，但他们还只掌握了一点浅显的技术，离开了我也不想再给他们讲了，教他们太多了，到头来发现老板竟然认为我做的这些东西让a某某、b某某只要xx时间搞定，这样不懂技术的老板真是有眼无珠啊，我有一句话一直没对他说出来，如果你们的人都这么牛逼，何以3年还搞不定这么个东西啊。

       一点总结既是自己半年工作的简短回忆，也望同行们能吸取我的教训，碰到不懂技术不重视技术的老板，慎之慎之。