CN110716748A

CN110716748A - Service processing method and device, computer readable medium and electronic equipment

Info

Publication number: CN110716748A
Application number: CN201910905513.XA
Authority: CN
Inventors: 吕洁印; 周受钦
Original assignee: China International Marine Containers Group Co Ltd; Shenzhen CIMC Intelligent Technology Co Ltd; Dongguan CIMC Intelligent Technology Co Ltd
Current assignee: Shenzhen CIMC Intelligent Technology Co Ltd; Guangdong CIMC Intelligent Technology Co Ltd
Priority date: 2019-09-24
Filing date: 2019-09-24
Publication date: 2020-01-21
Anticipated expiration: 2039-09-24
Also published as: CN110716748B

Abstract

The embodiment of the application provides a service processing method, a service processing device, a computer readable medium and electronic equipment. The service processing method comprises the following steps: the method comprises the steps of obtaining at least two subtasks from splitting a service to be processed, determining an action corresponding to each subtask and a service processing logic between the subtasks, generating an execution document corresponding to the service to be processed according to preset base class information, assembling and configuring the execution document according to the service processing logic to obtain a task flow corresponding to the service to be processed, and finally executing the action corresponding to each subtask in sequence based on the execution document according to a subtask execution sequence contained in the task flow. According to the technical scheme of the embodiment of the application, the business to be processed is reasonably split and configured, so that the business processing flow is very clear, a business developer can rapidly complete the development of business logic by using the framework, the maintenance and the development of a business system are facilitated, and the development efficiency of the whole business system is improved.

Description

Service processing method and device, computer readable medium and electronic equipment

Technical Field

The present application relates to the field of computer and communication technologies, and in particular, to a service processing method and apparatus, a computer-readable medium, and an electronic device.

Background

With the complicated functions of each application system, the development and debugging difficulty of the application program of the server and the development efficiency of providing the service logic are lower and lower. Most application server core architectures adopt the idea of layered design, and the development work of the simplified synchronization service enables a service developer to directly inherit a specific service processor to realize the hooking method of the example to provide the specific service.

However, when the specific service processor is directly used to implement the logic service, the high-level application services of the system, such as log services, application layer protocol stacks, etc., will be lost, and the service developers need to repeatedly develop these general application services to be able to put into normal application; moreover, the business logic is directly realized through the business processor, so that the serious business code coupling problem occurs in the business logic layer, the relation among the subtasks corresponding to each business is disordered, the task flow in the application process is disordered, the system maintenance and the system reuse are not facilitated, and the development efficiency is low.

Disclosure of Invention

Embodiments of the present application provide a service processing method, an apparatus, a computer-readable medium, and an electronic device, which are further beneficial to maintaining and developing a service system at least to a certain extent, and improve the development efficiency of the entire service system.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned by practice of the application.

According to an aspect of an embodiment of the present application, there is provided a service processing method, including: splitting a service to be processed to obtain at least two subtasks, and determining an action corresponding to each subtask and a service processing logic between the subtasks; generating an execution document corresponding to the service to be processed according to preset base class information, wherein the execution document comprises a service execution document corresponding to the service to be processed, the subtask execution document and an action execution document; assembling and configuring an execution document corresponding to the service to be processed according to the service processing logic to obtain a task flow corresponding to the service to be processed; and sequentially executing actions corresponding to each subtask based on the execution document according to the execution sequence of the subtasks contained in the task flow.

According to an aspect of an embodiment of the present application, there is provided a service processing apparatus, including: the system comprises a splitting module, a processing module and a processing module, wherein the splitting module is used for splitting a service to be processed to obtain at least two subtasks and determining an action corresponding to each subtask and a service processing logic between the subtasks; the document module is used for generating an execution document corresponding to the service to be processed according to preset base class information, wherein the execution document comprises a service execution document corresponding to the service to be processed, the subtask execution document and an action execution document; the configuration module is used for assembling and configuring the execution document corresponding to the service to be processed according to the service processing logic to obtain a task flow corresponding to the service to be processed; and the execution module is used for sequentially executing the action corresponding to each subtask based on the execution document according to the execution sequence of the subtasks contained in the task flow.

In some embodiments of the present application, based on the foregoing solution, the execution module is configured to: calling the subtasks according to the subtask execution sequence contained in the task flow; and according to the subtask execution document, handing over a server corresponding to the subtask to execute the action corresponding to the subtask, and transmitting the data obtained by processing the subtask to a server corresponding to the next subtask of the subtask until all subtasks in the task flow are executed.

In some embodiments of the present application, based on the foregoing, the document module is configured to: generating a service execution document corresponding to the service to be processed based on preset command base class information, wherein the service execution document comprises an input function for processing a service request in the service to be processed and a jump logic of the action, and the jump logic corresponds to the service processing logic; generating a subtask execution document corresponding to the subtask based on preset step base class information, wherein the step base class information comprises an action example of an action corresponding to the subtask, an input/output function of the subtask, and a mapping relation between the subtask and an adjacent subtask, and the mapping relation corresponds to the business processing logic; and generating an action execution document corresponding to the action based on preset action base class information, wherein the action base class information comprises an interaction mode between servers corresponding to each executed action.

In some embodiments of the present application, based on the foregoing, the configuration module is configured to: configuring input and output functions and action instances of the subtask execution document based on the jump logic in the service execution document; generating a task linked list based on the mapping relation between each subtask and the adjacent subtask in the subtask execution document; and adding the interaction mode in the action execution document to the task chain table to obtain the task flow.

In some embodiments of the present application, based on the foregoing solution, the service processing apparatus is further configured to: the loading unit is used for loading and analyzing the configuration file of the system to obtain configuration parameters; the instance unit is used for instantiating the service container class based on the configuration parameters to obtain a service instance; and the registering unit is used for determining a command identifier corresponding to the service to be processed according to the command list in the configuration file, registering a command class corresponding to the command identifier in the service instance, and executing the action in the task flow based on the command class.

In some embodiments of the present application, based on the foregoing solution, the service processing apparatus is further configured to: the detection unit is used for detecting whether all subtasks in the service to be processed are executed or not; and the releasing unit is used for withdrawing and releasing the service instance and the memory space thereof if the service instance is in the first place.

In some embodiments of the present application, based on the foregoing solution, the service processing apparatus is further configured to: the representing unit is used for representing the state of the executing process through a preset enumeration type value corresponding to the state machine; and the management unit is used for managing the execution process according to the enumeration type value.

According to an aspect of the embodiments of the present application, there is provided a computer readable medium, on which a computer program is stored, which when executed by a processor implements the service processing method as described in the above embodiments.

According to an aspect of an embodiment of the present application, there is provided an electronic device including: one or more processors; a storage device for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the service processing method as described in the above embodiments.

In the technical solutions provided in some embodiments of the present application, at least two subtasks are obtained from splitting a service to be processed, an action corresponding to each subtask and a service processing logic between the subtasks are determined, an execution document corresponding to the service to be processed is generated according to preset base class information, the execution document is assembled and configured according to the service processing logic, a task flow corresponding to the service to be processed is obtained, and finally, the action corresponding to each subtask is sequentially executed based on the execution document according to a subtask execution sequence included in the task flow. The business to be processed is reasonably split and configured, so that the business processing flow is very clear, and a business developer can utilize the framework to rapidly complete the development of business logic, thereby being beneficial to maintaining and developing a business system later and improving the development efficiency of the whole business system.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort. In the drawings:

FIG. 1 shows a schematic diagram of an exemplary system architecture to which aspects of embodiments of the present application may be applied;

FIG. 2 schematically shows a flow diagram of a traffic handling method according to an embodiment of the application;

FIG. 3 schematically illustrates a flow diagram for generating an execution document according to an embodiment of the present application;

FIG. 4 schematically shows a flow diagram for generating a task stream according to an embodiment of the application;

FIG. 5 schematically shows a flow diagram of sub-task execution according to an embodiment of the present application;

FIG. 6 schematically shows a flow diagram of releasing a service instance according to an embodiment of the application;

fig. 7 schematically shows a schematic diagram of a traffic processing apparatus according to an embodiment of the present application;

FIG. 8 schematically illustrates a hardware diagram of a computer device according to an embodiment of the present application;

fig. 9 schematically illustrates a computer-readable storage medium for implementing the above-described target data archiving method according to one embodiment of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

Fig. 1 shows a schematic diagram of an exemplary system architecture to which the technical solution of the embodiments of the present application can be applied.

As shown in fig. 1, the system architecture may include a terminal device (e.g., one or more of a smartphone 101, a tablet computer 102, and a portable computer 103 shown in fig. 1, but may also be a desktop computer, etc.), a network 104, and a server 105. The network 104 serves as a medium for providing communication links between terminal devices and the server 105. Network 104 may include various connection types, such as wired communication links, wireless communication links, and so forth.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation. For example, server 105 may be a server cluster comprised of multiple servers, or the like.

A user may use a terminal device to interact with the server 105 over the network 104 to receive or send messages or the like. The server 105 may be a server that provides various services. For example, a user uploads information of a service to be processed to the server 105 by using the terminal device 103 (or the terminal device 101 or 102), the server 105 may obtain at least two subtasks from splitting the service to be processed, determine an action corresponding to each subtask and a service processing logic between the subtasks, generate an execution document corresponding to the service to be processed according to preset base class information, assemble and configure the execution document according to the service processing logic, obtain a task flow corresponding to the service to be processed, and finally sequentially execute the action corresponding to each subtask based on the execution document according to a subtask execution sequence included in the task flow. The business to be processed is reasonably split and configured, so that the business processing flow is very clear, and a business developer can utilize the framework to rapidly complete the development of business logic, thereby being beneficial to maintaining and developing a business system later and improving the development efficiency of the whole business system.

It should be noted that the service processing method provided in the embodiment of the present application is generally executed by the server 105, and accordingly, the service processing apparatus is generally disposed in the server 105. However, in other embodiments of the present application, the terminal device may also have a similar function as the server, so as to execute the scheme of service processing provided in the embodiments of the present application.

In order to reduce the development and debugging difficulty of the server application program, provide the service logic development efficiency and improve the system modularization multiplexing degree, the core architecture of most big data application servers adopts the idea of layered design, and the internal architecture of the servers is divided into three layers. The first layer is a network communication architecture layer, the second layer is a service architecture layer, and the third layer is a service logic layer. Many server-side internal architectures employ a semi-synchronous or semi-asynchronous architecture that utilizes a layering concept to divide the system into three layers, namely an asynchronous layer responsible for handling external event sources, a synchronous layer responsible for handling higher-level services of the system, and a queuing layer responsible for providing buffering between synchronous and asynchronous. The model simplifies the development of advanced synchronization services while maintaining relatively efficient server performance. The system is divided into layers, so that the modularization of the system is favorably realized, a complex and complicated coordination mechanism between synchronous service and asynchronous service is reduced, and the locking overhead and serialization of the concurrent processing are effectively optimized by a queuing layer. Therefore, the semi-synchronous/semi-reactive thread pool communication architecture can realize the decoupling between the system network communication layer and the service logic layer, and a service developer can directly provide specific services by inheriting a specific service processor and realizing the hooking method of the example.

However, the service processor in the prior art only provides a communication function of a system foundation, and if the specific service processor is directly used to implement a logic service, various disadvantages will be caused, which first result in a loss of high-level application services of the system, such as log services, application layer protocol stacks, and the like, and a service developer needs to repeatedly develop the general application services, resulting in low development efficiency. Secondly, the direct implementation of the service logic through the service processor may cause severe service code coupling in the service logic layer, which may result in too high code maintenance cost and be not favorable for service expansion. Finally, in a distributed cluster, a task is usually required to be split into a plurality of subtasks, and the subtasks are respectively realized by a plurality of application servers, and the subtasks cooperate with each other to complete a specific application service. The service processor does not provide a clear service call flow mechanism, thereby being very easy to cause service confusion and being not beneficial to system multiplexing.

In one embodiment of the present application, a business logic architecture named Flow-Framework (Flow-Framework) is proposed to solve the code coupling problem inside the business layer. The Flow-Framework service logic architecture of this embodiment has two major advantages, and first, various advanced general application services, such as configuration services, log services, an application layer protocol stack, an error code set, a general character string processing tool, a time processing tool, and some common service data processing algorithms, are implemented. Secondly, a high-efficiency service flow calling processing mechanism is realized by combining the flow mode and the state machine mechanism. The Flow-Framework business logic architecture reasonably splits and organizes business processing flows by using a Flow (Stream) mode and Action/State (Action/State) State machine mechanism, so that the business processing flows are very clear, and a business developer can rapidly complete the development of business logic by using the architecture.

In one embodiment of the present application, a plurality of advanced general application services are also integrated, such as configuration services, log services, application layer protocol stacks, error code sets, general string processing tools, time processing tools, and some commonly used algorithms, and developers can use these tools to simplify writing of service codes. The application server (for example, a middleware subsystem, a service subsystem and the like) is realized by adopting a semi-synchronous/semi-asynchronous architecture and a Flow-Framework service architecture, and a service developer only needs to concentrate on writing service logic codes.

The implementation details of the technical solution of the embodiment of the present application are set forth in detail below:

fig. 2 shows a flowchart of a business process method according to an embodiment of the present application, which may be performed by a server, which may be the server shown in fig. 1. Referring to fig. 2, the service processing method at least includes steps S210 to S240, which are described in detail as follows:

in step S210, the service to be processed is split to obtain at least two subtasks, and an action corresponding to each subtask and a service processing logic between the subtasks are determined.

In an embodiment of the application, the problem of code coupling inside a service layer is solved through a service logic architecture based on the Flow-Framework, and a service developer only needs to inherit several core classes of the Flow-Framework to be enough, so that service loading and service Flow processing are realized. The Flow-Framework service logic architecture is used as a called party to receive a service request, a corresponding service processing Flow instance is selected from a service container of the architecture for processing, and after the processing is finished, the service processing Flow instance and a corresponding cache thereof are released.

In an embodiment of the present application, the Flow-Framework Service architecture subdivides the Service logic layer into key classes of seven cores, which are a Service Container class (Service _ Container), a Service class (Service), a Command class (Command), a Step class (Step), an Action class (Action), a Message class (Message), and a configuration Service class (Config), respectively.

In an embodiment of the present application, Service _ Container is a huge Service instance Container for centrally storing and managing instances of application services, and the type is designed in a singleton mode. In the framework, a specific service instance is represented by a task identifier, and the type of a service is represented by a command identifier. For example, a specific service instance is represented by a sixty-four integer Task identifier (Task _ ID) and a type of service is represented by a thirty-two integer Command identifier (Command _ ID).

In an embodiment of the present application, the Service _ Container maintains a mapping table for specializing a Command _ ID to a Command creation class (Command _ Creator) template, where the class template is a factory of the Command class and is responsible for generating a specific Command instance.

Specifically, in the process of generating the Command instance, after the peer-to-peer connection is established in the underlying communication architecture, the underlying receiver (Acceptor) generates a preset-bit (for example, 64-bit integer) Task _ ID, transmits the Task _ ID together with the request message to the synchronization Service layer through the queuing layer, and transmits the request message to the Service _ Container, and the Service _ Container single instance generates a Service according to the Command _ ID of the message request, acquires the specific Command instance from the Command _ Creator-type template-specific set, then fits in the Service instance, and finally stores the specific Command instance in the Hash Map (Hash _ Map) of the specific Command _ ID and the Service instance by using the mapping of the Task _ ID and the Service instance.

In an embodiment of the application, the Service _ Container single instance provides a plurality of interfaces to call a specific event server (Logic _ Handler) to realize dynamic management of Service instances, so as to realize combination of a Flow-Framework Service architecture and a communication-Task (ACE _ Task) -based semi-synchronous/semi-reactive (half-sync/half-reactive) thread pool communication architecture.

In an embodiment of the present application, the Message is a Message base class of the present architecture, and is combined with a communication _ Message Block class (ACE _ Message _ Block) by using an adapter (adapter) mode, so as to conveniently integrate an underlying communication module of the present architecture. The method is realized by adopting a template technology, and the setting of an application layer protocol stack and configuration service is realized through template parameters. The template parameter of the Message is an application protocol class (CProtoc), and the CProtoc class is a base class of the service architecture application protocol and is used for externally providing functions of unpacking, packing and the like of the Message.

In one embodiment of the present application, the Config provides a function of a configuration service for the architecture, and the configuration file is written by an Extensible Markup Language (XML) technology. The class comprises two parts of architecture basic configuration and user-defined configuration.

In an embodiment of the present application, during a service processing process, a service to be processed is first split into a plurality of subtasks, so that the subtasks cooperate with each other, and a specific service flow is combined according to a certain rule to complete processing of the service. In the service call Flow mechanism based on the Flow-Framework service architecture in this embodiment, a service code can be written by splitting a service to be processed reasonably and then by supporting several core classes of the architecture and implementing corresponding logic processing functions, and this good programming style can better improve the development efficiency of developers.

In an embodiment of the present application, in a process of splitting a service to be processed, the splitting may be performed according to a service type, a service function, and a branch service in a processing process of the service to be processed, the service to be processed is divided into at least two subtasks, and a service processing logic between each subtask is determined. For example, the business processing logic between subtasks in this embodiment may be a processing sequence or a call relationship between data, and is not limited herein.

In step S220, an execution document corresponding to the service to be processed is generated according to preset base class information, where the execution document includes a service execution document, the subtask execution document, and an action execution document corresponding to the service to be processed.

In an embodiment of the application, based on a Flow-Framework service architecture, base class information is preset, wherein the base class information includes command base class information (command _ base), step base class information (step _ base), and action base class information (action _ base).

Specifically, the Command, the Step and the Action together complete the processing of the business flow. Wherein, the Command is used for analyzing task request, assembling and controlling service flow in a complete service flow; step represents the subtask in the service flow, and the type requires the user to provide an input processing function and an output processing function, and the function is particularly responsible for the service logic processing of the subtask; actions are used to implement specific actions for communicating with other servers, including but not limited to request packaging, response unpacking, package integrity checking.

In an embodiment of the present application, as shown in fig. 3, the process of generating the execution document corresponding to the to-be-processed service according to the preset base class information in step S220 may include steps S310 to S330:

in step S310, based on preset command base class information, a service execution document corresponding to the service to be processed is generated, where the service execution document includes an input function for processing a service request in the service to be processed and a skip logic of the action, and the skip logic corresponds to the service processing logic.

In one embodiment of the present application, the Command _ base class is a parent class to all Command classes, and each specific Command class requires two virtual functions to implement that class. Parsing the input function (pars _ input) which is responsible for processing the input parameters of the service request and saving the requested input parameters into its own data structure. And constructing a function (built _ flow) for registering each Step class and establishing specific jump logic of each Step class by the service flow. The Command _ creator template in this embodiment is a factory class of the Command and is responsible for creating a specific instance of the Command class.

In step S320, a subtask execution document corresponding to the subtask is generated based on preset step base class information, where the step base class information includes an action instance of an action corresponding to the subtask, an input/output function of the subtask, and a mapping relationship between the subtask and an adjacent subtask, and the mapping relationship corresponds to the service processing logic.

In one embodiment of the application, Step _ base is a parent class to Step, which provides the Action to register the processing required for the Step, the input and output processing functions for the Step, and the response gateway for the next Step pointer. step _ base utilizes the mapping relation from a plurality of pairs of processing results in a map container to pointers of the next step, wherein the processing results are expressed by int integer and need to be defined by a user. Step selects the next Step by using its own call next Step function get _ next _ Step _ by _ ret (), thereby implementing the Step jump logic.

In step S330, an action execution document corresponding to the action is generated based on preset action base class information, where the action base class information includes an interaction manner between servers corresponding to each executed action.

In one embodiment of the present application, Action _ base is a parent class of all actions, and is responsible for communicating with a downstream server, and is used for implementing processing of request messages and response messages when interacting with other servers. The action base class information in this embodiment includes an interaction manner between servers corresponding to each executed action, for example, processing a data packet, a request parameter, or a response packet, where the interaction manner includes, but is not limited to: processing an input function handle _ input () for packet integrity processing; a code-managing function handle _ encode () used for requesting parameter packing; the handle _ process () is a process function for processing the response packet.

In one embodiment of the application, elements in the action execution document corresponding to each action are determined based on various functions in the action base class information, so that the action execution document is generated according to the elements.

In step S230, an execution document corresponding to the service to be processed is assembled and configured according to the service processing logic, so as to obtain a task flow corresponding to the service to be processed.

After the document to be processed is split to obtain the subtasks and the execution document corresponding to the document to be processed is generated, all the execution documents are assembled according to the business processing logic among the subtasks and are configured, and finally the business flow corresponding to the business to be processed is obtained so as to process each subtask in sequence according to the business flow.

In an embodiment of the present application, as shown in fig. 4, before the process of assembling and configuring the execution document corresponding to the service to be processed according to the service processing logic in step S230 to obtain the task flow corresponding to the service to be processed, step S410 to step S430 may be further included:

in step S410, the input-output function and the action instance of the subtask execution document are configured based on the jump logic in the service execution document.

In an embodiment of the application, after the Service provisioning receives a Service request, a Service request message is processed by an underlying network module to reach a Service Logic layer, and a specific Service processor (Logic _ Handler) calls a Service acquisition function get _ Service () in a Service _ Container according to a Task _ ID of the message to retrieve a Service instance of a response from a Service Container set maintained by the Service _ Container. Since the request is new at this time, the lookup result is empty. At this time, the Service _ Container calls its own Command acquisition function get _ Command () to acquire a specific Command instance from the set specialized by the Command _ Creator-type template. After obtaining the Command instance, the Service _ Container transfers the application of the Command instance as a parameter into the Service adding function add _ Service () of the Service _ Container, and the add _ Service () function allocates the Command instance in the Service instance and registers the Service instance in the Container set. The caller of get _ Service () gets a Service instance that has completed the assembly of Command.

In an embodiment of the application, during the instantiation process of the Command, the respective functions of pars _ input () and build _ flow () are called to complete the parsing of the request parameters and the assembling of the Step so as to form a complete service flow. The Command instance has a plurality of Step and Action members, and the configuration of the input processing function, the output processing function and the Action instance of each Step member is completed in the build _ flow () function, so that the configuration of the subtask execution document is completed.

In step S420, a task chain table is generated based on the mapping relationship between each subtask in the subtask execution document and its adjacent subtask.

In an embodiment of the application, a mapping relationship between a subtask and an adjacent subtask may be that each Step sets a Step to be turned next by using its own next Step setting function set _ next _ Step () function, so as to form a Step task chain table, where the task chain table is a completed service flow.

In one embodiment of the present application, in the application of the task linked list, the Command instance calls the Step Start function start _ Step _ flow to start the Step flow. After the current Step processing is completed, the Command instance calls a next Step function get _ next _ Step of the Command instance, and in the function implementation, according to the processing result of the current Step, the next Step function get _ next _ Step _ by _ ret of the current Step is called to acquire a next Step reference, so that the jump of the Step stream is realized.

In step S430, the interaction means in the action execution document is added to the task chain table to obtain the task flow.

In one embodiment of the present application, Step represents a subtask where actions are responsible for communicating with downstream servers, where a Step has one or more Action instances from which to interact with a downstream server. In the process of configuring the task flow, the interactive mode in the Action execution document is added into the task chain table, so that each Step can be called according to the sequence of Step input processing function, request packaging function handle _ encode (), response completeness check function handle _ input (), response processing function handle _ procs (), and Step output processing function of the Action, and the processing of one subtask is completed. During the Step stream jump, the Command instance calls the own get _ current _ Step function () to obtain the reference of the current Step, then executes the processing of the current Step, and caches the result of the Step processing.

In an embodiment of the application, the configuration of the service is completed by writing a corresponding configuration file and inheriting a Config _ Base class, and a corresponding application protocol set is defined for the service by inheriting a CProtoc Base class.

The framework has a clear message organization mode, and the request parameters, the fields and the response information of each service, which are required in the processing process, define a corresponding structural body in the context of Command class. The request parameters and response parameters associated with each Action request define a corresponding construct within the Action class context. The processing procedure of each service is actually the process of the message interaction of each Action with the downstream server and the collection of the Command-like message interaction with each Action-like message. The message processing flow design enables various information to be reasonably and orderly organized, and makes the organization logic become very clear.

In an embodiment of the present application, as shown in fig. 4, before the step S240, according to the execution sequence of the subtasks included in the task flow, and based on the execution document, a process of sequentially executing an action corresponding to each subtask may further include steps S410 to S430:

in step S410, a configuration file of the system is loaded and parsed to obtain configuration parameters.

In an embodiment of the present application, in a configuration phase of loading a service, a server program starts to run, and a configuration file function read _ configuration _ file () of the server program is called in a main function by calling a Config to load a system configuration file configuration.

In step S420, a service container class is instantiated based on the configuration parameters, and a service instance is obtained.

In an embodiment of the application, in an initialization stage of a Service Container, a main function calls an open function open () in Service _ Container, and instantiates a Service Container class based on a configuration parameter to obtain a Service instance.

In one embodiment of the present application, a service instance is used to represent a specific service on a server, i.e. a specific instance for processing a pending task. Configurable items of a service instance include, but are not limited to, basic information of the service, service provider, service interface, cache, security, and the like. In the embodiment, the service container class is instantiated based on the configuration parameters to obtain the service instance, so that specific steps and action instances in the task to be processed are inserted into the service instance.

In step S430, according to the command list in the configuration file, a command identifier corresponding to the service to be processed is determined, and a command class corresponding to the command identifier is registered in the service instance, so as to execute an action in the task flow based on the command class.

In an embodiment of the present application, the configuration file includes a command list, and in this embodiment, a command identifier of a service to be processed is determined first, so as to register in the service instance according to a command class corresponding to the command identifier.

Specifically, in the open () function of the Service _ Container, according to the Command _ ID list of the configuration file, the register _ Command _ factor () function is called to register the Command class factory in the mapping table in which the own Command _ ID is instantiated to the Command _ Creator class template, thereby completing the assembly of the Service.

In one embodiment of the present application, in a network module starting phase, after completing service configuration, a system starts a semi-synchronous/semi-reactive thread pool communication architecture based on a Task-adaptive communication environment (ACE _ Task) and establishes one or more snoop handles through an Acceptor in the architecture to wait for the arrival of a service request, so as to execute corresponding actions according to the service request after snooping the service request.

In step S240, according to the sub-task execution sequence included in the task flow, the actions corresponding to each of the sub-tasks are sequentially executed based on the execution document.

In an embodiment of the application, after the task stream is generated, the task stream includes an execution sequence of each sub-task, and finally, the action corresponding to each sub-task is sequentially executed according to the execution sequence in the execution document.

In an embodiment of the present application, as shown in fig. 5, the step S240 of sequentially executing the action corresponding to each subtask based on the execution document according to the execution order of the subtasks included in the task flow may include steps S510 to S520:

in step S510, the subtasks are called according to the execution sequence of the subtasks included in the task flow.

In one embodiment of the present application, Step represents a subtask and the Action is responsible for communicating with downstream servers. Wherein, a Step correspondence comprises one or more Action instances, thereby realizing the interaction with the downstream server.

In an embodiment of the present application, each Step sets the next Step to be turned using its own set _ next _ Step () function, thereby forming a Step task chain table, which is a completed traffic flow.

Specifically, each Step is called according to the sequence of a Step input processing function, a request packing function handle _ encode (), a response completeness check function handle _ input (), a response processing function handle _ procs (), and a Step output processing function of the Action, so that processing of one subtask is completed.

Specifically, in the Step flow jump process, the Command instance calls start _ Step _ flow () to start the Step flow, calls its own get _ current _ Step function () to obtain the reference of the current Step, then executes the processing of the current Step, and caches the result of the Step processing.

In step S520, according to the subtask execution document, the server corresponding to the subtask executes the action corresponding to the subtask, and transmits the data obtained by processing the subtask to the server corresponding to the next subtask of the subtask until all subtasks in the task stream are executed.

In an embodiment of the present application, an action corresponding to a sub-task is processed in a server, and a specific processing manner of the action is according to a configuration parameter in a sub-task execution document. After the current Step processing is completed, the Command instance calls a get _ next _ Step function () of the Command instance, in the function implementation, according to the processing result of the current Step, the get _ next _ Step _ by _ ret () of the current Step is called to obtain the next Step reference, according to the subtask execution document, a server executing the subtask is determined to indicate the server to process the current subtask, and data obtained by processing the previous subtask is transmitted to the server until all subtasks in the task flow are executed, so that the jump of the Step flow is realized.

In an embodiment of the application, in the service response output stage, the last Step is used for being responsible for outputting the service response, and a response message queue of a queuing layer is obtained in an output processing function of the Step, and the service response message is inserted into the queue and then delivered to the underlying network architecture of the system to realize the output of the response.

In an embodiment of the application, after the step S240 sequentially executes, according to the execution sequence of the subtasks included in the task flow, a process of performing an action corresponding to each of the subtasks based on the execution document, the method may further include:

detecting whether all subtasks in the service to be processed are executed;

and if so, canceling and releasing the service instance and the memory space thereof.

In an embodiment of the present application, after the actions corresponding to all the subtasks included in the service instance are completely executed, in this embodiment, it is detected again whether all the subtasks in the service to be processed are completely executed. And after all subtasks in the service to be processed are executed, the service instance and the memory space of the service instance are cancelled and released.

Specifically, in the Service instance destruction stage, after the Step stream processing is completed, the Service _ Container invokes its remove _ Service () method to withdraw the Service instance from the Service Container set, and releases the memory space of the Service instance to make room for the memory space to process the rest of data.

In an embodiment of the present application, a service shutdown function may be further included, where the function is used when a sub-task in one service instance is executed completely, or a pending task stops processing, and the like. Specifically, in the Service close flow stage, the Service _ Container in this embodiment provides a function of closing the Service, and the function is implemented in its close () function. In the close () function, Service _ Container releases all Service instances.

Alternatively, the service is typically required to run continuously. Of course, special circumstances may arise. For example, when a signal interruption occurs, in order to deal with the similar situation, in the writing of the code, a corresponding signal processing function should be implemented, and the close () of Service _ Container should be called in the signal processing function to close the Service architecture, so as to safely release all the memory space.

In an embodiment of the present application, as shown in fig. 6, the service processing method in this embodiment may further include steps S610 to S620:

in step S610, the state of the execution process is represented by a preset enumeration type value corresponding to the state machine.

In an embodiment of the present application, a Flow-Framework Service architecture uses a state machine mechanism for a Service class (Service) included in a Service logic layer to manage and coordinate each module for implementing Service logic.

Specifically, the state machine in this embodiment uses an enumerated type value to indicate which state the service is handling, as shown in the following table:

enumeration type	Description of the state
		STATE_NEED_INIT	The need to initialize the service
STATE_INIT_FINISHED	The service has completed initialization
		STATE_SERVICE_PROCESSING	In the middle of service processing
STATE_NEED_CLOSE	Service has completed and needs to be shut down
		STATETIMEOUT	Service occurrence timeout
STATE_EXCEPTION	Service occurrence abnormality

TABLE 1 specific states of service classes

In step S620, the execution process is managed according to the enumeration type value.

In an embodiment of the application, an execution process is managed according to enumeration type values, different enumeration type values are used for representing different server states, and different server states have corresponding management modes.

Illustratively, several method interfaces are externally provided in the embodiment, wherein handle _ input () is responsible for processing input, handle _ out () is responsible for processing output, handle _ timeout () is responsible for processing timeout, get _ state () acquires the state of the current service instance, and the like.

In the technical solutions provided in some embodiments of the present application, at least two subtasks are obtained by splitting a service to be processed, and an action corresponding to each subtask and a service processing logic between the subtasks are determined; generating an execution document corresponding to the service to be processed according to preset base class information, and assembling and configuring the execution document corresponding to the service to be processed according to the service processing logic to obtain a task flow corresponding to the service to be processed; and sequentially executing actions corresponding to each subtask based on the execution document according to the execution sequence of the subtasks contained in the task flow. The business to be processed is reasonably split and configured, so that the business processing flow is very clear, and a business developer can utilize the framework to rapidly complete the development of business logic, thereby being beneficial to maintaining and developing a business system later and improving the development efficiency of the whole business system.

The following describes an embodiment of an apparatus of the present application, which may be used to execute a service processing method in the foregoing embodiment of the present application. For details that are not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the service processing method described above in the present application.

Fig. 7 schematically shows a block diagram of a traffic processing device according to an embodiment of the application.

Referring to fig. 7, a service processing apparatus 700 according to an embodiment of the present application includes: a splitting module 701, a documentation module 702, a configuration module 703, and an execution module 704.

The splitting module 701 is configured to split a service to be processed to obtain at least two subtasks, and determine an action corresponding to each subtask and a service processing logic between the subtasks; the document module 702 is configured to generate an execution document corresponding to the to-be-processed service according to preset base class information, where the execution document includes a service execution document corresponding to the to-be-processed service, the subtask execution document, and an action execution document; a configuration module 703, configured to assemble and configure an execution document corresponding to the service to be processed according to the service processing logic, so as to obtain a task stream corresponding to the service to be processed; an executing module 704, configured to sequentially execute, according to an execution order of the subtasks included in the task stream, an action corresponding to each subtask based on the execution document.

In some embodiments of the present application, based on the foregoing, the execution module 704 is configured to: calling the subtasks according to the subtask execution sequence contained in the task flow; and according to the subtask execution document, handing over a server corresponding to the subtask to execute the action corresponding to the subtask, and transmitting the data obtained by processing the subtask to a server corresponding to the next subtask of the subtask until all subtasks in the task flow are executed.

In some embodiments of the present application, based on the foregoing, the document module 702 is configured to: generating a service execution document corresponding to the service to be processed based on preset command base class information, wherein the service execution document comprises an input function for processing a service request in the service to be processed and a jump logic of the action, and the jump logic corresponds to the service processing logic; generating a subtask execution document corresponding to the subtask based on preset step base class information, wherein the step base class information comprises an action example of an action corresponding to the subtask, an input/output function of the subtask, and a mapping relation between the subtask and an adjacent subtask, and the mapping relation corresponds to the business processing logic; and generating an action execution document corresponding to the action based on preset action base class information, wherein the action base class information comprises an interaction mode between servers corresponding to each executed action.

In some embodiments of the present application, based on the foregoing solution, the configuration module 703 is configured to: configuring input and output functions and action instances of the subtask execution document based on the jump logic in the service execution document; generating a task linked list based on the mapping relation between each subtask and the adjacent subtask in the subtask execution document; and adding the interaction mode in the action execution document to the task chain table to obtain the task flow.

In some embodiments of the present application, based on the foregoing solution, the service processing apparatus 700 is further configured to: the loading unit is used for loading and analyzing the configuration file of the system to obtain configuration parameters; the instance unit is used for instantiating the service container class based on the configuration parameters to obtain a service instance; and the registering unit is used for determining a command identifier corresponding to the service to be processed according to the command list in the configuration file, registering a command class corresponding to the command identifier in the service instance, and executing the action in the task flow based on the command class.

In some embodiments of the present application, based on the foregoing solution, the service processing apparatus 700 is further configured to: the detection unit is used for detecting whether all subtasks in the service to be processed are executed or not; and the releasing unit is used for withdrawing and releasing the service instance and the memory space thereof if the service instance is in the first place.

In some embodiments of the present application, based on the foregoing solution, the service processing apparatus 700 is further configured to: the representing unit is used for representing the state of the executing process through a preset enumeration type value corresponding to the state machine; and the management unit is used for managing the execution process according to the enumeration type value.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or program product. Thus, various aspects of the invention may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.

The computer apparatus 80 according to this embodiment of the present invention is described below with reference to fig. 8. The computer device 80 shown in fig. 8 is only an example and should not bring any limitation to the function and scope of use of the embodiments of the present invention.

As shown in fig. 8, the computer device 80 is in the form of a general purpose computing device. The components of computer device 80 may include, but are not limited to: the at least one processing unit 81, the at least one memory unit 82, a bus 83 connecting different system components (including the memory unit 82 and the processing unit 81), and a display unit 84.

Wherein the storage unit stores program code that is executable by the processing unit 81 such that the processing unit 81 performs the steps according to various exemplary embodiments of the present invention as described in the section "example methods" above in this specification.

The storage unit 82 may include readable media in the form of volatile storage units, such as a random access storage unit (RAM)821 and/or a cache storage unit 822, and may further include a read only storage unit (ROM) 823.

The storage unit 82 may also include a program/utility 824 having a set (at least one) of program modules 825, such program modules 825 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

Bus 83 may be any of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The computer device 80 may also communicate with one or more external devices (e.g., keyboard, pointing device, bluetooth device, etc.), with one or more devices that enable a user to interact with the computer device 80, and/or with any devices (e.g., router, modem, etc.) that enable the computer device 80 to communicate with one or more other computing devices. Such communication may be through input/output (I/O) interfaces 85. Also, computer device 80 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network such as the Internet) via network adapter 86. As shown, network adapter 86 communicates with the other modules of computer device 80 via bus 83. It should be understood that although not shown in the figures, other hardware and/or software modules may be used in conjunction with computer device 80, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

There is also provided, in accordance with an embodiment of the present disclosure, a computer-readable storage medium having stored thereon a program product capable of implementing the above-described method of the present specification. In some possible embodiments, aspects of the invention may also be implemented in the form of a program product comprising program code means for causing a terminal device to carry out the steps according to various exemplary embodiments of the invention described in the above section "exemplary methods" of the present description, when said program product is run on the terminal device.

Referring to fig. 9, a program product 90 for implementing the above method according to an embodiment of the present invention is described, which may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited in this regard and, in the present document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A method for processing a service, comprising:

splitting a service to be processed to obtain at least two subtasks, and determining an action corresponding to each subtask and a service processing logic between the subtasks;

generating an execution document corresponding to the service to be processed according to preset base class information, wherein the execution document comprises a service execution document, a subtask execution document and an action execution document corresponding to the service to be processed;

assembling and configuring an execution document corresponding to the service to be processed according to the service processing logic to obtain a task flow corresponding to the service to be processed;

and sequentially executing actions corresponding to each subtask based on the execution document according to the execution sequence of the subtasks contained in the task flow.

2. The method according to claim 1, wherein sequentially executing the action corresponding to each subtask based on the execution document according to the execution sequence of the subtasks included in the task flow comprises:

calling the subtasks according to the subtask execution sequence contained in the task flow;

and according to the subtask execution document, handing over a server corresponding to the subtask to execute the action corresponding to the subtask, and transmitting the data obtained by processing the subtask to a server corresponding to the next subtask of the subtask until all subtasks in the task flow are executed.

3. The method according to claim 1, wherein generating the execution document corresponding to the service to be processed according to preset base class information comprises:

generating a service execution document corresponding to the service to be processed based on preset command base class information, wherein the service execution document comprises an input function for processing a service request in the service to be processed and a jump logic of the action, and the jump logic corresponds to the service processing logic;

generating a subtask execution document corresponding to the subtask based on preset step base class information, wherein the step base class information comprises an action example of an action corresponding to the subtask, an input/output function of the subtask, and a mapping relation between the subtask and an adjacent subtask, and the mapping relation corresponds to the business processing logic;

and generating an action execution document corresponding to the action based on preset action base class information, wherein the action base class information comprises an interaction mode between servers corresponding to each executed action.

4. The method according to claim 3, wherein assembling and configuring the execution document corresponding to the service to be processed according to the service processing logic to obtain the task flow corresponding to the service to be processed comprises:

configuring input and output functions and action instances of the subtask execution document based on the jump logic in the service execution document;

determining adjacent subtasks of each subtask based on the mapping relation between each subtask and the adjacent subtask in the subtask execution document, and generating a task linked list;

and adding the interaction mode in the action execution document to the task chain table to obtain the task flow.

5. The method according to claim 1, wherein before sequentially executing the action corresponding to each of the subtasks based on the execution document according to the execution order of the subtasks included in the task flow, the method further comprises:

loading and analyzing a configuration file of the system to obtain configuration parameters;

instantiating a service container class based on the configuration parameters to obtain a service instance;

and determining a command identifier corresponding to the service to be processed according to a command list in the configuration file, and registering a command class corresponding to the command identifier in the service instance so as to execute actions in the task flow based on the command class.

6. The method according to claim 5, wherein after the actions corresponding to each of the subtasks are sequentially executed based on the execution document according to the execution order of the subtasks included in the task flow, the method further comprises:

detecting whether all subtasks in the service to be processed are executed;

7. The method according to any one of claims 1-6, further comprising:

representing the state of the execution process through a preset enumeration type value corresponding to a state machine;

and managing the execution process according to the enumeration type value.

8. A traffic processing apparatus, characterized in that the apparatus comprises:

the system comprises a splitting module, a processing module and a processing module, wherein the splitting module is used for splitting a service to be processed to obtain at least two subtasks and determining an action corresponding to each subtask and a service processing logic between the subtasks;

the document module is used for generating an execution document corresponding to the service to be processed according to preset base class information, wherein the execution document comprises a service execution document corresponding to the service to be processed, the subtask execution document and an action execution document;

the configuration module is used for assembling and configuring the execution document corresponding to the service to be processed according to the service processing logic to obtain a task flow corresponding to the service to be processed;

and the execution module is used for sequentially executing the action corresponding to each subtask based on the execution document according to the execution sequence of the subtasks contained in the task flow.

9. An electronic device, characterized in that the electronic device comprises:

a processor;

a memory having stored thereon computer readable instructions which, when executed by the processor, implement the business process method of any one of claims 1 to 7.

10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out a service processing method according to any one of claims 1 to 7.