CN109905258B

CN109905258B - PaaS management method, device and storage medium

Info

Publication number: CN109905258B
Application number: CN201711288701.XA
Authority: CN
Inventors: 夏海涛
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2017-12-07
Filing date: 2017-12-07
Publication date: 2020-11-17
Anticipated expiration: 2037-12-07
Also published as: CN109905258A; WO2019109948A1

Abstract

The application discloses a PaaS management method, a PaaS management device and a storage medium, and belongs to the technical field of cloud computing. The method comprises the following steps: and when the MANO entity determines that the target service tenant does not need to call the target service any more, sending a service configuration request aiming at the target service to the PaaS. Based on the service configuration request, the PaaS releases the contract binding relationship between the target service tenant and the target service, and terminates all the instances of the target service when determining that the contract binding relationship between other service tenants and the target service does not exist. Therefore, the service provided by the application does not need to be terminated along with the termination of the instance of the service tenant like a proprietary service, the reusability of the instance of the service among a plurality of service tenants is improved, and the efficiency of resource management of the service by the PaaS platform is greatly improved.

Description

PaaS management method, device and storage medium

Technical Field

The present disclosure relates to the field of cloud computing technologies, and in particular, to a method and an apparatus for Platform as a Service (PaaS) management, and a storage medium.

Background

PaaS refers to providing a server as a service to a user, so that the user can implement network functions such as development, testing, and online deployment of application programs on the internet. At present, PaaS is mainly realized by a Network Function Virtualization (NFV) technology, that is, PaaS is deployed in an NFV architecture, and when a Virtual Network Function (VNF) in the NFV architecture needs to call a service deployed on PaaS in an instantiation process, the service is instantiated to realize a Network Function corresponding to the service. Instantiation refers to a process of configuring virtual resources for a service or a VNF through a Network Function Virtualization Infrastructure (NFVI) in an NFV architecture. Among them, a VNF that calls a certain service may be referred to as a service tenant of the service.

In the related art, services deployed on PaaS are divided into two types, one is a public service, and the other is a private service. The lifecycle of the common service and the lifecycle of the VNF that calls the common service are independent of each other, that is, the common service is always kept online after instantiation, and when a certain VNF in the NFV architecture needs to call the common service in the instantiation process, only an instance corresponding to the common service needs to be called, and the instance of the common service is not terminated along with the termination of the instance of the VNF. The lifetime of the proprietary service is closely related to the lifetime of the VNF invoking the proprietary service, i.e. the proprietary service is instantiated along with the instantiation of the VNF invoking the proprietary service and terminates along with the termination of the instance of the VNF invoking the proprietary service.

In the management method of the PaaS, for a public service, no matter whether a VNF needs to call the public service or not, an instance of the public service is always kept online, so that a resource occupation burden on the PaaS is increased; for the proprietary service, since the instance of the proprietary service is terminated along with the termination of the instance of the VNF that invokes the proprietary service, the proprietary service needs to be instantiated each time the proprietary service is invoked, which reduces the application flexibility of the proprietary service.

Disclosure of Invention

In order to solve the problem of low flexibility of proprietary service application in the related art, the application provides a PaaS management method, device and storage medium. The technical scheme is as follows:

in a first aspect, a PaaS management method is provided, and is applied to a PaaS deployed in an NFV architecture, where the PaaS is deployed with multiple services, and the method includes:

receiving a service configuration request for a target service sent by a Management and organization function (MANO) entity in the NFV architecture, where the service configuration request is sent by the MANO entity when it is determined that a target service tenant in the NFV architecture no longer calls the target service, and the target service is any one of the services;

based on the service configuration request, releasing a contract binding relationship between the target service tenant and the target service, wherein the contract binding relationship is used for indicating that the target service tenant can call the target service;

terminating all instances of the target service when it is determined that there is no contractual binding relationship between other service tenants in the NFV architecture and the target service.

In the embodiment of the application, when the target service tenant no longer calls the target service, the contract binding relationship between the target service tenant and the target service is firstly released, and when it is determined that the contract binding relationship between other service tenants in the NFV architecture and the target service does not exist, all instances of the target service are terminated, instead of directly terminating all instances of the target service when the target service tenant no longer calls the target service. Therefore, the service provided by the application does not need to be terminated along with the termination of the instance of the service tenant like a proprietary service, and the application flexibility of the service on PaaS is improved.

Optionally, the service configuration request carries a configuration type, an identifier of the target service tenant, and an identifier of the target service, where the configuration type is a release contract.

Since the contract binding relationship between the target service tenant and the target service needs to be released in some scenarios, and the use binding relationship between the instance of the target service tenant and the instance of the target service needs to be released in some scenarios, in the present application, which relationship needs to be terminated may be determined by the configuration type carried in the service configuration request.

Optionally, after releasing the contractual binding relationship between the target service tenant and the target service based on the service configuration request, the method further includes:

sending a first type of service configuration response message to the MANO entity, wherein the first type of service configuration response message is used for indicating that the contract binding relationship between the target service and the target service tenant is released.

When the PaaS releases the contract binding relationship between the target service tenant and the target service, the MANO entity needs to be informed in time that the contract binding relationship is released.

Optionally, the service configuration request carries a configuration type, an identifier of an instance of the target service tenant, an identifier of an instance of the target service, and a delay time, where the configuration type is a release;

correspondingly, the releasing the contract binding relationship between the target service tenant and the target service based on the service configuration request comprises:

based on the configuration type, the identification of the target service tenant instance and the identification of the target service instance, releasing the use binding relationship between the target service instance and the target service tenant instance;

when determining that the target service tenant does not call the target service again within the lag time after the current time, releasing the contractual binding relationship between the target service and the target service tenant.

Specifically, when the configuration type is the release type, it indicates that the MANO entity intends to release the usage binding relationship between the instance of the target service tenant and the instance of the target service, and after the PaaS releases the usage binding relationship between the instance of the target service tenant and the instance of the target service, the contractual binding relationship between the target service tenant and the target service may also be released through the above manner.

Optionally, after the releasing the usage binding relationship between the instance of the target service and the instance of the target service tenant, the method further includes:

sending a second type service configuration response message to the MANO entity, wherein the second type service configuration response message is used for indicating that the use binding relationship between the instance of the target service and the instance of the target service tenant is released.

Similarly, after the PaaS releases the usage binding relationship between the instance of the target service tenant and the instance of the target service, the MANO entity needs to be notified in time that the usage binding relationship has been released.

Optionally, before the receiving the service configuration request for the target service sent by the MANO entity in the NFV architecture, the method further includes:

receiving a configuration request sent by the MANO entity, wherein the configuration request carries an identifier of an instance of the target service tenant and an identifier of an instance of the target service;

based on the identification of the instance of the target service tenant and the identification of the instance of the target service, establishing a use binding relationship between the instance of the target service tenant and the instance of the target service, and establishing a contract binding relationship between the target service tenant and the target service when determining that the target service tenant does not exist in the tenant list of the target service.

Specifically, in the present application, PaaS may establish a usage binding relationship between an instance of a target service tenant and an instance of a target service when a MANO entity sends a configuration request, and establish a contract binding relationship between the target service tenant and the target service according to an actual situation.

Optionally, before receiving the configuration request sent by the MANO entity, the method further includes:

receiving an instance acquisition request sent by the MANO entity, wherein the instance acquisition request carries the identifier of the target service;

when determining that the target service instance exists based on the target service identifier, sending a first response message to the MANO entity, wherein the first response message is used for indicating that the target service has been instantiated and carries the target service instance identifier;

when it is determined that the target service instance does not exist based on the target service identifier, sending a second response message to the MANO entity, where the second response message is used to indicate that the target service is not instantiated, receiving a service instantiation request sent by the MANO entity, where the service instantiation request carries the target service identifier, instantiating the target service based on the target service identifier to obtain the target service instance, and sending an instantiation response message to the MANO entity, where the instantiation response message carries the target service identifier.

Specifically, the MANO entity may obtain the identifier of the instance of the target service by sending an instance obtaining request to the PaaS. When the PaaS determines that the target service instance does not exist currently, the PaaS needs to feed back the target service instance to the MANO entity so that the MANO entity sends an instantiation request aiming at the target service.

Optionally, the instantiating the target service based on the identifier of the target service to obtain the instance of the target service includes:

acquiring a descriptor file of the target service from a stored descriptor file of the service based on the identification of the target service, wherein the descriptor file of the target service is used for describing information required in the instantiation process of the target service;

and instantiating the target service according to the information required in the target service instantiation process in the descriptor file of the target service to obtain the instance of the target service.

Specifically, PaaS may instantiate the target service through the above-described process to obtain an instance of the target service.

Optionally, the MANO entity is a virtual network function Manager (VNF Manager, VNFM) in the NFV architecture.

In the present application, the MANO entity may be a VNFM in the NFV architecture.

In a second aspect, another PaaS management method is provided, and is applied to a MANO entity in a Network Function Virtualization (NFV) architecture, where the NFV architecture has a PaaS deployed therein, where the PaaS has multiple services deployed thereon, and the method includes:

when determining that a target service tenant in the NFV architecture does not call a target service any more, sending a service configuration request for the target service to the PaaS;

the service configuration request is used for indicating the PaaS to release the contract binding relationship between the target service tenant and the target service based on the service configuration request, and terminating all the instances of the target service when determining that no contract binding relationship exists between other service tenants and the target service, wherein the target service is any one of the plurality of services.

In this embodiment of the application, when the target service tenant no longer calls the target service, the MANO entity may send a service configuration request to the PaaS, so that the PaaS first releases the contract binding relationship between the target service tenant and the target service, and terminates all instances of the target service when it is determined that there is no contract binding relationship between other service tenants in the NFV architecture and the target service, instead of directly terminating all instances of the target service when the target service tenant no longer calls the target service. Therefore, the service provided by the application does not need to be terminated along with the termination of the instance of the service tenant like a proprietary service, and the application flexibility of the service on PaaS is improved.

Optionally, the sending, to the PaaS, a service configuration request for a target service when it is determined that a target service tenant in the NFV architecture no longer calls the target service, includes:

when the descriptor file of the target service tenant is determined to be updated, acquiring the descriptor file of the target service tenant after updating;

when it is determined that the target service needs to be deleted from the service list used by the target service tenant according to the updated descriptor file of the target service tenant, sending a service configuration request to the PaaS, where the service configuration request carries a configuration type, an identifier of the target service tenant, and an identifier of the target service, and the configuration type is a contract release.

Specifically, when the descriptor file of the target service tenant is updated, the MANO entity may be triggered to send a service configuration request to PaaS.

Optionally, after sending the service configuration request to the PaaS, the method further includes:

receiving a first type of service configuration response message sent by the PaaS, wherein the first type of service configuration response message is used for indicating that the contract binding relationship between the target service and the target service tenant is released.

When the MANO entity receives the first type of service configuration response message, the PaaS is shown to have released the contract binding relationship between the target service and the target service tenant.

when the identification of the target service tenant instance is deleted, a descriptor file of the target service tenant is obtained;

determining lag time according to the descriptor file of the target service tenant;

and sending the service configuration request to the PaaS, wherein the service configuration request carries a configuration type, an identifier of an instance of the target service tenant, an identifier of an instance of the target service and the delay time, and the configuration type is a release type.

Specifically, when the identifier of the target service tenant is deleted, the MANO entity may be triggered to send a service configuration request to PaaS.

receiving a second type of service configuration response message sent by the PaaS, wherein the second type of service configuration response message is used for indicating that the use binding relationship between the instance of the target service and the instance of the target service tenant is released.

When the MANO entity receives the second type service configuration response message, the fact that PaaS has released the use binding relationship between the instance of the target service and the instance of the target service tenant is indicated.

Optionally, before sending the service configuration request for the target service to the PaaS, the method further includes:

sending a configuration request to the PaaS, wherein the configuration request carries an identifier of the instance of the target service tenant and an identifier of the instance of the target service, and the configuration request is used for indicating the PaaS to establish a use binding relationship between the instance of the target service tenant and the instance of the target service.

In the application, in order to facilitate that the subsequent instance of the target service tenant can call the instance of the target service, the MANO entity may send a configuration request to the PaaS, so that the PaaS establishes a usage binding relationship between the instance of the target service tenant and the instance of the target service.

Optionally, before sending the configuration request to the PaaS, the method further includes:

when determining that the target service tenant needs to call the target service, sending an instance acquisition request to the PaaS, wherein the instance acquisition request carries an identifier of the target service;

receiving a first response message sent by the PaaS, wherein the first response message is used for indicating that the target service has been instantiated, and the first response message carries an identifier of an instance of the target service;

receiving a second response message sent by the PaaS, wherein the second response message is used for indicating that the target service is not instantiated, sending a service instantiation request to the PaaS, the service instantiation request carries an identifier of the target service, and receiving an instantiation response message sent by the PaaS, and the instantiation response message carries an identifier of an instance of the target service.

Specifically, the MANO entity may also obtain the identification of the instance of the target service in the above two ways before sending the configuration request. When the target service instance does not exist in the PaaS, the MANO entity may further obtain the identifier of the target service instance by sending an instantiation request.

Optionally, the MANO entity is a virtual network function manager VNFM in the NFV architecture.

In a third aspect, a PaaS management apparatus is provided, where the PaaS management apparatus has a function of implementing the behavior of the PaaS management method in the first aspect. The PaaS management apparatus includes at least one module, where the at least one module is configured to implement the PaaS management method provided in the foregoing first aspect.

In a fourth aspect, another PaaS management apparatus is provided, which has a function of implementing the behavior of the PaaS management method in the second aspect. The PaaS management apparatus includes at least one module, and the at least one module is configured to implement the PaaS management method provided in the second aspect.

In a fifth aspect, another PaaS management apparatus is provided, where the PaaS management apparatus includes a processor and a memory, and the memory is used for storing a program for the PaaS management apparatus to execute the PaaS management method provided in the first aspect, and storing data for implementing the PaaS management method provided in the first aspect. The processor is configured to execute programs stored in the memory. The operating means of the memory device may further comprise a communication bus for establishing a connection between the processor and the memory.

A sixth aspect provides another PaaS management apparatus, which includes a processor and a memory, wherein the memory is used for storing a program for the PaaS management apparatus to execute the PaaS management method provided by the second aspect, and storing data for implementing the PaaS management method provided by the second aspect. The processor is configured to execute programs stored in the memory. The operating means of the memory device may further comprise a communication bus for establishing a connection between the processor and the memory.

In a seventh aspect, a computer-readable storage medium is provided, where instructions are stored in the computer-readable storage medium, and when the instructions are executed on a computer, the instructions cause the computer to execute the PaaS management method according to the first aspect.

In an eighth aspect, another computer-readable storage medium is provided, in which instructions are stored, and when the instructions are executed on a computer, the instructions cause the computer to execute the PaaS management method according to the second aspect.

In a ninth aspect, there is provided a computer program product containing instructions which, when run on a computer, causes the computer to execute the PaaS management method according to the first aspect.

A tenth aspect provides a computer program product containing instructions which, when run on a computer, cause the computer to perform the method for PaaS management according to the second aspect.

The technical effects obtained by the third, fifth, seventh and ninth aspects are similar to the technical effects obtained by the corresponding technical means in the first aspect, and are not described herein again.

The technical effects obtained by the above fourth, sixth, eighth and tenth aspects are similar to the technical effects obtained by the corresponding technical means in the second aspect, and are not repeated here.

The beneficial effect that technical scheme that this application provided brought is:

in the application, a plurality of services are deployed on PaaS, and when the MANO entity determines that the target service tenant no longer needs to call the target service, a service configuration request for the target service is sent to the PaaS. Based on the service configuration request, the PaaS releases the contract binding relationship between the target service tenant and the target service, and terminates all the instances of the target service when determining that the contract binding relationship between other service tenants and the target service does not exist. Therefore, the service provided by the application is not required to be always on-line like a public service, so that resources occupied by the public service cannot be released for a long time, the dynamic availability of the resources on the PaaS platform is enhanced, meanwhile, the service provided by the application is not required to be terminated along with the termination of the instance of the service tenant like a proprietary service, the reusability of the instance of the service among a plurality of service tenants is improved, and the efficiency of the PaaS platform in managing the resources of the service is greatly improved.

Drawings

Fig. 1 is a schematic diagram of an NFV architecture provided in an embodiment of the present application;

fig. 2A is a schematic diagram of an NFV architecture with PaaS deployed according to an embodiment of the present application;

fig. 2B is a schematic structural diagram of PaaS provided in the embodiment of the present application;

fig. 3 is a flowchart of a PaaS management method provided in an embodiment of the present application;

fig. 4A is a block diagram of a PaaS management apparatus according to an embodiment of the present application;

fig. 4B is a block diagram of another PaaS management apparatus according to an embodiment of the present disclosure;

fig. 5A is a block diagram of another PaaS management apparatus according to an embodiment of the present application;

fig. 5B is a block diagram of another PaaS management apparatus according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

Before further detailed description of the embodiments of the present application, an application scenario of the embodiments of the present application is introduced.

Since the PaaS in the embodiment of the present application is deployed in the NFV architecture, the NFV architecture is introduced first. Fig. 1 is a schematic diagram of an NFV architecture according to an embodiment of the present application, where the NFV system architecture can be applied to various types of networks, such as an operator communication network or a local area network.

As shown in fig. 1, the NFV architecture mainly includes a MANO entity 110, an NFVI 120, a plurality of VNFs 130, a plurality of Element Management (EM) 140, and an Operation Support Management System (OSS/BSS) 150. The MANO entity 110 further includes a Network Function Virtualization Orchestrator (NFVO) 110a, one or more VNFMs 110b, and a Virtualized Infrastructure Manager (VIM) 110 c.

For convenience of description, the functions of the respective modules in the NFV architecture of fig. 1 are described next.

The NFVO 110a is configured to implement Network Service Descriptors (NSDs) and management and processing of virtual Network function Forwarding graphs (VNF Forwarding graphs, VNFFGs), management of a Network Service lifecycle, and implement the lifecycle management of the VNF and a global view function of virtual resources in cooperation with the VNFM.

The VNFM110b is used to implement lifecycle management of the VNF, including management of virtualized network function Descriptor (VNF Descriptor, VNFD) files, instantiation of the VNF, elastic Scaling of VNF instances (including Scaling out/up and Scaling in/down), healing (healing) of VNF instances, and termination of VNF instances. The VNFM also supports receiving a flexible scaling (scaling) strategy issued by the NFVO, and realizes automatic VNF flexible scaling.

The VIM 110b is responsible for managing (including reserving and allocating) hardware resources of an infrastructure layer, managing virtualized resources, monitoring and reporting a fault of a virtual resource state, and providing a virtualized resource pool to an upper-layer application.

OSS/BSS 150 refers to the operator's existing operation and maintenance system OSS/BSS.

The EM 140 is used to perform traditional Fault, Configuration, user, Performance and Security Management (FCAPS) functions for the VNF 130.

The VNF 130 corresponds to a Physical Network Function (PNF) in a conventional non-virtualized Network, such as a virtualized 4G Core Network (EPC) EPC node, such as a Mobility Management Entity (MME), a Serving Gateway (SGW), a Packet Data Network Gateway (PGW), and the like. The functional behavior and state of the network function are independent of virtualization, and the NFV technology is required to expect that VNF and PNF have the same functional behavior and external interface.

In addition, the VNF 130 may be composed of multiple VNF components (VNFCs), and thus, in practical applications, one VNF 130 may be deployed on multiple Virtual Machines (VMs), each VM carrying a function of one VNF Component. Of course, one VNF 130 may also be deployed on one VM.

The NFVI 120 is composed of hardware resources and virtual resources and a virtualization layer, which from the perspective of the VNF 130 appears to be a complete entity that can provide the required virtual resources.

In addition, the embodiments of the present application mainly implement a method for managing services in PaaS, and therefore, a simple description is also given here to a PaaS platform.

PaaS is a business model with a server platform as a service. For example, a type of PaaS is provided for a user by using a cloud computing platform or a development environment corresponding to the cloud computing era as a service. In addition, in a typical hierarchy of cloud computing, the PaaS layer is interposed between Software as a Service (SaaS) and Infrastructure as a Service (IaaS).

The PaaS platform has the following characteristics:

an application running environment: the system comprises a distributed computing operation environment, multiple types of data storage and dynamic resource scaling functions.

Application full lifecycle support: including providing Software Development Kit (SDK), Integrated Development Environment (IDE), and the like, to expedite Development, testing, and deployment of applications.

Public service: public services such as queue services, storage services, and cache services are provided in the form of Application Programming Interfaces (APIs).

Monitoring, managing and metering: the management and monitoring functions of the resource pool and the application system are provided, and accurate measurement is realized.

Integration, composite application building capability: including connectivity services, integration services, messaging services, and flow services, among others.

Moreover, with the continuous development of the NFV technology, the original VNF presentation form built on the basis of the NFVI layer VM incorporates new characteristics, and a Cloud architecture supporting Cloud-native (Cloud-native) VNF and integrating PaaS platform services will become a new trend of telecommunication Cloud development. The management method of the PaaS provided by the embodiment of the application is applied to the NFV architecture with the PaaS.

Fig. 2A is a schematic diagram of an NFV architecture with PaaS deployed according to an embodiment of the present application, and as shown in fig. 2A, as compared with the NFV architecture shown in fig. 1, the NVF architecture shown in fig. 2A further includes PaaS 160, where the PaaS 160 includes a plurality of services and PaaS management for managing the plurality of services.

The VNF 130 in the NFV architecture may implement instantiation of the VNF by calling a service in the PaaS 160.

In the NFV architecture, in addition to the VNF, other modules may also call services in PaaS, and for convenience of description, the modules that call the services in PaaS are collectively referred to as service tenants. That is, in the embodiment of the present application, the service tenant may be a VNF in the NFV architecture.

In addition, the PaaS deployed in the NFV architecture and the MANO entity in the NFV architecture are used to execute the PaaS management method provided in the embodiment of the present application, and specifically, the PaaS management in the PaaS and the MANO entity in the NFV architecture execute the PaaS management method provided in the embodiment of the present application.

The PaaS management may also be referred to as a PaaS management entity or a PaaS management plane, and the MANO entity may specifically be a VNFM in the NFV architecture.

Fig. 2B is a schematic structural diagram of PaaS provided in the embodiment of the present application. The functions of PaaS in fig. 2A may be implemented by the computer device shown in fig. 2B. Referring to fig. 2B, the computer device comprises at least one processor 201, a communication bus 202, a memory 203 and at least one communication interface 204.

The processor 201 may be a Central Processing Unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more ics for controlling the execution of programs in accordance with the present invention.

The communication bus 202 may include a path that conveys information between the aforementioned components.

The Memory 203 may be a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical Disc storage, optical Disc storage (including Compact Disc, laser Disc, optical Disc, digital versatile Disc, blu-ray Disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to these. The memory 203 may be self-contained and coupled to the processor 201 via the communication bus 202. The memory 203 may also be integrated with the processor 201.

The communication interface 204 may be any device, such as a transceiver, for communicating with other devices or communication Networks, such as ethernet, Radio Access Network (RAN), or Wireless Local Area Networks (WLAN).

In particular implementations, processor 201 may include one or more CPUs, such as CPU0 and CPU1 shown in fig. 2B, as one embodiment.

In particular implementations, a computer device may include multiple processors, such as processor 201 and processor 205 shown in FIG. 2B, as one embodiment. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In particular implementations, the computer device may also include an output device 206 and an input device 207, as one embodiment. The output device 206 is in communication with the processor 201 and may display information in a variety of ways. For example, the output device 206 may be a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display device, a Cathode Ray Tube (CRT) display device, a projector (projector), or the like. The input device 207 is in communication with the processor 201 and may receive user input in a variety of ways. For example, the input device 207 may be a mouse, a keyboard, a touch screen device, or a sensing device, among others.

The computer device may be a general purpose computer device or a special purpose computer device. In a specific implementation, the computer device may be a desktop computer, a laptop computer, a network server, a Personal Digital Assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. The embodiment of the application does not limit the type of the computer equipment.

The memory 203 is used for storing program codes for executing the scheme of the application, and the processor 201 controls the execution. The processor 201 is operable to execute program code 208 stored in the memory 203. One or more software modules may be included in program code 208.

The present embodiments also provide for the construction of a MANO entity that includes at least one processor, a communication bus, a memory, and at least one communication interface. The processor, communication bus, memory, and communication interface included in the MANO entity are substantially the same as those in fig. 2B, and thus, will not be described in detail herein.

Next, a method for managing PaaS provided in the embodiments of the present application will be explained in detail.

Fig. 3 is a flowchart of a PaaS management method provided in an embodiment of the present application, and is applied to the NFV architecture with a PaaS shown in fig. 2A, where as shown in fig. 2A, a plurality of services are deployed on the PaaS. Specifically, as shown in fig. 3, the method includes the steps of:

step 301: and the MANO entity sends a configuration request to the PaaS, wherein the configuration request carries the identification of the target service tenant and the identification of the target service instance.

In the embodiment of the present application, managing PaaS deployed in an NFV architecture mainly includes two aspects, a first aspect is instantiation of a service deployed in PaaS, and a second aspect is termination of the service deployed in PaaS. Wherein, steps 301 and 302 will be used to explain the content of the first aspect, and steps 303 to 305 will be used to explain the content of the second aspect.

It should be noted that, for a target service tenant in the NFV architecture, in order to ensure that an instance of the target service tenant can call an instance of a target service deployed on PaaS, after obtaining an identifier of the instance of the target service, a MANO entity needs to send a configuration request to PaaS, so that PaaS carries the identifier of the instance of the target service tenant and the identifier of the instance of the target service according to the configuration request, and establishes a usage binding relationship between the instance of the target service tenant and the instance of the target service.

And the identification of the target service tenant is used for uniquely identifying the target service instance.

Further, after the MANO entity sends the configuration request to the PaaS, in order to ensure that the instance of the target service tenant can smoothly call the instance of the target service, the MANO entity also needs to establish a usage binding relationship between the instance of the target service tenant and the instance of the target service.

In addition, the identification of the instance of the target service obtained by the MANO entity can be specifically realized by the following two possible implementation manners:

a first possible implementation:when the MANO entity determines that the instance of the target service tenant needs to call the target service, sending an instance acquisition request to the PaaS, wherein the instance acquisition request carries the identifier of the target service; the PaaS receives an instance acquisition request sent by a MANO entity, and when the instance of the target service exists currently, a first response message is sent to the MANO entity, wherein the first response message is used for indicating that the target service is instantiated, and the first response message carries the identifier of the instance of the target service.

It should be noted that, for any service deployed on PaaS, there may be multiple instances of the service, and the multiple instances may all be occupied by an instance of a service tenant, or there may be some instances that are not occupied by an instance of the service tenant. Therefore, when the MANO entity determines that the instance of the tenant of the target service needs to call the target service, an instance acquisition request for the target service may be sent to the PaaS first to determine whether an unoccupied instance of the target service exists in the PaaS.

That is, in the embodiment of the present application, when the MANO entity determines that the instance of the target service tenant needs to invoke the target service, the MANO entity sends an instance obtaining request for the target service to the PaaS, where the instance obtaining request carries the identifier of the target service. When receiving the instance acquisition request, the PaaS determines whether the instance of the target service currently exists according to the identifier of the target service, so as to send the identifier of the instance of the target service to the MANO entity according to a first possible implementation manner.

In addition, when the MANO entity receives the first reply message, because the MANO entity is an instance acquisition request sent to the PaaS when determining that the instance of the target service tenant needs to invoke the target service, the MANO entity can establish a usage binding relationship between the instance of the target service tenant and the instance of the target service according to the identifier of the instance of the target service carried by the first reply message, so that the instance of the target service tenant can invoke the instance of the target service.

Specifically, the instance obtaining request may be a life cycle state query request, where the first response message carries a life cycle state of the target service, and the life cycle state is instantiated, and is used to indicate that the target service has been instantiated and that an instance of the target service currently exists.

Optionally, the MANO entity may also determine whether the instance of the target service exists in the PaaS in other manners, for example, determine whether the instance of the target service exists in the PaaS in a subscription manner.

A second possible implementation:and when the MANO entity determines that the instance of the target service tenant needs to call the target service, sending an instance acquisition request to the PaaS, wherein the instance acquisition request carries the identifier of the target service. And the PaaS receives the instance acquisition request sent by the MANO entity, and sends a second response message to the MANO entity when the instance of the target service does not exist currently, wherein the second response message is used for indicating that the target service is not instantiated. And the MANO entity receives the second response message and sends a service instantiation request aiming at the target service to the PaaS, wherein the service instantiation request carries the identification of the target service. When the PaaS receives a service instantiation request sent by the MANO entity, the target service is accessed based on the identification of the target serviceAnd line instantiation is carried out to obtain the instance of the target service, and an instantiation response message is sent to the MANO entity, wherein the instantiation response message carries the identification of the instance of the target service.

In a second possible implementation manner, because the target service instance does not exist currently, the PaaS sends a second response message to the MANO entity, and when the MANO entity receives the second response message, it is determined that the target service instance does not exist in the current PaaS. At this time, in order that the instance of the target service tenant can call the target service, the MANO entity may send a service instantiation request for the target service to the PaaS to obtain the instance of the target service.

For example, when the instance obtaining request is a life cycle state query request, the second response message carries a life cycle state of the target service, and the life cycle state is not instantiated, and is used to indicate that the target service is not instantiated, that is, there is no unoccupied instance of the target service currently.

Specifically, the implementation manner of instantiating the target service by PaaS may be: the PaaS acquires the descriptor file of the target service from the stored descriptor file of the service, wherein the descriptor file of the target service is used for describing information required in the instantiation process of the target service. And the PaaS instantiates the target service according to the information required in the target service instantiation process in the descriptor file of the target service to obtain the instance of the target service.

The identifier of the target service carried in the instance acquisition request and the instantiation request is used for uniquely identifying the target service, and specifically, the identifier of the target service may be a name of the target service.

In addition, the information required in the target service instantiation process is preset information, and the information required in the target service instantiation process mainly comprises instance parameters, the number of instances or the scale when the target service is initially deployed. The PaaS instantiates the target service, that is, the PaaS completes configuration of the instance of the target service and allocation of resources according to the instance parameters, the number of instances, or the scale when the target service is initially deployed.

That is, in the embodiment of the present application, for any service deployed in PaaS, a descriptor file corresponding to the service is stored in the PaaS, and when the service needs to be instantiated, the service may be instantiated according to the descriptor file corresponding to the service.

As can be seen from the first possible implementation manner and the second possible implementation manner, after the MANO entity sends the instance obtaining request for the target service to the PaaS, regardless of whether the instance of the target service exists currently, the PaaS sends the identifier of the instance of the target service to the MANO entity after determining the instance of the target service, so as to ensure that the instance of the target service tenant can invoke the instance of the target service.

It should be noted that, the PaaS sends the identifier of the instance of the target service to the MANO entity may be an identifier of one instance of the target service, or may be identifiers of multiple instances of the target service, that is, the PaaS may be allocated to one or more instances of the target service by the target service tenant according to an actual situation, which is not specifically limited herein in the embodiment of the present application.

In addition, as can be seen from the first possible implementation manner and the second possible implementation manner, both the MANO entity and the PaaS send an instance acquisition request for a target service to the PaaS when it is determined that an instance of a target service tenant needs to invoke the target service.

The following two scenarios may exist when the MANO entity determines that the target service tenant needs to call the target service, that is, in the embodiment of the present application, the service in PaaS may be instantiated in the following two scenarios:

in the first scene, the first scene is,and the MANO entity establishes the identification of the example of the target service tenant, and determines that the example of the target service tenant needs to call the target service when determining that the service list used by the target service tenant comprises the target service.

It should be noted that, for any service tenant, there is a descriptor file corresponding to the service tenant, and the descriptor file will define users that the corresponding service tenant can call. In addition, the MANO entity, upon creating an identification of an instance of a service tenant, will invoke the instance of the service defined in the descriptor file in a process that is instantiated later.

Thus, when the MANO entity is creating the identity of the instance of the target service tenant, it may indicate that the target service tenant needs to invoke the instance of the target service.

That is, when the MANO entity creates the identifier of the instance of the target service tenant, according to the descriptor file of the target service tenant, the service that can be called by the target service tenant defined in the descriptor file is determined as the target service, and an instance acquisition request for the target service is sent to PaaS.

When receiving the instance acquisition request, the PaaS sends an identifier of the instance for the target service to the MANO entity according to the two possible implementation manners, so that the MANO entity sends a configuration request to the PaaS according to step 301 when receiving the identifier of the instance for the target service.

In scenario one, after completing creating the identifier of the target service tenant, when the target service tenant needs to instantiate the instance, the MANO entity may directly invoke the target service instance corresponding to the target service tenant instance according to the established usage binding relationship, so as to complete the instantiation process of the target service tenant instance.

Specifically, the MANO entity is a VNFM, and when the VNFM receives an instance identifier creation request of a target service tenant sent by NFVO or EM, the VNFM locally creates an instance identifier of the target service tenant, acquires an identifier of a target service that the target service tenant can call from a description service file of the target service tenant, and sends the instance acquisition request according to the identifier of the target service.

It should be noted that, in scenario one, the precondition for the MANO entity to send the instance acquisition request for the target service is as follows: the target service is registered in PaaS, and the service that the target service tenant can call is explicitly defined in the descriptor file of the target service tenant.

In the second scenario, the first scenario is,and when the MANO entity instantiates the instance of the target service tenant and determines that the service list used by the target service tenant comprises the target service, determining that the instance of the target service tenant needs to call the target service.

In scenario two, when creating the identifier of the instance of the target service tenant, the MANO entity does not send an instance acquisition request to the PaaS to obtain the instance of the target service as in scenario one, but sends an instance acquisition request for the target service that can be invoked by the target service tenant to the PaaS in the process of instantiating the instance of the target service tenant after creating the identifier of the instance of the target service tenant.

That is, after creating the identifier of the instance of the target service tenant, the MANO entity determines the descriptor file of the target service tenant when the instance of the target service tenant currently needs to be instantiated, determines the service defined in the descriptor file and that the target service tenant can call as the target service, and sends an instance acquisition request for the target service to PaaS.

When receiving the instance acquisition request, the PaaS may also send the identifier of the instance for the target service to the MANO entity according to the two possible implementation manners, so that the MANO entity sends the configuration request to the PaaS according to step 301 when receiving the identifier of the instance for the target service.

Obviously, in scenario two, the precondition for the MANO entity to send the instance acquisition request for the target service is as follows: the target service is registered in PaaS, the MANO entity creates the identification of the target service tenant's instance, and the services that the target service tenant can call are explicitly defined in the descriptor file of the target service tenant.

Step 302: the PaaS receives the configuration request, establishes a use binding relationship between the instance of the target service and the instance of the target service tenant based on the identifier of the instance of the target service tenant and the identifier of the instance of the target service carried by the configuration request, and establishes a contract binding relationship between the target service tenant and the target service when the target service tenant is determined not to exist in the tenant list of the target service.

When receiving the configuration request, the PaaS needs to establish a use binding relationship between the instance of the target service and the instance of the target service tenant in order to ensure that the instance of the target service tenant can call the instance of the target service.

That is, after the PaaS sends the identifier of the instance of the target service to the MANO entity, in order to ensure that the instance of the target service tenant can call the instance of the target service, both the PaaS and the MANO entity store the usage binding relationship between the instance of the target service tenant and the instance of the target service.

It is to be noted that, because different service tenants may invoke the same service, in the embodiment of the present invention, when a target service tenant instantiates the target service for the first time, that is, when the PaaS creates an instance of the first target service according to the target service tenant, the PaaS needs to establish a contract binding relationship between the target service tenant and the target service. And then, when the target service tenant instantiates the target service for the second time, the contract binding relationship between the target service tenant and the target service after the target service tenant is not required to be established. That is, when a contract binding relationship exists between a service and a service tenant, it indicates that the service tenant can invoke the service.

Therefore, when the PaaS receives the service configuration request and establishes the usage binding relationship between the instance of the target service and the instance of the target service tenant, it may be determined whether the instance of the target service is the instance when the target service tenant instantiates the target service for the first time, and if so, a contract binding relationship between the target service tenant and the target service needs to be established at this time.

It should be noted that, for any service deployed on PaaS, PaaS maintains a tenant list for the service, and the tenant list records an identifier of a service tenant that has invoked the service.

Therefore, when the PaaS establishes the usage binding relationship between the instance of the target service and the instance of the target service tenant, whether the target service tenant exists in the tenant list of the target service can be determined according to the identifier of the target service tenant, and if the target service tenant does not exist, the target service tenant establishes a contract binding relationship with the target service.

It should be noted that, as shown in step 302, two different binding relationships exist in the embodiment of the present application, a binding relationship and a contract binding relationship are used, and for avoiding confusion, the use relationship and the contract binding relationship are explained here:

for PaaS, in order to ensure that a service tenant can call a service, a corresponding relationship between the service tenant and the service needs to be established; in order to ensure that the instance of the service tenant can call the instance of the service, a corresponding relationship between the instance of the service tenant and the instance of the service needs to be established. Therefore, for convenience of explanation, the correspondence between a service tenant and a service is referred to as a contract binding relationship between the service tenant and the service, and the correspondence between an instance of the service tenant and an instance of the service is referred to as a usage binding relationship between an instance of the service tenant and an instance of the service. That is, a contract binding relationship is established between the service tenant and the service, and a usage binding relationship is established between the instance of the service tenant and the instance of the service.

Since a service tenant usually has multiple instances, and a service also usually has multiple instances, the contractual binding relationship can only indicate that there is an instance of the service tenant's instance calling the service, but cannot indicate which instance of the service tenant specifically calls the instance of the service, and the use of the binding relationship can clearly indicate which instance of the service tenant calls the instance of the service.

For example, for the target service tenant and the target service, if the target service tenant has three instances, which are a1, a2 and A3, the target service also has three instances, which are B1, B2 and B3, and the current instance of the target service invoked by a1 is B1, the instance of the target service invoked by a2 is B2, and the instance of the target service invoked by A3 is B3. At this time, in PaaS, only one contract binding relationship exists between the target service tenant and the target service, that is, the contract binding relationship between the target service tenant and the target service. There are three usage bindings, respectively, a usage binding between a1 and B1, a2 and B2, and A3 and B3.

The

above steps

301 and 302 are used to describe an instantiation process of a service provided in the embodiment of the present application, and a termination process of the service provided in the embodiment of the present application will be described below through steps 303 to 305.

Step 303: and when the MANO entity determines that the target service tenant in the NFV architecture does not call the target service any more, sending a service configuration request aiming at the target service to the PaaS.

In the embodiment of the present application, in order to avoid the termination of the service due to the termination of the service tenant calling the service, when the MANO entity determines that the target service tenant no longer needs to call the target service, in order to terminate the target service, the MANO entity needs to first send a service configuration request for the target service to the PaaS, so that the PaaS determines whether the target service needs to be terminated according to specific conditions, so as to implement the termination of the target service as needed.

It should be noted that the MANO entity may determine that the target service tenant no longer needs to invoke the target service in the following two scenarios, that is, in the embodiment of the present application, the target service may need to be terminated in the following two scenarios.

Scene one:when the descriptor file of the target service tenant is updated, since the descriptor file of the target service tenant defines the services that the target service tenant can call, when the descriptor file of the target service tenant is updated, it may be necessary to terminate the services that the target service tenant can call.

Specifically, when the MANO entity determines that the descriptor file of the target service tenant is updated, the descriptor file of the target service tenant after the update is acquired. And when the MANO entity determines that the target service needs to be deleted from the service list used by the target service tenant according to the updated descriptor file of the target service tenant, sending a service configuration request to the PaaS.

At this time, since the target service needs to be deleted from the service list used by the target service tenant, that is, the target service tenant will not call the target service again, the MANO entity needs to request PaaS to release the contract binding relationship between the target service tenant and the target service.

In practical application, in order to distinguish service configuration requests in different scenes, the service configuration requests carry configuration types. Therefore, in scenario one, the configuration type carried by the service configuration request is contract release, and the service configuration request also carries the identifier of the target service tenant and the identifier of the target service, so that the PaaS releases the contract binding relationship between the target service tenant and the target service according to the service configuration request.

Specifically, when the target service tenant is a VNF, the identifier of the target service tenant may be a name of the VNF.

For example, when a VNF vendor updates a descriptor file of a VNF, after acquiring the updated descriptor file, if it is determined that a certain service needs to be deleted from a service list of the VNF according to the updated descriptor file, the VNFM determines the service that needs to be deleted as a target service, and sends a service configuration request in scenario one to PaaS. The service configuration request carries a configuration type, an identifier of the VNF, and an identifier of a service that needs to be deleted, where the configuration type is a release contract.

Scene two:when the MANO entity deletes the identity of the instance of the target service tenant, it indicates the instance of the target service tenant that will no longer be invoked, so when deleting the instance of the target service tenant, it may be necessary to terminate the target service.

It should be noted that, in scenario two, since only the identifier of the instance of the target service tenant needs to be deleted, it is only indicated that this instance of the target service tenant no longer invokes the target service, but it cannot represent that other instances of the target service tenant do not invoke the target service any more. Therefore, in order to avoid that the target service cannot be continuously called by other instances of the target service tenant as a result of immediately terminating the target service by the PaaS, a delay time is set for the target service tenant, and the delay time is a time when the PaaS delays releasing the contract binding relationship between the target service tenant and the target service.

For any service tenant, the descriptor file of the service tenant comprises preset lag time.

Therefore, when the MANO entity needs to delete the identifier of the target service tenant, the descriptor file of the target service tenant is obtained; and determining the lag time according to the descriptor file of the target service tenant, and sending a service configuration request to the PaaS.

At this time, since only the identifier of the instance of the target service tenant needs to be deleted, it is only indicated that this instance of the target service tenant no longer calls the target service, but other instances that do not represent the target service tenant no longer call the target service. Therefore, the MANO entity only needs to request PaaS to release the use binding relationship between the instance of the target service tenant and the instance of the target service.

That is, in scenario two, the configuration type carried by the service configuration request is to be removed from use, and the service configuration request also carries the identifier of the instance of the target service tenant, the identifier of the instance of the target service, and the hysteresis time.

For example, when a VNFM in the NFV architecture receives an instance identifier deletion request for a certain VNF sent by an NFVO or EM, the VNFM locally deletes the identifier of the VNF instance, and sends a service configuration request for the VNF to PaaS according to a service list of the VNF. The service configuration request carries a configuration type, an identifier of an instance of the VNF, an identifier of an instance of a service invoked by the instance of the VNF, and a hysteresis time, wherein the configuration type is to be decommissioned.

Step 304: and the PaaS receives a service configuration request aiming at the target service and sent by the MANO entity, and releases the contract binding relationship between the target service tenant and the target service based on the service configuration request.

As shown in step 303, the MANO entity may send a service configuration request for the target service to the PaaS in two different scenarios, and accordingly, step 304 is also specifically divided into the following two cases:

for scenario one in step 303:when receiving the service configuration request of the target service, the PaaS may find, according to the identifier of the target service tenant and the identifier of the target service carried by the service configuration request, a contract binding relationship between the target service tenant and the target service that has been established, and release the contract binding relationship between the target service tenant and the target service, because the configuration type carried by the service configuration request is a contract release.

After releasing the contract binding relationship between the target service tenant and the target service, PaaS also needs to send a first type of service configuration response message to the MANO entity, where the first type of service configuration response message is used to indicate that the contract binding relationship between the target service tenant and the target service tenant has been released.

That is, when the MANO entity receives the first-class service configuration response message, it is determined that the PaaS has released the contractual binding relationship between the target service and the target service tenant.

For scenario two in step 303:when receiving the service configuration request of the target service, the PaaS may find, according to the identifier of the instance of the target service tenant and the identifier of the instance of the target service carried by the service configuration request, the use binding relationship between the established instance of the target service tenant and the instance of the target service, and release the use binding relationship, because the configuration type carried by the service configuration request is release.

After the PaaS releases the usage binding relationship between the instance of the target service tenant and the instance of the target service, the PaaS also needs to send a second type of service configuration response message to the MANO entity, where the second type of service configuration response message is used to indicate that the usage binding relationship between the instance of the target service tenant and the instance of the target service tenant has been released.

That is, when the MANO entity receives the second type service configuration response message, it is determined that PaaS has released the usage binding relationship between the instance of the target service and the instance of the target service tenant.

In the second scenario, the MANO entity service configuration request further includes a lag time, so that, after the binding relationship between the instance of the target service and the instance of the target service tenant is released, in order to avoid that other instances of the target service tenant cannot continue to call the target service because the target service is immediately terminated by the PaaS, the PaaS may start timing, where the timing time is the lag time, and determine whether the target service tenant calls the target service again within the lag time. If the target service tenant does not call the target service any more within the lag time after the current time, at this time, PaaS may release the contract binding relationship between the target service tenant and the target service, and determine whether the target service needs to be terminated according to the following step 305.

Accordingly, if the target service tenant calls the target service within the delay time after the current time, at this time, PaaS does not need to release the contract binding relationship between the target service tenant and the target service, that is, PaaS will not terminate the target service.

Step 305: and when the PaaS determines that no contract binding relationship exists between other service tenants in the NFV architecture and the target service, terminating all the instances of the target service.

In the embodiment of the present application, to avoid a situation that the proprietary service needs to be instantiated each time the service is called because the instance of the service terminates with the termination of the instance of the VNF calling the service. When the PaaS releases the contract binding relationship between the target service tenant and the target service according to step 304, the PaaS does not immediately terminate the target service, but first determines whether there is another service tenant that needs to call the target service.

If there are still other service tenants that need to invoke the target service, if the target service is directly terminated at this time, the other service tenants need to instantiate the target service again while continuing to invoke the target service. Therefore, in the embodiment of the present application, PaaS will not terminate the target service immediately, but will terminate the target service when PaaS determines that there is no other service tenant that needs to call the target service.

Specifically, the PaaS may determine whether there is a service tenant that needs to call the target service by judging whether there is another service tenant that has a contract binding relationship with the target service currently, that is, when there is no another service tenant that has a contract binding relationship with the target service currently, it is determined that there is no another service tenant that needs to call the target service, and at this time, the PaaS terminates the target service.

Accordingly, when there is another service tenant having a contract binding relationship with the target service, the PaaS will not terminate the target service.

The PaaS terminates the target service, that is, the PaaS deletes all instances of the target service and releases resources occupied by all instances of the target service.

In the embodiment of the application, a plurality of services are deployed on PaaS, and when the MANO entity determines that the target service tenant does not need to call the target service any more, a service configuration request for the target service is sent to the PaaS. Based on the service configuration request, the PaaS releases the contract binding relationship between the target service tenant and the target service, and terminates all the instances of the target service when determining that the contract binding relationship between other service tenants and the target service does not exist. Therefore, the service provided by the application is not required to be always on-line like a public service, so that resources occupied by the public service cannot be released for a long time, the dynamic availability of the resources on the PaaS platform is enhanced, and meanwhile, the service provided by the application is not required to be terminated along with the termination of the instance of the service tenant like a proprietary service, so that the reusability of the instance of the service among a plurality of service tenants is improved, and the efficiency of the PaaS platform in managing the resources of the service is greatly improved.

Referring to fig. 4A, an embodiment of the present application provides a PaaS management apparatus 400, which is applied to a PaaS deployed in an NFV architecture, where the PaaS is deployed with a plurality of services, and the apparatus 400 includes a first receiving module 401, a releasing module 402, and a terminating module 403:

a first receiving module 401, configured to execute the step of receiving, by the PaaS, the service configuration request for the target service sent by the MANO entity in step 304 in the embodiment of fig. 3;

a release module 402, configured to perform the step of releasing the contract binding relationship between the target service tenant and the target service based on the service configuration request in step 304 in the embodiment of fig. 3;

a terminating module 403, configured to execute step 305 in the embodiment in fig. 3.

Optionally, the apparatus 400 further comprises:

and a third sending module, configured to send a first type of service configuration response message to the MANO entity, where the first type of service configuration response message is used to indicate that the contract binding relationship between the target service and the target service tenant has been released.

Optionally, the service configuration request carries a configuration type, an identifier of an instance of the target service tenant, an identifier of an instance of the target service, and a delay time, where the configuration type is to be released from use;

accordingly, the releasing module 402 is specifically configured to:

when the target service tenant is determined not to call the target service again within the lag time after the current time, releasing the contractual binding relationship between the target service and the target service tenant.

Optionally, the apparatus 400 further comprises:

and a fourth sending module, configured to send a second type of service configuration response message to the MANO entity, where the second type of service configuration response message is used to indicate that the usage binding relationship between the instance of the target service and the instance of the target service tenant has been released.

Optionally, referring to fig. 4B, the apparatus 400 further includes a second receiving module 404 and a establishing module 405:

a second receiving module 404, configured to execute the step of receiving, by PaaS, the configuration request in step 302 in the embodiment of fig. 3;

an establishing module 405, configured to execute the step 302 in the embodiment of fig. 3, that is, based on the identifier of the instance of the target service tenant and the identifier of the instance of the target service carried in the configuration request, establish a usage binding relationship between the instance of the target service and the instance of the target service tenant, and establish a contract binding relationship between the target service tenant and the target service when it is determined that the target service tenant does not exist in the tenant list of the target service.

Optionally, the apparatus 400 further includes a third receiving module, a first sending module, and a second sending module:

a third receiving module, configured to receive an instance obtaining request sent by the MANO entity, where the instance obtaining request carries an identifier of the target service;

a first sending module, configured to send a first response message to the MANO entity when it is determined that the instance of the target service exists based on the identifier of the target service, where the first response message is used to indicate that the target service has been instantiated, and carries the identifier of the instance of the target service;

a second sending module, configured to send a second response message to the MANO entity when it is determined that the target service instance does not exist based on the identifier of the target service, where the second response message is used to indicate that the target service is not instantiated, receive a service instantiation request sent by the MANO entity, where the service instantiation request carries the identifier of the target service, instantiate the target service based on the identifier of the target service to obtain the target service instance, and send an instantiation response message to the MANO entity, where the instantiation response message carries the identifier of the target service instance.

Optionally, the second sending module is specifically configured to:

and instantiating the target service according to the information required in the instantiation process of the target service in the descriptor file of the target service to obtain the instance of the target service.

Referring to fig. 5A, an embodiment of the present application provides another management apparatus 500 for PaaS, which is applied to an MANO entity in an NFV architecture, where the PaaS is deployed in the NFV architecture, and the apparatus 500 includes a first sending module 501:

a first sending module 501, configured to perform step 303 in the embodiment of fig. 3;

the service configuration request is used for indicating that the PaaS releases the contract binding relationship between the target service tenant and the target service based on the service configuration request, and terminating all instances of the target service when determining that the contract binding relationship between other service tenants and the target service does not exist, wherein the target service is any one of the plurality of services.

Optionally, the first sending module 501 is specifically configured to:

when the descriptor file of the target service tenant is determined to be updated, acquiring the updated descriptor file of the target service tenant;

and when determining that the target service needs to be deleted from the service list used by the target service tenant according to the updated descriptor file of the target service tenant, sending a service configuration request to the PaaS, wherein the service configuration request carries a configuration type, an identifier of the target service tenant and an identifier of the target service, and the configuration type is contract release.

Optionally, the apparatus 500 further comprises a third receiving module:

a third receiving module, configured to receive a first type of service configuration response message sent by the PaaS, where the first type of service configuration response message is used to indicate that a contract binding relationship between the target service and the target service tenant has been released.

Optionally, the first sending module 501 is specifically configured to:

and sending the service configuration request to the PaaS, wherein the service configuration request carries a configuration type, an identifier of an instance of the target service tenant, an identifier of an instance of the target service and the delay time, and the configuration type is release.

Optionally, the apparatus 500 further includes a fourth receiving module:

a fourth receiving module, configured to receive a second type of service configuration response message sent by the PaaS, where the second type of service configuration response message is used to indicate that the usage binding relationship between the instance of the target service and the instance of the target service tenant has been released.

Optionally, referring to fig. 5B, the apparatus 500 further includes a second sending module 502:

a second sending module 502, configured to execute step 301 in the embodiment of fig. 3.

Optionally, the apparatus 500 further includes a third sending module, a first receiving module, and a second receiving module:

a third sending module, configured to send an instance obtaining request to the PaaS when it is determined that the instance of the target service tenant needs to call a target service, where the instance obtaining request carries an identifier of the target service;

a first receiving module, configured to receive a first response message sent by the PaaS, where the first response message is used to indicate that the target service has been instantiated, and the first response message carries an identifier of an instance of the target service;

a second receiving module, configured to receive a second response message sent by the PaaS, where the second response message is used to indicate that the target service is not instantiated, send a service instantiation request to the PaaS, where the service instantiation request carries an identifier of the target service, and receive an instantiation response message sent by the PaaS, where the instantiation response message carries an identifier of an instance of the target service.

It should be noted that: in the case of managing services on PaaS, the management apparatus for PaaS provided in the foregoing embodiment is only illustrated by dividing the functional modules, and in practical applications, the functions may be distributed by different functional modules as needed, that is, the internal structure of the device may be divided into different functional modules to complete all or part of the functions described above. In addition, the PaaS management apparatus provided in the foregoing embodiment and the PaaS management method embodiment in the embodiment in fig. 3 belong to the same concept, and details of a specific implementation process thereof are referred to in the method embodiment, and are not described herein again.

In the above embodiments, the implementation may be wholly or partly realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website, computer, server, or data center to another website, computer, server, or data center via wire (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., Digital Versatile Disk (DVD)), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above-mentioned embodiments are provided not to limit the present application, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A platform as a service (PaaS) management method is applied to a PaaS deployed in a Network Function Virtualization (NFV) architecture, and is characterized in that a plurality of services are deployed on the PaaS, and the method comprises the following steps:

receiving a service configuration request aiming at a target service sent by a MANO entity of a management and orchestration function in the NFV architecture, wherein the service configuration request is sent by the MANO entity when determining that a target service tenant in the NFV architecture does not call the target service any more, and the target service is any one of the plurality of services;

2. The method of claim 1, wherein the service configuration request carries a configuration type, an identification of the target service tenant, and an identification of the target service, the configuration type being a decompaction.

3. The method of claim 2, wherein said releasing the contractual binding relationship between the target service tenant and the target service based on the service configuration request comprises:

and searching a contract binding relationship between the target service tenant and the target service according to the identifier of the target service tenant and the identifier of the target service, and releasing the contract binding relationship between the target service tenant and the target service.

4. The method of claim 1, wherein the service configuration request carries a configuration type, an identification of an instance of the target service tenant, an identification of an instance of the target service, and a lag time, the configuration type being decommissioning;

5. The method of claim 1, wherein prior to receiving the service configuration request for the target service sent by the MANO entity in the NFV architecture, further comprising:

6. The method of claim 5, wherein said receiving a configuration request sent by said MANO entity further comprises, prior to said receiving:

7. The method of claim 6, wherein instantiating the target service based on the identification of the target service, resulting in the instance of the target service, comprises:

8. A platform as a service (PaaS) management method is applied to a management and orchestration function (MANO) entity in a Network Function Virtualization (NFV) architecture, wherein the NFV architecture is provided with the PaaS, and is characterized in that a plurality of services are deployed on the PaaS, and the method comprises the following steps:

9. The method of claim 8, wherein the sending a service configuration request for a target service to the PaaS upon determining that a target service tenant in the NFV architecture is no longer invoking the target service comprises:

10. The method of claim 8, wherein the sending a service configuration request for a target service to the PaaS upon determining that a target service tenant in the NFV architecture is no longer invoking the target service comprises:

11. The method of claim 8, wherein prior to sending the service configuration request for the target service to the PaaS, further comprising:

12. The method of claim 11, wherein prior to sending the configuration request to the PaaS, further comprising:

13. A management apparatus of a platform as a service, PaaS, applied to a PaaS deployed in a network function virtualization, NFV, architecture, where the PaaS has a plurality of services deployed thereon, the apparatus comprising:

a first receiving module, configured to receive a service configuration request for a target service sent by a MANO entity that is a management and orchestration function in the NFV architecture, where the service configuration request is sent by the MANO entity when it is determined that a target service tenant in the NFV architecture no longer calls the target service, and the target service is any one of the multiple services;

a release module, configured to release a contract binding relationship between the target service tenant and the target service based on the service configuration request, where the contract binding relationship is used to indicate that the target service tenant can invoke the target service;

a terminating module, configured to terminate all instances of the target service when it is determined that there is no contract binding relationship between the target service and other service tenants in the NFV framework.

14. The apparatus of claim 13, wherein the service configuration request carries a configuration type, an identification of the target service tenant, and an identification of the target service, the configuration type being a decompaction.

15. The apparatus of claim 14, wherein the decommissioning module is specifically configured to: and searching a contract binding relationship between the target service tenant and the target service according to the identifier of the target service tenant and the identifier of the target service, and releasing the contract binding relationship between the target service tenant and the target service.

16. The apparatus of claim 13, wherein the service configuration request carries a configuration type, an identification of an instance of the target service tenant, an identification of an instance of the target service, and a lag time, the configuration type being decommissioning;

correspondingly, the release module is specifically configured to:

17. The apparatus of claim 13, wherein the apparatus further comprises:

a second receiving module, configured to receive a configuration request sent by the MANO entity, where the configuration request carries an identifier of an instance of the target service tenant and an identifier of an instance of the target service;

the establishing module is used for establishing a use binding relationship between the instance of the target service tenant and the instance of the target service based on the identifier of the instance of the target service tenant and the identifier of the instance of the target service, and establishing a contract binding relationship between the target service tenant and the target service when the target service tenant is determined not to exist in the tenant list of the target service.

18. The apparatus of claim 17, wherein the apparatus further comprises:

a first sending module, configured to send a first response message to the MANO entity when it is determined that the instance of the target service exists based on the identifier of the target service, where the first response message is used to indicate that the target service has been instantiated, and carries an identifier of the instance of the target service;

19. The apparatus of claim 18, wherein the second sending module is specifically configured to:

20. A management device of platform as a service (PaaS) is applied to a management and orchestration function (MANO) entity in a Network Function Virtualization (NFV) architecture, wherein the NFV architecture is provided with the PaaS, and a plurality of services are deployed on the PaaS, and the management device comprises:

a first sending module, configured to send a service configuration request for a target service to the PaaS when it is determined that a target service tenant in the NFV architecture no longer calls the target service;

21. The apparatus of claim 20, wherein the first sending module is specifically configured to:

22. The apparatus of claim 20, wherein the first sending module is specifically configured to:

23. The apparatus of claim 20, wherein the apparatus further comprises:

a second sending module, configured to send a configuration request to the PaaS, where the configuration request carries an identifier of an instance of the target service tenant and an identifier of an instance of the target service, and the configuration request is used to instruct the PaaS to establish a usage binding relationship between the instance of the target service tenant and the instance of the target service.

24. The apparatus of claim 23, wherein the apparatus further comprises:

a third sending module, configured to send an instance obtaining request to the PaaS when it is determined that an instance of the target service tenant needs to call a target service, where the instance obtaining request carries an identifier of the target service;