一种多应用服务平台系统中的应用访问方法 【技术领域】
本发明涉及互联网技术领域， 特别涉及一种多应用服务平台系统中的应用访问方法。 背景技术 在后台服务开发领域， 大部分互联网应用和企业应用都会遇到系统规模变得日益 复杂， 并且系统规模日益增大后， 开发成本和运维成本都急剧增高。
迫切需要一种解决方案， 降低应用服务平台的开发难度， 提高其部署的灵活性并 降低部署的难度。
发明内容 本发明提供了一种多应用服务平台系统中的应用访问方法， 本发明的技术方案能 降低多应用平台系统的开发难度， 提高部署的灵活性并降低部署的难度。
为达到上述目的， 本发明的技术方案是这样实现的 ：
本发明公开了一种多应用服务平台系统中的应用访问方法， 实现多个应用服务平 台系统， 在每个应用服务平台系统中设置代理服务器、 计算应用服务系统和网关， 且在云计 算应用服务系统中保存应用的描述信息以及应用与应用服务器之间的对应关系， 该方法包 括：
在一个应用服务平台系统内 ：
代理服务器接收客户端请求消息， 对客户端请求消息进行解析， 确定对应的应用， 根据该应用的描述信息创建应用上下文， 在所述客户端请求消息中添加应用上下文后， 根 据所述应用与应用服务器之间的对应关系将客户端请求消息分发给对应的应用所在的应 用服务器 ；
所述云计算应用服务系统中的所述应用服务器在接收到代理服务器发送的客户 端请求消息时， 将该客户端请求消息交给对应的应用进行处理 ；
所述对应的应用处理该客户端请求消息所请求的任务， 根据所述应用上下文进行 数据资源定位， 得出处理结果 ；
应用服务器将所述处理结果经代理服务器返回给客户端 ；
在各应用服务平台系统之间 ： 通过网关对应用进行跨应用服务平台系统的访问。
由上述可见， 针对大部分互联网应用和企业应用都会遇到系统规模变得日益复 杂， 并且规模日益增大后， 开发成本和运维成本急剧增高的问题， 本发明通过构建平台即服 务的软件平台， 将普遍的现有后台软件解决方案中按照服务角色进行拆分的方式， 改为以 细粒度的信令级别进行应用拆分， 并且进行应用开发与部署的简单方式， 降低了开发与部 署的复杂度 ； 另外， 本发明通过引入应用上下文的概念， 将复杂的资源定位与应用间的路由 从开发者视角上隔离开， 即支持了简洁的开发方式， 又能够使平台适用于超大规模的服务 器集群。并且通过增加网关的方案实现了应用的跨应用服务平台系统的访问。
附图说明
图 1 是本发明实施例中的一个应用服务平台系统的组网示意图 ； 图 2 是本发明实施例中的多应用服务平台系统的组网示意图。具体实施方式
为使本发明的目的、 技术方案和优点更加清楚， 下面将结合附图对本发明实施方 式作进一步地详细描述。
图 1 是本发明实施例中的一个应用服务平台系统的组网示意图。图 2 是本发明实 施例中的多应用服务平台系统的组网示意图。
在实际应用中， 在跨 IDC 机房的环境下， 每个机房中的部署结构均与前述的图 1 所 示的结构一致。即每个 IDC 机房中都有一个图 1 所示的应用服务平台系统。这里每个 IDC 称为一个 Site。各机房中的应用服务平台系统之间通过网关进行通信， 如图 2 所示。
则本发明中的多应用服务平台系统中的应用访问方法包括 ：
实现多个应用服务平台系统， 在每个应用服务平台系统中设置代理服务器、 计算 应用服务系统和网关， 且在云计算应用服务系统中保存应用的描述信息以及应用与应用服 务器之间的对应关系 ； 在一个应用服务平台系统内 ：
代理服务器接收客户端请求消息， 对客户端请求消息进行解析， 确定对应的应用， 根据该应用的描述信息创建应用上下文， 在所述客户端请求消息中添加应用上下文后， 根 据所述应用与应用服务器之间的对应关系将客户端请求消息分发给对应的应用所在的应 用服务器 ；
所述云计算应用服务系统中的所述应用服务器在接收到代理服务器发送的客户 端请求消息时， 将该客户端请求消息交给对应的应用进行处理 ；
所述对应的应用处理该客户端请求消息所请求的任务， 根据所述应用上下文进行 数据资源定位， 得出处理结果 ；
应用服务器将所述处理结果经代理服务器返回给客户端 ；
在各应用服务平台系统之间 ： 通过网关对应用进行跨应用服务平台系统的访问。
以下对本发明中的应用访问方法进行详细说明。
应用服务平台系统内的应用访问
如图 1 所示， 一个应用服务平台系统包括 ： 代理服务器和云计算应用服务系统， 其 中， 云计算应用服务系统中的应用服务器集群上负载并运行应用， 并且云计算应用服务系 统中保存有应用的描述信息以及应用与应用服务器之间的对应关系 ；
代理服务器， 用于接收客户端请求消息， 对客户端请求消息进行解析， 确定对应的 应用， 根据该应用的描述信息创建应用上下文， 在所述客户端请求消息中添加应用上下文 后， 根据所述应用与应用服务器之间的对应关系将客户端请求消息分发给对应的应用所在 的应用服务器 ； 接收应用服务器端返回的处理结果， 并返回给客户端 ；
所述云计算应用服务系统中的所述应用服务器， 用于在接收到代理服务器发送的 客户端请求消息时， 将该客户端请求消息交给对应的应用进行处理， 并将处理结果返回给
代理服务器 ； 所述对应的应用处理该客户端请求消息所请求的任务， 根据所述应用上下文 进行数据资源定位， 得出处理结果。
应用服务器将所述处理结果经代理服务器返回给客户端。
上述云计算应用服务系统中保存的应用与应用服务器之间的对应关系， 采用表格 保存， 其中记录有应用进程名称和应用服务路径， 即应用与应用服务器之间的对应关系。
本发明实施例中， 云计算应用服务系统包括 ： 中心服务器、 资源服务器和由多个应 用服务器组成的服务器集群， 其中 ：
中心服务器， 用于接收外部上传的应用， 将应用的描述信息保存到应用配置信息 列表中， 创建所述应用与应用服务器之间的对应关系， 并在对应的应用服务器上部署该应 用， 保存用于保存应用与应用服务器之间的对应关系的应用运行信息列表 ；
每个应用服务器， 用于将所负载的应用的运行信息上传到中心服务器上的用于保 存应用与应用服务器之间对应关系的应用运行信息列表中 ；
其中， 应用配置信息列表包括如下信息 ： 应用 ID、 应用名称、 应用服务类型、 应用 进程名、 应用服务元数据标注 ； 应用运行信息列表包括如下信息 ： 应用进程名称、 应用的服 务地址 ； 资源服务器， 用于保存应用服务器上的各应用处理客户端请求消息所请求的任务 时需要访问的数据资源 ； 在本实施例中， 资源服务器包括 ： 数据库服务器、 文件服务器和内 存对象缓冲服务器。
代理服务器， 用于接收客户端请求消息， 通过查询中心服务器上的应用配置信息 列表识别该客户端请求消息所对应的应用， 然后通过查询中心服务器上的应用配置信息列 表和应用运行信息列表获得对应的应用的服务地址， 根据所获得的服务地址将客户端请求 消息分发给对应的应用所在的应用服务器 ； 接收应用服务器端返回的处理结果， 并返回给 客户端 ；
在本发明的一个实施例中， 代理服务器包括 ： 超文本传输协议 HTTP 代理服务器、 初始会话 SIP 代理服务器和短信系统 SMS 代理服务器。其中， HTTP 代理服务器负责分发 HTTP 应用， SIP 代理服务器负责与客户端的 SIP 长连接， SMS 代理服务器负责分发短信上行 应用。
此外， 云计算应用服务系统还包括与应用服务器集群连接的基础服务服务器 ( 在 图 1 中未画出该基础服务服务器 )， 用于提供平台内部需求的一些核心应用或独立应用。
在图 1 所示的应用服务平台系统中， 所述代理服务器， 用于在接收到客户端请求 消息时， 从客户端请求消息中提取请求参数， 查询中心服务器中的应用配置信息列表， 查找 出请求参数与元数据标注字段符合的应用配置信息列表项， 进而识别出对应的应用。
例如 ： 当接收到 HTTP 请求消息时， 根据该请求消息中的统一资源定位符 URL， 查询 中心服务器上的应用配置信息列表， 查找出应用元数据标注字段包含有与所述 URL 一致信 息的应用配置信息列表项， 根据所查找出的应用配置信息列表项中的应用名称识别出该客 户端请求消息所对应的应用 ；
或者， 代理服务器在接收到与远程调用应用组件 RemoteAppBean 对应的远程调用 过程协议 Rpc 请求时， 根据该请求消息中的远程调用服务名称 (RemoteAppName)， 查找出中 心服务器上应用名称 (AppName) 字段与所述远程调用服务名称一致的应用配置信息列表
项， 根据所查找出的应用配置信息列表项中的应用名称字段识别出该请求消息所对应的应 用；
所述代理服务器， 用于根据所查找出的应用配置信息列表项中的应用进程名， 查 找出中心服务器上的应用进程名称字段包含与所述应用进程名一致信息的应用运行信息 列表项， 从所查找出的应用运行信息列表项中获取应用服务的服务地址信息。并根据所述 应用的服务地址信息将客户端请求消息分发给对应的应用所在的应用服务器。
所述代理服务器， 根据所查找出的应用配置信息列表项中的元数据标注字段中的 关于加载应用服务上下文信息， 创建应用服务上下文。
在图 1 所示的应用服务平台系统中， 中心服务器， 进一步用于保存资源列表 ； 资源 列表包括如下信息 ： 资源名称、 资源类型、 应用服务上下文类型、 定位算法名称和定位算法 参数 ；
应用在接收到客户端请求消息后， 在完成该客户端请求消息所请求的任务的过程 中根据应用上下文以及资源列表中的对应信息进行资源定位。
可见， 本发明这种由上述代理服务器、 应用服务器集群、 中心服务器和资源服务器 构成的应用服务平台系统， 将分散的服务器资源在逻辑上整合到一起， 极大降低了应用的 开发难度， 提高了部署的灵活性并降低了部署的难度。 应用服务平台系统基于如下层次结构进行开发， 具体来说代理服务器上代理服务 器、 基础服务及负载运行于应用服务器集群上的应用都基于如下层次结构进行开发 ：
开发基础框架类库 (Framework) ： 基础框架类库提供基础核心功能与用于在特定 业务领域进行定制的扩展接口 ； 在基础框架类库中定义并实现多种应用组件 AppBean 基础 类型， 并且基础框架类库中预定义了应用上下文接口及基本应用上下文类型的实现， 以提 供基础核心功能 ； 其中不同的 AppBean 基础类型对应不同类型的应用， 用于不同类型信令 的处理 ； 基础框架类库提供的扩展接口具体用来在业务框架类库 BizLibrary 中扩展的新 的 AppBean 基础类型和新的应用上下文。
根据业务特性， 在基础框架类库的基础上开发为业务定制的业务框架类库 (Biz Library)。业务框架类库还提供业务相关的扩展接口， 用于扩展新的应用 ；
基于基础框架类库和业务框架类库， 开发实现业务需求的应用、 基础服务以及代 理服务器。
应用依赖于 Framework 和 Biz Library， 实现业务需求。
基础服务依赖于 Framework 和 Biz Library， 提供基础服务。
代理服务器依赖于 Framework 和 Biz Library， 实现基于业务的路由与负载功能。
在本发明实施例中， 提供了基于应用组件 (AppBean) 的应用开发模式。这里定义 最小的开发及负载的粒度为 AppBean， 一个 AppBean 定义为实现一个微小粒度功能的应用 程序。
一般情况下将应用定义到信令级别， 定义到信令级别的应用的具体表现形式根据 业务的不同， 可以有多种， 比如可以是一个特定的 Http 请求 ( 如 GET/default.do)， 或一条 特定的上行短信 (FROM ： 13800138000 ； TO ： 10658000032 ； TEXT ： HELLO)， 或一条特定的 SIP 指令， 或一条 RPC 指令 ( 一个方法， 不是一个接口 ) 等等。
本发明实施例中， 处理一条或者多条指令的应用， 定义为 AppBean， 应用能够开发
和部署的最小单位为 AppBean， 能够针对一条信令或多条信令开发 AppBean， 并将其部署到 平台系统中， 接受用户的请求， 请求可能来自用户的客户端软件， 浏览器， 内部引用， 或外部 信令调用。
本 发 明 实 施 例 中， 基 于 Java 实 现 部 分 应 用， AppBean 被 描 述 为 一 个 接 口 (interface)， 所有特定的 AppBean 都会从本接口派生， 用以实现特定的方法， 比如自安装 机制、 配置初始化、 服务加载及服务卸载等。
AppBean 是一个抽象接口， 但应用开发时， 必须从为特定信令处理设计的 AppBean 基础类型 (BaseAppBeanTypes) 进行派生。
在 本 发 明 实 施 例 中， 已 实 现 的 AppBean 基 础 类 型 包 括 ： 处 理 HTTP 请 求 的 HttpAppBean、 处理 RPC 请求的 RemoteAppBean 和处理定时任务的 JobAppBean 等。
每个特定的 AppBean 基础类型会处理特定形式的信令， 应用开发人员需要选择 合适的 AppBean 基础类型去实现自己的应用。AppBean 基础类型不局限于上述的几种， 在 Biz Library 的层面上可以扩展特定类型的 BaseAppBeanType， 并且实现特定类型处理的 Proxy。
关于应用上下文 ( 称为 AppContext)
本发明中不仅将开发模式拆分为面向单独信令， 并且将信令与应用上下文绑定 在一起， 应用上下文称为 AppContext。在本发明的应用服务平台系统中， 应用服务上下文 (AppContext) 是应用调用及资源定位的关键。这里应用调用包括代理服务器调用应用服 务， 以及应用服务内调用其他的应用服务， 这两种应用都需要 AppContext 来实现目标应用 服务的定位。
AppContext 可以这样理解 ： AppContext 绑定一个当前应用运行的所在环境身份， 比如当前用户， 这样做， 开发人员在开发时刻是基于 AppContext( 当前用户 ) 进行开发， 访 问资源 ( 数据库， 文件， 缓存 ) 都必须通过当前的 AppContext， 这样开发者可以不用管理 数据库， 文件， 缓存等的拆分问题， 甚至用户数据的跨机房问题， 只关基于当前用户进行开 发即可， 极大的简化了开发模式， 将系统部署结构与开发过程隔离开来， 实现高效， 便捷的 PaaS 平台。
AppContext 从数据构成上分为两部分， AppContext 是可序列化与反序列化的 ：
(1) 通用资源标志符 URI(Context Uri) ： 为字符串格式， 包括用户的索引信息， 负 责后续的定位， 如 id ： 230302023 ； session ： 13910000001。
(2) 附加数据 (ContextData) ： 是预定义好的强类型数据结构， 可以包含多个字 段； 其包括该应用的属性信息 ； 应用的属性信息包括 ： 会话参数、 授权信息等 ；
在某些场合， 附加数据会由 Proxy 产生提供给后面应用， 在长连接的 Proxy 服务器 场景 ( 参见 Proxys 章节 )。
支持 getNamedValue(String fieldName) 方法， 可以获取到一个特定字段名的数 据， 此方法被用于灰度发布场合 ( 见后文 )。
AppContext 是抽象基类， 在 Framework 中预定义了以下的 AppContext 子类 ：
NullContext ： 预定义的空上下文， 用在不需要上下文的场合 ；
SessionContext ： 预定义的只保存会话 Id 的上下文。
在复杂应用中， 一般会在 Biz Library 中扩展特定的 AppContext， 比如一个 IM 系统， 在 SIP Proxy 上会保存用户的 Session， 那么我们可以扩展 UserContext， 那么每个应用 处理的时候都会接收到 Proxy 上保存的 Session 信息。
除标准 AppContext， 在使用本发明的应用服务系统平台进行扩展开发的时候， 需 要先定制业务相关的一些基础， AppContext 就是其中之一。下面例举一个关于 AppContext 的具体实施例。
例如 ： 使用本发明的应用服务平台系统开个一个即时消息 (IM) 系统， 这个 IM 系统中的用户都采用一个整数 id 进行定位， 那么可以根据如下方式定制这个 IM 系统的 AppContex， 从 AppContext 派生， 命名为 UserContext ：
·Uri 部分 ： “id ： 230302023” ， 表示用户的 id， 那么通过这个用户的 id， 可以定位 用户的应用服务位置与数据库存储位置 ；
·Data 部分 ：
- 用户的登录网络地址 ； - 客户端类型等 ；
当定制了用户的 UserContext， 所有该系统内基于用户进行操作的 AppBean 都会 用 UserContext 作为 AppBean 的 C 参数， 如：
- 获取用户资料 ； - 设置用户资料 ； - 获取好友列表等 ； 此外， 在本发明的应用服务平台系统中， 除了提供基于单个用户的 AppContext 外， 还提供了基于群组的业务类型， 开发基于群组的应用服务， 也需要定制基于群组 的 AppContext， IM 系 统 使 用 一 个 整 数 用 于 标 识 群 组， 从 AppContext 派 生， 命名为 GroupContext， GroupContext 的结构如下 ：
·Uri 部分 ： “group ： 123123” ， 标识群组 id， 表示用户的 id， 那么通过这个群组的 id， 我们可以定位群组的应用服务位置， 与数据库存储位置 ；
·Data 部分 ：
- 群组的会话参数 ； - 群组的授权等 ；
当 定 制 了 基 于 群 组 的 GroupContext 后， 该系统内基于群组进行操作的所有 AppBean 都会用 GroupContext 作为 AppBean 的 C 参数， 如：
- 设置群组名称 ； - 更新群组权限 ； - 获取群离线消息等。
应用的元数据标注 (Annotations) 信息
在发明中， 开发一个应用 AppBean 及扩展 AppBean 时， 会通过 Java 元数据标注 (Annotation) 标注应用的负载方式， 运行方式等数据， 此数据编译后， 可以在运行期加载， 或从编译后的二进制包中将数据从反射中提取出来。
在本发明的实施例中， 一些预定义的 Annotations 如下文描述， 扩展的 AppBean 都 会定义自己特定的 Annotation。
1.@AppName( 应用的名字和分类名 )
·声明 AppBean 的名字以及分类名 ；
-@AppName(category ＝″ Core″， name ＝″ GetUserInfo″ ) ；
这里 @xxx 为 Java 语言对程序元数据的标注。
·Category ： name 全局唯一 ；
·category 可以用于 AppBean 的分类 ；
- 方便运维人员进行配置与分类 ；
- 在一个 Category 中， 如果允许一个 AppBean 能够被其他 Category 中的 AppBean 访问， 必须将这个 AppBean 声明成为公开， 或友好 ；
·@Public() ： 允许所有的 AppBean 访问 ；
·@Friendlly(“Core” )： 只允许指定 Category 访问 ；
·@Friendlly(“Core ： AddBuddy” )： 只允许指定应用访问。
2.@Stateful( 应用的状态信息 )
·当声明一个 AppBean 为有状态的， 则此个 AppBean 可以将状态保存在本机内存 中；
·没有标注 @Stateful 的应用均视为无状态应用， 禁止使用本机内存进行状态的 保存 ；
· 如果一个 Category 中的多个 AppBean 声明的 Stateful 参数一样 ( “Presence” )， 则这个几个 AppBean 启动到一个进程中， 并且不允许单独热更新 ；
·@Stateful 的应用在热更新的时候会丢失状态， 所以尽量用 memcache 方式去代 替， 建议仅在某些性能要求很高的领域启动 ；
· 当某个 AppBean 被声明为 Stateful 时， 针对这个 AppBean 的访问会采用这个 AppBean 的 AppContext 绑定的一致性 Hash 的方式进行路由。 3.@HttpPrefix
HttpPrefix(HTTP 前缀， 只针对 HttpAppBean)
·用于标注一个 HttpAppBean 处理的 Http 请求范围 ；
·如 ： @HttpPrefix(″ /login.do″ ) ；
- 表示该 HttpAppBean 处理以 login.do 为起始的 http 请求。
Message Name( 事件名称， 只针对 MessageAppBean)
·用于标注一个 MessageAppBean 的名称 ；
·如 ： @Message Name
4.@ContextLoader( 加载应用服务上下文信息 )
·用于标注一个 AppBean 如何加载 AppContext
·如 ： @ContextLoader(name ＝″ CookieParser″ )
- 表示通过名为 CookieParser 的程序去处理处理 Context ；
-CookieParser 程序内置在 Proxy 当中， 通过处理 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
是一个泛型类， 其中泛型参数解释如下 ： ·上下文 ： 特定类型的上下文
·Context 来源 ： 从何处获取上下文 C ；
· URL 前缀 ： 此应用处理的 URL 前缀 (URL 前缀通过 @HttpPrefix 元数据标注处理 )
HttpAppBean 通过标注来指明自己所处理的请求 UrlPrefix( 前缀 )， 例如， 开发一 个用于最简单的 HttpAppBean 的步骤大致如下 ：
1. 从 HttpAppBean 的基类派生
@HttpPrefix(“/Hello” )
@AppName(category ＝” example” name ＝” hello” )
class Hello WorldAppBean extends HttpAppBean()
2. 指定上下文类型 ， 为 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 是一个泛型类， 其中泛型参数解释如下 ：
· ： 请求参数， 强类型定义， 可序列化 ；
· ： 应答参数， 强类型定义， 可序列化 ；
· ： 特定类型的应用上下文。
实现一个 RemoteAppBean 必须提供确定的下述类型， 例如开发一个处理获取用户 资料的 RemoteAppBean 的步骤如下 ：
1. 从 RemoteAppBean 的基类派生
@AppName(category ＝” example” ， name ＝” GetUserInfo” )
class GetUserInfo extends RemoteAppBean
2. 定义请求参数类型 为 GetOption， GetOption 为可序列化类， 保存获取用户 的 id 及选项参数 ；
3. 定义应答参数类型 为 UserInfo， UserInfo 为可序列化类， 保存用户信息 ；
4. 定义上下文 为 NullContext， 本案例中不需要上下文 ；
5. 继承后实现 process() 方法用于处理业务逻辑， 继承 load() 方法用与初始化， 继承 unload() 方法卸载， 继承 setup() 方法实现自安装。
当调用一个 RemoteAppBean 时必须提供这个 RemoteAppBean 在实现时所声明的特 定类型的应用上下文 (AppContext)。
一个获取用户信息的应用会如下声明 ：
1. 从 RemoteAppBean GetOption， UserInfo， UserContext 中派生 ；
a. 请求参数 A 为 GetOption， 为获取用户的一些选项参数
b. 应答参数 R 为 UserInfo， 为用户信息的集合
c. 应用上下文 C 为 UserContext， 为当前上下文的用户信息， UserContext 用于标 识用户 ID
2. 实现 process 方法处理业务逻辑
3.JobAppBean( 任务应用组件 )
JobAppBean 从 AppBean 派生， 用来处理一个定时任务， 并且可以在全局中保证定 时任务在某个资源上独占运行。
实现一个 JobAppBean 的步骤如下
1. 从 JobAppBean 的基类派生
@JobSchedule(cron ＝” */5****” )
@JobResource(resource ＝” USERDB” ， parallel true)
@AppName(category ＝” example” ， name ＝” GetUserInfo” )
class GetUserJobApp extends JobAppBean
2. 定义 Job 的运行时间， 其中 Job 的运行时间按照 Corn 表达式中表述的时间运行
3. 定义 Job 将要独占的资源， 关于资源的定义请见下一节， 绑定资源后， 平台系统 中的 JobAppBean 在针对此资源时将不会重复运行。
基于 AppContext 的资源访问定位在本发明中， 定义并实现一个具有某种业务功能的应用后， 这个应用势必要访问 各种资源， 如数据库、 文件服务器、 内存对象缓冲服务器或其他提供的服务等。本发明中的 应用服务平台系统是大型分布式系统， 所以这些资源都不是单点服务， 也就是同一个类型 的数据库可能存在多个纵向拆分 (Sharding) 的实例。本发明中将一个应用能够访问的资 源绑定在了其应用上下文 AppContext 上。
比如， 声明一个获取用户信息的应用， 名为 GetUserInfo App， 在应用的实现环节 读取用户数据库 (UserDB)， 将结果返回。其中 UserDB 存在多个通过用户 id 进行取模后进 行纵向拆分的实例。
那么具体过程如下 ：
1. 代理服务器 Http Proxy 接收到来自于客户端的 Http 请求 ；
2.Http Proxy 通过 Http 请求的 URL 判断该请求对应的应用 ； 具体为 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 的 参数
如： 获取用户资料、 设置用户资料、 获取好友列表、 ...
但在一个 IM 平台中， 除了提供基于用户的 AppContext 以外， 还存在基于群组的业 务类型， 开发基于群组的应用， 也需要定制基于群组的 AppContext， IM 系统使用一个整数
用于标识群组， 那么 GroupContext 结构如下
-Uri 部分 ： “group ： 123123” ， 标识群组 id， 表示用户的 id， 那么通过这个群组的 id， 我们可以定位群组的应用位置， 与数据库存储位置
-Data 部分包括 ： 群组的会话参数、 群组的授权等
当 定 制 了 基 于 群 组 的 GroupContext 后， 所有该系统内基于群组进行操作的 AppBean 都会用 GroupContext 作为 AppBean 的 参数
如： 设置群组名称、 更新群组权限、 获取群离线消息、 ...
跨应用服务平台系统的应用访问
如图 2 所示， 每个 IDC 中都有一个图 1 所示的应用服务平台系统， 在每个应用服务 平台系统中增加一个网关， 各应用服务平台系统之间通过网关进行通信。网关之间可以采 用专线通讯， 或者采用压缩、 加密后的公网通信。
可见网关与其他应用服务平台系统中的网关进行通信， 实现应用的跨应用服务平 台系统访问。具体来说， 在每个应用服务平台系统中 ：
中心服务器， 用于查找出本应用服务平台系统中部署的需要跨平台访问的应用所 对应的应用配置信息列表项， 并发送给本应用服务平台系统的网关 ； 网关， 用于将所接收的对应应用配置信息列表项信息发送给其他应用服务平台系 统中的网关 ； 用于接收其他应用服务平台系统中的网关发送的应用配置信息列表项， 并对 本中心服务器上的本地应用配置信息列表做如下处理 ：
对于所接收的每个应用配置信息列表项， 如果本地的应用配置信息列表中存在对 应的项， 且其中的应用进程名称不为网关， 则忽略， 如果本地的应用配置信息列表中不存在 对应的项或者存在但其中的应用进程名为网关， 则用接收的应用配置信息列表项更新本地 的应用配置信息列表， 并在更新后的应用配置信息列表项中增加远程系统字段， 将该字段 的值设置为所接收应用配置信息列表项的来源系统。
当要跨应用服务平台系统访问应用时 ：
网关首先从本应用服务平台系统的中心服务器获取对应的应用配置信息列表项， 查看对应的应用配置信息列表项中的应用元数据标注中是否包含对等系统标注 ； 如果包含 对等系统标注， 则根据该应用的应用上下文确定目标应用服务平台系统 ； 如果不包含对等 系统标注， 则通过该对应的应用配置信息列表项中的远程系统字段确定目标应用服务平台 系统 ； 根据所确定的目标应用服务平台系统获知该目标应用服务平台系统的网关的地址， 并将应用访问请求转发到目标应用服务平台系统的网关 ；
所述网关还用于在接收到其他应用服务平台系统的网关发送的应用访问请求后， 根据本应用服务平台系统内的中心服务器上的应用配置信息列表和应用运行信息列表， 将 请求转发到相应的应用。
在本发明中， 将只承载与本应用服务平台系统内的用户相关的数据和应用的 应用服务平台系统定义为对等系统 (PeerSite) ； 将承载本应用服务平台系统内的用户 以及其他应用服务平台系统用户的数据和应用的应用服务平台系统定义为非对等系统 (NonPeerSite) ；
根据前面的定义， AppContext 中额外存在一个 GetSiteName() 方法， 可以获取上 下文所属的 PeerSite。
下面以 RemoteAppBean 为例对应用的跨应用服务平台系统的访问进行说明。
RemoteAppBean 的跨 Site( 即跨应用服务平台系统 ) 访问
在本发明的实施例中， RemoteAppBean 的跨 Site 访问的方法如下 ：
1. 如 果 一 个 RemoteAppBean 只 与 一 个 PeerSite 中 的 用 户 相 关， 则在该 RemoteAppBean 的应用元数据标注中增加对等系统标注 ； 如果一个 RemoteAppBean 不与特 定 PeerSite 中的用户相关， 则该 RemoteAppBean 的应用元数据标注中不增加对等系统标 注；
即 RemoteAppBean 存在一个额外的标注 @PeerSite ； 其中 @PeerSite 的定义如下 ： 如果该应用是用户相关的， 必须部署到用户所属的 PeerSite 当中去， 那么必须增加标注 @ PeerSite ； 如果该 RemoetAppBean 在多个 Site 中的部署不是用户相关的， 则不需要标注 @ PeerSite。
2. 通过网关将不与特定对等系统中的用户相关的各 RemoteAppBean 的路由信息 在各个应用服务平台系统间进行同步 ；
3. 根据所同步的路由信息实现不与特定对等系统中的用户相关的 RemoteAppBean 的跨应用服务平台系统的访问。
多个 Site 之间的路由表的同步方式
网关负责不同 Site 间的 RemoteAppBean 的路由， 因为本系统中 AppBean 的路由是 动态的 ( 应用配置信息列表以及应用运行信息列表 )， 所以在多个 Site 间， 路由的同步是动 态执行的。
通过网关将不与特定 PeerSite 中的用户相关的各 RemoteAppBean 的路由信息在 各个应用服务平台系统间进行同步包括 ：
每个应用服务平台系统中的中心服务器查找出本应用服务平台系统中部署的 应 用 元 数 据 标 注 中 不 包 含 对 等 系 统 标 注 @PeerSite 的 RemoteAppBean， 作为需要同步 的 RemoteAppBean( 标注为 @PeerSite 的 RemoteAppBean 不进行同步 )， 并将需要同步的 RemoteAppBean 的对应应用配置信息列表项发送给本应用服务平台系统的网关， 本应用服 务平台系统的网关将所接收的对应应用配置信息列表项信息发送给其他各应用服务平台 系统中的网关 ；
接收到所述对应应用配置信息列表项的网关做如下处理 ： 对于所接收的每个应用 配置信息列表项， 如果本地的应用配置信息列表中存在对应的项， 且其中的应用进程名称 不为网关， 则忽略， 如果本地的应用配置信息列表中不存在对应的项或者存在但其中的应 用进程名为网关， 则用接收的应用配置信息列表项更新本地的应用配置信息列表， 并在更 新后的应用配置信息列表项中增加远程系统 RemoteSite 字段， 将该字段的值设置为所接 收应用配置信息列表项的来源系统。
可 见， 网 关 会 在 各 个 Site 间 同 步 各 个 Site 中 部 署 的 非 PeerSite 类 型 的 RemoteAppBean 的 路 由 数 据， 当 寻 找 RemoteAppBean 的 路 由 地 址 时， 可以找到 RemoteAppBean 的对应网关。
RemoteAppBean 的路由步骤
根 据 所 同 步 的 路 由 信 息 实 现 不 与 特 定 对 等 系 统 PeerSit 中 的 用 户 相 关 的 RemoteAppBean 的跨应用服务平台系统的访问包括 ：1. 当要访问不与特定对等系统中的用户相关的 RemoteAppBean 时， 首先从本应用 服务平台系统的中心服务器获取对应的应用配置信息列表项 ；
2. 查看对应的应用配置信息列表项中的应用元数据标注中是否包含对等系统标 注 @PeerSite ；
如果包含对等系统标注 @PeerSite， 则通过该 RemoteAppBean 的应用上下文确定 目标应用服务平台系统 ；
如果不包含对等系统标注 @PeerSite， 则通过该对应的应用配置信息列表项中的 远程系统 RemoteSite 字段确定目标应用服务平台系统 ；
3. 根据所确定的目标应用服务平台系统获知该目标应用服务平台系统的网关的 地址， 并将访问请求通过本应用服务平台系统的网关转发到目标应用服务平台系统的网 关；
4. 目标应用服务平台系统的网关接收到所述访问请求后， 根据本系统内的中心服 务器上的应用配置信息列表和应用运行信息列表， 将请求转发到相应的 RemoteAppBean。
由上述可见， 本发明这种由上述代理服务器、 应用服务器集群、 中心服务器和资源 服务器构成的应用服务平台系统， 将分散的服务器资源在逻辑上整合到一起， 并且面向单 个信令的应用开发， 以及基于基础框架类库和业务框架类库的开发方式极大降低了应用的 开发难度， 提高了部署的灵活性并降低了部署的难度。
综上所述， 针对大部分互联网应用和企业应用都会遇到系统规模变得日益复杂， 并且规模日益增大后， 开发成本和运维成本急剧增高的问题， 本发明通过构建平台即服务 的软件平台， 将普遍的现有后台软件解决方案中按照服务角色进行拆分的方式， 改为以细 粒度的信令级别进行应用拆分， 并且进行应用开发与部署的简单方式， 降低了开发与部署 的复杂度 ； 另外， 本发明通过引入应用上下文的概念， 将复杂的资源定位与应用间的路由从 开发者视角上隔离开， 即支持了简洁的开发方式， 又能够使平台适用于超大规模的服务器 集群。并且通过增加网关的方案实现了应用的跨应用服务平台系统的访问。
以上所述仅为本发明的较佳实施例而已， 并非用于限定本发明的保护范围。凡在 本发明的精神和原则之内所作的任何修改、 等同替换、 改进等， 均包含在本发明的保护范围 内。