IT实战经验

融合通信技术实战案例，自媒体平台也有一定的参考价值

2017-12-22  本文已影响5人  威客方案

概念

融合通信是指，把计算机技术与传统通信技术融合一体的新通信模式，融合计算机网络与传统通信网络在一个网络平台上，实现电话、传真、数据传输、音视频会议、呼叫中心、即时通信等众多应用服务。

业务平台功能架构


核心开发框架模型

框架模型概念说明

核心基础框架模型主要描述下述几个概念及概念之间的关系，自下至上分别为：

■ OSGI：一个基于Java语言的服务（业务）规范，是一个面向Java的动态模型系统，为模块化应用的开发定义了一个基础框架。简单的说，通过OSGI可以在后台在线对应用系统组件进行安装、升级或卸载，而无需打断设备（服务器）的正常运行。

■ Infrastructure Framework：实现了与OSGI的高度解耦。从开发者层面来看，它完全屏蔽了OSGI层面的技术实现，即开发人员在不需要关注复杂的OSGI技术的情况下，仍可做高层设计。同时，“Infrastructure Framework”又具备OSGI的功能，如服务的管理、注册等。另外，基于“Infrastructure Framework”之上的其他业务Bundle在开发过程中也不需要依赖OSGI依赖了，框架更加简洁。

■ Host：一个JVM实例只启动一个Host，映射到物理主机（或虚拟主机）；Host的子元素是Server。

■ Server：表示软件维度上的一个子系统，主要负责定义主处理流程，不管具体业务功能的实现。一个Host上可以启动1~N个Server；在最严格的分布式部署要求下，一个Host上只启动一个Server。每个Server都有自己独立的配置信息库；Server运行时会根据配置文件信息主动申明自己需要装配的Components，因此其运行时的子元素是Component。

■ Component：从职责分配的角度上来看，上面已经讲到Server主要负责定义主处理流程，那么在此，Component则负责流程中的具体（业务功能）实现。同一个Component可以为多个不同的Server服务。每个被装载到Server中的Component实例，都拥有自己独立的配置(来自Server的配置信息库)，实现了同一Component在不同Server中的严格相互隔离。

■ Plugin：从意义上看，Plugin类似于OSGI的bundle概念，为系统的模块化设计提供支撑。一个Plugin可以提供至多1个Server和至少0个Component的实现，可以理解为Plugin是装盛Server实现和Component实现的容器。从设计角度来看，目前主要有以下几种类型的Plugin：

(1) Server Plugin：提供Server功能实现的Plugin。

(2) Infrastructure Plugin：提供系统基础功能的Plugin，如IM系统中的Connector、File、Cache等基础功能的Plugin。

(3) Protocol Plugin：提供协议解析器（Parser）和协议处理类（Protocol Processor）的Plugin，如Message协议解析、Presence协议解析、Jingle协议解析等。

■ Repository：可以理解为Plugin管理器，管理着全部的Plugin，并读取Plugin中的Components，然后依据Server中的配置信息，将单个的Component注入到对应的Server中。

特别说明：核心基础框架模型中的Server不会与Repository中的Plugin直接打交道，而是通过灵活的配置信息，将合适的Component注入到对应的Server中。

■ MessageChannel：基于架构设计的一致性和对称性，在Server与Server之间传递的信息，将被统一封装到Message对象中。MessageChannel则是连接各个Server之间的通道，接收、传递和处理封装好的Message对象。MessageChannel可以有多种不同的实现，以适应苛刻的通讯要求。

核心开发框架的插件机制

框架插件机制的说明：

核心框架采用了插件注入机制，即按需装配插件。从核心框架的设计来看，Server是负责系统的主处理流程，本身不具备业务处理的功能。换言之，Server启动后，Server中没有内容，但是它会发出通知，告诉框架它需要装配哪些Component才能工作。

Repository，相当于一个Plugin管理器，其中包含了各种功能的Plugin，并统一管理这些Plugin；在系统运行时，它会扫描其包含的全部Plugin信息，并启动这些Plugin。从设计角度来看，（开发时）我们又人为的把一个个大的功能拆分成若干个小的功能点，这就是Component了，以便于开发和维护。Plugin会监听其包含的Component的一系列动作，并广播其能提供的Component服务。

在核心框架的作用下，Server拿到了其需要的Component实例，于是就将这些Component实例动态地装配到Server中，Server也就能提供相应的服务了。当Plugin停止时，Server就相应地卸载掉已经装配了的Component，也就停止了相应的服务。整个过程都是动态发生了，只要相应的配置文件正确，不需要人工干预，核心框架会自动完成这些工作。

分布式实现框架

介绍分布式实现之前，有必要说明一下本系统的消息处理流程。系统收到一条消息后，对其的处理步骤是固定的，依次是：stream(接入)、parse(解析)、process(处理)、route(路由)，每个步骤都对应一个server：steamer、parser、processor、router。每个server有两个固定组件：DataReceiver(数据接收器)、MessageChannel(数据发送通道)。每个server从DataReceiver中接收数据，处理完成后，通过其MessageChannel发送给下级server的DataReceiver。消息处理的流程如下图所示：

本系统分布式实现的基本思想为：将负责消息处理不同阶段的server部署到分布式的各个独立节点上，每个独立节点间使用高速通道互联，且负责每个消息处理的节点会有多个。以此来提高系统对消息的并行处理能力。

系统中与分布式实现有关的bundle为：com.cmcc.olive.server.integration.distribution、

com.cmcc.olive.server.management。com.cmcc.olive.server.integration.distribution实现分布式版本的DataReceiver和MessageChannel。com.cmcc.olive.server.management实现了分布式节点的功能。

负责消息处理不同阶段的server（如pipe.streamer、pipe.parser）可以根据不同的server配置加载不同版本的DataReceiver、MessageChannel。当对server配置了deployment.type=distributed 时，server将加载分布式版本的组件实现（包括DataReceiver、MessageChannel）；当对server配置了deployment.type=local或没有设置deployment.type属性时，server将加载本地版本的组件实现。

业务平台逻辑架构

系统逻辑架构说明：

核心基础框架从功能层面将整个系统划分为三大功能块，分别是Host功能块、Server功能块和Repository功能块。Host功能块上可以运行1~N个逻辑Server，在最严格的分布式部署要求下，一个Host上只运行一个Server，并且支持动态的启停Server。Repository功能块则包含若干个功能Plugin，Plugin由若干个Component组合而成，其中Component是主要的功能逻辑载体，以组件的形式对外提供服务。

业务平台主处理流程

系统整体功能与交换流程说明：

整体功能与流程架构图描述了系统整体的逻辑功能与流程控制，侧重展现了各个模块之间的划分以及模块间的交互关系。

从水平角度看（也可以理解为系统的运行视图），Server定义了系统的主处理流程；从垂直角度看（也可以理解为开发视图），Plugin定义了与功能或流程相关的插件。这样从水平和垂直两个不同的维度对系统进行定义和划分，便于开发人员在开发时对系统功能和流程的理解，也便于开发时的维护。

那么，系统各模块划分、功能及关系说明如下：

请求连接服务器，接收用户请求并与之协商加密策略、压缩方式建立安全通信通道，可接受TCP、HTTP等各种连接请求。

认证服务器，连接的用户与服务器协商加密机制，并通过Auth Server验证，验证通过后用户Session信息保存在Connection Session服务器。后续的XML流将在此可靠通道下传递。

XML解析服务器，业务通信过程中的XML数据流经由Parsing Server解析，分为Presence、Message、IQ、Jingle等几种类型，解析成Java能够识别的业务对象，然后交给协议处理服务器处理。

XMPP核心业务处理模块以及扩展服务模块，最终的业务处理服务都在这里，还包括与外部服务器（例如流媒体服务器）的对接通信，包含的功能有：

消息路由服务器，负责消息的路由查找及流转。

会话管理，管理用户Session、网络连接Session服务器Session。当用户发起请求建立连接通道后，会将连接信息保存在Session Server，后续的XMPP通讯均基于该Session。XMPP核心及扩展服务模块的会话也由该服务器管理。

管理服务器，系统中的所有模块都是基于OSGI组件化的服务，OSGI组件将注册到组件管理服务器，业务模块需要用到某个组件时从组件管理服务器查找，并负责全局的配置信息管理及相关的业务监控。

流媒体服务器，实时语音和视频通话，处理VOIP相关。相对独立的模块，系统扩展协议Jingle与流媒体服务器交互。

数据访问，对系统业务的数据支撑，负责数据的持久化和访问。支持关系数据库和非关系型数据库（NoSQL）两种类型的数据库的数据存取。

提供Key-Value型的高速缓存服务，支持任意对象的存储。

统一的文件存储接口，存储用户上传的各式各样的文件，并提供HTTP方式的文件访问服务。

外围系统接入的统一入口，方便外围系统与本多维通讯系统进行数据交互。

VOIP子系统架构(整体)

融合通信系统要求支持实时的语音、视频通话（即VOIP），对此，我们提出两种架构解决方案以实现对VOIP功能的支持，分别是“通过流媒体服务器中转”和“点对点”这两种架构方案。

通过流媒体服务器中转

通过流媒体服务器中转的VOIP方案的流程如下：

(1) 主叫方发起通话请求：手机客户端1（以下称“主叫方”）准备发起与手机客户端2（以下称“被叫方”）之间的VOIP通话请求；

(2) XMPP处理请求：实时通讯服务器收到主叫方的VOIP通话请求，查询被叫方是否满足进行实时VOIP通话的要求（至少要求在线）。被叫方不在线，返回结果给主叫方，可以结束本次通话请求了；被叫方在线，则进入下一步流程处理。

(3) 被叫方响应通话请求：实时通讯服务器将主叫方的通话请求推送到被叫方，被叫方手机响铃。被叫方在一段时间内未作任何操作或直接挂接本次通话请求，则服务器通知主叫方可以结束本次通话请求了；被叫方接受主叫方的通话请求，则进入下一步流程处理。

(4)XMPP+Jingle协商VOIP会话的建立：

当然，对媒体的编解码工作可以交由流媒体服务器来做，但这样对移动客户端来说，可能比较耗流量。

(5) 主叫方建立VOIP会话：开始录制音频或视频，并按照规定上传到流媒体服务器上。

(6) 被叫方建立VOIP会话：按照规定从流媒体服务器上下载数据，在本地播放音频或视频。

(7)VOIP通话过程控制：在主叫方和被叫方进行VOIP通话的期间，实时通讯服务器仍不断地与主叫方和被叫方进行数据的交换，如权限的控制、如何计费等，直到本次VOIP通话完全结束。

点对点

数据存取架构

数据库模型采用关系型数据库+NoSQL，频繁访问的数据采用NoSQL数据库进行数据快速存取，重要数据、非频繁访问数据采用关系型数据库存储。

数据缓存架构

缓存技术，根据系统需要频繁访问的数据采用缓存提高访问速度，可支持对象级的缓存，如任意的Java Object、图片等类型的数据。共享缓存也提供各服务器节点之间的数据共享。

网络拓扑架构

网络拓扑架构说明：

系统边界

服务端关键流程

异步聊天流程

异步聊天流程：

实时通话流程

实时通话流程：

语音信箱流程

语音信箱流程：

匹配朋友到朋友列表流程

匹配朋友到朋友列表流程：

推送朋友到朋友列表流程

推送朋友到朋友列表流程：

查找新朋友流程

查找新朋友流程：

推送新朋友流程

推送新朋友流程：

邀请朋友流程

邀请朋友流程：

个性卡片流程

查看个性卡片流程：

创建圈子流程

创建圈子流程：

发布动态流程

发布动态流程：

圈友会话流程

圈友会话流程：

多人通话流程

实时通话流程：

动态互动流程

动态互动流程：

圈子管理流程

圈子管理流程：

交换号码流程

交换号码流程：

退出圈子流程

退出圈子流程：

我的动态发布流程

我的动态发布流程：

我的私密发布流程

我的私密发布流程：

我的相册查看流程

我的相册查看流程：

上一篇下一篇

猜你喜欢

热点阅读