金山有一套自己的服務(wù)端，單服務(wù)端，c++的，跑在CentOS上。代碼很龐大。維護起來不是很方面，而且個人感覺使用了太多的c++的特性。

第一次重構(gòu)服務(wù)端是剛來的時候，包括多服務(wù)端構(gòu)架，多線程底層，因為時間緊，使用的是我上一個服務(wù)端的大體框架，上一套服務(wù)器使用c++/stlport/boost/asio，邏輯是簡單了，但是問題也隱藏起來了，這次干脆使用純c代碼+libev。當(dāng)?shù)讓哟罱ㄍ瓿沙绦騿T開始工作后，我利用剩余時間重新考慮了一下服務(wù)端，首先被我放棄的是一開始就考慮上萬人承載、無縫地圖等等，把承載放在了比較合理的設(shè)計8k，實際5k一組上，經(jīng)過和其他部門的溝通，在構(gòu)架上也做了一些改動，避免了一處明顯的瓶頸設(shè)計。

再次重構(gòu)依然采用多服務(wù)端構(gòu)架，做了簡單的跨*nix平臺，目前在FreeBSD7.2和CentOS5.2上開發(fā)，底層是多線程，邏輯單線程，客戶端監(jiān)聽使用4個收，4個發(fā)來處理IO，服務(wù)端之間是一個連接一個線程，kqueue/epoll只針對客戶端監(jiān)聽使用，監(jiān)聽使用一個，4個收包線程一個線程使用一個。

邏輯線程就一個，簡單的從收到的包的隊列里取出數(shù)據(jù)然后處理。

都是些輕車熟路的東西，寫下來不到1000行代碼，效果還需要壓來測試。

在一次次重構(gòu)中，真正感覺到了簡單的美麗，現(xiàn)在的代碼連libev都拋棄了，kqueue/epoll簡單包裝了一下，純c的代碼運用起來也漸漸得心應(yīng)手，沒有任何復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，感覺很好。

valgrind終于進行了重大升級，雖然features上提的是支持MacOS，但好歹和FreeBSD同源不是，3.5.0版本在FreeBSD上使用再也不需要mount /proc了，而且上個版本在FB7.2上根本用不成。這次表現(xiàn)的很好，雖然誤報依然一大堆，但好歹有報不是。終于不在FB上寫程序的時候提心吊膽了，以前可是根本就沒泄露檢測工具。反倒是CentOS上編譯valgrind失敗，好像是一個define的問題，沒去管它。

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