金山有一套自己的服務端，單服務端，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的問題，沒去管它。

當個項目總監，特別是比較大項目的管理者還是很累的，不過我覺得做管理要有所依，服務端編程我不會放下，再忙每天都要抽出時間來寫幾段代碼，其實管理很簡單，我的風格不喜歡搞太多事情，懶，但是做管理這樣是不夠的，缺乏強溝通、強推動。總覺得團隊少了最核心的一點什么。努力！