在移動互聯(lián)網(wǎng)快速推動創(chuàng)業(yè)浪潮的今天，絕大多數(shù)應用在構建之初都將社交元素潛意識的列入到了其產(chǎn)品功能清單中，即時通訊服務作為強社交的載體，又一次強勢回歸到應用設計者的視野中來。同時也涌現(xiàn)出了大量以即時通訊服務為賣點的產(chǎn)品，如具有代表性的用友IM。
企業(yè)級市場，即時通訊服務的產(chǎn)品設計與技術架構也發(fā)生了巨大的變化:1、從原本僅支持自身軟件業(yè)務的場景轉變?yōu)樾柚尉�上與線下業(yè)務的混合場景；2、服務架構更開放與透明，完全無狀態(tài)化；3、配合云計算、大數(shù)據(jù)等成熟技術，支持具備接入海量數(shù)據(jù)及業(yè)務服務的能力；4、支持更多種類的客戶端及協(xié)議，服務端具備接入適配功能。
從客戶端設計角度出發(fā)，移動化催生了設備的多樣性，保障各終端的使用統(tǒng)一成為了客戶端設計的關鍵。要求即時通訊服務不限制服務接入的方式和協(xié)議，不管服務是通過移動網(wǎng)絡還是固定網(wǎng)絡接入，也不管協(xié)議是否支持HTTP、XMPP、MQTT、TCP等，都應可以得到所需消息的響應服務。企業(yè)級客戶端通常功能比較復雜，需要應用設計者重新劃分功能層次，最終可歸納為2種形式(API和SDK)。站在通訊協(xié)議角度，應根據(jù)客戶端自身特點，從輕到重進行技術選型，如：推薦HTML5采用WebSocket協(xié)議實現(xiàn)，避免使用HTTP長短輪詢及一些RIA插件實現(xiàn)。
客戶端形態(tài)方面，桌面及移動原生APP對比WEB APP相對較重，通常采用SDK + TCP/UDP實現(xiàn)，應用設計者在設計客戶端SDK時候應關注提升性能和擴展性上，通用SDK一般包含線程控制、編解碼、鎖與資源、粘包丟包、壓縮與加密、內存管理等處理模塊。
包含即時通訊服務的企業(yè)應用客戶端也在朝著更簡潔、碎片的方向發(fā)展，下面重點談談如何構建企業(yè)級即時通訊的核心“通訊服務”。首先先回顧一下目前即時通訊服務面臨的挑戰(zhàn):1、海量通訊數(shù)據(jù)處理；2、高并發(fā)，高事務；3、復雜協(xié)議轉換；4、大規(guī)模集群下穩(wěn)定性及容災問題；5、快速通訊消息響應；6、平滑服務擴展；以上6大問題將影響保障通訊服務能力的基礎問題。
雖然通過云計算架構、容器架構、微服務架構等流行技術可以解決即時通訊服務中彈性、容災、自動化及異地網(wǎng)絡問題，但是其自身特性決定了其技術的細致程度，類似鐘表行業(yè)的瑞士，需要追求極致。很難像其他應用一樣去適應通用云平臺，其中一個簡單的例子，即時通訊服務的負載均衡器很少通過軟負載去實現(xiàn)，如果采用軟負載去實現(xiàn)，負載均衡本身將成為瓶頸點，尤其是在僅維持連接狀態(tài)的長連場景下。云平臺的設計勢必要向即時通訊服務傾斜，成為專有云。
針對企業(yè)級即時通訊服務本身，企業(yè)在構建服務之初，應合理規(guī)劃接入連接規(guī)模的階段，避免資源浪費和設計的不合理，例如：處理C10K架構和C100K的架構將截然不同。在協(xié)議選擇上可以劃分為多層，客戶端接入層選擇自定義協(xié)議或輕量級的協(xié)議，減少數(shù)據(jù)包體積，網(wǎng)關后幾層由于構建在內網(wǎng)或者一個數(shù)據(jù)中心中，應選擇一些擴展性強并且健壯的協(xié)議，如：XMPP等。協(xié)議加密方面可以設計成插件方式，選擇性支持二層、三層、四層加密、過濾等機制，也可使用簽名證書。當通訊服務構建完成需要進行2步核心測試，分別是單機0思考壓力測試及集群調度測試。
企業(yè)級即時“通訊服務”存在一個重要的特點，要求服務具備極高的穩(wěn)定性，保障消息的可靠不丟失，尤其在移動場景下，例如:2G切換3G又切換4G后到?jīng)]信號的極端場景下，消息始終不能丟失。這需要服務端在擁有極大并發(fā)的情況，保障通訊業(yè)務事務的健壯性，不管是通過消息回執(zhí)的方式，還是消息鎖機制保障，目的是一樣的。從數(shù)據(jù)層面考慮，也將面臨新的問題“數(shù)據(jù)持久化”，單純談數(shù)據(jù)持久化可能不是問題，但如果轉換成海量消息數(shù)據(jù)的場景，這又將是一個服務端設計的挑戰(zhàn)，消息與消息之間是存在多級關系的，例如：消息A屬于用戶B，消息A屬于群組B中用戶A發(fā)送給用戶B的圖片類型消息等。單純使用關系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫是很難解決這個問題，通常需要應用設計者自行設計一套數(shù)據(jù)散列算法進行消息對象分區(qū)，同時服務端還應實現(xiàn)一套查詢引擎或數(shù)據(jù)調度中心。數(shù)據(jù)存儲設計方面應遵循一個原則：“先規(guī)劃一期規(guī)模數(shù)據(jù)，同時設計升級方案”。當這些都搞定后，數(shù)據(jù)層面還應考慮提升數(shù)據(jù)服務的穩(wěn)定性和安全性，通常云平臺是無法實現(xiàn)這些需求，服務可以彈性，但數(shù)據(jù)無法彈性，這里就需要應用開發(fā)者根據(jù)穩(wěn)定性和安全級別設定數(shù)據(jù)庫容災及彈性方案。
資源存儲層面，建議單獨部署文件服務器(大、小文件服務器分開)、流媒體服務器。如果規(guī)模有限，可以采用開源文件服務器，如FastDFS、MogileFS、MooseFS，或租用第三方存儲服務資源。當即時通訊服務中以資源服務為核心時，應考慮自行構建分布式文件系統(tǒng)，通常采用集中式方式實現(xiàn)。
構建企業(yè)級“即時通訊”服務已不僅僅是滿足一些：單聊、群聊、語音、附件等基礎功能，而是要從客戶端及服務端兩個層面分開考慮，每一個層面?zhèn)戎攸c都不同。構建服務之初的規(guī)劃與設計非常重要，不同的階段化規(guī)模都將影響最終服務的架構。
