CN102427480A

CN102427480A - 一种多应用服务平台系统中的应用访问方法

Info

Publication number: CN102427480A
Application number: CN2011104603752A
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: 2012-04-25
Anticipated expiration: 2031-12-31
Also published as: CN102427480B

Abstract

本发明公开了一种多应用服务平台系统中的应用访问方法。在一个应用服务平台系统内：代理服务器接收客户端请求消息，确定对应的应用，创建应用上下文，在客户端请求消息中添加应用上下文后，将客户端请求消息分发给对应的应用所在的应用服务器；应用服务器在接收到代理服务器发送的客户端请求消息时，交给对应的应用进行处理；对应的应用处理该客户端请求消息，根据应用上下文进行数据资源定位，得出处理结果；应用服务器将处理结果经代理服务器返回给客户端；在各应用服务平台系统之间：通过网关对应用进行跨应用服务平台系统的访问。本发明的技术方案能降低应用平台系统的开发难度，提高部署的灵活性并降低部署的难度。

Description

一种多应用服务平台系统中的应用访问方法

技术领域

本发明涉及互联网技术领域，特别涉及一种多应用服务平台系统中的应用访问方法。

背景技术

在后台服务开发领域，大部分互联网应用和企业应用都会遇到系统规模变得日益复杂，并且系统规模日益增大后，开发成本和运维成本都急剧增高。

迫切需要一种解决方案，降低应用服务平台的开发难度，提高其部署的灵活性并降低部署的难度。

发明内容

本发明提供了一种多应用服务平台系统中的应用访问方法，本发明的技术方案能降低多应用平台系统的开发难度，提高部署的灵活性并降低部署的难度。

为达到上述目的，本发明的技术方案是这样实现的：

本发明公开了一种多应用服务平台系统中的应用访问方法，实现多个应用服务平台系统，在每个应用服务平台系统中设置代理服务器、计算应用服务系统和网关，且在云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系，该方法包括：

在一个应用服务平台系统内：

代理服务器接收客户端请求消息，对客户端请求消息进行解析，确定对应的应用，根据该应用的描述信息创建应用上下文，在所述客户端请求消息中添加应用上下文后，根据所述应用与应用服务器之间的对应关系将客户端请求消息分发给对应的应用所在的应用服务器；

所述云计算应用服务系统中的所述应用服务器在接收到代理服务器发送的客户端请求消息时，将该客户端请求消息交给对应的应用进行处理；

所述对应的应用处理该客户端请求消息所请求的任务，根据所述应用上下文进行数据资源定位，得出处理结果；

应用服务器将所述处理结果经代理服务器返回给客户端；

在各应用服务平台系统之间：通过网关对应用进行跨应用服务平台系统的访问。

由上述可见，针对大部分互联网应用和企业应用都会遇到系统规模变得日益复杂，并且规模日益增大后，开发成本和运维成本急剧增高的问题，本发明通过构建平台即服务的软件平台，将普遍的现有后台软件解决方案中按照服务角色进行拆分的方式，改为以细粒度的信令级别进行应用拆分，并且进行应用开发与部署的简单方式，降低了开发与部署的复杂度；另外，本发明通过引入应用上下文的概念，将复杂的资源定位与应用间的路由从开发者视角上隔离开，即支持了简洁的开发方式，又能够使平台适用于超大规模的服务器集群。并且通过增加网关的方案实现了应用的跨应用服务平台系统的访问。

附图说明

图1是本发明实施例中的一个应用服务平台系统的组网示意图；

图2是本发明实施例中的多应用服务平台系统的组网示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

图1是本发明实施例中的一个应用服务平台系统的组网示意图。图2是本发明实施例中的多应用服务平台系统的组网示意图。

在实际应用中，在跨IDC机房的环境下，每个机房中的部署结构均与前述的图1所示的结构一致。即每个IDC机房中都有一个图1所示的应用服务平台系统。这里每个IDC称为一个Site。各机房中的应用服务平台系统之间通过网关进行通信，如图2所示。

则本发明中的多应用服务平台系统中的应用访问方法包括：

实现多个应用服务平台系统，在每个应用服务平台系统中设置代理服务器、计算应用服务系统和网关，且在云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系；

在一个应用服务平台系统内：

应用服务器将所述处理结果经代理服务器返回给客户端；

以下对本发明中的应用访问方法进行详细说明。

应用服务平台系统内的应用访问

如图1所示，一个应用服务平台系统包括：代理服务器和云计算应用服务系统，其中，云计算应用服务系统中的应用服务器集群上负载并运行应用，并且云计算应用服务系统中保存有应用的描述信息以及应用与应用服务器之间的对应关系；

代理服务器，用于接收客户端请求消息，对客户端请求消息进行解析，确定对应的应用，根据该应用的描述信息创建应用上下文，在所述客户端请求消息中添加应用上下文后，根据所述应用与应用服务器之间的对应关系将客户端请求消息分发给对应的应用所在的应用服务器；接收应用服务器端返回的处理结果，并返回给客户端；

所述云计算应用服务系统中的所述应用服务器，用于在接收到代理服务器发送的客户端请求消息时，将该客户端请求消息交给对应的应用进行处理，并将处理结果返回给代理服务器；所述对应的应用处理该客户端请求消息所请求的任务，根据所述应用上下文进行数据资源定位，得出处理结果。

应用服务器将所述处理结果经代理服务器返回给客户端。

上述云计算应用服务系统中保存的应用与应用服务器之间的对应关系，采用表格保存，其中记录有应用进程名称和应用服务路径，即应用与应用服务器之间的对应关系。

本发明实施例中，云计算应用服务系统包括：中心服务器、资源服务器和由多个应用服务器组成的服务器集群，其中：

中心服务器，用于接收外部上传的应用，将应用的描述信息保存到应用配置信息列表中，创建所述应用与应用服务器之间的对应关系，并在对应的应用服务器上部署该应用，保存用于保存应用与应用服务器之间的对应关系的应用运行信息列表；

每个应用服务器，用于将所负载的应用的运行信息上传到中心服务器上的用于保存应用与应用服务器之间对应关系的应用运行信息列表中；

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

资源服务器，用于保存应用服务器上的各应用处理客户端请求消息所请求的任务时需要访问的数据资源；在本实施例中，资源服务器包括：数据库服务器、文件服务器和内存对象缓冲服务器。

代理服务器，用于接收客户端请求消息，通过查询中心服务器上的应用配置信息列表识别该客户端请求消息所对应的应用，然后通过查询中心服务器上的应用配置信息列表和应用运行信息列表获得对应的应用的服务地址，根据所获得的服务地址将客户端请求消息分发给对应的应用所在的应用服务器；接收应用服务器端返回的处理结果，并返回给客户端；

在本发明的一个实施例中，代理服务器包括：超文本传输协议HTTP代理服务器、初始会话SIP代理服务器和短信系统SMS代理服务器。其中，HTTP代理服务器负责分发HTTP应用，SIP代理服务器负责与客户端的SIP长连接，SMS代理服务器负责分发短信上行应用。

此外，云计算应用服务系统还包括与应用服务器集群连接的基础服务服务器(在图1中未画出该基础服务服务器)，用于提供平台内部需求的一些核心应用或独立应用。

在图1所示的应用服务平台系统中，所述代理服务器，用于在接收到客户端请求消息时，从客户端请求消息中提取请求参数，查询中心服务器中的应用配置信息列表，查找出请求参数与元数据标注字段符合的应用配置信息列表项，进而识别出对应的应用。

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

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

所述代理服务器，用于根据所查找出的应用配置信息列表项中的应用进程名，查找出中心服务器上的应用进程名称字段包含与所述应用进程名一致信息的应用运行信息列表项，从所查找出的应用运行信息列表项中获取应用服务的服务地址信息。并根据所述应用的服务地址信息将客户端请求消息分发给对应的应用所在的应用服务器。

所述代理服务器，根据所查找出的应用配置信息列表项中的元数据标注字段中的关于加载应用服务上下文信息，创建应用服务上下文。

在图1所示的应用服务平台系统中，中心服务器，进一步用于保存资源列表；资源列表包括如下信息：资源名称、资源类型、应用服务上下文类型、定位算法名称和定位算法参数；

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

可见，本发明这种由上述代理服务器、应用服务器集群、中心服务器和资源服务器构成的应用服务平台系统，将分散的服务器资源在逻辑上整合到一起，极大降低了应用的开发难度，提高了部署的灵活性并降低了部署的难度。

应用服务平台系统基于如下层次结构进行开发，具体来说代理服务器上代理服务器、基础服务及负载运行于应用服务器集群上的应用都基于如下层次结构进行开发：

开发基础框架类库(Framework)：基础框架类库提供基础核心功能与用于在特定业务领域进行定制的扩展接口；在基础框架类库中定义并实现多种应用组件AppBean基础类型，并且基础框架类库中预定义了应用上下文接口及基本应用上下文类型的实现，以提供基础核心功能；其中不同的AppBean基础类型对应不同类型的应用，用于不同类型信令的处理；基础框架类库提供的扩展接口具体用来在业务框架类库BizLibrary中扩展的新的AppBean基础类型和新的应用上下文。

根据业务特性，在基础框架类库的基础上开发为业务定制的业务框架类库(Biz Library)。业务框架类库还提供业务相关的扩展接口，用于扩展新的应用；

基于基础框架类库和业务框架类库，开发实现业务需求的应用、基础服务以及代理服务器。

应用依赖于Framework和Biz Library，实现业务需求。

基础服务依赖于Framework和Biz Library，提供基础服务。

代理服务器依赖于Framework和Biz Library，实现基于业务的路由与负载功能。

在本发明实施例中，提供了基于应用组件(AppBean)的应用开发模式。这里定义最小的开发及负载的粒度为AppBean，一个AppBean定义为实现一个微小粒度功能的应用程序。

一般情况下将应用定义到信令级别，定义到信令级别的应用的具体表现形式根据业务的不同，可以有多种，比如可以是一个特定的Http请求(如GET/default.do)，或一条特定的上行短信(FROM：13800138000；TO：10658000032；TEXT：HELLO)，或一条特定的SIP指令，或一条RPC指令(一个方法，不是一个接口)等等。

本发明实施例中，处理一条或者多条指令的应用，定义为AppBean，应用能够开发和部署的最小单位为AppBean，能够针对一条信令或多条信令开发AppBean，并将其部署到平台系统中，接受用户的请求，请求可能来自用户的客户端软件，浏览器，内部引用，或外部信令调用。

本发明实施例中，基于Java实现部分应用，AppBean被描述为一个接口(interface)，所有特定的AppBean都会从本接口派生，用以实现特定的方法，比如自安装机制、配置初始化、服务加载及服务卸载等。

AppBean是一个抽象接口，但应用开发时，必须从为特定信令处理设计的AppBean基础类型(BaseAppBeanTypes)进行派生。

在本发明实施例中，已实现的AppBean基础类型包括：处理HTTP请求的HttpAppBean、处理RPC请求的RemoteAppBean和处理定时任务的JobAppBean等。

每个特定的AppBean基础类型会处理特定形式的信令，应用开发人员需要选择合适的AppBean基础类型去实现自己的应用。AppBean基础类型不局限于上述的几种，在Biz Library的层面上可以扩展特定类型的BaseAppBeanType，并且实现特定类型处理的Proxy。

关于应用上下文(称为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不限于如上的几种，可以根据实际业务需求增加其他的标注，如后文中会提到的PeersSite。

基础AppBean类型(AppBeanBaseType)

在Framework中，实现一个AppBeanBaseType的步骤如下描述：

一个AppBeanBaseType包括以下组件及特性：

·AppBeanBaseType是一个抽象基类

·AppBeanBaseType必须添加标注AppBeanBaseType，这样才能被AppLoader识别到

·在AppBean中并没有定义处理业务的方法，但是在AppBeanBaseType中必须提供处理业务的抽象方法，提供给应用子类去实现

·应用时刻，AppBeanBaseType是单件，业务处理抽象方法中会传入本次业务运行的全部请求参数，与应答方法的事务抽象类，我们称之为AppTx

·AppTx一般情况下会绑定在一个AppContext上

·必须实现相应的AppHost类，AppHost类会实际触发AppBean的业务处理方法，AppHost会与AppBeanBaseType一起派生

·一般情况下需要实现负责分发此请求的AppBeanRouteManager以及处理应用的Proxy(独立代理服务)

在Framework中实现了几个基础的AppBeanBaseType，但是应用可使用的AppBean并不限于下面的几个类型，还可以在Biz Library层次上进行扩展。

1.HttpAppBean(超文本传输协议应用组件)

HttpAppBean用于处理一条特定的Http请求，Http请求可能来自于来自用户客户端浏览器或程序的直接请求，请求会通过Http Proxy的智能7层负载转发到应用进程上。Http请求也可能来源于其他服务器的请求。

HttpAppBean<C extends AppContext>是一个泛型类，其中泛型参数解释如下：

·上下文<C>：特定类型的上下文

·Context来源：从何处获取上下文C；

·URL前缀：此应用处理的URL前缀(URL前缀通过HttpPrefix元数据标注处理)

HttpAppBean通过标注来指明自己所处理的请求UrlPrefix(前缀)，例如，开发一个用于最简单的HttpAppBean的步骤大致如下：

1.从HttpAppBean的基类派生

HttpPrefix(“/Hello”)

AppName(category＝”example”name＝”hello”)

class Hello WorldAppBean extends HttpAppBean<NullContext>()

2.指定上下文类型<C>，为NullContext，即不需要上下文；

3.通过HttpPrefix标注，表示用于处理发到HttpPrefix标注的地址的请求；

4.通过AppName标注，表示本应用的目录为example，名称为hello；

5.实现process()方法，process()方法为HttpAppBean中定义的抽象方法，读取上HttpRequest，处理后，返回HttpResponse给客户端。

例如：开发一个用于用户统一登录认证的应用的流程为：

1.从HttpAppBean的基类派生；

2.指定应用服务上下文类型C为SessionContext；

3.指定Context来源为cookie中的ssic字段；

4.实现process方法，读取HttpRequest，处理后返回HttpResponse给客户端。

2.RemoteAppBean(远程调用应用组件)

RemoteAppBean从AppBean派生，用来处理一个特定的Rpc请求，Rpc请求可能来源于下列几个场景

·来源于其他AppBean的调用，可能是任意来源类型；

·来源于其proxy；

·来源于其他外部服务调用。

RemoteAppBean是一个泛型类，其中泛型参数解释如下：

·<A>：请求参数，强类型定义，可序列化；

·<R>：应答参数，强类型定义，可序列化；

·<C>：特定类型的应用上下文。

实现一个RemoteAppBean必须提供确定的下述类型，例如开发一个处理获取用户资料的RemoteAppBean的步骤如下：

1.从RemoteAppBean的基类派生

AppName(category＝”example”，name＝”GetUserInfo”)

class GetUserInfo extends RemoteAppBean<GetOption，UserInfo，NullContext>

2.定义请求参数类型<A>为GetOption，GetOption为可序列化类，保存获取用户的id及选项参数；

3.定义应答参数类型<R>为UserInfo，UserInfo为可序列化类，保存用户信息；

4.定义上下文<C>为NullContext，本案例中不需要上下文；

5.继承后实现process()方法用于处理业务逻辑，继承load()方法用与初始化，继承unload()方法卸载，继承setup()方法实现自安装。

当调用一个RemoteAppBean时必须提供这个RemoteAppBean在实现时所声明的特定类型的应用上下文(AppContext)。

一个获取用户信息的应用会如下声明：

1.从RemoteAppBean GetOption，UserInfo，UserContext 中派生；

a.请求参数A为GetOption，为获取用户的一些选项参数

b.应答参数R为UserInfo，为用户信息的集合

c.应用上下文C为UserContext，为当前上下文的用户信息，UserContext用于标识用户ID

2.实现process方法处理业务逻辑

3.JobAppBean(任务应用组件)

JobAppBean从AppBean派生，用来处理一个定时任务，并且可以在全局中保证定时任务在某个资源上独占运行。

实现一个JobAppBean的步骤如下

1.从JobAppBean的基类派生

JobSchedule(cron＝”*/5****”)

JobResource(resource＝”USERDB”，parallel true)

AppName(category＝”example”，name＝”GetUserInfo”)

class GetUserJobApp extends JobAppBean

2.定义Job的运行时间，其中Job的运行时间按照Corn表达式中表述的时间运行

3.定义Job将要独占的资源，关于资源的定义请见下一节，绑定资源后，平台系统中的JobAppBean在针对此资源时将不会重复运行。

基于AppContext的资源访问定位

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

比如，声明一个获取用户信息的应用，名为GetUserInfo App，在应用的实现环节读取用户数据库(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所示，每个IDC中都有一个图1所示的应用服务平台系统，在每个应用服务平台系统中增加一个网关，各应用服务平台系统之间通过网关进行通信。网关之间可以采用专线通讯，或者采用压缩、加密后的公网通信。

可见网关与其他应用服务平台系统中的网关进行通信，实现应用的跨应用服务平台系统访问。具体来说，在每个应用服务平台系统中：

中心服务器，用于查找出本应用服务平台系统中部署的需要跨平台访问的应用所对应的应用配置信息列表项，并发送给本应用服务平台系统的网关；

网关，用于将所接收的对应应用配置信息列表项信息发送给其他应用服务平台系统中的网关；用于接收其他应用服务平台系统中的网关发送的应用配置信息列表项，并对本中心服务器上的本地应用配置信息列表做如下处理：

对于所接收的每个应用配置信息列表项，如果本地的应用配置信息列表中存在对应的项，且其中的应用进程名称不为网关，则忽略，如果本地的应用配置信息列表中不存在对应的项或者存在但其中的应用进程名为网关，则用接收的应用配置信息列表项更新本地的应用配置信息列表，并在更新后的应用配置信息列表项中增加远程系统字段，将该字段的值设置为所接收应用配置信息列表项的来源系统。

当要跨应用服务平台系统访问应用时：

网关首先从本应用服务平台系统的中心服务器获取对应的应用配置信息列表项，查看对应的应用配置信息列表项中的应用元数据标注中是否包含对等系统标注；如果包含对等系统标注，则根据该应用的应用上下文确定目标应用服务平台系统；如果不包含对等系统标注，则通过该对应的应用配置信息列表项中的远程系统字段确定目标应用服务平台系统；根据所确定的目标应用服务平台系统获知该目标应用服务平台系统的网关的地址，并将应用访问请求转发到目标应用服务平台系统的网关；

所述网关还用于在接收到其他应用服务平台系统的网关发送的应用访问请求后，根据本应用服务平台系统内的中心服务器上的应用配置信息列表和应用运行信息列表，将请求转发到相应的应用。

在本发明中，将只承载与本应用服务平台系统内的用户相关的数据和应用的应用服务平台系统定义为对等系统(PeerSite)；将承载本应用服务平台系统内的用户以及其他应用服务平台系统用户的数据和应用的应用服务平台系统定义为非对等系统(NonPeerSite)；

根据前面的定义，AppContext中额外存在一个GetSiteName()方法，可以获取上下文所属的PeerSite。

下面以RemoteAppBean为例对应用的跨应用服务平台系统的访问进行说明。

RemoteAppBean的跨Site(即跨应用服务平台系统)访问

在本发明的实施例中，RemoteAppBean的跨Site访问的方法如下：

1.如果一个RemoteAppBean只与一个PeerSite中的用户相关，则在该RemoteAppBean的应用元数据标注中增加对等系统标注；如果一个RemoteAppBean不与特定PeerSite中的用户相关，则该RemoteAppBean的应用元数据标注中不增加对等系统标注；

即RemoteAppBean存在一个额外的标注PeerSite；其中PeerSite的定义如下：如果该应用是用户相关的，必须部署到用户所属的PeerSite当中去，那么必须增加标注PeerSite；如果该RemoetAppBean在多个Site中的部署不是用户相关的，则不需要标注PeerSite。

2.通过网关将不与特定对等系统中的用户相关的各RemoteAppBean的路由信息在各个应用服务平台系统间进行同步；

3.根据所同步的路由信息实现不与特定对等系统中的用户相关的RemoteAppBean的跨应用服务平台系统的访问。

多个Site之间的路由表的同步方式

网关负责不同Site间的RemoteAppBean的路由，因为本系统中AppBean的路由是动态的(应用配置信息列表以及应用运行信息列表)，所以在多个Site间，路由的同步是动态执行的。

通过网关将不与特定PeerSite中的用户相关的各RemoteAppBean的路由信息在各个应用服务平台系统间进行同步包括：

每个应用服务平台系统中的中心服务器查找出本应用服务平台系统中部署的应用元数据标注中不包含对等系统标注PeerSite的RemoteAppBean，作为需要同步的RemoteAppBean(标注为PeerSite的RemoteAppBean不进行同步)，并将需要同步的RemoteAppBean的对应应用配置信息列表项发送给本应用服务平台系统的网关，本应用服务平台系统的网关将所接收的对应应用配置信息列表项信息发送给其他各应用服务平台系统中的网关；

接收到所述对应应用配置信息列表项的网关做如下处理：对于所接收的每个应用配置信息列表项，如果本地的应用配置信息列表中存在对应的项，且其中的应用进程名称不为网关，则忽略，如果本地的应用配置信息列表中不存在对应的项或者存在但其中的应用进程名为网关，则用接收的应用配置信息列表项更新本地的应用配置信息列表，并在更新后的应用配置信息列表项中增加远程系统RemoteSite字段，将该字段的值设置为所接收应用配置信息列表项的来源系统。

可见，网关会在各个Site间同步各个Site中部署的非PeerSite类型的RemoteAppBean的路由数据，当寻找RemoteAppBean的路由地址时，可以找到RemoteAppBean的对应网关。

RemoteAppBean的路由步骤

根据所同步的路由信息实现不与特定对等系统PeerSit中的用户相关的RemoteAppBean的跨应用服务平台系统的访问包括：

1.当要访问不与特定对等系统中的用户相关的RemoteAppBean时，首先从本应用服务平台系统的中心服务器获取对应的应用配置信息列表项；

2.查看对应的应用配置信息列表项中的应用元数据标注中是否包含对等系统标注PeerSite；

如果包含对等系统标注PeerSite，则通过该RemoteAppBean的应用上下文确定目标应用服务平台系统；

如果不包含对等系统标注PeerSite，则通过该对应的应用配置信息列表项中的远程系统RemoteSite字段确定目标应用服务平台系统；

3.根据所确定的目标应用服务平台系统获知该目标应用服务平台系统的网关的地址，并将访问请求通过本应用服务平台系统的网关转发到目标应用服务平台系统的网关；

4.目标应用服务平台系统的网关接收到所述访问请求后，根据本系统内的中心服务器上的应用配置信息列表和应用运行信息列表，将请求转发到相应的RemoteAppBean。

由上述可见，本发明这种由上述代理服务器、应用服务器集群、中心服务器和资源服务器构成的应用服务平台系统，将分散的服务器资源在逻辑上整合到一起，并且面向单个信令的应用开发，以及基于基础框架类库和业务框架类库的开发方式极大降低了应用的开发难度，提高了部署的灵活性并降低了部署的难度。

综上所述，针对大部分互联网应用和企业应用都会遇到系统规模变得日益复杂，并且规模日益增大后，开发成本和运维成本急剧增高的问题，本发明通过构建平台即服务的软件平台，将普遍的现有后台软件解决方案中按照服务角色进行拆分的方式，改为以细粒度的信令级别进行应用拆分，并且进行应用开发与部署的简单方式，降低了开发与部署的复杂度；另外，本发明通过引入应用上下文的概念，将复杂的资源定位与应用间的路由从开发者视角上隔离开，即支持了简洁的开发方式，又能够使平台适用于超大规模的服务器集群。并且通过增加网关的方案实现了应用的跨应用服务平台系统的访问。

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

Claims

1.一种多应用服务平台系统中的应用访问方法，其特征在于，实现多个应用服务平台系统，在每个应用服务平台系统中设置代理服务器、计算应用服务系统和网关，且在云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系，该方法包括：

在一个应用服务平台系统内：

应用服务器将所述处理结果经代理服务器返回给客户端；

2.根据权利要求1所述的方法，其特征在于，在每个应用服务平台系统中：

云计算应用服务系统包括：中心服务器、资源服务器和由多个应用服务器组成的应用服务器集群；其中，在资源服务器上保存应用服务器上的各应用处理客户端请求消息所请求的任务时需要访问的数据资源；

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

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

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

所述代理服务器接收客户端请求消息，对客户端请求消息进行解析，确定对应的应用，以及所述根据应用与应用服务器之间的对应关系将客户端请求消息分发给对应的应用所在的应用服务器包括：代理服务器在接收到客户端请求消息时，对客户端请求消息进行解析，通过查询中心服务器上的应用配置信息列表识别所述客户端请求消息所对应的应用，通过查询中心服务器上的应用配置信息列表和应用运行信息列表获得对应的应用的服务地址，根据所获得的服务地址将客户端请求消息分发给对应的应用服务所在的应用服务器。

3.根据权利要求2所述的方法，其特征在于，

各应用服务平台系统之间通过网关进行通信；

将只承载与本应用服务平台系统内的用户相关的数据和应用的应用服务平台系统定义为对等系统；将承载本应用服务平台系统内的用户以及其他用户的数据和应用的应用服务平台系统定义为非对等系统。

4.根据权利要求3所述的方法，其特征在于，所述通过网关对应用进行跨应用服务平台系统的访问包括：

如果一个应用只与一个对等系统中的用户相关，则在该应用的应用元数据标注中增加对等系统标注；如果一个应用不与特定对等系统中的用户相关，则该应用的应用元数据标注中不增加对等系统标注；

通过网关将不与特定对等系统中的用户相关的各应用的路由信息在各个应用服务平台系统间进行同步；

根据所同步的路由信息实现不与特定对等系统中的用户相关的应用的跨应用服务平台系统的访问。

5.根据权利要求4所述的方法，其特征在于，所述通过网关将不与特定对等系统中的用户相关的各应用的路由信息在各个应用服务平台系统间进行同步包括：

每个应用服务平台系统中的中心服务器查找出本应用服务平台系统中部署的应用元数据标注中不包括对等系统标注的应用，作为需要同步的应用，并将需要同步的应用的对应应用配置信息列表项发送给本应用服务平台系统的网关，本应用服务平台系统的网关将所接收的对应应用配置信息列表项信息发送给其他各应用服务平台系统中的网关；

接收到所述对应应用配置信息列表项的网关做如下处理：对于所接收的每个应用配置信息列表项，如果本地的应用配置信息列表中存在对应的项，且其中的应用进程名称不为网关，则忽略，如果本地的应用配置信息列表中不存在对应的项或者存在但其中的应用进程名为网关，则用接收的应用配置信息列表项更新本地的应用配置信息列表，并在更新后的应用配置信息列表项中增加远程系统字段，将该字段的值设置为所接收应用配置信息列表项的来源系统。

6.根据权利要求5所述的方法，其特征在于，所述根据所同步的路由信息实现不与特定对等系统中的用户相关的应用的跨应用服务平台系统的访问包括：

当要访问不与特定对等系统中的用户相关的应用时，首先从本应用服务平台系统的中心服务器获取对应的应用配置信息列表项；

查看对应的应用配置信息列表项中的应用元数据标注中是否包含对等系统标注；

如果包含对等系统标注，则通过根据该应用的应用上下文确定目标应用服务平台系统；

如果不包含对等系统标注，则通过该对应的应用配置信息列表项中的远程系统字段确定目标应用服务平台系统；

根据所确定的目标应用服务平台系统获知该目标应用服务平台系统的网关的地址，并将访问请求通过本应用服务平台系统的网关转发到目标应用服务平台系统的网关；

目标应用服务平台系统的网关接收到所述访问请求后根据本系统内的中心服务器上的应用配置信息列表和应用运行信息列表，将请求转发到相应的应用。

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

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

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

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

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

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

或者，

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

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

10.根据权利要求2至6中任一项所述的方法，其特征在于，所述应用服务平台系统基于如下层次结构进行开发：

开发基础框架类库，所述基础框架类库中定义多种应用组件AppBean基础类型、应用上下文接口及基本应用上下文类型的实现，以提供基础核心功能；其中不同的AppBean基础类型对应不同类型的应用，用于处理不同类型的信令；

根据业务特性，在基础框架类库的基础上开发为业务定制的业务框架类库；

基于基础框架类库和业务框架类库，开发实现业务需求的应用；以及，基于基础框架类库和业务框架类库，实现代理服务器基于业务的路由与负载功能。