我們知道，客戶端是相對服務(wù)端而言的，客戶端程序相對普通應(yīng)用程序，主要是增加了網(wǎng)絡(luò)通訊功能。在這個移動和云存儲的年代，大部分終端應(yīng)用程序都有網(wǎng)絡(luò)通訊功能， 所以都可以稱為客戶端。常見的客戶端如瀏覽器，IM客戶端， 網(wǎng)絡(luò)會議客戶端，郵件客戶端，微博和微信客戶端等...
通過觀察，我們會發(fā)現(xiàn)所有的客戶端基本是大同小異，都會包括一些相同的功能組件， 下面簡單例舉下：
通訊協(xié)議層
既然客戶端都有網(wǎng)絡(luò)功能，就會涉及到通訊方式和數(shù)據(jù)格式以及協(xié)議， 這三者不是完全獨立，而是有機統(tǒng)一的。
首先說通訊方式，常見的通訊方式包括TCP，UDP， P2P和http(s), 很多時候我們不會用單一的通訊方式，而是多種通訊方式的結(jié)合。比如說TCP端口被封，走不通時，我們會轉(zhuǎn)成嘗試http(s)。IM中聊天文本走的是TCP， 由服務(wù)器轉(zhuǎn)發(fā)，但是2個客戶端之間的文件傳輸我們可能走的又是P2P了， 多個人之間的語音聊天， 我們走的又是UDP了。
其次說數(shù)據(jù)格式，常見的數(shù)據(jù)格式包括二進制編碼，開源序列化協(xié)議和文本格式。
二進制一般是自定義的私有格式，通常對數(shù)值，我們會轉(zhuǎn)成大頭端，對字符串我們會用UTF8 編碼，因為沒有冗余數(shù)據(jù)，它的優(yōu)點是不會浪費帶寬；主要缺點是有硬編碼的味道，不好擴充。
開源序列化協(xié)議這里主要是指google的protocal buffer, 現(xiàn)在很多公司都在用， 很多人基于它開發(fā)了自己的RPC框架。主要優(yōu)點是數(shù)據(jù)小，使用簡單而高效。
文本格式主要是指xml和json. 相對來說xml比較清晰和容易擴充，但是冗余數(shù)據(jù)比較多。json借助javascript對它語言層次的支持，感覺主要是前端人員使用的比較多。
最后再說協(xié)議, 協(xié)議和我們的應(yīng)用相關(guān)聯(lián)。比如郵件客戶端，當然是走SMTP和POP3了; IM客戶端的話，一般走XMPP了; 網(wǎng)絡(luò)會議的話，可以走ITU的T.120協(xié)議， 也可以RFC 6501定義的XCON， 信令走SIP， 數(shù)據(jù)走RTP等。
通信協(xié)議層是整個客戶端網(wǎng)絡(luò)事件驅(qū)動的引擎，它可能會比較簡單，也可能會很復(fù)雜。如果是基于XMPP的IM， 它可能會比較簡單，因為基本上只需要一層文本協(xié)議的封包和解包就可以了。 當如果是基于T.120網(wǎng)絡(luò)會議客戶端，就會比較復(fù)雜，它數(shù)據(jù)包走的自定義的二機制格式，按照T.120協(xié)議的建議， 在通訊協(xié)議層又分了3層：TP, MCS和GCC。TP層主要封裝數(shù)據(jù)傳輸?shù)姆绞? 可以讓上層無差別的區(qū)分TCP和http(s)。 MCS層主要提供多點傳輸功能， 它抽象出通道(channel)這個概念， 讓不同session的數(shù)據(jù)進行邏輯隔離， 上層用戶可以同時加入不同的通道來進行一對一和一對多的數(shù)據(jù)收發(fā)，并且通道中的數(shù)據(jù)有不同的優(yōu)先級， 還有令牌這個機制。我們也可以在MCS層對數(shù)據(jù)進行加密和壓縮， 還可以對上層的大數(shù)據(jù)包進行切包等。 GCC層主要封裝會議的最基本邏輯，比如創(chuàng)建會議和加入session數(shù)據(jù)包的格式封裝等， 讓上層可以通過API調(diào)用而不用關(guān)心協(xié)議要求的數(shù)據(jù)包格式。不同的數(shù)據(jù)包會工作在不同的層次， 比如心跳包可能在底層TP層就被攔截了，它不要再往上層發(fā)，因為上面不用關(guān)心這個； 而有些數(shù)據(jù)包，則需要從底層往上層按照整個協(xié)議棧層層轉(zhuǎn)發(fā)，當然每層都會剝離掉自己的協(xié)議頭， 直至上層用戶數(shù)據(jù)到達它的最終用戶。
總之，通訊協(xié)議層封裝了客戶端和服務(wù)端的通訊方式及協(xié)議格式， 讓上層用戶不用關(guān)心底層的通信機制， 而只關(guān)注應(yīng)用的接口事件。理論上我們可以在上層應(yīng)用不做大調(diào)整的前提下，直接將網(wǎng)絡(luò)會議客戶端中的T.120協(xié)議成基于SIP的XCON。
功能組件
一個客戶端程序通常是由很多功能模塊組成，模塊按功能來說可以分為基礎(chǔ)組件和應(yīng)用組件。
基礎(chǔ)組件為應(yīng)用組件提供的基礎(chǔ)設(shè)施，基礎(chǔ)組件是可以在不同的項目中重復(fù)使用的(比如界面控件庫，2D渲染引擎Skia, 跨平臺的網(wǎng)絡(luò)和線程庫等)。
應(yīng)用組件通常和我們當前的特定應(yīng)用程序相關(guān)，比如我們的網(wǎng)絡(luò)會議客戶端包含的桌面共享模塊, 文檔共享模塊，視頻音頻模塊，文本聊天模塊等。
應(yīng)用模塊本身分為帶界面和無界面兩種情況， 帶界面的情況下我們通常會給組件提供一個容器窗口的句柄， 讓組件自己在內(nèi)部組織自己的界面。這種帶界面的組件通常會為邏輯和界面的分離帶來麻煩，在Window上實現(xiàn)一些半透明和動畫效果也很難。 比如我們想提供跨平臺的SDK來封裝邏輯，這時我們會更傾向讓應(yīng)用組件采用無界面的模式，組件在跨平臺層只封裝邏輯和提供數(shù)據(jù)， 而把數(shù)據(jù)發(fā)到最上層界面層后再統(tǒng)一處理。
對功能組件我們的設(shè)計原則是盡量保持獨立和可復(fù)用，最好能以仿COM方式動態(tài)升級而不用重新編譯， 另外組件之間要保持層次性，避免雙向或是循環(huán)依賴。
數(shù)據(jù)存儲
客戶端本身是處理和收發(fā)網(wǎng)絡(luò)數(shù)據(jù)， 這里就涉及到對這些數(shù)據(jù)如何組織和存儲的問題。這個通常會根據(jù)客戶端的類型采用不同的處處理方式:
對于永久存儲的數(shù)據(jù)，當然是保存成文件或是存入數(shù)據(jù)庫，文件如xml, 數(shù)據(jù)庫如ACCESS, SQL server, mysql等。
臨時數(shù)據(jù)當然是存入內(nèi)存了，根據(jù)需要采用不同的數(shù)據(jù)結(jié)構(gòu)， 組織格式如array，list, map, hashmap等。
還有一種是常見的數(shù)據(jù)保存方式是內(nèi)存數(shù)據(jù)庫，最常見是SQLite了， 內(nèi)存數(shù)據(jù)庫既能高效的分類保存大量數(shù)據(jù)， 又可以直接用基于SQL語句進行查詢和處理， 比如foxmail客戶端就是用SQLite存儲的郵件信息。
還有一種是跨進程共享的數(shù)據(jù)，我們一般當然是內(nèi)存映射文件了。比如我們有一個實時顯示log的工具， 我們通常會在對方應(yīng)用程序里分配共享內(nèi)存的內(nèi)存映射文件，所有的log都寫到里面，然后在log工具程序里讀取和顯示。
當然還有一些數(shù)據(jù)可能存到網(wǎng)上去的， 常見的比如我們的云筆記, 這時數(shù)據(jù)分服務(wù)端數(shù)據(jù)和本地cache。
對于數(shù)據(jù)存儲我們的設(shè)計原則是根據(jù)需要，選擇簡單高效的方式。比如我們在設(shè)計網(wǎng)絡(luò)會議客戶端時曾討論要不要引入SQLite, 理想情況是引入內(nèi)存數(shù)據(jù)庫后各個組件和上層應(yīng)用的數(shù)據(jù)都可以統(tǒng)一存儲，采用數(shù)據(jù)驅(qū)動的方式，可以很方便的跟蹤整個客戶端的運行情況。但后來發(fā)現(xiàn)這種設(shè)計會把本來各自獨立的組件通過數(shù)據(jù)庫耦合在了一起，而且各組件的數(shù)據(jù)格式本身都很不要一樣， 很難統(tǒng)一存儲， 另外很多數(shù)據(jù)實際也只是臨時數(shù)據(jù), 沒必要把簡單的時間做復(fù)雜了。
客戶端框架
客戶端框架一般有兩個作用：一是把所有的功能組件組織起來，進行統(tǒng)一的管理和展現(xiàn)； 二是實現(xiàn)整個客戶端的主界面。客戶端框架在協(xié)調(diào)各個組件時， 要注意避免讓組件之間產(chǎn)生雙向依賴， 而是應(yīng)該讓組件把事件通知給框架后由框架統(tǒng)一協(xié)調(diào)和處理， 所以客戶端框架通常是整個客戶端邏輯最復(fù)雜的部分。 一個好的客戶端框架，通常會采用插件方式設(shè)計，可以動態(tài)插拔需要的組件。最好是可以根據(jù)服務(wù)端的配置， 動態(tài)下載和更新所需要的插件。
對于客戶端框架， 我們的設(shè)計原則是低耦合和可擴展。基本上所有下層組件的改動都會影響到我們的客戶端框架，客戶的很多新需求和新組件也會導(dǎo)致框架產(chǎn)生壞味道， 這里我們設(shè)計時就要考慮如何讓客戶端框架能及時的適應(yīng)這些變化。
界面庫
客戶端肯定會有界面，在Windows平臺上，現(xiàn)在的界面大致分為以下幾類：
基于Windows原始窗口控件句柄的C++ native 客戶端， 基于.net的winform客戶端，基于.net的WPF客戶端，基于C++的DirectUI客戶端， 以嵌入瀏覽器(如webkit)方式實現(xiàn)的客戶端， 還有一類是基于Xaml的Metro客戶端。
對于企業(yè)級大型安裝應(yīng)用，主要考慮的是開發(fā)效率，所以客戶端還是以.net為主； 但是對于互聯(lián)網(wǎng)企業(yè)， 更多的是要求客戶端精簡而高效， 所以還是以C++為主。 這里就設(shè)及到C++的兩種界面庫， 一種是基于windows窗口句柄和控件自繪機制的界面庫，還有一中是基于DirectUI的界面庫， 現(xiàn)在大一點的公司基本上都有自己的DirectUI界面庫。基于修改Webkit方式實現(xiàn)的界面庫可以通過Canvas和SVG動畫等方式實現(xiàn)一些很炫的效果， 但是它和標準程序的用戶體驗還是有一定差距：一來web實現(xiàn)的控件跟Windows標準控件有很大不同， 二來web的流式布局和應(yīng)用程序的網(wǎng)格布局也不一樣。
對于界面，個人覺得這個東西變化實在太快了，所以我覺得應(yīng)該盡量用界面和邏輯相分離的方式組織代碼。
總結(jié)
對于客戶端架構(gòu)設(shè)計，個人覺得最大的原則就分層設(shè)計， 每層都封裝一個概念并保持獨立， 同時根據(jù)依賴倒置的原則， 站在上層客戶的角度提供接口。軟件工程里面的一條黃金定律:“任何問題都可以通過增加一個間接層來解決。
posted on 2014-07-26 23:49
Richard Wei 閱讀(7416)
評論(2) 編輯 收藏 引用 所屬分類:
架構(gòu)體系