本文的潛在讀者是五年以下經驗的程式設計師，五年以上的資深工程師請繞道。

如果讀者有需求，本文回覆超過十個類似需求，我會整理一套開源的開發框架，含python/c++的socket伺服器端/客戶端程式碼，Java/oc的socket客戶端外加事件分發以及sample。這樣的框架github上有，但是我感覺現有的開源的都不是我理想中的（簡潔易懂）。

我們非常常見的一種業務需求是客戶端和服務端通訊。注意這裡的措辭，是客戶端和服務端通訊，在伺服器叢集中，伺服器本身也可以是客戶端。然而這裡不想討論分散式的結構。我們以APP為例子。

這個需求非常常見，但是大多數沒有架構設計的小團隊都會做的非常糟糕，通訊想怎麼寫就怎麼寫，一個原生socket寫下來，後面全亂套了。服務端的同僚N多時候也只關注自己的一畝三分地。導致整個專案的結構雜亂無章。

實際上，非同步通訊通常都會自建一套訊息分發機制。為了更好的梳理場景，我們先看看同步的（阻塞）的通訊的處理流程，如下圖。

通常APP開發人員都知道這種同步IO的場景。不涉及多執行緒和回撥等不那麼直白的結構。

可惜，很多業務都需要維持長時間的通訊（TCP/UDP）。因為要長時間的接收伺服器推送的訊息。例如要實現新聞APP的自動更新新聞列表。對這個需求還有比較折中的辦法來實現。

折中總是有代價的，代價就是資料流量的損耗。有些新聞APP的資料流量驚人，一天可以跑幾百MB，估計每隔一分鐘就去伺服器爬一次最新的新聞列表。

另外一些則必須要一個伺服器通知APP的機制。例如IM訊息，使用者A保不準哪會會給使用者B發一個訊息。如果還這樣去刷http，恐怕是非常不理想的方式。

這裡牽涉到回撥函式，多執行緒等幾個方面。簡單的用一個活動圖來表述一下我說的流程吧。

需要注意幾個地方。

一、PDU需要含一個seq_id，這是客戶端用來分發主動請求的內容的回撥事件的派發機制的索引id。

二、hashmap需要注意執行緒安全。----這個如果不處理，程式肯定會有問題。

三、callback的實現。Java通常用類似interface這類東西實現。C/C++則是函式指標。