亚洲色拍少妇喷水,青青操视频网站

概念

融合通信是指，把計算機技術與傳統(tǒng)通信技術融合一體的新通信模式，融合計算機網(wǎng)絡與傳統(tǒng)通信網(wǎng)絡在一個網(wǎng)絡平臺上，實現(xiàn)電話、傳真、數(shù)據(jù)傳輸、音視頻會議、呼叫中心、即時通信等眾多應用服務。

業(yè)務平臺功能架構

核心開發(fā)框架模型

框架模型概念說明

核心基礎框架模型主要描述下述幾個概念及概念之間的關系，自下至上分別為：

■ OSGI：一個基于Java語言的服務（業(yè)務）規(guī)范，是一個面向Java的動態(tài)模型系統(tǒng)，為模塊化應用的開發(fā)定義了一個基礎框架。簡單的說，通過OSGI可以在后臺在線對應用系統(tǒng)組件進行安裝、升級或卸載，而無需打斷設備（服務器）的正常運行。

■ Infrastructure Framework：實現(xiàn)了與OSGI的高度解耦。從開發(fā)者層面來看，它完全屏蔽了OSGI層面的技術實現(xiàn)，即開發(fā)人員在不需要關注復雜的OSGI技術的情況下，仍可做高層設計。同時，“Infrastructure Framework”又具備OSGI的功能，如服務的管理、注冊等。另外，基于“Infrastructure Framework”之上的其他業(yè)務Bundle在開發(fā)過程中也不需要依賴OSGI依賴了，框架更加簡潔。

■ Host：一個JVM實例只啟動一個Host，映射到物理主機（或虛擬主機）；Host的子元素是Server。

■ Server：表示軟件維度上的一個子系統(tǒng)，主要負責定義主處理流程，不管具體業(yè)務功能的實現(xiàn)。一個Host上可以啟動1~N個Server；在最嚴格的分布式部署要求下，一個Host上只啟動一個Server。每個Server都有自己獨立的配置信息庫；Server運行時會根據(jù)配置文件信息主動申明自己需要裝配的Components，因此其運行時的子元素是Component。

■ Component：從職責分配的角度上來看，上面已經(jīng)講到Server主要負責定義主處理流程，那么在此，Component則負責流程中的具體（業(yè)務功能）實現(xiàn)。同一個Component可以為多個不同的Server服務。每個被裝載到Server中的Component實例，都擁有自己獨立的配置(來自Server的配置信息庫)，實現(xiàn)了同一Component在不同Server中的嚴格相互隔離。

■ Plugin：從意義上看，Plugin類似于OSGI的bundle概念，為系統(tǒng)的模塊化設計提供支撐。一個Plugin可以提供至多1個Server和至少0個Component的實現(xiàn)，可以理解為Plugin是裝盛Server實現(xiàn)和Component實現(xiàn)的容器。從設計角度來看，目前主要有以下幾種類型的Plugin：

(1) Server Plugin：提供Server功能實現(xiàn)的Plugin。

(2) Infrastructure Plugin：提供系統(tǒng)基礎功能的Plugin，如IM系統(tǒng)中的Connector、File、Cache等基礎功能的Plugin。

(3) Protocol Plugin：提供協(xié)議解析器（Parser）和協(xié)議處理類（Protocol Processor）的Plugin，如Message協(xié)議解析、Presence協(xié)議解析、Jingle協(xié)議解析等。

■ Repository：可以理解為Plugin管理器，管理著全部的Plugin，并讀取Plugin中的Components，然后依據(jù)Server中的配置信息，將單個的Component注入到對應的Server中。

特別說明：核心基礎框架模型中的Server不會與Repository中的Plugin直接打交道，而是通過靈活的配置信息，將合適的Component注入到對應的Server中。

■ MessageChannel：基于架構設計的一致性和對稱性，在Server與Server之間傳遞的信息，將被統(tǒng)一封裝到Message對象中。MessageChannel則是連接各個Server之間的通道，接收、傳遞和處理封裝好的Message對象。MessageChannel可以有多種不同的實現(xiàn)，以適應苛刻的通訊要求。

核心開發(fā)框架的插件機制

框架插件機制的說明：

核心框架采用了插件注入機制，即按需裝配插件。從核心框架的設計來看，Server是負責系統(tǒng)的主處理流程，本身不具備業(yè)務處理的功能。換言之，Server啟動后，Server中沒有內(nèi)容，但是它會發(fā)出通知，告訴框架它需要裝配哪些Component才能工作。

Repository，相當于一個Plugin管理器，其中包含了各種功能的Plugin，并統(tǒng)一管理這些Plugin；在系統(tǒng)運行時，它會掃描其包含的全部Plugin信息，并啟動這些Plugin。從設計角度來看，（開發(fā)時）我們又人為的把一個個大的功能拆分成若干個小的功能點，這就是Component了，以便于開發(fā)和維護。Plugin會監(jiān)聽其包含的Component的一系列動作，并廣播其能提供的Component服務。

在核心框架的作用下，Server拿到了其需要的Component實例，于是就將這些Component實例動態(tài)地裝配到Server中，Server也就能提供相應的服務了。當Plugin停止時，Server就相應地卸載掉已經(jīng)裝配了的Component，也就停止了相應的服務。整個過程都是動態(tài)發(fā)生了，只要相應的配置文件正確，不需要人工干預，核心框架會自動完成這些工作。

分布式實現(xiàn)框架

介紹分布式實現(xiàn)之前，有必要說明一下本系統(tǒng)的消息處理流程。系統(tǒng)收到一條消息后，對其的處理步驟是固定的，依次是：stream(接入)、parse(解析)、process(處理)、route(路由)，每個步驟都對應一個server：steamer、parser、processor、router。每個server有兩個固定組件：DataReceiver(數(shù)據(jù)接收器)、MessageChannel(數(shù)據(jù)發(fā)送通道)。每個server從DataReceiver中接收數(shù)據(jù)，處理完成后，通過其MessageChannel發(fā)送給下級server的DataReceiver。消息處理的流程如下圖所示：

本系統(tǒng)分布式實現(xiàn)的基本思想為：將負責消息處理不同階段的server部署到分布式的各個獨立節(jié)點上，每個獨立節(jié)點間使用高速通道互聯(lián)，且負責每個消息處理的節(jié)點會有多個。以此來提高系統(tǒng)對消息的并行處理能力。

系統(tǒng)中與分布式實現(xiàn)有關的bundle為：com.cmcc.olive.server.integration.distribution、

com.cmcc.olive.server.management。com.cmcc.olive.server.integration.distribution實現(xiàn)分布式版本的DataReceiver和MessageChannel。com.cmcc.olive.server.management實現(xiàn)了分布式節(jié)點的功能。

負責消息處理不同階段的server（如pipe.streamer、pipe.parser）可以根據(jù)不同的server配置加載不同版本的DataReceiver、MessageChannel。當對server配置了deployment.type=distributed 時，server將加載分布式版本的組件實現(xiàn)（包括DataReceiver、MessageChannel）；當對server配置了deployment.type=local或沒有設置deployment.type屬性時，server將加載本地版本的組件實現(xiàn)。

業(yè)務平臺邏輯架構

系統(tǒng)邏輯架構說明：

核心基礎框架從功能層面將整個系統(tǒng)劃分為三大功能塊，分別是Host功能塊、Server功能塊和Repository功能塊。Host功能塊上可以運行1~N個邏輯Server，在最嚴格的分布式部署要求下，一個Host上只運行一個Server，并且支持動態(tài)的啟停Server。Repository功能塊則包含若干個功能Plugin，Plugin由若干個Component組合而成，其中Component是主要的功能邏輯載體，以組件的形式對外提供服務。

業(yè)務平臺主處理流程

系統(tǒng)整體功能與交換流程說明：

整體功能與流程架構圖描述了系統(tǒng)整體的邏輯功能與流程控制，側重展現(xiàn)了各個模塊之間的劃分以及模塊間的交互關系。

從水平角度看（也可以理解為系統(tǒng)的運行視圖），Server定義了系統(tǒng)的主處理流程；從垂直角度看（也可以理解為開發(fā)視圖），Plugin定義了與功能或流程相關的插件。這樣從水平和垂直兩個不同的維度對系統(tǒng)進行定義和劃分，便于開發(fā)人員在開發(fā)時對系統(tǒng)功能和流程的理解，也便于開發(fā)時的維護。

那么，系統(tǒng)各模塊劃分、功能及關系說明如下：

Stream Server

請求連接服務器，接收用戶請求并與之協(xié)商加密策略、壓縮方式建立安全通信通道，可接受TCP、HTTP等各種連接請求。

Auth Server

認證服務器，連接的用戶與服務器協(xié)商加密機制，并通過Auth Server驗證，驗證通過后用戶Session信息保存在Connection Session服務器。后續(xù)的XML流將在此可靠通道下傳遞。

Parsing Server

XML解析服務器，業(yè)務通信過程中的XML數(shù)據(jù)流經(jīng)由Parsing Server解析，分為Presence、Message、IQ、Jingle等幾種類型，解析成Java能夠識別的業(yè)務對象，然后交給協(xié)議處理服務器處理。

Protocol Processing Server

XMPP核心業(yè)務處理模塊以及擴展服務模塊，最終的業(yè)務處理服務都在這里，還包括與外部服務器（例如流媒體服務器）的對接通信，包含的功能有：

Presence status：在線狀態(tài)，用戶在線狀態(tài)存取
Subscription：訂閱，好友在線狀態(tài)查找
Realtime message：實時消息
Offline message：離線消息
Register：用戶注冊
Roster：花名冊，用戶好友相關信息
Search：用戶搜索
MUC：群組、群組聊天相關
File Transfer：對文件傳輸?shù)闹С?/p>
Service Discovery：服務發(fā)現(xiàn)，基于OSGI服務注冊與查找相關支持
Persistent：數(shù)據(jù)持久化支持
Jingle：XMPP的擴展協(xié)議，通過Jingle可以實現(xiàn)點對點的多媒體控制
Jingle Audio via RTP：音頻支持
Jingle Video via RTP：視頻支持
Jingle ICE：Jingle交互式連接建立
Jingle STUN：Jingle地址映射相關支持
Message：消息
vCard：名片

Router Server

消息路由服務器，負責消息的路由查找及流轉。

Session Server

會話管理，管理用戶Session、網(wǎng)絡連接Session服務器Session。當用戶發(fā)起請求建立連接通道后，會將連接信息保存在Session Server，后續(xù)的XMPP通訊均基于該Session。XMPP核心及擴展服務模塊的會話也由該服務器管理。

Management Server

管理服務器，系統(tǒng)中的所有模塊都是基于OSGI組件化的服務，OSGI組件將注冊到組件管理服務器，業(yè)務模塊需要用到某個組件時從組件管理服務器查找，并負責全局的配置信息管理及相關的業(yè)務監(jiān)控。

Streaming Media Server

流媒體服務器，實時語音和視頻通話，處理VOIP相關。相對獨立的模塊，系統(tǒng)擴展協(xié)議Jingle與流媒體服務器交互。

Data Access Server

數(shù)據(jù)訪問，對系統(tǒng)業(yè)務的數(shù)據(jù)支撐，負責數(shù)據(jù)的持久化和訪問。支持關系數(shù)據(jù)庫和非關系型數(shù)據(jù)庫（NoSQL）兩種類型的數(shù)據(jù)庫的數(shù)據(jù)存取。

Cache Server

提供Key-Value型的高速緩存服務，支持任意對象的存儲。

File Server

統(tǒng)一的文件存儲接口，存儲用戶上傳的各式各樣的文件，并提供HTTP方式的文件訪問服務。

Gateway Server

外圍系統(tǒng)接入的統(tǒng)一入口，方便外圍系統(tǒng)與本多維通訊系統(tǒng)進行數(shù)據(jù)交互。

VOIP子系統(tǒng)架構(整體)

融合通信系統(tǒng)要求支持實時的語音、視頻通話（即VOIP），對此，我們提出兩種架構解決方案以實現(xiàn)對VOIP功能的支持，分別是“通過流媒體服務器中轉”和“點對點”這兩種架構方案。

通過流媒體服務器中轉

通過流媒體服務器中轉的VOIP方案的流程如下：

(1) 主叫方發(fā)起通話請求：手機客戶端1（以下稱“主叫方”）準備發(fā)起與手機客戶端2（以下稱“被叫方”）之間的VOIP通話請求；

(2) XMPP處理請求：實時通訊服務器收到主叫方的VOIP通話請求，查詢被叫方是否滿足進行實時VOIP通話的要求（至少要求在線）。被叫方不在線，返回結果給主叫方，可以結束本次通話請求了；被叫方在線，則進入下一步流程處理。

(3) 被叫方響應通話請求：實時通訊服務器將主叫方的通話請求推送到被叫方，被叫方手機響鈴。被叫方在一段時間內(nèi)未作任何操作或直接掛接本次通話請求，則服務器通知主叫方可以結束本次通話請求了；被叫方接受主叫方的通話請求，則進入下一步流程處理。

(4)XMPP+Jingle協(xié)商VOIP會話的建立：

與主叫方的協(xié)商（RTP協(xié)議）：通知主叫方可以開始錄制語音或視頻了，并采用指定的編碼格式對實時錄制的音頻或視頻進行編碼，然后將編碼后的數(shù)據(jù)發(fā)送到流媒體服務器的指定端口A上。
與被叫方的協(xié)商（RTP協(xié)議）：通知被叫方可以去流媒體服務器的指定端口B上取回數(shù)據(jù)，并采用指定的編碼格式對實時取回的數(shù)據(jù)進行解碼。

當然，對媒體的編解碼工作可以交由流媒體服務器來做，但這樣對移動客戶端來說，可能比較耗流量。

(5) 主叫方建立VOIP會話：開始錄制音頻或視頻，并按照規(guī)定上傳到流媒體服務器上。

(6) 被叫方建立VOIP會話：按照規(guī)定從流媒體服務器上下載數(shù)據(jù)，在本地播放音頻或視頻。

(7)VOIP通話過程控制：在主叫方和被叫方進行VOIP通話的期間，實時通訊服務器仍不斷地與主叫方和被叫方進行數(shù)據(jù)的交換，如權限的控制、如何計費等，直到本次VOIP通話完全結束。

點對點

數(shù)據(jù)存取架構

數(shù)據(jù)庫模型采用關系型數(shù)據(jù)庫+NoSQL，頻繁訪問的數(shù)據(jù)采用NoSQL數(shù)據(jù)庫進行數(shù)據(jù)快速存取，重要數(shù)據(jù)、非頻繁訪問數(shù)據(jù)采用關系型數(shù)據(jù)庫存儲。

數(shù)據(jù)緩存架構

緩存技術，根據(jù)系統(tǒng)需要頻繁訪問的數(shù)據(jù)采用緩存提高訪問速度，可支持對象級的緩存，如任意的Java Object、圖片等類型的數(shù)據(jù)。共享緩存也提供各服務器節(jié)點之間的數(shù)據(jù)共享。

網(wǎng)絡拓撲架構

網(wǎng)絡拓撲架構說明：

外層是互聯(lián)網(wǎng)，終端設備、第三方系統(tǒng)、其他外部網(wǎng)關通過GPRS/3G/4G等網(wǎng)絡與本系統(tǒng)通訊
互聯(lián)網(wǎng)和內(nèi)部網(wǎng)絡之間設主備兩套防火墻，防火墻內(nèi)架設主備兩套三層/四層交換機
內(nèi)網(wǎng)架設F5負載，各服務器節(jié)點與F5設備相連

系統(tǒng)邊界