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