CN103283209B - 一种应用服务平台系统及其实现方法 - Google Patents

Abstract

本发明公开了一种应用服务平台系统及其实现方法。在应用服务平台系统中设置代理服务器和云计算应用服务系统；在云计算应用服务系统中的应用服务器集群上负载并运行应用，并且在云计算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系；代理服务器接收客户端请求消息，根据应用的描述信息创建应用上下文，在所述客户端请求消息中添加应用上下文后，根据所述应用与应用服务器之间的对应关系将客户端请求消息分发给对应的应用所在的应用服务器；应用服务器将该客户端请求消息交给对应的应用进行处理；对应的应用根据应用上下文进行数据资源定位。本发明的技术方案降低了应用开发的难度，提高了部署的灵活性并降低了部署的难度。

Description

一种应用服务平台系统及其实现方法

技术领域

本发明涉及互联网领域，具体涉及一种应用服务平台系统及其实现方法。

发明背景

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

本发明致力于降低应用开发难度，提高部署的灵活性并降低部署的难度。

发明内容

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

为解决上述技术问题，本发明的技术方案是这样实现的：

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

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

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

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

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

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

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

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

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

附图简要说明

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

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

图3是本发明实施例中的相关应用开发的层次结构图；

图4是本发明实施例中的单个应用服务器的内部结构以及与外部的连接示意图；

图5是本发明实施例中的应用进程启动过程的流程图；

图6是本发明实施例中的应用进程停止过程的流程图；

图7是本发明实施例中的应用进程更新过程的流程图；

图8是本发明实施例中的应用进程热更新的流程图；

图9是本发明实施例中的全局配置系统的示意图；

图10是本发明实施例中的监控系统的示意图；

图11是本发明实施例中的程序内嵌计数器的实现方式示意图；

图12是本发明实施例中的注入式调试系统的示意图；

图13是本发明实施例中的多个应用服务平台系统的结构示意图。

实施本发明的方式

本发明是一套基于集群PC服务器环境的应用服务开发平台，具体实现中，应用可以基于Java运行环境但是并不局限于Java语言，本发明将分散的服务器资源在逻辑上整合为一个整体的应用平台，负载基于平台进行开发的应用。

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

本发明通过代理服务器Proxys进行路由，并通过应用服务器AppServer进行应用负载，并且构建了一套整体可运维，可监控的服务器集群平台。

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。

一、整体概述

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

※代理(Proxy)

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

-代理服务：

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

·HTTPProxy：负责分发Http应用；

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

※应用服务器集群(AppEngineHosts)

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

※基础服务(BasicService)

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

※资源(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和BizLibrary，实现业务需求。

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

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

在本发明实施例中，提供了基于应用组件(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(当前用户)进行开发，访问资源(数据库，文件，缓存)都必须通过当前的AppContext，这样开发者可以不用管理数据库，文件，缓存等的拆分问题，甚至用户数据的跨机房问题，只关基于当前用户进行开发即可，极大的简化了开发模式，将系统部署结构与开发过程隔离开来，实现高效，便捷的PaaS平台。

AppContext从数据构成上分为两部分，AppContext是可序列化与反序列化的：

(1)通用资源标志符URI(ContextUri)：为字符串格式，包括用户的索引信息，负责后续的定位，如id：230302023；session：13910000001。

(2)附加数据(ContextData)：是预定义好的强类型数据结构，可以包含多个字段；其包括该应用的属性信息；应用的属性信息包括：会话参数、授权信息等；

在某些场合，附加数据会由Proxy产生提供给后面应用，在长连接的Proxy服务器场景(参见Proxys章节)。

支持getNamedValue(StringfieldName)方法，可以获取到一个特定字段名的数据，此方法被用于灰度发布场合(见后文)。

AppContext是抽象基类，在Framework中预定义了以下的AppContext子类：

NullContext：预定义的空上下文，用在不需要上下文的场合；

SessionContext：预定义的只保存会话Id的上下文。

在复杂应用中，一般会在RizLibrary中扩展特定的AppContext，比如一个IM系统，在SIPProxy上会保存用户的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请求。

MessageName(事件名称，只针对MessageAppBean)

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

·如：MessageName

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并不限于下面的几个类型，还可以在BizLibrary层次上进行扩展。

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

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

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

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

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

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

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

1.从HttpAppBean的基类派生

HttpPrefix(“/Hello”)

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

classHelloWorldAppBeanextendsHttpAppBean<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＝”GetUserlnfo”)

classGetUserInfoextendsRemoteAppBean<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>为UserConrext，为当前上下文的用户信息，UserContext用于标识用户ID

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

3.JobAppBean(任务应用组件)

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

实现一个JobAppBean的步骤如下

1.从JobAppBean的基类派生

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

JobResource(resource＝”USERDB”，parallel＝true)

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

classGetUserJobAppextendsJobAppBean

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

3.定义Job将要独占的资源，关于资源的定义请见下一节，绑定资源后，平台系统中的

JobAppBean在针对此资源时将不会重复运行。

基于AppContext的资源访问定位

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

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

那么具体过程如下：

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

2.HttpProxy通过Http请求的URL判断该请求对应的应用；具体为HttpProxy通过访问中心服务器上的应用配置信息列表，找到元数据标注Annotations字段中的HttpPrefix与Http请求的URL一致的应用配置信息列表项，该表项对应的应用即为该Http请求所对应的应用；

3.HttpProxy通过步骤2识别该请求是GetUserInfoApp的请求，并需要UserContext作为上下文参数；

4.HttpProrxy根据应用配置信息表项中的Annotations字段中的ContextLoader，以及Http请求报文中提取的相关信息创建UserContext；

5.HttpProxy在来自客户端的Http请求中添加了UserContext数据后将Http请求转发到GetUserInfoApp所在的应用服务器；这里通过查询应用运行信息列表获得GetUserInfoAPP的服务地址。

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

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

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

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

在上述过程的步骤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基于业务框架类库RizLibrary的扩展方法

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

例如：当开发一个短信服务系统时，我们可以单独基于短信扩展出短信类型的AppBean基础类型：SmsAppBean，并相应的开发出用于分发短信的SmsProxy，并且开发出基于短信用户的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信令开发应用了，同时我们会实现一个SIPPROXY客户端会与SIPPROXY保持一个长连接，并且登录有SIPPROXY会保持用户的一些基本状态，并在后续的应用中传给后续的应用，其中每个应用需要的上下文，可以通过扩展AppContext实现。

AppContext的扩展示例：UserContext

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

1.ContextUri：

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

2.ContextData：

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

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

二、应用的部署、运维和路由

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

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

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

表3

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

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

表4

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

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

图4是本发明实施例中的单个应用服务器的内部结构以及与外部的连接示意图。其中，中心服务器将应用部署到应用服务器集群中的应用服务器上包括：

在每个应用服务器上部署一个守护进程；在中心服务器上保存应用进程列表；该应用进程列表包括：应用进程标识、动态端口标记、应用服务器名称、应用服务器分组名称、部署包接口和服务端口；

中心服务器根据应用服务器列表、应用服务器分组列表和应用进程列表中的信息，确定每个应用服务器上应启动的应用进程部署信息列表；该应用进程部署信息列表包括：应用进程标识、动态端口标记、部署包接口和服务端口；

每个应用服务器上的守护进程启动后，与中心服务器建立连接并保持心跳，从中心服务器获取本应用服务器的应用进程部署信息列表，根据该应用进程部署信息列表下载并启动本应用服务器的应用进程；

每个启动的应用进程都与中心服务器建立连接并保持心跳；

中心服务器为每个建立连接的守护进程在守护进程状态信息列表中记录其连接信息，以及为每个建立连接的应用进程在应用运行信息列表中保存记录其连接信息。

如图4所示，守护进程(Master)是部署在每台应用服务器上的后台监控进程，负责进行应用服务的下载运行与部署。每个应用服务器上部署一个守护进程，守护进程会与中心服务器建立一个长连接，通过这个长连接接受部署、更新、监控等系统指令。在一个应用服务器中几个应用服务可以运行在一个应用进程(Worker)中，该应用进程也可以称为服务外壳。一个应用服务器上可以有多个应用进程。

应用的部署

在本发明中，开发完成的应用会部署到服务器集群中的应用服务器上运行，并将代理服务器针对此应用的路由定制到负载该应用的应用服务器上。

开发人员将开发完成的应用的代码进行编译，生成用于部署的JAVA应用发布(jar包)，也称为部署包。在本发明的一个实施例中，一种可能的jar包的分布如下：Framework.jar，BizLibrary.jar，App1.jar，App2.jar。其中App1，App2的jar包中包括实际能运行的AppBean，而在Framework及BizLibrary中存在BaseAppBeanType，并且在jar包的资源文件中有存在META-INF/appbean.properties配置。以上的jar包会打为一个tar.gz包，作为部署的发布包。

运维人员使用加载工具，一般为AppLoader，AppLoader会通过java的反射机制提取所有开发者实现的AppBean，提取步骤如下：

1.遍历压缩包中的所有的jar包；

2.通过寻找资源文件中的配置，跳过非应用jar包；

3.遍历应用jar包中的所有class；

4.跳过未实现AppBean接口的类；

5.跳过abstractclass递归遍历class的基类，当基类上能够找到annotation：AppBeanBaseType时；

6.将AppBeanType，BaseType以及应用Class上的所有Annotation都转换为JSON字符串。

通过上述步骤分析得到的数据保存到应用组件列表和应用包列表中。

在本发明的实施例中应用组件列表和应用包列表分别如表5和表6所示，

表5

表6

根据应用组件列表和应用包列表中的信息生成应用配置信息列表。应用配置信息列表(又称为Application表)如表7所示：

表7

在表3中，关于Annotations字段：AppLoader会通过分析Java应用类与应用类包含的元数据标注，并提取出每个AppBean的类型信息与元数据标注信息，并通过JSON(JavaScriptObjectNotation)格式的字符串保存在Application表的Annotations字段，具体格式如下：

Annotations字段包含classInfo子字段与classAnnotations子字段；

classInfo字段中包含，当前类型，基础类型，及基础类型的泛型参数；

classAnnotations字段包含该AppBean包含的每一个元数据标注，元数据标注的每个参数，通过”key”，“value”方式存储。

在表3中，除了WorkerPackage(应用服务部署包名称)、ServerGroup(应用服务器组)及Enabled(是否启用)字段，其余的字段的数据均由加载工具自动写入中心服务器中的应用配置信息列表中。这避免了人工写入的麻烦及错误风险。

运维人员选择应用服务部署包名称、应用服务器组以及是否启用的选项，更新Application表。

在本发明中，运行应用的应用进程也在全局统一配置，具体来说在中心服务上配置并保存应用进程列表，又称worker表，如表8所示：

表8

由中心服务器根据应用服务器列表(表3)、应用服务器分组列表(表4)和应用进程列表(表8)中的信息，确定每个应用服务器上应启动的应用进程部署信息列表，具体规则如下：

1.获取当前应用服务器的名称，以及其应用服务器分组名称；

2.在应用进程列表(表8)中，如果其应用服务器分组名称字段不为空，则在应用进程列表中寻找应用服务器分组名称字段包含当前应用服务器的应用服务器分组名称的记录；

3.在应用进程列表(表8)中，如果其应用服务器名称字段不为空，则在应用进程列表中寻找应用服务器名称字段包含当前应用服务器名称的记录；

4.将2、3步骤中的记录组合起来得到当前服务器上应该启动的应用进程的部署信息列表。

应用进程部署信息列表的每项包含如下信息：应用进程标识(WorkerID)、动态端口标记(IsDynamicPor)、部署包接口(PackageUrl)、服务端口(ServicePorts)。

每个应用服务器上的守护进程启动后，与中心服务器建立连接并保持心跳，从中心服务器获取本应用服务器的应用进程部署信息列表，根据该应用进程部署信息列表下载并启动本应用服务器的应用进程；每个启动的应用进程都与中心服务器建立连接并保持心跳；中心服务器为每个建立连接的守护进程在守护进程状态信息列表中记录其连接信息，及为每个建立连接的应用进程在应用运行信息列表中保存记录其连接信息。

守护进程(Master)的启动和注册

一个守护进程Master负责管理本应用服务器上的所有应用进程Worker，Master的启动注册步骤如下：

1.启动Master；

2.Master建立与中心服务器的TCP长连接，并监听来自中心服务器的命令；

3.不断与中心服务器保持心跳，上传应用服务器的运行状态；

4.通过TCP长连接从中心服务器获取本应用服务器的应用进程部署信息列表，启动相应的应用进程。

Master获取应用进程部署信息列表后，启动应用进程的过程如下：

1.通过应用进程部署信息列表中的PackageUrl下载应用进程运行包；

2.创建目录名为WorkerId+PackageName，将下载的应用进程运行包解压缩到WorkerId中；

3.从本地端口池中选择能用的端口选择能用的端口，从目录中的WorkerId中启动应用进程，将端口池中的端口传给应用进程。

中心服务器会为每个连接上的Master在数据库中的守护进程状态信息列表中保存一条记录其连接信息的条目，该记录的条目如表9所示：

表9

Master的端口池管理

Master的端口池管理流程如下：

1.Master启动后，从中心服务器上的应用服务器列表获取本应用服务器的端口池范围，如“8001-8099”；

2.Master会测试该端口池范围中的尚未开启监听的端口号，将其标记为可用；

3.当启动一个Worker时，如果其对应的应用进程部署信息列表项中的动态端口标记为动态端口，则Master根据对应的应用进程部署信息列表项中的服务端口获知该Worker所需的端口号数量，否则不做处理。如“http；rpc“表示应用需要http与rpc两个端口；

4.从本应用服务器的端口池范围中取出相应数量的端口号分配给该Worker，并将所分配的端口号标记为已占用；如采用如下格式传输：http＝8001；rpc＝8002；

5.当Worker启动需要的端口是，使用Master传输过来的端口号组合，如：当应用监听http端口时，选择8001端口，当应用监听rpc端口是监听8002；

6.当该Worker退出时，守护进程将该应用进程所占用的端口号返回给端口池。

应用进程(Worker)的启动和注册

由Master控制的Worker启动步骤如下：

1.接受来自于Master的参数，其中包含端口池的配置；

2.实现服务启动的逻辑，包含配置读取，资源初始化等；

3.当配置为动态端口时按照端口池配置启动监听端口，否则按照服务的配置进行监听；

3.与中心服务器建立一条长连接，并监听来自于中心服务器的命令；

4.通过这条长连接在中心服务器中注册自己；

5.通过这条长连接维持与中心服务器的心跳。

每个启动的Worker都会与中心服务器建立一条长连接并保持心跳，中心服务器会针对每一个建立连接的Worker在应用运行信息列表中保存如表10所示的记录来记录其连接信息，表10即为应用运行信息列表，又称RunningWorker表：

表10

在表10中，应用服务地址的格式可以为：rpc＝tcp：//192.168.1.100：8000；http＝http：//192.168.1.100：8080。

根据前面的描述，Worker与中心服务器建立一个长连接后，并定期发送心跳(如15秒)，其中以下的情况出现会导致中心服务器将可用的Worker从应用运行信息列表中踢出：1.连接断开；2.超过预设时间(如45秒)未接收到心跳。

应用进程(Worker)的管理

除了守护进程启动的时刻自启动应用进程的设计，在守护进程运行时，也可以管理应用进程的运行。

增加一个与中心服务器连接的控制终端；控制终端向中心服务器发送启动指定应用进程的请求，中心服务器将该请求发送给对应的守护进程，守护进程启动该指定应用进程，该应用进程连接守护进程，守护进程将该请求发送给该应用进程，该应用进程调用服务的启动方法；控制终端向中心服务器发送停止指定应用进程的请求，中心服务器将该请求发送给对应的守护进程，守护进程再将该请求发送给该指定应用进程，该应用进程调用服务的停止方法，守护进程停止该应用进程。

关于控制终端如何找到合适的中心服务器地址：因为中心服务器会采用负载均衡的方式进行部署，但是HADB是单点结构，那么当控制终端想要操作一台中心服务器的时候，会采用如下步骤：1.控制终端通过负载地址访问中心服务器的GetEndpoint接口；2.控制终端在通过中心服务器返回的Endpoint连接到具体负责连接的那一台中心服务器上。

图5是本发明实施例中的应用进程启动过程的流程图。如图5所示，包括：控制终端通过Http向中心服务器发送启动指定应用进程的请求，中心服务器将该请求选择TCP连接，通过所选择的TCP连接发送启动指定应用进程的请求给对应的守护进程；守护进程启动应用进程，应用进程通过Namepipe连接上守护进程；守护进程通过Namepipe将该请求发送给应用进程，应用进程调用服务的启动(Start)方法。

图6是本发明实施例中的应用进程停止过程的流程图。如图6所示，包括：控制终端通过Http向中心服务器发送停止指定应用进程的请求，中心服务器根据请求选择TCP连接，通过该TCP连接将该请求发送给对应的守护进程将；守护进行守护进程通过Namepipe将该请求发送给应用进程，应用进程通过反射调用服务的停止(Stop)方法；守护进程停止应用进程。

图7是本发明实施例中的应用进程更新过程的流程图。如图7所示，当用应用进程A’更新指定应用进程A时，包括：控制终端通过Http向中心服务器发送将A更新为A’的请求，中心服务器根据请求选择TCP连接，通过该TCP连接将该请求发送给对应的守护进程；守护进程获取新应用进程的地址，并覆盖当前的应用进程，以进行应用进程更新。具体来说，先停止应用进程A，然后从中心服务器下载A’并用A’覆盖A，启动新的应用进程A’。

图8是本发明实施例中的应用进程热更新的流程图。如图8所示，当用应用进程A’更新指定应用进程A时，包括：控制终端将A’的部署包上传到中心服务器，向中心服务器发送用A’更新的请求，中心服务器将该请求发送给对应的守护进程，守护进程从中心服务器下载A’的部署包，并启动应用进程A’，该应用进程A’启动后向中心服务器进行注册；然后，控制终端向中心服务器发送更新A的请求，中心服务器将该请求发送给对应的守护进程，守护进程再将该请求发给应用进程A，应用进程A删除自身在中心服务器上的注册信息，该应用进程A停止。

图8所示的热更新相对于图7所示的更新，可以不用停止应用进程的业务。

上述方案实现了应用进程运行状态的监控，可以方便地查看应用进程的运行状况，大大简化了运维部署成本，实现了快速部署。并且应用进程的监控和实际应用进程进行隔离，有效提高了应用进程运行的安全性。

当应用进程启动后，我们的核心需求为通过一个应用进程名称找到该应用进程启动的应用服务器地址。在本步骤中通过如下方式实现：客户端与中心服务器建立连接，向中心服务器提供自己要访问的应用进程标识信息；中心服务器读取应用进程列表和应用运行信息列表，将符合客户端所提供的应用进程标识信息的记录返回给客户端；客户端解析所接收内容，从中选择一个记录进行路由。此外，当应用进程列表或应用运行信息列表发生变化时，中心服务器通知客户端，客户端重新从中心服务器获取符合自己要访问的应用进程标识信息的记录。具体描述如下：

1.客户端访问中心服务器，与中心服务器建立一条TCP长连接，并监听中心服务器的命令；

2.客户端通过TCP长连接访问中心服务器，提供自己想要访问的应用进程名称；

3.中心服务器读取应用进程列表，以及应用运行信息列表，并将应用进程名称符合的记录返回给客户端，并且在内存中记录下本连接的信息，注册回调；

4.客户端解析记录，按照如下规则获取应用进程名称所对应的地址；

a)拿到应用进程名称符合的记录；

b)拿到应用进程列表符合的记录，拆解ServiceUrls中符合的记录；

如：http＝http：//192.168.1.100：8800；rpc＝tcp：//192.168.1.100：8801

从中获取到rpc的地址；

c)从一系列符合的记录中按照访问规则返回给调用方，比如：

i.随机访问会从固定地址中随机选取一个；

ii.如果是一致性hash会按照一致性hash算法选择取；

5.当以下变化触发时，所有的中心服务器都会受到通知；

a)当应用进程列表变化时；

b)当应用运行信息列表变化时；

6.由于客户端保持了与中心服务器的长连接并监听了来自于中心服务器的命令，负责此客户端的中心服务器收到变化通知时，会将变化信息发送到客户端；

7.客户端接收到变化后，会重新重复步骤3，重新获取并建立路由表。

在本发明中，应用(AppBean)的热更新过程如下：中心服务器遍历所有受影响的应用服务器，向对应的应用服务器的守护进程发送更新指令；守护进程下载新的应用包，启动一个新应用进程，监听新的端口；该新应用进程与中心服务器建立连接，中心服务器为该新应用进程保存一条记录(具体是更新应用配置信息列表中的应用进程名称)，并将该变化同步到所有监听的客户端。此时，请求开始路由到新的应用进程，老的应用进程不再接收到应用请求一段时间后，退出。

应用的路由

则在图2所示的系统中，代理服务器(proxy)需要调用某个应用，或者一个应用需要调用另一个应用时，正是通过应用配置信息列表(Application表，表7)和应用运行信息列表(RunningWorker表，表10)进行路由的。

基本的路由策略如下：

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

2.通过应用配置信息列表中元数据标注找到对应的应用进程名称；

3.通过应用进程名称在应用运行信息列表中，找到与应用进行名称相等的一个或多个应用服务器地址：

4.通过应用配置信息列表中的元数据标注判断此应用进程名称是随机负载还是一致性Hash负载

5.通过随机负载算法或者一致性Hash算法，找到确切的目标应用服务器地址；

6.调用到目标应用服务器，并将应用配置信息列表项中的应用名称(AppName)附加在请求上，这使得目标应用服务器上的守护进程可以根据该应用分类名称直接定位对应的应用，而不再需要再重复步骤1和2的过程了。

例如，在本发明的一个实施例中，查找一个Http应用的地址的流程如下：

1.代理服务器接收到客户端或浏览器发出的Http请求；

2.代理服务器访问中心服务器，从Application表的Annotations字段(应用元数据标注字段)中，找到HttpPrefix(一种元数据标注信息)与Http请求中请求URL相符的一条记录；

具体来说，枚举所有Application表中的记录，找到Annotations中的HttpPrefix元数据标注，并判断请求的URL是否与HttpPrefix的值为起始；

3.代理服务器根据步骤2中所确定的一条记录中的Annotations字段(应用服务元数据标注字段)的信息生成AppContext；

具体来说，找到Annotations字段的ContextLoader信息，找到符合ContextLoader取值的赋值函数，从Http请求报文的Cookie字段中提取信息作为函数的输入，运行函数，得到AppContext；

4.代理服务器根据步骤2中所确定的一条记录中的WorkerName字段(应用进程名段)，从RunningWorker表的中找出WorkerName字段(运行的应用进程名称)与之相符的记录；可以有多条记录与之相符。

5.代理服务器根据步骤2中所确定的一条记录中的Annotations字段中的Stateful配置进行如下选择：

如果为‘true’，则使用一致性哈希的方式从多条RunningWorker中通过AppContext信息选出一条记录；这里，一致性哈希是通过AppContext的Uri字符串计算哈希值，选择哈希值所对应的一条记录；具体的哈希算法可采用KETAMA算法；

如果为‘false’，则随机选出一条RuningWorker记录；

6.提取所选出的RuningWorker记录中的ServiceURLs字段(应用服务地址字段)中的地址信息，根据给地址信息实现应用的调用。

在上面的例子中，代理服务器接收到的是针对HttpAppBean的请求，因此根据该请求中的URL找Application表中的对应的HttpPrefix，以找到对应的应用服务。

而RemoteAppBean会基于AppName进行路由。例如，如果代理服务器接收到的是与RemoteAppBean对应的Rpc请求，则直接根据该Rpc请求中的远程调用服务名称(RemoteAppName)查找应用服务名称(AppName)字段与其一致Application表，该Application表即为部署该Rpc请求对应的RemoteAppBean时所生成的表，然后执行与上述3-6相同的步骤。

应用的灰度发布

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

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

在本发明中，灰度发布因子是条件表达式，按照如下格式定义：

field.condition

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

field1.condition1and|orfield2.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)。

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

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

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

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

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

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

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

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

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

版本号级联灰度

在本系统中，可能存在如下情况：应用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’后的路由过程与前述描述一致，这里不再赘述。

三、配置系统

在大型集群系统开发中，应用服务的配置信息一向是混乱及难以管理的，本发明中使用了一种基于中心的配置方式，在保留灵活性的基础上，实现了配置的全局可管理性，便捷，特例化，更新等特性。

图9是本发明实施例中的全局配置系统的示意图。如图9所示，该系统在图2所示的系统的基础上，增加了一个与中心服务器连接的用于保存应用的配置信息的全局配置数据库。应用服务器向中心服务器发送配置信息请求消息；中心服务器在接收到应用服务器发送的配置信息请求消息后，从全局配置数据库检索出相应的配置信息并返回给应用服务器。

应用服务器还将自身的地址注册到配置服务器；配置服务器用于在对配置数据库中的应用服务器的配置信息进行更新后，根据应用服务器的注册地址向相应的应用服务器下发更新后的配置信息。

在本系统中，配置信息被分为文本配置Text和表配置Table两种。其中：Text为文本，可以为任意格式，如.properties格式，或xml格式等；Table为数据表，与数据库中的表类似，Framework中提供了存取表的接口，可以直接针对表进行访问。

本地/全局配置模式

在本发明中，应用服务器还可以从本地获取配置信息，因此配置存在本地配置和全局配置两种运行模式：

在本地配置模式中，Text会以当前运行目录为根目录，读取文本文件，Table会以运行根目录中的全局配置数据库的配置信息，直接读取数据库中的表结构；

在全局配置模式中，Text和Table的读取都会通过中心服务器进行，中心服务器会读取保存在全局配置数据库中的Text配置和Table配置，并且会实现特例化特性，及PUSH更新特性。

其中，应用服务器通过切换远程加载模块和本地加载模块，来实现远程从中心服务器获取配置信息的全局配置模式以及从本地获取配置信息的本地配置模式之间的切换。所述远程加载模块，用于向中心服务器发送配置信息请求消息，并接收中心服务器返回的配置信息；所述本地加载模块，用于从应用服务器的本地获取配置信息。

一般情况下当单元测试，和直接从开发环境运行时，应用运行在本地配置模式；当实际部署到环境中运行时，应用都会运行在全局配置模式下，运行在全局配置模式可以支持特例化，及PUSH更新。

特例化配置

特例化的需求描述为，当某个配置针对全局配置为A，但是又需要将某台服务器或某个应用读到的配置为B时的需求。

本发明中，在全局配置数据库中保存了默认配置信息和特例化配置信息。中心服务器在接收到应用服务器发送的配置信息请求消息后，根据最大匹配原则对配置信息请求消息中匹配参数进行匹配，将匹配到的默认配置信息或特例化配置信息返回给应用服务器。

例如，在本发明的一个实施例中：按照配置信息键值、应用名称和应用服务器名称之间的对应关系保存配置信息；应用服务器向中心服务器发送包含配置信息键值、应用名称和应用服务器名称这三个参数的配置信息请求消息；中心服务器在接收到该请求消息后，先根据其中的配置信息键值、应用名称和应用服务器名称这三个参数去从配置数据库中检索配置信息；如果没有检索到匹配项，则根据配置信息键值和应用名称这两个参数去从配置数据库中检索配置信息；如果仍没有检索到匹配项，则根据配置信息键值这一个参数去从配置数据库中检索配置信息。

图9所示的系统在全局配置模式下支持两种配置文本配置和表配置，其中配置都通过rpc方式从中心服务器读取，配置表对所有应用均为一致，配置文本可以针对不同的应用进行特例化。

配置特例化的方式如下文描述：

1.应用A获取配置时，会提交loadText参数如下，

a.Path＝”Tracing”表示读取Tracing的配置

b.Args＝”Application＝A；Server＝SERVER-A；”，双引号内的字段有不同的键值对组成

2.中心服务器接受到配置请求以后会通过Args字段对比自己满足Path＝”Tracing”的配置，如果存在以下两条记录

c.Args＝””，Value＝”Warn”

d.Args＝”Application＝A”，Value＝”Info”

3.中心服务器在选取配置的时候会采取最大匹配原则。以最多的键值对相等进行判断，如果存在相同键值对相等的次数，则以出现在请求中的键值对顺序进行判断，先满足的会返回；

4.按照上述判别规则，中心服务器会返回Value＝”Info”给应用。

特例化的可选参数包含：

group＝服务器组名

server＝服务器名

app＝应用名称AppName

配置的PUSH更新

中心服务器对全局配置数据库中的配置信息进行更新，并找到使用该配置信息的应用，向使用该配置信息的应用所在的应用服务器发送更新后的配置信息。具体来说：

1.终端向中心服务器发起配置更新请求(具体来说，运维人员通过运维工具发布配置更新请求，运维工具将更新请求提交给中心服务器)；

2.中心服务器对全局配置数据库中的配置信息进行更新，并找到对应的应用进程的连接，通过该连接下发配置更新请求；

3.对应的应用进程重新从中心服务器获取配置信息，刷新配置信息并返回结果给中心服务器；

4.中心服务器将结果返回给终端。

四、监控系统

图10是本发明实施例中的监控系统的示意图。如图10所示，该系统在图2所示系统的基础上，增加了与中心服务器连接的全局监控数据库，与全局监控数据库连接的监控服务器，以及在每个应用服务器中增加一个本机日志数据库。由于篇幅所限，在图10中只示意性的画出了图2中的中心服务器和一个应用服务器。

在图10中，在全局监控数据库中保存不同监控策略。应用服务器中的守护进程以及应用进程，通过中心服务器从全局监控数据库获取对应的监控策略，根据所获取的监控策略进行监控，将监控结果数据保存到本机日志数据库中，以及根据监控策略将相应的监控结果数据通过中心服务器上传到全局监控数据库中，并在获取到的数据超过阀值时附加报警标记。监控服务器展示全局监控数据库中的监控结果数据，并提示报警。

在图10中，监控服务器对全局监控数据库中的监控策略进行更新，然后向指定应用服务器中的守护进程和/或应用进程发送监控策略更新通知；所述指定应用服务器中的护进程和/或应用进程收到所述监控策略更新通知后，从全局配置服务器获取对应的更新后的监控策略。

具体来说：具体为监控服务器向全局监控数据库发送更新监控策略指令，全局监控数据库对监控策略进行更新后返回应答响应消息；监控机向指定服务器上的守护进程和/或应用进程发送监控策略更新通知；指定服务器上的守护进程和/或应用进程收到监控策略更新通知后，从全局监控数据库获取对应的更新后的监控策略，具体为对比自身已有的监控策略的版本号是否与全局监控数据库上的对应监控策略的版本号一致，如不一致，则从全局监控数据库获取监控策略并用所获取的监控策略对已有的监控策略进行更新，并向监控服务器返回更新成功消息。

全局报表服务器定期从各应用服务器的本机日志数据库中获取数据，进行汇总后保存到全局报表数据库中，将全局报表数据库中的数据展示给用户。应用服务器中的守护进程删除本机日志数据库中的超过一定时间(如7天)的数据，这保证本机日志数据库中的数据不至于超过限制大小。

在图10所示的系统中，监控与报警系统的数据来源分为两个类型：

1.系统资源计数器(包含CPU，内存，磁盘，IO，网络流量等能够直接从操作系统中取出来的数据，一般为一个浮点数)；

2.程序内嵌计数器，为本系统特有的基于程序内部技术的，动态规格的报表计数器；

在本系统中系统资源计数器由守护进程Master监控，而程序内嵌计数器由应用进程Worker进行监控。所有的计数器的监控配置(即采集策略)都由Master和Worker通过中心服务器从全局监控数据库中读取。读取到监控配置以后Master和Worker会按照监控配置定期将数据存储到本机日志数据库中，或上传到中心服务器，是否上传取决于监控策略的配置。

应用服务器中的守护进程对系统资源计数器进行监控；监控的指标包括：CPU指标、内存指标、磁盘指标、网卡流量指标和MySQL指标等。

具体来说，守护进程从中心服务器获取监控配置，根据监控配置中的内容定时执行脚本获取该项数据，将该项数据保存到本机日志数据库中，并根据监控配置进行如下操作：1)如果配置了阀值报警，并且获取到的值超过了阀值，将数据包上传到中心服务器，并附加报警标记；2)如果配置了定时上传，则直接将数据打包上传到中心服务器。中心服务器将上传数据保存到全局监控数据库中。

下面重点描述本发明中特有的程序内嵌计数器。

在服务器端开发领域，性能计数器是反映一个服务运行状况的关键指标，在windows平台下，有perfmon程序可以用于监控系统的关键资源，而应用程序也能够对扩展perfmon的类型并进行记录，并且通过perfmon工具查看实时数据，或者存储，linux最新版本的内核也随性能计数器进行了支持。

但是上述操作系统相关的计数器对业务层面的计数需求较难满足。例如：

1.数据的记录往往是几条，对几千条的数据很难做到监控和展示；

2.计数器的类型局限于几种类型(数字，频率，平均值，命中率)等，且不能记录文字等的信息，扩展起来较为困难；

3.功能更多的关注在实时监控上，对大规模数据日常的记录操作并不友好。

基于以上的考虑，本发明设计了进程内的程序内嵌计数器，使其能够更好的支持业务类数据的记录与监控。

图11是本发明实施例中的程序内嵌计数器的实现方式示意图。参见图11，业务代码会将相关的计数输出到内嵌计数器中，而客户端代理会在启动时刻，通过中心服务器获取计数器的采集策略，并且定时进行程序内嵌计数器的数据采集工作，上传到中心服务器，或记录到本机日志数据库中，并根据阀值进行告警。

可见，在本发明中，需要设计程序内嵌计数器，在应用进程中嵌入所设计程序内嵌计数器；应用服务器中的应用进程根据所获取的监控策略对程序内嵌计数器进行监控。

在本发明中，程序内嵌计数器的数据结构如下：

-程序内嵌计数器中包含多个名字唯一的类别(Category)；

-每个类别中可以包含多个固定的列；

-每个类别中包含多个名字唯一的实例(instance)，也可以理解为行。

根据以上的定义，一个定义好的程序内嵌计数器的输出如表11所示：

Category：“rpc-client”

表11

其中，列是固定的，而行与请求的方法名一样，可能随着请求的增加而增加。

生成一个类别的方法包括：确定该类别的名字，设置该类别的输出列、该类别的一组原子计数器和原子计数器的操作方法、该类别的快照的数据格式以及该类别的根据快照数据计算输出实例的方法。

具体来说，在本发明的实施例中，通过以下手段定义一个类别(Category)：

1.定义唯一的名字，即指定该类别的名字；

2.定义该类别的输出列；列的类型可以为整数、浮点数和字符串；

3.定义原始的数据类型及操作方法：定义该类别的一组原子计数器和原子计数器的操作方法；

4.定义该类别的快照的数据格式；包含从原子计数器中取出来的直接结构；

5.定义该类别的根据快照数据计算输出实例的方法；即定义从两次快照计算报表输出行的方法；

6.定义该类别的输出实例的汇总方法，即定义报表行的汇总方法。

根据以上描述，定制一个命中率计数器(即一个实现命中率计算的类别)的方法如下：

1.指定该类别的唯一名字；这里为“cached-hit-ratio”；

2.定义该类别的输出列为：每秒访问次数(/sec)，命中率(ratio)；这里有两个列；

3.定义原子计数器及操作方法：命中率计数器的原始数据包含两个整数型原子计数器，第一原子计数器hitted和第二原子计数器missed；

业务代码记录命中时会将hitted加一；

业务代码记录未命中时会将missed减一；

4.定义该类别的快照的数据格式为：保存生成快照时刻的第一原子计数器的计数值、第二原子计数器的计数值、系统时间；

5.定义该类别的根据快照数据计算输出实例的方法，即根据两次快照计算报表输出行的方法为：根据两次快照的数据计算总访问次数、命中次数和两次快照的间隔时间，然后根据总访问次数和两次快照的间隔时间的比值获得每秒访问次数，根据命中次数和总访问次数的比值获得命中率；

例如，输出行从两次间隔时间为T的快照中计算出来，我们定义时间0时获取到快照snapshot1，当再次经过时间T后，在此获取快照snapshot2，输出计算公式为

report.total＝(snapshot2.hitted+shapshot2.missed)-(snapshot1.hitted+snapshot1.missed)

report.hitted＝(snapshot2.hitted-snapshot1.hitted)

report.interval＝(snapshot2.time-snapshot1.time)

输出行展现数据为

(call./sec)：total/interval

(hitratio)：hitted/total

6.定义该类别的输出实例的汇总方法为：对各实例的总访问次数进行求和得到汇总后的总访问次数，对各实例的命中次数进行求和得到汇总后的命中次数，汇总后的两次快照时间间隔等于实例的两次快照时间间隔，各实例的两次快照时间间隔相等。如：

summary.total＝sum(report.total)

summary.hitted＝sum(report.hitted)

summary.interval＝report.interval；

sum()运算表示求和，汇总的各行数据时间一致

应用进程中的业务代码根据类别名查找到该实现命中率计算的类别，并根据实例名查找到该实现命中率计算的类别的相应实例，在业务命中时将相应实例中的第一原子计数器加1，在业务未命中时将相应实例中的第二原子计数器加1。

程序内嵌计数器设计好之后，每次代码触发后，数据都会存储在应用进程的内存中，应用进程启动后，监控的步骤如下：

1.应用进程与中心服务器建立长连接；

2.应用进程获取本机的监控配置；

3.中心服务器按照应用服务器的名称，返回适合于应用服务器的监控配置；

4.应用服务器启动监控线程，固定时刻运行；

5.固定时刻后，应用进程会获取程序内嵌计数器的快照snapshot，如果有上一次获取到的snapshot，则将用两次snapshot计算出最后的结果，否则将本次snapshot计入到上次的结果中；

6.如果有计算结果，根据记录模式执行如下操作：

a)NONE，不记录；

b)ALL：将所有instance的记录存储到本机日志数据库中；

c)SUMMARY：将所有instance的记录执行汇总，并存到本机日志数据库中；

7.如果有计算结果，根据上传模式执行如下操作；

a)NONE，不记录；

b)ALL：将所有instance的记录打包上传到中心服务器当中

c)SUMMARY：将所有instance的记录执行汇总，并打包上传至中心服务器；

8.判断计算结果是否突破阈值，如果突破阈值，将计算结果附加报警记录，上传至中心服务器。

五、开发辅助系统

基于插件的开发方式

在本发明的基于Java的应用开发中，基于现有的插件系统(Eclipse)生成了扩展插件，该扩展插件连接开发管理服务器实现以下功能：

创建并管理工程组件、实现基于版本的升级系统；

创建应用的框架代码；

实现对RemoteAppBean调用代码的生成，并协助管理依赖信息；

实现对应用的注入式调试。

组件的版本管理

在本系统中，开发中需要进行不同版本组件的依赖，对于基础库的版本依赖的方式如下，例如：

开发Apps1.0时，依赖为Framework-1.0.jar，BizLibrary-1.0-jar；

开发Apps2.0时，依赖为Framework-1.1.jar，BizLibrary-2.0-jar。

本系统这样解决这个问题，将版本的定义如下：

1.0版本，依赖库包含：Framework-1.0.jar；BizLibrary-1.0.jar；

2.0版本，依赖库包含：Framework-1.1.jar；BizLibrary-2.0.jar。

此项版本信息由开发管理员进行创建，每次升级版本，都需要在开发管理服务器的配置库中新增此配置信息。

新建工程时的依赖配置建立

创建App工程时，开发需要选择一个当前的版本，当开发人员选择版本后，插件进行的步骤如下：

1.通过开发管理服务器获取依赖的包的信息；

2.获取特定版本的包；

3.将依赖关系加入到当前的App工程环境中；

4.将版本号写到META-INF/AppBean.properties版本中(此项版本也会后续影响到程序上线，以及灰度发布)

旧有工程的依赖配置升级

当我们需要根据新发布的基础库进行旧有应用的升级时，比如，当基础库升级至2.0版本，我们将1.0版本的应用升级至2.0版本时的步骤如下：

1.开发人员将当前版本选择至2.0；

2.插件向版本管理系统读取2.0版本的依赖库信息；

3.插件下载开发管理系统配置的依赖插件；

4.替换本地的依赖关系；

5.升级成功。

对RemoteAppBean的调用代码的生成

RemoteAppBean是本系统内实现应用互访及应用层次的核心概念，当实现了RemoteAppBean并经过AppLoader上传到中心服务器后，任何一个希望访问这个RemoteAppBean的应用需要生成针对这个RemoteAppBean调用的代理类。

在开发一个需要访问RemoteAppBean的应用时，扩展插件从开发管理服务器获取已公开的所有RemoteAppBean，并将其信息显示给开发者，又开发者选择要调用的RemoteAppBean；扩展插件从所选择的RemoteAppBean的反射信息中获取如下信息：应用名称和类型信息；扩展插件根据所获取的信息生成请求和应答类型实体类；扩展插件根据所述请求和应答实体类型创建代理类，并将该代理类插入到所述需要访问RemoteAppBean的应用中。

具体步骤如下：

1.开发者开始进行RemoteAppBean依赖；

2.插件访问开发管理平台并获到当前所有公开的RemoteAppBean，并将其信息返回并显示给开发者；

3.开发者选择要调用的RemoteAppBean；

4.插件从RemoteAppBean的反射信息中，获取如下信息：

a)AppName：应用名称；

b)类型信息，包括：请求，应答，及上下文类型；

5.插件根据上面的信息生成请求，应答类型实体类，此过程如下：

a)AppLoader会将请求与应答类型，保存为反射的中间数据，保存管理平台库中；

b)如果此类型在本工程的引用中存在，则直接引用该类；

c)否则插件根据中间数据，重新生成请求与应答类型的类的代码；

6.使用上一步获得的请求，与应答类型，创建代理类，代理类会使用步骤4中获得的上下文类型；

7.将代理类的初始化插入到调用的AppBean中。

依赖检测

在大规模的复杂平台中，不同服务间的依赖是一个非常难以管理的问题。

在本发明中，显示创建应用之间的依赖信息，并在应用的更新过程中检测依赖信息，以确定是否进行应用的更新。

当AppLoader加载一个存在依赖的App工程时，会将依赖信息保存为如下的数据：

调用者；

被调用者；

依赖的请求参数类型信息；

依赖的应答参数类型信息。

例如，当应用B依赖应用A时，系统会创建依赖信息：

调用者：B

被调用者：A

依赖的请求参数类型信息：A.RequestArgs

依赖的应答参数类型信息：A.ResponseArgs

应用的更新过程中的依赖检测

B对A存在依赖，但是当A升级为A’的时候，依赖检测的步骤如下：

1.部署程序上传应用程序A’，并发起更新指令；

2.部署程序发现应用程序B依赖于A，这时会对A’和B对A的依赖的请求及应答参数进行对比，有两种可能：

a)A’的请求和应答参数与A的请求和应答参数兼容(相等，或向下兼容)，系统允许更新，并将A与B都标记为更新程序；

b)A’的请求和应答参数与A的请求和应答参数不兼容，系统将不允许更新，除非将B的更新也一并提交，或先将B下线。

版本测试范围预估

通过上一节场景的描述，当某个版本的应用开发时，系统会记录所有时间点的更新记录，这样当系统管理员确定上线版本时，可以从某个时间点上提取出在某个时间点后可能会影响到的应用范围列表。

这个列表可以进行自动的测试范围判断，提取的步骤如下：

1.找出所有在时间点后更新的应用；2.找出依赖这些应用的应用；3.递归找出步骤2中的应用，直到没有引用位置；4.将所有找出的应用纳入测试范围。

注入式调试

一般情况下调试一个应用程序需要将程序部署到实际运行环境当中去(测试环境或是生产环境)，但是部署到测试环境中的应用很难调试，本系统发明了一种注入式的解决方案可以解决开发人员针对运行环境的调试问题。

解决方案为：扩展插件在本地启动应用；所述启动的应用与代理服务器创建连接，并向代理服务器发送要调试应用的配置参数；所述要调试应用的配置参数限定指定范围内的用户；代理服务器在接收到客户端请求消息后，首先匹配所述要调试应用的配置参数，如果匹配成功则将客户端请求消息发送给所述启动的应用处理，并将所述启动的应用返回的处理结果发送给客户端，如果匹配不成功，则将客户端请求分发给对应的应用所在的应用服务器。

图12是本发明实施例中的注入式调试系统的示意图。参见图12，插件与图2所示系统中的代理服务器连接，这里只示意出了图2所示系统中的代理服务器和应用服务器集群。

如图12所示，在正常运行的环境中，客户端的请求会直接发给代理服务器，然后代理服务器根据应用配置发送特定的应用服务器，参见前面的章节的描述。

注入调试的步骤如下：

1.通过插件启动的应用会与特定类型的代理服务器(每一台都要创建)创建长连接，并监听请求；

2.应用向代理服务器发送注入请求，将调试的应用的配置参数发送给代理服务器，其中插件限制应用的配置参数必须包含灰度参数(也就是只能影响固定范围内的用户)；

3.代理服务器会在本地的路由表中添加注入项；

4.当代理服务器监听到来自客户端的请求后，会判断请求是否满足当前的注入条件；不满足注入条件的请求会按照原有路由逻辑进行路由。

5.满足注入条件的请求会通过插件与代理服务器建立的长连接将请求转发给插件启动的应用；

6.应用会将来自连接的请求转换为正常情况下的请求，传给应用进行处理，并将应答返回发送给代理服务器，并通过代理服务器下行给客户端；

7.应用退出后，与代理服务器的连接会中断，这时代理服务器会自动将注入项移除。

这样就实现了在开发机上进行环境的注入调试。

六、跨应用服务平台系统的应用访问

在跨IDC机房的环境下，每个机房中的部署结构均与前述的图2所示的结构一致。即每个IDC机房中都有一个图2所示的应用服务平台系统。这里每个IDC称为一个Site。

图13是本发明实施例中的多个应用服务平台系统的结构示意图。如图13所示，每个IDC中都有一个图2所示的应用服务平台系统，在每个应用服务平台系统中增加一个网关，各应用服务平台系统之间通过网关进行通信。网关之间可以采用专线通讯，或者采用压缩、加密后的公网通信。

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

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

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

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

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

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

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

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

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

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

在本发明的实施例中，在Framework层面上只有RemoteAppBean可以透过网关进行访问，其他的Bean均只能在本Site内进行访问，其中RemoteAppBean访问的方法如下：

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 (54)

1.一种实现应用服务平台系统的方法，其特征在于，在应用服务平台系统中设置代理服务器、中心服务器、资源服务器和由多个应用服务器组成的应用服务器集群，其中，在资源服务器上保存应用服务器上的各应用处理客户端请求消息所请求的任务时需要访问的数据资源，所述应用服务器集群上负载并运行应用，该方法包括：

中心服务器接收外部上传的应用，将应用的描述信息保存到应用配置信息列表中，并将应用部署到应用服务器集群中的应用服务器上；应用服务器集群中的应用服务器将所负载的应用的运行信息上传到中心服务器上的应用运行信息列表中；

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

代理服务器在接收到客户端请求消息时，对客户端请求消息进行解析，通过查询中心服务器上的应用配置信息列表识别所述客户端请求消息所对应的应用，根据应用配置信息列表中的该应用的描述信息创建应用上下文，在所述客户端请求消息中添加应用上下文后，通过查询中心服务器上的应用配置信息列表和应用运行信息列表获得对应的应用的服务地址，根据所获得的服务地址将客户端请求消息分发给对应的应用所在的应用服务器；

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

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

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

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

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

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

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

3.根据权利要求2所述的方法，其特征在于，所述AppBean基础类型包括：处理超文本传输协议HTTP请求的超文本传输协议应用组件HttpAppBean、处理远程过程调用协议RPC请求的远程调用应用组件RemoteAppBean、和处理定时任务的任务应用组件JobAppBean；

当需要开发新类型应用时，该方法还包括：在业务框架类库中扩展与该新类型应用对应的AppBean基础类型，以及在业务框架类库中扩展针对该新类型应用的应用上下文。

4.根据权利要求1所述的方法，其特征在于，所述应用上下文在数据构成上包括两部分：

通用资源标志符URI：包括用户的索引信息，负责后续的资源定位；

附加数据：包括该应用的属性信息。

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

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

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

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

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

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

或者，

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

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

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

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

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

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

9.根据权利要求8所述的方法，其特征在于，所述中心服务器将应用部署到应用服务器集群中的应用服务器上包括：

在每个应用服务器上部署一个守护进程；在中心服务器上保存应用进程列表；该应用进程列表包括：应用进程标识、动态端口标记、应用服务器名称、应用服务器分组名称、部署包接口和服务端口；

中心服务器根据应用服务器列表、应用服务器分组列表和应用进程列表中的信息，确定每个应用服务器上应启动的应用进程部署信息列表；该应用进程部署信息列表包括：应用进程标识、动态端口标记、部署包接口和服务端口；

每个应用服务器上的守护进程启动后，与中心服务器建立连接并保持心跳，从中心服务器获取本应用服务器的应用进程部署信息列表，根据该应用进程部署信息列表下载并启动本应用服务器的应用进程；

每个启动的应用进程都与中心服务器建立连接并保持心跳；

中心服务器为每个建立连接的守护进程在守护进程状态信息列表中记录其连接信息，以及为每个建立连接的应用进程在应用运行信息列表中保存记录其连接信息。

10.根据权利要求9所述的方法，其特征在于，所述中心服务器上的应用服务器列表还包括：服务器端口池范围；

该方法还包括：

每个应用服务器上的守护进程启动后，从中心服务器上的应用服务器列表获取本应用服务器的端口池范围，测试该端口池范围中的尚未开启监听的端口号，将其标记为可用；

当启动一个应用进程，如果其对应的应用进程部署信息列表项中的动态端口标记为动态端口，则守护进程根据对应的应用进程部署信息列表项中的服务端口获知该应用进程所需的端口号数量，并从本应用服务器的端口池范围中取出相应数量的端口号分配给该应用进程，并将所分配的端口号标记为已占用；

当该应用进程退出时，守护进程将该应用进程所占用的端口号返回给端口池。

11.根据权利要求9所述的方法，其特征在于，该方法还包括：

客户端与中心服务器建立连接，向中心服务器提供自己要访问的应用进程标识信息；中心服务器读取应用进程列表和应用运行信息列表，将符合客户端所提供的应用进程标识信息的记录返回给客户端；客户端解析所接收内容，从中选择一个记录进行路由；

当应用进程列表或应用运行信息列表发生变化时，中心服务器通知客户端，客户端重新从中心服务器获取符合自己要访问的应用进程标识信息的记录。

12.根据权利要求9所述的方法，其特征在于，该方法还包括：

增加一个与中心服务器连接的控制终端；

控制终端向中心服务器发送启动指定应用进程的请求，中心服务器将该请求发送给对应的守护进程，守护进程启动该指定应用进程，该应用进程连接守护进程，守护进程将该请求发送给该应用进程，该应用进程调用服务的启动方法；

控制终端向中心服务器发送停止指定应用进程的请求，中心服务器将该请求发送给对应的守护进程，守护进程再将该请求发送给该指定应用进程，该应用进程调用服务的停止方法，守护进程停止该应用进程。

13.根据权利要求9所述的方法，其特征在于，增加一个与中心服务器连接的控制终端，该方法还包括更新应用进程的过程，将指定应用进程A更新为应用进程A’具体包括：

控制终端向中心服务器发送将A更新为A’的请求，中心服务器将该请求发送给对应的守护进程，守护进程先停止应用进程A，然后下载A’，并用A’覆盖A，启动新的应用进程A’；

或者，

控制终端向中心服务器发送用A’更新的请求，中心服务器将该请求发送给对应的守护进程，守护进程下载A’的部署包，并启动应用进程A’，应用进程A’启动后向中心服务器进行注册；然后，控制终端向中心服务器发送更新A的请求，中心服务器将该请求发送给对应的守护进程，守护进程再将该请求发给应用进程A，应用进程A删除自身在中心服务器上的注册信息，该应用进程A停止。

14.根据权利要求9所述的方法，其特征在于，该方法还包括对应用的热更新过程，具体包括：

中心服务器向对应的应用服务器的守护进程发送更新指令；守护进程下载新的应用，启动一个新应用进程，该新应用进程与中心服务器建立连接，中心服务器为该新应用进程在应用运行信息列表中记录其连接信息；中心服务器更新应用配置信息列表中的应用进程名，并将应用配置信息列表中的应用进程名的变化同步到所有监听的客户端。

15.根据权利要求9所述的方法，其特征在于，所述方法还包括在中心服务器上配置应用配置信息列表的过程，具体包括：

解析应用的JAVA应用发布jar包，将解析后的数据保存在应用组件列表和应用包列表中；

其中，应用组件列表包括：应用类型、应用版本、应用名称、应用元数据标注、输入参数类型、输出参数类型、依赖关系和包标识；应用包列表包括：包标识、包版本和包所在服务地址；

根据应用组件列表和应用包列表生成应用配置信息列表。

16.根据权利要求1所述的方法，其特征在于，该方法还包括：在所述应用服务平台系统中对应用进行灰度发布，则所述应用配置信息列表还包括：灰度发布因子；对于不采用灰度发布的应用，将其对应的灰度发布因子设置为空；

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

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

17.根据权利要求16所述的方法，其特征在于，所述灰度发布因子为条件表达式；

所述代理服务器先在灰度发布因子不为空的应用中对其灰度发布因子进行匹配包括：

代理服务器对客户端请求消息进行解析，确定中心服务器上的应用配置信息列表中的对应列表项，根据该对应列表项中的信息创建应用上下文，根据所创建的应用上下文中的灰度发布因子匹配条件信息匹配灰度发布因子，如果符合灰度发布因子所表达的条件，则命中。

18.根据权利要求16或17所述的方法，其特征在于，当发布了应用B和调用B的应用A后，又对相应的升级版本B’和A’进行了灰度发布，并将B’的灰度因子设定为匹配A’的版本号，则客户端请求消息路由到A’后的过程如下：

A’在应用配置信息列表中寻找要调用的应用，找到B和B’；由于B’的灰度发布因子不为空，因此先进行匹配；A’获取自身的版本号后匹配B’的灰度发布因子，命中；A’选择B’作为调用的应用。

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

增加一个与中心服务器连接的用于保存应用的配置信息的全局配置数据库；

应用服务器向中心服务器发送配置信息请求消息；

中心服务器在接收到应用服务器发送的配置信息请求消息后，从全局配置数据库检索出相应的配置信息并返回给应用服务器。

20.根据权利要求19所述的方法，其特征在于，所述全局配置数据库中保存了默认配置信息和特例化配置信息；

所述中心服务器在接收到应用服务器发送的配置信息请求消息后，从全局配置数据库检索出相应的配置信息并返回给应用服务器包括：中心服务器在接收到应用服务器发送的配置信息请求消息后，根据最大匹配原则对配置信息请求消息中匹配参数进行匹配，将匹配到的默认配置信息或特例化配置信息返回给应用服务器。

21.根据权利要求19所述的方法，其特征在于，该方法还包括：

终端向中心服务器发起配置更新请求；

中心服务器对全局配置数据库中的配置信息进行更新，并找到对应的应用进程的连接，通过该连接下发配置更新请求；

对应的应用进程重新从中心服务器获取配置信息，刷新配置信息并返回结果给中心服务器；

中心服务器将结果返回给终端。

22.根据权利要求19所述的方法，其特征在于，该方法还包括：应用服务器从本应用服务器的本地获取配置信息；

其中，应用服务器通过切换远程加载模块和本地加载模块，来实现远程从中心服务器获取配置信息的模式以及从本地获取配置信息的模式之间的切换；

所述远程加载模块，用于向中心服务器发送配置信息请求消息，并接收中心服务器返回的配置信息；

所述本地加载模块，用于从应用服务器的本地获取配置信息。

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

增加与中心服务器连接的全局监控数据库，与全局监控数据库连接的监控服务器；以及每个应用服务器中增加一个本机日志数据库；

在全局监控数据库中保存不同监控策略；

应用服务器中的守护进程以及应用进程，通过中心服务器从全局监控数据库获取对应的监控策略，根据所获取的监控策略进行监控，将监控结果数据保存到本机日志数据库中，以及根据监控策略将相应的监控结果数据通过中心服务器上传到全局监控数据库中，并在获取到的数据超过阀值时附加报警标记；

监控服务器展示全局监控数据库中的监控结果数据，并提示报警。

24.根据权利要求23所述的方法，其特征在于，应用服务器中的守护进程，根据所获取的监控策略进行监控包括：

应用服务器中的守护进程对系统资源计数器进行监控；监控的指标包括：CPU指标、内存指标、磁盘指标、网卡流量指标或MySQL指标。

25.根据权利要求23所述的方法，其特征在于，应用服务器中的应用进程，根据所获取的监控策略进行监控包括：

设计程序内嵌计数器，在应用进程中嵌入所设计程序内嵌计数器；

应用服务器中的应用进程根据所获取的监控策略对程序内嵌计数器进行监控。

26.根据权利要求25所述的方法，其特征在于，所述设计程序内嵌计数器包括：设计程序内嵌计数器包含多个名字唯一的类别；每个类别包含多个固定的列和多个名字唯一的实例；

生成一个类别的方法包括：确定该类别的名字，设置该类别的输出列、该类别的一组原子计数器和原子计数器的操作方法、该类别的快照的数据格式以及该类别的根据快照数据计算输出实例的方法。

27.根据权利要求23至26中任一项所述的方法，其特征在于，该方法进一步包括：

监控服务器对全局监控数据库中的监控策略进行更新，然后向指定应用服务器中的守护进程和/或应用进程发送监控策略更新通知；

所述指定应用服务器中的守护进程和/或应用进程收到所述监控策略更新通知后，从全局配置服务器获取对应的更新后的监控策略。

28.根据权利要求1所述的方法，其特征在于，在所述应用的开发中，该方法还包括：

基于插件系统Eclipse生成扩展插件，该扩展插件创建并管理工程组件、实现基于版本的升级系统、创建应用的框架代码、实现对RemoteAppBean调用代码的生成、协助管理依赖信息以及实现对应用的注入式调试。

29.根据权利要求28所述的方法，其特征在于，所述扩展插件实现对RemoteAppBean调用代码的生成包括：

在开发一个需要访问RemoteAppBean的应用时，扩展插件从开发管理服务器获取已公开的所有RemoteAppBean，并将其信息显示给开发者，又开发者选择要调用的RemoteAppBean；

扩展插件从所选择的RemoteAppBean的反射信息中获取如下信息：应用名称和类型信息；所述类型信息包括请求、应答和上下文的类型信息；

扩展插件根据所获取的信息生成请求和应答类型实体类；

扩展插件根据所述请求和应答实体类型创建代理类，并将该代理类插入到所述需要访问RemoteAppBean的应用中。

30.根据权利要求29所述的方法，其特征在于，该方法还包括：显示创建应用之间的依赖信息，并在应用的更新过程中检测依赖信息，以确定是否进行应用的更新。

31.根据权利要求30所述的方法，其特征在于，所述在应用的更新过程中检测依赖信息，以确定是否进行应用的更新包括：

用升级后的应用A’更新应用A时，判断是否存在依赖于应用A的应用B；

如果存在，则判断应用A’的请求和应答参数是否与应用A的请求和应答参数兼容，是则允许更新，否则不允许更新。

32.根据权利要求28所述的方法，其特征在于，所述扩展插件实现对应用的注入式调试包括：

扩展插件在本地启动应用；

所述启动的应用与代理服务器创建连接，并向代理服务器发送要调试应用的配置参数；所述要调试应用的配置参数限定指定范围内的用户；

代理服务器在接收到客户端请求消息后，首先匹配所述要调试应用的配置参数，如果匹配成功则将客户端请求消息发送给所述启动的应用处理，并将所述启动的应用返回的处理结果发送给客户端，如果匹配不成功，则将客户端请求分发给对应的应用所在的应用服务器。

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

实现多个所述的应用服务平台系统，在每个应用服务平台系统中增加一个网关，各应用服务平台系统之间通过网关进行通信；

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

通过网关对远程调用应用组件RemoteAppBean进行跨应用服务平台系统的访问。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

37.一种应用服务平台系统，其特征在于，该系统包括：代理服务器、中心服务器、资源服务器和由多个应用服务器组成的应用服务器集群，其中，

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

每个应用服务器，用于负载并运行应用，将所负载的应用的运行信息上传到中心服务器上的应用运行信息列表中；

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

资源服务器，用于保存应用服务器上的各应用处理客户端请求消息所请求的任务时需要访问的数据资源；

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

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

38.根据权利要求37所述的系统，其特征在于，所述应用服务平台系统中部署有：基础框架类库和业务框架类库；

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

业务框架类库，用于根据业务的特性，定制业务的相关功能；

所述应用服务器中部署的应用，基于所述基础框架类库和业务框架类库，负载并运行应用，实现业务需求功能；

所述代理服务器，用于接收客户端请求消息，基于所述基础框架类库和业务框架类库对所接收的客户端请求消息进行路由。

39.根据权利要求38所述的系统，其特征在于，

在所述业务框架类库，还提供扩展新类型应用对应的AppBean基础类型的接口，以及提供扩展针对新类型应用的应用上下文的接口；

所述应用上下文在数据构成上包括两部分：

通用资源标志符URI：包括用户的索引信息，负责后续的资源定位；

附加数据：包括该应用的属性信息。

40.根据权利要求37至39中任一项所述的系统，其特征在于，

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

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

41.根据权利要求40所述的系统，其特征在于，

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

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

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

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

42.根据权利要求40所述的系统，其特征在于，所述应用服务器集群中的多个应用服务器被分为多个不同组；

所述中心服务器上保存有应用服务器列表和应用服务器分组列表；

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

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

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

43.根据权利要求42所述的系统，其特征在于，

每个应用服务器上部署有一个守护进程；

所述中心服务器上还保存有应用进程列表；该应用进程列表包括：应用进程标识、动态端口标记、应用服务器名称、应用服务器分组名称、部署包接口和服务端口；

中心服务器，用于根据应用服务器列表、应用服务器分组列表和应用进程列表中的信息，确定每个应用服务器上应启动的应用进程部署信息列表；该应用进程部署信息列表中的每一项包括：应用进程标识、动态端口标记、部署包接口和服务端口；

每个应用服务器上的守护进程启动后，与中心服务器建立连接并保持心跳，从中心服务器获取本应用服务器的应用进程部署信息列表，根据该应用进程部署信息列表下载并启动本应用服务器的应用进程；

每个启动的应用进程都与中心服务器建立连接并保持心跳；

中心服务器为每个建立连接的守护在守护进程状态信息列表中记录其连接信息，以及为每个建立连接的应用进程在应用运行信息列表中记录其连接信息。

44.根据权利要求43所述的系统，其特征在于，该系统还包括：与中心服务器连接的控制终端；

控制终端向中心服务器发送启动指定应用的请求，中心服务器将该请求发送给对应的守护进程将，守护进程启动应用进程，应用进程连接上守护进程，守护进程将该请求发送给应用进程，由应用进程启动所述指定应用；

控制终端向中心服务器发送停止指定应用的请求，中心服务器将该请求发送给对应的守护进程将，守护进程再将该请求发送给应用进程，由应用进程停止所述指定应用，守护进程停止应用进程。

45.根据权利要求40所述的系统，其特征在于，在该系统中对应用进行灰度发布，则所述应用配置信息列表还包括：灰度发布因子；对于不采用灰度发布的应用，其对应的灰度发布因子为空；

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

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

46.根据权利要求40所述的系统，其特征在于，该系统进一步包括：全局配置数据库，用于保存应用的配置信息；所述配置信息包括默认配置信息和特例化配置信息；

应用服务器，用于向中心服务器发送配置信息请求消息，并接收中心服务器返回的配置信息；

中心服务器，用于在接收到应用服务器发送的配置信息请求消息后，根据最大匹配原则对配置信息请求消息中匹配参数进行匹配，将匹配到的默认配置信息或特例化配置信息返回给应用服务器。

47.根据权利要求46所述的系统，其特征在于，

中心服务器，还用于接收终端发起的配置更新请求，对全局配置数据库中的配置信息进行更新，并找到对应的应用进程的连接，通过该连接下发配置更新请求，使得对应的应用进程重新从中心服务器获取配置信息，刷新配置信息并返回结果给中心服务器；

中心服务器将结果返回给终端。

48.根据权利要求46所述的系统，其特征在于，应用服务器包括：远程加载模块和本地加载模块；其中，

远程加载模块，用于向中心服务器发送配置信息请求消息，并接收中心服务器返回的配置信息；

本地加载模块，用于从应用服务器的本地获取配置信息；

应用服务器通过切换远程加载模块和本地加载模块，来实现远程从中心服务器获取配置信息的模式以及从本地获取配置信息的模式之间的切换。

49.根据权利要求43所述的系统，其特征在于，该系统进一步包括：与中心服务器连接的全局监控数据库，与全局监控数据库连接的监控服务器；每个应用服务器中还包括一个本机日志数据库；

全局监控数据库，用于保存不同监控策略；

应用服务器中的守护进程以及应用进程，通过中心服务器从全局监控数据库获取对应的监控策略，根据所获取的监控策略进行监控，将监控结果数据保存到本机日志数据库中，以及根据监控策略将相应的监控结果数据通过中心服务器上传到全局监控数据库中，并在获取到的数据超过阀值时附加报警标记；

监控服务器，用于展示全局监控数据库中的监控结果数据，并提示报警。

50.根据权利要求49所述的系统，其特征在于，

应用服务器中的守护进程根据所获取的监控策略对系统资源计数器进行监控；监控的指标包括：CPU指标、内存指标、磁盘指标、网卡流量指标或MySQL指标；

应用服务器中的应用进程中嵌入有程序内嵌计数器，应用服务器中的应用进程根据所获取的监控策略对程序内嵌计数器进行监控；

所述程序内嵌计数器包括：多个名字唯一的类别；每个类别包含多个固定的列和多个名字唯一的实例。

51.根据权利要求49或50所述的系统，其特征在于，

监控服务器，进一步用于对全局监控数据库中的监控策略进行更新，然后向指定应用服务器中的守护进程和/或应用进程发送监控策略更新通知；

所述指定应用服务器中的护进程和/或应用进程收到所述监控策略更新通知后，从全局配置服务器获取对应的更新后的监控策略。

52.根据权利要求40所述的系统，其特征在于，该系统进一步包括：扩展插件，用于实现对应用的注入式调试；

所述扩展插件用于在本地启动应用；所述启动的应用与代理服务器创建连接，并向代理服务器发送要调试应用的配置参数；所述要调试应用的配置参数限定指定范围内的用户；

代理服务器在接收到客户端请求消息后，首先匹配所述要调试应用的配置参数，如果匹配成功则将客户端请求消息发送给在插件上所述启动的应用处理，并将所述启动的应用返回的处理结果发送给客户端，如果匹配不成功，则将客户端请求分发给对应的应用所在的应用服务器。

53.根据权利要求40所述的系统，其特征在于，该应用服务平台系统进一步包括一个网关，该网关与其他应用服务平台系统中的网关进行通信，实现应用的跨应用服务平台系统访问；

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

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

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

54.根据权利要求53所述的系统，其特征在于，当要跨应用服务平台系统访问应用时，

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

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