CN102497454B

CN102497454B - 一种在应用服务平台系统中对应用进行灰度发布的方法

Info

Publication number: CN102497454B
Application number: CN201110460620.XA
Authority: CN
Inventors: 高磊; 赵博然
Original assignee: Beijing Feinno Communication Technology Co Ltd
Current assignee: Beijing Feinno Communication Technology Co Ltd
Priority date: 2011-12-31
Filing date: 2011-12-31
Publication date: 2014-06-11
Anticipated expiration: 2031-12-31
Also published as: CN102497454A

Abstract

本发明公开了一种在应用服务平台系统中对应用进行灰度发布的方法。该方法包括：在应用服务平台系统中的云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系；应用的描述信息中包括灰度发布因子；代理服务器接收到客户端请求消息后，查询应用的描述信息识别所述客户端请求消息所对应的应用，如果找到多个应用，按如下方式选择：先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配，如果没有匹配命中则选择灰度发布因子为空的应用；根据所选择的应用以及应用与应用服务器之间的对应关系将客户端请求消息分发给云计算应用服务系统中的对应应用服务器。本发明的技术方案能够在应用服务平台系统中对应用进行灰度发布。

Description

一种在应用服务平台系统中对应用进行灰度发布的方法

技术领域

本发明涉及互联网技术领域，特别涉及一种在应用服务平台系统中对应用进行灰度发布的方法。

背景技术

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。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.AppName(应用的名字和分类名)

·声明AppBean的名字以及分类名；

-AppName(category＝″Core″，name＝″GetUserInfo″)；

这里xxx为Java语言对程序元数据的标注。

·Category：name全局唯一；

·category可以用于AppBean的分类；

-方便运维人员进行配置与分类；

-在一个Category中，如果允许一个AppBean能够被其他Category中的AppBean访问，必须将这个AppBean声明成为公开，或友好；

·Public()：允许所有的AppBean访问；

·Friendlly(“Core”)：只允许指定Category访问；

·Friendlly(“Core：AddBuddy”)：只允许指定应用访问。

2.Stateful(应用的状态信息)

·当声明一个AppBean为有状态的，则此个AppBean可以将状态保存在本机内存中；

·没有标注Stateful的应用均视为无状态应用，禁止使用本机内存进行状态的保存；

·如果一个Category中的多个AppBean声明的Stateful参数一样(“Presence”)，则这个几个AppBean启动到一个进程中，并且不允许单独热更新；

·Stateful的应用在热更新的时候会丢失状态，所以尽量用memcache方式去代替，建议仅在某些性能要求很高的领域启动；

·当某个AppBean被声明为Stateful时，针对这个AppBean的访问会采用这个AppBean的AppContext绑定的一致性Hash的方式进行路由。

3.HttpPrefix

HttpPrefix(HTTP前缀，只针对HttpAppBean)

·用于标注一个HttpAppBean处理的Http请求范围；

·如：HttpPrefix(″/login.do″)；

-表示该HttpAppBean处理以login.do为起始的http请求。

Message Name(事件名称，只针对MessageAppBean)

·用于标注一个MessageAppBean的名称；

·如：Message Name

4.ContextLoader(加载应用服务上下文信息)

·用于标注一个AppBean如何加载AppContext

·如：ContextLoader(name＝″CookieParser″)

-表示通过名为CookieParser的程序去处理处理Context；

-CookieParser程序内置在Proxy当中，通过处理HttpRequest中的Cookie字段去加载用户相关信息。

在本发明的实施例中，一些预定义的Annotations不限于如上的几种，可以根据实际业务需求增加其他的标注。

基于AppContext的资源访问定位

在本发明中，定义并实现一个具有某种业务功能的应用后，这个应用势必要访问各种资源，如数据库、文件服务器、内存对象缓冲服务器或其他提供的服务等。本发明中的应用服务平台系统是大型分布式系统，所以这些资源都不是单点服务，也就是同一个类型的数据库可能存在多个纵向拆分(Sharding)的实例。本发明中将一个应用能够访问的资源绑定在了其应用上下文AppContext上。

比如，声明一个获取用户信息的应用，名为GetUserInfoApp，在应用的实现环节读取用户数据库(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请求转发到GetUserInfoApp所在的应用服务器；这里通过查询应用运行信息列表获得GetUserInfoAPP的服务地址。

6.应用服务器上的运行GetUserInfoApp的应用进程接收到Http请求，提取UserContext，并交给GetUserInfoApp处理；

7.GetUserInfoApp读取UserDB，在读取UserDB的时候，通过UserContext中的id信息，进行UserDB的定位；

8.GetUserInfoApp组织返回报文，并返回给Http Proxy；

9.Http Proxy将返回报文返回给客户端。

在上述过程的步骤7中，通过资源(Resource)表进行定位。在本发明的一个实施例中的资源表如表1所示：

表1

可以通过实现不同的定位函数(Locator)，来实现针对不同资源的不同定位方式。例如在上例中，资源表的具体配置如表2所示：

表2

则在步骤7中使用id：1001定位UserDB时，ModDatabaseLocator会取出1001，并将1001除5，取余数为1，返回名为UserDB.1的数据库实例。

又例如：

开发一个即时消息(简写为IM)系统，这个IM系统中的用户都采用一个整数的id进行定位，那么可以如下方案定制这个IM系统的AppContext，从AppContext派生，命名为UserContext，

-Uri部分：“Id：230302023”，表示用户的id，那么通过这个用户的id，我们可以定位用户的应用位置，与数据库存储位置

-Data部分：

·用户的登录网络地址、

·客户端类型

·等...

当定制了基于用户的UserContext，所有该系统内基于用户进行操作的AppBean都会用UserContext作为AppBean的<C>参数

如：获取用户资料、设置用户资料、获取好友列表、...

但在一个IM平台中，除了提供基于用户的AppContext以外，还存在基于群组的业务类型，开发基于群组的应用，也需要定制基于群组的AppContext，IM系统使用一个整数用于标识群组，那么GroupContext结构如下

-Uri部分：“group：123123”，标识群组id，表示用户的id，那么通过这个群组的id，我们可以定位群组的应用位置，与数据库存储位置

-Data部分包括：群组的会话参数、群组的授权等

当定制了基于群组的GroupContext后，所有该系统内基于群组进行操作的AppBean都会用GroupContext作为AppBean的<C>参数

如：设置群组名称、更新群组权限、获取群离线消息、...

在图2所示的应用服务平台系统中，服务器集群中的多个应用服务器被分为多个不同的组，每组包括一台到多台服务器。中心服务器在接收到外部上传的应用时，根据外部指令将该应用部署到单个应用服务器上，或者部署到属于同一组的多个服务器上。这样，一个应用可以选择性地负载在某个组当中，也就是可以将核心的应用单独使用一组服务器，保证核心应用的资源使用及稳定性；而对刚上线的不稳定的应用使用一组单独的服务器，以剥离其中的影响，降低整个系统的风险。这种做法有利于进行整体资源的分配及网络策略的调整。

在本发明中，能够运行应用的应用服务器需要在全局统一配置，具体来说在中心服务上配置并保存全局的应用服务器列表和应用服务器分组列表。

应用服务器列表如表3所示：

字段名称	字段类型主键	描述
			ServerName	Varchar Y	应用服务器名称
ServerGroup	Varchar	应用服务器分组名称
			ServerAddress	Varchar	应用服务器地址

表3

由表3可见，应用服务器列表包括如下信息：应用服务器名称、应用服务器所属的分组名称、应用服务器地址。

应用服务器分组列表如表4所示：

字段名称	字段类型	主键	描述
				GroupNarme	varchar	Y	应用服务器分组名称
GroupDesc	Varchar		应用服务器描述信息

表4

由表4可见，应用服务器分组列表包括：应用服务器分组名称、分组中的应用服务器描述信息。

在实际应用中，多台应用服务器可以被分为不同的组，用于运行不同的应用服务，应用服务器分组的好处如下：1.将核心应用专门指定应用服务器组，可以保证核心应用的资源使用及稳定性；2.给一些新增的不稳定的应用指定单独的应用服务器组，可以降低整个系统的风险；3.有利于进行整体资源的分配及网络策略的调整。

以上对应用服务平台系统进行了详细描述，以下再对本发明的灰度发布方法进行详细描述。

灰度发布，就是应用按用户范围或启发方式分部开放给所有用户的过程，灰度发布可以降低应用更新造成的风险。

前面提到应用配置信息列表中包含灰度发布因子(GrayFactor)。在本发明中。对于没有采用灰度发布的应用，其对应的应用配置信息列表项中灰度发布因子为空；而对于采用灰度发布的应用，其应用配置信息列表项中配置有灰度发布因子。

在本发明中，灰度发布因子是条件表达式。

灰度发布因子的条件表达式为：基本条件表达式，或多个基本条件表达式之间的逻辑运算关系表达式；

基本条件表达式按照如下格式定义：

field.condition

其中：field和condition以.分隔开，field.condition间可以做逻辑运算，例如：

field1.condition1 and|or field2.condition2

field表示取值点，condition表示取值条件，即基本条件表达式为：取值点.取值条件；当取值点满足取值条件时，命中，即当满足此取值条件时使用此灰度发布的应用。

灰度发布因子的条件表达式也可以是多个基本条件表达式之间的逻辑运算关系表达式，例如：

在图2所示的系统中，代理服务器接收到客户端请求消息后，通过查询中心服务器上的应用配置信息列表识别所述客户端请求消息所对应的应用时，如果找到多个应用，则按如下方式选择；

代理服务器先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配，如果匹配命中则选择所命中的应用，如果没有匹配命中则选择灰度发布因子为空的应用(即默认应用)。

在本发明的一个实施例中，基于AppContext进行灰度发布，即field取值点为预定义在AppContext中的条件，通过AppContext.getNamedValue(″field1″)取得。

在前面的章节中提到了AppContext存在一个getNamedValue()方法的扩展，在灰度发布中getNamedValued()会作为灰度发布的field参数进行计算。

则所述的代理服务器先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配包括：代理服务器根据灰度发布因子不为空的多个应用所各自对应的应用配置信息列表中项，分别创建应用上下文，对于其中的每个应用，根据所创建的应用上下文中的灰度发布因子匹配条件信息匹配其灰度发布因子，如果符合灰度发布因子所表达的条件，则命中。例如当灰度发布因子为：客户端版本号＝V2.0，则根据应用上下文中的客户端版本号信息进行匹配，看其是否为V2.0，是则命中。

例如在前述章节中的UserContext扩展例子中，NamedValued定义如下：

灰度发布可用字段包括：用户所属区域(user_region)、用户客户端类型(client_type)、用户端ip地址所属区域(client_region)和客户端版本号(client_version)。

那么在SIP Proxy中实现的带灰度发布的应用路由步骤如下：

1.接收到请求后，获取用户的会话信息，创建UserContext；

2.通过请求的参数，在所有该类请求对应的应用配置信息列表中，寻找对应应用的应用配置信息列表项及对应的元数据标注(这一步根据不同类型的AppBean有不同的执行方法)；

3.在灰度发布的场合，步骤2可能寻找到多个应用配置信息列表项(一个应用对应一个应用配置信息列表行)，其中灰度发布因子GrayFactors为空的只允许有1个，其他GrayFactors不为空的数据为灰度发布。

4.优先判断GrayFactors不为空的应用配置信息列表项数据，按照配置获取的顺序将UserContext对GrayFactors进行计算，

a)如果计算不符合，则自动计算下一个，只到找到一个符合的为止

b)如果找到GrayFactors不为空的数据，则使用此应用配置信息列表项进行后续的路由计算；

c)如果找不到符合的GrayFactors不为空的应用配置信息列表项，则使用默认的应用配置信息列表项(GrayFactors为空的)信息进行后续的路由计算；

5.找到一个应用配置列表项后的路由算法与前述描述一致，即根据所找到的应用配置信息列表项中的应用进程名称查询应用运行信息列表，找到应用进程名称一致的应用运行信息列表项，如果为多个，则根据元数据标注判断此应用进程是随机负载还是一致性Hash负载，通过随机负载算法或者一致性Hash算法，找到确切的目标应用服务器地址，调用到目标应用服务器，并将应用配置信息列表项中的App Name附加在请求上。

版本号级联灰度

在本系统中，可能存在如下情况：应用A提供服务给用户，但是应用A调用应用B；应用A升级为应用A’，但是同时需要升级应用B为B’，我们会对应用A’进行灰度发布，但是希望A’调用B’而不是B。A和B的版本号为1.0，A’和B’的版本号为2.0。

本发明中给出的解决方案如下：当发布了应用B和调用B的应用A后，又对相应的升级版本B’和A’进行了灰度发布，并将B’的灰度因子设定为匹配A’的版本号，则客户端请求消息路由到A’后的过程如下：

1.A’在应用配置信息列表中寻找要调用的应用，找到B和B’；其中B’配置为灰度发布，且灰度发布因子中为版本匹配，灰度发布因子配置如下：app_version.equals(“2.0”)

2.由于B’的灰度发布因子不为空，因此先进行匹配；A’获取自身的版本号后匹配B’的灰度发布因子，命中；A’选择B’作为调用的应用。

3.选择B’后的路由过程与前述描述一致，这里不再赘述。

综上所述，本发明提供的一种在应用服务平台系统中对应用进行灰度发布的方法，能够在本申请的发明人创造性地提出的应用服务平台系统中对应用进行灰度发布，并且由于在该应用服务平台系统中部署的应用的开发是拆分到单个信令级别的，因此本发明中的灰度发布是针对信令，将应用按用户范围或启发方式分步开放给用户，降低了应用更新造成的风险。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims

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所述的方法，其特征在于，所述云计算应用服务系统包括：中心服务器、资源服务器和由多个应用服务器组成的应用服务器集群；其中，在资源服务器上保存应用服务器上的各应用处理客户端请求消息所请求的任务时需要访问的数据资源；

所述应用服务器集群上负载并运行应用；

所述在云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系包括：中心服务器接收外部上传的应用，将应用的描述信息保存到应用配置信息列表中，并将应用部署到应用服务器集群中的应用服务器上；应用服务器集群中的应用服务器将所负载的应用的运行信息上传到中心服务器上的用于保存应用与应用服务器之间对应关系的应用运行信息列表中；

其中，应用配置信息列表包括如下信息：应用ID、应用名称、应用类型、应用进程名、应用元数据标注和灰度发布因子；应用运行信息列表包括如下信息：应用进程名称和应用的服务地址；

代理服务器根据应用与应用服务器之间的对应关系将客户端请求消息分发给云计算应用服务系统中的对应应用所在的应用服务器包括：代理服务器通过查询中心服务器上的应用配置信息列表和应用运行信息列表获得对应的应用的服务地址，根据所获得的服务地址将客户端请求消息分发给对应的应用服务所在的应用服务器。

6.根据权利要求5所述的方法，其特征在于，所述代理服务器根据应用的描述信息创建应用上下文包括：

代理服务器在接收到客户端请求消息时，从客户端请求消息中提取请求参数，查询中心服务器中的应用配置信息列表，查找出请求参数与元数据标注字段符合的应用配置信息列表项，然后根据该应用配置信息列表项中的元数据标注字段中的关于加载应用上下文的信息，创建应用上下文。

7.根据权利要求5所述的方法，其特征在于，所述中心服务器上还保存资源列表；资源列表包括如下信息：资源名称、资源类型、应用上下文类型、定位算法名称和定位算法参数；

所述应用处理客户端请求消息所请求的任务，根据所述应用上下文进行数据资源定位包括：应用在接收到客户端请求消息后，在完成该客户端请求消息所请求的任务的过程中根据应用上下文以及资源列表中的对应信息进行资源定位。

8.根据权利要求5所述的方法，其特征在于，所述代理服务器在接收到客户端请求消息时，对客户端请求消息进行解析，通过查询中心服务器上的应用配置信息列表识别所述客户端请求消息所对应的应用包括：

代理服务器在接收到HTTP请求消息时，根据该请求消息中的统一资源定位符URL，查找出中心服务器上的应用元数据标注字段包括有与所述URL一致信息的应用配置信息列表项，根据所查找出的应用配置信息列表项中的应用名称识别出该客户端请求消息所对应的应用；

或者，

代理服务器在接收到Rpc请求消息时，根据该请求消息中的远程调用服务名称，查找出中心服务器上应用名称字段与所述远程调用服务名称一致的应用配置信息列表项，根据所查找出的应用配置信息列表项中应用名称字段识别出该请求消息所对应的应用；

所述通过查询中心服务器上的应用配置信息列表和应用运行信息列表获得对应的应用的服务地址包括：代理服务器根据所查找出的应用配置信息列表项中的应用进程名，查找出中心服务器上的应用进程名称字段包含与所述应用进程名一致信息的应用运行信息列表项，从所查找出的应用运行信息列表项中获取应用的服务地址信息。

9.根据权利要求5所述的方法，其特征在于，该方法进一步包括：

将所述应用服务器集群中的多个应用服务器分为多个不同组；

在所述中心服务器上保存应用服务器列表和应用服务器分组列表；其中，应用服务器列表包括如下信息：应用服务器名称、应用服务器所属的分组名称和应用服务器地址；应用服务器分组列表包括：应用服务器分组名称和分组中的应用服务器描述信息；

中心服务器在接收到外部上传的应用时，根据外部指令将该应用部署到单个应用服务器上，或者部署到属于同一组的多个服务器上。