做服務(wù)器有一段時間了，想記錄下自己的體會。
依我的看法，服務(wù)器可以看做是4個部分組合起來的， 底層的網(wǎng)絡(luò)框架， 通用的數(shù)據(jù)結(jié)構(gòu)和庫， 整個服務(wù)器的架構(gòu)設(shè)計，服務(wù)器的上層業(yè)務(wù)邏輯。
底層的網(wǎng)絡(luò)框架，目前可以說技術(shù)基本都是公開的了， 可以自己從頭寫，采用iocp，epoll。也可以直接使用ace, libevent 或者asio,
如果是linux下，我覺得libevent是個非常好的選擇，效率足夠，而且可移植。代碼也簡單。ace的缺點，就是比較大，用他來開發(fā)，沒有什么問題，
遇到問題需要查找維護，就比較棘手了，asio看過一點，proactor模式的。口碑也不錯。
如果直接用這些庫來支撐上層邏輯，那么上層的開發(fā)還是比較麻煩的，自己還需要在這些庫的基礎(chǔ)上，再加上一些封裝，以簡化上層的開發(fā)難度。
譬如lau stephen老兄的spserver, 就是個不錯的嘗試。他是在libevent的基礎(chǔ)上，整合出一個應(yīng)用層框架。
網(wǎng)絡(luò)框架的兩個關(guān)鍵點，1是性能要足夠，2是要方便上層開發(fā)。3是要穩(wěn)定，有這3點，就足夠了、
通用的數(shù)據(jù)結(jié)構(gòu)和庫，主要是用來實現(xiàn)一些封裝，譬如封裝線程，封裝數(shù)據(jù)庫訪問，封裝線程池，封裝內(nèi)存池， 封裝線程安全的隊列，該隊列主要用來實現(xiàn)
半同步，半異步模式中關(guān)鍵的排隊層。 這個庫，應(yīng)該是隨著自己的經(jīng)驗和水平的增進而不斷改進的。對于大部分服務(wù)器的開發(fā)，這個庫都是必要的.
整個服務(wù)器的架構(gòu)設(shè)計，設(shè)計架構(gòu)的時候，考慮無非是簡單，容易擴展，安全性，成本也是一部分考慮。 沒有通用的架構(gòu)，只有針對自己的需求和條件的
比較好的架構(gòu)。所以千萬不能照抄架構(gòu)，要結(jié)合自己的實際情況來思考，別人的東西，只能參考。簡單的出發(fā)點，就是便于維護，KISS原則。
擴展性的關(guān)鍵，就在一個負(fù)載均衡，要保證系統(tǒng)中沒有會阻礙性能提升的障礙點。安全性的考慮，很多關(guān)鍵的業(yè)務(wù)，必須部署在內(nèi)網(wǎng)，以避免攻擊。
例如，網(wǎng)游中常用的gate架構(gòu)，既有安全性的考慮，也有負(fù)載均衡的考慮，他只把gate服務(wù)器部署在公網(wǎng)上。
服務(wù)器的上層業(yè)務(wù)邏輯， 這塊千差萬別，但是有一些共同的問題。譬如邏輯采用單線程還是多線程的問題，如果上層業(yè)務(wù)很簡單，譬如就是簡單的數(shù)據(jù)庫查詢或者
注冊認(rèn)證，可以采用多線程來做邏輯，盡可能的提高服務(wù)器的性能。但是如果是很復(fù)雜的業(yè)務(wù)，譬如im或者網(wǎng)游邏輯服務(wù)器，數(shù)據(jù)交互會非常多，這個時候，多線程
是很不可取的，維護，擴展性，都會出現(xiàn)很大的問題。查錯也會成為大麻煩。
最好的線程劃分還是按照業(yè)務(wù)的相關(guān)性，把業(yè)務(wù)糾纏比較緊密的，放在一個線程里。各個線程直接，通過消息或者隊列來進行通信。
邏輯服務(wù)器的高下，主要在于細(xì)節(jié)。譬如數(shù)據(jù)結(jié)構(gòu)的效率，內(nèi)存分配的效率，服務(wù)器的防御性編程處理， 對于客戶端的協(xié)議支持是否全面。 做邏輯服務(wù)器的關(guān)鍵，是要用心。只要是花心思了，保證穩(wěn)定，能夠滿足客戶端的業(yè)務(wù)需求和性能需求，就是很好了。