寫給程式設計師---技術感悟及有關高併發伺服器框架設計

   以一個從業19年的it技術人員視角看，有時候感覺到現在的程式設計師挺幸福的，各種開源產品，多種開發框架，所謂的架構設計更多的是選擇/選型；再想想曾經的微控制器，受限記憶體，低頻cpu，程式語言以彙編為主，到後來c/c++......日漸蒼白的頭髮，天知道我們經歷了什麼！

   技術發展的步伐伴隨著我們這代人的成長，見證著程式猿們為了變“懶”開始契而不捨的追求“複用”，從一開始的原始碼級複用，到工程/模組複用，再到二進位制複用，直到今天的服務化複用，我們經歷著從編碼規範，到分層架構，再到動態庫，進而追隨MS發展出的com/dcom，直到SOA及各種openRPC、微服務......一晃已是不惑之年！

   什麼是技術？在我看來所謂的技術其實是利用趁手的工具解決問題的能力，而經驗是在你看多了失敗後，從直接或間接的教訓中收穫的；經驗可在很大層度上避免犯錯，而解決問題的能力是要求總能找到最佳解決方案。時間沉澱下來的是：沒吃過豬肉，但見過各種豬各種跑法；收穫總是負面的，很多時候你會覺得，所謂流行或牛逼的技術，其實大多都是新瓶裝老酒。

   之前有朋友熱衷高併發伺服器架構設計，其實這是個偽命題，實際情況是：併發能力90%以上的場景是取決於業務的，更多的因該考慮scale out，再明確點就是需要考慮業務邏輯及資料訪問的scale out，這也是很多網際網路大廠解決方案的核心所在。對於另外10%的情況如果從純技術架構上探討高併發框架，應該考慮的事情包括但不限於：

   1. 需要實現一個AIO框架，如果需要跨平臺至少需要考慮適配 iocp/select/poll/epoll/kqueue/port等平臺相關實現方案，需要抽象出操作介面及事件介面。

    

   2. 需要實現一個高效的thread-pool，需要儘可能降低執行緒切換機率（滿負荷情況下），因此你可能需要一個lock-free佇列/或連結串列，精心設計機制，避免執行緒飢餓或任務延遲

       

   3. 需要設計高效的事件處理機制，事件佇列建議使用lock-free實現；有必要使用thread-pool進行任務分發，另外最好考慮一下IO執行緒和任務處理執行緒的隔離，防止io檢測不及時；協議解析歸到哪類執行緒（IO/業務），也需要慎重考慮。最好的辦法是讓執行緒池保留對應數量的“緊急任務”執行緒，然後讓IO/業務按規則共享池內執行緒。

       

   4. 框架的對外程式設計介面需要規範。建議封裝良好，遮蔽socket控制程式碼，讓外部使用者僅僅運算元據。至少需要暴露操作介面和事件介面。

   曾經大致按照這個思路實現過一個網路框架，效能還行，http小報文（64B）QPS高於nginx約30%（nginx約85萬/s，自研框架約110萬/s），測試環境24C/64G，雙千兆網路卡，併發連線數2048，CPU滿負。已用於商用。