金山有一套自己的服务端，单服务端，c++的，跑在CentOS上。代码很庞大。维护起来不是很方面，而且个人感觉使用了太多的c++的特性。

第一次重构服务端是刚来的时候，包括多服务端构架，多线程底层，因为时间紧，使用的是我上一个服务端的大体框架，上一套服务器使用c++/stlport/boost/asio，逻辑是简单了，但是问题也隐藏起来了，这次干脆使用纯c代码+libev。当底层搭建完成程序员开始工作后，我利用剩余时间重新考虑了一下服务端，首先被我放弃的是一开始就考虑上万人承载、无缝地图等等，把承载放在了比较合理的设计8k，实际5k一组上，经过和其他部门的沟通，在构架上也做了一些改动，避免了一处明显的瓶颈设计。

再次重构依然采用多服务端构架，做了简单的跨*nix平台，目前在FreeBSD7.2和CentOS5.2上开发，底层是多线程，逻辑单线程，客户端监听使用4个收，4个发来处理IO，服务端之间是一个连接一个线程，kqueue/epoll只针对客户端监听使用，监听使用一个，4个收包线程一个线程使用一个。

逻辑线程就一个，简单的从收到的包的队列里取出数据然后处理。

都是些轻车熟路的东西，写下来不到1000行代码，效果还需要压来测试。

在一次次重构中，真正感觉到了简单的美丽，现在的代码连libev都抛弃了，kqueue/epoll简单包装了一下，纯c的代码运用起来也渐渐得心应手，没有任何复杂的数据结构，感觉很好。

valgrind终于进行了重大升级，虽然features上提的是支持MacOS，但好歹和FreeBSD同源不是，3.5.0版本在FreeBSD上使用再也不需要mount /proc了，而且上个版本在FB7.2上根本用不成。这次表现的很好，虽然误报依然一大堆，但好歹有报不是。终于不在FB上写程序的时候提心吊胆了，以前可是根本就没泄露检测工具。反倒是CentOS上编译valgrind失败，好像是一个define的问题，没去管它。

当个项目总监，特别是比较大项目的管理者还是很累的，不过我觉得做管理要有所依，服务端编程我不会放下，再忙每天都要抽出时间来写几段代码，其实管理很简单，我的风格不喜欢搞太多事情，懒，但是做管理这样是不够的，缺乏强沟通、强推动。总觉得团队少了最核心的一点什么。努力！