一种敏捷式高效分层服务器端的接口架构

摘要

本发明公开了一种敏捷式高效分层服务器端的接口架构，其包括：请求分发层，接收客户端的请求；业务处理层，包括多个动作，所述业务处理层根据客户端的请求通过其中至少一个动作进行具体业务处理，生成最终统一精简协议的结果返回给客户端；其中所述请求分发层包括：servlet调度器，接收客户端请求，并根据请求协议类型，调用Get处理函数/Post处理函数对所述请求进行处理；动作调用者，注入到servlet调度器，所述动作调用者负责请求与业务处理层中各个动作的匹配和分发调用。该服务器端的接口架构避免了由不同请求重复创建对象而引起的效率低下和内存消耗问题，且具有便捷的逻辑处理和良好的响应效率。

说明书

技术领域

本发明涉及一种软件架构，具体来说，涉及一种敏捷式高效分层服务器端的接口架构。

背景技术

随着移动互联网的发展，移动终端应用软件层出不群，且越来越多地开始依赖于服务器端进行个性化的信息存储、获取和交互，从而实现整体服务的信息安全、连续、可共享、易整合和高可用。

基于以上背景，作为终端软件信息支撑的服务器端软件开始通过开发和开放对外接口的方式与终端软件进行数据交互，搭建信息应答平台。而传统的服务器端接口开发具有如下问题：

1.集中于处理协议层的解决方案，未形成可满足业务层面的整体成熟的软件架构，重构代价大、可扩展性低。不易测试和快速迭代、很难进行复杂的功能扩展。

2．基于以上问题，目前上已有较成熟的软件架构可供选择。如：apache软件基金会（ASF）赞助的开源项目struts2。

Struts2是一个优雅的、可扩展的web架构。它采用MVC (模型-视图-控制器，Model-View-Controller)模型，使得整体结构更清晰，能够灵活方便地进行功能扩展和快速迭代；将主处理Action（动作）设计为简单的POJO （Plain Ordinary Java Object）普通Java对象，使得编写测试用例更为方便快捷，提高测试的易实施性和效率。其整体架构思路和工作流程如下：

1. 客户端发送请求。

2. 请求先通过ActionContextCleanUp（过滤器）至FilterDispatcher（核心控制器）。

3. FilterDispatcher通过ActionMapper（动作映射器） 来匹配该请求（Request）需要调用的Action（动作）。

4. 若ActionMapper匹配到某个Action，FilterDispatcher 把请求的处理交给ActionProxy （动作代理）。

5. ActionProxy 根据ActionMapping和ConfigurationManager （配置管理器）找到需要调用的Action 类。

6. ActionProxy 创建一个ActionInvocation （动作调用）的实例。

7. ActionInvocation 调用真正的Action，并进行相关拦截器的调用。

8. Action 执行完毕，ActionInvocation 创建Result （结果）并返回。

   但是，此种架构存在如下问题：

1．整体处理性能不够理想。struts2将每个请求协议封装成独立对象；每个请求都需创建一个新的action去做逻辑处理，以实现线程安全；集成各种不同类型的返回结果；大量使用代理、正则表达式、反射等技术，虽然功能非常强大，易于开发，但是牺牲了运行效率。

2．整体组织结构比较复杂和臃肿, 配置文件多而复杂，不便组织，维护起来比较繁琐。

3. 对于底层协议封装过多，不便于进行高效灵活的协议扩展。

发明内容

本发明要解决的技术问题在于，针对现有架构的不足，提供一种改进的敏捷式高效分层服务器端的接口架构。

为实现上述目的，本发明提出了一种敏捷式高效分层服务器端的接口架构，其包括：请求分发层，接收客户端的请求；业务处理层，包括多个动作（Action），所述业务处理层根据客户端的请求通过其中至少一个动作进行具体业务处理，生成最终统一精简协议的结果（result）返回给客户端；其中所述请求分发层包括：servlet调度器（ServletDispatcher），接收客户端请求，并根据请求协议类型，调用Get处理函数（doGet）/Post处理函数（doPost）对所述请求进行处理；动作调用者（ActionInvoker），注入到servlet调度器，所述动作调用者（ActionInvoker）负责请求与业务处理层中各个动作（Action）的匹配和分发调用；其中所述servlet是一种服务器端的Java应用程序，是客户端与服务器端的中间件，担当客户请求与服务器响应的中间层。

根据本发明的实施例，其中所述Get函数/Post函数同时调用处理方法统一进行后续分发。

根据本发明的实施例，其中所述动作调用者用单例模式实现。

根据本发明的实施例，其中所述动作调用者与业务处理层中各个动作的匹配和分发调用的具体操作为：将匹配规则数据结构路由策略注入到动作调用者动作调用器类中；其中路由策略以索引/值对的形式组建，为键值对对应的数据结构，其中索引为客户端请求的统一资源定位符，值为各动作实例。

根据本发明的实施例，其中所述值根据类路径使用反射原理实现实例化。

根据本发明的实施例，其中所述业务处理层内部使用继承特性、模板模式和拦截器组合调用策略。

根据本发明的实施例，其中所述业务处理层根据动作调用者的统一资源定位符，配置相应的动作，该动作通过动作父类调用请求执行函数，同时所述业务处理层为该动作配置相应的拦截器栈并注入类中；各动作继承动作父类，通过各自执行方法负责具体业务逻辑的实现；动作父类提供回传协议封装方法和回传结果包装器，将协议统一封装成精简统一的json格式，供子动作调用；其中拦截器栈为由一系列实现可注入的动作拦截器接口的实例组合而成的拦截器列表。

根据本发明的实施例，其中所述拦截器列表中各拦截器用单例模式实现。

根据本发明的实施例，其中所述动作父类调用请求执行函数的具体操作流程包括：第一步，调用前置拦截器栈调用函数，以遍历调用各拦截器栈实例的拦截器前置处理函数，执行前置拦截，若所有结果都返回“真”，则进行第二步；反之，拦截断裂，直接返回客户端；第二步，调用执行方法，以负责具体业务逻辑实现；第三步，调用拦截器后置函数，以遍历调用拦截器栈实例的拦截器后置处理函数，执行后置拦截；其中该流程采用模板模式设计组合。

根据本发明的实施例，其中所述统一资源定位符与动作的配置以及动作与拦截器列表的配置均与开源的应用程序架整合。

本发明具有以下有益效果：本发明敏捷式高效分层服务器端的接口架构避免了由不同请求重复创建对象而引起的效率低下和内存消耗问题，且具有便捷的逻辑处理和良好的响应效率。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1为根据本发明一实施例的敏捷式高效分层服务器端的接口架构示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明进一步详细说明：

图1为根据本发明一实施例的一种敏捷式高效分层服务器端的接口架构示意图，所述接口架构包括：请求分发层100，接收客户端的请求；业务处理层200，包括多个动作（Action），所述业务处理层200根据客户端的请求通过其中至少一个动作进行具体业务处理，生成最终统一精简协议的结果（result）返回给客户端；其中所述请求分发层包括：servlet调度器（ServletDispatcher）101，接收客户端请求，并根据请求协议类型，调用Get处理函数（doGet）/Post处理函数（doPost）对请求进行处理；动作调用者（ActionInvoker）102，注入到servlet调度器 101，所述动作调用者（ActionInvoker）102负责请求与业务处理层200中各个动作（Action）的匹配和分发调用。其中所述servlet是一种服务器端的Java应用程序，是客户端与服务器端的中间件，担当客户请求（Web浏览器或其他HTTP客户程序）与服务器响应（HTTP服务器上的数据库或应用程序）的中间层。

在一个实施例中，所述前置拦截器栈调用/后置拦截器栈调用同时调用处理（process）方法统一进行后续分发。

在一个实施例中，所述动作调用者（ActionInvoker）102用单例模式实现，以使整个工程生命周期只需创建一个实例，避免了由不同请求重复创建对象而引起的效率低下和内存消耗问题。

在一个实施例中，所述动作调用者（ActionInvoker）102与业务处理层200中各个动作（Action）的匹配和分发调用的具体操作为：将匹配规则数据结构路由策略（routeMap）注入到动作调用者（ActionInvoker）类中；其中路由策略（routeMap）以索引（key）/值（value）对的形式组建，为键值对对应的数据结构，其中索引(key)为客户端请求的统一资源定位符（url），值（value）为各动作（Action）实例。即，动作调用者（ActionInvoker）102根据路由策略（routeMap）的配置规则，按不同的统一资源定位符（url）匹配生成不同的动作（Action）实例，其中每个统一资源定位符（url）对应一种业务逻辑，相应对应一个动作（Action），所述动作（Action）实例使用单例模式生成。如下表1为路由策略（routeMap）的数据结构视图：

key　valueurl1-->Action1url2-->Action2url3-->Action3……-->……

表 1

在一个实施例中，值（value）根据类路径（ classPath）使用反射原理实现实例化。

在一个实施例中，所述业务处理层200内部使用继承特性、模板模式和拦截器组合调用策略，以实现便捷的逻辑处理和良好的响应效率。具体来说，业务处理层200根据动作调用者（ActionInvoker）102的统一资源定位符（url），配置相应的动作（Action），该动作（Action）通过动作父类（BaseAction）调用请求执行（handlerRequest）函数，同时所述业务处理层200为该动作（Action）配置相应的拦截器栈（interceptors）并注入类中；各动作（Action）继承动作父类（BaseAction），通过各自执行（execute）方法负责具体业务逻辑的实现；动作父类（BaseAction）提供回传协议封装方法和回传结果包装器（writeJsonResult），将协议统一封装成精简统一的json格式，供子动作（Action）调用。其中拦截器栈（interceptions）为由一系列实现可注入的动作拦截器（ActionInterceptor）接口的实例组合而成的拦截器列表。

在一个实施例中，所述拦截器列表中各拦截器用单例模式实现，确保响应快速高效，资源占用率低。

在一个实施例中，动作父类（BaseAction）调用请求执行（handlerRequest）函数的具体操作流程包括：

第一步，调用前置拦截器栈调用（doBefore）函数，以遍历调用各拦截器栈（Interceptors）的拦截器前置处理（handlerBefore）函数，执行前置拦截，若所有结果都返回“真”（true），则进行第二步；反之，拦截断裂，直接返回客户端；第二步，调用执行（execute）方法，以负责具体业务逻辑实现；第三步，调用后置拦截器栈调用（doAfter）函数，以遍历调用拦截器栈（Interceptors）的拦截器后置处理（handlerAfter）函数，执行后置拦截；其中该流程采用模板模式设计组合，使得具体继承动作父类（BaseAction）的动作（Action）只需简单的实现执行（execute）方法做业务处理，即可完成整个数据处理流。

在一个实施例中，统一资源定位符（url）与动作（Action）的配置以及动作（Action）与拦截器列表的配置均与开源的应用程序架（spring）整合，使得整体文件管理统一、平滑、便捷。且通过开源的应用程序架（spring）文件管理系统和机制，将配置文件进行灵活配置和注入各实体中，实现各实体可视化配置，依赖关系简洁明了。上述两个方面的配置策略从架构层面对数据流分发模式和业务处理模式进行剥离和内部灵活组合，实现了高内聚低耦合设计。

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