CN113760308A

CN113760308A - DSP system construction method and device, electronic equipment and storage medium

Info

Publication number: CN113760308A
Application number: CN202110163819.XA
Authority: CN
Inventors: 蒋松芳; 孟然
Original assignee: Beijing Wodong Tianjun Information Technology Co Ltd
Current assignee: Beijing Wodong Tianjun Information Technology Co Ltd
Priority date: 2021-02-05
Filing date: 2021-02-05
Publication date: 2021-12-07

Abstract

The embodiment of the invention discloses a method and a device for constructing a DSP system, electronic equipment and a storage medium. The method comprises the following steps: when a system building instruction is received, a description file corresponding to a DSP system to be built is obtained, mirror image address information and application programming interface API description information corresponding to each service component contained in the DSP system to be built are read through analysis of the description file, the mirror image file is further determined, each service component is started to operate based on each mirror image file, the API description information of each service component is registered in a preset gateway module, so that the preset gateway module determines a corresponding target service component when receiving a service request, and the service request is forwarded to the target service component. The method realizes that the deployment of the DSP system can be automatically completed based on the description file, and the description file can be configured according to the actual requirement of the user, thereby realizing the construction of the customized DSP based on the actual requirement of the user.

Description

DSP system construction method and device, electronic equipment and storage medium

Technical Field

The embodiment of the invention relates to the technical field of computers, in particular to a method and a device for constructing a DSP system, electronic equipment and a storage medium.

Background

DSP (Demand-Side Platform) is a Demand Side Platform, and advertisers can easily and conveniently buy and sell online advertisements located on a plurality of advertisement trading platforms through the DSP.

At present, DSPs used by advertisers have a unified function, and as the advertising business scales of part of head advertisers and agents increase, they accumulate a large amount of private area client data, and have a demand for more accurate targeted delivery to improve ROI (Return on Investment), thereby creating a demand for customizing functions of a DSP platform, for example, DSPs used by advertisers have a universal unified function, whereas advertiser a needs to customize DSPs having one thousand functions among the ten thousand functions, and advertiser B needs to customize DSPs having another thousand functions.

In the process of implementing the invention, at least the following problems are found in the prior art:

how to construct a customized DSP according to the user requirements is a problem to be solved at present.

Disclosure of Invention

The embodiment of the invention provides a method and a device for constructing a DSP system, electronic equipment and a storage medium, so as to realize the construction of a customized DSP according to the actual requirements of a user.

In a first aspect, an embodiment of the present invention provides a method for constructing a DSP system, including:

when a system construction instruction is received, obtaining a description file corresponding to a DSP system to be constructed;

analyzing the description file, and reading mirror image address information and Application Programming Interface (API) description information which respectively correspond to each service component contained in the DSP system to be constructed from an analysis result;

acquiring mirror image files corresponding to the service components respectively according to the mirror image address information, and starting and operating the service components based on the mirror image files;

registering the API description information of each service component into a preset gateway module, so that the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request, and forwards the service request to the target service component.

In a second aspect, an embodiment of the present invention further provides a device for constructing a DSP system, including:

the file acquisition module is used for acquiring a description file corresponding to the DSP system to be constructed when a system construction instruction is received;

the file analysis module is used for analyzing the description file and reading mirror image address information and Application Programming Interface (API) description information which respectively correspond to each service component contained in the DSP system to be constructed from an analysis result;

the component starting module is used for acquiring the mirror image files corresponding to the service components according to the mirror image address information and starting and operating the service components based on the mirror image files;

and the API registration module is used for registering the API description information of each service component into a preset gateway module so that the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request and forwards the service request to the target service component.

In a third aspect, an embodiment of the present invention further provides an electronic device, where the electronic device includes:

one or more processors;

a storage device for storing one or more programs,

when the one or more programs are executed by the one or more processors, the one or more processors implement the method for constructing the DSP system as provided by any of the embodiments of the invention.

In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the method for constructing a DSP system according to any embodiment of the present invention.

The embodiment of the invention has the following advantages or beneficial effects:

when a system building instruction is received, a description file corresponding to a DSP system to be built is obtained, the description file is analyzed, mirror image address information and Application Programming Interface (API) description information which correspond to all service components contained in the DSP system to be built are read from an analysis result, mirror image files corresponding to all the service components are obtained according to all the mirror image address information, and all the service components are started to operate on the basis of all the mirror image files. And registering the API description information of each service component in a preset gateway module so that the preset gateway module determines a corresponding target service component when receiving a service request and forwards the service request to the target service component. The scheme realizes that the deployment of the DSP system can be automatically completed based on the description file, thereby greatly reducing the customization cost of the DSP system. In addition, the description file corresponding to the DSP system to be built can be configured according to the actual requirements of the user, so that the customized DSP can be built based on the actual requirements of the user.

Drawings

In order to more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, a brief description is given below of the drawings used in describing the embodiments. It should be clear that the described figures are only views of some of the embodiments of the invention to be described, not all, and that for a person skilled in the art, other figures can be derived from these figures without inventive effort.

Fig. 1A is a schematic flowchart of a method for constructing a DSP system of a demand side platform according to a first embodiment of the present invention;

fig. 1B is a schematic diagram of a preset gateway module invoking service component according to an embodiment of the present invention;

fig. 2 is a schematic flow chart of a method for constructing a DSP system of a demand side platform according to a second embodiment of the present invention;

fig. 3 is a schematic flowchart of a method for constructing a DSP system of a demand side platform according to a third embodiment of the present invention;

fig. 4A is a schematic flowchart of a method for constructing a DSP system of a demand side platform according to a fourth embodiment of the present invention;

fig. 4B is a schematic structural diagram of a delivery engine according to a fourth embodiment of the present invention;

fig. 5A is a schematic flowchart of a method for constructing a DSP system of a demand side platform according to a fifth embodiment of the present invention;

fig. 5B is a schematic diagram of a DSP system according to a fifth embodiment of the present invention;

fig. 6 is a schematic structural diagram of a device for constructing a DSP system of a demand side platform according to a sixth embodiment of the present invention;

fig. 7 is a schematic structural diagram of an electronic device according to a seventh embodiment of the present invention.

Detailed Description

The present invention will be described in further detail with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be further noted that, for the convenience of description, only some of the structures related to the present invention are shown in the drawings, not all of the structures.

Example one

Fig. 1A is a schematic flowchart of a method for constructing a demand side platform DSP system according to an embodiment of the present invention, which is applicable to a case where a DSP system is constructed according to actual requirements of a user, and is particularly applicable to a case where service components included in a DSP system are started and run according to a description file corresponding to the DSP system, and API description information of each service component is registered. The method can be executed by a construction device of a DSP system of a demand side platform, and the device can be realized by hardware and/or software, and the method specifically comprises the following steps:

and S110, acquiring a description file corresponding to the DSP system to be constructed when the system construction instruction is received.

The system construction instruction is used for constructing the DSP system to be constructed. The system build instructions may be generated based on a user performing an operation. For example, the system build instructions are generated upon detecting that a user has triggered a corresponding control that confirms the building of the system. Alternatively, the system construction instructions may also be sent by the management side. The management terminal can be understood as a server terminal with functions of issuing system construction instructions, description files and the like.

In this embodiment, the description file may be used to describe element information of each service component included in the DSP system to be built. The description file is generated based on the actual requirement of the user in a pre-configuration mode. Illustratively, the advertiser a needs to customize a DSP system having one thousand functions out of ten thousand functions, and based on the one thousand functions required by the advertiser a, 1000 service components corresponding to the one thousand functions are predetermined, and element information of the 1000 service components is described, so as to generate a description file including 1000 element information as a description file corresponding to the DSP system to be constructed. That is, according to the actual requirement of the user on the service function, the element information of each service component of the DSP system to be constructed is described, so that each service component can be combined to construct a complete DSP system. And element information of each service assembly is described, so that service functions are customized as required, and personalized customization of the DSP system is realized.

In one embodiment, the descriptive file may be a yaml document. Optionally, the description file may also be used to describe the composition and internal relationship of the whole DSP system to be constructed. For example, macro information describing applications, modules, business components, and version authorizations.

Optionally, the pre-configured description file may be stored in a database of the management end, and when receiving a system construction instruction, send a request to the management end to obtain the description file corresponding to the DSP system to be constructed; or the management terminal sends the system construction instruction to the client terminal and simultaneously sends the description file corresponding to the DSP system to be constructed to the client terminal.

And S120, analyzing the description file, and reading mirror image address information and Application Programming Interface (API) description information respectively corresponding to each service component contained in the DSP system to be constructed from the analysis result.

In this embodiment, since the description file contains descriptions of the element information of each business component, the description of the element information in the description file can be acquired based on the analysis result by analyzing the description file. In one embodiment, the description file may be parsed into component models Ada-model corresponding to each service component, that is, each component model is taken as a parsing result. The component model includes definitions of each element information of the business component.

In one embodiment, the element information of the business component includes, but is not limited to, a mirror address and an Application Programming Interface (API), and the result of the parsing of the component model includes, but is not limited to, definitions of mirror address information and API description information. The mirror image address information may be address information for storing a mirror image file corresponding to the service component. Optionally, the image file corresponding to each service component may be placed in an image warehouse of the management end; correspondingly, the mirror image address information is the specific address information of the corresponding mirror image file stored in the mirror image warehouse.

The API description information of the business component is used for describing each API contained in the business component. Each API contained in the service component has the function of processing the corresponding service request. Illustratively, API-a of a certain service component is used to process a service request for uploading a file, and API-B is used to process a service request for deleting an uploaded file, then API description information of the service component includes description information of service services of API-a and API-B. It should be noted that the API description information may also be used to specify the component functions of the service component, and a user may modify the API description information of the service component to implement secondary development or function customization of the functions of the service component.

S130, acquiring mirror image files corresponding to the service components according to the mirror image address information, and starting and operating the service components based on the mirror image files.

The image file includes, but is not limited to, component code that the business component relies on to start the runtime. Illustratively, a developer of a service component can compile a component code of the service component compiled by the developer into a docker mirror image, place the docker mirror image into a mirror image warehouse of a management end, and obtain the docker mirror image according to mirror image address information of the docker mirror image in the mirror image warehouse.

Specifically, after the image file corresponding to each service component is obtained, based on the component code of the service component included in each image file, each service component may be started to operate. In this embodiment, the purpose of obtaining the image files corresponding to the service components is to enable the developed service components to be directly called in the process of constructing the DSP to be constructed without concerning the component codes of the service components.

S140, registering the API description information of each service component in the preset gateway module, so that the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request, and forwards the service request to the target service component.

The target business component may be a business component that provides a business service corresponding to the business request. In this embodiment, when the API description information of each service component is registered in the preset gateway module, the preset gateway module may discover the service of each API through the registered information, so as to determine the service corresponding to each service component. When the preset gateway module receives the service request, the target service component can be determined from the service components according to the service corresponding to the received service request and the known service services correspondingly provided by the service components. After the preset gateway module forwards the service request to the target service component, the target service component may process the service request by calling an API that provides a service corresponding to the service request.

Illustratively, business component 1 includes API-A and API-B, and business component 2 includes API-C. API description information of API-A, API-B, API-C is respectively registered in a preset gateway module, service services corresponding to API-A, API-B and API-C are respectively an upload file, a delete file and a download file, when the preset gateway module receives a service request for deleting files, the service request is forwarded to a service component 1, and the service component 1 can process the service request by calling API-B.

It should be noted that the preset gateway module may receive a service request sent by an internal component, an external component, or an external system. In other words, the mode of registering the API description information of each service component to the preset gateway module so that the preset gateway module forwards the service request to the corresponding target service component, and the target service component calls the corresponding API to process the service request can support the calling of the registered API by the internal component and the external component, and simultaneously support the calling of the registered API by the external system, thereby flexibly implementing the customization and development of the service.

For example, as shown in fig. 1B, the API Gateway in fig. 1B is a preset Gateway module, and component API description information (i.e., API service in the figure) is registered in the API Gateway in advance; the API Gateway knows the service corresponding to each registered component API, and when the API Gateway receives a service request sent by a front-end component, an external component or an external system, the API Gateway can forward the service request to a target service component and call the corresponding component API to process the service request based on the known service corresponding to each service component.

The aim of calling the service component through the preset gateway module is as follows: the mutual calling between the service components can also be realized through the preset gateway module, so that the interaction of internal data and external data is realized, and meanwhile, the interaction of the internal data is also realized.

Optionally, the API description information includes a corresponding relationship between an API name included in the corresponding service component and a uniform resource locator URL address; the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request, and forwards the service request to the target service component, and the preset gateway module comprises the following steps: when receiving a service request, the preset gateway module determines an API corresponding to a URL address contained in the service request as a target API according to the corresponding relation, or determines a default API pre-configured for a domain name as a target API according to the domain name contained in the service request; and determining the service component where the target API is positioned as a target service component, and forwarding the service request to the target service component.

In one embodiment, the correspondence between the Uniform Resource Locator (URL) address and the API name is configured in advance in the API description information of the description file. Illustratively, the URL address is http://. x. com/File/Download/554182A, and the corresponding API name is a Download File API. Note that the same API name may correspond to a plurality of URL addresses. Specifically, the preset gateway module may determine a target API corresponding to the URL address of the received service request based on a correspondence between the API name and the URL address, and determine a service component in which the target API is located as the target service component.

Consider that there are situations where a received service request does not carry a URL address, for example, the service request contains a domain name but no URL address (e.g., the service request displays the system home page of the DSP system for the request). At this time, the corresponding target API cannot be determined according to the URL address of the service request. Therefore, in another embodiment, a corresponding default API may be pre-configured for each domain name. When a service request is received, a corresponding target API is determined according to a domain name carried in the service request, and a service component where the target API is located is determined as the target service component, so that the phenomenon that the API corresponding to the service request which does not carry the URL address cannot be determined is avoided.

In these optional embodiments, the correspondence between the API name included in the service component and the URL address is configured in the API description information, so that the preset gateway module determines the target API based on the URL address or the domain name of the service request, thereby determining the target service component, achieving accurate determination of the target service component, and further ensuring accurate processing of the service request.

According to the technical scheme of the embodiment, when a system building instruction is received, a description file corresponding to a DSP system to be built is obtained, the description file is analyzed, mirror image address information and application programming interface API description information which correspond to each service component and are contained in the DSP system to be built are read from an analysis result, the mirror image file corresponding to each service component is obtained according to each mirror image address information, each service component is started and operated based on each mirror image file, the API description information of each service component is registered in a preset gateway module, so that the preset gateway module determines a corresponding target service component when receiving a service request, and the service request is forwarded to the target service component. The scheme realizes that the deployment of the DSP system can be automatically completed based on the description file, thereby greatly reducing the customization cost of the DSP system. In addition, the description file corresponding to the DSP system to be built can be configured according to the actual requirements of the user, so that the customized DSP can be built based on the actual requirements of the user.

It should be noted that the present embodiment may also provide a delivery engine, and the delivery engine may construct the DSP system by executing the above method steps. The delivery engine can be used by a user (an advertiser), and the management end issues the description file to the delivery engine of the user so that the delivery engine can automatically complete the construction of the DSP system customized by the user by analyzing the description file, thereby realizing the one-key delivery of the DSP system.

Specifically, the delivery engine may communicate with the management end, and when receiving a system building instruction generated based on a user trigger operation, apply for obtaining a description file corresponding to the DSP system to be built from the management end, parse the description file, read image address information and application programming interface API description information corresponding to each service component included in the DSP system to be built from a parsing result Ada-model, obtain an image file corresponding to each service component according to the image address information, start running each service component based on each image file, and register the API description information of each service component in the preset gateway module. Namely, the delivery engine can automatically complete the construction of the whole DSP system according to the description file provided by the management end.

The delivery engine is provided for the purpose of: the description file can be configured according to the actual requirement of a user, and the user can acquire the description file through the delivery engine, so that the delivery engine can complete the deployment and installation of the whole DSP only according to one description file, thereby realizing one-key delivery of the DSP, effectively reducing the delivery cost, facilitating the realization of the automatic customization and release of a complex DSP system with a large scale, and further improving the customization speed of the DSP system.

Alternatively, the delivery engine may be divided into three layers: an Application Model (Application Model) layer, a Cloud Runtime (Cloud Runtime) layer, and a Cloud API (Cloud API) layer. Specifically, the Application Model layer is used for scanning and analyzing the description file, and starting and operating each service component according to the description file; the Cloud Runtime layer is used for receiving various control instructions issued by the Cloud API layer, such as a system construction instruction, and executing corresponding operations according to the received control instructions; the CloudAPI layer is used for receiving various external control instructions, storing the control instructions and issuing the control instructions to the Cloud Runtime layer. The number of structural layers of the delivery engine may be three, four, or the like, and the specific structural layers are not limited in the present application and may be divided according to actual needs.

Example two

Fig. 2 is a schematic flow chart of a method for constructing a demand side platform DSP system according to a second embodiment of the present invention, where this embodiment optionally starts and runs each service component based on each image file on the basis of each of the above embodiments, where the method includes: reading resource information of resources required by the operation of each service component and a configuration file template of each service component from the analysis result; calling a platform as a service (PaaS) interface based on each resource information to apply for the resources required by operation for each service component and initialize the applied resources to obtain an operation container of each service component; respectively writing the resource information into a configuration file template of the corresponding service component to obtain a configuration file corresponding to each service component, and writing each mirror image file and each configuration file into an operation container of the corresponding service component; and starting the process of each running container to run each business component.

Wherein explanations of the same or corresponding terms as those of the above embodiments are omitted. Referring to fig. 2, the method for constructing a DSP system of a demand side platform provided in this embodiment includes the following steps:

s210, when a system construction instruction is received, a description file corresponding to the DSP system to be constructed is obtained.

And S220, analyzing the description file, and reading mirror image address information and Application Programming Interface (API) description information which respectively correspond to each service component contained in the DSP system to be constructed from the analysis result.

And S230, acquiring mirror image files corresponding to the service components respectively according to the mirror image address information.

And S240, reading resource information of resources required by the operation of each service component and a configuration file template of each service component from the analysis result.

In the present embodiment, the factor information includes, but is not limited to, mirror addresses, APIs, resources, and configuration files. Correspondingly, the description file is generated by describing the mirror image address, the API, the resource and the configuration file in advance. Thus, the parsing result of the description file also includes the resource information and the definition of the configuration file template. In other words, when the description file is configured in advance, the present embodiment may describe elements such as the mirror address, the API, the resource, and the configuration file of each service component, so as to construct the DSP system to be constructed based on the description of each element in the description file.

The resource information may be a resource required when the service component is run, including but not limited to a computation, a storage, and a network resource required when the service component is run, for example, a minimum of 2 Central Processing Units (CPUs), a 4G memory, and a 2M bandwidth are required to run the service component. The configuration file template may be a template of a configuration file required when the component code of the business component is run, and the configuration file template is decoupled from the component code and not coupled in an image file.

It should be noted that the execution sequence of steps S230 and S240 is not sequential, and may be that S230 and S240 are executed sequentially, or that S230 and S240 are executed simultaneously, which is not limited in this application.

And S250, calling a platform as a service (PaaS) interface based on the resource information to apply for the resources required by the operation of each service component and initialize the applied resources to obtain an operation container of each service component.

The Platform as a Service (PaaS) interface can apply for computing, storing, network and other cloud resources for the DSP system to be constructed. The PaaS interface can also apply for middleware resources for the DSP system to be built and provide a running container for each service component contained in the DSP system to be built. The purpose of calling the PaaS interface to initialize the resources is as follows: by applying for cloud resources, the difference between a physical machine and an operating system when a DSP system is constructed can be shielded, and each service component of the DSP only needs to be developed and operated aiming at a container environment provided by PaaS, so that the adaptation cost of a bottom layer complex environment is reduced.

And S260, respectively writing the resource information into the configuration file templates of the corresponding service components to obtain configuration files respectively corresponding to the service components, and writing the mirror image files and the configuration files into the operation containers of the corresponding service components.

The configuration file refers to a relevant file required by the operation of the business component. Specifically, the configuration file that the component code of each service component depends on when running is obtained by writing the resource information into the configuration file template. In other words, the configuration file and the image file are written into the operation container of the corresponding service component, so that the operation container can synchronously use the configuration file when the component code contained in the configuration file is operated, thereby completing the operation of the service component. It should be noted that any business component may correspond to one or more execution containers, and each execution container is used for executing an instance of the corresponding business component. The number N of the operation containers corresponding to the service component may be determined according to the description file, and a PaaS interface may be called according to the number N and resource information of resources required for the operation of the service component (the resource information represents resources required by one operation container), so as to apply for N resources required for the operation of the service component and initialize the applied N resources, thereby obtaining N operation containers of the service component. Exemplarily, it is determined that the number N of the operation containers corresponding to a certain service component a is 3 according to the description file, 3 resources need to be applied for the service component a by calling the PaaS interface, after the 3 applied resources are respectively initialized, 3 operation containers of the service component a are obtained, and after the 3 operation containers are started, each operation container operates an instance of the service component a.

Optionally, the Cloud Runtime layer of the delivery engine in the above embodiment may interact with PaaS through a PaaS interface, so as to implement application and management of resources required in the ApplicationModel layer. After the Cloud Runtime layer calls the PaaS interface to complete resource application and initialization, the daemon process of the node of the Cloud Runtime layer can write all resource information into the corresponding configuration file template. That is, in the process of constructing the DSP system, the delivery engine needs to apply for the dependent resources through PaaS, and the code warehouse that needs to be pulled is supported by the remote warehouse.

And S270, starting processes of the running containers to run the business components.

Specifically, in this embodiment, each service component is run by starting the process of each running container, so that the start and running of each service component included in the DSP system to be constructed are completed. Optionally, the Cloud Runtime layer of the delivery engine in the above embodiment may manage the starting process of the operation container of each service component through the kubernets open-source container cluster management system.

It is considered that the operation container of the partial business component needs to initialize the database before operation, for example, a data table needs to be created, initial data needs to be written, or a reference file needs to be prepared. Optionally, after writing each image file and each configuration file into the operation container of the corresponding service component, before starting the process of each operation container, the method further includes: reading installer codes of all service components from the analysis result; installer code for each service component is executed to initialize a database used by each service component.

Wherein the installer code can include at least one of creating a data table code, writing an initial data code, and preparing a reference file code. By executing the installer code corresponding to each service component, creation of a data table, writing of initial data, preparation of a base file, and the like can be realized.

That is, in the present embodiment, the element information further includes an installer, and accordingly, the description file is also generated based on a pre-configuration of the installer. That is, when the description file is configured in advance, it is necessary to describe elements such as the mirror address, the configuration file, the API, the resource information, and the installer so that the definition of the installer code in the analysis result can be read after the description file is analyzed. In this embodiment, initialization of the database used by each service component is realized by reading the installer code from the analysis result, so that a function of first configuring the database of each service component is provided.

S280, registering the API description information of each service component into the preset gateway module, so that the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request, and forwards the service request to the target service component.

According to the technical scheme of the embodiment, the description file which also comprises the resource information and the configuration file template is configured for the DSP system to be constructed in advance, so that the resources of each service component can be applied and the configuration file corresponding to the service component can be generated according to the analysis result of the description file, and then each service component is started to operate according to the configuration file and the image file, the abstraction that each service component depends on the resources is realized, and the difference between a physical machine and an operating system for constructing each service component is reduced; meanwhile, each service component is started through each operation container, and the adaptation cost of the bottom layer complex environment is effectively reduced.

EXAMPLE III

Fig. 3 is a flowchart illustrating a method for constructing a demand side platform DSP system according to a third embodiment of the present invention, where on the basis of the foregoing embodiments, optionally, after starting processes of running containers, the method further includes: reading the test cases of all the service components from the analysis result; executing the test cases of all the service components, and determining whether all the service components are normally started or not according to the execution result; if not, outputting the abnormal starting notification information.

Wherein explanations of the same or corresponding terms as those of the above embodiments are omitted. Referring to fig. 3, the method for constructing a DSP system of a demand side platform provided in this embodiment includes the following steps:

and S310, acquiring a description file corresponding to the DSP system to be constructed when the system construction instruction is received.

And S320, analyzing the description file, and reading mirror image address information and Application Programming Interface (API) description information which respectively correspond to each service component contained in the DSP system to be constructed from the analysis result.

And S330, acquiring mirror image files corresponding to the service components respectively according to the mirror image address information.

And S340, reading resource information of resources required by the operation of each service component and a configuration file template of each service component from the analysis result.

And S350, calling a platform as a service (PaaS) interface based on the resource information to apply for the resources required by operation for each service component and initialize the applied resources to obtain an operation container of each service component.

And S360, respectively writing the resource information into the configuration file templates of the corresponding service components to obtain configuration files respectively corresponding to the service components, and writing the mirror image files and the configuration files into the operation containers of the corresponding service components.

And S370, starting the process of each running container to run each business component.

S380, reading the test cases of the service components from the analysis result; executing the test cases of all the service components, and determining whether all the service components are normally started or not according to the execution result; if not, outputting the abnormal starting notification information.

The test case can be used to verify whether the starting state of the service component is correct. For example, the test case may be a test case for performing a probing interface test, and if the test case passes the test, it indicates that the start state of the service component is normal; and if the test is not passed, indicating that the starting state of the service component is abnormal. And at the moment, notification information of abnormal starting can be sent to the management end, so that developers corresponding to the management end can process the service component. The notification information may include information about the business component that initiated the state exception, such as the exception type and business component name, etc.

That is to say, on the basis of the foregoing embodiments, the element information of the service component in this embodiment further includes a test case, and correspondingly, the description file further includes a description of the test case. That is, in the present embodiment, when the description file is configured in advance, elements such as the test case are described, so as to verify the starting state of the service component based on the definition of the test case in the analysis result.

And S390, registering the API description information of each service component in the preset gateway module, so that the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request, and forwards the service request to the target service component.

According to the technical scheme of the embodiment, the situation that operation errors and the like may occur after part of the service components are started is considered, and the test cases of the service components are described in advance, so that the starting state is verified after the service components are started and operated, the normal operation of the service components is ensured, and the stability of the constructed DSP system is further improved.

Considering that a part of service components may have a situation that the starting state is normal but the service request processing is failed, the test case can only realize normal starting of the component code process, and cannot determine whether the service components can normally realize processing of the service request after normal starting, so that description of the monitoring code can be introduced into a pre-configured description file, thereby realizing monitoring of the service request processing process of each service component. Optionally, after determining that each service component is normally started according to the execution result, the method further includes: reading the monitoring codes of all the service components from the analysis result; and executing the monitoring codes of all the service components, determining whether all the service components can normally process the service request according to the execution result, and if not, outputting notification information of abnormal service processing.

The monitoring code may be configured to determine whether the started service component can normally process the service request. Specifically, after the monitoring codes of the service components are executed, whether the service components can normally process the service request can be judged based on the execution result of the monitoring codes. When the service component can not process the service request normally, the notification information of the service processing abnormity can be sent to the management terminal.

That is to say, on the basis of the foregoing embodiments, in this embodiment, the element information of the service component further includes a monitoring code, and correspondingly, the description file further includes a description of the monitoring code. That is, in this embodiment, when the description file is configured in advance, the monitoring code is described, so as to implement monitoring on the service component processing service request process based on the definition of the monitoring code in the parsing result. In the embodiment, the service component is monitored for processing the service request, so that the service component can normally process the service request, and further, the stability of the constructed DSP system is improved.

Optionally, the delivery engine may detect the operation state of the service component through a test case in a description file corresponding to the service component after the operation container of the service component is started through the kubernets open source container cluster management system. The delivery engine can also detect the operation state of the service assembly based on the test case through kubernets, and if the service assembly is in a normal operation state, the service assembly is monitored by adopting a monitoring process, so that whether each service assembly can normally process the service request is determined.

Optionally, executing the monitoring code of each service component, and determining whether each service component can normally process the service request according to the execution result, includes: and simulating and calling the interfaces in the service components by executing the monitoring codes of the service components, and comparing the actual return result and the expected result of the calling interfaces to determine whether the service components can normally process the service requests.

The actual return result may include an actual response result of an interface in the simulated invoked service component; the expected result may include a desired effect of simulating an interface in the invoked business component. For example, the monitoring code simulates an interface API-D of a calling business component, the expected result is that the file a is deleted, and the actual returned result is that the file a is not deleted. That is, when the actual returned result of the calling interface is inconsistent with the expected result, it indicates that the service component cannot normally process the service request. Or, the actual return result may further include the actual call time of the interface; the expected result may also include an expected invocation time of the interface. In one embodiment, a time difference threshold may be preset, and when the time difference between the actual calling time and the expected calling time does not exceed the time difference threshold and the actual returned result is consistent with the expected result, it is determined that the service component can normally process the service request.

Optionally, after starting the process of each running container, the method further includes: and reading the service attribute of each service component from the analysis result, and adjusting the component attribute of each service component based on the service attribute of each service component.

The service attribute may be used to set a switch of a service function of the service component, for example, to turn on or off some service functions of the service component; can also be used to set the associated threshold of the business function of the business component; for example, the upload threshold may be adjusted from 100M to 1G for the business function of uploading files, or the upload threshold may be set to 5M for general users, and the upload threshold may be set to 100M for VIP customers.

That is, in this embodiment, on the basis of the above embodiment, the element information further includes a service attribute, and correspondingly, the description file further includes a description of the service attribute. That is, when the description file is preconfigured, the service attribute is described, so that the component processing logic of the service component is adjusted based on the definition of the service attribute in the analysis result, the adaptation capability of the service component is stronger, and more actual requirements of the user can be met. The purpose of describing the business attributes of the business components is to: and a series of related attributes of the service components are exposed to the outside, and a linkage characteristic switch is set through the attributes, so that the service of the service components is customized according to the requirements.

In a preferred embodiment, the element information of the service component includes mirror image address, configuration file, resource, test case, monitoring code, installer, API and service attribute; correspondingly, the analysis result of the description file comprises definitions of mirror image address information, a configuration file template, resource information, a test case, a monitoring code, API description information and service attributes. After the mirror image address information, the configuration file template, the resource information, the test case, the monitoring code, the API description information and the service attribute are read together in the analysis result, the construction steps of the DSP system are as follows:

(1) determining a configuration file through a configuration file template and resource information; (2) calling a PaaS interface through the resource information to apply for corresponding resources and initializing the applied resources to obtain an operation container of each service component; (3) writing the mirror image file and the configuration file into an operation container; (4) initializing a database used by the service component through an installer code; (5) starting the process of the operation container of each business component; (6) registering the API description of each service component into a preset gateway module; (7) executing the test cases of all the service components to judge whether all the service components are normally started; (8) after the service component is normally started, executing a monitoring code of the service component, and determining whether the service component can normally process a service request; (9) and adjusting the component attributes of each service component based on the service attributes of each service component.

Namely, a description file is adopted to describe a DSP system to be constructed, and the interior of the DSP system comprises the definitions of modules, components, resources and service attributes; the service component open mirror image address, the configuration file, the resource, the test case, the monitoring code, the installer, the API and the related configuration of the attribute can realize the self-description of the service component through the related definition of the description document.

Example four

Fig. 4A is a schematic flow chart of a method for constructing a demand side platform DSP system according to a fourth embodiment of the present invention, where on the basis of the foregoing embodiments, optionally, after each service component is started and operated based on each image file, the method further includes: collecting log files generated during the operation of each business component; and monitoring the flow of each service component based on the log file, and storing the flow monitoring result.

Wherein explanations of the same or corresponding terms as those of the above embodiments are omitted. Referring to fig. 4A, the method for constructing a demand side platform DSP system provided in this embodiment includes the following steps:

and S410, acquiring a description file corresponding to the DSP system to be constructed when the system construction instruction is received.

And S420, analyzing the description file, and reading mirror image address information and Application Programming Interface (API) description information respectively corresponding to each service component contained in the DSP system to be constructed from the analysis result.

And S430, acquiring mirror image files corresponding to the service components respectively according to the mirror image address information.

And S440, reading resource information of resources required by the operation of each service component and a configuration file template of each service component from the analysis result.

S450, calling a platform as a service (PaaS) interface based on the resource information to apply for the resources required by operation for each service component and initialize the applied resources to obtain an operation container of each service component.

And S460, writing the resource information into the configuration file templates of the corresponding service components respectively to obtain configuration files corresponding to the service components respectively, and writing the mirror image files and the configuration files into the operation containers of the corresponding service components.

And S470, starting the processes of the running containers to run the business components.

And S480, registering the API description information of each service component into the preset gateway module, so that the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request, and forwards the service request to the target service component.

S490, collecting log files generated during operation of each service component; and monitoring the flow of each service component based on the log file, and storing the flow monitoring result.

Specifically, the traffic monitoring is performed on each service component based on the log file, and the traffic monitoring includes at least one of the following steps: counting the total number of service requests received by the service component; counting the total number of the service requests processed and completed by the service components; and counting the calling times of all service services (API) in the service components.

In an embodiment, based on the traffic monitoring result, the service monitoring of the service component may also be implemented, that is, the service preset in the service component is monitored. In an embodiment, a preset calling threshold may be set for a preset service, and when the actual calling times of the preset service exceeds the preset calling threshold, it is determined that the service is in an abnormal use state. The specific value of the preset invoking threshold is not limited, and may be determined based on the number of regular uses of the business service, for example. Illustratively, the preset service is an upload file (API-a), the preset calling threshold is 1000, and when the actual number of calls exceeds 1000, the upload file is considered to be in an abnormal use state, and at this time, an alarm notification may be sent to the management terminal.

Optionally, the Cloud Runtime layer in the delivery engine may provide log collection service and monitoring service, where the monitoring service includes traffic monitoring service and service monitoring service. The log collection service can be used for collecting log files generated when each service component runs; the flow monitoring service is used for monitoring the flow of each service component based on the log file; the business monitoring service is used for monitoring preset business services in each business component. Illustratively, as shown in FIG. 4B, a block diagram of a delivery engine is presented. The Cloud Runtime layer of the delivery engine provides log collection service and monitoring service, wherein the log collection service collects log files of the business components.

According to the technical scheme, after the operation of each service component is started based on each mirror image file, the log files generated when each service component operates are collected, and further the flow monitoring of the service components is realized, so that the related data of the service components can be checked, counted and analyzed, further, the analysis, adjustment and maintenance of the service components are realized, the operation stability of each service component is ensured, and the use experience of a user is greatly improved.

Optionally, the method further includes: determining whether the operation containers of the corresponding service components need to be increased or decreased according to the flow monitoring result of each service component; for the service component needing to be added with the operation container, applying for a new resource required by operation for the service component and initializing the applied new resource to obtain a new operation container of the service component; writing the mirror image file and the configuration file of the service component into a new operation container, and starting the process of the new operation container; and for the business components needing to reduce the operation containers, closing the existing operation containers of the business components.

Specifically, according to the flow monitoring result of each service component, it is really necessary to increase or decrease the operation containers of the corresponding service components, including: and determining whether the operation container of the corresponding service component needs to be increased or decreased according to the number of the service requests received by each service component. In an optional implementation manner, a lowest receiving threshold and a highest receiving threshold may be preset for each service component, and when the number of service requests received by the service component reaches the highest receiving threshold, it is determined that the running container of the service component needs to be increased; determining that the operational container of the business component needs to be reduced when the number of business requests received by the business component does not exceed a minimum receive threshold. The specific values of the lowest receiving threshold and the highest receiving threshold are not limited in the present application, for example, the lowest receiving threshold may be 10, and the highest receiving threshold may be 300.

It should be noted that, for a service component to which an operation container needs to be added, a PaaS interface may be called to apply for a new resource for the service component and initialize the applied new resource, so as to obtain a new operation container for the service component. For the service components needing to reduce the operation containers, the PaaS interface can be called to close the existing operation containers of the service components.

In this embodiment, the operation container of the service component is adjusted according to the traffic monitoring result, so that an automatic control policy of the operation container is implemented, and automatic expansion and contraction of the service component is automatically completed, so that the resource of the service component is adjusted in real time, and further, reasonable use of the resource is ensured.

In one embodiment, the Cloud Runtime layer in the delivery engine may provide component management services and resource management services. The component management service includes, but is not limited to, an automatic capacity expansion service, that is, an operation container of the service component may be adjusted according to a traffic monitoring result. The resource management service can call the PaaS interface to complete the application of the resources required by each service component. Illustratively, as shown in FIG. 4B, the Cloud Runtime layer provides component management services and resource management services.

EXAMPLE five

Fig. 5A is a schematic flow chart of a method for constructing a demand side platform DSP system according to a fifth embodiment of the present invention, where on the basis of the foregoing embodiments, optionally, the method further includes: when an upgrading instruction of a service assembly is received, acquiring a new description file of the service assembly to be upgraded from a management terminal according to the upgrading instruction; reading new mirror image address information and new API description information of the service assembly to be upgraded from the new description file; and acquiring a new image file corresponding to the service component to be upgraded according to the new image address information, replacing the existing image file in the operation container of the service component to be upgraded with the new image file, restarting the process of the operation container of the service component to be upgraded, and replacing the existing API description information of the service component to be upgraded in the preset gateway module with new API description information.

Wherein explanations of the same or corresponding terms as those of the above embodiments are omitted. Referring to fig. 5A, the method for constructing a demand side platform DSP system provided in this embodiment includes the following steps:

s501, when a system construction instruction is received, a description file corresponding to the DSP system to be constructed is obtained.

S502, analyzing the description file, and reading mirror image address information and Application Programming Interface (API) description information respectively corresponding to each service component contained in the DSP system to be constructed from the analysis result.

S503, acquiring mirror image files corresponding to the service components according to the mirror image address information.

S504, reading resource information of resources required by operation of each business component and a configuration file template of each business component from the analysis result.

And S505, calling a platform as a service (PaaS) interface based on the resource information to apply for the resources required by the operation of each service component and initialize the applied resources to obtain an operation container of each service component.

S506, respectively writing the resource information into the configuration file templates of the corresponding service components to obtain configuration files respectively corresponding to the service components, and writing the mirror image files and the configuration files into the operation containers of the corresponding service components.

And S507, starting processes of the running containers to run the business components.

And S508, registering the API description information of each service component into the preset gateway module, so that the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request, and forwards the service request to the target service component.

S509, when an upgrading instruction of the service component is received, acquiring a new description file of the service component to be upgraded from the management terminal according to the upgrading instruction; and reading the new mirror image address information and the new API description information of the service assembly to be upgraded from the new description file.

The upgrade instruction of the service component may be generated based on the user execution operation, or may be automatically issued by the management terminal. For example, the upgrade instruction may be automatically issued by the management end after the component code of the service component is updated, or the upgrade instruction may be automatically issued by the management end after the configuration file template of the service component is updated.

In other words, the management terminal configures a corresponding new description file for the service component to be upgraded in advance; and acquiring a new description file of the service component to be upgraded from the management terminal through the upgrading instruction, and acquiring corresponding new mirror image address information and new API description information.

S510, acquiring a new image file corresponding to the service component to be upgraded according to the new image address information, replacing the existing image file in the operation container of the service component to be upgraded with the new image file, restarting the process of the operation container of the service component to be upgraded, and replacing the existing API description information of the service component to be upgraded in the preset gateway module with new API description information.

Specifically, when a new image file and new API description information are acquired, the new image file is written into the operation container corresponding to the service component to be upgraded, so that the existing image file is replaced, and the process of the operation container of the service component to be upgraded is restarted; and meanwhile, replacing the API description information of the registered service component to be upgraded in the preset gateway module with new API description information, thereby realizing the dynamic upgrade of the service component.

According to the technical scheme of the embodiment, the new description file of the service component to be upgraded is acquired from the management terminal, the new mirror image address information and the new API description information are acquired based on the new description file, and then the existing service component in the DSP system is dynamically upgraded, so that the real-time updating of the service contained in the service component is realized, and the flexibility of the service component in the DSP system is improved.

Optionally, the method further includes: and when a display instruction corresponding to the service component is received, visually displaying data generated when the service component operates. The data generated during the operation of the service component includes, but is not limited to, data of a log file, data of a traffic monitoring result, data of a state of the service component, and the number of operation containers of the service component. The operation of the business component is not limited to the generation of the data, and any visual data generated by the operation of the business component can be displayed. The present application does not limit the manner of presentation of data generated when a business component operates, and may present data in any format, such as a graph, a line graph, a graph, or a data table.

In one embodiment, the Cloud Runtime layer in the delivery engine can also provide dashboard services, and the component management services provided by the Cloud Runtime layer also include dynamic upgrade services. The dashboard service is used for visually displaying data generated by the Cloud Runtime layer, namely, visually displaying data generated during the operation of the business component; the dynamic upgrade service is used for acquiring a new description file of the service component to be upgraded from the management end so that an Application Model layer in the delivery engine can analyze the new description file, and the Cloud Runtime layer calls a PaaS interface to apply for resources corresponding to the new scanning file, thereby completing the dynamic upgrade of the service component. Exemplarily, as shown in fig. 4B, where the AD Cloud Master is a management end, the component management service obtains a new description file of the service component to be upgraded from the management end.

Optionally, the method for constructing the demand side platform DSP system in each of the above embodiments further includes: when an adding instruction of a business component is received, interacting with a management terminal to determine whether the management terminal has the authority of adding a new business component; if so, acquiring a description file of the new service component issued by the management terminal, and reading mirror image address information and API description information of the new service component from the description file of the new service component; and acquiring a mirror image file corresponding to the new service component according to the mirror image address information of the new service component, starting to operate the new service component based on the mirror image file corresponding to the new service component, and registering the API description information of the new service component into a preset gateway module.

Wherein, the adding instruction of the business component can be generated based on the user executing operation. For example, the user has triggered a corresponding control that adds a business component. Optionally, the interacting with the management end to determine whether the management end has the right to add the new service component includes: acquiring verification information of the management terminal on the authorization permission information, and if the verification is passed, having the authority of adding a new service component; and if the verification fails, the authority for adding the new service component is not provided.

Illustratively, when an adding instruction of a service component is received, a request for checking license authorization is sent to the management terminal, and checking information authorized by the management terminal to the license is obtained, if the check authorized by the management terminal passes, a description file of a new service component issued by the management terminal is obtained.

In one embodiment, the mirror image address information, the configuration file template, the API description information, the test case, the resource information, the monitoring code, the installer code, and the service attribute of the new service component are read from the parsing result of the description file of the new service component, thereby completing the construction, deployment, and verification of the entire DSP system.

In the embodiment, by acquiring the description file of the new service component issued by the management terminal, and reading the mirror address information and the API description information of the new service component from the description file of the new service component, to start running the new service component, dynamic addition of the service component in the DSP system is realized, thereby realizing extended installation of the value-added service.

In one embodiment, the component management services provided by the Cloud Runtime layer in the delivery engine further include component add-on services. The component newly-added service is used for interacting with the management terminal to determine whether the new service component has the authority of adding the new service component when receiving the adding instruction of the service component; and if so, acquiring a description file of the new service component issued by the management terminal. Illustratively, as shown in FIG. 4B, the component add-on service may interact with the management side. Optionally, the node in the Cloud Runtime layer may interact with the management end, and obtain a description file of a new service component sent by the management end, and the node completes installation and initialization of the new service component after receiving the description file.

Next, a principle of constructing a DSP system based on the payment engine will be explained. As shown in fig. 5B, a schematic diagram of the construction of a DSP system is shown. The delivery engine provides log collection service, component management service, resource management service, monitoring service and dashboard service. The delivery engine reads the description file, analyzes the description file into each component model Ada-model, and calls the underlying PaaS to complete the application of resources, the deployment, the configuration, the initialization, the operation, the test, the monitoring and the like in sequence according to the definition of each component model. After the user finishes the installation of the DSP system, if the service assembly needs to be upgraded or the operation container needs to be added or deleted in the later period, the delivery engine can receive the assembly code of the service assembly or the description file modified by the operation container by a developer, and the replacement of the service assembly or the addition or deletion of the operation container is realized according to the corresponding control instruction. And if a new value-added service component needs to be installed in the later stage, acquiring a component model of the service component after authorization through the connection of the delivery engine and the management end, and performing initial installation and configuration of the new service component according to the component model to finish the customized installation of the value-added service component. In addition, as shown in fig. 5B, the interaction engine may also interact and/or integrate with the enterprise system to provide various business services included in the constructed DSP system for the enterprise system.

EXAMPLE six

Fig. 6 is a schematic structural diagram of a device for constructing a demand side platform DSP system according to a sixth embodiment of the present invention, which is applicable to a case where a DSP system is constructed according to actual requirements of a user, and is particularly applicable to a case where service components included in a DSP system are started and run according to a description file corresponding to the DSP system, and API description information of each service component is registered. The device specifically includes: a file acquisition module 610, a file parsing module 620, a component starting module 630 and an API registration module 640.

The file obtaining module 610 is configured to obtain a description file corresponding to a DSP system to be built when a system building instruction is received;

the file analysis module 620 is configured to analyze the description file, and read, from an analysis result, mirror address information and application programming interface API description information respectively corresponding to each service component included in the DSP system to be constructed;

the component starting module 630 is configured to obtain image files corresponding to the service components according to the image address information, and start and operate the service components based on the image files;

the API registration module 640 is configured to register API description information of each service component in the preset gateway module, so that the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request, and forwards the service request to the target service component.

In this embodiment, when a system building instruction is received by the file obtaining module, a description file corresponding to the DSP system to be built is obtained, the description file is analyzed by the file analyzing module, mirror address information and API description information corresponding to each service component included in the DSP system to be built are read from an analysis result, the mirror file corresponding to each service component is obtained by the component starting module according to each mirror address information, each service component is started and operated based on each mirror file, and the API description information of each service component is registered in the preset gateway module by the API registration module, so that the preset gateway module determines a corresponding target service component when receiving a service request, and forwards the service request to the target service component. The scheme realizes that the deployment of the DSP system can be automatically completed based on the description file, thereby greatly reducing the customization cost of the DSP system. In addition, the description file corresponding to the DSP system to be built can be configured according to the actual requirements of the user, so that the customized DSP can be built based on the actual requirements of the user.

Optionally, the component starting module 630 includes a reading unit, an initializing unit, a writing unit, and a starting unit:

the reading unit is used for reading resource information of resources required by the operation of each service component and a configuration file template of each service component from the analysis result;

the system comprises an initialization unit, a service platform as a service (PaaS) interface, a service component and a service component, wherein the initialization unit is used for calling the PaaS interface based on each resource information to apply for the resources required by operation for each service component and initialize the applied resources to obtain an operation container of each service component;

the writing unit is used for respectively writing the resource information into the configuration file templates of the corresponding service components to obtain configuration files respectively corresponding to the service components, and writing the mirror image files and the configuration files into the operation containers of the corresponding service components;

and the starting unit is used for starting the processes of the running containers so as to run the business components.

Optionally, the component starting module 630 further includes an initialization unit, configured to read installer codes of each service component from the analysis result after each image file and each configuration file are written into the operation container of the corresponding service component and before a process of each operation container is started; installer code for each service component is executed to initialize a database used by each service component.

Optionally, the component starting module 630 further includes a starting detection unit, configured to read the test case of each service component from the analysis result after the process of each running container is started; executing the test cases of all the service components, and determining whether all the service components are normally started or not according to the execution result; if not, outputting the abnormal starting notification information.

Optionally, the construction apparatus of the demand side platform DSP system further includes a processing and monitoring module, configured to read a monitoring code of each service component from the analysis result after the start detection unit determines that each service component is normally started according to the execution result; and executing the monitoring codes of all the service components, determining whether all the service components can normally process the service request according to the execution result, and if not, outputting notification information of abnormal service processing.

Optionally, the processing and monitoring module is specifically configured to simulate and call an interface in each service component by executing a monitoring code of each service component, and determine whether each service component can normally process the service request by comparing an actual return result and an expected result of the call interface.

Optionally, the construction device of the demand side platform DSP system further includes a log collection module and a flow monitoring module; the log collection module is used for collecting log files generated when the business components run after the business components are started to run based on the mirror image files; and the flow monitoring module is used for monitoring the flow of each service component based on the log file and storing the flow monitoring result.

Optionally, the construction apparatus of the demand side platform DSP system further includes a container adding and deleting module, configured to determine whether to add or reduce an operation container of a corresponding service component according to a traffic monitoring result of each service component; for the service component needing to be added with the operation container, applying for a new resource required by operation for the service component and initializing the applied new resource to obtain a new operation container of the service component; writing the mirror image file and the configuration file of the service component into a new operation container, and starting the process of the new operation container; and for the business components needing to reduce the operation containers, closing the existing operation containers of the business components.

Optionally, the construction apparatus of the platform DSP system on the demand side further includes an assembly upgrading module, configured to obtain, according to an upgrading instruction, a new description file of the service assembly to be upgraded from the management terminal when the upgrading instruction of the service assembly is received; reading new mirror image address information and new API description information of the service assembly to be upgraded from the new description file; and acquiring a new image file corresponding to the service component to be upgraded according to the new image address information, replacing the existing image file in the operation container of the service component to be upgraded with the new image file, restarting the process of the operation container of the service component to be upgraded, and replacing the existing API description information of the service component to be upgraded in the preset gateway module with new API description information.

Optionally, the API description information includes a corresponding relationship between an API name included in the corresponding service component and a uniform resource locator URL address; correspondingly, the API registration module 640 is configured to, when the preset gateway module receives the service request, determine, according to the correspondence, an API corresponding to the URL address included in the service request as a target API, or determine, according to the domain name included in the service request, a default API that is pre-configured for the domain name as the target API; and determining the service component where the target API is positioned as a target service component, and forwarding the service request to the target service component.

Optionally, the construction apparatus of the demand side platform DSP system further includes a component adding module, configured to interact with the management terminal to determine whether the authority to add a new service component is provided when receiving an add instruction of a service component; if so, acquiring a description file of the new service component issued by the management terminal, and reading mirror image address information and API description information of the new service component from the description file of the new service component; acquiring a mirror image file corresponding to the new service component according to the mirror image address information of the new service component, starting to operate the new service component based on the mirror image file corresponding to the new service component, and registering API description information of the new service component into a preset gateway module

The construction device of the demand side platform DSP system provided by the embodiment of the invention can execute the construction method of the demand side platform DSP system provided by any embodiment of the invention, and has corresponding functional modules and beneficial effects of the execution method.

It should be noted that, the units and modules included in the system are merely divided according to functional logic, but are not limited to the above division as long as the corresponding functions can be realized; in addition, specific names of the functional units are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the embodiment of the invention.

EXAMPLE seven

Fig. 7 is a schematic structural diagram of an electronic device according to a seventh embodiment of the present invention. FIG. 7 illustrates a block diagram of an exemplary electronic device 12 suitable for use in implementing embodiments of the present invention. The electronic device 12 shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiment of the present invention. The device 12 is typically an electronic device that assumes the building functions of a DSP system.

As shown in FIG. 7, electronic device 12 is embodied in the form of a general purpose computing device. The components of electronic device 12 may include, but are not limited to: one or more processors or processing units 16, a memory 28, and a bus 18 that couples the various components (including the memory 28 and the processing unit 16).

Bus 18 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures include, but are not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an enhanced ISA bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

Electronic device 12 typically includes a variety of computer-readable media. Such media may be any available media that is accessible by electronic device 12 and includes both volatile and nonvolatile media, removable and non-removable media.

Memory 28 may include computer device readable media in the form of volatile Memory, such as Random Access Memory (RAM) 30 and/or cache Memory 32. The electronic device 12 may further include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, the storage device 34 may be used to read from and write to non-removable, nonvolatile magnetic media (not shown in FIG. 7, and commonly referred to as a "hard drive"). Although not shown in FIG. 7, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, nonvolatile optical disk (e.g., a Compact disk-Read Only Memory (CD-ROM), a Digital Video disk (DVD-ROM), or other optical media) may be provided. In these cases, each drive may be connected to bus 18 by one or more data media interfaces. Memory 28 may include at least one program product 40, with program product 40 having a set of program modules 42 configured to carry out the functions of embodiments of the invention. Program product 40 may be stored, for example, in memory 28, and such program modules 42 include, but are not limited to, one or more application programs, other program modules, and program data, each of which examples or some combination may comprise an implementation of a network environment. Program modules 42 generally carry out the functions and/or methodologies of the described embodiments of the invention.

Electronic device 12 may also communicate with one or more external devices 14 (e.g., keyboard, mouse, camera, etc., and display), one or more devices that enable a user to interact with electronic device 12, and/or any devices (e.g., network card, modem, etc.) that enable electronic device 12 to communicate with one or more other computing devices. Such communication may be through an input/output (I/O) interface 22. Also, the electronic device 12 may communicate with one or more networks (e.g., a Local Area Network (LAN), Wide Area Network (WAN), and/or a public Network such as the internet) via the Network adapter 20. As shown, the network adapter 20 communicates with other modules of the electronic device 12 via the bus 18. It should be understood that although not shown in the figures, other hardware and/or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, Redundant processing units, external disk drive Arrays, disk array (RAID) devices, tape drives, and data backup storage devices, to name a few.

The processor 16 executes various functional applications and data processing by running the program stored in the memory 28, for example, implementing the method for constructing the platform DSP system on demand side provided by the above embodiments of the present invention, including:

acquiring mirror image files corresponding to the service components respectively according to the mirror image address information, and starting to operate the service components based on the mirror image files;

and registering the API description information of each service component in the preset gateway module, so that the preset gateway module determines a target service component for processing the service request based on the registered API description information when receiving the service request, and forwards the service request to the target service component.

Of course, those skilled in the art can understand that the processor can also implement the technical solution of the method for constructing the platform DSP system provided by any embodiment of the present invention.

Example eight

An eighth embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the method for constructing a platform DSP system as provided in any embodiment of the present invention, where the method includes:

Computer storage media for embodiments of the invention may employ any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

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

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

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

It is to be noted that the foregoing is only illustrative of the preferred embodiments of the present invention and the technical principles employed. It will be understood by those skilled in the art that the present invention is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the invention. Therefore, although the present invention has been described in greater detail by the above embodiments, the present invention is not limited to the above embodiments, and may include other equivalent embodiments without departing from the spirit of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A method for constructing a demand side platform DSP system is characterized by comprising the following steps:

2. The method of claim 1, wherein starting running each of the business components based on each of the image files comprises:

reading resource information of resources required by the operation of each service component and a configuration file template of each service component from the analysis result;

calling a platform as a service (PaaS) interface based on the resource information to apply for the resources required by operation for each service component and initialize the applied resources to obtain an operation container of each service component;

respectively writing the resource information into a configuration file template of a corresponding service component to obtain configuration files respectively corresponding to the service components, and writing the image files and the configuration files into an operation container of the corresponding service component;

and starting the process of each operation container to operate each service component.

3. The method of claim 2, wherein after writing each of the image files and each of the configuration files into a runtime container of a corresponding business component, and before starting a process of each of the runtime containers, the method further comprises:

reading installer codes of all the service components from the analysis result;

executing installer codes of all the service components to initialize a database used by all the service components.

4. The method of claim 2, wherein after initiating the process for each of the run containers, the method further comprises:

reading the test cases of the service components from the analysis result;

executing the test case of each business component, and determining whether each business component is normally started or not according to an execution result; if not, outputting the abnormal starting notification information.

5. The method of claim 4, wherein after determining that each of the service components is normally started according to the execution result, the method further comprises:

reading the monitoring codes of the service components from the analysis result;

and executing the monitoring codes of the service components, determining whether the service components can normally process the service request according to the execution result, and if not, outputting notification information of abnormal service processing.

6. The method of claim 5, wherein executing the monitoring code of each service component and determining whether each service component can normally process the service request according to the execution result comprises:

and simulating and calling the interface in each service component by executing the monitoring code of each service component, and comparing the actual return result and the expected result of the calling interface to determine whether each service component can normally process the service request.

7. The method of claim 2, wherein after initiating the running of each business component based on each image file, the method further comprises:

collecting log files generated during the operation of each service component;

and monitoring the flow of each service component based on the log file, and storing the flow monitoring result.

8. The method of claim 7, further comprising:

determining whether the operation containers of the corresponding service components need to be increased or decreased according to the flow monitoring result of each service component;

for a service component needing to be added with an operation container, applying for a new resource required by operation for the service component and initializing the applied new resource to obtain a new operation container of the service component; writing the mirror image file and the configuration file of the service component into a new operation container, and starting the process of the new operation container;

and for the business components needing to reduce the operation containers, closing the existing operation containers of the business components.

9. The method of claim 2, further comprising:

when an upgrading instruction of a service component is received, acquiring a new description file of the service component to be upgraded from a management terminal according to the upgrading instruction;

reading new mirror image address information and new API description information of the service assembly to be upgraded from the new description file;

and acquiring a new image file corresponding to the service component to be upgraded according to the new image address information, replacing the existing image file in the operation container of the service component to be upgraded with the new image file, restarting the process of the operation container of the service component to be upgraded, and replacing the existing API description information of the service component to be upgraded in the preset gateway module with the new API description information.

10. The method according to claim 1, wherein the API description information includes a corresponding relationship between an API name and a uniform resource locator URL address included in the corresponding service component;

when receiving a service request, the preset gateway module determines a target service component for processing the service request based on the registered API description information, and forwards the service request to the target service component, including:

when receiving a service request, the preset gateway module determines an API corresponding to a URL address contained in the service request as a target API according to the corresponding relation, or determines a default API pre-configured for the domain name as a target API according to the domain name contained in the service request;

and determining the service component where the target API is positioned as a target service component, and forwarding the service request to the target service component.

11. The method according to any one of claims 1-10, further comprising:

when an adding instruction of a business component is received, interacting with a management terminal to determine whether the management terminal has the authority of adding a new business component;

if yes, acquiring a description file of a new service component issued by a management end, and reading mirror image address information and API description information of the new service component from the description file of the new service component;

and acquiring a mirror image file corresponding to the new service component according to the mirror image address information of the new service component, starting to operate the new service component based on the mirror image file corresponding to the new service component, and registering API description information of the new service component into the preset gateway module.

12. A construction device of a demand side platform DSP system is characterized by comprising:

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

one or more processors;

a memory for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the method of constructing a demand side platform DSP system according to any one of claims 1 to 11.

14. A computer-readable storage medium on which a computer program is stored, the program, when executed by a processor, implementing the method of constructing a demand side platform DSP system according to any one of claims 1 to 11.