一种应用服务平台系统

1.一种应用服务平台系统，其特征在于，该系统包括：代理服务器、由多个应用服务器组成的应用服务器集群、中心服务器和资源服务器，其中：
所述多个应用服务器之间通过集群连接方式构成应用服务器集群；
各代理服务器和所述应用服务器集群分别与中心服务器相连接；
各代理服务器和各资源服务器分别与服务器集群相连接。
2.根据权利要求1所述的系统，其特征在于，
所述多个代理服务器包括：超文本传输协议HT TP代理服务器、初始会话SIP代理服务器和短信系统SMS代理服务器；
所述资源服务器包括：数据库服务器、文件服务器和内存对象缓冲服务器。

一种应用服务平台系统\n技术领域\n[0001] 本实用新型涉及后台服务开发领域，特别是涉及一种应用服务平台系统。\n背景技术\n[0002] 在后台服务开发领域，大部分互联网应用和企业应用都会遇到系统规模变得日益复杂，并且系统规模日益增大后，开发成本和运维成本都急剧增高。\n[0003] 本实用新型致力于提供一种新的应用服务平台系统，以降低应用开发难度，提高部署的灵活性并降低部署的难度。\n实用新型内容\n[0004] 本实用新型提供了一种应用服务平台系统，该系统降低了应用开的难度，提高了部署的灵活性并降低了部署的难度。\n[0005] 为达到上述目的，本实用新型的技术方案是这样实现的：\n[0006] 本实用新型公开了一种应用服务平台系统，该系统包括：代理服务器、由多个应用服务器组成的服务器集群、中心服务器和资源服务器，其中：\n[0007] 代理服务器，用于接收客户端请求消息，通过查询中心服务器上的应用服务配置信息列表识别该客户端请求消息所对应的应用服务，然后通过查询中心服务器上的应用服务配置信息列表和应用服务运行信息列表获得对应的应用服务的路径，根据所获得的路径将客户端请求消息分发给对应的应用服务所在的应用服务器；接收应用服务器端返回的处理结果，并返回给客户端；\n[0008] 其中，应用服务配置信息列表包括如下信息：应用服务ID、应用服务名称、应用服务类型、应用进程名、应用服务元数据标注；应用服务运行列表包括如下信息：应用进程名称、应用服务路径；\n[0009] 每个应用服务器，用于负载应用服务并运行，将应用服务的运行信息写入中心服务器上的应用服务运行信息列表中；用于在接收到代理服务器发送的客户端请求消息时，将该客户端请求消息交给对应的应用服务进行处理；应用服务处理该客户端请求消息所请求的任务，并将处理结果返回给代理服务器；\n[0010] 中心服务器，用于接收外部上传的应用服务，将外部传入的该应用服务的描述信息保存到应用服务配置信息列表中，并在对应的应用服务器上部署该应用服务；\n[0011] 资源服务器，用于保存应用服务器上的各应用服务需要访问的数据资源。\n[0012] 由上述可见，本实用新型这种由上述代理服务器、应用服务器集群、中心服务器和资源服务器构成的应用服务平台系统，将分散的服务器资源在逻辑上整合到一起，极大降低了应用的开发难度，提高了部署的灵活性并降低了部署的难度。\n附图说明\n[0013] 图1是本实用新型实施例中的应用服务平台系统的一个实际组网示意图；\n[0014] 图2是本实用新型实施例中的单个应用服务器的结构示意图。\n具体实施方式\n[0015] 为了使本实用新型的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本实用新型进行详细描述。\n[0016] 图1是本实用新型实施例中的应用服务平台系统的实际组网示意图。如图1所示，该应用服务平台系统包括：代理服务器、由多个应用服务器组成的服务器集群、中心服务器和资源服务器，其中：\n[0017] 代理服务器，用于接收客户端请求消息，通过查询中心服务器上的应用服务配置信息列表识别该客户端请求消息所对应的应用服务，然后通过查询中心服务器上的应用服务配置信息列表和应用服务运行信息列表获得对应的应用服务的路径，根据所获得的路径将客户端请求消息分发给对应的应用服务所在的应用服务器；接收应用服务器端返回的处理结果，并返回给客户端；\n[0018] 其中，应用服务配置信息列表至少包括如下信息：应用服务ID、应用服务名称、应用服务类型、应用进程名、应用服务元数据标注；应用服务运行列表至少包括如下信息：应用进程名称、应用服务路径；\n[0019] 在本实施例中，代理服务器包括：超文本传输协议HTTP代理服务器、初始会话SIP代理服务器和短信系统SMS代理服务器。其中，HTTP代理服务器负责分发HTTP应用服务，SIP代理服务器负责与客户端的SIP长连接，SMS代理服务器负责分发短信上行应用服务。\n[0020] 每个应用服务器，用于负载应用服务并运行，将应用服务的运行信息写入中心服务器上的应用服务运行信息列表中；用于在接收到代理服务器发送的客户端请求消息时，将该客户端请求消息交给对应的应用服务进行处理；应用服务处理该客户端请求消息所请求的任务，并将处理结果返回给代理服务器；\n[0021] 中心服务器，用于接收外部上传的应用服务，将外部传入的该应用服务的描述信息保存到应用服务配置信息列表中，并在对应的应用服务器上部署该应用服务；\n[0022] 资源服务器，用于保存应用服务器上的各应用服务需要访问的数据资源。在本实施例中，资源服务器包括：数据库服务器、文件服务器和内存对象缓冲服务器。\n[0023] 在图1所示的应用服务平台系统中，代理服务器，进一步用于在接收到客户端请求消息时，根据客户端请求消息中的信息以及中心服务器上的应用服务配置信息列表，创建应用服务上下文，在所述客户端请求消息中添加应用服务上下文后分发给对应的应用服务器上的应用服务；\n[0024] 应用服务在接收到客户端请求消息后，在完成该客户端请求消息所请求的任务的过程中，根据应用服务上下文进行数据资源定位。\n[0025] 在图1所示的应用服务平台系统中，所述代理服务器，用于在接收到客户端请求消息时，根据该请求消息中的统一资源定位符URL，查找出中心服务器上的应用服务元数据标注字段包含与所述URL一致信息的应用服务配置信息列表，根据所查找出的应用服务配置信息列表中的应用服务名称识别出该客户端请求消息所对应的应用服务；所述代理服务器，用于根据所查找出的应用服务配置信息列表中的应用进程名，查找出中心服务器上的应用进程名称字段包含与所述应用进程名一致信息的应用服务运行信息列表，从所查找出的应用服务运行信息列表中获取应用服务的路径信息。\n[0026] 所述代理服务器，根据所查找出的应用服务配置信息列表中的元数据标注字段中的关于加载应用服务上下文信息，创建应用服务上下文。\n[0027] 在图1所示的应用服务平台系统中，中心服务器，进一步用于保存资源列表；资源列表包括如下信息：资源名称、资源类型、应用服务上下文类型、定位算法名称、定位算法参数；\n[0028] 应用服务在接收到客户端请求消息后，在完成该客户端请求消息所请求的任务的过程中根据应用服务上下文以及资源列表中的对应信息进行资源定位。\n[0029] 在图1所示的应用服务平台系统中，服务器集群中的多个应用服务器被分为多个不同的组，每组包含一台到多台服务器；中心服务器上保存有应用服务器列表和应用服务器分组列表；应用服务器列表包括如下信息：应用服务器名称、应用服务器所属的分组名称、应用服务器地址；应用服务器分组列表包括：应用服务器分组名称、分组中的应用服务器描述信息；\n[0030] 中心服务器在接收到外部上传的应用服务时，根据外部指令将该应用服务部署到单个应用服务器上，或者部署到属于同一组的多个服务器上。\n[0031] 这样，一个应用服务可以选择性地负载在某个组当中，也就是可以将核心的应用服务单独使用一组服务器，保证核心应用的资源使用及稳定性；而对刚上线的不稳定的应用服务使用一组单独的服务器，以剥离其中的影响，降低整个系统的风险。这种做法有利于进行整体资源的分配及网络策略的调整。\n[0032] 图2是本实用新型实施例中的单个应用服务器的结构示意图。如图2所示，主机进程是部署在每台应用服务器上的后台监控进程，负责进行应用服务的下载运行与部署。\n主机进程会与中心服务器建立一个长连接，通过这个长连接接受部署、更新、监控等系统指令。在一个应用服务器中几个应用服务可以运行在一个应用进程中，该应用进程也可以称为服务外壳。一个应用服务器上可以有多个应用进程。\n[0033] 运行于图1所示的应用服务平台系统的应用服务基于应用组件(AppBean)进行开发。应用服务的开发需要通过扩展定制好的几种AppBean进行，一种AppBean用于处理一种类型的业务请求，业务请求可能来自用户的客户端软件、浏览器、内部引用、或外部信令调用。\n[0034] 在应用服务的开发时刻，AppBean可以认为是一个抽象基类，所有的应用服务都会从AppBean这个基类派生。下面对AppBean进行介绍。\n[0035] ·AppBean的抽象接口\n[0036] -setup() 实现自安装\n[0037] -prepare()实现资源初始化\n[0038] -run() 实现运行\n[0039] ·AppBean的几个子类，每个子类可能会处理不同形式的信令，应用开发人员需要选择合适的子类去实现自己的应用，其中主要的子类有如下几种：\n[0040] -RemoteAppBean：每个RemoteAppBean处理一条特定的Rpc请求；\n[0041] -HttpAppBean：处理一条特定的Http请求；\n[0042] -MessageAppBean：处理一个特定的消息事务；\n[0043] 下面对以上的几种AppBean进行举例说明：\n[0044] RemoteAppBean\n[0045] ·处理一个特定的Rpc请求，可能来源于下列几个场景\n[0046] -来源于其他AppBean的引用；\n[0047] -来源于proxy；\n[0048] -来源于其他的系统外部服务；\n[0049] ·参数解释\n[0050] -请求参数，强类型定义；\n[0051] -应答参数，强类型定义；\n[0052] -特定类型的应用服务上下文AppContext；\n[0053] 调用一个从RemoteAppBean派生的应用服务时，必须提供这个应用服务在实现时所声明的特定类型的应用服务上下文(AppContext)，例如：\n[0054] 一个获取用户信息的应用服务会如下声明：\n[0055] 1.从RemoteAppBean中派生；\n[0056] a.请求参数为GetOption，为获取用户的一些选项参数\n[0057] b.应答参数为UserInfo，为用户信息的集合\n[0058] c.应用服务上下文为UserContext，为当前上下文的用户信息，UserContext用于标识用户ID\n[0059] 2.实现process方法处理业务逻辑\n[0060] HttpAppBean\n[0061] ·HttpAppBea用于处理一条特定的Http请求，Http请求可能来自于：\n[0062] -来自用户客户端和浏览器的直接请求，请求会通过HAP的智能7层负载进行反向代理转换\n[0063] -直接来源于其他服务器的请求\n[0064] ·实现一个特定的基于HttpAppBean的应用服务需要定制如下参数：\n[0065] -应用服务上下文：特定类型的上下文；\n[0066] -Context来源：从何处获取上下文；\n[0067] -URL前缀：此应用服务处理的URL前缀。(URL前缀通过@HttpPrefix元数据标注处理，后续会提到)\n[0068] 例如：开发一个用于用户统一登录认证的应用服务的流程为：\n[0069] 1.从HttpAppBean的基类派生；\n[0070] 2.指定应用服务上下文类型为SessionContext；\n[0071] 3.指定Context来源为cookie中的ssic字段；\n[0072] 4.实现process方法，读取HttpRequest，处理后返回HttpResponse给客户端。\n[0073] MessageAppBean\n[0074] ·MessageAppBean用于处理松耦合的消息事务，一个MessageAppBean处理一个特定类型的Message，MessageAppBean会监听此类型的消息队列，并在消息队列到达时开始处理；\n[0075] ·实现一个特定的MessageAppBean需要指定如下参数\n[0076] -应用服务上下文：特定类型的上下文；\n[0077] -消息类型：指定强类型Message；\n[0078] -事件名称(Message Name)：一个用于标记一类消息的全局唯一名称；\n[0079] ·MessageAppBean采用生产者/消费者模式\n[0080] -生产者会将产生的Message压入消息队列\n[0081] MessageQueueService.Enqueue(context，entity)；\n[0082] -作为消费者的MessageAppBean会在启动的时候回到消息队列服务中注册，并订阅特定类型的Queue，开始接受Queue中的内容；\n[0083] -生产者和消费者，允许一对多，多对多的映射关系。\n[0084] 以上对三种AppBean进行了举例介绍。\n[0085] 由上述的举例说明可以看出，各AppBean的参数都不太一样，但都包括AppContext这个参数。\n[0086] AppContext\n[0087] 在本实用新型的应用服务平台系统中，应用服务上下文(AppContext)是应用调用及资源定位的关键。这里应用调用包括代理服务器调用应用服务，以及应用服务内调用其他的应用服务，这两种应用都需要AppContext来实现目标应用服务的定位。AppContext从数据构成上分为两部分：\n[0088] ·Uri：为字符串格式，包含了用户的索引信息，负责定位，例如：\n[0089] -id：230302023\n[0090] -session：13910000001\n[0091] ·Data：附加数据\n[0092] -预定义好的强类型数据结构；\n[0093] -在某些场合，附加数据会由Proxy提供给后面的应用服务。\n[0094] 在本实用新型的系统中有一些预先定义好的上下文：\n[0095] -NullContext：预定义的空上下文，用在不需要上下文的场合；\n[0096] -SessionContext：预定义的只保存会话ID的上下文。\n[0097] 除标准AppContext，在使用本实用新型的应用服务系统平台进行扩展开发的时候，需要先定制业务相关的一些基础，AppContext就是其中之一。下面例举一个关于AppContext的具体实施例。\n[0098] 例如：使用本实用新型的应用服务平台系统开个一个即时消息(IM)系统，这个IM系统中的用户都采用一个整数id进行定位，那么可以根据如下方式定制这个IM系统的AppContex，从AppContext派生，命名为UserContext：\n[0099] ·Uri部分：“id：230302023”，表示用户的id，那么通过这个用户的id，可以定位用户的应用服务位置与数据库存储位置；\n[0100] ·Data部分：\n[0101] -用户的登录网络地址；\n[0102] -客户端类型等；\n[0103] 当定制了用户的UserContext，所有该系统内基于用户进行操作的AppBean都会用UserContext作为AppBean的参数，如：\n[0104] -获取用户资料；\n[0105] -设置用户资料；\n[0106] -获取好友列表等；\n[0107] 此外，在本实用新型的应用服务平台系统中，除了提供基于单个用户的AppContext外，还提供了基于群组的业务类型，开发基于群组的应用服务，也需要定制基于群组的AppContext，IM系统使用一个整数用于标识群组，从AppContext派生，命名为GroupContext，GroupContext的结构如下：\n[0108] ·Uri部分：“group：123123”，标识群组id，表示用户的id，那么通过这个群组的id，我们可以定位群组的应用服务位置，与数据库存储位置；\n[0109] ·Data部分：\n[0110] -群组的会话参数；\n[0111] -群组的授权等；\n[0112] 当定制了基于群组的GroupContext后，该系统内基于群组进行操作的所有AppBean都会用GroupContext作为AppBean的参数，如：\n[0113] -设置群组名称；\n[0114] -更新群组权限；\n[0115] -获取群离线消息等。\n[0116] 应用元数据标注\n[0117] 运行与本实用新型所示的平台系统上的一个应用服务可能会包含如下的元数据标注：\n[0118] 1.AppName(应用服务的名字和分类名)\n[0119] ·声明AppBean的名字以及分类名；\n[0120] -@AppName(category＝″Core″，name＝″AddBuddy″)\n[0121] 这里@xxx为Java语言对程序元数据的标注。\n[0122] ·Category：name全局唯一；\n[0123] ·Category可以用于AppBean的分类；\n[0124] -方便运维人员进行配置与分类；\n[0125] -在一个Category中，如果允许一个AppBean能够被其他Category中的AppBean访问，必须将这个AppBean声明成为公开或友好；\n[0126] ·@Public()：允许所有的AppBean访问；\n[0127] ·@Friendlly(“Core”)：只允许指定Category访问；\n[0128] ·@Friendlly(“Core：AddBuddy”)：只允许指定应用访问；\n[0129] 2.Stateful(应用服务的状态信息)\n[0130] @Stateful(″Presence″)\n[0131] ·当声明一个AppBean为有状态的，则此个AppBean可以将状态保存在本机内存中；\n[0132] ·没有标注@Stateful的应用均视为无状态应用，禁止使用本机内存进行状态的保存；\n[0133] ·如果一个Category中的多个AppBean声明的Stateful参数一样(“Presence”)，则这个几个AppBean启动到一个进程中，并且不允许单独热更新；\n[0134] ·@Stateful的应用在热更新的时候会丢失状态，所以尽量用memcache方式去代替，建议仅在某些性能要求很高的领域启动；\n[0135] ·当某个AppBean被声明为Stateful时，针对这个AppBean的访问会采用这个AppBean的AppContext绑定的一致性Hash的方式进行路由；\n[0136] 3.BeforeHandler(前置业务处理项)\n[0137] ·在某个AppBean接管控制之前优先处理前置业务，比如配额判断，日志记录，安全审核等；\n[0138] ·这个Handler可以中断业务的运行，修改业务的入口参数，可以异步处理；\n[0139] @BeforeHandler(type ＝ SecurityQuotaHandler.class，params ＝(″AddBuddy“))；\n[0140] ·实现一个BeforeHandler需要实现emoteAppBeanHandler＜A，R，C＞接口；\n[0141] -void run(RemoteAppHandlerTx＜A，R，C＞tx)；\n[0142] 4.AfterHandler(后置业务处理项)\n[0143] ·可以指定在业务成功后进行处理，或失败后进行，或不管成功失败都进行；\n[0144] @AfterHandler(type＝OperationLogHandler.class，result＝OpResults.All，params＝(″AddBuddy“))；\n[0145] ·Handler能够拿到完整的请求参数，及应用在context中添加的上下文数据；\n[0146] ·Handler的处理结果不会再影响到AppBean的返回结果\n[0147] ·实现方法与B eforeHandler相同。\n[0148] 5.\n[0149] HttpPrefix(HTTP前缀，只针对HttpAppBean)\n[0150] ·用于标注一个HttpAppBean处理的Http请求范围；\n[0151] ·如：@HttpPrefix(″/login.do″)；\n[0152] -表示该HttpAppB ean处理以login.do为起始的http请求。\n[0153] Message Name(事件名称，只针对MessageAppBean)\n[0154] ·用于标注一个MessageAppBean的名称；\n[0155] ·如：@Message Name\n[0156] 6.ContextLoader(加载应用服务上下文信息)\n[0157] ·用于标注一个AppBean如何加载AppContext\n[0158] ·如：@ContextLoader(name＝″CookieParser″)\n[0159] -表示通过名为CookieParser的程序去处理处理Context；\n[0160] -CookieParser程序内置在Proxy当中，通过处理HttpRequest中的Cookie字段去加载用户相关信息。\n[0161] 前面介绍了基于AppBean的应用服务开发过程。可以看出在本实用新型中应用服务开发的最小粒度为AppBean。接下来介绍开发完成的应用服务如何在应用服务系统平台上部署以及运行的过程。\n[0162] 前面提到应用服务系统平台中的服务器集群中的应用服务器可以分成多个组，一个应用服务可以部署在一组应用服务器上，因此首先介绍一下本实用新型中的应用服务器的分组配置情况。\n[0163] 在本实用新型中，能够运行应用服务的应用服务器需要在全局统一配置，具体来说在中心服务上配置全局的应用服务器列表和应用服务器分组列表。\n[0164] 应用服务器列表如表1所示：\n[0165] \n 字段名称 字段类型 主键 描述\n ServerName Varchar Y 应用服务器名称\n ServerGroup Varchar 应用服务器分组名称\n ServerAddress Varchar 应用服务器地址\n[0166] 表1\n[0167] 由表1可见，应用服务器列表包括如下信息：应用服务器名称、应用服务器所属的分组名称、应用服务器地址。\n[0168] 应用服务器分组列表如表2所示：\n[0169] \n 字段名称 字段类型 主键 描述\n GroupName varchar Y 应用服务器分组名称\n GroupDesc Varchar 应用服务器描述信息\n[0170] 表2\n[0171] 由表2可见，应用服务器分组列表包括：应用服务器分组名称、分组中的应用服务器描述信息。\n[0172] 中心服务器在接收到外部上传的应用服务时，根据外部指令将该应用服务部署到单个应用服务器上，或者部署到属于同一组的多个服务器上。\n[0173] 在实际应用中，多台应用服务器可以被分为不同的组，用于运行不同的应用服务，应用服务器分组的好处如下：1.将核心应用专门指定应用服务器组，可以保证核心应用的资源使用及稳定性；2.给一些新增的不稳定的应用指定单独的应用服务器组，可以降低整个系统的风险；3.有利于进行整体资源的分配及网络策略的调整。\n[0174] 加载应用服务到应用服务器的过程\n[0175] 在本实用新型中，开发完成的应用服务会加载到服务器集群中的应用服务器上运行，并将代理服务器针对此应用服务的路由定制到负载该应用服务的应用服务器上。这个过程包括如下步骤：\n[0176] -开发人员将开发完成的应用服务的代码进行编译，生成用于部署的部署包(jar包)；\n[0177] -运维人员通过加载工具(一般为AppLoader)，通过元数据查找自动分析部署包中的应用类型及元数据标注，将分析出的数据写入中心服务器上的应用服务配置信息列表中，并将部署包上传到中心服务器上。\n[0178] 应用服务配置信息列表(以下称为Application表)如表3所示：\n[0179] \n[0180] 表3\n[0181] 在表3中，关于Annotations字段：AppLoader会通过分析Java应用类与应用类包含的元数据标注，并提取出每个AppBean的类型信息与元数据标注信息，并通过JS ON(JavaScript Object Notation)格式的字符串保存在Application表的Annotations字段，具体格式如下：\n[0182] Annotations字段包含classInfo子字段与classAnnotations子字段；\n[0183] classInfo字段中包含，当前类型，基础类型，及基础类型的泛型参数；\n[0184] classAnnotations字段包含该AppBean包含的每一个元数据标注，元数据标注的每个参数，通过”key”，“value”方式存储。\n[0185] 在表3中，除了WorkerPackage(应用服务部署包名称)、ServerGroup(应用服务器组)及Enabled(是否启用)字段，其余的字段的数据均由加载工具自动写入中心服务器中的应用服务配置信息列表中。这避免了人工写入的麻烦及错误风险。\n[0186] -运维人员选择应用服务部署包名称、应用服务器组以及是否启用的选项，更新Application表表。\n[0187] -中心服务器在运维人员的指令下，向Application表所示的应用服务器组中的各应用服务器发送加载Application表所指示的应用服务部署包的加载指令。\n[0188] -应用服务器上主机进程接收到加载指令后，下载对应的应用服务的部署包，并启动应用进程(AppWorker)，该应用进程运行该应用服务，并将该应用服务的运行状态写入中心服务器中的应用服务运行列表中。\n[0189] 应用服务运行列表(以下称为Running Worker表)如表4所示：\n[0190] \n[0191] 表4\n[0192] 每一个启动的应用进程都会与中心服务器建立连接，并在全局的应用服务运行列表中添加一条如表4所示的运行状态记录。\n[0193] 在表4中，应用服务路径个格式可以为：\n[0194] rpc＝tcp://192.168.1.100：8000；http＝http://192.168.1.100：8080。\n[0195] 应用服务的路由策略\n[0196] 代理服务器(proxy)需要调用某个应用服务，或者一个应用服务需要调用另一个应用服务时，正是通过应用服务配置信息列表和应用服务运行列表进行定位的。\n[0197] 例如，在本实用新型的一个实施例中，查找一个Http应用服务的地址的流程如下：\n[0198] 1.代理服务器接收到客户端或浏览器发出的Http请求；\n[0199] 2.代理服务器访问中心服务器，从Application表的Annotations字段(应用服务元数据标注字段)中，找到HttpPrefix(一种元数据标注信息)与Http请求中请求URL相符的一条记录；\n[0200] 具体来说，枚举所有Application表中的记录，找到Annotations中的@HttpPrefix元数据标注，并判断请求的URL是否与HttpPrefix的值为起始；\n[0201] 3.代理服务器根据步骤2中所确定的一条记录中的Annotations字段(应用服务元数据标注字段)的信息生成AppContext；\n[0202] 具 体来 说，找 到Annotations字 段 的@ContextLoader信 息，找 到 符 合ContextLoader取值的赋值函数，从Http请求报文的Cookie字段中提取信息作为函数的输入，运行函数，得到AppContext；\n[0203] 4.代理服务器根据步骤2中所确定的一条记录中的WorkerName字段(应用进程名段)，从Running Worker表的中找出AppWorkerName字段(运行的应用进程名称)与之相符的记录；可以有多条记录与之相符。\n[0204] 5.代理服务器根据步骤2中所确定的一条记录中的Annotations字段中的@Stateful配置进行如下选择：\n[0205] a.如果为‘true’，则使用一致性哈希的方式从多条Running Worker中通过AppContext信息选出一条记录；这里，一致性哈希是通过AppContext的Uri字符串计算哈希值，选择哈希值所对应的一条记录；具体的哈希算法可采用KETAMA算法；\n[0206] b.如果为‘false’，则随机选出一条RuningWorker记录；\n[0207] 6.提取所选出的RuningWorker记录中的ServiceURLs字段(应用服务路径字段)中的地址信息，根据给地址信息实现应用服务的调用。\n[0208] 在上面的例子中，代理服务器接收到的是针对HttpAppBean的请求，因此根据该请求中的URL找Application表中的对应的HttpPrefix，以找到对应的应用服务。如果代理服务器接收到的是与RemoteAppBean对应的Rpc请求，则直接根据该Rpc请求中的远程调用服务名称(RemoteAppName)查找应用服务名称(AppName)字段与其一致Application表，该Application表即为部署该Rpc请求对应的RemoteAppBean时所生成的表。如果代理服务器接收到的是与MessageAppBean对应的Message消息，则根据该消息中的事件名称，从Application表的Annotations字段找到MessageName与所述事件名称相符的一条记录，该条记录即为处理该消息的应用服务所应用的表格信息。\n[0209] 在本实用新型中，定义并实现一个具有某种业务功能的应用服务，这个应用服务势必要访问各种资源，如数据库、文件服务器、内存对象缓冲服务器或其他提供应用服务。\n在本实用新型的一个实施例中，这些资源都不是单点服务，也就是同一个类型的数据库可能存在多个纵向拆分的实例，在本实施例中，将一个应用服务能够访问的资源绑定在了实现时声明的AppContext上。\n[0210] 例如，在前面我们声明了一个获取用户信息的应用服务，名称GetUserInfoApp，在该应用服务的实现环节读取用户数据库(UserDB)，并将结果返回。具体过程如下：\n[0211] 1.代理服务器接收来自于客户端的Http请求；\n[0212] 2.代理服务器通过Http请求的URL判断该请求对应的应用服务；具体为代理服务器通过方位中心服务器上的各\n[0213] Application表，找到Annotations字段中的@HttpPrefix与Http请求的URL一致的Application表，该表对应的应用服务即为该Http请求所对应的应用服务；\n[0214] 3.根据第2步的判断代理服务器识别该请求对应的应用服务是GetUserInfoAPP的请求，并需要UserContext作为上下文参数；\n[0215] 4.代理服务器通过访问中心服务器上的对应的Application列表，根据其Annotations字段的@ContextLoader信息创建UserContext；\n[0216] 5.代理服务器在来自客户端的Http请求中添加所创建的UserContext数据，通过查询Application列表和RunningWorker列表获得GetUserInfoAPP的路径后，将Http请求转发到GetUserInfoAPP所在的应用服务器；\n[0217] 6.应用服务器上的运行GetUserInfoAPP的应用进程接收到Http请求后，提取UserContext，并交给GetUserInfoAPP处理；\n[0218] 7.GetUserInfoAPP读取UserDB，在读取UserDB的时候，通过UserContext中的id信息进行UserDB的定位；\n[0219] 8.GetUserInfoAPP组织返回报文，并返回给代理服务器；\n[0220] 9.代理服务器将返回报文返回给客户端。\n[0221] 在上述过程的步骤7中，通过资源(Resource)表进行定位。在本实用新型的一个实施例中的资源表如表5所示：\n[0222] \n[0223] 表5\n[0224] 可以通过实现不同的定位函数(Locator)，来实现针对不同资源的不同定位方式。\n例如在上例中，资源表的具体配置如表6所示：\n[0225] \n 字段名称 字段说明 示例取值\n ResourceName 资源名称 UserDB\n ResourceType 资源类型 Database\n ContextType 定位依赖的Context UserContext\n LocatorName 定位算法 ModDatabaseLocator\n LocatorParams 定位算法的参数 5\n[0226] 表6\n[0227] 则在步骤7中使用id：1001定位UserDB时，ModDatabaseLocator会取出1001，并将1001除5，取余数为1，返回名为UserDB.1的数据库实例。\n[0228] 由上述可见，本实用新型这种由上述代理服务器、应用服务器集群、中心服务器和资源服务器构成的应用服务平台系统，将分散的服务器资源在逻辑上整合到一起，极大降低了应用的开发难度，提高了部署的灵活性并降低了部署的难度。\n[0229] 以上所述仅为本实用新型的较佳实施例而已，并不用以限制本实用新型，凡在本实用新型的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本实用新型保护的范围之内。