语音加速系统总体设计.docx
《语音加速系统总体设计.docx》由会员分享，可在线阅读，更多相关《语音加速系统总体设计.docx（29页珍藏版）》请在冰豆网上搜索。
语音加速系统总体设计
语音加速系统
版本：
V1.0.1
——总体设计
目录
语音加速系统1
1引言1
1.1编写目的1
1.2背景1
1.3定义1
1.4参考资料1
1.5修改历史1
2总体方案介绍2
2.1加速服务器的布置2
2.2加速服务器的选择2
3加速方案调研2
3.1socks5透明代理方案2
3.1.1拓扑图3
3.1.2方案介绍3
3.1.3类似解决方案3
3.2不透明的应用代理方案3
3.2.1拓扑图4
3.2.2方案介绍4
3.3类似CDN的内容缓存方案4
3.3.1拓扑图5
3.3.2序列图6
3.3.3方案介绍6
3.4优缺点比较6
4语音加速系统总体架构7
4.1ACSforFlash部署设计方案7
4.1.1方案概述7
4.1.2侦听FlashTCP连接响应机制（供参考）8
4.1.3侦听FlashRTMP握手协议响应机制（采用）8
4.1.4基于DNS智能解析技术的ACS分配用户网络识别方案8
4.1.5ACS切换调度方案9
4.1.6ACS分配策略9
4.2ACSforRTP部署设计方案10
4.2.1RTP语音（socks5）封包传输机制10
4.3服务器逻辑拓扑图10
4.3.1总体逻辑图10
4.3.2加速频道服务器11
4.4客户端语音加速机制11
4.4.1Flash客户端加速11
4.4.2Phone+（RTP）客户端加速11
5架构元素12
5.1服务器云端12
5.1应用程序客户端12
6元素功能及接口12
6.1语音客户端（Flash/Phone+）12
6.2加速频道服务器（ACS）12
6.2.1接口设计12
6.2.2扩展方式12
6.2.3与其他服务器的连接13
6.3加速管理服务器（AMS）13
6.3.1接口设计13
6.3.2扩展方式13
6.3.3与其他服务器的连接13
6.4加速系统应用程序中间件（AAM）13
6.4.1接口设计13
6.4.2扩展方式14
6.4.3与其他服务器的连接14
7重点用例概述14
7.1服务器存活管理14
7.2ACS资源分配过程14
7.3ACS加速传输控制过程15
7.3.1Flash（RTMP）管理机制15
7.3.2Phone+（RTP）管理过程16
8运行设计16
8.1服务启动顺序及配置16
8.1.1加速管理服务器（AMS）16
8.1.2加速频道服务器（ACS）17
8.1.3加速系统应用程序中间件（AAM）17
8.2运行控制17
8.2.1AMS17
8.2.2ACS17
8.2.3AAM17
8.3运行环境17
9系统数据结构设计18
9.1逻辑结构设计要点18
9.1.1AMS主要内存数据结构18
9.1.1ACS主要内存数据结构18
9.2物理结构设计要点18
9.3数据结构与程序的关系18
10系统出错处理设计19
10.1出错信息19
10.2补救措施19
10.3系统维护设计19
1引言
1.1编写目的
指导语音加速系统详细设计和代码编写，并为单元和集成测试提供参考标准和目标依据。
1.2背景
由于中国的网络状况原因，在电信、联通、移动之间的网络互通上面，网络质量不能得到保证，特别是涉及到语音或者视频等服务时。
网项目和Phone+项目，需要为全国的不同网络接入的用户，提供保证品质的语音服务，需要考虑的本实施方案，需要兼顾碰我网项目和Phone+项目不同的特点，能提供透明的语音加速服务。
1.3定义
本文档中用到的术语的定义和英文名称定义：
中文名称
英文名称
英文简称
说明
加速管理服务器
AccelerateManagementServer
AMS
负责ACS所有服务器管理，资源分配等工作
加速频道服务器
AccelerateChannelServer
ACS
负责频道语音加速工作，接受AMS管理
加速系统应用程序中间件
AccelerateApplicationMiddleware
AAM
嵌入应用程序的插件，应用程序通过该中间件访问语音加速系统控制服务器，用于获得加速频道服务器资源信息
网房间服务器（语音服务器）
LangmaRoomServer（Peng58RoomServer）
PRS
网项目提供TCP/RTMP协议接入服务的语音服务器
Phone+频道服务器（语音服务器）
Phone+ChannelServer
PCS
Phone+项目提供UDP/RTP协议接入服务的语音服务器
1.4参考资料
本文档的有关参考文件：
a.文档编制标准：
中华人民共和国国家标准UDC681.3--计算机软件产品开发文件编制指南GB8567-88。
1.5修改历史
2总体方案介绍
2.1加速服务器的布置
加速服务器的布置需要符合以下几点要求：
1）在不同的网络的骨干节点上予以布置：
电信；联通；移动
2）在不同的网络的骨干节点以大区城市上进行不断扩展：
华东；华北；华南
3）在每一个骨干节点上要以群组可平滑扩展的方式存在
2.2加速服务器的选择
1）首先需要判断客户端和语音服务器之间的网络状况，条件好的情况下可以直接连接语音服务器，只有在条件比较差的情况下才去连接加速服务器。
2）加速服务器分配管理，中心服务器需要根据客户端的IP地址和接入网络，为客户端指定可以最优提供加速服务的服务器域名。
3）加速服务器组以负载均衡的方式为需要提供服务的客户端进行加速服务。
4）需要考虑是否有不同用户对于同一份媒体流的并发式需求，这样可以节省带宽。
3加速方案调研
3.1socks5透明代理方案
3.1.1拓扑图
3.1.2方案介绍
利用标准的socks5协议实现包括用户连接和语音数据的全部透明代理方案。
客户端只要检测到和语音服务器之间网络状况不好，就通过socks5代理来和语音服务器进行连接，语音数据全部通过socks5代理进行透明转发。
3.1.3类似解决方案
二七代理：
GameCap采用的关键技术：
MaxHook技术：
截获和分析网络游戏数据包，并且交给加速服务器（与您距离较近的节点服务器）转发，从而使数据包更快地到达游戏服务器；
PreRouting技术：
通过专用高速通道，从游戏服务器接收网络数据，转发给玩家的电脑，完成加速过程；
UltimatePing技术：
通过优化数据传输显著降低Ping值；
GameFirst技术：
优先处理和传输网络游戏数据包
3.2不透明的应用代理方案
3.2.1拓扑图
3.2.2方案介绍
不利用标准的socks5代理，通过应用层的协议，如果客户端和语音服务器网络质量较差的情况下，由客户端直接通过加速服务器连接语音服务器，加速服务器为每一个需要提供加速服务的用户建立一条唯一的和语音服务器之间的连接。
3.3类似CDN的内容缓存方案
3.3.1拓扑图
3.3.2序列图
3.3.3方案介绍
以内容为加速的索引，这样，每一组加速服务器是以流媒体内容作为连接的索引支撑
当用户连接加速服务器后，根据用户所需要的内容，来查询加速服务器上是否存在，如果存在的话，直接加入内容分发即可，如果不存在，在加速服务器和内容服务器之间建立新的语音隧道连接后再给客户端提供语音加速服务。
加速服务器为每个语音服务内容和语音服务器建立连接，而不是为每一个用户和语音服务器建立连接。
3.4优缺点比较
方案名称
优点
缺点
Socks5透明代理加速方案
开放性非常好，不仅能够提供语音加速，以后可以扩展到其他方面
为每个用户提供连接，需要的服务器和带宽较多
应用层不透明代理加速方案
开发难度较低
为每个用户提供连接，需要的服务器和带宽较多
类似CDN的缓冲加速方案
在为碰我网提供服务时能够节省带宽
在为PHONE+提供服务器时此优点不明显
开发难度相对较大，和应用结合非常紧密
4语音加速系统总体架构
鉴于目前的产品技术架构，网需要使用不透明代理应用方案，而Phone+项目使用socks5透明代理方案完成。
4.1ACSforFlash部署设计方案
4.1.1方案概述
目前我们对网语音加速模块实施的大致思路为：
用户到PRS网速不佳时采用Flash<->ACS<->PRS的连接方式。
为了节省ACS硬件及网络成本，我们设计在网络状况良好的情况下用户可以直连PRS参与语音通话。
因此目前ACS为Flash提供语音加速服务，我们设计为入口和出口均采用TCP承载的RTMP协议通讯方式。
由于Flash内嵌的TCP连接机制限制二次开发对其进行TCP协议层操控，无法完美整合socks5代理方案。
因此如果想让一个ACS能够为不同的PRS服务器提供语音加速服务，一般设计是让Flash客户端先与ACS连接握手，然后通过应用层AMF数据消息通知ACS与哪个PRS进行TCP/RTMP连接握手。
但是这样大大降低用户端Flash与真实PRS之间的连接速度（RTMP协议连接握手过程有若干个计算素数过程，这个过程比较消耗物理时间，一般在10ms左右），当然也会对产品的用户体验造成负面影响。
一种简单的做法是设定每一个ACS应用程序只为一个PRS提供加速服务，而一个PRS可以部署多个ACS，如：
教育网、移动网、电信网均可分别部署不同的ACS为一个PRS提供服务，各自不同网络的用户连接各自网络最适合的ACS进行语音加速中转。
依此设计每一个ACS对网络带宽和对物理服务器CPU、内存资源占用率都应该小于其服务的PRS所占用的物理服务器资源。
一般我们会在一台物理服务器部署一个PRS应用程序，并希望这一个应用程序尽可能充分使用该物理服务器所享有的带宽、CPU、内存资源。
而一个ACS使用这些网络及硬件资源的比率要比其服务的PRS小很多，所以可以考虑一台物理服务器上部署多个ACS应用程序，每个ACS应用程序分配一个网络端口供用户连接使用。
但是经过互联网部署PRS实践经验证明，很多运营商购置的网络防火墙、路由器出于安全性考虑能够智能识别RTMP协议并且判断当前承载该协议的TCP连接通道是否是使用1935端口（RTMP官方协议默认端口）。
如果不是则会很快掐断该TCP连接。
所以为了更好的为普通互联网用户服务，我们在部署RTMP协议服务器时对外提供的访问端口必须要使用1935，这样一来一台服务器则只能部署一个支持RTMP协议接入的应用服务程序。
基于以上讨论，我们创新了一种RTMP加速代理TCP出口连接机制。
即：
通过RTMP握手时的消息内容rtmp:
//10.254.21.5/appname来做设计，将appname改换成真实PRS的地址及端口信息，这样在ACS接受来至Flash客户端RTMP连接握手请求时开始分析真实PRS地址从而创建与不同PRS的TCP/RTMP握手连接。
由于RTMP握手请求是Flash客户端和RTMP服务器进行TCP连接后的第一个工作步骤，所以在此处再开始出口数据TCP连接虽然比服务器监听到入口数据TCP连接请求时就创建代理出口TCP连接慢一拍，但这相比与之前提到过的基于AMF消息数据传送目的PRS信息快很多，基本可以忽略不计。
而这样一来ACS便可对多个不同物理服务器的PRS提供加速代理服务。
最终能够实现节约硬件和网络资源，有不影响代理连接速度的语音加速子系统。
4.1.2侦听FlashTCP连接响应机制（供参考）
1）Flash客户端通过TCP与ACS连接；
2）ACS接受到来自客户端RTMP握手请求，则自动完成握手控制；
3）ACS在嗅探到来自客户端的TCP连接，立即向对应的真实PRS发起TCP连接，并自动完成RTMP握手。
如果握手成功ACS则需要标记该中转通道中转协议握手成功；
4）ACS接受到来自客户端的AMF消息，ACS会先判断转出链路的握手情况，如果未握手成功，则先缓存AMF数据，待握手成功后转发出去；
5）ACS反复收到来自客户端的AMF消息，而总是需要缓存，则需判断等待转出线路握手成功的时间是否超时，如果超时需要清理该TCP连接；
6）ACS接收到来自客户端的RTMP语音流数据，则自动接驳转出链路进行转发输出；
4.1.3侦听FlashRTMP握手协议响应机制（采用）
1）Flash客户端通过TCP与ACS连接；
2）Flash客户端在连接成功后开始于ACS进行RTMP协议握手，发送类似rtmp:
//10.254.21.5/appname式样的握手请求命令。
同时将appname内容定义成动态内容，使其包含真实PRSIP/PORT等信息；
3）ACS处理RTMP协议握手请求时，解析出握手请求的appname中包含的真实PRSIP/PORT信息，立即向对应的真实PRS发起TCP连接，并自动完成PRSRTMP协议握手。
如果握手成功ACS则需要标记该中转通道中转协议握手成功；
4）ACS接受到来自客户端的AMF消息，ACS会先判断转出链路的握手情况，如果未握手成功，则先缓存AMF数据，待握手成功后转发出去；
5）ACS反复收到来自客户端的AMF消息，而总是需要缓存，则需判断等待转出线路握手成功的时间是否超时，如果超时需要清理该TCP连接；
6）ACS接收到来自客户端的RTMP语音流数据，则自动接驳转出链路进行转发输出；
4.1.4基于DNS智能解析技术的ACS分配用户网络识别方案
1）用户访问网站，均需通过域名访问，客户端通过DNS智能解析获得网网站服务器的IP地址访问网站；
2）网站在不同的机房部署若个网站主机群，通过NingX反向代理方案将网页请求重定向到主网站机房，并在必要的HTTP请求链接中追加用户网络类型属性参数；
3）网站服务器通过HTTP请求链接获得到用户网络信息后为用户推送符合用户网络特性的ACS信息供用户使用或者直接告知用户真实的PRS信息；
4）用户通过服务器返回的PRSIP/PORT信息连接对应的语音服务器或是经过ACS中转；
举例如下：
a）中心网站服务器部署在北京联通IDC机房，另又部署两个反向代理网站主机群在贵阳电信IDC和教育网IDC。
b）某贵阳电信用户访问网站被DNS智能解析分配指向到贵阳IDC机房服务器，某教育网用户访问网站被DNS智能解析分配指向教育网IDC机房的服务器。
c）贵阳电信机房主机配置NingX系统将用户http请求反向代理到北京中心机房；教育网机房主机配置NingX系统将用户http请求反向代理到北京中心机房。
d）NingX可以通过配置控制让通过它转向的http请求附加请求参数，我们利用该机制在不同的机房进行不同的配置，附带参数标识不同的机房信息（例如：
e）中心网站服务器通过读取idc_id的数值，知道网站访问者的网络类型，以便后台程序可以根据该网络类型分配对应的ACS服务器或者直接将真实PRS地址信息下发给用户进行直连。
如：
某频道所在的PRS服务器在联通机房，则联通用户可以直连该PRS服务器，而其他网络用户可以通过ACS中转连接该服务器。
4.1.5ACS切换调度方案
由于目前网Flash语音模块是嵌入在网站中的网页DOM元素，它随着页面的加载、切换等行为而创建和销毁，因此它不是一个长期驻留客户端电脑内存的应用程序。
这对于产品客户端的推广、维护、管理有积极的一面，但也带来一些麻烦的问题。
和语音加速直接关联的便是客户端网速检测的问题。
由于客户端没有一个长期驻留内存运行的程序，无法连贯的对我们提供的语音服务器到用户客户端网络状况进行检测记录工作，不便于服务器收集客户端网络状况而对其进行动态合理的分配ACS资源。
有些时候存在我们分配的ACS不是最优或者还不如用户直连PRS进行通讯的效果。
这种情况出现的时候只能通过用户手工触发调整来实施网络优化。
因此希望在Flash界面中能够设计如下图所示的“加速”按钮以便用户客户端手工触发加速服务器优选调整工作。
4.1.6ACS分配策略
1）服务器需要记录每一个IP（或一个C类地址IP段）到某一个PRS地址的历史最优访问路径，并存在该网络访问路径的ACS分配评价体系数据库；
2）每次用户请求加入频道，服务器首先查询用户IP所在C类地址段到所访问PRS地址的网络评价数据，并根据网络质量评价数据分配（同时考虑ACS负载情况）一个以较优访问路径为为依据的ACS供用户使用（或者不分配让用户直连PRS）；
3）用户在进入频道后，参与频道互动过程中可能会认为语音质量不佳。
此时可以通过手工点击Flash界面中的加速按钮触发重新分配PRS（即分配ACS）的过程，用户得到新的PRS地址信息后，与当前所连接PRS信息比对，如果不一致可以通过Flash内部进行自动切换；
4）其他策略待补充…
4.2ACSforRTP部署设计方案
4.2.1RTP语音（socks5）封包传输机制
未完成
4.3服务器逻辑拓扑图
4.3.1总体逻辑图
4.3.2加速频道服务器
4.4客户端语音加速机制
4.4.1Flash客户端加速
4.4.2Phone+（RTP）客户端加速
5架构元素
5.1服务器云端
编号
服务器名称
01
加速管理服务器（AMS）
02
加速频道服务器（ACS）
5.2应用程序客户端
编号
模块名称
01
加速系统应用程序中间件（AAM）
6元素功能及接口
6.1语音客户端（Flash/Phone+）
用户在使用产品时，服务器根据客户端的网络情况判断是否需要分配对应的的ACS地址/端口供用户使用。
如果分配语音加速服务器为其服务，则当用户连上ACS服务器后ACS服务器会连接真实的PRS，并为用户进行数据代理转发服务。
6.2加速频道服务器（ACS）
6.2.1接口设计
1）和语音客户端通讯
a）接受来自Flash语音客户端的语音数据，Flash客户端通过TCP连接使用RTMP协议与其进行通讯，建立与计划连接的真实PRS的连接，并转发控制指令及语音流数据；
b）接受来至Phone+语音客户端的socks5数据包，将其解包后转发给对应的PCS服务器；
2）和PRS通讯
a）向PRS中转语音及控制指令数据；
3）和AMS通讯
a）ACS与AMS之间因为可能位于Internet上的不同网络之间，使用TCP通讯；
b）启动时向AMS注册；
c）定时向AMS报告存活情况，附带负载情况（连接数，带宽占用情况）；
d）AMS在分配了一个ACS给用户提供服务前，先发包向ACS进行服务请求，告知ACS需提供服务的对象，ACS收到请求后回应AMS，然后AMS返回加速服务器信息给应用服务器；
6.2.2扩展方式
在一个加速服务器区内，架设多台ACS，形成ACS服务器组，每个服务器负责一个PRS的代理服务。
而一个PRS又可以有多个ACS为其服务，例如某真实PRS部署在电信网机房中，则根据不同运营商网络情况判断一般可能会在联通网、移动网、教育网上分别找寻同时与电信网直连互通的双线机房搭建一个ACS为PRS提供语音加速服务器，AMS根据网速判定动态分配适合的ACS给用户服务。
6.2.3与其他服务器的连接
无
6.3加速管理服务器（AMS）
6.3.1接口设计
1）与ACS通讯
a）由于ACS与AMS之间可能部署在不同机房的互联网上，因此建立TCP通讯连接；
b）接受ACS的注册消息包，同时ACS每60秒向AMS发送存活消息包，并附带负载情况报告给AMS，AMS将该数据在内存中存储。
方便系统运行中根据该数据分配ACS供用户使用；
c）AMS在程序启动时从系统数据库中读取它管辖的ACS服务器配置情况，ACS向AMS注册后，AMS向ACS下推ACS信息；
2）与APPServer通讯
a）接收并处理来自AppServer的加速服务器资源申请，并进行计算分配ACSIP/PORT等信息；
b）客户端得到ACS服务器信息当做PRS服务器进行使用，直接连接ACS服务器，但ACS服务器会将数据代理接驳至真实的PRS服务器；
6.3.2扩展方式
设计上AMS允许有多个，一个AMS管辖若干个ACS。
每一个待服务的PRS一般只由一个AMS管理其对应的ACS。
不同的PRS可以指定各自不同的AMS为其管辖对应的ACS。
注意，目前网PRS信息及分配joinToken均由PZMS负责，这样的设计PZMS将会形成瓶颈，另外PZMS要根据不同的PRS选择对应的AMS进行ACS资源分配，对系统将造成更大的性能瓶颈。
因此管理频道及joinToken分配建议改造由PUDBMS完成，分配PRS还是可以由PZMS完成，但是其完成PRS分配的同时，最好也附带返回对应的AMS信息。
这样PUDBMS即可直接与AMS对接进行ACS资源分配。
而Phone+系统中PCMS和PES已经完成了上述管理机制，因此Phone+系统上应该由PCMS分配PCS服务器，在返回PCS服务器信息的同时返回PCS对应的AMS服务器，运行过程中由PES直接与对应的AMS对接进行ACS资源分配。
6.3.3与其他服务器的连接
与数据库连接，记录该服务器管辖的ACS的详细运行情况。
6.4加速系统应用程序中间件（AAM）
AAM是作为嵌入到使用加速系统的客户端插件由应用程序服务器控制启动的动态库。
6.4.1接口设计
1）与AMS通讯
a）AAM提供客户端API供应用程序调用，用以控制AAM和AMS通讯进行；
6.4.2扩展方式
无
6.4.3与其他服务器的连接
无
7重点用例概述
7.1服务器存活管理
1）ACS每隔60秒向AMS发送存活消息包。
内容包括：
ACS_ID，在线双向数据流人数，在线人数
每台ACS向AMS发送存活包，AMS便缓存了如下数据：
ACS1在线双向数据流人数在线人数
ACS2在线双向数据流人数在线人数
ACS3在线双向数据流人数在线人数
…
依此数据AMS可掌握每台ACS的存活和带宽负载情况。
7.2ACS资源分配过程
1）过程略；
7.3ACS加速传输控制过程
7.3.1Flash（RTMP）管理机制
1）Flash客户端把ACS地址当做PRS服务器进行连接，首先建立TCP连接；
2）ACS在监听到来自客户端的连接请求后，创建中转入口端协议链，并准备完成与客户端的RTMP协议握手过程。
3）Flash向ACS发起RTMP协议连接请求，服务器接收到后根据连接请求中的appname内容获得真实的PRS地址信息，向真实的PRS服务器发起TCP连接，创建中转出口协议链，又作为客户端与PRS完成RTMP协议握手过程；
4）在第三步所述的TCP连接创建及握手过程中ACS应该建立起入口
升级会员 