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

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

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

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

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

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

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

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