专利名称：一种应用服务平台系统和一种开发应用服务的方法
技术领域：
本发明涉及后台服务开发领域，特别是涉及一种应用服务平台系统和一种开发应用服务的方法。
背景技术：
在后台服务开发领域，大部分互联网应用和企业应用都会遇到系统规模变得日益复杂，并且系统规模日益增大后，开发成本和运维成本都急剧增高。本发明致力于降低应用开发难度，提高部署的灵活性并降低部署的难度。
发明内容
本发明提供了一种应用服务平台系统，该系统降低了应用开的难度，提高了部署的灵活性并降低了部署的难度。本发明还提供了一种开发应用服务平台的方法。为达到上述目的，本发明的技术方案是这样实现的本发明公开了一种应用服务平台系统，该系统包括代理服务器、由多个应用服务器组成的服务器集群、中心服务器和资源服务器，其中代理服务器，用于接收客户端请求消息，通过查询中心服务器上的应用服务配置信息列表识别该客户端请求消息所对应的应用服务，然后通过查询中心服务器上的应用服务配置信息列表和应用服务运行信息列表获得对应的应用服务的路径，根据所获得的路径将客户端请求消息分发给对应的应用服务所在的应用服务器；接收应用服务器端返回的处理结果，并返回给客户端；其中，应用服务配置信息列表包括如下信息应用服务ID、应用服务名称、应用服务类型、应用进程名、应用服务元数据标注；应用服务运行列表包括如下信息应用进程名称、应用服务路径；每个应用服务器，用于负载应用服务并运行，将应用服务的运行信息写入中心服务器上的应用服务运行信息列表中；用于在接收到代理服务器发送的客户端请求消息时， 将该客户端请求消息交给对应的应用服务进行处理；应用服务处理该客户端请求消息所请求的任务，并将处理结果返回给代理服务器；中心服务器，用于接收外部上传的应用服务，将外部传入的该应用服务的描述信息保存到应用服务配置信息列表中，并在对应的应用服务器上部署该应用服务；资源服务器，用于保存应用服务器上的各应用服务需要访问的数据资源。本发明还公开了一种运行于上述的应用服务平台系统的应用服务的方法，该方法包括基于应用组件AppBean开发应用服务，一种AppBean处理一种类型的业务请求；在基于一种AppBean开发一个应用服务时，需要确定的参数包括应用服务上下文。
由上述可见，本发明这种由上述代理服务器、应用服务器集群、中心服务器和资源服务器构成的应用服务平台系统，将分散的服务器资源在逻辑上整合到一起，极大降低了应用的开发难度，提高了部署的灵活性并降低了部署的难度。
图1是本发明实施例中的应用服务平台系统的逻辑结构示意图；图2是本发明实施例中的应用服务平台系统的一个实际组网示意图；图3是本发明实施例中的单个应用服务器的结构示意图。
具体实施例方式为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。图1是本发明实施例中的应用服务平台系统的逻辑结构示意图。在图1中，各逻辑部分的描述如下※代理(Proxy)-用于分发客户端的消息，并维护客户端状态(如长连接)；-服务· SAP 维护与客户端的SIP长连接；· HAP 负责分发Http应用；· SMSP 负责分发短信上行应用；※应用主机集群(AppEngineHosts)-负载实际的应用服务运行，可进行服务器分组；※基础服务(Base Service)-平台内部需求的一些核心应用或独立应用；※资源(Resource)-提供给平台使用的系统资源，如·数据库(Database)·文件(File)·内存对象缓冲服务器(Memcache)※中心(Center)-整个系统的管控中心，用于看管所用应用服务的部署、分发、更新等系统管理操作。图2是本发明实施例中的应用服务平台系统的一个实际组网示意图。如图2所示， 该应用服务平台系统包括代理服务器、由多个应用服务器组成的服务器集群、中心服务器和资源服务器，其中代理服务器，用于接收客户端请求消息，通过查询中心服务器上的应用服务配置信息列表识别该客户端请求消息所对应的应用服务，然后通过查询中心服务器上的应用服务配置信息列表和应用服务运行信息列表获得对应的应用服务的路径，根据所获得的路径将客户端请求消息分发给对应的应用服务所在的应用服务器；接收应用服务器端返回的处理结果，并返回给客户端；其中，应用服务配置信息列表至少包括如下信息应用服务ID、应用服务名称、应用服务类型、应用进程名、应用服务元数据标注；应用服务运行列表至少包括如下信息应用进程名称、应用服务路径；在本实施例中，代理服务器包括超文本传输协议HTTP代理服务器、初始会话SIP 代理服务器和短信系统SMS代理服务器。其中，HTTP代理服务器负责分发HTTP应用服务， SIP代理服务器负责与客户端的SIP长连接，SMS代理服务器负责分发短信上行应用服务。每个应用服务器，用于负载应用服务并运行，将应用服务的运行信息写入中心服务器上的应用服务运行信息列表中；用于在接收到代理服务器发送的客户端请求消息时， 将该客户端请求消息交给对应的应用服务进行处理；应用服务处理该客户端请求消息所请求的任务，并将处理结果返回给代理服务器；中心服务器，用于接收外部上传的应用服务，将外部传入的该应用服务的描述信息保存到应用服务配置信息列表中，并在对应的应用服务器上部署该应用服务；资源服务器，用于保存应用服务器上的各应用服务需要访问的数据资源。在本实施例中，资源服务器包括数据库服务器、文件服务器和内存对象缓冲服务器。在图2所示的应用服务平台系统中，代理服务器，进一步用于在接收到客户端请求消息时，根据客户端请求消息中的信息以及中心服务器上的应用服务配置信息列表，创建应用服务上下文，在所述客户端请求消息中添加应用服务上下文后分发给对应的应用服务器上的应用服务；应用服务在接收到客户端请求消息后，在完成该客户端请求消息所请求的任务的过程中，根据应用服务上下文进行数据资源定位。在图2所示的应用服务平台系统中，所述代理服务器，用于在接收到客户端请求消息时，根据该请求消息中的统一资源定位符URL，查找出中心服务器上的应用服务元数据标注字段包含与所述URL —致信息的应用服务配置信息列表，根据所查找出的应用服务配置信息列表中的应用服务名称识别出该客户端请求消息所对应的应用服务；所述代理服务器，用于根据所查找出的应用服务配置信息列表中的应用进程名，查找出中心服务器上的应用进程名称字段包含与所述应用进程名一致信息的应用服务运行信息列表，从所查找出的应用服务运行信息列表中获取应用服务的路径信息。所述代理服务器，根据所查找出的应用服务配置信息列表中的元数据标注字段中的关于加载应用服务上下文信息，创建应用服务上下文。在图2所示的应用服务平台系统中，中心服务器，进一步用于保存资源列表；资源列表包括如下信息资源名称、资源类型、应用服务上下文类型、定位算法名称、定位算法参数；应用服务在接收到客户端请求消息后，在完成该客户端请求消息所请求的任务的过程中根据应用服务上下文以及资源列表中的对应信息进行资源定位。在图2所示的应用服务平台系统中，服务器集群中的多个应用服务器被分为多个不同的组，每组包含一台到多台服务器；中心服务器上保存有应用服务器列表和应用服务器分组列表；应用服务器列表包括如下信息应用服务器名称、应用服务器所属的分组名称、应用服务器地址；应用服务器分组列表包括应用服务器分组名称、分组中的应用服务器描述信息；中心服务器在接收到外部上传的应用服务时，根据外部指令将该应用服务部署到单个应用服务器上，或者部署到属于同一组的多个服务器上。这样，一个应用服务可以选择性地负载在某个组当中，也就是可以将核心的应用服务单独使用一组服务器，保证核心应用的资源使用及稳定性；而对刚上线的不稳定的应用服务使用一组单独的服务器，以剥离其中的影响，降低整个系统的风险。这种做法有利于进行整体资源的分配及网络策略的调整。图3是本发明实施例中的单个应用服务器的结构示意图。如图3所示，主机进程是部署在每台应用服务器上的后台监控进程，负责进行应用服务的下载运行与部署。主机进程会与中心服务器建立一个长连接，通过这个长连接接受部署、更新、监控等系统指令。在一个应用服务器中几个应用服务可以运行在一个应用进程中，该应用进程也可以称为服务外壳。一个应用服务器上可以有多个应用进程。在本发明中，基于图1和图2所示的应用服务平台系统，提供了基于应用组件 (AppBean)的应用服务开发模式。在本发明中，应用服务的开发需要通过扩展定制好的几种 AppBean进行，一种AppBean用于处理一种类型的业务请求，业务请求可能来自用户的客户端软件、浏览器、内部引用、或外部信令调用。在应用服务的开发时刻，AppBean可以认为是一个抽象基类，所有的应用服务都会从AppBean这个基类派生。下面对AppBean进行介绍。· AppBean 的抽象接口-setup ()实现自安装-prepare ()实现资源初始化-run ()实现运行· AppBean的几个子类，每个子类可能会处理不同形式的信令，应用开发人员需要选择合适的子类去实现自己的应用，其中主要的子类有如下几种-RemoteAppBean 每个 RemoteAppBean 处理一条特定的 Rpc 请求；-HttpAppBean 处理一条特定的 Http 请求；-MessageAppBean 处理一个特定的消息事务；下面对以上的几种AppBean进行举例说明RemoteAppBean·处理一个特定的Rpc请求，可能来源于下列几个场景-来源于其他AppBean的引用；-来源于proxy ；-来源于其他的系统外部服务；·参数解释-<A>请求参数，强类型定义；-<R>应答参数，强类型定义；-<C>特定类型的应用服务上下文AppContext ；调用一个从RemoteAppBean派生的应用服务时，必须提供这个应用服务在实现时所声明的特定类型的应用服务上下文(AppContext)，例如
—个获取用户信息的应用服务会如下声明1.从 RemoteAppBearKGetOption, Userlnfo, UserContext)中派生；a.请求参数<A>为GetOption，为获取用户的一些选项参数b.应答参数<R>为Userlnfo，为用户信息的集合c.应用服务上下文<C>为herContext，为当前上下文的用户信息，UserContext 用于标识用户ID2.实现process方法处理业务逻辑HttpAppBean· HttpAppBea用于处理一条特定的Http请求，Http请求可能来自于-来自用户客户端和浏览器的直接请求，请求会通过HAP的智能7层负载进行反向代理转换-直接来源于其他服务器的请求·实现一个特定的基于HttpAppBean的应用服务需要定制如下参数-应用服务上下文<C>特定类型的上下文；-Context来源从何处获取上下文<C> ；-URL前缀此应用服务处理的URL前缀。(URL前缀通过OHttpPrefix元数据标注处理，后续会提到)例如开发一个用于用户统一登录认证的应用服务的流程为1.从 HttpAppBean 的基类派生；2.指定应用服务上下文类型<C>为kssionContext ；3.指定Context来源为cookie中的ssic字段；4.实现process方法，读取HttpRequest,处理后返回HttpResponse给客户端。MessageAppBean'MessageAppBean用于处理松耦合的消息事务，一个MessageAppBean处理一个特定类型的Message，MessageAppBean会监听此类型的消息队列，并在消息队列到达时开始处理；·实现一个特定的MessageAppBean需要指定如下参数-应用服务上下文<C>特定类型的上下文；-消息类型<A>指定强类型Message ；-事件名称(MessageName)一个用于标记一类消息的全局唯一名称；· MessageAppBean采用生产者/消费者模式-生产者会将产生的Message压入消息队列MessageQueueService. Enqueue(context,entity)；-作为消费者的MessageAppBean会在启动的时候回到消息队列服务中注册，并订阅特定类型的Queue，开始接受Queue中的内容；-生产者和消费者，允许一对多，多对多的映射关系。以上对三种AppBean进行了举例介绍。由上述的举例说明可以看出，各AppBean的参数都不太一样，但都包括 AppContext这个参数。
AppContext在本发明的应用服务平台系统中，应用服务上下文(AppContext)是应用调用及资源定位的关键。这里应用调用包括代理服务器调用应用服务，以及应用服务内调用其他的应用服务，这两种应用都需要AppContext来实现目标应用服务的定位。AppContext从数据构成上分为两部分-Uri 为字符串格式，包含了用户的索引信息，负责定位，例如-id :230302023-session :13910000001.Data:附加数据-预定义好的强类型数据结构；-在某些场合，附加数据会由Proxy提供给后面的应用服务。在本发明的系统中有一些预先定义好的上下文-NullContext 预定义的空上下文，用在不需要上下文的场合；-SessionContext 预定义的只保存会话ID的上下文。除标准AppContext，在使用本发明的应用服务系统平台进行扩展开发的时候，需要先定制业务相关的一些基础，AppContext就是其中之一。下面例举一个关于AppContext 的具体实施例。例如使用本发明的应用服务平台系统开个一个即时消息(IM)系统，这个IM 系统中的用户都采用一个整数id进行定位，那么可以根据如下方式定制这个IM系统的 AppContex,从 AppContext 派生，命名为 UserContext · Uri部分:"id :230302023”，表示用户的id，那么通过这个用户的id，可以定位用户的应用服务位置与数据库存储位置；· Data 部分-用户的登录网络地址；-客户端类型等；当定制了用户的herContext，所有该系统内基于用户进行操作的AppBean都会用 UserContext 作为 AppBean 的 <C> 参数，如-获取用户资料；-设置用户资料；-获取好友列表等；此外，在本发明的应用服务平台系统中，除了提供基于单个用户的AppContext 外，还提供了基于群组的业务类型，开发基于群组的应用服务，也需要定制基于群组的AppContext，IM系统使用一个整数用于标识群组，从AppContext派生，命名为 GroupContext, GroupContext 的结构如下· Uri部分“group 123123”，标识群组id，表示用户的id，那么通过这个群组的 id，我们可以定位群组的应用服务位置，与数据库存储位置；· Data 部分-群组的会话参数；-群组的授权等；
当定制了基于群组的GroupContext后，该系统内基于群组进行操作的所有 AppBean 都会用 GroupContext 作为 AppBean 的 <C> 参数，如-设置群组名称；-更新群组权限；-获取群离线消息等。应用元数据标注在本发明中，一个应用服务可能会包含如下的元数据标注1. AppName (应用服务的名字和分类名)·声明AppBean的名字以及分类名；-OAppName (category = 〃 Core “ ,name=" AddBuddy “)这里@ΧΧΧ为Java语言对程序元数据的标注。· Category :name 全局唯一；· Category 可以用于 AppBean 的分类；-方便运维人员进行配置与分类；-在一个Category中，如果允许一个AppBean能够被其他Category中的AppBean 访问，必须将这个AppBean声明成为公开或友好；· iPubIicO 允许所有的 AppBean 访问；· iFriendlly( “Core，，)只允许指定 Category 访问；· OFriendlly( "Core =AddBuddy")只允许指定应用访问；2. Stateful (应用服务的状态信息)OStateful(〃 Presence")·当声明一个AppBean为有状态的，则此个AppBean可以将状态保存在本机内存中；·没有标注OStateful的应用均视为无状态应用，禁止使用本机内存进行状态的保存； 如果一个 Category 中的多个 AppBean 声明的 Stateful 参数一样(“Presence”)， 则这个几个AppBean启动到一个进程中，并且不允许单独热更新；· iStateful的应用在热更新的时候会丢失状态，所以尽量用memcache方式去代替，建议仅在某些性能要求很高的领域启动；·当某个AppBean被声明为Stateful时，针对这个AppBean的访问会采用这个 AppBean的AppContext绑定的一致性Hash的方式进行路由；3. BeforeHandler (前置业务处理项)·在某个AppBean接管控制之前优先处理前置业务，比如配额判断，日志记录，安全审核等；·这个Handler可以中断业务的运行，修改业务的入口参数，可以异步处理；iBeforeHandler (type = SecurityQuotaHandler. class, params = ("AddBuddy “))；·实现一个 BeforeHandler 需要实现 emoteAppBeanHandler<A, R，C> 接口 ；-void run (RemoteAppHandlerTx<A, R, C>tx)；
4. AfterHandler (后置业务处理项)·可以指定在业务成功后进行处理，或失败后进行，或不管成功失败都进行；OAfterHandler (type = OperationLogHandler. class,result = OpResults. All, params = (〃 AddBuddy “))；· Handler能够拿到完整的请求参数，及应用在context中添加的上下文数据；· Handler的处理结果不会再影响到AppBean的返回结果·实现方法与BeforeHandler相同。5.HttpPrefix (HTTP 前缀，只针对 HttpAppBean)·用于标注一个HttpAppBean处理的Http请求范围；.^niOHttpPrefixr /login, do");-表示该HttpAppBean处理以login, do为起始的http请求。Message Name (事件名称，只针对 MessageAppBean)·用于标注一个MessageAppBean的名称；·如@Message Name6. ContextLoader (加载应用服务上下文信息) 用于标注一个AppBean如何加载AppContext 如@ContextLoader (name = 〃 CookieParser〃 )-表示通过名为CookieParser的程序去处理处理Context；-CookieParser程序内置在Proxy当中，通过处理HttpRequest中的Cookie字段去加载用户相关信息。前面介绍了基于AppBean的应用服务开发过程。可以看出在本发明中应用服务开发的最小粒度为AppBean。接下来介绍开发完成的应用服务如何在应用服务系统平台上部署以及运行的过程。前面提到应用服务系统平台中的服务器集群中的应用服务器可以分成多个组，一个应用服务可以部署在一组应用服务器上，因此首先介绍一下本发明中的应用服务器的分组配置情况。在本发明中，能够运行应用服务的应用服务器需要在全局统一配置，具体来说在中心服务上配置全局的应用服务器列表和应用服务器分组列表。应用服务器列表如表1所示
权利要求
1.一种应用服务平台系统，其特征在于，该系统包括代理服务器、由多个应用服务器组成的服务器集群、中心服务器和资源服务器，其中代理服务器，用于接收客户端请求消息，通过查询中心服务器上的应用服务配置信息列表识别该客户端请求消息所对应的应用服务，然后通过查询中心服务器上的应用服务配置信息列表和应用服务运行信息列表获得对应的应用服务的路径，根据所获得的路径将客户端请求消息分发给对应的应用服务所在的应用服务器；接收应用服务器端返回的处理结果，并返回给客户端；其中，应用服务配置信息列表包括如下信息应用服务ID、应用服务名称、应用服务类型、应用进程名、应用服务元数据标注；应用服务运行列表包括如下信息应用进程名称、 应用服务路径；每个应用服务器，用于负载应用服务并运行，将应用服务的运行信息写入中心服务器上的应用服务运行信息列表中；用于在接收到代理服务器发送的客户端请求消息时，将该客户端请求消息交给对应的应用服务进行处理；应用服务处理该客户端请求消息所请求的任务，并将处理结果返回给代理服务器；中心服务器，用于接收外部上传的应用服务，将外部传入的该应用服务的描述信息保存到应用服务配置信息列表中，并在对应的应用服务器上部署该应用服务； 资源服务器，用于保存应用服务器上的各应用服务需要访问的数据资源。
2.根据权利要求1所述的系统，其特征在于，代理服务器，进一步用于在接收到客户端请求消息时，根据客户端请求消息中的信息以及中心服务器上的应用服务配置信息列表，创建应用服务上下文，在所述客户端请求消息中添加应用服务上下文后分发给对应的应用服务器上的应用服务；应用服务在接收到客户端请求消息后，在处理该客户端请求消息所请求的任务的过程中，根据应用服务上下文进行数据资源定位。
3.根据权利要求2所述的系统，其特征在于，中心服务器，进一步用于保存资源列表；资源列表包括如下信息资源名称、资源类型、应用服务上下文类型、定位算法名称、定位算法参数；应用服务在接收到客户端请求消息后，在完成该客户端请求消息所请求的任务的过程中根据应用服务上下文以及资源列表中的对应信息进行资源定位。
4.根据权利要求1所述的系统，其特征在于，所述多个代理服务器包括超文本传输协议HTTP代理服务器、初始会话SIP代理服务器和短信系统SMS代理服务器；所述资源服务器包括数据库服务器、文件服务器和内存对象缓冲服务器。
5.根据权利要求1所述的系统，其特征在于，所述服务器集群中的多个应用服务器被分为多个不同组； 所述中心服务器上保存有应用服务器列表和应用服务器分组列表； 应用服务器列表包括如下信息应用服务器名称、应用服务器所属的分组名称、应用服务器地址；应用服务器分组列表包括应用服务器分组名称、分组中的应用服务器描述信息； 中心服务器，用于在接收到外部上传的应用服务时，根据外部指令将该应用服务部署到单个应用服务器上，或者部署到属于同一组的多个服务器上。
6.根据权利要求1所述的系统，其特征在于，所述代理服务器，用于在接收到客户端请求消息时，根据该请求消息中的统一资源定位符URL，查找出中心服务器上的应用服务元数据标注字段包含与所述URL —致信息的应用服务配置信息列表，根据所查找出的应用服务配置信息列表中的应用服务名称识别出该客户端请求消息所对应的应用服务；或者，用于在接收到客户端的请求消息时，根据该请求消息中的远程调用服务名称，查找出中心服务器上应用服务名称字段与所述远程调用服务名称一致的应用服务配置信息列表， 根据所查找出的应用服务名称字段识别出该请求消息所对应的应用服务；或者，用于在接收到客户端的请求消息时，根据该请求消息中的事件名称，查找出中心服务器上的应用服务元数据标注字段包含与所述事件名称一致信息的应用服务配置信息列表， 根据所查找出的应用服务配置信息列表中的应用服务名称识别出该客户端请求消息所对应的应用服务；所述代理服务器，用于根据所查找出的应用服务配置信息列表中的应用进程名，查找出中心服务器上的应用进程名称字段包含与所述应用进程名一致信息的应用服务运行信息列表，从所查找出的应用服务运行信息列表中获取应用服务的路径信息。
7.根据权利要求2所述的系统，其特征在于，所述代理服务器，用于在接收到客户端请求消息时，根据该请求消息中的统一资源定位符URL，查找出中心服务器上的应用服务元数据标注字段包含与所述URL —致信息的应用服务配置信息列表，然后根据该应用服务配置信息列表中的元数据标注字段中的关于加载应用服务上下文的信息，创建应用服务上下文。
8.一种开发运行于权利要求1至6中任一项所述的应用服务平台系统的应用服务的方法，其特征在于，该方法包括基于应用组件AppBean开发应用服务，一种AppBean处理一种类型的业务请求；在基于一种AppBean开发一个应用服务时，需要确定的参数包括应用服务上下文。
9.根据权利要求8所述的方法，其特征在于，该方法进一步包括在基于一种AppBean开发一个应用服务时，令该应用服务的元数据标注包括应用服务的名字和分类名、应用服务的状态信息、前置业务处理项、后置业务处理项、HTTP前缀/ 事件名称、加载应用服务上下文信息。
10.根据权利要求8所述的方法，其特征在于，所述应用服务上下文在数据构成上包括两部分字符串格式的通用资源标志符URI和附加数据部分。
全文摘要
本发明公开了一种应用服务平台系统和一种开发应用服务的方法。所述系统包括代理服务器、由多个应用服务器组成的服务器集群、中心服务器和资源服务器，其中代理服务器，用于向各应用服务器分发客户端请求；每个应用服务器，用于负载应用服务并运行；中心服务器，用于接收外部上传的应用服务，并在对应的应用服务器上部署该应用服务；资源服务器，用于保存应用服务器上的各应用服务需要访问的数据资源。本发明的技术方案降低了应用开发的难度，提高了部署的灵活性并降低了部署的难度。
文档编号H04L29/08GK102185900SQ20111009715
公开日2011年9月14日 申请日期2011年4月18日 优先权日2011年4月18日
发明者高磊 申请人:北京新媒传信科技有限公司