一种基于NGOD架构的云应用服务管理方案

2014-09-18赵晓森王志谦

电视技术 2014年17期

赵晓森，徐扬，王志谦

（北京邮电大学网络技术研究院信息网络中心，北京 100876）

随着社会的发展、生活水平的提高，人们对于精神文化的需求快速增长。同时由于PC和手机、平板PC等智能终端的迅猛发展，人们可以接触到的信息和应用服务越来越丰富，用户更多地向互联网方向靠拢。国家新闻出版广电总局发布的中国视听新媒体发展报告（2013）显示，2013年北京地区电视机开机率从三年前的70%下降至30%。如何通过技术的改进创新，为用户提供更多的应用、内容，重新获得用户的关注，成为广电运营商亟待解决的问题。为此，本文提出了一种基于NGOD架构的云应用服务管理方案，该方案对现有的NGOD架构的标准进行了扩展，并采用应用虚拟化技术，使之适应云端应用的部署运行。

1 云应用服务管理方案

随着国内三网融合与广电网双向改造的不断推进，国内越来越多的家庭拥有具有双向交互能力的数字电视机顶盒。但是由于国内广电运营状况比较复杂、地区之间差距大，家庭用户机顶盒终端平台多种多样，而且普遍配置低、运算能力差。如果基于终端为用户提供应用服务，需要对国内机顶盒进行整体升级，这样耗时太长、投入太大，无法让人接受。

一些公司提出了一种新的解决方案，通过在广电网上搭建云平台，为用户提供云应用服务，突破终端造成的瓶颈[1-2]。然而，由于商业原因，这些公司都没有公开技术细节。在此基础上，本文提出了一种基于NGOD架构的云应用服务管理方案。

下一代交互电视架构（Next Generation On Demand，NGOD）是由美国Comcast公司提出的一种新的交互式的开放的服务网络框架结构。该架构合理细致地划分出了各个逻辑功能组件，全面详尽地规定了各组件间的协议交互和通信接口。NGOD架构支持各个厂商产品之间的相互操作，有高度的可扩展性，能支持未来的多种业务功能[3]。目前，业内开始逐步地转向使用NGOD架构进行开发和部署广电网内的视频点播系统。

该应用管理方案在广电网的服务端基于NGOD架构配置应用服务器，用户点播的应用在应用服务器上运行。用户通过终端（也就是用户机顶盒）选择了应用，云端采用应用虚拟化技术将应用部署到应用服务器上，应用程序的处理、显示图像的渲染等在服务器上完成，运行结果以音视频流的方式通过网络传送到终端，终端完成音视频的解码并将结果呈现。终端同时可以进行操作，用户的操作指令通过网络传送到云端应用服务器上运行的应用，应用处理后再次将响应结果以音视频的形式传输到终端。这样将终端的运算能力剥离到云端，终端只需要具备基本的网络接入、视频解码和交互处理能力。

该方案最大限度地屏蔽了各类型电视机顶盒终端的差异，有利于运营商开展新的增值业务，避免了大规模升级用户机顶盒，节约了时间，减少了投入；同时实现了对用户的统一管理，对内容的可管可控，有利于维护信息安全；由于终端接收到的是应用运行结果的音视频流，用户无法对应用程序进行篡改和复制，有利于维护系统安全、保障应用开发者的知识产权。

2 扩展NGOD架构

2.1 总体架构

现有NGOD架构标准并没有考虑到广电网上应用的部署，故笔者提出对NGOD架构进行扩展，在不影响现有系统功能的基础上使之适用于广电网上的云应用。为此，新增加应用服务器管理器（Application Server Manag⁃er，ASM）和应用服务器（Application Server，AS）两个模块。图1为对NGOD架构进行扩展后的部分架构图。原有的接口无法在功能上满足新增的两个模块，需要进行接口扩展，增加新的接口。现有NGOD架构标准定义了S1～S6会话管理接口，在此基础上新增了S7接口。现有标准定义了R1～R7资源管理接口，在此基础上新增了R8接口。现有标准定义了D1～D7发现接口，在此基础上新增了D8接口。C2接口为新增加的点播客户端与应用服务器的控制接口。本文主要介绍新增加的应用服务器和应用服务器管理器两个模块即相应新增接口，原有架构信息不再赘述。

2.2 应用服务器管理器及主要接口

2.2.1 应用服务器管理器（ASM）

应用服务器管理器（Application Server Manager，ASM）的功能包括资源管理功能和设备发现功能。由于NGOD架构选择了中心和分支模式以及乐观的资源分配策略作为强制的结构，故本文只介绍中心与分支模式下的乐观资源分配策略。

2.2.2 S7接口及业务处理流程

ASM与SM（Session Manager，会话管理器）之间定义了S7接口，负责在应用服务器上对会话请求所需的服务器资源进行商议，该接口基于RTSP协议，术语、消息语法、方法定义和状态码依据于RFC 2326和NGOD官方对RTSP协议做的扩展[4]。主要包括SETUP，TEARDOWN，ANNOUNCE等消息信令。图2为乐观分配策略下消息交互流程。

图2 乐观分配策略消息交互流程

ODC（On Demand Client，点播客户端）通过S1接口向SM发出应用服务请求后，SM首先通过S6接口向ERM（Edge Resource Manager，边缘资源管理器）发送SETUP会话建立请求，选择ED（Edge Device，边缘设备）。ERM向SM返回SETUP RESPONSE消息，包括ED的IP、端口等信息。然后SM通过S3接口向ODRM（On Demand Re⁃source Manager，点播资源管理器）发送包括ED的IP、端口等信息的SETUP会话建立请求，选择SS（Streaming Server，推流服务器）[5]。之后，SM作为RTSP客户端通过S7接口向ASM发出服务器资源请求SETUP。在SETUP报文中，除了点播客户端的信息、用户请求的应用信息外，还包括ODRM返回的SS的信息，以便于建立会话的下行通路。ASM在选定AS（Application Server，应用服务器）部署应用之后，返回SETUP RESPONSE消息，包括选定的AS的IP和部署的应用的进程号，SM将其转发给点播客户端，用来建立点播客户端到AS的上行通路。

用户结束使用云应用服务后，点播客户端向SM发送撤销会话的请求，或者SM与点播客户端之间的心跳检测超时的情况下，SM向ASM发送TEARDOWN消息，请求释放该会话占用的应用服务器资源。ASM在释放服务器资源后，向SM发送TEARDOWN RESPONSE消息。

在一些异常情况下，例如ASM检测到AS的异常，ASM会主动向已经建立会话的SM发送一些非请求消息（消息中包含发生的事件以及发生的时间等信息），这些消息一般通过RTSP ANNOUNCE Request和Response消息来实现。

2.2.3 R8接口及业务处理流程

ASM与AS之间定义了R8接口，ASM通过使用该接口，依据选定的负载均衡策略来管理应用服务器的资源。R8接口也是基于RTSP协议的，包括SETUP，TEAR⁃DOWN，ANNOUNCE，GET_PARAMETER，PING等信令。

当SM向ASM发出SETUP会话建立请求后，ASM结合点播客户端的请求与各应用服务器的状态，依据负载均衡策略，选定应用服务器来部署应用，并通过R8接口向选定的AS发送SETUP报文，包括客户端请求的应用的信息。AS加载部署应用后，向ASM发送SETUP RE⁃SPONSE报文，包括IP、所部署应用的进程号。

ASM收到SM发送的TEARDOWN报文后，进行一些内部处理，例如更新AS信息表，然后向AS发送TEAR⁃DOWN报文告知结束会话。AS结束会话后返回TEAR⁃DOWN RESPONSE报文。

在会话过程中发生异常时，AS可以通过发送AN⁃NOUNCE报文向ASM反映异常。ASM可以通过GET_PARAMETER Request和Response来获取和AS会话的参数消息。ASM通过周期性地向AS发送PING报文来维护会话的生命周期。在NGOD RTSP Usage Specifi⁃cation中，默认的会话超时时间被设为3 h。

2.2.4 D8接口及业务处理流程

ASM和AS之间定义了服务发现与注册接口D8。AS通过该接口向ASM注册并提供可用资源的详细目录。D2～D6接口实现了VREP协议，该协议是NGOD在TRIP（RFC 3219）的基础上扩展而来的协议，为了便于与原系统兼容，D8接口采用VREP协议。

VREP协议包括4种消息类型：OPEN，UPDATE，NO⁃TIFICATION，KEEPALIVE。OPEN消息主要用于VREP传输会话的建立；UPDATE消息主要用于资源设备向其资源管理器上报自身配置参数；NOTIFICATION消息主要用于错误的报告；KEEPALIVE消息用来恢复和维持心跳[6]。

图3所示为D8接口消息交互流程。

图3 D8接口VREP协议消息交互

AS接入系统后主动向相应的ASM发起连接请求，传输层连接建立后，两者首先通过OPEN消息协商参数信息，包括VREP协议版本、超时时间、VREP会话标识、支持的路由类型以及组件的收发能力等信息。OPEN消息被接收之后，向对方发送KEEPALIVE消息确认。

在通过OPEN消息对组件的收发能力协商后，AS只具备发送UPDATE消息的能力，ASM的D8接口只具备接收UPDATE消息的能力。AS通过向ASM发送UPDATE消息，报告服务器资源详细信息，包括CPU信息和内存信息。ASM发送KEEPALIVE消息对其进行确认。

当AS和ASM在收发消息的过程中发现消息有误时，任何一方都会利用NOTIFACATION消息报告错误并断开连接。

2.2.5 扩展RTSP协议

NGOD架构对RTSP协议做了扩展[4]，在此基础上，本文对RTSP协议又进行了一些扩展，新定义了一些字段，包括：Application_Id，标示应用；Application_Type，标示应用的类型；AS_IP，应用服务器的IP地址；AS_PID，应用服务的进程号；AS_PORT_UP，应用服务器的端口，用于建立上行通路；AS_PORT_DOWN，应用服务器的端口，用于输出流化后的音视频到SS。会话消息类型太多，本文不一一叙述。下面是一个SM发送到ASM的SETUP的消息示例：

其中，destination指SS的IP地址或主机名，client-port指SS的输入端口。如下是ASM发送的SETUP Response消息示例：

2.3 应用服务器及会话通路

2.3.1 虚拟化

对云端资源虚拟化，主要有3种技术方式：服务器虚拟化、桌面虚拟化和应用虚拟化。

服务器虚拟化是将服务器物理资源抽象成逻辑资源，将CPU、内存、磁盘、I/O等硬件变成可以动态管理的“资源池”，一台服务器变成几台甚至上千台服务器。将服务器硬件资源按需分配给每台虚拟机，虚拟机上再安装操作系统和用户所需的应用程序。采用服务器虚拟化方式，可以为每个用户分配一台虚拟机，这样便于资源管理和用户数据的管理，并且用户与用户之间有很好的隔离性。但是因为其实现方式是在系统里安装虚拟化软件，再在虚拟机上安装操作系统，所以就会产生原生系统和虚拟化软件两层消耗。即使以Hyper-V为代表的虚拟化技术实现了跨过原生系统，直接在硬件上安装虚拟化软件，但虚拟机上运行操作系统本身就是很大的消耗。随着用户的增多，需要配置越来越多的虚拟机，这会带来一个无法忽略的成本。另外，由于需要对每台虚拟机进行维护、安全检测，对系统管理员来说，工作量太大，并且可能因为无法及时对虚拟机进行维护检测带来很大风险。

桌面虚拟化指将计算机的桌面进行虚拟化，以达到桌面使用的安全性和灵活性。桌面虚拟化依赖于服务器虚拟化，与服务器虚拟化有着类似的优缺点。

应用虚拟化指将应用程序与操作系统解耦合，为应用程序提供一个虚拟的运行环境。在这个环境中，不仅包括应用程序的可执行文件，还包括它所需要的运行时环境。从本质上说，应用虚拟化是把应用对底层的系统和硬件的依赖抽象出来。每个通过应用虚拟化技术封装的应用程序，在相互独立的虚拟化环境中运行，这样可以减少不同应用程序之间出现的冲突，提高应用程序的兼容性，同时可以实现在同一台计算机上运行同一种应用程序的不同版本，具有很大的灵活性。应用虚拟化简化了应用安装过程，提高了应用部署的速度。采用应用虚拟化技术，系统管理员可以直接在服务器上对系统进行维护检测，减少了工作量，降低了风险[7]。

综上考虑，本文推荐采用应用虚拟化技术在应用服务器上部署应用。

2.3.2 会话通路

在原有的NGOD架构中，用户请求视频点播服务时，会话的上行通路是点播客户端到推流服务器，会话的下行通路是媒体资源注入到推流服务器，推流服务器将其推流到边缘设备，再传输到点播客户端呈现。

对NGOD架构进行扩展后，用户请求云应用服务时，会话的上行通路是点播客户端到应用服务器，在该通路上传输用户的操作指令。应用服务器将应用流化后传输到推流服务器，推流服务器再将其传输到边缘设备，然后传输到点播客户端呈现，从而构成了会话的下行通路。