寫給程序員---技術(shù)感悟及有關(guān)高并發(fā)服務(wù)器框架設(shè)計(jì)

   以一個(gè)從業(yè)19年的it技術(shù)人員視角看，有時(shí)候感覺到現(xiàn)在的程序員挺幸福的，各種開源產(chǎn)品，多種開發(fā)框架，所謂的架構(gòu)設(shè)計(jì)更多的是選擇/選型；再想想曾經(jīng)的單片機(jī)，受限內(nèi)存，低頻cpu，編程語言以匯編為主，到后來c/c++......日漸蒼白的頭發(fā)，天知道我們經(jīng)歷了什么！

   技術(shù)發(fā)展的步伐伴隨著我們這代人的成長(zhǎng)，見證著程序猿們?yōu)榱俗儭皯小遍_始契而不舍的追求“復(fù)用”，從一開始的源碼級(jí)復(fù)用，到工程/模塊復(fù)用，再到二進(jìn)制復(fù)用，直到今天的服務(wù)化復(fù)用，我們經(jīng)歷著從編碼規(guī)范，到分層架構(gòu)，再到動(dòng)態(tài)庫，進(jìn)而追隨MS發(fā)展出的com/dcom，直到SOA及各種openRPC、微服務(wù)......一晃已是不惑之年！

   什么是技術(shù)？在我看來所謂的技術(shù)其實(shí)是利用趁手的工具解決問題的能力，而經(jīng)驗(yàn)是在你看多了失敗后，從直接或間接的教訓(xùn)中收獲的；經(jīng)驗(yàn)可在很大層度上避免犯錯(cuò)，而解決問題的能力是要求總能找到最佳解決方案。時(shí)間沉淀下來的是：沒吃過豬肉，但見過各種豬各種跑法；收獲總是負(fù)面的，很多時(shí)候你會(huì)覺得，所謂流行或牛逼的技術(shù)，其實(shí)大多都是新瓶裝老酒。

   之前有朋友熱衷高并發(fā)服務(wù)器架構(gòu)設(shè)計(jì)，其實(shí)這是個(gè)偽命題，實(shí)際情況是：并發(fā)能力90%以上的場(chǎng)景是取決于業(yè)務(wù)的，更多的因該考慮scale out，再明確點(diǎn)就是需要考慮業(yè)務(wù)邏輯及數(shù)據(jù)訪問的scale out，這也是很多互聯(lián)網(wǎng)大廠解決方案的核心所在。對(duì)于另外10%的情況如果從純技術(shù)架構(gòu)上探討高并發(fā)框架，應(yīng)該考慮的事情包括但不限于：

   1. 需要實(shí)現(xiàn)一個(gè)AIO框架，如果需要跨平臺(tái)至少需要考慮適配 iocp/select/poll/epoll/kqueue/port等平臺(tái)相關(guān)實(shí)現(xiàn)方案，需要抽象出操作接口及事件接口。

   2. 需要實(shí)現(xiàn)一個(gè)高效的thread-pool，需要盡可能降低線程切換概率（滿負(fù)荷情況下），因此你可能需要一個(gè)lock-free隊(duì)列/或鏈表，精心設(shè)計(jì)機(jī)制，避免線程饑餓或任務(wù)延遲

   3. 需要設(shè)計(jì)高效的事件處理機(jī)制，事件隊(duì)列建議使用lock-free實(shí)現(xiàn)；有必要使用thread-pool進(jìn)行任務(wù)分發(fā)，另外最好考慮一下IO線程和任務(wù)處理線程的隔離，防止io檢測(cè)不及時(shí)；協(xié)議解析歸到哪類線程（IO/業(yè)務(wù)），也需要慎重考慮。最好的辦法是讓線程池保留對(duì)應(yīng)數(shù)量的“緊急任務(wù)”線程，然后讓IO/業(yè)務(wù)按規(guī)則共享池內(nèi)線程。

   4. 框架的對(duì)外編程接口需要規(guī)范。建議封裝良好，屏蔽socket句柄，讓外部使用者僅僅操作數(shù)據(jù)。至少需要暴露操作接口和事件接口。

   曾經(jīng)大致按照這個(gè)思路實(shí)現(xiàn)過一個(gè)網(wǎng)絡(luò)框架，性能還行，http小報(bào)文（64B）QPS高于nginx約30%（nginx約85萬/s，自研框架約110萬/s），測(cè)試環(huán)境24C/64G，雙千兆網(wǎng)卡，并發(fā)連接數(shù)2048，CPU滿負(fù)。已用于商用。