一种应用开发方法和运行该方法所开发应用的平台系统

技术领域

本发明涉及互联网技术领域，特别涉及一种应用开发方法和运行该方法所开发应用的平台系统。

背景技术

目前，大部分互联网应用和企业应用都会遇到系统规模变得日益复杂并且系统规模增大后，应用的开发也变得异常复杂。例如，现有的应用的开发模式需要关心复杂的服务器端的分层结构、者数据的拆分、访问其他服务的接口、负载等等。

因此有必要提出一种应用开发模式，来使应用的开发变得简单轻松。

发明内容

本发明提供了一种应用开发方法和运行该方法所开发应用的平台系统，以解决现有的应用开发过程复杂的问题

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

本发明公开了一种应用开发方法，其特征在于，该方法包括：将应用开发拆分到单个信令级别，并且基于如下层次结构进行应用开发：

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

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

基于基础框架类库和业务框架类库，开发实现业务需求的应用；其中，该开发的应用基于应用上下文进行资源访问。

本发明还公开了一种运行根据上述方法开发的应用的平台系统，该系统包括：代理服务器和云计算应用服务系统，其中，云计算应用服务系统中的应用服务器集群上负载并运行应用，并且云计算应用服务系统中保存有应用的描述信息以及应用与应用服务器之间的对应关系；

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

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

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

附图说明

图1是本发明实施例中的运行应用的平台系统的逻辑结构示意图；

图2是本发明实施例中的运行应用的平台系统的一个实际组网示意图；

图3是本发明实施例中的应用开发的层次结构示意图。

具体实施方式

本发明中的应用开发方法包括：将应用开发拆分到单个信令级别，并且基于如下层次结构进行应用开发：

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

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

基于基础框架类库和业务框架类库，开发实现业务需求的应用；其中，该开发的应用基于应用上下文进行资源访问。

在本发明中，将应用开发拆分到单个信令的级别，并且设计出应用上下文的概念，将应用中的资源访问及应用的路由绑定在应用上下文上，简化了应用的难度。

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

图1是本发明实施例中的运行应用的平台系统的逻辑结构示意图。在应用服务平台系统中设置代理服务器和云计算应用服务系统，其中，代理服务器中设置代理逻辑部分，云计算应用服务系统中设置应用服务器集群、基础服务、资源、中心等逻辑部分。在图1中，各逻辑部分的描述如下：

※代理(Proxy)

-用于分发客户端的消息，并维护客户端状态(如长连接)；

-代理服务：

·SIP Proxy：维护与客户端的SIP长连接；

·HTTP Proxy：负责分发Http应用；

·SMS Proxy：负责分发短信上行应用；

※应用服务器集群(AppEngine Hosts)

-负载实际的应用服务运行，可进行服务器分组；

※基础服务(Basic Service)

-平台内部需求的一些核心应用或独立应用；

※资源(Resource)

-提供给平台使用的系统资源，如：

·数据库(Database)  ·文件(File)  ·内存对象缓冲服务器(Memcache)

※中心(Center)

-整个系统的管控中心，用于看管所用应用服务的部署、分发、更新等系统管理操作。

图2是本发明实施例中的运行应用的平台系统的一个实际组网示意图。如图2所示，该平台系统包括：代理服务器和云计算应用服务系统，其中，云计算应用服务系统中的应用服务器集群上负载并运行应用，并且云计算应用服务系统中保存有应用的描述信息以及应用与应用服务器之间的对应关系；

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

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

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

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

针对上述图1所示逻辑架构，本发明实施例中，云计算应用服务系统包括：中心服务器、资源服务器和由多个应用服务器组成的服务器集群，其中：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图3是本发明实施例中的应用开发的层次结构示意图。如图3所示，代理服务器上代理服务器、基础服务及负载运行于应用服务器集群上的应用都基于如下层次结构进行开发：

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

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

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

应用依赖于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基础类型不局限于上述的几种，在BizLibrary的层面上可以扩展特定类型的BaseAppBeanType，并且实现特定类型处理的Proxy。

本发明中不仅将开发模式拆分为面向单独信令，并且将信令与应用上下文绑定在一起，应用上下文称为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参数，如：

-设置群组名称；  -更新群组权限；  -获取群离线消息等。

在发明中，开发一个应用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(HTTP前缀/事件名称)

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当中，通过处理Http Request中的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 HelloWorldAppBean 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(coron＝”*/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上。

比如，声明一个获取用户信息的应用，名为GetUserInfoApp，在应用的实现环节读取用户数据库(UserDB)，将结果返回。其中UserDB存在多个通过用户id进行取模后进行纵向拆分的实例。

那么具体过程如下：

1.代理服务器Http Proxy接收到来自于客户端的Http请求；

2.Http Proxy通过Http请求的URL判断该请求对应的应用；具体为Http Proxy通过访问中心服务器上的应用配置信息列表，找到元数据标注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>参数

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

AppBean基于业务框架类库BizLibrary的扩展方法

在本发明中，当需要开发新类型的应用时：通过基础框架类库Framework提供的扩展接口在业务框架类库BizLibrary中扩展与该新类型应用对应的AppBean基础类型，以及在业务框架类库BizLibrary中扩展针对该新类型应用的应用上下文。然后可以基于基于Framework和BizLibrary开发出相应的代理服务器，最后就可以在此基础上进行新应用的开发。

例如：当开发一个短信服务系统时，我们可以单独基于短信扩展出短信类型的AppBean基础类型：SmsAppBean，并相应的开发出用于分发短信的Sms Proxy，并且开发出基于短信用户的UserContext，当完成这三项后，平台的应用可以基于用户及短信指令的方式进行开发，其中拓展点如下所述：

·拓展AppBean及Proxy可以让平台获取支持任意信令的能力；

·拓展AppContext可以让平台支持几乎任意数据类型的业务系统。

AppBean的扩展示例：SipAppBean

如果在一个基于SIP的IM平台中，考虑应用本系统，把SIP信令的PROTOCOL，METHOD，EVENT作为一个区分SIP信令的标示，那么在此基础上，我们可以设计一个SipAppBean，用于处理来自客户端的SIP请求。那么实现一个SipAppBean的步骤如下：

1.派生自AppBean；

2.设计标识SipMethod(protocol＝″V1″，method＝”SERVICE”，event＝”GetUserInfo”)标示此SipAppBean处理的信令类型；

3.设计标识SipMethods(SipcMethod[]methods)允许一个SipAppBean处理多个请求；

4.设计SipAppHost类，打开SIP端口，监听所有的SIP请求，并分发到具体的应用的SipAppBean上，分发的依据是AppName，为PROXY层面添加；

5.实际SipTx事务类，将请求，应答，上下文包装在其中；

6.在SipAppBean上设计通用的处理信令的抽象方法；

7.SipcAppHost产生SipTx，并转发到SipAppBean的抽象方法上。

这样，我们就可以为每一个SIP信令开发应用了，同时我们会实现一个SIP PROXY客户端会与SIP PROXY保持一个长连接，并且登录有SIP PROXY会保持用户的一些基本状态，并在后续的应用中传给后续的应用，其中每个应用需要的上下文，可以通过扩展AppContext实现。

AppContext的扩展示例：UserContext

在上文的描述中，我们针对每个IM用户扩展一个AppContext，称为UserContext，根据前文，我们需要实现UserContext的两个部分：

1.ContextUri：

我们定义ContextUri为id：332132132，表示用户的id

2.ContextData：

定义ContextData包括如下数据：NickName昵称、Age年龄、ClientType客户端类型、ClientVersion客户端版本号、ClientCaps客户端能力、Region用户所属地区。

基于上面的设计，SIP PROXY会将从用户保存的会话中将信息提取出来，并发送到的应用的对应应用进程上，这样应用进程会从请求信息中拿到UserContext并分发到实际的应用上，这样应用就能实际的拿到UserContext并进行资源访问等处理。

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

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

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

表3

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

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

表4

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

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

因此在本发明的一个实施例中，应用服务器集群中的多个应用服务器被分为多个不同组；所述中心服务器上保存有应用服务器列表和应用服务器分组列表；

应用服务器列表包括如下信息：应用服务器名称、应用服务器所属的分组名称和应用服务器地址；

应用服务器分组列表包括：应用服务器分组名称和分组中的应用服务器描述信息；

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

综上所述，本发明通将普遍的现有后台软件解决方案中按照服务角色进行拆分的方式，改为以细粒度的信令级别进行应用拆分，并且进行应用开发的简单方式，降低了开发的复杂度；另外，本发明通过引入应用上下文的概念，将复杂的资源定位与应用问的路由从开发者视角上隔离开，即支持了简洁的开发方式，又能够使平台适用于超大规模的服务器集群。

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