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