一种支持多种协议的服务方法、装置及系统与流程

本发明涉及通信技术领域，尤其涉及一种支持多种协议的服务方法、装置及系统。

背景技术：

随着移动通信技术的快速发展，通信业务量的增加，对于移动通信网络监控系统的需求也变得越来越多，系统对于后台数据的响应要求也变得越来越高。大量不同语言，不同工具，不同协议的接口的数据服务常常共存，造成了后台服务架构越来越复杂，使用的独立模块也越来越多，使得各种服务模块部署难，维护难，升级难。服务于服务之间，接口与接口之间常常是独立的，技术实现方式也多种多样无法统一管理和有效监控。对于接口常用的方式有http，soap(webservice)，websocket等协议，针对这些协议接口常常针对同一个业务的服务需要进行单独的开发。后端服务在不同协议接口间不能复用。

技术实现要素：

本发明的实施例提供一种支持多种协议的服务方法、装置及系统，用以提供不同协议的数据请求服务，实现接口的多样性。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，本发明实施例提供了一种支持多种协议的服务方法，包括：接收分发设备发送的数据请求消息；解析所述数据请求消息获知所述数据请求消息的协议类型、所述数据请求消息的数据格式及服务标识；根据所述服务标识，获取响应数据；根据所述数据请求消息的数据格式对所述响应数据进行数据封装，并根据所述协议类型对所述数据封装后的响应数据进行协议封装；将协议封装的响应数据反馈至分发设备。

可选地，在所述将协议封装的响应数据反馈至分发设备之前，还包括：更新负载计数器的计数。

可选地，所述根据所述服务标识，获取响应数据包括：根据所述服务标识，若查找到所述服务标识对应的服务，则调用所述服务，如果调用所述服务成功获取数据，并将所述数据作为响应数据；若未查找到所述服务标识对应的服务，或如果调用所述服务未成功获取数据，则将错误消息作为响应数据。

第二方面，本发明实施例提供了一种支持多种协议的服务方法，包括：接收前端服务器发送的数据请求消息；将所述数据请求消息发送至工作站；接收所述工作站发送的响应数据；将所述响应数据发送至所述前端服务器。

可选地，将所述数据请求消息发送至工作站包括：根据各个工作站的负载计数器中的计数，将所述数据请求消息发送至负载计数器中的计数最小的工作站；更新发送所述数据请求消息的工作站的负载计数器的计数。

第三方面，本发明实施例提供了一种工作站，包括：接收模块，用于接收所述分发设备发送的数据请求消息；协议组件，用于解析所述数据请求消息获知所述数据请求消息的协议类型；数据组件，用于解析所述数据请求消息获知、所述数据请求消息的数据格式及服务标识；数据服务容器，用于根据所述服务标识，获取响应数据；所述数据组件，还用于根据所述数据请求消息的数据格式对所述响应数据进行数据封装；所述协议组件，还用于根据所述协议类型对所述数据封装后的响应数据进行协议封装；发送模块，用于将协议封装的响应数据反馈至分发设备。

可选地，还包括：更新模块，还用于更新负载计数器的计数。

可选地，所述数据服务容器，具体用于根据所述服务标识，若查找到所述服务标识对应的服务，则调用所述服务，如果调用所述服务成功获取数据，并将所述数据作为响应数据；若未查找到所述服务标识对应的服务，或如果调用所述服务未成功获取数据，则将错误消息作为响应数据。

第四方面，本发明实施例提供了一种分发设备，包括：接收模块，用于接收前端服务器发送的数据请求消息；处理模块，用于将所述数据请求消息发送至工作站；所述接收模块，还用于接收所述工作站发送的响应消息；发送模块，用于将所述响应消息发送至所述前端服务器。

第五方面，本发明实施例提供了一种支持多种协议的服务系统，包括：上述实施例所述的至少一个工作站，及上述实施例所述的分发设备。

本发明实施例提供了一种支持多种协议的服务方法、装置及系统，包括：接收分发设备发送的数据请求消息；解析所述数据请求消息获知所述数据请求消息的协议类型、所述数据请求消息的数据格式及服务标识；根据所述服务标识，获取响应数据；根据所述数据请求消息的数据格式对所述响应数据进行数据封装，并根据所述协议类型对所述数据封装后的响应数据进行协议封装；将协议封装的响应数据反馈至分发设备。这样一来，工作站可以支持各种协议，从而在接收到数据请求消息后，可以解析此数据请求消息的协议类型，及数据格式，获取此数据请求消息的响应数据。即为工作站具备支持各种协议的功能，支持协议包括常用的http接口，webservice接口，websocket接口等。支持通过各种协议调用相同的服务，增加了服务的复用率，减少了服务重复针对不同接口开发的成本。从而实现了接口的多样性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种支持多种协议的服务方法的流程示意图；

图2为本发明实施例提供的一种组件消息流程的示例图；

图3为本发明实施例提供的另一种支持多种协议的服务方法的流程示意图；

图4为本发明实施例提供的另一种支持多种协议的服务方法的流程示意图；

图5为本发明实施例提供的一种工作站的结构示意图；

图6为本发明实施例提供的另一种工作站的结构示意图；

图7为本发明实施例提供的一种分发设备的结构示意图；

图8为本发明实施例提供的一种支持多种协议的服务系统的结构示意图；

图9为本发明实施例提供的一种进程的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，本发明实施例提供了一种支持多种协议的服务方法，包括：

步骤101、接收分发设备发送的数据请求消息。

具体的，在前端服务器需要数据时，向分发设备发送数据请求消息。前端服务器在生成数据请求消息，根据其所需的数据格式对数据请求消息进行数据封装，并根据其支持的协议类型对数据封装后的数据请求消息进行相应的协议封装，并将协议封装后的数据请求消息发送至分发设备。分发设备将数据请求消息发送至工作站。

步骤102、解析数据请求消息获知数据请求消息的协议类型、数据请求消息的数据格式及服务标识。

具体的，工作站中包含有一个数据服务容器和一个基础功能管理引擎，每个基础功能管理引擎包括进行数据处理的数据组件和协议处理的协议组件，此基础功能管理引擎具备可扩展，热插拔等特性。协议组件可以支持多个协议的解析及封装，可以根据实际需求对协议组件进行扩展。同理，也可以根据实际需求对数据组件进行扩展，从而可以使得工作站支持多协议的数据服务。

工作站在接收到数据请求消息后，对数据请求消息进行解析，协议组件可以解析数据请求消息的协议封装，获知此数据请求消息的协议类型。数据组件可以对协议解析后的数据请求消息进行解析，获知其支持的数据格式及服务标识。

步骤103、根据服务标识，获取响应数据。

具体的，工作站在解析出服务标识后，可以根据此服务标识在数据服务容器内查找服务，以便找出此服务标识对应的服务，并在找到服务后，在此服务中获取到响应数据。

进一步的，根据服务标识，获取响应数据包括：

根据服务标识，若查找到服务标识对应的服务，则调用服务，如果调用服务成功获取数据，并将数据作为响应数据。

若未查找到服务标识对应的服务，或如果调用服务未成功获取数据，则将错误消息作为响应数据。

需要说明的是，数据服务容器用于提供各种各样的数据请求服务。数据服务容器通过与各种数据源例如数据库、数据文件、远程接口等对接获取相应的数据。

步骤104、根据数据请求消息的数据格式对响应数据进行数据封装，并根据协议类型对数据封装后的响应数据进行协议封装。

具体的，在获取到响应数据后，可以根据步骤102解析出的数据请求消息的数据格式对响应数据进行数据封装。例如，数据格式为json格式，此时可以将响应数据分装为json格式的数据包。并将此数据包根据步骤102解析出的协议类型，进行相应的协议封装。

需要说明的是，基础功能管理引擎用于管理编排工作站框架中的基础性功能组件，每个组件被称为一个module，该基础功能管理引擎采用流(stream)的模式在各个模块中来传递请求任务。如图2所示，各个模块之间根据需要可以改变执行顺序，基础功能管理引擎可以通过简单的方式添加和删除组件。假设目前引擎中具有组件a和组件b两个组件，由于基础功能扩展，需要添加组件c，由于基础功能管理引擎采取流的模式，可以通过配置增加新的组件，并且能够通过配置决定组件c在整个工作站中的位置，从而使消息流转顺序可以是(abc)也可以是(acb)或者(cab)等。为了并发需要管理引擎和响应的组件在每个工作站中都存在。

基础功能管理引擎中必须具有的基础功能组件包括:一个数据组件(datamodule)，一个协议组件(protocolmodule)。数据组件负责根据分发设备发来的数据请求消息从数据服务容器内的服务中获取数据并且进行必要的格式加工，最后再通过协议组件添加上请求协议进行打包最后返回到分发设备。

步骤105、将协议封装的响应数据反馈至分发设备。

具体的，工作站在响应数据进行完协议封装后，可以将此协议封装后的响应数据发送至分发设备，以便分发设备将其发送至前端服务器。

本发明实施例提供了一种支持多种协议的服务方法，包括：接收分发设备发送的数据请求消息；解析所述数据请求消息获知所述数据请求消息的协议类型、所述数据请求消息的数据格式及服务标识；根据所述服务标识，获取响应数据；根据所述数据请求消息的数据格式对所述响应数据进行数据封装，并根据所述协议类型对所述数据封装后的响应数据进行协议封装；将协议封装的响应数据反馈至分发设备。这样一来，工作站可以支持各种协议，从而在接收到数据请求消息后，可以解析此数据请求消息的协议类型，及数据格式，获取此数据请求消息的响应数据。即为工作站具备支持各种协议的功能，支持协议包括常用的http接口，webservice接口，websocket接口等。支持通过各种协议调用相同的服务，增加了服务的复用率，减少了服务重复针对不同接口开发的成本。从而实现了接口的多样性。

并且工作站的各种服务也是以组件的方式进行提供，支持热插拔，提高了部署升级的效率和开销。

如图3所示，本发明实施例提供了一种支持多种协议的服务方法，包括：

步骤201、接收前端服务器发送的数据请求消息。

具体的，在前端服务器需要获取某个服务的数据时，可以将数据请求消息发送至分发设备，以便分发设备将数据请求消息发送至工作站。

步骤202、将数据请求消息发送工作站。

具体的，分发设备在接收到数据请求消息后，可以将其发送至工作站。

进一步的，分发设备可以根据各个工作站的负载情况，将数据请求消息发送至负载最小的工作站，从而可以均衡工作站的负载。

此时，将数据请求消息发送至工作站包括：

根据各个工作站的负载计数器中的计数，将数据请求消息发送至负载计数器中的计数最小的工作站；更新发送数据请求消息的工作站的负载计数器的计数。

即为，工作站可以通过其负载计数器来标记其当前的负载情况。这样，分发设备可根据各个工作站的负载计数器中的计数来获知各个工作站的负载情况，确定出负载最小的工作站，从而将数据请求消息发送至此工作站。在将数据请求消息发送至工作站后，可以此工作站的负载计数器的计数更新，即为加1。

步骤203、接收工作站发送的响应数据。

具体的，工作站在获取了响应数据后，可以将响应数据发送至分发设备。

步骤204、将响应数据发送至前端服务器。

具体的，分发设备在接收到响应数据后，可以将此响应数据发送至分发设备。

这样一来，工作站所有接收的数据请求消息，都是通过分发设备的功能实现，它是前后端的接口对接的部分，不光用于接收前端服务器发起的数据请求消息，分发设备还可以通过计算工作站的负载情况，均衡的把数据请求消息分摊到不同的worker工作站。通过将数据请求消息分配到负载比较小的工作站的方式实现大量数据请求消息的并发。并且工作站具备支持各种协议的功能，支持协议包括常用的http接口，webservice接口，websocket接口等。支持通过各种协议调用相同的服务，增加了服务的复用率，减少了服务重复针对不同接口开发的成本。从而实现了接口的多样性。

并且工作站的各种服务也是以组件的方式进行提供，支持热插拔，提高了部署升级的效率和开销。

如图4所示，本发明实施例提供了一种支持多种协议的服务方法，包括：

步骤301、分发设备接收前端服务器发送的数据请求消息。

具体的，可参考步骤201，在此不再赘述。

步骤302、分发设备将数据请求消息发送至工作站。工作站接收分发设备发送的数据请求消息。

具体的，可参考步骤202及步骤101，在此不再赘述。

步骤303、工作站解析数据请求消息获知数据请求消息的协议类型、数据请求消息的数据格式及服务标识。

具体的，可参考步骤102，在此不再赘述。

步骤304、工作站根据服务标识，获取响应数据。

具体的，可参考步骤103，在此不再赘述。

步骤305、工作站根据数据请求消息的数据格式对响应数据进行数据封装，并根据协议类型对数据封装后的响应数据进行协议封装。

具体的，可参考步骤104，在此不再赘述。

步骤306、工作站更新负载计数器的计数。

具体的，工作站在将响应数据进行完协议封装后，其完成了此次处理任务，可以将其负载计数器中的计算减1，即为更新此负载计数器的计数。

需要说明的是，工作站的负载计数器中的计数用以表示出工作站当前的负载情况。

步骤307、工作站将协议封装的响应数据反馈至分发设备。分发设备接收工作站发送的响应数据。

具体的，可参考步骤105及步骤203，在此不再赘述。

步骤308、分发设备将响应数据发送至前端服务器。

具体的，可参考步骤204，在此不再赘述。

这样，工作站具备支持各种协议的功能，支持协议包括常用的http接口，webservice接口，websocket接口等。支持通过各种协议调用相同的服务，增加了服务的复用率，减少了服务重复针对不同接口开发的成本。从而实现了接口的多样性。

并且工作站的各种服务也是以组件的方式进行提供，支持热插拔，提高了部署升级的效率和开销。

同时采用多个工作站提供数据服务容器具备了高并发和快速响应的特点。同时减化了后端程序部署架构的组成，便于后续的维护和升级。

如图5所示，本发明实施例通过了一种工作站，包括：

接收模块401，用于接收分发设备发送的数据请求消息。

协议组件402，用于解析数据请求消息获知数据请求消息的协议类型。

数据组件403，用于解析数据请求消息获知、数据请求消息的数据格式及服务标识。

数据服务容器404，用于根据服务标识，获取响应数据。

具体的，数据服务容器404，具体用于根据服务标识，若查找到服务标识对应的服务，则调用所述服务，如果调用服务成功获取数据，并将数据作为响应数据；若未查找到服务标识对应的服务，或如果调用服务未成功获取数据，则将错误消息作为响应数据。

数据组件403，还用于根据数据请求消息的数据格式对响应数据进行数据封装。

协议组件402，还用于根据协议类型对数据封装后的响应数据进行协议封装。

发送模块405，用于将协议封装的响应数据反馈至分发设备。

进一步的，上述工作站，如图6所示，还包括：

更新模块406，还用于更新负载计数器的计数。

如图7所示，本发明实施例提供了一种分发设备，包括：

接收模块501，用于接收前端服务器发送的数据请求消息。

处理模块502，用于将数据请求消息发送至工作站。

具体的，处理模块502，具体用于根据各个工作站的负载计数器中的计数，将数据请求消息发送至负载计数器中的计数最小的工作站；更新发送数据请求消息的工作站的负载计数器的计数。

接收模块501，还用于接收工作站发送的响应消息。

发送模块503，用于将响应消息发送至前端服务器。

如图8所示，本发明实施例提供了一种支持多种协议的服务系统，包括至少一个工作站601及分发设备602。其中至少一个工作站601为上述实施例所述的工作站。分发设备602为上述实施例所述的分发设备。

具体的，对于分发设备602和多个工作站601的实施方式采用多进程中pre-fork的方式，分发设备作为主进程，工作站601作为子进程，工作站601进程又启动很多线程用于处理任务，如图9所示。作为分发设备的主进程负责启动监听用于响应客户端的数据请求，主进程收到客户端发送的数据请求消息，将数据请求消息直接发送到子进程中的任务队列中，子进程中选中一个空闲的线程用于响应前台请求数据请求消息。分发设备作为主进程控制一个各个子进程的负载计数器，负载计数器的实现可以采用共享内存等ipc资源。由主进程和子进程共同来维护，当主进程找出一个负载最小的子进程时，主进程就在这个子进程任务计数上个做增加1操作。等子进程响应完了一次请求则在自己的任务计数上做减1操作。

对于基本功能引擎的流模式，采用栈的方式逐级调用并逐级返回的策略，保障在各个基础组件中能按照事先的配置和编排进行调用和处理。

数据组件和协议组件作为平台工作站框架的基础组件用可动态加载模块实现可以发布成动态库等方式。数据组件用于生成服务返回同一的报文格式比如json格式。协议组件用于判断请求所需要的协议并且支持按照请求的协议进行封装。

当一个数据请求被客户端发起，分发设备602接收到数据请求消息，逐个判断工作站601的负载计数器的计算，找出负载最小的工作站601，将这个工作站601的负载计数器的计数加1并将该数据请求消息的连接直接发给该工作站601的任务队列。处理工作站601从队列中去处想要处理的任务，通过协议组件分析请求的协议类型，通过数据组件分析请求的数据格式以及服务标识，查找数据服务容器是否有所请求的服务，如果数据服务容器中没有包含该请求的服务，则将该工作站601的任务负载计数器的计数减1，并将错误信息作为响应数据。如果在数据服务容器中能查找到相应的服务标识，则调用相应的服务获取数据，如果服务执行失败，则将该工作站601的负载计数器的计算减1，并将错误信息返回作为响应数据。如果执行成功，则将获取的数据作为响应数据。同时将该工作站601的负载计数器的计算减1。

经过数据处理组件将响应数据的数据格式化，在经过协议处理组件封装协议，并将响应数据经过分发设备返回给前端服务器。

这样，工作站具备支持各种协议的功能，支持协议包括常用的http接口，webservice接口，websocket接口等。支持通过各种协议调用相同的服务，增加了服务的复用率，减少了服务重复针对不同接口开发的成本。从而实现了接口的多样性。

并且工作站的各种服务也是以组件的方式进行提供，支持热插拔，提高了部署升级的效率和开销。

同时采用多个工作站提供数据服务容器具备了高并发和快速响应的特点。同时减化了后端程序部署架构的组成，便于后续的维护和升级。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。