CN113076203B - Implementation method, implementation device and storage medium of application service - Google Patents

Abstract

The application discloses an implementation method, an implementation device and a storage medium of application services. Based on the application, a service request of a user carrying a user identifier can be acquired, then, a domain process arrangement file is called, at least one application service flow corresponding to the acquired service request is arranged, when the application service flow is realized, at least one service expansion packet corresponding to the user identifier is screened out from a service expansion packet set based on the user identifier carried by the service request corresponding to the application service flow, and the screened at least one service expansion packet is called to realize the application service flow corresponding to the service request. According to the embodiment of the application, the service logic of the service extension packet part is not developed any more by carrying out the introduction type calling on the service extension packet corresponding to each application service flow for realizing the service request. Meanwhile, the service extension packages corresponding to different users are respectively invoked, so that the service logic mashup is reduced, and the realization efficiency of the application service is improved.

Description

An implementation method, implementation device and storage medium of application services

Technical field

The present application relates to the field of computer technology, and in particular, to an implementation method, implementation device and storage medium of an application service.

Background technique

SAAS system (Software-as-a-service) is a model for providing software through the Internet. The service provider uniformly deploys the application software on its own server. Customers can order the required application software services from the service provider through the Internet according to their actual needs, and pay the service provider based on the ordered service quantity and usage time. , to obtain services provided by service providers over the Internet. Using the SAAS system, users no longer need to purchase software, but only need to rent Internet-based software from service providers to manage business activities. There is no need to maintain the software, the service provider will have full authority to manage and maintain the software.

Contents of the invention

Each embodiment of the present application provides an application service implementation method, implementation device, and storage medium, which helps to reduce repeated development logic and improve application service implementation efficiency.

In one embodiment, a method includes:

Obtain the user's service request, where the service request carries the user ID;

Call the domain process orchestration file used to implement the service request, orchestrate at least one application service process corresponding to the obtained service request, and when implementing the application service process, based on the information carried by the service request corresponding to the application service process user ID, and select at least one business expansion package corresponding to the user ID from the business expansion package collection;

Call at least one of the filtered business extension packages to implement the application service process corresponding to the service request.

Optionally, based on obtaining at least one sub-service request contained in the service request, the domain process orchestration file respectively calls the domain capability module used to implement the sub-service request, wherein the sub-service request carries the user corresponding to the corresponding service request. logo;

The domain capability module sorts the execution process of at least one business module that implements the sub-service request to implement the application service process corresponding to the sub-service request.

Optionally, when each business module implements the corresponding sub-user service request according to the execution process, based on the user identity, at least one business expansion package marked with the same user identity is queried in the expansion package collection, and when the query is found, the The business expansion package is called as one of the corresponding business modules in parallel or sequentially, and/or, the business module is replaced with the queried business expansion package and called.

Optionally, when no business extension package with the same user ID is queried in the service extension package set, request attribute information of the service request corresponding to the sub-user request is obtained, and the request attribute information is used to represent the preset value of At least one business extension package called by the service request;

Call at least one service extension package corresponding to the requested attribute information in the service extension package collection.

In another embodiment, an application service implementation device is provided, and the implementation device includes:

The acquisition module is used to obtain the user's service request, where the service request carries the user ID;

The orchestration module is used to call the domain process orchestration file used to implement the service request, orchestrate at least one application service process corresponding to the obtained service request, and when implementing the application service process, based on the application service process corresponding to the The user ID carried in the service request, and at least one business expansion package corresponding to the user ID is selected from the business expansion package collection;

Call the module to call at least one of the filtered business extension packages to implement the application service process corresponding to the service request.

Optionally, the orchestration module is also used to:

Based on obtaining at least one sub-service request included in the service request, the domain process orchestration file respectively calls the domain capability module used to implement the sub-service request, where the sub-service request carries the user identification corresponding to the corresponding service request;

The domain capability module sorts the execution process of at least one business module that implements the sub-service request to implement the application service process corresponding to the sub-service request.

Optionally, the orchestration module is also used to:

When each business module implements the corresponding sub-user service request according to the execution process, based on the user identity, it queries at least one business expansion package with the same user identity in the expansion package collection, and when the query is found, calls the business expansion package as One of the corresponding business modules is called in parallel or sequentially, and/or, the business module is replaced with the queried business extension package and called.

Optionally, the orchestration module is also used to:

When no business expansion package with the same user ID is queried in the business expansion package collection, the request attribute information of the service request corresponding to the sub-user request is obtained. The request attribute information is used to represent the preset call for the service request. At least one business expansion pack;

Call at least one service extension package corresponding to the requested attribute information in the service extension package collection.

In another embodiment of the present application, a non-transitory computer-readable storage medium is provided, the non-transitory computer-readable storage medium stores instructions that, when executed by a processor, cause the processor to perform the above-mentioned Each step in the implementation method of an application service.

In another embodiment of the present application, a terminal device is provided, including a processor, and the processor is configured to execute each step in the above method for implementing an application service.

Based on the above embodiments and based on this application, the user's service request can be obtained, where the service request carries the user identification, and the domain process orchestration file used to implement the service request is called, and at least one application corresponding to the obtained service request is The service process is arranged, and when the application service process is implemented, based on the user identification carried in the service request corresponding to the application service process, at least one business expansion package corresponding to the user identification is selected from the business expansion package collection, Finally, call at least one of the filtered business extension packages to implement the application service process corresponding to the service request. In the embodiment of this application, the business expansion package corresponding to each application service process that implements the service request is introduced and called, and the business logic of the business expansion package is no longer developed. At the same time, the business extension packages corresponding to different users are called separately, which reduces the complexity of business logic and improves the efficiency of application service implementation.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required to be used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application and therefore do not It should be regarded as a limitation of the scope. For those of ordinary skill in the art, other relevant drawings can be obtained based on these drawings without exerting creative efforts.

Figure 1 is an exemplary architectural schematic diagram of an implementation method of application services in an embodiment of the present application;

Figure 2 shows a schematic flowchart of a method for implementing an application service provided by an embodiment of the present application;

Figure 3 is a schematic diagram of a specific process of an application service implementation method provided by an embodiment of the present application;

Figure 4 is a schematic diagram of the business logic flow of an application service implementation method provided by an embodiment of the present application;

Figure 5 shows a schematic diagram of a device for implementing an application service according to an embodiment of the present application;

Figure 6 shows a schematic diagram of a terminal device provided by an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of this application.

The terms "first", "second", "third", "fourth", etc. (if present) in the description and claims of this application and the above-mentioned drawings are used to distinguish similar objects without necessarily using Used to describe a specific order or sequence. It is to be understood that the data so used are interchangeable under appropriate circumstances so that implementations of the application described herein, for example, can be practiced in sequences other than those illustrated or described herein. Furthermore, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units need not be limited to those steps or units that are expressly listed, but may include steps or units that are not expressly listed or that are not specific to the process, method, product, or device. Other steps or units inherent to the equipment.

Based on the problems in the prior art, embodiments of the present application provide a method for implementing application services, which can be applied to the field of computer technology. Figure 1 is an exemplary architectural diagram of an application service implementation method in an embodiment of the present application. Among them, as shown in Figure 1, the applicable scenario of the embodiment of the present application is mainly the SAAS system. Optionally, at the architectural level of service implementation, when the system receives a service request from a user, the application layer 11 coordinates the received service request and concretely implements at least one application service process for the service request. An application service process can call multiple business module implementations published by application programming interface (API) layer 13. The specific implementation process of an application service process uses the domain capability module of the domain service layer 12 to define the business logic and sequence the execution process. Correspondingly, the service interface corresponding to the business module published by the API layer 13 executes business logic for the corresponding domain capability module and implements the application service process.

As shown in Figure 1, a service request corresponds to a specific application service process. The application service process can be understood as describing each execution process from start to end of the specific operation corresponding to the service request. After an application service process is arranged through the domain process orchestration file, it can correspond to multiple domain capability modules (Domain capability module 1, Domain capability module 2, ... Domain capability module N). A domain capability module is used to describe the detailed operations of each execution process in the application service process. For example, if the user's service request is to settle goods in the shopping cart, the service request will be concreted in the application layer 11 and the application service process is product amount calculation → payment operation → order generation. Each execution process can be orchestrated by the corresponding domain capability module in the domain service layer 12. Furthermore, the service interface implementation corresponding to each business module (business module 1, business module 2, ..., business module K) of the API layer 13 is called. Among them, the execution process of a domain capability module can be implemented by calling multiple business modules.

Figure 2 shows a schematic flowchart of a method for implementing an application service provided by an embodiment of the present application. Among them, the following steps can be included:

Step S101: Obtain the user's service request, where the service request carries the user identification.

In this step, the service request in the embodiment of the present application can be a service request that users in the SAAS system need to implement. For example, the service request used in Internet transaction scenarios can be specific services such as query transactions, shopping cart settlement, and customer contact. ask. Among them, the obtained service request carries the corresponding user ID.

Step S102: Call the domain process orchestration file used to implement the service request, orchestrate at least one application service process corresponding to the obtained service request, and when implementing the application service process, based on the service corresponding to the application service process The user ID carried in the request is used to filter out at least one service extension package corresponding to the user ID from the service extension package collection.

In this step, based on the obtained service request, the received service request is coordinated at the application layer, and at least one application service process of the service request is implemented concretely. Among them, each service request can contain multiple service sub-requests, and each service self-request can correspond to an application service process. Therefore, each service request can correspond to at least one application service process.

For each application service process, the domain capability module of the domain service layer defines the business logic and sorts the execution process to implement the application service process. Among them, the domain process orchestration file is called in the domain service layer to orchestrate the application service process corresponding to each sub-service request. Optionally, a domain capability module in the domain service layer can be called to orchestrate the complete business logic of the application service, so that the business module in the API layer can be called according to the business logic to execute the business logic orchestrated by the domain capability module to achieve The complete application service process corresponding to the service request.

In the foregoing situation, the service request can carry the user ID and filter out at least one business extension package corresponding to the user ID from the preset service extension package set when executing the corresponding application service process. Among them, business expansion package and business module are concepts of the same level. The difference is that the business extension package can be developed and maintained by a third party or the user themselves, and communicates with the system in the embodiment of the present application through an interface connection to execute all or part of the business logic in the application service process. The business extension package can be tagged with the same user ID as the corresponding service request. In addition, the business module can be developed and maintained by the system in the embodiment of the present application to execute all or part of the business logic in the application service process.

Step S103: Call at least one of the selected business extension packages to implement the application service process corresponding to the service request.

In this step, in the embodiment of the present application, when there is a business extension package with the same identity as the user ID carried in the service request in the business extension package set, the business extension package is called to implement the application service process corresponding to the service request.

Based on the above embodiment, the user's service request can be obtained, where the service request carries the user identification, and the domain process orchestration file used to implement the service request is called to orchestrate at least one application service process corresponding to the obtained service request. , and when implementing the application service process, based on the user identification carried in the service request corresponding to the application service process, at least one business expansion package corresponding to the user identification is filtered out from the business expansion package collection, and finally, the filtering is called At least one of the outgoing business extension packages implements the application service process corresponding to the service request. In the embodiment of this application, the business expansion package corresponding to each application service process that implements the service request is introduced and called, and the business logic of the business expansion package is no longer developed. At the same time, the business extension packages corresponding to different users are called separately, which reduces the complexity of business logic and improves the efficiency of application service implementation.

FIG. 3 is a schematic diagram of a specific process of an application service implementation method provided by an embodiment of the present application. Among them, this part can include the following steps:

Step S201: Obtain the service request and obtain the sub-service requests therein.

In this step, taking the embodiment of the present application as an example, in an Internet transaction scenario, the obtained service request may include multiple execution process groups. Each execution process corresponds to a self-service request. For example, when the user request is "Commodity Settlement", the execution process of the application service process corresponding to the service request may include "Create Order" → "Calculate Settlement Amount" → "Buyer Payment" → "Payment Verification" and other execution processes. Each execution process can be requested as a subservice.

In addition, each service request carries the user ID. Correspondingly, each sub-service request carries the same user ID.

Step S202: The domain process orchestration file arranges the domain capability modules for the service request.

In this step, based on obtaining at least one sub-service request contained in the service request, the domain process orchestration file respectively calls the domain capability module used to implement the sub-service request, where the sub-service request carries the user corresponding to the corresponding service request. logo.

Optionally, the user request corresponds to a domain service, where the domain service can be orchestrated by calling multiple domain capability modules through the domain process orchestration file. Orchestration can be based on Extensible Markup Language (XML) or process engine, and each domain capability module serves typical businesses in that domain. According to the sub-service requests contained in the user service request, the domain process orchestration file arranges the corresponding domain capability module for each sub-service request.

Step S203: The domain capability module arranges the business module for the execution process required for the sub-service request.

In this step, the domain capability module sorts the execution process of at least one business module that implements the sub-service request, so as to implement the application service process corresponding to the sub-service request. Optionally, the execution process in the sub-service request can be implemented by multiple business modules. For example, the execution process of "buyer payment" can be executed by calling the business module corresponding to UnionPay payment or the business module corresponding to WeChat payment. It can be understood that this example is an example of calling business modules in parallel, and the business modules can also be called sequentially in the order in the execution process.

The business module is generally set up at the API layer. Therefore, the domain capability module arranges the business module for the execution process required for the sub-service request to configure the calling sequence of the service interface corresponding to the business module that implements the sub-service request.

Step S204: Check whether the service expansion package set contains a service expansion package with the same user ID.

In this step, generally, the SAAS system is designed to be completely isolated between users, or it is the same operating environment, and the business logic of different users is branched through if-else judgment; or the business logic of different users is mixed together. To address this problem, embodiments of the present application provide a preset set of service expansion packages. Among them, the business extension package set has the same functions as the business module and is used to implement the user's business logic. The difference is that business modules are generally developed and maintained by the system and are general. The business expansion package can be developed and maintained by a third party or user, with personalized business logic implementation. For example, in the execution process of "Buyer Payment", the business logic of the corresponding business module provided by the system may be UnionPay payment. At this time, the business expansion package can be configured as Alipay payment or WeChat payment based on user needs. Personalized business expansion packages can be marked with corresponding user IDs.

Based on the foregoing, when each business module implements the corresponding sub-user service request according to the execution process, based on the user identity, at least one business expansion package with the same user identity is queried in the expansion package collection.

Step S205: Call and query the service expansion package with the same user ID.

In this step, when the user ID marked with the service request is queried, the business extension package is called as one of the corresponding business modules for parallel or sequential calls, and/or the business module is replaced with the queried business extension. package and make the call.

Here, the personalized business expansion package can be retained at the same time as the business module to implement the execution process. You can also replace the business module with the queried business expansion package and call it.

Step S206: Call at least one service extension package corresponding to the requested attribute information.

In this step, when the business expansion package with the same user ID is not queried in the business expansion package collection, the request attribute information of the service request corresponding to the sub-user request is obtained. The request attribute information is used to indicate that the preset value is At least one business extension package called by the service request. And, calling at least one service extension package corresponding to the requested attribute information in the service extension package set.

Optionally, if the user identification corresponding to the user request does not exist in the service extension package set, obtain the request attribute information of the service request corresponding to the sub-user request. Among them, request attribute information can be preset for user requests that may be executed by each user. The request attribute information is the basic attribute of the service request that the user can execute. For example, an industry class can be set as the request attribute information. For example, for fresh food transactions in Internet transactions, a temperature control business expansion package can be configured for this industry type. When the obtained request attribute information is an industry class, at least one business expansion package corresponding to the request attribute information is called.

In the above-mentioned steps S205 and S206, when the service extension package is called, the business logic code of the running user is routed according to the user ID.

In addition, the overall implementation framework can choose the SpringBoot container, and the implementation of business modules can rely on SpringBoot's automatic configuration to reduce additional configuration when introducing business extension packages. Among them, you can customize the @AutowireExtension annotation on the implementation class of the business extension package. Using this annotation, the implementation class will be injected into the SpringBoot container. Among them, for example, the service interface SomeBizExtension of the business extension package can be configured as SomeTenant1BizExtensionlmpl for user 1's business extension package, and the service interface for user 2's business extension package is SomeTenant2BizExtensionlmpl. Use the custom annotation @AutowireExtension to generate a dynamic proxy class based on the service interface SomeBizExtension of the business extension package. The proxy class uses the user ID as the key value to cache the business extension package.

The service interface of the business extension package called in the domain capability module, if the user ID is different, is generally provided by an independent JAR package and introduced into the current execution process. In addition, when deploying the overall module, you can selectively rely on the business expansion packages of some or all users according to different clusters.

Figure 4 is a schematic diagram of the business logic flow of an application service implementation method provided by an embodiment of the present application. Among them, service request 1 in the application layer (the transfer method from other service requests 2 to service request N is similar to service request 1 and will not be repeated here) can include multiple sub-user service requests (sub-user service request 1, sub-user service request 2. ...Sub-user service request M). The domain service layer can call a domain capability module (domain capability module 1, domain capability module 2,... domain capability module M) in the domain service layer to orchestrate the complete business logic of the application service, so that the corresponding business logic can be arranged according to the business logic. The service interface of the business module (the service interface of business module 1, the service interface of business module 2,..., the service interface of business module K) calls the business module (business module 1, business module 2,..., business module K) in the API layer Execute the business logic orchestrated by the domain capability module to realize the complete application service process corresponding to the service request.

In summary, the embodiment of the present application implements an application service implementation method through the above method. By placing the business extension packages corresponding to each application service process that implements service requests in a third party for development and maintenance, and making incoming calls, the business logic of the business extension package is no longer developed. Moreover, the business logic code of different users can be plugged in and out when deployed. At the same time, the business extension packages corresponding to different users are called separately. Changes in the business logic of different users do not affect the business logic of other users, reducing the confusion of business logic, realizing a dynamic and scalable domain service implementation method, and improving the application Service implementation efficiency.

Based on the same inventive concept as the method for implementing an application service described above, FIG. 5 shows a schematic diagram of an apparatus for implementing an application service further provided by an embodiment of the present application. As shown in Figure 5, the implementation device may include:

The acquisition module 51 is used to obtain the user's service request, where the service request carries the user identification;

The orchestration module 52 is used to call the domain process orchestration file used to implement the service request, orchestrate at least one application service process corresponding to the obtained service request, and when implementing the application service process, based on the application service process The user ID carried in the corresponding service request is used to filter out at least one business expansion package corresponding to the user ID from the business expansion package collection;

The calling module 53 calls the filtered at least one business extension package to implement the application service process corresponding to the service request.

In this embodiment, the specific functions and interaction methods of the acquisition module 51, the arrangement module 52 and the calling module 53 can be found in the corresponding embodiment records in Figure 2, and will not be described again here.

Optionally, the orchestration module 52 is also used to:

Based on obtaining at least one sub-service request included in the service request, the domain process orchestration file respectively calls the domain capability module used to implement the sub-service request, where the sub-service request carries the user identification corresponding to the corresponding service request;

The domain capability module sorts the execution process of at least one business module that implements the sub-service request to implement the application service process corresponding to the sub-service request.

Optionally, the orchestration module 52 is also used to:

When each business module implements the corresponding sub-user service request according to the execution process, based on the user identity, it queries at least one business expansion package with the same user identity in the expansion package collection, and when the query is found, calls the business expansion package as One of the corresponding business modules is called in parallel or sequentially, and/or, the business module is replaced with the queried business extension package and called.

Optionally, the orchestration module 52 is also used to:

When no business expansion package with the same user ID is queried in the business expansion package collection, the request attribute information of the service request corresponding to the sub-user request is obtained. The request attribute information is used to represent the preset call for the service request. At least one business expansion pack;

Call at least one service extension package corresponding to the requested attribute information in the service extension package collection.

Figure 6 shows a schematic diagram of a terminal device provided by an embodiment of the present application. As shown in Figure 6, another embodiment of the present application also provides a terminal device, which may include a processor 601, wherein the processor 601 is configured to execute the above-mentioned template learning method for voice response and a method for using Steps of a method for generating information for voice response. It can also be seen from Figure 6 that the terminal device provided by the above embodiment also includes a non-transitory computer-readable storage medium 602. The non-transitory computer-readable storage medium 602 stores a computer program, and the computer program is run by the processor 601 The steps of the above-mentioned template learning method for voice response and the information generation method for voice response are performed. In actual applications, the terminal device can be one or more computers, as long as it includes the above-mentioned computer-readable medium and processor.

Specifically, the storage medium can be a general storage medium, such as a removable disk, a hard disk, FLASH, etc. When the computer program on the storage medium is run, it can execute the above-mentioned template learning method for voice response and a Various steps in a message generation method for voice response. In practical applications, the computer-readable medium may be included in the device/device/system described in the above embodiments, or may exist separately without being assembled into the device/device/system. The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed, the above-mentioned template learning method for voice response and an information generation method for voice response can be executed. various steps in.

According to the embodiments disclosed in the present application, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, but is not limited to, portable computer disks, hard disks, random access memory (RAM), and read-only memory (ROM). ), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above, but shall not be used to limit this application scope of protection. In the embodiments disclosed herein, a computer-readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

The flowcharts and block diagrams in the drawings of this application illustrate the possible implementation architecture, functions and operations of systems, methods and computer program products according to various embodiments disclosed in this application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code that contains one or more logic functions that implement the specified executable instructions. It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in a different figure. For example, two blocks shown connected may actually execute substantially in parallel, or they may sometimes execute in the reverse order, depending on the functionality involved. It will also be noted that each block in the block diagram or flowchart illustration, and combinations of blocks in the block diagram or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or operations, or may be implemented by special purpose hardware-based systems that perform the specified functions or operations. Achieved by a combination of specialized hardware and computer instructions.

It will be understood by those skilled in the art that the features described in the various embodiments and/or claims of the present disclosure may be combined and/or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments and/or claims of the present application may be combined and/or combined in various ways without departing from the spirit and teachings of the present application, and all of these combinations and/or combinations fall within the disclosure scope of this application.

Finally, it should be noted that the above-mentioned embodiments are only specific implementation modes of the present application, and are used to illustrate the technical solutions of the present application, but not to limit them. The protection scope of the present application is not limited thereto. Although refer to the foregoing The embodiments describe the present application in detail. Those of ordinary skill in the art should understand that any person familiar with the technical field can still make changes to the technical solutions recorded in the foregoing embodiments within the technical scope disclosed in the present application. It may be easy to think of changes, or equivalent substitutions of some of the technical features; and these changes, changes or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and shall be covered by this application. within the scope of protection. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims (10)

1. A method for implementing an application service, comprising:

acquiring a service request of a user, wherein the service request carries a user identifier;

calling a domain process arrangement file for realizing the service request, and arranging at least one application service flow corresponding to the acquired service request, so that a service module in an API layer is called according to the service logic to execute the service logic arranged by the domain capacity module; the business module is developed and maintained by a system and has generality; when the application service flow is realized, at least one business expansion packet corresponding to the user identification is screened out from a business expansion packet set based on the user identification carried by the service request corresponding to the application service flow; the service extension package is developed and maintained by a third party or the user and has personalized service logic implementation;

and calling the screened at least one business expansion packet to realize the application service flow corresponding to the service request.

2. The implementation method according to claim 1, wherein the step of calling a domain process arrangement file for implementing the service request to arrange at least one application service flow corresponding to the acquired service request includes:

based on the obtained at least one sub-service request contained in the service request, the domain process arrangement file respectively calls a domain capability module for realizing the sub-service request, wherein the sub-service request carries a user identifier corresponding to the corresponding service request;

the domain capability module performs execution flow sequencing on at least one business module for realizing the sub-service request so as to realize the application service flow corresponding to the sub-service request.

3. The implementation method according to claim 2, wherein the step of screening at least one service extension packet corresponding to the user identifier from the service extension packet set based on the user identifier carried by the service request corresponding to the application service flow includes:

and when each business module realizes the corresponding sub-user service request according to the execution flow, inquiring at least one business expansion packet with the same user identifier in the expansion packet set based on the user identifier, and calling the business expansion packet as one of the corresponding business modules to carry out parallel or sequential calling and/or replacing the business module to carry out calling for the inquired business expansion packet when inquiring.

4. The implementation method according to claim 2, wherein the step of screening at least one service extension packet corresponding to the user identifier from the service extension packet set based on the user identifier carried by the service request corresponding to the application service flow further includes:

when the service extension packages with the same marks and the user identification are not queried in the service extension package set, acquiring request attribute information of a service request corresponding to the sub-service request, wherein the request attribute information is used for representing at least one service extension package preset to be called by the service request;

and invoking at least one service extension packet corresponding to the request attribute information in the service extension packet set.

5. An apparatus for implementing an application service, comprising:

the acquisition module is used for acquiring a service request of a user, wherein the service request carries a user identifier;

the arrangement module is used for calling a domain process arrangement file for realizing the service request, arranging at least one application service flow corresponding to the acquired service request, and enabling the service module in the API layer to be called according to the service logic to execute the service logic arranged by the domain capacity module; the business module is developed and maintained by a system and has generality; when the application service flow is realized, at least one business expansion packet corresponding to the user identification is screened out from a business expansion packet set based on the user identification carried by the service request corresponding to the application service flow; the service extension package is developed and maintained by a third party or the user and has personalized service logic implementation;

and the calling module is used for calling the screened at least one business expansion packet to realize the application service flow corresponding to the service request.

6. The implementation of claim 5, wherein the orchestration module is further configured to:

based on the obtained at least one sub-service request contained in the service request, the domain process arrangement file respectively calls a domain capability module for realizing the sub-service request, wherein the sub-service request carries a user identifier corresponding to the corresponding service request;

the domain capability module performs execution flow sequencing on at least one business module for realizing the sub-service request so as to realize the application service flow corresponding to the sub-service request.

7. The implementation of claim 6, wherein the orchestration module is further configured to:

and when each business module realizes the corresponding sub-user service request according to the execution flow, inquiring at least one business expansion packet with the same user identifier in the expansion packet set based on the user identifier, and calling the business expansion packet as one of the corresponding business modules to carry out parallel or sequential calling and/or replacing the business module to carry out calling for the inquired business expansion packet when inquiring.

8. The implementation of claim 6, wherein the orchestration module is further configured to:

when the service extension packages with the same marks and the user identification are not queried in the service extension package set, acquiring request attribute information of a service request corresponding to the sub-service request, wherein the request attribute information is used for representing at least one service extension package preset to be called by the service request;

and invoking at least one service extension packet corresponding to the request attribute information in the service extension packet set.

9. A non-transitory computer readable storage medium storing instructions which, when executed by a processor, cause the processor to perform the steps in a method of implementing an application service according to any one of claims 1 to 4.

10. A terminal device comprising a processor for performing the steps of the method of implementing an application service according to any of claims 1 to 4.