CN111240868B

CN111240868B - Instance processing and calling method, device, system and storage medium

Info

Publication number: CN111240868B
Application number: CN202010075629.8A
Authority: CN
Inventors: 李波; 郑晓; 龙欣
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2020-01-22
Filing date: 2020-01-22
Publication date: 2024-04-02
Anticipated expiration: 2040-01-22
Also published as: CN111240868A

Abstract

The embodiment of the application provides an example processing and calling method, equipment, a system and a storage medium. In the embodiment of the application, for the first instance and the second instance with the dependency relationship, the service binding relationship can be dynamically and flexibly established between the first instance and the second instance, and based on the service binding relationship, the first instance can initiate a call to the second instance to enable the second instance to provide services for the second instance, so that the second instance does not need to be deployed together with the first instance by taking the first instance as a host due to the dependency relationship, loose coupling between the instances is realized, and the service elasticity and flexibility of the instances are improved.

Description

Instance processing and calling method, device, system and storage medium

Technical Field

The embodiment of the application relates to the technical field of cloud computing, in particular to an example processing and calling method, equipment, a system and a storage medium.

Background

In the cloud network, a user can create own examples, and corresponding services are provided to the outside through the examples. In many cases, one instance often needs to use other services or instances in order to improve quality of service and performance. For example, the elastic reasoning instance requires the use of an accelerator service to increase the efficiency of the elastic reasoning service.

For instance a that needs to rely on other services or instances, in order to ensure that instance a can function properly, instance a needs to be the hosting instance of the other services or instances that it depends on, and the other services or instances that it depends on are created with instance a and released with instance a. This limits the service resilience and flexibility of other services or instances.

Disclosure of Invention

Aspects of the present application provide an instance processing and invoking method, device, system, and storage medium, which are used to implement loose coupling between instances, and improve service flexibility and flexibility of the instances.

An embodiment of the present application provides an instance management system, including: a client and a server; the client is deployed on the side of the first instance, and the server is deployed on the side of the second instance;

the server is configured to establish a service binding relationship between the first instance and the second instance according to the unique information of the first instance when the first instance needs to bind the second instance;

and the client is used for sending a remote call request to the server based on the service binding relation under the condition that the first instance needs to remotely call the second instance, so that the server can call the second instance to provide services for the first instance.

The embodiment of the application also provides an example processing method, which is suitable for the server, and comprises the following steps: determining that the first instance needs to bind the second instance; and establishing a service binding relation between the first instance and the second instance according to the unique information of the first instance.

The embodiment of the application also provides an example calling method, which is suitable for the client, and comprises the following steps: determining that a first instance needs to remotely call a second instance, wherein a service binding relationship is established between the first instance and the second instance; a remote call request is initiated to a server according to the service binding relation, so that the server calls the second instance to provide service for the first instance; and receiving a service result provided by the second instance returned by the service end for the first instance.

The embodiment of the application also provides a server device, which comprises: a memory and a processor; the memory is used for storing a computer program; the processor, coupled to the memory, is configured to execute the computer program for: determining that the first instance needs to bind the second instance; and establishing a service binding relation between the first instance and the second instance according to the unique information of the first instance.

The present embodiments also provide a computer readable storage medium storing a computer program, which when executed by a processor causes the processor to implement steps in an example processing method provided by the embodiments of the present application.

The embodiment of the application also provides a client device, which comprises: a memory and a processor; the memory is used for storing a computer program; the processor, coupled to the memory, is configured to execute the computer program for: determining that a first instance needs to remotely call a second instance, wherein a service binding relationship is established between the first instance and the second instance; a remote call request is initiated to a server according to the service binding relation, so that the server calls the second instance to provide service for the first instance; and receiving a service result provided by the second instance returned by the service end for the first instance.

The present embodiments also provide a computer readable storage medium storing a computer program, which when executed by a processor causes the processor to implement steps in an instance calling method provided by the embodiments of the present application.

In the embodiment of the application, for the first instance and the second instance with the dependency relationship, the service binding relationship can be dynamically and flexibly established between the first instance and the second instance, and based on the service binding relationship, the first instance can initiate a call to the second instance to enable the second instance to provide services for the second instance, so that the second instance does not need to be deployed together with the first instance by taking the first instance as a host due to the dependency relationship, loose coupling between the instances is realized, and the service elasticity and flexibility of the instances are improved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:

FIG. 1 is a schematic diagram of an example management system according to an exemplary embodiment of the present application;

FIG. 2a is a schematic diagram of a system for managing accelerator instances according to an exemplary embodiment of the present application;

FIG. 2b is a flow diagram of an example binding and call provided by an exemplary embodiment of the present application;

FIG. 2c is a schematic diagram of the isolation status of an ECS instance and an EAI instance based on a VPC implementation and the instance creation and service invocation flow provided by an exemplary embodiment of the present application;

FIG. 2d is a detailed flow chart of the embodiment of FIG. 2c for invoking the EAI acceleration service;

FIG. 3 is a flow chart of an example processing method according to an exemplary embodiment of the present application;

FIG. 4 is a flow chart of an example calling method provided in an exemplary embodiment of the present application;

fig. 5 is a schematic structural diagram of a server device according to an exemplary embodiment of the present application;

fig. 6 is a schematic structural diagram of a client device according to an exemplary embodiment of the present application.

Detailed Description

For the purposes, technical solutions and advantages of the present application, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

In the prior art, for an instance that needs to rely on other instances, a host instance is needed as the instance on which it depends, deployed and released along with the instance on which it depends, which can limit the service resilience and flexibility of other services or instances. Aiming at the technical problem, in some embodiments of the present application, for a first instance and a second instance having a dependency relationship, a service binding relationship can be dynamically and flexibly established between the first instance and the second instance, and based on the service binding relationship, the first instance can initiate a call to the second instance to enable the second instance to provide services for the second instance, so that the second instance does not need to be deployed together with the first instance by taking the first instance as a host due to the dependency relationship, loose coupling between the instances is realized, and service elasticity and flexibility of the instances are improved.

The following describes in detail the technical solutions provided by the embodiments of the present application with reference to the accompanying drawings.

Fig. 1 is a schematic structural diagram of an example management system according to an exemplary embodiment of the present application. As shown in fig. 1, the system includes: a client 11 and a server 12. Wherein the client 11 is disposed at the first instance side; the server 12 is disposed on the second instance side. The client 11 and the server 12 are communicatively connected.

In this embodiment, there is a dependency relationship between the first instance and the second instance, that is, the second instance may provide services for the first instance, and the first instance may use services provided by the second instance. Any instance with a dependency relationship may be used as the first instance and the second instance in the embodiments of the present application.

In this embodiment, the service content, the type, and the source of the first instance and the second instance are not limited. Examples from the service content point of view: the first instance may be an elastic computing service (Elastic Compute Service, ECS) instance that provides elastic reasoning, transcoding, or desktop rendering services; accordingly, the second instance may be a flexible accelerator instance to provide acceleration services for ECS instances that provide flexible reasoning, transcoding, or desktop rendering services. From a source perspective, examples are: the first instance or the second instance may be an instance in a public cloud, a private cloud, an edge cloud, or a hybrid cloud, or the like, and of course, may also be an instance on a private device of a user.

It should be noted that, there is a dependency between the first instance and the second instance, and the second instance may be determined according to the first instance, or the first instance may be determined according to the second instance. If the second instance is determined based on the first instance, then the second instance may be different from the first instance. If the first instance is determined based on the second instance, the first instance that can be serviced by the different second instance will also be different.

Whether the first instance is the second instance determined based on the first instance or the first instance determined based on the second instance, in this embodiment, the client 11 is deployed on the first instance side, and the server 12 is deployed on the second instance side. The server 12 is mainly responsible for dynamically establishing a service binding relationship between the first instance and the second instance, and the client 11 is mainly responsible for initiating a call to the second instance based on the service binding relationship between the first instance and the second instance, so as to achieve the purpose that the first instance successfully uses the service provided by the second instance.

It should be noted that, the server 12 may be deployed on the same physical device B as the second instance, as shown in fig. 1; of course, the server 12 may also be deployed near the second instance, but on a different physical device than the second instance. Similarly, the client 11 may be deployed on the same physical device a as the first instance, as shown in fig. 1; of course, the client 11 may also be deployed near the first instance, but on a different physical device than the first instance.

Wherein the primary purpose of establishing a service binding relationship between a first instance and a second instance is to bind the second instance to the first instance, in which process it is necessary to ensure that the second instance is bound to the first instance and not to other instances. Based on this, the server 12 may determine whether the first instance needs to bind the second instance, and in the case that the first instance needs to bind the second instance, establish a service binding relationship between the first instance and the second instance according to the unique information of the first instance.

The unique information of the first instance may be any information that the first instance uniquely has, and the information may uniquely identify the first instance enough to distinguish the first instance from other instances, for example, may be a MAC address, an IP address, an ID, a name, or the like of the first instance. Wherein, the service binding relation between the first instance and the second instance is established according to the unique information of the first instance, so that the second instance can be ensured to be bound to the first instance, and the second instance is prevented from being bound to other instances by mistake.

Alternatively, to establish a service binding relationship between the first instance and the second instance, the server 12 may establish a correspondence between the unique information of the first instance and the unique information of the second instance, or may store the unique information of the first instance into a binding relationship list or legal group of the second instance. Wherein the list of binding relationships or the legal group is used to store the unique information of other instances establishing service binding relationships with the second instance.

After establishing the service binding relationship between the first instance and the second instance, the first instance may use the service provided by the second instance. In this embodiment, the client 11 is deployed at the first instance side, where the client 11 is mainly configured to determine whether the first instance needs to remotely invoke the second instance, and send a remote invocation request to the server 12 based on the service binding relationship between the first instance and the second instance established by the server 12 when the first instance needs to remotely invoke the second instance, so that the server 12 invokes the second instance to provide services for the first instance.

The server 12 may also receive a remote call request sent by the client 11, call the second instance to provide a service for the first instance according to the remote call request, and return a service result provided by the second instance for the first instance to the client 11, so as to achieve the purpose that the first instance successfully uses the service provided by the second instance.

Therefore, in this embodiment, the server may dynamically and flexibly establish a service binding relationship between the first instance and the second instance according to the binding requirement of the first instance on the second instance, and then the client initiates a call to the second instance based on the service binding relationship, so that the first instance may successfully use the service provided by the second instance. For the second instance, the first instance is not required to be deployed with the first instance as a host because of the dependency relationship with the first instance, the second instance can be independently deployed, the coupling degree between the first instance and the second instance is reduced, loose coupling between the instances is realized, and the service elasticity and flexibility of the second instance are improved.

In some optional embodiments of the present application, the server 12 may, in addition to establishing a service binding relationship between the first instance and the second instance, flexibly release the service binding relationship between the first instance and the second instance as required. For the second service end 12, it may be determined whether the service binding between the first instance and the second instance needs to be released, and in the case that the service binding between the first instance and the second instance needs to be released, the service binding between the first instance and the second instance is released.

Optionally, if the server 12 establishes a correspondence between the unique information of the first instance and the unique information of the second instance in the process of establishing the service binding relationship, the server 12 needs to delete the correspondence between the unique information of the first instance and the unique information of the second instance in the process of releasing the service binding relationship. If the server 12 stores the unique information of the first instance in the binding list or legal group of the second instance in the process of establishing the service binding relationship, the server 12 needs to delete the unique information of the first instance from the binding list or legal group of the second instance in the process of releasing the service binding relationship.

In the embodiment of the present application, the specific implementation manner of the service end 12 in determining whether the second instance needs to be bound or not and in determining whether the service binding relation needs to be released or not is not limited. The following is illustrative:

in an alternative embodiment a1, some conditions or rules that the first instance binds the second instance needs to meet may be configured in advance on the server 12. Based on this, the server 12 can determine whether these conditions or rules configured in advance are satisfied; if yes, determining that the first instance needs to bind the second instance; if not, it is determined that the first instance does not need to bind the second instance. In addition, when the conditions or rules change from a satisfied state to a state that is no longer satisfied, it may be determined that the service binding between the first instance and the second instance needs to be released.

For example, a time frame, such as 7:00-12:00 am, may be preconfigured to the service requirements of the first instance, indicating that the first instance needs to use the service provided by the second instance during the period of 7:00-12:00 am. Based on this, the server 12 may determine that the first instance needs to bind the second instance during the period of 7:00-12:00 am, and may determine that 7: the service binding relationship between the first instance and the second instance needs to be released in a period of time before 00 and after 12:00.

In another alternative embodiment a2, whether the first instance needs to bind the second instance and whether the service binding between the first instance and the second instance needs to be unbindd may be determined by a deployment user or a use user of the first instance. For ease of description, the deployment user or use user of the first instance is referred to as the first user. It should be noted that, the deployment user of the first instance and the use user of the first instance may be the same user or different users. For the case that the deployment user and the use user of the first instance are different users, it may be agreed that only the deployment user has the right to determine whether the first instance needs to bind the second instance and whether the service binding relationship between the first instance and the second instance needs to be released; or it may be agreed that only the user has the right to determine whether the first instance needs to bind the second instance and whether the service binding between the first instance and the second instance needs to be released; or it may be agreed that both the deployment user and the use user have the right to determine whether the first instance needs to bind the second instance and whether the service binding between the first instance and the second instance needs to be released.

For the first user, an instance binding instruction can be issued under the condition that the first instance needs to bind the second instance; an instance unbinding instruction may be issued in case it is determined that the service binding relation between the first instance and the second instance needs to be released. For the server 12, it may be determined that the first instance needs to bind the second instance in response to an instance binding instruction sent by the first user; or, in response to an unbinding instruction sent by the first user, determining that the service binding relationship between the first instance and the second instance needs to be unbinding.

In this alternative embodiment a2, the embodiment in which the first user issues the instance binding instruction or the instance unbinding instruction to the server 12 is not limited. In an alternative embodiment, to facilitate the first user issuing an instance binding instruction or an instance unbinding instruction, the server 12 provides an interactive interface for the first user to issue various instructions. The interactive interface provided by the server 12 towards the first user may be a web page, a command window or an application page, etc.

For example, the server 12 may provide an instance binding interface for the first user to issue instance binding instructions. For a first user, opening an instance binding interface on self-used terminal equipment, wherein the instance binding interface comprises at least one instance for binding the first instance; optionally, at least one instance available for binding by the first instance may be displayed in a tabular manner. The first user can select a second instance, which needs to be bound, from the bindable instances; the server 12 determines, in response to an instance selection operation sent by the first user on the instance binding interface, the selected instance as a second instance that needs to be bound by the first instance, and determines that the first instance needs to bind the second instance.

Further optionally, a binding control corresponding to the second instance may also be included on the instance binding interface. In addition to selecting the second instance, the first user may also issue an instance binding instruction by clicking a binding control corresponding to the second instance.

For another example, the server 12 may provide an instance unbinding interface for the first user to issue an instance unbinding instruction. For the first user, an instance unbinding boundary surface can be opened on the terminal equipment used by the first user, and an unbinding control corresponding to the second instance is included on the instance unbinding interface. The first user may initiate a trigger operation on the unbinding control, thereby issuing an instance unbinding instruction. Wherein the triggering operation may be, but is not limited to: single click, double click, long press, touch, hover, etc. The server 12 determines that the service binding relationship between the first instance and the second instance needs to be released in response to a trigger operation of the first user on the unbinding control.

It should be noted that, the above example binding interface and example unbinding interface may be the same interface, or may be two independent interfaces. Taking an example that an instance binding interface and an instance unbinding interface are the same interface, displaying other instances which can be bound by a first instance in a list mode on the interface, and displaying a binding control and an unbinding control beside each instance; for any instance, before it is bound, its corresponding binding control is in an active state, while the unbinding control is in a disabled state; accordingly, when the instance is bound, its corresponding unbinding control will be in an active state, while the binding control user is in a disabled state. For a user, clicking a binding control corresponding to an unbound instance to send an instance binding instruction; accordingly, clicking on the unbinding control corresponding to a bound instance sends out an instance unbinding instruction.

In the above-mentioned alternative embodiment, the service end 12 may dynamically and flexibly establish or break the service binding relationship between the first instance and the second instance according to the binding requirement of the first instance on the second instance. For the second instance, the first instance is not required to be deployed and released together with the first instance by taking the first instance as a host because of the dependency relationship with the first instance, the second instance can be independently deployed and released, the coupling degree between the first instance and the second instance is reduced, loose coupling between the instances is realized, and the service elasticity and flexibility of the second instance are improved.

In the embodiments of the present application, due to the reduced coupling degree between the first instance and the second instance, the second instance no longer has to be deployed and released together with the first instance as in the prior art, but can be deployed and released separately. Based on this, the server 12 may provide an instance creation function in addition to establishing and releasing the service binding relationship between the first instance and the second instance, so as to create the second instance for the first user according to the instance requirement of the first user. The user who creates the second instance may be the first user or a user who is specially responsible for instance creation. The first user may submit his own instance requirements to the user who is responsible for instance creation, which creates a desired second instance for the first user.

Further, with the development of resource slicing technology, physical resources can be logically sliced into different specifications, which provides a basis for multi-specification examples. Where the specification of an instance refers to the physical resource specification required by the instance, for example, the instance specification may be 8C32G, 16C64G, 32C128G, or 64C256G, etc. In the examples of these instance specifications, the number preceding the letter C represents the number of CPU cores required by the instance and the number preceding the letter G represents the amount of memory required by the instance. In this embodiment, the second instance may support multiple specifications, for example, multiple specifications such as 8C32G, 16C64G, 32C128G, and 64C256G, allowing the first user to customize the specifications of the second instance according to the requirements.

Based on the above analysis, the server 12 provides instance creation functionality externally, one implementation of creating a second instance for the first user or a user specifically responsible for instance creation includes: an instance creation interface is provided externally, on which at least one instance specification, such as 8C32G, 16C64G, 32C128G, and 64C256G, is included for the first user or a user specifically responsible for instance creation to select a desired instance specification. The first user or a user specifically responsible for instance creation may select a desired instance specification, such as 32C128G, among the at least one instance specification. The server 12 may determine the selected instance specification in response to an instance specification selection operation on the instance creation interface; creating a second instance according to the selected instance specification, and providing a basis for subsequent dynamic establishment of a service binding relationship between the first instance and the second instance.

The description herein is as follows: the second instance may be created by the server 12 in the manner described above prior to binding the first instance with the second instance, but is not so limited. For example, the second instance may be created in other ways or by other devices in advance and deployed on the server side 12.

Further, in the case that the second instance supports multiple specifications, since the service end 12 can dynamically and flexibly establish or release the service binding relationship between the first instance and the second instance, in the case that the first user cannot determine which instance specification is suitable for use, an optimal instance specification can be selected from multiple instance specifications in an attempted manner, that is, the service binding relationship is established with the second instance of one specification first, if not suitable, the service binding relationship is released, and then the service binding relationship is established with the second instance of another specification until the optimal instance specification is attempted. The process of tentatively selecting the optimal instance specification can be greatly simplified based on the dynamic establishment and release of the service binding relationship, which is beneficial to improving the efficiency of selecting the optimal instance specification.

Further, in the case that the second instance supports multiple specifications, since the service end 12 can flexibly establish or release the service binding relationship between the first instance and the second instance, when the specification of the second instance needs to be changed, the service binding relationship between the first instance and the second instance of the current specification can be quickly released on the premise of not affecting the service and not damaging the environment, and the service binding relationship between the second instance of the new specification and the first instance can be re-established, so as to complete adjustment deployment, and achieve real "elasticity".

In the above or below embodiments of the present application, the specific implementation manner of establishing the service binding relationship between the first instance and the second instance by the server 12 according to the unique information of the first instance is not limited. All the implementation manners of successfully and accurately binding the second instance to the first instance according to the unique information of the first instance are applicable to the embodiments of the present application.

In some alternative embodiments, it is contemplated that in order to secure the data transfer process during the remote invocation process, there will typically be an authentication process, typically based on key information, which authentication is verified, and the party that obtained the key information is authorized. In this alternative embodiment, the process of establishing a service binding relationship between the first instance and the second instance may be understood as a process of providing the first instance with key information required to invoke or access the second instance, which means that the first instance has the right to invoke or access the second instance, once the first instance obtains the key information required to invoke or access the second instance, that is, that the service binding relationship between the first instance and the second instance is established.

Based on the analysis, one embodiment of the server 12 establishing a service binding relationship between the first instance and the second instance according to the unique information of the first instance includes: generating key information between the first instance and the second instance based on the unique information of the first instance; the key information is correspondingly provided to the first instance and the second instance to establish a service binding relationship between the first instance and the second instance.

In the embodiment of the present application, the specific implementation manner of generating the key information between the first instance and the second instance according to the unique information of the first instance is not limited, and the key generation manner or algorithm can be flexibly set according to the application requirement, which is not limited. An alternative embodiment is given below:

in an alternative embodiment, the server 12 may generate service binding identity information corresponding to the first instance according to the unique information of the first instance; further, key information between the first instance and the second instance is generated according to the service binding identity information corresponding to the first instance. The service binding identity information is used for identifying who an object needs to establish a binding relationship with the second instance is, that is, who an object needs to provide a service by the second instance is, so the service binding identity information can also be called a service name, and identifies a service demander. In an embodiment of the present application, the service binding identity information points to the first instance. The service binding identity information generated according to the unique information of the first instance can identify that the first instance is not the other instance, and therefore the generated key information is exclusive key information between the first instance and the second instance, the second instance is ensured to be successfully and accurately bound to the first instance, and the second instance is prevented from being bound to the other instance by mistake.

In this embodiment, the generation algorithm used to generate the service binding identity information corresponding to the first instance is not limited to the unique information of the first instance, and may be flexibly set as required. For example, a prefix or suffix may be added to the unique information of the first instance, so as to obtain service binding identity information corresponding to the first instance. For example, assuming that the unique information of the first instance is i-xxx, a specified prefix, such as foobar, may be added before the information, so as to obtain service binding identity information, such as foobar-i-xxx, corresponding to the first instance.

In an alternative embodiment, the server 12 may call an API that is externally developed by the first instance, and obtain the ID of the first instance in the running state as the unique information of the first instance. The ID of the first instance in the running state has uniqueness, and the second instance can be accurately bound to the first instance; in addition, the ID of the first example in the running state has strong confidentiality, can prevent being counterfeited to a certain extent, and is beneficial to ensuring the security of the second example.

In the present embodiment, the key algorithm employed to generate the key information from the service binding identity information corresponding to the first instance is not limited. For example, a symmetric key algorithm may be employed, or an asymmetric key algorithm may be employed. If a symmetric key algorithm is employed, the generated key information is a symmetric key, which may be provided to the first instance and the second instance, respectively, establishing a service binding relationship between the first instance and the second instance. If an asymmetric key algorithm is employed, the key information is an asymmetric key, i.e., comprising a public key and a private key, the public key may be provided to the first instance and the private key provided to the second instance to establish a service binding relationship between the first instance and the second instance.

Further, in the case of adopting the asymmetric key algorithm, the process of generating the key information between the first instance and the second instance by the server 12 according to the service binding identity information corresponding to the first instance includes: generating a public key pair, namely a public key and a private key, according to an agreed asymmetric key generation algorithm; and adding the service binding identity information corresponding to the first instance into a public name field of the public key. And then writing the public key into a storage position agreed with the first instance, and storing the private key in the local end so as to establish a service binding relation between the first instance and the second instance. In this embodiment, the public key is used to encrypt data sent by the first instance to the second instance; the private key is used to decrypt data encrypted by the public key.

Further, in either of the above ways, after establishing the service binding, the first instance may invoke the second instance to provide services for it based on the service binding. Wherein the client 11 may determine whether the first instance requires remote invocation of the second instance; in the case where it is determined that the first instance needs to remotely invoke the second instance to provide services for the second instance, the client 11 may send a remote invocation request to the server 12 according to the service binding relationship between the first instance and the second instance, so that the server 12 invokes the second instance to provide services for the first instance, as shown in fig. 1. For the server 12, a remote call request sent by the client 11 can be received; calling a second instance to provide service for the first instance according to the remote call request; and returns the service result provided by the second instance for the first instance to the client 11, as shown in fig. 1. The service result provided by the second instance returned by the server 12 for the first instance may also be received by the client 11.

In an alternative embodiment, the server 12 generates service binding identity information and key information based on the unique information of the first instance and provides the generated key information to the first instance and the second instance, respectively, in the process of establishing the service binding relationship. In this alternative embodiment, the client 11 may acquire the unique information of the first instance and the first key information provided in advance to the first instance by the server 12; generating service binding identity information according to the unique information of the first instance; the service binding identity information and the first key information are added in a remote invocation request to be sent to the server 12. The service binding identity information and the first key information are used for creating an encryption channel; the first key information is at least part of key information used between the first instance and the second instance. Accordingly, after receiving the remote invocation request, the server 12 may parse the service binding identity information and the key information from the remote invocation request before invoking the second instance; authenticating the client according to the service binding identity information and the key information; and under the condition that the client passes authentication, calling the second instance to provide service for the first instance according to the remote calling request. By authenticated, it is meant that the encrypted channel between the client 11 (or the first instance) and the server 12 (or the second instance) is successfully created (see fig. 1), so that the security of the second instance can be ensured by performing data transmission based on the encrypted channel later.

Optionally, if the server side adopts a symmetric key algorithm, the first key information is the key information generated by the server side; if the server side adopts an asymmetric key algorithm, the first key information is a public key of a key pair generated by the server side.

Alternatively, if the server 12 uses the ID of the first instance in the running state as the unique information of the first instance, the client 11 needs to use the ID of the first instance in the running state as the unique information of the first instance accordingly. Similar to the manner in which the server 12 obtains the ID of the first instance in the running state, the client 11 may also call the API that is created by the first instance externally, to obtain the ID of the first instance in the running state, as the unique information of the first instance.

In an alternative embodiment, if the server 12 uses an asymmetric key algorithm, a public key and a private key are generated, and the public key is stored in a storage location agreed with the client 11. Based on this, the client 11 may acquire the public key between the first instance and the second instance as the first key information at the storage location agreed with the server 12. Based on this, the client 11 may add the public key and the service binding identity information to the remote invocation request to send to the server 12; accordingly, the server 12 authenticates the client including: resolving service binding identity information from a public name field of a public key sent by the client 11, and comparing the resolved service binding identity information with the service binding identity information sent by the client 11; if the two are the same, it may be determined that the client is authenticated. It should be noted that, the authentication process not only includes comparing two service binding identity information, but also includes other authentication operations, such as verifying whether the public key is legal, complete, etc., which are described herein in detail.

In an alternative embodiment, the client 11 may listen for a service request of the first instance; if the monitored service request carries the identifier of the second instance, determining that the first instance needs to remotely call the second instance; then, creating an encrypted channel according to the service binding relationship between the first instance and the second instance; and sending a remote call request to the server 12 based on the encryption channel, so that the server 12 calls the second instance to provide service for the first instance, and receiving a service result provided by the second instance returned by the server 12 through the encryption channel for the first instance. For detailed implementation of some operations in this alternative embodiment, please refer to the foregoing embodiment, and the detailed description is omitted here.

Here, in the above-described embodiment, the procedure of remotely calling the second instance is schematically described. Based on the above principle explanation, the remote call procedure of the second example may be implemented by using an existing remote call framework, or may be implemented by self-developing a new remote call framework, which is not limited. The remote invocation procedure for the second instance may differ in detail when implemented with a different remote invocation framework. For example, gRPC is an open source, cross-platform, high performance RPC framework, apache thread is another RPC framework, and applications are very widespread. In the embodiment of the present application, the remote call procedure to the second instance may be implemented using the gppc or Apache thread protocol under the RPC framework, but is not limited thereto. Under the gRPC framework, SSL/TLS or Google token-based authentication mechanism can be used; SSL authentication mechanisms and the like can be used under the Apache thread framework, and the implementation details of the SSL authentication mechanisms and the like are different, and the SSL authentication mechanisms and the like are not described in detail.

In the cloud network, a user can rent or purchase resources in the cloud and deploy own ECS examples on the rented or purchased resources, meanwhile, an elastic accelerator Example (EAI) is also provided in the cloud network to provide acceleration service for the ECS of the user, and the ECS example of the user can accelerate the calculation process by using the EAI example. Among other things, an ECS instance is a resiliently scalable computing service, including but not limited to: reasoning, transcoding, or desktop rendering, etc., as shown in fig. 2 a. An EAI instance is a virtual accelerator that may be attached to an ECS instance. The EAI instance may decouple the CPU from the GPU, and may provide transparent, easy-to-use GPU acceleration capabilities in a flexible configuration, rich combination. In FIG. 2a, an example is illustrated with an EAI instance based on a GPU implementation.

Among other things, EAI instances can provide acceleration services for a variety of ECS instances. To facilitate the EAI instance to provide services for different ECS instances, the EAI instance is decoupled from the ECS instance, as shown in fig. 2a, a service end is deployed at one side of the EAI instance, and dynamic binding and unbinding are performed on the EAI instance and the ECS instance through the service end. Further, as shown in fig. 2a, a client is deployed at one end of the ECS instance, through which a service request of the ECS instance is monitored and a call to the EAI instance is initiated if the EAI instance is required by the ECS instance.

The process of binding an EAI instance, unbinding an EAI instance, and remotely invoking an EAI instance by an ECS instance is described in detail below in conjunction with the flow chart of fig. 2 b.

As shown in fig. 2b, the process of binding an EAI instance by an ECS instance includes:

and 20b, the server determines that the ECS instance providing the reasoning service needs to bind the EAI instance according to the instance binding requirement submitted by the user. The ECS providing the reasoning service refers to an ECS instance corresponding to the gray box in fig. 2 a.

21b, the server side calls an API externally provided by the ECS instance, and obtains the ID of the ECS instance in the running state as the unique information of the ECS instance.

The unique information of the ECS instance may be other unique information such as a MAC address of the ECS instance, in addition to the ID of the ECS instance in the running state.

And 22b, the server generates service binding identity information corresponding to the first instance according to the ID of the ECS instance and the customized generation rule.

For example, taking the example that the ID of the ECS instance is i-xxx, a specified prefix, e.g., foobar, may be added in front of the ID, thereby obtaining service binding identity information, e.g., foobar-i-xxx, of the ECS instance.

And 23b, the server side adopts an asymmetric key algorithm to generate an asymmetric key pair, wherein the key pair comprises a public key and a private key.

24b, the service end writes the service binding identity information into a Common Name (Common Name) field of the public key.

For example, foobar-i-xxx may be written in the public name field to identify the legitimate user of the key pair.

And 25b, the server writes the public key to a storage position agreed with the client on one side of the ECS instance, so that the binding between the ECS instance and the EAI instance is completed.

Wherein the ECS instance takes the public key and the EAI instance holds the corresponding private key at one end, which means that a binding relationship is established between the two.

As further shown in fig. 2b, the process of the ECS instance invoking the EAI instance includes:

26b, when the ECS instance initiates a service request to the EAI instance, the client may monitor the service request and determine that the ECS instance needs to invoke the EAI instance.

Wherein the client may be implemented as an elastic SDK, but is not limited thereto.

27b, the client calls an API externally provided by the ECS instance to acquire the ID of the ECS instance in the running state as the unique information of the ECS instance.

28b, the client generates service binding identity information corresponding to the first instance according to the ID of the ECS instance and the customized generation rule.

29b, the client reads the public key provided by the server from the agreed storage location.

And 30b, the client initiates a remote call request to the server according to the service binding identity information and the public key so as to request the server to call the EAI instance to provide acceleration service for the ECS instance.

The remote call request carries the service binding identity information and the public key, and can also carry data needing to be accelerated or carry other information which can point to the data needing to be accelerated. Wherein the service binding identity information and the public key are used to create an encrypted channel.

31b, the server authenticates the client according to the service binding identity information and the public key sent by the client. The authentication process mainly refers to judging whether the client has the authority to call the EAI instance.

32b, after passing the authentication, meaning that the encryption channel is successfully created, the server side calls the EAI instance to provide acceleration service for the ECS instance.

33b, the server returns the service result of the EAI instance to the client based on the encrypted channel, so that the client can transfer the service result to the ECS instance.

In the process of calling the EAI instance, in order to ensure the safety of the EAI instance, the server side can externally provide the EAI instance by adopting a mode of combining an auxiliary network card and a container (dock) process, wherein the auxiliary network card can externally provide the EAI instance by adopting the dock process in a mode of a service port, which is equivalent to isolating the auxiliary network card and limiting possible attacks on the dock process level.

Furthermore, in the process of calling the EAI instance, the attack surface on the EAI instance can be further reduced by adopting a security information group and other modes. For example, identifying information such as IP, MAC address, etc. of the ECS instance that successfully bound the EAI instance is added to the security information set. When a remote call request initiated to an EAI instance is received, the server can judge whether the identification information such as IP, MAC address and the like of the instance initiating the EAI call is in a security information group; if yes, allowing the EAI instance to be called; otherwise, the EAI instance is refused to be invoked.

As further shown in fig. 2b, the process of unbinding the EAI instance by the ECS instance includes:

34b, the server determines that the ECS instance needs to be unbound to the EAI instance according to the instance unbinding requirement submitted by the user.

35b, the server deletes the public key of the client and the private key of the client to unbind the ECS instance and the EAI instance.

In the above embodiment, for the ECS instance and the EAI instance with the dependency relationship, the service binding relationship between the ECS instance and the EAI instance may be dynamically and flexibly established, and based on the service binding relationship, the ECS instance may call the EAI instance to enable the EAI instance to provide an acceleration service for the EAI instance, so that the EAI instance does not need to be deployed together with the ECS instance by taking the ECS instance as a host due to the dependency relationship, and loose coupling between the instances is achieved, which is beneficial to improving service elasticity and flexibility of the instances.

In an alternative embodiment, as shown in fig. 2c, with the help of the Open API (Open API) of the EAI instance, the user can flexibly perform the following operations through the console: 1. creating an EAI instance with required specification, 2, binding the EAI instance to a user ECS instance, 5, unbinding the EAI instance and the user ECS instance, and 6, deleting the EAI instance and the like.

Further, as shown in fig. 2c, a virtual private cloud (Virtual Private Cloud, VPC) may be used to construct an isolated virtual network environment for ECS instances and EAI instances, where the virtual network environment is configured and managed autonomously by a user, so as to improve security of resources in the user cloud and simplify network deployment of the user. The VPC is a dynamic configuration pool of cloud computing resources, and data needs to be transmitted between the user ECS instance and the EAI instance provided by the cloud service provider in this embodiment by using an encryption protocol, a tunneling protocol and other security procedures, so as to realize isolation between different users. The user ECS side in fig. 2c corresponds to a client deployed at one end of the ECS instance, and the background ECS side in fig. 2c corresponds to a service deployed at one side of the EAI instance.

As shown in fig. 2c, after creating the ECS instance and the EAI instance, the background ECS may generate a public-private key pair according to the feature information of the ECS instance, for example, the ID of the ECS instance in the running state, create an encrypted channel, for example, the gRPC channel, using the public-private key pair, and start the daemon (as in operation 2.A in fig. 2 c). The daemon is a program running on a background ECS end and is used for responding to a call request from a user ECS end and providing EAI acceleration service for the user ECS end. In addition, the public key required to create the gRPC channel is sent to the user ECS side. The user ECS side saves the public key (e.g., eais-i-xxx) under the specified directory, e.g., saves the path for etc/hosts/eais-i-xxx (e.g., operation 2.B in fig. 2 c). Further, the user ECS downloads the SDK with the elastic service binary file (elastic server binary) from the predetermined location, and running the SDK may start an elastic service (e.g., inference service) that listens to the user's service request and initiates a procedure of calling the EAI instance to the background ECS (as in operations 3 and 4 in fig. 2 c). After the EAI acceleration service is finished, the background ECS end stops the daemon program and deletes the public-private key pair to release the gRPC channel (as in operation 5.a in fig. 2 c); the user ECS deletes the etc/hosts/EAIs-i-xxx entry, thereby releasing the binding between the ECS instance and the EAI instance (as in operation 5.a in fig. 2 c). Wherein operations 2.A and 2.B can be considered as detailed implementations of operation 2; operations 5.a and 5.B can be considered a detailed implementation of operation 5.

The detailed flow of invoking the EAI acceleration service is shown in fig. 2 d:

the user ECS runs the SDK, starts the elastic service, and listens to the service request of the user calling the EAI instance (as in operation 4.1 in fig. 2 d). In addition, the elastic service generates a service address corresponding to the identity information of the ESC instance according to the characteristic information of the ECS instance, for example, the ID of the ECS instance in the running state (operation 4.2 in fig. 2 d); in turn, an encrypted channel, such as the gRPC channel, is created based on the service address and the public key already stored on the home side (operation 4.3 in FIG. 2 d). The user initiates a service invocation request whose payload (payload) depends on the request category, and if an inference request, the payload is a model or a picture (as in operation 4.4 in fig. 2 d). The service request is then sent in packets to the background ECS via the encrypted channel (operation 4.5 in fig. 2 d).

The service request reaches a TCP service port of the background ECS end through the gRPC channel; at the background ECS side, the daemon program listens to the service request sent by the user ECS side from the TCP service port (as shown in operation 4.6 in fig. 2 d); authentication of the encrypted channel (as in operation 4.7 of fig. 2 d), the authentication mainly comprises: judging the validity of a public key used by a user ECS end, and judging whether a service address used by the user ECS end is the same as a service address generated by a background ECS end according to characteristic information (such as an ID in a running state) of a CES instance; if the authentication fails, rejecting the service request (operation 4.81 in FIG. 2 d); if the authentication is successful, initiate a GPU call (as operation 4.82 in FIG. 2 d); after the GPU computing task is completed, the computing result is returned to the user ECS end through the gRPC channel (as in operation 4.9 in fig. 2 d).

Fig. 3 is a flowchart of an example processing method according to an exemplary embodiment of the present application. This embodiment is described from the perspective of the server, and as shown in fig. 3, the method includes:

301. it is determined that the first instance needs to bind the second instance.

302. And establishing a service binding relation between the first instance and the second instance according to the unique information of the first instance.

In this embodiment, the server is disposed on the second instance side, for example, may be disposed on the same physical device as the second instance, or may be disposed near the second instance but disposed on a different physical device from the second instance. The server side can provide binding and unbinding services for the second instance, can dynamically bind the first instance and the second instance, and can dynamically establish a service binding relationship between the first instance and the second instance according to the binding requirement of the first instance.

Wherein the primary purpose of establishing a service binding relationship between a first instance and a second instance is to bind the second instance to the first instance, in which process it is necessary to ensure that the second instance is bound to the first instance and not to other instances. Based on the above, the server may determine whether the first instance needs to bind the second instance, and in the case that the first instance needs to bind the second instance, establish a service binding relationship between the first instance and the second instance according to the unique information of the first instance.

In an alternative implementation, an embodiment of step 32 includes: based on the unique information of the first instance, generating service binding identity information corresponding to the first instance; generating key information between the first instance and the second instance according to the service binding identity information corresponding to the first instance; the key information is correspondingly provided to the first instance and the second instance to establish a service binding relationship between the first instance and the second instance.

In an alternative embodiment, the ID of the first instance in the running state may be used as the unique information of the first instance. Based on the above, before the service binding identity information corresponding to the first instance is generated, an API that the first instance is open to the outside may be called, and the ID of the first instance in the running state is obtained as the unique information of the first instance.

Further, an embodiment of generating key information between the first instance and the second instance according to the service binding identity information corresponding to the first instance includes: generating a public key and a private key according to a contracted asymmetric key generation algorithm; and adding the service binding identity information corresponding to the first instance into a public name field of the public key.

Wherein one embodiment of providing the key information to the first instance and the second instance includes: writing the public key into a storage location agreed with the first instance for encrypting data required by the first instance to be sent to the second instance; the private key is saved at the home end for decrypting the data encrypted by the public key.

In some alternative embodiments, after establishing the service binding relationship between the first instance and the second instance, the method of this embodiment further includes: receiving a remote call request sent by a client based on a service binding relationship; according to the remote call request, calling a second instance to provide service for the first instance; and returning the service result provided by the second instance for the first instance to the client.

Further optionally, the remote invocation request carries key information and service binding identity information. The method of this embodiment further includes, before invoking the second instance to serve the first instance: authenticating the client according to the key information and the service binding identity information; in the case that the client passes authentication, according to the remote call request, the second instance is called to provide service for the first instance

In some alternative embodiments, after establishing the service binding relationship between the first instance and the second instance, the method of this embodiment further includes: determining that the service binding relation between the first instance and the second instance needs to be released; the service binding relationship between the first instance and the second instance is released.

Optionally, one embodiment of determining that the first instance needs to bind the second instance includes: and responding to an instance binding instruction sent by the first user, and determining that the first instance needs to bind the second instance. Accordingly, one embodiment of determining that the first instance needs to unbind from the service binding with the second instance includes: responding to an instance unbinding instruction sent by a first user, and determining that the service binding relation between the first instance and the second instance needs to be unbinding; wherein the first user is a deployment and/or use user of the first instance.

Further, the determining that the first instance needs to bind the second instance in response to the instance binding instruction sent by the first user includes: displaying an instance binding interface, wherein the instance binding interface comprises at least one instance for binding a first instance; in response to an instance selection operation by the first user on the instance binding interface, the selected instance is determined as a second instance that needs to be bound by the first instance.

Further, the determining, in response to the instance unbinding instruction sent by the first user, that the service binding relationship between the first instance and the second instance needs to be unbinding includes: displaying an instance unbinding interface, wherein the instance unbinding interface comprises an unbinding control corresponding to the second instance; and responding to the triggering operation of the unbinding control by the first user, and determining that the service binding relation between the first instance and the second instance needs to be unbinding.

In some alternative embodiments, before determining that the first instance needs to bind the second instance, the method of the present embodiment further includes: process of creating the second instance. Wherein creating an embodiment of the second instance comprises: displaying an instance creation interface, wherein at least one instance specification is displayed on the instance creation interface; determining a selected instance specification in response to an instance specification selection operation; a second instance is created according to the selected instance specification.

In this embodiment, for the first instance and the second instance having the dependency relationship, the service binding relationship can be dynamically and flexibly established between the first instance and the second instance, so that the second instance does not need to be deployed together with the first instance by taking the first instance as a host due to the dependency relationship, loose coupling between the instances is realized, and service elasticity and flexibility of the instances are improved.

Fig. 4 is a flowchart of an example calling method according to an exemplary embodiment of the present application. The method is described from the client side, as shown in fig. 4, and includes:

401. it is determined that the first instance requires remote invocation of the second instance, a service binding relationship having been established between the first instance and the second instance.

402. And initiating a remote call request to the server according to the service binding relation so that the server can call the second instance to provide service for the first instance.

403. And receiving a service result provided by the second instance returned by the server for the first instance.

In this embodiment, the service binding relationship between the first instance and the second instance is already established, and the process of establishing the service binding relationship can refer to the foregoing embodiment, which is not described herein again. Of course, the service binding relationship between the first instance and the second instance may also be established in other manners than the foregoing embodiments, which is not limited thereto.

In an alternative embodiment, determining that the first instance requires remote invocation of the second instance includes: monitoring a service request of a first instance; if the monitored service request carries the identifier of the second instance, determining that the first instance needs to remotely call the second instance.

In an alternative embodiment, an implementation of step 402 includes: acquiring the unique information of the first instance and the first key information provided for the first instance by the server in advance; generating service binding identity information corresponding to the first instance according to the unique information of the first instance; adding the service binding identity information corresponding to the first instance and the first key information in the remote call request and sending the remote call request to the server; wherein the first key information is at least part of key information used between the first instance and the second instance.

Further, according to the unique information and the first key information of the first instance, a remote call request is initiated to the server, including: generating service binding identity information corresponding to the first instance according to the unique information of the first instance; and initiating a remote call request to the server according to the service binding identity information and the first key information corresponding to the first instance.

In an alternative embodiment, the ID of the first instance in the running state may be used as the unique information of the first instance. Based on this, one embodiment of obtaining the unique information of the first instance includes: and calling an API which is externally created by the first instance, and acquiring the ID of the first instance in the running state as the unique information of the first instance.

In an alternative embodiment, the obtaining the first key information of the first instance provided by the server in advance includes: and acquiring a public key between the first instance and the second instance as first key information at a storage position agreed with the server.

In this embodiment, based on the service binding relationship between the first instance and the second instance, the call to the second instance may be initiated if the first instance needs to remotely call the second instance, so that the first instance may successfully use the service provided by the second instance. In this embodiment, the second instance does not need to be deployed with the first instance by taking the first instance as a host because of the dependency relationship with the first instance, but can be deployed independently, so that the coupling degree between the first instance and the second instance is reduced, loose coupling between the instances is realized, and the service elasticity and flexibility of the second instance are improved.

It should be noted that, the execution subjects of each step of the method provided in the above embodiment may be the same device, or the method may also be executed by different devices. For example, the execution subject of steps 401 to 403 may be device a; for another example, the execution subject of steps 401 and 402 may be device a, and the execution subject of step 403 may be device B; etc.

In addition, in some of the flows described in the above embodiments and the drawings, a plurality of operations appearing in a specific order are included, but it should be clearly understood that the operations may be performed out of the order in which they appear herein or performed in parallel, the sequence numbers of the operations, such as 401, 402, etc., are merely used to distinguish between the various operations, and the sequence numbers themselves do not represent any order of execution. In addition, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel. It should be noted that, the descriptions of "first" and "second" herein are used to distinguish different messages, devices, modules, etc., and do not represent a sequence, and are not limited to the "first" and the "second" being different types.

Fig. 5 is a schematic structural diagram of a server device according to an exemplary embodiment of the present application. As shown in fig. 5, the server device includes: a memory 501 and a processor 502.

Memory 501 is used to store computer programs and may be configured to store various other data to support operations on a server device. Examples of such data include instructions, messages, pictures, videos, etc. for any application or method operating on the server device.

A processor 502 coupled to the memory 501 for executing a computer program for: determining that the first instance needs to bind the second instance; and establishing a service binding relation between the first instance and the second instance according to the unique information of the first instance.

In an alternative embodiment, the processor 502 is specifically configured to, when establishing a service binding relationship between the first instance and the second instance: based on the unique information of a first instance, generating service binding identity information corresponding to the first instance; generating key information between the first instance and the second instance according to the service binding identity information corresponding to the first instance; the key information is correspondingly provided to a first instance and a second instance to establish a service binding relationship between the first instance and the second instance.

In an alternative embodiment, the processor 502 is further configured to, prior to generating the service binding identity information: and calling an API (application program interface) of the first instance, which is open to the outside, and acquiring the ID of the first instance in the running state as the unique information of the first instance.

In an alternative embodiment, the processor 502 is specifically configured to, when generating the key information according to the service binding identity information: generating a public key and a private key according to a contracted asymmetric key generation algorithm; and adding the service binding identity information corresponding to the first instance into a public name field of the public key.

In an alternative embodiment, the processor 502 is specifically configured to, when providing the key information to the first instance and the second instance correspondingly: writing the public key into a storage location agreed with the first instance for encrypting data required by the first instance to be sent to the second instance; the private key is saved at the home end for decrypting the data encrypted by the public key.

In an alternative embodiment, the processor 502 is further configured to, after establishing the service binding relationship between the first instance and the second instance: receiving a remote call request sent by a client based on a service binding relationship, wherein the remote call request is used for requesting to call a second instance to provide service for a first instance; according to the remote call request, calling a second instance to provide service for the first instance; and returning the service result provided by the second instance for the first instance to the client.

Further optionally, the remote invocation request carries the key information and the service binding identity information. Based on this, the processor 502 is further configured to, prior to invoking the second instance to serve the first instance: authenticating the client according to the key information and the service binding identity information; and under the condition that the client passes authentication, calling the second instance to provide service for the first instance according to the remote calling request.

In an alternative embodiment, the processor 502 is further configured to, after establishing the service binding relationship between the first instance and the second instance: determining that the service binding relation between the first instance and the second instance needs to be released; the service binding relationship between the first instance and the second instance is released.

Further optionally, the processor 502 is specifically configured to, when determining that the first instance needs to bind the second instance: and responding to an instance binding instruction sent by the first user, and determining that the first instance needs to bind the second instance. Accordingly, when determining that the first instance needs to unbind from the service binding with the second instance, the processor 502 is specifically configured to: responding to an instance unbinding instruction sent by a first user, and determining that the service binding relation between the first instance and the second instance needs to be unbinding; wherein the first user is a deployment and/or use user of the first instance.

Still further, the processor 502 is specifically configured to, when determining that the first instance needs to bind the second instance: displaying an instance binding interface, wherein the instance binding interface comprises at least one instance for binding a first instance; in response to an instance selection operation by the first user on the instance binding interface, the selected instance is determined as a second instance that needs to be bound by the first instance.

Still further, the processor 502 is specifically configured to, when determining that the service binding between the first instance and the second instance needs to be released: displaying an instance unbinding interface, wherein the instance unbinding interface comprises an unbinding control corresponding to the second instance; and responding to the triggering operation of the unbinding control by the first user, and determining that the service binding relation between the first instance and the second instance needs to be unbinding.

In an alternative embodiment, the processor 502 is further configured to, prior to determining that the first instance needs to bind the second instance: displaying an instance creation interface, wherein at least one instance specification is displayed on the instance creation interface; determining a selected instance specification in response to an instance specification selection operation; a second instance is created according to the selected instance specification.

Further, as shown in fig. 5, the server device further includes: a communication component 503, a power supply component 504, and the like. Only some of the components are schematically shown in fig. 5, which does not mean that the server device only comprises the components shown in fig. 5. The server device in this embodiment may be a conventional server, a cloud server, or a server array.

Accordingly, the embodiments of the present application further provide a computer readable storage medium storing a computer program, where the computer program when executed can implement each step in the above method embodiments that can be executed by the server device.

Fig. 6 is a schematic structural diagram of a client device according to an exemplary embodiment of the present application. As shown in fig. 6, the client device includes: memory 601, processor 602, and communication component 603.

The memory 601 is used for storing computer programs and may be configured to store various other data to support operations on the server device. Examples of such data include instructions, messages, pictures, videos, etc. for any application or method operating on the server device.

A processor 602 coupled to the memory 601 for executing a computer program for: determining that a first instance needs to remotely call a second instance, wherein a service binding relationship is established between the first instance and the second instance; initiating a remote call request to a server through a communication component 603 according to the service binding relationship so that the server can call the second instance to provide service for the first instance; and receiving a service result provided by the second instance returned by the service end for the first instance through a communication component 603.

In an alternative embodiment, the processor 602 is specifically configured to, when initiating a remote call request to the server: acquiring the unique information of the first instance and the first key information provided for the first instance by the server in advance; generating service binding identity information corresponding to the first instance according to the unique information of the first instance; adding the service binding identity information corresponding to the first instance and the first key information in the remote call request and sending the remote call request to the server; wherein the first key information is at least part of key information used between the first instance and the second instance.

In an alternative embodiment, processor 602, when obtaining the unique information of the first instance, is specifically configured to: and calling an API which is externally created by the first instance, and acquiring the ID of the first instance in the running state as the unique information of the first instance.

In an alternative embodiment, the processor 602, when obtaining the first key information of the first instance provided in advance by the server, is specifically configured to: and acquiring a public key between the first instance and the second instance as first key information at a storage position agreed with the server.

In an alternative embodiment, the processor 602 is specifically configured to, when determining that the first instance requires remote invocation of the second instance: monitoring a service request of a first instance; if the monitored service request carries the identifier of the second instance, determining that the first instance needs to remotely call the second instance.

Further, as shown in fig. 6, the client device further includes: a communication component 603, a display 607, a power component 608, an audio component 609, and other components. Only some of the components are schematically shown in fig. 6, which does not mean that the client device only comprises the components shown in fig. 6. In addition, the components within the dashed box in fig. 6 are optional components, not necessarily components, depending on the product form of the client device. The client device in this embodiment may be implemented as a terminal device such as a desktop computer, a notebook computer, a smart phone, or an IOT device, or may be a server device such as a conventional server, a cloud server, or a server array. If the client device of the embodiment is implemented as a terminal device such as a desktop computer, a notebook computer, a smart phone, etc., the client device may include components within the dashed line frame in fig. 6; if the client device of the present embodiment is implemented as a server device such as a conventional server, a cloud server, or a server array, the components within the dashed box in fig. 6 may not be included.

Accordingly, the present application further provides a computer readable storage medium storing a computer program, where the computer program is executed to implement the steps executable by the client device in the above method embodiments.

The memory in fig. 5 and 6 described above may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk.

The communication assembly of fig. 5 and 6 described above is configured to facilitate wired or wireless communication between the device in which the communication assembly is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as a mobile communication network of WiFi,2G, 3G, 4G/LTE, 5G, etc., or a combination thereof. In one exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component may further include a Near Field Communication (NFC) module, radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra Wideband (UW) technology, bluetooth (T) technology, and the like.

The displays in fig. 5 and 6 described above include screens, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may sense not only the boundary of a touch or slide action, but also the duration and pressure associated with the touch or slide operation.

The power supply assembly shown in fig. 5 and 6 provides power to the various components of the device in which the power supply assembly is located. The power components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the devices in which the power components are located.

The audio components of fig. 5 and 6 described above may be configured to output and/or input audio signals. For example, the audio component includes a Microphone (MIC) configured to receive external audio signals when the device in which the audio component is located is in an operational mode, such as a call mode, a recording mode, and a speech recognition mode. The received audio signal may be further stored in a memory or transmitted via a communication component. In some embodiments, the audio assembly further comprises a speaker for outputting audio signals.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and changes may be made to the present application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims of the present application.

Claims

1. An instance management system, comprising: a client and a server; the client is deployed on one side of a first instance, the client and the first instance are deployed on the same physical equipment or different physical equipment, the server is deployed on one side of a second instance, and the client and the second instance are deployed on the same physical equipment or different physical equipment; the first instance is an instance for providing elastic computing service in a cloud network, and the second instance is an instance for providing elastic acceleration service for the first instance in the cloud network;

the server is configured to generate key information between the first instance and the second instance based on the unique information of the first instance, and provide the key information to the first instance and the second instance correspondingly, so as to establish a service binding relationship between the first instance and the second instance; and in the event that it is determined that the service binding relationship between the first instance and the second instance needs to be released, releasing the service binding relationship between the first instance and the second instance;

2. The system of claim 1, wherein the server is specifically configured to:

responding to an instance binding instruction sent by a first user, and determining that the first instance needs to bind the second instance; and

responding to an instance unbinding instruction sent by a first user, and determining that the service binding relation between the first instance and the second instance needs to be unbinding;

wherein the first user is a deployment and/or use user of the first instance.

3. The system of claim 1, the server is further configured to:

displaying an instance creation interface, wherein at least one instance specification is displayed on the instance creation interface;

determining a selected instance specification in response to an instance specification selection operation;

the second instance is created according to the selected instance specification.

4. An instance processing method, suitable for a server, the method comprising:

determining that a first instance needs to be bound with a second instance, wherein the first instance is an instance for providing elastic computing service in a cloud network, the second instance is an instance for providing elastic acceleration service for the first instance in the cloud network, and the service end is deployed on one side of the second instance and on the same physical equipment or different physical equipment with the second instance;

Generating service binding identity information corresponding to the first instance based on the unique information of the first instance, generating key information between the first instance and the second instance according to the service binding identity information corresponding to the first instance, providing the key information to the first instance and the second instance correspondingly so as to establish a service binding relation between the first instance and the second instance, and sending a remote call request to the server based on the service binding relation when a client deployed on one side of the first instance needs to remotely call the second instance, so that the server can call the second instance to provide service for the first instance, wherein the client and the first instance are deployed on the same physical device or different physical devices;

determining that the service binding relationship between the first instance and the second instance needs to be released, and releasing the service binding relationship between the first instance and the second instance.

5. The method of claim 4, further comprising, prior to generating service binding identity information corresponding to the first instance based on the uniqueness information of the first instance:

And calling an API (application program interface) of the first instance, which is open to the outside, and acquiring the ID of the first instance in the running state as the unique information of the first instance.

6. The method of claim 4, generating key information between the first instance and the second instance from service binding identity information corresponding to the first instance, comprising:

generating a public key and a private key according to a contracted asymmetric key generation algorithm;

and adding the service binding identity information corresponding to the first instance into a public name field of the public key.

7. The method of claim 6, providing the key information correspondence to the first instance and the second instance to establish the service binding relationship, comprising:

writing the public key into a storage position agreed with the first instance, and storing the private key at a local end so as to establish the service binding relation;

wherein the public key is used to encrypt data sent by the first instance to the second instance; the private key is used to decrypt data encrypted by the public key.

8. The method of any of claims 4-7, after establishing a service binding relationship between the first instance and the second instance, the method further comprising:

Receiving a remote call request sent by a client based on the service binding relation;

according to the remote call request, calling the second instance to provide service for the first instance; and

and returning the service result provided by the second instance for the first instance to the client.

9. The method of claim 8, the remote invocation request carrying the key information and the service binding identity information;

before invoking the second instance to serve the first instance, the method further comprises:

authenticating the client according to the key information and the service binding identity information;

and under the condition that the client passes authentication, calling the second instance to provide service for the first instance according to the remote calling request.

10. The method according to claim 4, wherein the method comprises,

determining that the first instance needs to bind the second instance includes: responding to an instance binding instruction sent by a first user, and determining that the first instance needs to bind the second instance;

determining that the first instance needs to unbind from a service binding relationship with the second instance includes: responding to an instance unbinding instruction sent by a first user, and determining that the service binding relation between the first instance and the second instance needs to be unbinding;

Wherein the first user is a deployment and/or use user of the first instance.

11. The method of claim 10, responsive to an instance binding instruction issued by a first user, determining that the first instance needs to bind the second instance, comprising:

displaying an instance binding interface, wherein the instance binding interface comprises at least one instance for binding the first instance;

in response to an instance selection operation issued by a first user on the instance binding interface, determining the selected instance as a second instance that needs to be bound by the first instance.

12. The method of claim 11, responsive to an instance unbinding instruction issued by a first user, determining that a service binding relationship between the first instance and the second instance needs to be unbinding, comprising:

displaying an instance unbinding interface, wherein the instance unbinding interface comprises an unbinding control corresponding to the second instance;

in response to a trigger operation of the first user on the unbinding control, determining that service binding between the first instance and the second instance needs to be released.

13. The method of any of claims 4-7, prior to determining that the first instance needs to bind the second instance, the method further comprising:

14. An instance calling method, suitable for a client, comprising:

determining that a first instance needs to remotely call a second instance, wherein a service binding relation is established between the first instance and the second instance, the first instance is an instance for providing elastic computing service in a cloud network, the second instance is an instance for providing elastic acceleration service for the first instance in the cloud network, and the client is deployed on one side of the first instance and on the same physical equipment or different physical equipment with the first instance;

acquiring the unique information of the first instance and first key information provided for the first instance by a server in advance, generating service binding identity information corresponding to the first instance according to the unique information of the first instance, adding the service binding identity information corresponding to the first instance and the first key information in the remote call request, and sending the remote call request to the server so that the server can call the second instance to provide services for the first instance; the first key information is at least part of key information used between the first instance and the second instance; the server is deployed at one side of the second instance and deployed on the same physical equipment or different physical equipment with the second instance;

And receiving a service result provided by the second instance returned by the service end for the first instance.

15. The method of claim 14, obtaining the unique information of the first instance, comprising:

and calling an API (application program interface) externally created by the first instance, and acquiring the ID of the first instance in the running state as the unique information of the first instance.

16. The method of claim 14, obtaining the first key information of the first instance provided by the server in advance, comprising:

and acquiring a public key between the first instance and the second instance as the first key information at a storage position agreed with the server.

17. The method of any of claims 14-16, determining that the first instance requires remote invocation of the second instance, comprising:

monitoring a service request of the first instance;

and if the monitored service request carries the identification of the second instance, determining that the first instance needs to remotely call the second instance.

18. A server device, comprising: a memory and a processor;

the memory is used for storing a computer program;

the processor, coupled to the memory, is configured to execute the computer program for:

19. A computer readable storage medium storing a computer program which, when executed by a processor, causes the processor to carry out the steps of the method of any one of claims 4-13.

20. A client device, comprising: a memory and a processor;

the memory is used for storing a computer program;

acquiring the unique information of the first instance and first key information provided for the first instance by a server in advance, generating service binding identity information corresponding to the first instance according to the unique information of the first instance, adding the service binding identity information corresponding to the first instance and the first key information in the remote calling request, and sending the service binding identity information and the first key information to the server so that the server can call the second instance to provide services for the first instance, wherein the first key information is at least part of key information used between the first instance and the second instance, and the server is deployed on one side of the second instance and on the same physical equipment or different physical equipment with the second instance;

21. A computer readable storage medium storing a computer program which, when executed by a processor, causes the processor to carry out the steps of the method of any one of claims 14 to 17.