专利名称：一种在应用服务平台系统中对应用进行灰度发布的方法
技术领域：
本发明涉及互联网技术领域，特别涉及一种在应用服务平台系统中对应用进行灰度发布的方法。
背景技术：
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。对于应用服务平台而言，由于灰度发布的具体方法需要结合应用服务平台系统的具体应用路由方式，实现非常复杂，而现有的灰度发布方法并不适用于本应用服务平台系统，因此，现有针对应用服务平台的灰度发布解决方案是个迫切解决的问题，也就是说，迫切需要一种新的灰度发布方法来支持应用服务平台系统。
发明内容
本发明提供了一种在应用服务平台系统中对应用进行灰度发布的方法，该方法能够在本申请的发明人创造性地提出的应用服务平台系统中对应用进行灰度发布。为达到上述目的，本发明的技术方案是这样实现的；本发明公开了一种在应用服务平台系统中对应用进行灰度发布的方法，其特征在于，在应用服务平台系统中设置代理服务器和云计算应用服务系统，且在云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系；应用的描述信息中包括灰度发布因子，对于不采用灰度发布的应用，将其对应的灰度发布因子设置为空；该方法包括代理服务器接收到客户端请求消息后，对客户端请求消息进行解析，通过查询中心服务器上保存的应用的描述信息识别所述客户端请求消息所对应的应用，如果找到多个应用，则按如下方式选择代理服务器先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配，如果匹配命中则选择所命中的应用，如果没有匹配命中则选择灰度发布因子为空的应用；代理服务器根据所选择的应用以及应用与应用服务器之间的对应关系将客户端请求消息分发给云计算应用服务系统中的对应应用所在的应用服务器。本发明实施例的有益效果是本发明提供了一种在应用服务平台系统中对应用进行灰度发布的方法，该方法能够在本申请的发明人创造性地提出的应用服务平台系统中对应用进行灰度发布。
图1是本发明实施例中的一种在应用服务平台系统中对应用进行灰度发布的方法的流程图；图2是本发明实施例中的应用服务平台系统的一个实际组网示意图。
具体实施例方式为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。图1是本发明实施例中的一种在应用服务平台系统中对应用进行灰度发布的方法的流程图。在应用服务平台系统中设置代理服务器和云计算应用服务系统，且在云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系；应用的描述信息中包括灰度发布因子，对于不采用灰度发布的应用，将其对应的灰度发布因子设置为空；则如图1所示，该方法包括101，代理服务器接收到客户端请求消息后，对客户端请求消息进行解析，通过查询中心服务器上保存的应用的描述信息识别所述客户端请求消息所对应的应用，如果找到多个应用，则按如下方式选择代理服务器先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配，如果匹配命中则选择所命中的应用，如果没有匹配命中则选择灰度发布因子为空的应用。本步骤中，所述代理服务器先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配包括代理服务器根据灰度发布因子不为空的应用各自的描述信息分别创建应用上下文，对于其中的每个应用，根据其应用上下文中的灰度发布因子匹配条件信息匹配其描述信息中的灰度发布因子，如果符合灰度发布因子所表达的条件，则命中。102，代理服务器根据所选择的应用以及应用与应用服务器之间的对应关系将客户端请求消息分发给云计算应用服务系统中的对应应用所在的应用服务器。下面对本发明中的应用灰度发布方法所适用的应用服务平台系统进行说明。图2是本发明实施例中的应用服务平台系统的一个实际组网示意图。如图2所示， 该应用服务平台系统包括代理服务器和云计算应用服务系统，其中，云计算应用服务系统中的应用服务器集群上负载并运行应用，并且云计算应用服务系统中保存有应用的描述信息以及应用与应用服务器之间的对应关系；代理服务器，用于接收客户端请求消息，对客户端请求消息进行解析，确定对应的应用，如果有多个对应的应用，根据灰度发布因子最终确定一个应用，然后根据该应用的描述信息创建该应用的应用上下文，在所述客户端请求消息中添加应用上下文后，根据所述应用与应用服务器之间的对应关系将客户端请求消息分发给对应的应用所在的应用服务器；接收应用服务器端返回的处理结果，并返回给客户端；所述云计算应用服务系统中的所述应用服务器，用于在接收到代理服务器发送的客户端请求消息时，将该客户端请求消息交给对应的应用进行处理，并将处理结果返回给代理服务器；所述对应的应用处理该客户端请求消息所请求的任务，根据所述应用上下文进行数据资源定位，得出处理结果。应用服务器将所述处理结果经代理服务器返回给客户端。上述云计算应用服务系统中保存的应用与应用服务器之间的对应关系，采用表格保存，其中记录有应用进程名称和应用服务路径，即应用与应用服务器之间的对应关系。
如图2所示，本发明实施例中，云计算应用服务系统包括中心服务器、资源服务器和由多个应用服务器组成的服务器集群，其中中心服务器，用于接收外部上传的应用，将应用的描述信息保存到应用配置信息列表中，创建所述应用与应用服务器之间的对应关系，并在对应的应用服务器上部署该应用，保存用于保存应用与应用服务器之间的对应关系的应用运行信息列表；每个应用服务器，用于将所负载的应用的运行信息上传到中心服务器上的用于保存应用与应用服务器之间对应关系的应用运行信息列表中；其中，应用配置信息列表包括如下信息应用ID、应用名称、应用服务类型、应用进程名、应用服务元数据标注和灰度发布因子；应用运行信息列表包括如下信息应用进程名称、应用的服务地址；资源服务器，用于保存应用服务器上的各应用处理客户端请求消息所请求的任务时需要访问的数据资源；在本实施例中，资源服务器包括数据库服务器、文件服务器和内存对象缓冲服务器。代理服务器，用于接收客户端请求消息，通过查询中心服务器上的应用配置信息列表识别该客户端请求消息所对应的应用，然后通过查询中心服务器上的应用配置信息列表和应用运行信息列表获得对应的应用的服务地址，根据所获得的服务地址将客户端请求消息分发给对应的应用所在的应用服务器；接收应用服务器端返回的处理结果，并返回给客户端；在本发明的一个实施例中，代理服务器包括超文本传输协议HTTP代理服务器、 初始会话SIP代理服务器和短信系统SMS代理服务器。其中，HTTP代理服务器负责分发 HTTP应用，SIP代理服务器负责与客户端的SIP长连接，SMS代理服务器负责分发短信上行应用。此外，云计算应用服务系统还包括与应用服务器集群连接的基础服务服务器(在图2中未画出该基础服务服务器)，用于提供平台内部需求的一些核心应用或独立应用。在图2所示的应用服务平台系统中，所述代理服务器，用于在接收到客户端请求消息时，从客户端请求消息中提取请求参数，查询中心服务器中的应用配置信息列表，查找出请求参数与元数据标注字段符合的应用配置信息列表项，进而识别出对应的应用。例如当接收到HTTP请求消息时，根据该请求消息中的统一资源定位符URL，查询中心服务器上的应用配置信息列表，查找出应用元数据标注字段包含有与所述URL —致信息的应用配置信息列表项，根据所查找出的应用配置信息列表项中的应用名称识别出该客户端请求消息所对应的应用；或者，代理服务器在接收到与远程调用应用组件RemoteAppBean对应的远程调用过程协议Rpc请求时，根据该请求消息中的远程调用服务名称(RemoteAppName)，查找出中心服务器上应用名称(AppName)字段与所述远程调用服务名称一致的应用配置信息列表项，根据所查找出的应用配置信息列表项中的应用名称字段识别出该请求消息所对应的应用；所述代理服务器，用于根据所查找出的应用配置信息列表项中的应用进程名，查找出中心服务器上的应用进程名称字段包含与所述应用进程名一致信息的应用运行信息列表项，从所查找出的应用运行信息列表项中获取应用服务的服务地址信息。并根据所述应用的服务地址信息将客户端请求消息分发给对应的应用所在的应用服务器。所述代理服务器，根据所查找出的应用配置信息列表项中的元数据标注字段中的关于加载应用服务上下文信息，创建应用服务上下文。在图2所示的应用服务平台系统中，中心服务器，进一步用于保存资源列表；资源列表包括如下信息资源名称、资源类型、应用服务上下文类型、定位算法名称和定位算法参数；应用在接收到客户端请求消息后，在完成该客户端请求消息所请求的任务的过程中根据应用上下文以及资源列表中的对应信息进行资源定位。可见，本发明这种由上述代理服务器、应用服务器集群、中心服务器和资源服务器构成的应用服务平台系统，将分散的服务器资源在逻辑上整合到一起，极大降低了应用的开发难度，提高了部署的灵活性并降低了部署的难度。关于应用上下文称为AppContext本发明的应用服务平台系统中不仅将开发模式拆分为面向单独信令，并且将信令与应用上下文绑定在一起，应用上下文称为AppContext。在本发明的应用服务平台系统中， 应用服务上下文(AppContext)是应用调用及资源定位的关键。这里应用调用包括代理服务器调用应用服务，以及应用服务内调用其他的应用服务，这两种应用都需要AppContext 来实现目标应用服务的定位。AppContext可以这样理解=AppContext绑定一个当前应用运行的所在环境身份， 比如当前用户，这样做，开发人员在开发时刻是基于AppContext (当前用户)进行开发，访问资源(数据库，文件，缓存)都必须通过当前的AppContext，这样开发者可以不用管理数据库，文件，缓存等的拆分问题，甚至用户数据的跨机房问题，只关基于当前用户进行开发即可，极大的简化了开发模式，将系统部署结构与开发过程隔离开来，实现高效，便捷的 PaaS平台。AppContext从数据构成上分为两部分，AppContext是可序列化与反序列化的(1)通用资源标志符URI (Context Uri)为字符串格式，包括用户的索引信息，负责后续的定位，如 id 230302023 ；session 13910000001。(2)附加数据(ContextData):是预定义好的强类型数据结构，可以包含多个字段；其包括该应用的属性信息；应用的属性信息包括会话参数、授权信息等；在某些场合，附加数据会由Proxy产生提供给后面应用，在长连接的Proxy服务器场景(参见Proxys章节)。支持getNamedValue (String fieldName)方法，可以获取到一个特定字段名的数据，此方法被用于灰度发布场合(见后文)。AppContext是抽象基类，在Framework中预定义了以下的AppContext子类NullContext 预定义的空上下文，用在不需要上下文的场合；SessionContext 预定义的只保存会话Id的上下文。在复杂应用中，一般会在Biz Library中扩展特定的AppContext，比如一个IM系统，在SIP Proxy上会保存用户的Session，那么我们可以扩展UserContext，那么每个应用处理的时候都会接收到Proxy上保存的Session信息。除标准AppContext，在使用本发明的应用服务系统平台进行扩展开发的时候，需要先定制业务相关的一些基础，AppContext就是其中之一。下面例举一个关于AppContext 的具体实施例。例如使用本发明的应用服务平台系统开个一个即时消息(IM)系统，这个IM 系统中的用户都采用一个整数id进行定位，那么可以根据如下方式定制这个IM系统的 AppContex,从 AppContext 派生，命名为 UserContext · Uri部分“id :230302023”，表示用户的id，那么通过这个用户的id，可以定位用户的应用服务位置与数据库存储位置；· Data 部分_用户的登录网络地址；-客户端类型等；当定制了用户的UserContext，所有该系统内基于用户进行操作的AppBean都会用UserContext作为AppBean的C 参数，如-获取用户资料；-设置用户资料；-获取好友列表等；此外，在本发明的应用服务平台系统中，除了提供基于单个用户的AppContext 外，还提供了基于群组的业务类型，开发基于群组的应用服务，也需要定制基于群组的AppContext，IM系统使用一个整数用于标识群组，从AppContext派生，命名为 GroupContext, GroupContext 的结构如下· Uri部分“group 123123”，标识群组id，表示用户的id，那么通过这个群组的 id，我们可以定位群组的应用服务位置，与数据库存储位置；· Data 部分-群组的会话参数；-群组的授权等；当定制了基于群组的GroupContext后，该系统内基于群组进行操作的所有 AppBean 都会用 GroupContext 作为 AppBean 的 C 参数，如-设置群组名称；-更新群组权限；-获取群离线消息等。应用的元数据标注(Annotations)信息在发明中，开发一个应用AppBean及扩展AppBean时，会通过Java元数据标注 (Annotation)标注应用的负载方式，运行方式等数据，此数据编译后，可以在运行期加载， 或从编译后的二进制包中将数据从反射中提取出来。在本发明的实施例中，一些预定义的Annotations如下文描述，扩展的AppBean都会定义自己特定的Annotation。1. OAppName (应用的名字和分类名)·声明AppBean的名字以及分类名；-OAppName (category = 〃 Core", name=" GetUserInfo")；这里@ΧΧΧ为Java语言对程序元数据的标注。· Category :name 全局唯一；· category 可以用于 AppBean 的分类；-方便运维人员进行配置与分类；-在一个Category中，如果允许一个AppBean能够被其他Category中的AppBean 访问，必须将这个AppBean声明成为公开，或友好；· iPub IicO 允许所有的 AppBean 访问；
· OFriendlly ( “Core，，)只允许指定 Category 访问；· OFriendlly( "Core =AddBuddy")只允许指定应用访问。2. OStateful (应用的状态信息)·当声明一个AppBean为有状态的，则此个AppBean可以将状态保存在本机内存中；·没有标注OStateful的应用均视为无状态应用，禁止使用本机内存进行状态的保存； 如果一个Category 中的多个AppBean声明的 Stateful 参数一样(“Presence”)， 则这个几个AppBean启动到一个进程中，并且不允许单独热更新；· iStateful的应用在热更新的时候会丢失状态，所以尽量用memcache方式去代替，建议仅在某些性能要求很高的领域启动；·当某个AppBean被声明为Stateful时，针对这个AppBean的访问会采用这个 AppBean的AppContext绑定的一致性Hash的方式进行路由。3. OHttpPrefixHttpPrefix (HTTP 前缀，只针对 HttpAppBean)·用于标注一个HttpAppBean处理的Http请求范围； 如@HttpPrefix(〃 /login, do")；-表示该HttpAppBean处理以login,do为起始的http请求。Message Name (事件名称，只针对 MessageAppBean)·用于标注一个MessageAppBean的名称；·如@Message Name4. iContextLoader (加载应用服务上下文信息)·用于标注一个AppBean如何加载AppContext 如@ContextLoader (name = 〃 CookieParser〃 )-表示通过名为CookieParser的程序去处理处理Context；-CookieParser程序内置在Proxy当中，通过处理HttpRequest中的Cookie字段去加载用户相关信息。在本发明的实施例中，一些预定义的Annotations不限于如上的几种，可以根据实际业务需求增加其他的标注。基于AppContext的资源访问定位在本发明中，定义并实现一个具有某种业务功能的应用后，这个应用势必要访问各种资源，如数据库、文件服务器、内存对象缓冲服务器或其他提供的服务等。本发明中的应用服务平台系统是大型分布式系统，所以这些资源都不是单点服务，也就是同一个类型的数据库可能存在多个纵向拆分(Sharding)的实例。本发明中将一个应用能够访问的资源绑定在了其应用上下文AppContext上。比如，声明一个获取用户信息的应用，名为GetUserlnfoApp，在应用的实现环节读取用户数据库(UserDB)，将结果返回。其中UserDB存在多个通过用户id进行取模后进行纵向拆分的实例。那么具体过程如下
1.代理服务器Http Proxy接收到来自于客户端的Http请求；2. Http Proxy通过Http请求的URL判断该请求对应的应用；具体为HttpProxy 通过访问中心服务器上的应用配置信息列表，找到元数据标注Annotations字段中的@ HttpPrefix与Http请求的URL —致的应用配置信息列表项，该表项对应的应用即为该 Http请求所对应的应用；3. Http Proxy通过步骤2识别该请求是GetUserInfoApp的请求，并需要 UserContext作为上下文参数；4. Http Prorxy根据应用配置信息表项中的Annotations字段中的@ ContextLoader,以及Http请求报文中提取的相关信息创建UserContext ；5. Http Proxy在来自客户端的Http请求中添加了 UserContext数据后将Http 请求转发到GetUserlnfoApp所在的应用服务器；这里通过查询应用运行信息列表获得 GetUserInfoAPP的服务地址。6.应用服务器上的运行GetUserInf0App的应用进程接收到Http请求，提取 UserContext,并交给 GetUserInfoApp 处理；7. GetUserInfoApp 读取 UserDB，在读取 UserDB 的时候，通过 UserContext 中的 id 信息，进行UserDB的定位；8. GetUserInfoApp 组织返回报文，并返回给 Http Proxy ；9. Http Proxy将返回报文返回给客户端。在上述过程的步骤7中，通过资源(Resource)表进行定位。在本发明的一个实施例中的资源表如表1所示
权利要求
1.一种在应用服务平台系统中对应用进行灰度发布的方法，其特征在于，在应用服务平台系统中设置代理服务器和云计算应用服务系统，且在云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系；应用的描述信息中包括灰度发布因子，对于不采用灰度发布的应用，将其对应的灰度发布因子设置为空；该方法包括代理服务器接收到客户端请求消息后，对客户端请求消息进行解析，通过查询中心服务器上保存的应用的描述信息识别所述客户端请求消息所对应的应用，如果找到多个应用，则按如下方式选择代理服务器先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配，如果匹配命中则选择所命中的应用，如果没有匹配命中则选择灰度发布因子为空的应用；代理服务器根据所选择的应用以及应用与应用服务器之间的对应关系将客户端请求消息分发给云计算应用服务系统中的对应应用所在的应用服务器。
2.根据权利要求1所述的方法，其特征在于，所述灰度发布因子为条件表达式；所述代理服务器先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配包括代理服务器根据灰度发布因子不为空的应用各自的描述信息分别创建应用上下文，对于其中的每个应用，根据其应用上下文中的灰度发布因子匹配条件信息匹配其描述信息中的灰度发布因子，如果符合灰度发布因子所表达的条件，则命中。
3.根据权利要求2所述的方法，其特征在于，当发布了应用B和调用B的应用A后，又对相应的升级版本B’和A’进行了灰度发布，并将B’的灰度因子设定为匹配A’的版本号， 则客户端请求消息路由到A’后的过程如下A’在应用的描述信息中寻找要调用的应用，找到B和B’；由于B’的灰度发布因子不为空，因此先进行匹配；A’获取自身的版本号后匹配B’的灰度发布因子，命中；A’选择B’作为调用的应用。
4.根据权利要求2所述的方法，其特征在于，所述灰度发布因子的条件表达式为基本条件表达式，或多个基本条件表达式之间的逻辑运算关系表达式；基本条件表达式为取值点.取值条件；其中，取值点满足取值条件时，命中。
5.根据权利要求1至4中任一项所述的方法，其特征在于，该方法进一步包括所述代理服务器根据所选择应用的描述信息创建应用上下文，在所述客户端请求消息中添加应用上下文后，再根据所述应用与应用服务器之间的对应关系将客户端请求消息分发给云计算应用服务系统中的对应应用所在的应用服务器；所述云计算应用服务系统中的所述应用服务器在接收到代理服务器发送的客户端请求消息时，将该客户端请求消息交给对应的应用进行处理；所述对应的应用处理该客户端请求消息所请求的任务，根据所述应用上下文进行数据资源定位，得出处理结果；应用服务器将所述处理结果经代理服务器返回给客户端。
6.根据权利要求5所述的方法，其特征在于，所述云计算应用服务系统包括中心服务器、资源服务器和由多个应用服务器组成的应用服务器集群；其中，在资源服务器上保存应用服务器上的各应用处理客户端请求消息所请求的任务时需要访问的数据资源；所述应用服务器集群上负载并运行应用；所述在云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系包括中心服务器接收外部上传的应用，将应用的描述信息保存到应用配置信息列表中，并将应用部署到应用服务器集群中的应用服务器上；应用服务器集群中的应用服务器将所负载的应用的运行信息上传到中心服务器上的用于保存应用与应用服务器之间对应关系的应用运行信息列表中；其中，应用配置信息列表包括如下信息应用ID、应用名称、应用类型、应用进程名、应用元数据标注和灰度发布因子；应用运行信息列表包括如下信息应用进程名称和应用的服务地址；代理服务器根据应用与应用服务器之间的对应关系将客户端请求消息分发给云计算应用服务系统中的对应应用所在的应用服务器包括代理服务器通过查询中心服务器上的应用配置信息列表和应用运行信息列表获得对应的应用的服务地址，根据所获得的服务地址将客户端请求消息分发给对应的应用服务所在的应用服务器。
7.根据权利要求6所述的方法，其特征在于，所述代理服务器根据应用的描述信息创建应用上下文包括代理服务器在接收到客户端请求消息时，从客户端请求消息中提取请求参数，查询中心服务器中的应用配置信息列表，查找出请求参数与元数据标注字段符合的应用配置信息列表项，然后根据该应用配置信息列表项中的元数据标注字段中的关于加载应用上下文的信息，创建应用上下文。
8.根据权利要求6所述的方法，其特征在于，所述中心服务器上还保存资源列表；资源列表包括如下信息资源名称、资源类型、应用上下文类型、定位算法名称和定位算法参数；所述应用处理客户端请求消息所请求的任务，根据所述应用上下文进行数据资源定位包括应用在接收到客户端请求消息后，在完成该客户端请求消息所请求的任务的过程中根据应用上下文以及资源列表中的对应信息进行资源定位。
9.根据权利要求6所述的方法，其特征在于，所述代理服务器在接收到客户端请求消息时，对客户端请求消息进行解析，通过查询中心服务器上的应用配置信息列表识别所述客户端请求消息所对应的应用包括代理服务器在接收到HTTP请求消息时，根据该请求消息中的统一资源定位符URL，查找出中心服务器上的应用元数据标注字段包括有与所述URL—致信息的应用配置信息列表项，根据所查找出的应用配置信息列表项中的应用名称识别出该客户端请求消息所对应的应用；或者，代理服务器在接收到Rpc请求消息时，根据该请求消息中的远程调用服务名称，查找出中心服务器上应用名称字段与所述远程调用服务名称一致的应用配置信息列表项，根据所查找出的应用配置信息列表项中应用名称字段识别出该请求消息所对应的应用；所述通过查询中心服务器上的应用配置信息列表和应用运行信息列表获得对应的应用的服务地址包括代理服务器根据所查找出的应用配置信息列表项中的应用进程名，查找出中心服务器上的应用进程名称字段包含与所述应用进程名一致信息的应用运行信息列表项，从所查找出的应用运行信息列表项中获取应用的服务地址信息。
10.根据权利要求6所述的方法，其特征在于，该方法进一步包括 将所述应用服务器集群中的多个应用服务器分为多个不同组； 在所述中心服务器上保存应用服务器列表和应用服务器分组列表；其中，应用服务器列表包括如下信息应用服务器名称、应用服务器所属的分组名称和应用服务器地址；应用服务器分组列表包括应用服务器分组名称和分组中的应用服务器描述信息；中心服务器在接收到外部上传的应用时，根据外部指令将该应用部署到单个应用服务器上，或者部署到属于同一组的多个服务器上。
全文摘要
本发明公开了一种在应用服务平台系统中对应用进行灰度发布的方法。该方法包括在应用服务平台系统中的云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系；应用的描述信息中包括灰度发布因子；代理服务器接收到客户端请求消息后，查询应用的描述信息识别所述客户端请求消息所对应的应用，如果找到多个应用，按如下方式选择先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配，如果没有匹配命中则选择灰度发布因子为空的应用；根据所选择的应用以及应用与应用服务器之间的对应关系将客户端请求消息分发给云计算应用服务系统中的对应应用服务器。本发明的技术方案能够在应用服务平台系统中对应用进行灰度发布。
文档编号H04L29/08GK102497454SQ201110460620
公开日2012年6月13日 申请日期2011年12月31日 优先权日2011年12月31日
发明者赵博然, 高磊 申请人:北京新媒传信科技有限公司