之前寫了移動市場的淺談，當時是想緊接著寫這個系列的。包括即時通訊、播放器等。后來因為要回家定親加上要看房子，拖延了下來。今天接著寫，算是上班打醬油吧。也趁此機會罵下樓市，真心黑。破縣城都四千多五千。廢話不說了，說正題了。

做一款軟件，首先需要明確的不是你是單機的還是分布式的，cs的還是bs的。這些都是后話。第一個遇到的問題是這款軟件要實現什么功能，也即是市場以及設計者開發者對于這款軟件的需求預期是什么。

因為即時通訊軟件是比較成熟的了。所以功能就很好列出來。對于功能，最實惠一目了然的描述方法就是用例圖了。不過悲劇的是公司把端口給禁用了，上傳不了圖片。萬惡的公司。所以這里我就簡單羅列下了。

功能列表：

• 聊天：這個會包括三種方式（語音聊天、視頻聊天、文字聊天）。其又擴展為兩個場合（單人、多人）。其中文字聊天又包括文本、表情、圖片。其中表情可擴展為基本表情、自定義表情。
• 傳輸：擴展為兩種，文件傳輸、文件夾傳輸。其中功能點要包括：在線傳輸、離線傳輸。而且需要實現斷點續傳。
• 頻道：其實這個和聊天應該歸屬一個功能點下面的兩種。也可以說類似多人聊天，唯一不同的就是弱管理。用戶自己可申請開戶，然后再分到的頻道中發布相關信息，其他用戶可通過搜索頻道進入該電臺，然后在其中進行接受信息，并支持交互。
• 外圍方面，在硬件方面，包括移動端、PC端接入程序。即用戶可以使用手機、平板、PC等登陸。

? 功能列表已經列出來了，下面就是探討這個軟件的結構怎么部署了。所以他的deployment如下：

• 客戶端：即用戶接入程序。通過接入程序，用戶可以實現上面的所有功能。這個包括pc版本、平板版本、手機版本等。具體還要適配一大堆類型出來。工作量不可小覷，不過總體而言，他的開發策略就是原型式的，一處編寫到處修改。所謂適配就是改改改。
• 服務器：負責處理一些必要的后臺信息，如用戶登陸時的相關鑒權以及信息登記。?因為服務器不需要適配不同的機型。服務器用什么是我們說了算，終端用戶也不關心。所以在初期可以直接指定windows還是linux下的某一款。此處就暫定windows了。這邊適用的開發策略就是迭代式的了，因為功能繁多，慢慢迭代吧。個人不覺得迭代屬于敏捷開發，可能緣于個人對于敏捷的排斥，始終覺得這就是騙子，混飯吃也就罷了，還坑爹。尤其看到那些什么敏捷開發交流大會，個人感覺與傳銷無異。

即時通訊的部署的大致框架也說了，現在就是來看看技術難點了。一些不會擴散的功能點上的難點，其實不算難點。慢慢做就行了。所以軟件設計初期要考慮的是那些容易擴展全局的難點，就像癌癥在血液里，不搞定，小心全身崩潰。一些指甲發黑之類的，先拿刀剁了放旁邊，等哪天搞定了再接上來就行了。不過一些雖然會擴散全身的，但是束手無策的，個人感覺就當不存在就行了，反正沒招。

即時通訊，對于互聯網第一個遇到的問題是負載的問題。服務器的能力畢竟有限。這個時候不得不考慮第一個服務器進行專職化，就是多些服務器，各盡其職。重要的就是彼此之間職責要清晰。于是就出現了幾個服務器，第一個是專門用來接收用戶登錄的，負責鑒權以及更新數據庫。第二個是專門負責通信的，即用戶與用戶想互相說話，因為網絡問題，他們自己說不了，于是找了個中轉站。但是負載的問題依然存在，客戶多了，通信量大了，通信服務器扛不住。于是就想到了兩個辦法，第一就是治標不治本的辦法，搞集群，一大堆中轉服務器，但是瓶頸依然存在。第二個就是分流，能不通過通信服務器的就別走通信服務器了，于是就想到了P2P。經濟實惠的辦法還是P2P吧，雖然他的實現對于網絡有一些要求。

于是乎整個軟件的結構就清晰了。他主要包括：客戶端、服務器兩塊。其中服務器分：登錄服務器、通信服務器。具體會話的流程如下描述。

• 登錄：用戶首先登錄服務器，表明自己在線。用戶連接登錄服務器的指定端口，發起登錄請求。請求中攜帶必要的鑒權信息。登錄服務器找鑒權服務器進行鑒權，并根據鑒權結果跳轉處理策略。如果鑒權成功，則生成唯一的合法性SESSIONID（其中SESSIONID的一部分由用戶唯一ID組成），并將連接信息以及改ID打包交付數據庫服務器，其中狀態位標注為登錄，數據庫服務器負責入庫操作，存入的表為狀態表，并返回是否入庫成功。登錄服務器根據數據庫服務器的返回結果繼續跳轉處理策略。如果成功，則回復登錄成功的消息給用戶，并在消息體中攜帶連接服務器的相關信息以及SESSIONID。如果失敗則回復客戶端服務器繁忙，稍后再試。數據庫服務器定時掃描該狀態表，如果超過30s，而且狀態為非在線狀態的，則刪除該記錄。
• 連接：用戶接收到登錄服務器的返回結果，如果失敗，直接提示用戶即可。流程結束。如果成功，則從消息體中獲取連接服務器的信息，釋放與登錄服務器的連接，并使用之前的端口與連接服務器進行嘗試連接，連接失敗，直接提示用戶網絡超時。如果連接成功，則發送連接請求信息，其中消息體攜帶SESSIONID。連接服務器接收遠程連接之后，首先將其套接字標注為未初始化，當接收到客戶的連接請求時，從消息體中回去SESSIONID，然后將客戶端的連接信息以及SESSIONID打包發送至數據庫服務器進行進一步合法性檢查，如果數據庫服務器發現其一致，則回復合法，否則回復非法。連接服務器根據數據庫服務器的回復進行跳轉處理策略。如果接受到的是非法，則直接拒絕，強制中斷客戶端的連接。客戶端發現連接被強制中斷之后提示用戶服務異常。如果合法，則將SOCKET狀態更改為連接。并發送命令至數據庫服務器查詢該SESSIONID對應的用戶的相關信息，如好友列表、頭像、個性簽名等等，消息中并且攜帶在線好友，數據庫服務器接收到該消息，首先將之前紀錄的狀態更新為在線，然后去查詢相關表，將查詢到的信息打包返回至連接服務器。連接服務器接到信息之后轉發給用戶。數據庫服務器定時掃描狀態表，并通過連接服務器以保證客戶端信息同步。
• 用戶需要發起會話時，首先對連接服務器發起會話請求信息。連接服務器發送響應消息至A，消息體中攜帶通信服務器的相關連接信息。A接收消息后，根據消息體中的信息對通信服務器建立TCP連接。
• 消息中攜帶需要會話的用戶的唯一ID。連接服務器根據該唯一ID進行查詢狀態表，如果存在，則表示需要對話的用戶在線。則直接將請求消息中轉給通信服務器，通信服務器通知B用戶會話請求信息，消息中攜帶A用戶的連接信息。B接到消息之后直接對A發起一UDP數據包，消息體為空。然后B發送響應信息至通信服務器，通信服務器通知A現在可以開始與B會話。其中此處UDP與TCP使用同一端口。如果B不在線，則發送消息通知A，讓其直接將信息發送至通信服務器，通信服務器負責保存本地。等B上線時再進行轉發，其中保存時間可以設置。
• 離線。A斷開與連接服務器的連接。連接服務器發送命令至數據庫服務器更新狀態表中狀態為離線。數據庫服務器定時掃描狀態表，并觸發相應流程用于通知客戶好友的上線與離線，并保證狀態表的清潔。

因為上班時間寫的，所以就成了草稿。回頭我畫下相應的圖。總之，現在思路清晰了。整個系統包括以下幾個臺位：

• 客戶端：用于讓用戶接入系統
• 注冊服務器：用戶接入系統時使用，提供鑒權等相應處理
• 連接服務器：用于保持與所有用戶的連接，狀態消息的通知以及客戶會話請求時通信服務器相關信息的返回。
• 通信服務器：用于通信渠道的建立以及離線信息的保存。包括離線文件傳輸。根據實際情況可以考慮增加一臺文件服務器，供通信服務器使用。
• 數據庫服務器：提供對于數據庫所有的操作接口。所有關于數據庫的操作均歸必須通過該臺位。
• 鑒權服務器：可有可無，供注冊服務器使用，主要用于鑒權。

?

轉載于:https://www.cnblogs.com/BLoodMaster/archive/2012/10/08/2715369.html

總結

以上是生活随笔為你收集整理的即时通讯软件设计(一)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。