金山有一套自己的服务端,单服务端,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的问题,没去管它。
当个项目总监,特别是比较大项目的管理者还是很累的,不过我觉得做管理要有所依,服务端编程我不会放下,再忙每天都要抽出时间来写几段代码,其实管理很简单,我的风格不喜欢搞太多事情,懒,但是做管理这样是不够的,缺乏强沟通、强推动。总觉得团队少了最核心的一点什么。努力!
posted on 2009-10-22 10:49
大日如来 阅读(663)
评论(0) 编辑 收藏 引用 所属分类:
游戏-编程