在以前的章節中,咱們對服務端系統的設計實現原理進行了剖析,在這一章中,咱們將對服務端框架進行實際運用,實現一款運行於內網環境的聊天系統。該聊天系統由客戶端與服務器兩部分組成,同時服務端經過數據庫維護用戶的帳號信息。本章將重點介紹如何運用該服務端框架進行服務器業務邏輯開發。sql
本聊天系統只做爲服務端框架的運用展現,所以僅限於最基本的局域網聊天工具,數據傳輸均採用爲明文形式,並不在安全性上進行深刻探討。具體功能需求分析以下:數據庫
聊天系統須要維護用戶的帳號信息,記錄註冊的新帳號,並對每次登陸的用戶信息進行校驗。咱們選用輕量級的Mysql做爲數據庫管理系統,並選擇Mysql++做爲Mysql的API操做庫。安全
整個聊天系統只創建了一個名爲UserInfo表結構,如表5-1所示。同時根據Mysql++封裝了兩個操做接口,分別添加新用戶帳號信息,以及根據帳號名和密碼查詢該用戶是否存在。服務器
表5-1 用戶帳號信息表UserInfo網絡
字段名併發 |
數據類型框架 |
關鍵字異步 |
約束工具 |
含義spa |
id |
int(20) |
Y |
unique |
惟一標識符 |
username |
varchar(20) |
N |
unique,not null |
帳號名 |
Password |
varchar(20) |
N |
not null |
密碼 |
因爲數據庫操做涉及網絡傳輸及磁盤處理,所以屬於耗時操做。而在服務端框架Reactor反應池中的全部處理必須在非阻塞環境下進行,若是進行耗時操做將會阻塞當前線程,致使其它消息事件得不到及時處理。所以在Reactor中進行數據庫操做應該以異步的方式進行,能夠經過建立工做線程池的方式處理數據庫等耗時操做。可是在本聊天系統中,只有在註冊新用戶和用戶登陸兩個場景中才涉及數據庫操做。爲了簡化開發模型,咱們在此直接調用數據庫相關的操做。
數據庫部分並不是本文論述重點,所以再也不作進一步介紹。
經過分析功能需求,能夠得知客戶端鏈接主要存在兩種狀態下的消息請求,分別爲臨時狀態和登陸狀態。在臨時狀態下須要可以請求註冊新用戶和登陸操做,在登陸狀態下須要可以請求當前在線用戶信息,向某個用戶發送消息類型和廣播消息類型。而且因爲服務器存在登陸超時的機制,客戶端鏈接無論在臨時狀態仍是登陸狀態,均需定時向服務器發送心跳消息。
客戶端的兩種狀態正好對應於服務端框架制定的兩種設備類型,即臨時設備類型和登陸設備類型。如圖5-1所示。咱們爲臨時設備添加新的註冊帳號消息事件,用於向全部與服務端創建了鏈接的客戶進行註冊操做。同時咱們建立一個新的設備類型,名爲ChatType設備類型,而且繼承於登陸設備類型,用於專門處理登陸後和聊天相關的消息事件。
圖5-1 聊天設備類型及消息事件
臨時設備類型新添加的消息事件介紹以下:
ChatType爲新建立的繼承於默認登陸設備的設備類型,具體實現的消息事件介紹以下:
雖然咱們已經爲聊天客戶端的鏈接制定了具體的設備類型和消息事件,可是一些和鏈接狀態相關的業務邏輯仍然須要咱們設計。好比如何制定與聊天客戶端相關的具體登陸過程?當某個聊天客戶端已經成功登陸後,怎樣第一時間通知其餘客戶端該帳號已上線?當某個聊天客戶端退出時,又如何通知其餘客戶端該帳號已下線?這些與客戶端狀態相關的操做都依賴上一章節制定的鏈接生命週期機制來進行管理。
圖5-2 聊天設備的生命週期
具體的聊天設備的鏈接生命週期實現如圖所示。咱們只需對具體業務相關的生命週期接口的實現進行重寫便可,所以無需進行更改的生命週期接口並未被列出。須要被重寫的接口實現介紹以下:
該聊天系統部署於局域網內,並可經過C#實現的客戶端進行相關操做。運行場景截圖以下:
圖5-3 登陸及註冊窗口
如圖5-3爲客戶端的登陸窗口與註冊窗口。註冊窗口經過登陸窗口的註冊按鍵打開,並可進行新帳號的註冊操做。同時登陸窗口能夠進行帳號的登陸操做,若是登陸失敗將會顯示具體失敗緣由;若是登陸成功,將會進入客戶端主界面。
圖5-4 主界面及好友聊天窗口
如圖5-4爲客戶端的主界面及聊天窗口。在主界面中顯示了當前登陸的用戶名及當前在線的用戶名列及數量。能夠單擊具體用戶名進入與該用戶的聊天窗口。在聊天窗口中,能夠在輸入欄輸入消息,並點擊發送鍵或按下回車鍵發送該消息。若是收到其餘用戶的聊天消息,客戶端也會主動彈出該用戶的聊天窗口,並顯示接收的的聊天信息。在主界面的下方還存在羣聊按鍵,點擊能夠進入羣聊窗口。
圖5-5 羣聊窗口
如圖5-5爲羣聊窗口。在羣聊窗口中能夠接收到打開了該窗口的其餘用戶發送的聊天信息。同時本身也能輸入相關聊天消息併發送給全部該窗口下的其餘用戶。