作為一個IM入門菜鳥，在看了兩周的入門文章貼（http://www.52im.net/thread-464-1-1.html）后善绎，終于開始考慮開發(fā)相關(guān)的事情了。
第一步是畫一個簡單的前后端交互的架構(gòu)圖诫尽。結(jié)合網(wǎng)上的相關(guān)文章禀酱，自己給出了一個粗略的架構(gòu)圖。這張架構(gòu)圖只包含大顆粒度的業(yè)務(wù)牧嫉，只能說明粗略的架構(gòu)思路剂跟，不包含任何技術(shù)細節(jié)。
在實際開發(fā)中驹止，每個模塊的技術(shù)架構(gòu)浩聋、流程需要單獨去思考、設(shè)計臊恋、處理衣洁，也會在后面的文章中給出。
我的粗略架構(gòu)圖下圖：
這張圖抖仅，“客戶端”是所有流程的開始坊夫。
可能大家對這張30分鐘出來的圖不太理解（其實是我畫的太抽象）砖第，我來解釋下我的思路。
首先环凿，對于一個客戶端（此處僅先考慮APP梧兼，暫不考慮web）用戶來說，有兩種狀態(tài)：登錄和未登錄智听。不管處于這兩種中哪種狀態(tài)羽杰，都應(yīng)該保持與服務(wù)器的長連接。因為對于一個用戶來說到推，不管是否登錄都需要接受系統(tǒng)推送的消息考赛。
所以用戶與服務(wù)器的連接的關(guān)系有兩種：
1、短連接：用于業(yè)務(wù)接口莉测，比如登錄颜骤、登出、上傳捣卤、下載之類的忍抽；
2、長連接：用戶保持與服務(wù)端的連接董朝，獲得推送鸠项、實時消息等等；
基于這個前提益涧，就有了上面的圖锈锤。
舉個例子，比如單點聊天中發(fā)送圖片闲询，A發(fā)送圖片給B久免。
那么A準(zhǔn)備發(fā)送的圖片將會通過HTTP協(xié)議上傳到服務(wù)器，上傳成功后扭弧，服務(wù)器生成一個SOCKET的數(shù)據(jù)報文阎姥，準(zhǔn)備通知A和B。
這個數(shù)據(jù)報文就是通過長連接推送過去的鸽捻。
A收到報文呼巴，只要更新UI狀態(tài)就好。
B收到報文御蒲，會根據(jù)報文解析后的圖片URL去請求圖片信息衣赶，通過HTTP協(xié)議下載到本地。
這樣一次通信完成厚满。
其他類似的業(yè)務(wù)接口以此類推府瞄。
接下來就要進行服務(wù)端的開發(fā)框架和語言選型。
參考資料：
http://www.68idc.cn/help/jiabenmake/qita/2014051696081.html
