Service construction method and apparatus, electronic device, and storage medium

Abstract

The application relates to a service construction method and device, electronic equipment and a storage medium method, wherein the method comprises the following steps: acquiring a target SDK used for service construction, wherein the target SDK is an SDK to be accessed to a service framework, a prototype class in the target SDK is a subclass taking a target service class in a target DSL as a base class, and the target service class defines a target interface; acquiring, by the service framework, the subclass taking the target service class as the base class in the target SDK, to obtain each prototype class in the target SDK, wherein the target interface is implemented by the subclass taking the target service class as the base class; and instantiating each prototype class by the service framework, completing access of the service framework to the target SDK, and obtaining a target service. The application solves the technical problem of low efficiency in converting an algorithm prototype into a service in the related art.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of artificial intelligence, and in particular to a service construction method and device, an electronic device, and a storage medium. BACKGROUND

[0002] With the rapid development of the technical field of artificial intelligence, more and more applications need AI algorithms to empower them. The form in which algorithms are finally implemented is usually to be encapsulated in a service first, and then called through the external interface of the service, that is, to go through a service encapsulation process. The output of the algorithm prototype is usually in the form of SDK, but due to the different code habits and quality of developers of different SDKs, the process of service of SDK needs to consume a lot of human cost, and the efficiency of converting the algorithm prototype into a service is low.

[0003] At present, there is no effective solution to the problem that the efficiency of converting the algorithm prototype into a service is low. SUMMARY

[0004] The present application provides a service construction method and device, an electronic device, and a storage medium to at least solve the technical problem of low efficiency of converting an algorithm prototype into a service in the related art.

[0005] According to an aspect of an embodiment of the present application, a service construction method is provided, including: obtaining a target SDK for service construction, wherein the target SDK is an SDK to be accessed to a service framework, a prototype class in the target SDK is a subclass with a target service class in a target DSL as a base class, and the target service class defines a target interface; obtaining, by the service framework, the subclass with the target service class as the base class in the target SDK to obtain each prototype class in the target SDK, wherein the target interface is implemented by the subclass with the target service class as the base class; and instantiating each prototype class by the service framework to complete access of the service framework to the target SDK and obtain a target service.

[0006] According to another aspect of an embodiment of the present application, a service construction device is also provided, including: a first obtaining module configured to obtain a target SDK for service construction, wherein the target SDK is an SDK to be accessed to a service framework, a prototype class in the target SDK is a subclass with a target service class in a target DSL as a base class, and the target service class defines a target interface; a second obtaining module configured to obtain, by the service framework, the subclass with the target service class as the base class in the target SDK to obtain each prototype class in the target SDK, wherein the target interface is implemented by the subclass with the target service class as the base class; and a service generation module configured to instantiate each prototype class by the service framework to complete access of the service framework to the target SDK and obtain a target service.

[0007] According to another aspect of the embodiments of the present application, a storage medium is also provided, which includes a stored program, and the program performs the method described above when running.

[0008] According to another aspect of the embodiments of the present application, an electronic device is also provided, which includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete the communication among each other through the communication bus; the memory is used to store a computer program; and the processor is used to execute the computer program to implement the method according to any one of the preceding embodiments.

[0009] According to an aspect of the present application, a computer readable storage medium is provided, which includes a stored program, and the program performs the method according to any one of the preceding embodiments when running.

[0010] In the embodiments of the present application, the target SDK used for service construction is acquired, wherein the target SDK is an SDK to be accessed to the service framework, the prototype classes in the target SDK are subclasses with the target service class in the target DSL as the base class, and the target interface is defined in the target service class; each prototype class in the target SDK is obtained by the service framework acquiring the subclass with the target service class as the base class, wherein the target interface is implemented by the subclass with the target service class as the base class; each prototype class is instantiated by the service framework, the access of the service framework to the target SDK is completed, and the target service is obtained in the manner, the service framework acquires the subclass with the target service class as the base class in a subscription mode, thereby obtaining the prototype class in the target SDK, and the prototype class is instantiated to access the target SDK to the service framework to obtain the target service, so as to achieve the purpose of automatically converting the algorithm prototype into the service. Since the target interface is defined in the target service class in the target DSL, and the target SDK is inherited from the target service class and has a unified interface standard, the service framework can be quickly accessed, the labor cost and time cost of accessing the SDK to the service framework are reduced, and thus the technical problem of low efficiency of converting the algorithm prototype into the service in the related art is solved. BRIEF DESCRIPTION OF DRAWINGS

[0011] The accompanying drawings, which are included to provide a further understanding of the present application, form a part of the present application and illustrate the illustrative embodiments of the present application and the description thereof, and do not limit the present application. In the drawings:

[0012] Figure 1 FIG. 1 is a schematic diagram of a hardware environment of a service construction method according to an embodiment of the present application;

[0013] Figure 2 FIG. 2 is a flowchart of an optional service construction method according to an embodiment of the present application;

[0014] Figure 3 is a whole flow schematic diagram of an optional service construction scheme according to an embodiment of the application;

[0015] Figure 4 is a schematic diagram of an optional service construction apparatus according to an embodiment of the application; and,

[0016] Figure 5 is a structural schematic diagram of an electronic device according to an embodiment of the application. DETAILED DESCRIPTION

[0017] In order to enable persons skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by persons skilled in the art without creative work should fall within the scope of protection of the present application.

[0018] It should be noted that the terms "first", "second", and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to include only those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to the process, method, product or device.

[0019] First, some of the nouns or terms appearing in the description of the embodiments of the present application are applicable to the following explanations:

[0020] SDK (Software Development Kit): software development kit, is a collection of development tools used by software engineers when building applications for a specific software package, software framework, hardware platform, operating system, etc.

[0021] Class Definition: A class is a collection of objects that share the same attributes and methods. It defines the attributes and methods that are common to every object in the collection. When you write a class, you give it some general behavior, and when you create objects based on the class, you can give each object the general behavior and then give each object its own unique personality as needed. An object is an instance of a class, and creating an object from a class is called instantiation.

[0022] Class Inheritance: Inheritance is a way to create a new class that can inherit one or more base classes, and the new class is called a subclass or derived class, and the base class is called a parent class or superclass.

[0023] Abstract Class: An abstract class is often used to represent abstract concepts derived from the analysis and design of a problem domain, and is an abstraction of a series of specific concepts that appear different but are essentially the same. A class modified by "abstract" in a programming statement is an abstract class. In C++, a class containing pure virtual functions is called an abstract class, and it cannot generate objects; in Java, a class containing abstract methods is called an abstract class, and it also cannot generate objects; Python also has the concept of abstract classes, which specify a series of methods and specify methods that must be implemented by inherited classes. Abstract classes are incomplete and can only be used as base classes. In object-oriented methods, abstract classes are mainly used for type hiding and as global variables.

[0024] Interface: An abstract type is a collection of abstract methods, and an interface is usually declared with "interface". In some object-oriented languages, a class can implement multiple interfaces but can only inherit from one abstract (or any other type) class. A class that implements an interface must implement all the methods described in the interface, otherwise it must be declared as an abstract class. In Python, interfaces are implemented by abstract classes and abstract methods.

[0025] DSL (Domain Specific Language): A domain-specific language is a language designed for a specific context in a particular field. Here, the field refers to a business context (such as banking, insurance, etc.) or an application context (such as web applications, databases, AI algorithms, etc.). Another concept compared to this is GPL (general-purpose language), which can be widely used in various business or application problems. Common GPLs include Java, Python, etc.

[0026] From the perspective of usage, languages can be divided into two categories: (1) DSL: a language written or represented in DSL form. (2) Host Language: a language used to execute or process DSL. From the implementation, DSL is divided into external DSL and internal DSL. A DSL written by a different language and processed by another host language is called external DSL. If the DSL and the host language are the same language, the DSL is called internal DSL, which is also called embedded DSL, because the DSL is written and processed by the same semantic host language.

[0027] Embedded DSL is a domain-specific language with a general-purpose language as a host language. It uses an existing programming language as a host language to establish various semantics that are specifically oriented to a specific domain based on the facilities of the host language. The advantages of embedded DSL are as follows: strong expressiveness and reusability of language features of the host language; reusability of supporting facilities (library ecology, compilation tools, development environment, etc.) of the host language; low construction threshold and seamless embedding into host language engineering, which can facilitate interaction across the "Domain".

[0028] The publish-subscribe pattern is a software design pattern. In the publish-subscribe pattern, a message sender called a publisher does not send messages directly to a subscriber, which means that the publisher and the subscriber do not know each other. There is a third component between the publisher and the subscriber, called a message broker or dispatch center or middleware, which maintains the contact between the publisher and the subscriber, filters all incoming messages from the publisher and distributes them to the subscriber accordingly.

[0029] According to an aspect of an embodiment of the present application, a method for service construction is provided.

[0030] Optionally, in the embodiment, the service construction method can be applied to a hardware environment composed of a terminal 101 and a server 103 as shown in Figure 1 . As shown in Figure 1As shown, the server 103 is connected with the terminal 101 through a network, which can be used to provide service construction services (such as SDK service, algorithm encapsulation, etc.) for the terminal or the client installed on the terminal, and a database 105 can be set on the server or independently of the server, which is used to provide data storage services for the server 103. The above network includes but is not limited to a wide area network, a metropolitan area network or a local area network, and the terminal 101 is not limited to a PC, a mobile phone, a tablet computer, etc. The service construction method of the embodiment of the application can be executed by the server 103, or can be executed by the terminal 101, or can be executed by the server 103 and the terminal 101 together. Wherein, the terminal 101 executing the service construction method of the embodiment of the application can also be executed by the client installed thereon. Subsequently, a service construction method executed on the server is taken as an example to be described.

[0031] Figure 2 is a flow chart of an optional service construction method according to the embodiment of the application, as shown in the figure, the method can include the following steps: Figure 2

[0032] Step S202, obtaining a target SDK for service construction, wherein the target SDK is an SDK to be accessed to the service framework, the prototype classes in the target SDK are subclasses with a target service class in a target DSL as a base class, and the target service class defines a target interface;

[0033] Step S204, obtaining each prototype class in the target SDK through the service framework for the subclass with the target service class as the base class, wherein the target interface is implemented through the subclass with the target service class as the base class;

[0034] Step S206, instantiating each prototype class through the service framework, completing the access of the target SDK to the service framework, and obtaining a target service.

[0035] Through the above steps S202 to S206, the service framework adopts a subscription mode to dynamically obtain the subclass with the target service class as the base class, thereby obtaining the prototype class in the target SDK, and instantiating the prototype class to access the target SDK to the service framework to obtain the target service, which achieves the purpose of automatically converting the algorithm prototype into a service. Since the target service class in the target DSL defines the target interface, and the target SDK inherits from the target service class and has a unified interface standard, the service framework can be quickly accessed, reducing the labor cost and time cost of accessing the SDK to the service framework, thereby solving the technical problem of low efficiency of converting the algorithm prototype into a service in the related art.

[0036] ​In the technical solution provided in step S202, the server obtains a target SDK for service construction, wherein the target SDK is an SDK to be accessed to the service framework, and a prototype class in the target SDK is a subclass with a target service class in a target DSL as a base class, and the target service class defines a target interface.

[0037] The target DSL described above refers to a domain specific language with a general language as a host language, and belongs to an embedded DSL (Embedded Domain Specific Language). The host language of the target DSL can be an object-oriented programming language including but not limited to Python, Java, C++, and the like.

[0038] The storage form of the target DSL is not limited, and can be stored in the form of a module, a library, a file, or the like. For example, the target DSL is an embedded DSL with Python as a host language, and is packaged into a wheel package in the form of a wheel, that is, the wheel package can be downloaded and installed in any Python development environment by using a pip tool.

[0039] For example, for service construction in the field of AI algorithms, since the algorithm developers in the field of AI algorithms usually use Python language, the target DSL can be an embedded DSL module based on Python, which is easy to install and use, and the implementation based on Python also makes it easy for developers to understand and accept.

[0040] The target DSL can include one or more classes, including a target service class, and the target service class can define interfaces and methods, can define abstract interfaces that must be implemented by subclasses, and can define general methods or interfaces that can be inherited or overridden.

[0041] The target interface is an interface defined in the target service class and must be implemented by the subclass. The number of target interfaces is not limited and can be one or more.

[0042] For example, the target interface can be load_model (an interface for importing a model), init_model (an interface for model initialization), infer (an inference interface), log_config (a configuration file interface), and test (a unit test interface).

[0043] The target service class can also define non-mandatory interfaces, such as unload_model (an interface for releasing model resource occupation), warm_up (a model warm-up interface), and accelerate (an interface for model acceleration).

[0044] The class implementing the function required by the target service in the target SDK is a prototype class, and the target SDK can have one or more prototype classes. Each prototype class is obtained by inheriting the target service class, that is, each prototype class is a subclass of the target service class.

[0045] For example, when a developer develops an SDK, the target DSL is installed in the development environment, the target service class in the target DSL is imported, a subclass of the target service class is developed, and the target SDK is obtained after the development. Each prototype class in the target SDK is a subclass of the target service class, and can implement the target interface defined in the target service class.

[0046] By inheriting the target service class in the target DSL, a common module that can be reused by different SDKs is implemented, the development time and labor cost of different SDKs are reduced, the external interface standard of a large number of different SDKs is unified, and the quality of SDK service and the efficiency of problem positioning are guaranteed. Because all SDKs inherit the same class, all SDKs can be quickly accessed and the execution order can be controlled on the service side.

[0047] In the technical solution provided in step S204, the server obtains each prototype class in the target SDK through the service framework, and the target interface is implemented through the subclass of the target service class.

[0048] The service framework uses a publish-subscribe mode to obtain the subclass of the target service class in the target SDK, that is, to subscribe to all subclasses of the target service class. Because the classes in the target SDK all inherit the target service class, the service framework can obtain each prototype class in the target SDK, and instantiate each prototype class of the target SDK in the subsequent steps.

[0049] In the technical solution provided in step S206, the server instantiates each prototype class through the service framework, completes the access of the target SDK by the service framework, and obtains the target service.

[0050] After obtaining the SDK instance, the service framework can control whether the instance is executed and the execution order; can subscribe to the changes of the SDK instance at each execution; can also add a linking module between instance executions, and the like, so that the access of the SDK on the service side is more flexible and controllable.

[0051] Through the steps S204 to S206, the service framework side completes the SDK access by using the publish-subscribe design pattern, and the service framework obtains the subclass inheriting the target service class and instantiates, which realizes the decoupling of the SDK development and the service development (i.e. the target SDK is accessed to the service framework, and the target service is obtained), improves the development efficiency because the developers are different teams, and guarantees the controllability of the SDK instance for the service development side.

[0052] As an optional embodiment, the step S204 includes the following steps of obtaining each prototype class in the target SDK by the service framework to the subclass in the target SDK taking the target service class as the base class:

[0053] The step S41 determines the target module in at least one module included in the target SDK, wherein the target module is a module containing the subclass taking the target service class as the base class.

[0054] The step S42 obtains the subclass taking the target service class as the base class from the target module to obtain the prototype class.

[0055] The target SDK can include one or more modules, and the target module can include one or more prototype classes.

[0056] For example, the target DSL is a Python-based embedded DSL, and the target SDK contains one or more Python modules (Module) defining the subclass inheriting the target service class in the target DSL. The Module is a Python file ending with.py and containing Python object definition and Python statement. The Module can define functions, classes and variables, and can also contain executable code.

[0057] The service framework can access the modules in the SDK through the addresses of the modules in the SDK by using the publish-subscribe pattern, obtain the subclass inheriting the target service class from the target module containing the subclass inheriting the target service class, and thus obtain each prototype class in the target SDK.

[0058] As an optional embodiment, the step S206 includes the following steps of instantiating each prototype class by the service framework to complete the access of the target SDK to the service framework, and obtain the target service:

[0059] The step S61 instantiates each prototype class by the service framework to obtain the target instance corresponding to each prototype class.

[0060] The step S62 determines the target execution order according to the priority attribute of each target instance.

[0061] Step S63, the target instances are integrated into the target service according to the target execution order, where the target execution order represents the execution order of all the target instances in the target service.

[0062] In the prototype class, the priority attribute of the target instance corresponding to the prototype class can be defined.

[0063] One prototype class can be instantiated to obtain one or more target instances, and according to the priority attribute of each target instance, the control of the series-parallel connection or the execution order of the target instances in the target service can be realized.

[0064] The integration of the target instances into the target service according to the target execution order can be the combination of the target instances and the code for controlling the execution order of the target instances into the service code, and the output of the target service, that is, the independent service with algorithmic capability. The service code contained in the target service can also include code for realizing other functions.

[0065] Optionally, in this embodiment, after the target instances are integrated into the target service according to the target execution order in step S63, the method further includes the following steps:

[0066] In the case that the target service receives a service request, all the target instances in the target service process the service request according to the target execution order.

[0067] After the target SDK is accessed into the service framework to obtain the target service, the target service can provide services to the outside. The service request can be transmitted into the target service through the external interface of the target service, and the target service can execute the methods of the target instances in sequence according to the target execution order in the case that the service request is received.

[0068] As an optional embodiment, before the target SDK used for service construction is obtained in step S202, the method further includes the following steps:

[0069] Step S31, the target DSL is installed in the development environment of the SDK, and the target service class in the target DSL is imported;

[0070] Step S32, at least one prototype class with the target service class as the base class is created in response to the configuration operation of the target object, where each prototype class in the at least one prototype class is used to realize the target interface;

[0071] Step S33, the target SDK is generated according to the at least one prototype class.

[0072] Before the SDK is developed, the target DSL is installed in the development environment, and the target service class provided by the target DSL is imported, so that the prototype class inherited from the class can be developed, and the development of the SDK is completed.

[0073] The inheritance of the target DSL implementation is unified, so that the common module required by different SDKs is realized, and the development time and labor cost of different SDKs are reduced.

[0074] Optionally, in the embodiment, the step S33 of generating the target SDK according to the at least one prototype class further includes the following steps:

[0075] The step S331 of generating the candidate SDK according to the at least one prototype class;

[0076] The step S332 of testing the candidate SDK by calling the target test interface of the candidate SDK through the delivery system, to obtain a target test result, wherein the target interface includes the target test interface;

[0077] The step S333 of taking the candidate SDK as the target SDK when the target test result indicates that the candidate SDK passes the test.

[0078] Optionally, the delivery system can call the prototype class in the candidate SDK and instantiate the interface, and if all the target interfaces are implemented, the candidate SDK passes the test.

[0079] The SDK is tested through the steps S331 to S333. If the target interface defined in the target service class includes the target test interface, after the development of the SDK is completed, the candidate SDK is obtained, and the candidate SDK can be uploaded to the delivery system. The delivery system calls the target test interface (for example, test, a unit test interface) in the candidate SDK, internally calls all the interfaces that must be implemented (that is, all the interfaces in the target interface except the target test interface), and performs interface testing. If the test passes, the candidate SDK can be used as the target SDK for the service framework to access.

[0080] The condition for passing the test can be that all the target interfaces are implemented, or that all the target interfaces are functional.

[0081] The incoming parameter for performing the interface test can be in-memory data or test data internal / external network link or local address.

[0082] As an optional embodiment, before the step S204 of obtaining each prototype class in the target SDK by taking the target service class in the target DSL as a base class through the service framework, the method can further include the following steps:

[0083] The step S301 of obtaining a basic image, wherein the basic image includes an operating system and basic dependencies;

[0084] Step S302, downloading the target SDK in the base image and installing the dependencies required by the SDK, and obtaining the service framework and installing the dependencies required by the service framework, to obtain a target image;

[0085] Step S303, starting the target image in the form of a container instance as a target container, and performing a jump operation for jumping to step S204 (obtaining, through the service framework, a subclass of a target service class in the target DSL and taking the target service class in the target DSL as a base class, to obtain each prototype class in the target SDK).

[0086] The target image needs to include the target DSL, which can be pre-installed in the base image, or the target DSL can be included in the dependencies required by the service framework, that is, the import of the target DSL is completed in the step of installing the service framework and the dependencies required by the service framework in the base image.

[0087] Through the above steps S301 to S302, a service image is constructed, and through the above step S303, the constructed image is deployed to a resource platform and started in the form of a container instance. When the container is started, the service framework accesses the target SDK through the above steps S204 to S206, the service of the target SDK is completed, and the target service is obtained. After the service framework normally starts the target service, it can receive a service request and implement the function in the target service by executing the method of the instance in the target service.

[0088] The above base image mainly includes an operating system, basic dependencies, etc.

[0089] Downloading the target SDK in the base image and installing the dependencies required by the SDK can be to deliver the download link of the target SDK through a delivery system, and to download the target SDK in the base image and install the dependencies required by the target SDK according to the download link.

[0090] Optionally, in this embodiment, according to the expected input and output after the service of the target SDK (that is, the construction of the service), the pre-processing and post-processing modules integrated in the service framework to be run can be selected. (Pre-processing: such as frame extraction of video input on GPU; post-processing: such as conversion of SDK output data to serializable data type).

[0091] Optionally, in this embodiment, a Dockerfile (Dockerfile is a text file, which contains a series of instructions (Instruction) for constructing an image. Each instruction constructs a layer of image, so the content of each instruction is how to construct the layer of image) can be constructed first, and then the service image is constructed on the basis of the Dockerfile.

[0092] Optionally, in the embodiment, the step S204 can further include the steps S41-S42 in the foregoing embodiment.

[0093] Optionally, in the embodiment, the step S41 can further include the following steps of determining the target module in the at least one module included in the target SDK:

[0094] The step S411 transmits the module address corresponding to each module in the at least one module to a specified interface of the service framework, wherein the module address corresponding to each module is used to indicate the location of each module in the target container.

[0095] The step S412 accesses each module by the service framework according to the module address corresponding to each module, and determines the module containing the subclass of the target service class as the target module.

[0096] The at least one module included in the target SDK can be part or all of the modules in the target SDK, and the at least one module included in the target SDK includes all target modules in the target SDK.

[0097] The module address is not limited in form, for example, it can be the module identifier (such as module name, module number) of each module, or the combination of the resource address of the target SDK and the module identifier of each module, or the resource address of each target module.

[0098] The step S204 can also be implemented by the following method: determining all target modules in the target SDK; transmitting the module address corresponding to each target module to a specified interface of the service framework; accessing each target module by the service framework according to the module address corresponding to each target module, and obtaining the subclass of the target service class in the target module to obtain each prototype class in the target SDK.

[0099] Optionally, in the embodiment, the step S206 can further include the steps S61-S63 in the foregoing embodiment.

[0100] Optionally, in the embodiment, before the step S301, the method further includes the steps S31-S33 and the steps S331-S333 in the foregoing embodiment.

[0101] As an optional embodiment, the technical solution of the present application is described in the following specific embodiments:

[0102] As more and more applications need AI to empower them, the research investment in AI algorithms is increasing. The final form of algorithm landing and monetization is usually to be packaged in a service first, and then called through the external interface of the service, that is, to go through a service packaging process. It is a problem to be solved to quickly evaluate the performance and resource usage of a large number of algorithms in the same field or even different fields in the service environment, the delivery quality of the algorithm prototype, and finally package the algorithm prototype into an engineering-level service in a limited time and human resources.

[0103] The output of the algorithm prototype is usually in the form of SDK, and the following problems affect the efficiency and quality of converting the prototype into a service.

[0104] Problem (1): Large number and variety. Performance: There is no unified interface standard between different SDKs; the repeated implementation of the same function part of different SDKs increases the cost of manpower and time. Reason: Algorithm researchers are many, code habits and quality are different; the number of algorithm SDKs is large; algorithms involve many fields.

[0105] Problem (2): Difficult to intervene. Performance: Except for the interfaces provided by the SDK, no interaction can be completed. Reason: The interface quality or quantity cannot meet the engineering needs, and the SDK source code is mostly in an unreadable form.

[0106] Problem (3): Difficult to manage. Performance: High positioning cost and low service efficiency. Reason: Lack of necessary information needed for service; lack of modules or interfaces that SDKs should provide; conflict caused by different configurations of the same module inside and outside the SDK.

[0107] The embodiment provides a service construction scheme. On the one hand, the scheme provides an Embedded Domain Specific Language (DSL) module based on python on the algorithm SDK research and development side. It is used as a dependency for SDK research and development in different algorithm fields. Algorithm researchers only need to install the DSL module when developing a prototype class, import the service class in the DSL module as a parent class, implement the interfaces or override the abstract methods that need to be implemented in the parent class, and then output the SDK that can access the service framework, so as to ensure that a large number of different SDKs can quickly access the service framework according to a unified standard. On the other hand, the service framework is provided on the service packaging side. Finally, the address of the SDK prototype class is transmitted into the interface reserved by the service framework by using an automatic packaging script, so that the service framework can obtain all subclasses that inherit the DSL service class and instantiate them through the subscription mode, control the series and parallel connection or execution order of the SDK according to the priority attribute of each instance, and then combine the two into a service code, so as to output an independent service with the algorithm capability.

[0108] As Figure 3As shown, it is an overall flow schematic diagram of an optional service construction scheme according to an embodiment of the present application.

[0109] The overall idea of the present scheme is outlined as follows:

[0110] (1) Gaia is the above-mentioned DSL module (i.e. the target DSL in the present application), which is stored in a private library in the form of a wheel package, and is used to unify the external interface standard on the SDK side. Before developing the SDK, the algorithm researcher installs the module in the development environment, imports the base class SdkBase (i.e. the target service class in the present application) provided by Gaia, and can develop a prototype class inherited from the class; after the development is completed, the SDK (i.e. the candidate SDK in the present application) is uploaded to the algorithm delivery system, and the delivery system will call the test interface to perform interface testing, and if it passes, it can be obtained by the automatic packaging script.

[0111] (2) Atlas is the service framework (i.e. the service framework in the present application), which is also stored in a private library in the form of a wheel package. It has all the functional modules required for service in its internal, wherein, when the execution unit (process / thread) is started, the SDK address is transmitted according to the automatic script, the corresponding module is dynamically loaded, and all subclass objects inherited from the SdkBase class are obtained in the loaded module, and are instantiated and sorted according to the priority attribute of the instance. In this way, it can be ensured that after receiving the request, all AI capabilities can be enabled according to the predetermined priority order.

[0112] (3) The automatic script installs Gaia and Atlas in the basic image, downloads the SDK (i.e. the target SDK in the present application), encapsulates it into a new image (i.e. the target image in the present application), and automatically deploys it on the resource platform, starts (i.e. the target image in the present application is started as a target container in the form of a container instance), and completes the automatic service of AI capabilities.

[0113] The specific steps of the present scheme are as follows:

[0114] Step 1: The algorithm researcher installs the Gaia wheel and imports the SdkBase class. Since the DSL module is a python-based Embedded DSL, it can be conveniently stored in a private library in the form of a Gaia wheel, and downloaded and installed by pip tool in the form of a specified private library link. The Gaia or the base class can be imported in any developed python environment.

[0115] Step two: Algorithm researchers develop subclasses that inherit from the SdkBase class. SdkBase has abstract interfaces that must be implemented by subclasses (if not implemented, the coding tool will prompt and fail the interface test), and general methods or interfaces that can be inherited or overridden.

[0116] The interfaces that must be implemented by subclasses in Gaia are as follows:

[0117] (1) load_model: Different AI framework libraries (such as pytorch, tensorflow, etc.) have been implemented in Gaia, and SDK developers only need to implement the method of passing in the model location, which can be a download link or a local address.

[0118] (2) init_model: Model initialization methods based on different AI framework libraries (such as pytorch, tensorflow, etc.) have been implemented in Gaia, and SDK developers only need to configure whether there are additional requirements for starting, such as multi-threading / processing; if it is multi-processing, the starting method of the process; initialization as blocking or non-blocking, etc.

[0119] (3) infer: Inference interface, the main module implemented by researchers.

[0120] (4) log_config: Developers only have the implementation authority to configure log levels, streams / files, and whether to be collected by the log system.

[0121] (5) test: Unit test interface, which will be called by the SDK delivery system. Its internal will call all the above must be implemented interfaces, and the developer needs to configure the test data, which can be in-memory data type or test data provided by internal / external network link or local address.

[0122] Non-mandatory interfaces are:

[0123] (6) unload_model: Release model resource occupation. When the model is large or there are multiple models, you can choose this interface or override it to implement special requirements.

[0124] (7) warm_up: For the first run of the prototype SDK with poor performance, you can call or override this interface, which generally only needs to configure warm-up data.

[0125] (8) accelerate: Gaia has implemented the interface of converting models using OpenVINO and TensorRT, which can be selected according to actual needs.

[0126] Step three: link the developed SDK into the delivery system, which will call its test interface to test the interface and function. If it passes, it can be automatically packaged by the subsequent script.

[0127] Step four: build the service image. The automatic script will first build the Dockerfile, and then build the service image based on it. The specific process is as follows:

[0128] 1. Pull the base image from the private library, which mainly contains the operating system and basic dependencies.

[0129] 2. Download the delivered SDK and install its required dependencies in the base image.

[0130] 3. Install Atlas and its required dependencies.

[0131] 4. According to the expected input and output of the service, select the pre-processing and post-processing modules integrated in Atlas to run. (Pre-processing such as video input frame extraction on GPU, post-processing such as conversion of SDK output data to serializable data type, etc.)

[0132] Step five: image deployment and container startup. The automatic packaging script will pass the above built image into the image library and trigger deployment, deploy the image to the resource platform and start it in the form of a container instance. When the container starts, Atlas will start its execution unit (single / multi-thread / process) before building the server, and according to the SDK address passed in, it will be dynamically imported as a module. Then get all the subclass objects of SdkBase, instantiate each subclass object and put it into the container object, and rearrange the order of instances in the instance container according to the priority attribute of the instantiated object. After the Atlas server is started normally, it can receive requests and execute the infer method of each instance in the order mentioned above.

[0133] The following beneficial effects can be achieved by the scheme: (1) a unified inherited module is implemented by using a python-based Embedded DSL: the module is easy to install and use, and the python-based implementation also makes it easy for researchers to understand and accept; common modules required by different SDKs are implemented, reducing the time and labor cost of developing different SDKs. The external interface standard of a large number of different SDKs is unified, ensuring the quality of SDK service and the efficiency of problem positioning. Because the same class is inherited by the SDK, different SDKs can be quickly accessed and the execution order can be controlled on the service side; class-level inheritance ensures that researchers have enough flexible space to implement specific functions. (2) The service framework side uses dynamic loading modules, the idea of inversion of control and the publish-subscribe design pattern to complete SDK access: dynamic loading modules ensure that the implementation mechanism of the SDK itself (such as thread / process configuration) is not affected by the implementation mechanism in the service framework, which ensures that the SDK can be quickly and seamlessly connected. By using the idea of inversion of control, all SDK instances can be obtained and their attributes can be controlled through the interfaces defined in the DSL module in the service framework. This not only decouples the development of the SDK and the development of the service (because the developers are different teams, the development efficiency can be improved), but also ensures the controllability of the SDK instances on the service development side. Through the passive publishing and active subscribing mode, the service framework side can control whether the instance is executed and the execution order after obtaining the SDK instance container; it can subscribe to changes in the SDK instance at each execution; it can also add a linking module between instance executions, etc. This makes the SDK access on the service side more flexible and controllable.

[0134] The embodiment can be applied in the actual production process of intelligent content production, review and distribution including but not limited to intelligent advertising, and used as a way of SDK service in the landing and monetization of artificial intelligence algorithms. The service construction scheme can ensure the efficiency and quality of SDK service, saving a lot of manpower and time cost.

[0135] It should be noted that, for each of the above method embodiments, in order to simply describe, it is expressed as a combination of a series of actions, but those skilled in the art should know that the present application is not limited by the order of the described actions, because according to the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0136] Those skilled in the art can clearly understand that the method according to the above-mentioned embodiments can be realized by means of software on a general hardware platform as necessary, and of course, can also be realized by hardware, but in many cases, the former is a better implementation. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk) and includes a plurality of instructions for causing a terminal device (which can be a mobile phone, a computer, a server, or a network device) to execute the methods described in the various embodiments of the present application.

[0137] According to another aspect of the embodiments of the present application, a service construction apparatus for implementing the above-mentioned service construction method is also provided. Figure 4 is a schematic diagram of an optional service construction apparatus according to an embodiment of the present application, as shown in Figure 4 , the apparatus can include:

[0138] A first obtaining module 22 is configured to obtain a target SDK for service construction, wherein the target SDK is an SDK to be accessed to a service framework, a prototype class in the target SDK is a subclass with a target service class in a target DSL as a base class, and the target service class defines a target interface;

[0139] A second obtaining module 24 is configured to obtain, by the service framework, a subclass with the target service class as a base class in the target SDK to obtain each prototype class in the target SDK, wherein the target interface is implemented by the subclass with the target service class as a base class;

[0140] A service generating module 26 is configured to instantiate each prototype class by the service framework to complete the access of the target SDK to the service framework and obtain a target service.

[0141] It should be noted that the first obtaining module 22 in this embodiment can be configured to perform step S202 in the embodiments of the present application, the second obtaining module 24 in this embodiment can be configured to perform step S204 in the embodiments of the present application, and the service generating module 26 in this embodiment can be configured to perform step S206 in the embodiments of the present application.

[0142] It should be noted that the above-mentioned modules have the same examples and application scenarios as the corresponding steps, but are not limited to the content disclosed in the above-mentioned embodiments. It should be noted that the above-mentioned modules as part of the apparatus can run in a hardware environment as shown in Figure 1 , and can be realized by software or hardware.

[0143] Through the above-mentioned modules, the technical problem of low efficiency in converting an algorithm prototype into a service in the related art can be solved.

[0144] As an optional embodiment, the second obtaining module 24 comprises: a first determining unit, configured to determine a target module from at least one module included in the target SDK, wherein the target module is a module containing a subclass of the target service class; and a subclass obtaining unit, configured to obtain the subclass of the target service class from the target module, to obtain the prototype class.

[0145] As an optional embodiment, the service generating module 26 comprises: an instantiating unit, configured to instantiate each prototype class through the service framework, to obtain a target instance corresponding to each prototype class; a second determining unit, configured to determine a target execution order according to the priority attribute of each target instance; and a synthesizing unit, configured to synthesize the target instances into the target service according to the target execution order, wherein the target execution order indicates the execution order of all target instances in the target service.

[0146] Optionally, after the target instances are synthesized into the target service according to the target execution order, in the case that the target service receives a service request, all target instances in the target service process the service request according to the target execution order.

[0147] As an optional embodiment, the apparatus can further comprise a developing unit, configured to: install the target DSL in a development environment of the SDK, and import the target service class in the target DSL; create at least one prototype class of the target service class in response to a configuration operation of the target object, wherein each prototype class in the at least one prototype class is used to implement the target interface; and generate the target SDK according to the at least one prototype class.

[0148] Optionally, the developing unit is further configured to: generate a candidate SDK according to the at least one prototype class; test the candidate SDK by calling a target test interface of the candidate SDK through a delivery system, to obtain a target test result, wherein the target interface comprises the target test interface; and in the case that the target test result indicates that the candidate SDK passes the test, take the candidate SDK as the target SDK.

[0149] As an optional embodiment, the apparatus can further comprise a mirror image building unit, configured to: obtain a basic mirror image, wherein the basic mirror image comprises an operating system and basic dependencies; download the target SDK in the basic mirror image and install dependencies required by the SDK, and obtain a service framework and install dependencies required by the service framework, to obtain a target mirror image.

[0150] Optionally, the apparatus can further comprise a mirror image deploying unit, configured to: start the target mirror image as a target container in the form of a container instance, and perform a jump operation for jumping to a step of obtaining, through the service framework, a subclass of the target service class in the target DSL, to obtain each prototype class in the target SDK.

[0151] Optionally, the target container can include the second acquisition module 24 and the service generation module 26 in the device.

[0152] Optionally, the first determination unit is further configured to: transmit the module address corresponding to each of the at least one module to a designated interface of the service framework, where the module address corresponding to each of the at least one module is used to indicate the location of each of the at least one module in the target container; and access each of the at least one module according to the module address corresponding to each of the at least one module by the service framework, and determine the module containing the subclass of the target service class as the target module.

[0153] It should be noted that the above modules and the corresponding steps achieve the same examples and application scenarios as the above embodiments, but are not limited to the contents disclosed in the above embodiments. It should be noted that the above modules as part of the device can run in the hardware environment as shown in Figure 1 The hardware environment includes a network environment.

[0154] According to another aspect of the embodiments of the present application, an electronic device is further provided for implementing the above service construction method, which comprises: Figure 5 As shown in the figure, the electronic device can include a processor 1501, a communication interface 1502, a memory 1503, and a communication bus 1504, wherein the processor 1501, the communication interface 1502, and the memory 1503 complete mutual communication through the communication bus 1504.

[0155] The memory 1503 is used to store computer programs.

[0156] The processor 1501 is used to execute the programs stored in the memory 1503, and implement the steps of the above method embodiments.

[0157] The bus mentioned in the above electronic device can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, only one thick line is shown in the figure, but it does not mean that there is only one bus or only one type of bus.

[0158] The communication interface is used for communication between the above electronic device and other devices.

[0159] The memory can include a random access memory (RAM) and can also include a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory can also be at least one storage device located away from the aforementioned processor.

[0160] The processor described above can be a general processor, including a central processing unit (CPU), a network processor (NP), etc.; can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0161] Those of ordinary skill in the art can understand that, Figure 5 The structure shown is only schematic and does not limit the structure of the electronic device described above. For example, the electronic device can also include more or fewer components (such as a network interface, a display device, etc.) than those shown in the figure, or have a different configuration from that shown in the figure. Figure 5 The structure shown is only schematic and does not limit the structure of the electronic device described above. For example, the electronic device can also include more or fewer components (such as a network interface, a display device, etc.) than those shown in the figure, or have a different configuration from that shown in the figure. Figure 5 The structure shown is only schematic and does not limit the structure of the electronic device described above. For example, the electronic device can also include more or fewer components (such as a network interface, a display device, etc.) than those shown in the figure, or have a different configuration from that shown in the figure.

[0162] The embodiment of the present application also provides a computer readable storage medium, the storage medium includes a stored program, wherein the program runs to execute the method steps of the method embodiment described above.

[0163] Optionally, in the embodiment, the storage medium described above can include but is not limited to: a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0164] By adopting the embodiment of the application, a service construction scheme is provided. By adopting a subscription mode in the service framework, a subclass of a target service class is dynamically obtained, so that a prototype class in a target SDK is obtained, and the prototype class is instantiated to access the target SDK to the service framework to obtain a target service, so that the purpose of automatically converting an algorithm prototype into a service is achieved. Since the target service class in the target DSL defines a target interface, and the target SDK is inherited from the target service class and has a unified interface standard, the service framework can be quickly accessed, the labor cost and time cost of accessing the SDK to the service framework are reduced, and thus the technical problem of low efficiency of converting an algorithm prototype into a service in the related art is solved.

[0165] Optionally, specific examples in the embodiment can refer to the examples described in the above embodiments, and the embodiment will not be described here again.

[0166] It should be noted that, in this document, relational terms such as "first" and "second", and the like, are used solely to distinguish one entity or action from another entity or action, without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without more limitations, an element defined by the phrase "comprising a... " does not exclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0167] The serial numbers of the above embodiments of the application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0168] When the integrated units in the above embodiments are realized in the form of software function units and sold or used as independent products, the software function units can be stored in the above computer-readable storage medium. Based on such understanding, the technical solutions of the application essentially or the parts that make contributions to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a plurality of instructions for causing one or more computer devices (which can be personal computers, servers or network devices, etc.) to execute all or part of the steps of the methods described in the embodiments of the application.

[0169] In the above embodiments of the application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0170] In several embodiments provided in the present application, it should be understood that the disclosed client can be implemented in other manners. Of course, the described apparatus embodiments are merely schematic, and the division of units is merely logical function division, and there can be other division manners in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, units or modules, and can be in electrical, mechanical or other forms.

[0171] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0172] In addition, each functional unit in the various embodiments of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0173] The above is only the preferred embodiment of the present application, and it should be pointed out that for ordinary skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, and these improvements and refinements should be considered as the protection scope of the present application.

Claims

1. A service construction method characterized by comprising: The method comprises the following steps: acquiring a target SDK for service construction, wherein the target SDK is an SDK to be accessed to a service framework, a prototype class in the target SDK is a subclass of a target service class in a target DSL, and the target service class defines a target interface; acquiring, by the service framework, a subclass of the target service class in the target SDK to obtain each prototype class in the target SDK, wherein the target interface is implemented by the subclass of the target service class; instantiating, by the service framework, the each prototype class to complete access of the target SDK to the service framework, and obtaining a target service. Before the step of acquiring the target SDK for service construction, the method further comprises the following steps: installing the target DSL in a development environment of an SDK, and importing a target service class in the target DSL; in response to a configuration operation of a target object, creating at least one prototype class of the target service class, wherein each prototype class in the at least one prototype class is used to implement the target interface; and generating the target SDK according to the at least one prototype class.

2. The method of claim 1, wherein, The step of acquiring, by the service framework, the subclass of the target service class in the target SDK to obtain the each prototype class in the target SDK comprises the following steps: determining a target module in at least one module included in the target SDK, wherein the target module is a module containing the subclass of the target service class; acquiring the subclass of the target service class from the target module to obtain a prototype class.

3. The method of claim 1, wherein, The step of instantiating, by the service framework, the each prototype class to complete access of the target SDK to the service framework, and obtaining a target service comprises the following steps: instantiating, by the service framework, the each prototype class to obtain a target instance corresponding to the each prototype class; determining a target execution order according to a priority attribute of each target instance; integrating the target instances into a target service according to the target execution order, wherein the target execution order represents an execution order of all target instances in the target service.

4. The method of claim 1, wherein, The step of generating the target SDK according to the at least one prototype class comprises the following steps: generating a candidate SDK according to the at least one prototype class; testing the candidate SDK by calling a target test interface of the candidate SDK through a delivery system to obtain a target test result, wherein the target interface includes the target test interface; in a case where the target test result indicates that the candidate SDK passes the test, taking the candidate SDK as the target SDK.

5. The method according to any one of claims 1 to 4, characterized in that, The method further comprises the following steps: acquiring a base image, wherein the base image includes an operating system and basic dependencies; downloading the target SDK and installing SDK required dependencies in the base image, and acquiring the service framework and installing service framework required dependencies to obtain a target image. The target image is started in a container instance form as a target container, and a jump operation of each prototype class in the target SDK is obtained through a service framework by jumping to a subclass of the target service class in the target SDK.

6. The method of claim 5, wherein, The obtaining of the subclass of the target service class in the target SDK through the service framework to obtain each prototype class in the target SDK includes: In at least one module included in the target SDK, a target module is determined, including: transmitting a module address corresponding to each module in the at least one module into a specified interface of the service framework, wherein the module address corresponding to each module is used to indicate a position of each module in the target container; and accessing each module through the service framework according to the module address corresponding to each module, and determining a module containing a subclass of the target service class as the target module. The subclass of the target service class in the target module is obtained to obtain a prototype class.

7. A service construction apparatus characterized by comprising: Including: The first obtaining module is configured to obtain a target SDK used for service construction, wherein the target SDK is an SDK to be accessed into a service framework, a prototype class in the target SDK is a subclass of a target service class in a target DSL, and the target service class defines a target interface; The second obtaining module is configured to obtain the subclass of the target service class in the target SDK through the service framework to obtain each prototype class in the target SDK, wherein the target interface is implemented through the subclass of the target service class; The service generation module instantiates each prototype class through the service framework, completes access of the service framework to the target SDK, and obtains a target service. The apparatus further includes a development unit configured to install the target DSL in a development environment of an SDK and import a target service class in the target DSL before the target SDK used for service construction is obtained; in response to a configuration operation of a target object, create at least one prototype class of the target service class, wherein each prototype class in the at least one prototype class is used to implement the target interface; and generate the target SDK according to the at least one prototype class.

8. An electronic device, comprising: Including: A processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete communication with each other through the communication bus; The memory is configured to store a computer program; The processor is configured to execute the computer program to implement the method in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The storage medium includes a stored program, wherein the program runs to execute the method in any one of claims 1 to 6. The storage medium includes a stored program, wherein the program runs to execute the method in any one of claims 1 to 6.

Images