CN117591140A

CN117591140A - Service grid, service upgrading method, device, equipment and medium

Info

Publication number: CN117591140A
Application number: CN202311344806.8A
Authority: CN
Inventors: 谢辉; 邵东风; 于楠; 姜家意; 柳雪妍; 谢蕾
Original assignee: Hangzhou Netease Cloud Music Technology Co Ltd
Current assignee: Hangzhou Netease Cloud Music Technology Co Ltd
Priority date: 2023-10-17
Filing date: 2023-10-17
Publication date: 2024-02-23

Abstract

The application provides a service grid, a service upgrading method, a device, equipment and a medium, wherein the service grid comprises the following components: the control surface is used for carrying out upgrade release operation on the first service according to the service upgrade list; the upgrade plug-in is used for determining a first target application program interface from the application program interface layer according to the upgrade release operation, determining a first target implementation with a mapping relation with the first target application program interface from the data plane version management module, and upgrading the first target implementation according to the version mapping relation between the first target application program interface and the first target implementation so as to upgrade the first service. The service upgrading method and the service upgrading device can conduct service upgrading in the agent-free mode of the service grid, does not need to independently deploy an agent process for each service, and can conduct standardized processing on the existing component protocol, so that the existing component protocol has better expansibility and maintainability, service upgrading speed can be improved, and service upgrading cost is saved.

Description

Service grid, service upgrading method, device, equipment and medium

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a service grid, a service upgrading method, a device, equipment and a medium.

Background

A micro-service architecture is a type of architecture that can break up an application (also called an application program) into multiple small services, each of which can run in its own process, and communicate between services using a lightweight communication mechanism. Where the lightweight communication mechanism is typically an HTTP resource API.

Typically, each mini-service that each application breaks down is built around a particular business. Then, with the development of the Service, some services need to be upgraded, and since the Service Mesh is an infrastructure layer for processing communication between services, it is responsible for realizing reliable transmission of the request, and the Service governance capability and the Service development can be decoupled, so that the developer is more focused on the Service development and innovation. Therefore, when some services decomposed by the application program in the related art are upgraded, the service can be realized through a service grid.

Currently, service grids are implemented by a set of lightweight network agents, and these agents are deployed with applications to proxy incoming or outgoing requests to or from the applications. For example, agents may be Envoy, et al, which is designed as an application layer (also called the L7 layer) agent and a communication bus in a seven layer protocol (also called the OSI model) of a service oriented architecture, and is a separate process that runs with an application program. All envoys form a communication grid transparent to the applications, each of which sends and receives messages locally without perceiving the network topology. However, when upgrading a service resolved by an application program based on the proxy mode of the service grid, there are the following problems: first, the proxy is a stand-alone process, such that service upgrades need to be relayed through the proxy to cause I/O to increase one-hop overhead, such that response time-consuming increases for high performance components such as Redis and the like are significant. Second, because the structure of the existing component protocol is substantially fixed, the extensibility of the enhancement based on the existing component protocol content is poor. Third, if the existing component protocol is adapted, a problem of high maintenance cost is caused. Fourth, one agent needs to be deployed for each application, which can add more deployment resources.

Disclosure of Invention

The service grid, the service upgrading method, the device, the equipment and the medium can upgrade the service in the non-proxy mode of the service grid, do not need to independently deploy proxy processes for each service, and can perform standardized processing on the existing component protocol, so that the existing component protocol has better expansibility and maintainability, thereby improving the service upgrading speed and saving the service upgrading cost.

In a first aspect, the present application provides a service grid, the service grid comprising: the system comprises a service control module, a data plane version management module and an upgrade plug-in, wherein the service control module comprises: a control plane, a data plane and an application interface layer;

the control surface is used for carrying out upgrading and publishing operations on the first service according to the service upgrading list;

the upgrade plug-in is configured to determine a first target application program interface from the application program interface layer according to the upgrade publishing operation, determine a first target implementation having a mapping relationship with the first target application program interface from the data plane version management module, and upgrade the first target implementation according to a version mapping relationship between the first target application program interface and the first target implementation, so as to upgrade the first service;

The first object is implemented as any implementation in the data plane, and a one-to-one relationship between the implementation and the service in the data plane is provided.

In some optional implementations, the version mapping relationship between the application program interface and the implementation in the data plane version management module includes: an implemented declaration file;

wherein the declaration file of the implementation includes: dependency information for data plane attributes.

In some alternative implementations, the declaration file of the implementation further includes: gray scale upgrade strategy.

In some alternative implementations, the service control module further includes: a service plane;

the service plane is configured to determine a second target application program interface from the application program interface layer according to the received service access request, determine, based on the second target application program interface, a second target implementation in the data plane having a mapping relationship with the second target application program interface, and access the second target implementation.

In some alternative implementations, the service control module further includes: a driving surface; the driving surface is used for driving the operation of the data surface.

In some alternative implementations of the present invention,

The data plane is configured with a data plane class loader and a first container;

the service plane is configured with a service plane class loader and a second container;

the application program interface layer is configured with a common class loader and a third container;

the drive face is configured with a drive face class loader and a fourth container.

In some alternative implementations of the present invention,

the first end of the public class loader is connected with the first end of the driving face class loader, and the second end of the public class loader is connected with the business face class loader;

and the second end of the driving surface class loader is connected with the data surface class loader.

In some alternative implementations, the first container, the second container, the third container, and the fourth container are independent of each other;

the first container, the second container, the third container and the fourth container are control inversion containers.

In a second aspect, the present application provides a service upgrade method based on a service grid, where the service grid includes: the system comprises a service control module, a data plane version management module and an upgrade plug-in, wherein the service control module comprises: a control plane, a data plane and an application program interface layer, the method comprising:

Performing upgrading and publishing operation on the first service according to the service upgrading list through the control surface;

determining a first target application program interface from the application program interface layer according to the upgrade release operation through the upgrade plug-in, determining a first target implementation with a mapping relation with the first target application program interface from the data surface version management module, and upgrading the first target implementation according to a version mapping relation between the first target application program interface and the first target implementation so as to upgrade the first service;

In some optional implementations, the upgrading the first target implementation according to the version mapping relationship between the first target application program interface and the first target implementation includes:

Acquiring a statement file of the first target implementation from a version mapping relation between the first target application program interface and the first target implementation;

packaging the declaration file realized by the first target according to a preset packaging structure to obtain an upgrade package;

and upgrading the first target implementation based on the upgrade package.

In some alternative implementations, the declaration file of the implementation further includes: a gray scale upgrading strategy;

correspondingly, the upgrading the first target implementation according to the version mapping relationship between the first target application program interface and the first target implementation includes:

and upgrading the first target implementation according to the gray scale upgrading strategy and according to the version mapping relation between the first target application program interface and the first target implementation.

In some alternative implementations, the service control module further includes: a service plane, the method further comprising:

when the service surface receives a service access request, the service surface determines a second target application program interface from the application program interface layer according to the received service access request;

And determining a second target implementation in the data plane, which has a mapping relation with the second target application program interface, based on the second target application program interface, and accessing the second target implementation.

In some alternative implementations, the data plane includes a plurality of target realizations, and before the accessing the second target realization, further includes:

determining the second target implementation according to the service access request by presetting an implementation screening rule in the data plane;

and displaying and declaring the second target implementation in the data plane.

In a third aspect, the present application provides a service upgrade apparatus based on a service grid, where the service grid includes: the system comprises a service control module, a data plane version management module and an upgrade plug-in, wherein the service control module comprises: control plane, data plane and application program interface layer, including:

the upgrade release module is used for performing upgrade release operation on the first service according to the service upgrade list through the control surface;

the service upgrading module is used for determining a first target application program interface from the application program interface layer according to the upgrading release operation through the upgrading plug-in, determining a first target implementation with a mapping relation with the first target application program interface from the data plane version management module, and upgrading the first target implementation according to the version mapping relation between the first target application program interface and the first target implementation so as to upgrade the first service;

In some optional implementations, the service upgrade module is specifically configured to: acquiring a statement file of the first target implementation from a version mapping relation between the first target application program interface and the first target implementation; packaging the declaration file realized by the first target according to a preset packaging structure to obtain an upgrade package; and upgrading the first target implementation based on the upgrade package.

correspondingly, the service upgrading module is specifically configured to: and upgrading the first target implementation according to the gray scale upgrading strategy and according to the version mapping relation between the first target application program interface and the first target implementation.

In some alternative implementations, the service control module further includes: the service face further comprises:

the second determining module is used for determining a second target application program interface from the application program interface layer according to the received service access request when the service surface receives the service access request;

and the service access module is used for determining a second target implementation with a mapping relation with the second target application program interface in the data surface based on the second target application program interface and accessing the second target implementation.

In some alternative implementations, the method further includes:

a third determining module, configured to determine, according to the service access request, that the second target is achieved by presetting a screening rule in the data plane;

In a fourth aspect, the present application provides an electronic device, including:

a processor and a memory for storing a computer program, the processor being adapted to invoke and run the computer program stored in the memory for performing the service grid based service upgrade method according to the embodiment of the second aspect.

In a fifth aspect, the present application provides a computer-readable storage medium storing a computer program for causing a computer to perform a service grid-based service upgrade method according to the embodiment of the first aspect.

In a sixth aspect, the present application provides a computer program product comprising program instructions which, when run on an electronic device, cause the electronic device to perform a service grid based service upgrade method as described in the embodiments of the first aspect.

The technical scheme disclosed by the embodiment of the application has at least the following beneficial effects:

by providing the service grid without the proxy mode, the service decomposed by the application program is upgraded through the service grid, so that service upgrading can be performed in the service grid without the proxy mode, independent deployment of proxy processes for each service is not needed, and standardized processing can be performed on the existing component protocol, so that the existing component protocol has better expansibility and maintainability, the service upgrading speed can be improved, and the service upgrading cost is saved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic structural diagram of a service grid according to an embodiment of the present application;

FIG. 2 is a schematic diagram of packaging a declaration file according to a preset configuration according to an embodiment of the present application;

FIG. 3 is a schematic diagram of another service grid provided in an embodiment of the present application;

fig. 4 is a schematic structural diagram of each component in a service control module according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a class loader of each component in a service control module according to an embodiment of the present application;

fig. 6 is a schematic flow chart of a service upgrading method based on a service grid according to an embodiment of the present application;

FIG. 7 is a schematic block diagram of a service upgrade apparatus based on a service grid provided in an embodiment of the present application;

FIG. 8 is a schematic block diagram of an electronic device provided by an embodiment of the present application;

fig. 9 is a schematic block diagram of a computer-readable storage medium provided in an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

It should be noted that the terms "first," "second," and the like in the description and the claims of the present invention and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the invention described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or server that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Considering that when the service grid based on the proxy mode performs upgrading operation on the service decomposed by the application program at present, the following problems exist: firstly, the proxy is an independent process, so that the upgrade of the service needs to increase one-hop overhead of I/O through proxy transfer, and the response time consumption of the high-performance component is obviously increased; second, because the structure of the existing component protocol is basically fixed, the expansibility of enhancement based on the content of the existing component protocol is poor; thirdly, if the existing component protocol is adapted, high maintenance cost is caused; fourth, one agent needs to be deployed for each application, which can add more deployment resources. Where deploying one agent for each application corresponds to deploying one agent for each service that is broken down for each application.

In order to solve the technical problems, the technical idea of the invention is as follows: through designing a service grid without proxy, when the service decomposed by the application program needs to be upgraded, the service is upgraded through the service grid, so that service upgrading is realized in a proxy-free mode of the service network, proxy processes do not need to be independently deployed for each service, and meanwhile, the conventional component protocol can be standardized, so that the conventional component protocol has better expansibility and maintainability, the service upgrading speed can be improved, and the service upgrading cost is saved.

Before describing embodiments of the present application in detail, the terms and terminology involved in the embodiments of the present application will be described first, and the terms and terminology involved in the embodiments of the present application are suitable for the following explanation:

service Mesh: the service grid is a dedicated infrastructure layer for handling inter-service communications. It is responsible for reliably delivering requests through complex service topologies including modern cloud-native applications.

Cloud Native (Cloud Native) technology: the method is beneficial to each organization to construct and operate the elastically expandable application in novel dynamic environments such as public cloud, private cloud, mixed cloud and the like. Representative technologies for cloud proto include containers, service grids, micro-services, immutable infrastructure, and declarative APIs.

Application program interface (Application Programming Interface, API): is a convention in which the different components of the software system are joined. The primary purpose of an application program interface is to provide the ability for applications and developers to access a set of routines without having to access source code or understand the details of the internal operating mechanisms.

Proxy (Envoy): an open source edge and service proxy designed for cloud native applications is a high performance proxy software designed for large modern service oriented architecture.

Proxy mode (Proxy), refers to a mode that needs to be deployed in an additional independent process.

The Proxyless mode (Proxyless) refers to a mode that is not deployed in an additional independent process.

Control inversion vessel (Inversion of Control, ioC vessel): to have a container with dependency injection functionality, the IOC container is responsible for instantiating, locating, configuring objects in the application and establishing dependencies between these objects. Wherein the application need not directly build related objects in the code, the application is assembled from IOC containers.

Dependent on injection mode (Compile Dependency Inject, CDI): the method is a mode of the IOC container, and can achieve the purposes of quick instantiation and injection by realizing injection analysis and definition of objects during compiling and directly utilizing the analysis during starting of an application program.

Control surface: the system is a centralized platform of the service grid, is used for coordinating and processing the behavior of the service agent and providing an API for operation and maintenance requirements, so that a user controls and monitors the whole service grid based on the API.

Data plane: all network communications between services, i.e., proxy telecommunications or data caching, are regulated and controlled by a set of intelligent agents (or service agents) deployed with independent spaces. That is, the data plane proxies all communications of the service, etc.

Service plane: refers to the application business code portion. I.e. the implementation part of the application business logic.

Object (Bean): is a class automatically generated by a computer, and is an object instantiated, assembled and managed by a Spring Ioc container. The object may be an example of any java class such as a database connection, a business logic class, and a controller, etc. That is, the Bean is not program edited, but rather is generated by Spring by reflection when the program is running

Having introduced some concepts related to the embodiments of the present application, a service grid, a service upgrade method, an apparatus, a device, and a medium provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

Fig. 1 is a schematic structural diagram of a service grid according to an embodiment of the present application. As shown in fig. 1, the service grid 100 includes: a service control module 110, a data plane version management module 120, and an upgrade plug-in 130. The service control module 110 includes: control plane 11, data plane 12 and application interface layer 13.

The control surface 11 is configured to perform an upgrade and release operation on the first service according to the service upgrade list;

the upgrade plug-in 130 is configured to determine a first target application program interface from the application program interface layer 13 according to an upgrade publishing operation, determine a first target implementation having a mapping relationship with the first target application program interface from the data plane version management module 120, and upgrade the first target implementation according to a version mapping relationship between the first target application program interface and the first target implementation, so as to upgrade the first service;

wherein the first object is implemented as any implementation in the data plane 12 and the implementation in the data plane 12 is in a one-to-one relationship with the service.

The first object described above is implemented as one or more implementations in data plane 12, which is not subject to any limitation in this application, given that there may be overlaps in services that are dependent between different applications.

The above implementation can be understood as an implementation (example) under a service of a control layer in a JAVA development background. Generally, the JAVA development background includes three layers, respectively: model layer model, view layer view, control layer controller.

It should be understood that the first service in the embodiment of the present application may be selected as any micro-service decomposed by any application program. The application program is optionally any application program in the application cluster, which is not limited in this application.

The data plane version management module 120 described above primarily provides application program interface APIs to syntax description standards and version management for each implementation of the impl in the data plane 12. Specifically, the data plane version management module 120 performs syntax description standard and version management and trace operations of the application program interface API to each implementation of the impl in the data plane 12 in a gitOps manner.

That is, the data panel management module 120 may provide a version mapping relationship between the application program interface API and the implementation imageand a declaration file included in the version mapping relationship. Wherein the declaration file includes: the application program interface API to the version declaration file implementing the impl, and the declaration file implementing the impl.

It should be appreciated that the gitOps approach is a persistent delivery approach that deposits the declarative infrastructure and applications of the application system in the Git version library. By taking Git as the core of the delivery pipeline, each developer can submit Pull requests (Pull requests) and use Git to accelerate and simplify application deployment and operation and maintenance tasks. By using Git, a developer can more efficiently focus on creating new functionality rather than operation-and-maintenance related tasks (e.g., application system installation, configuration, migration, etc.).

The upgrade plug-in 130 may be a maven plug-in or other plug-in with service upgrade function, which is not limited in this application.

The number of data planes 12 in the present application is one or more. When the number of data planes 12 is more than one, the object beans between each data plane 12 are set to be not directly accessible to achieve isolation of the object beans. In addition, the plurality of data planes 12 need to be started according to a preset starting sequence and a dependency definition at the time of starting, so as to ensure the normal starting of each data plane 12.

In the present application, the application program interface layer 13 mainly stores application program interface APIs corresponding to each implementation of the image in the data plane 12.

In particular, it is considered that, with the development of the service, the services decomposed by some application programs need to be upgraded to meet the development requirement of the service. Accordingly, by configuring an upgrade schedule for the corresponding service of the application program in the control plane 11 in the service control module 110, so that the control plane 11 can determine whether the current point in time is an upgrade point in time of any service based on the service upgrade schedule. If the control plane 11 determines that the current time point is not the upgrade time point of any one service, service upgrade management and other management operations are continued based on the service upgrade schedule. If the control plane 11 determines that the current point in time is an upgrade point in time of the first service, an upgrade release operation may be performed on the first service.

Furthermore, when the upgrade plug-in 130 that establishes a communication connection with the control plane 11 receives the upgrade issue operation for the first service sent by the control plane 11, the upgrade plug-in 130 may determine the identification information of the first service by analyzing the upgrade issue operation of the first service. Then, the application program interface API corresponding to the identification information of the first service is determined from the application program interface layer 13 storing all the application program interface APIs corresponding to the implementation of the imagebased on the identification information of the first service, so that the application program interface API is determined as the first target application program interface API corresponding to the first service. Next, the upgrade plug-in 130 determines, from the data plane version management module 120, an implementation impl having a mapping relationship with the first target application program interface API based on the first target application program interface API, and determines the implementation impl as the first target implementation impl. Thereafter, the upgrade plug-in 130 determines a version declaration file of the first target application program interface API to the first target implementation impl and a declaration file of the first target implementation impl based on the version mapping relationship between the first target implementation impl and the first target application program interface API provided by the data plane version management module 120. And then, packaging the acquired statement file to obtain an upgrade package. Therefore, the upgrade package is based on the upgrade package to upgrade the first target implementation image from the current version to the new version in the upgrade package, so that the purpose of upgrading the first service is achieved.

In this application, the identification information of the first service may be selected as information capable of uniquely determining the identity of the first service, such as the first service name, the first service ID, etc., which is not limited in this application.

In some alternative implementations, when the upgrade plugin 130 packages the declaration file, the declaration file may be read in real time through a gitlab openapi (network request), and the declaration file is packaged according to the structure shown in fig. 2, so as to obtain an upgrade package of the service.

In this embodiment of the present application, the structure of the upgrade package may be selected as a fat jar. Wherein, the fat Jar is also called a uber-Jar, and is a Jar package containing all dependencies. All dependencies except the java virtual machine (jvm) are embedded in the Jar package. FatJar is an all-in-one Jar package.

The jar (Java Archive file) is a software package file format that allows multiple files to be combined into one compressed file, based on a zip file format, for compressing and publishing, deploying and encapsulating libraries, components and plug-ins, and can be used directly by tools like compilers and JVM.

In some alternative implementations, considering that multiple users may use the first service, by performing the upgrade operation on the first service used by all users at one time, an error may occur in the upgrade, so that the version upgrade of the first service may cause adverse effects such as abnormal use. Therefore, when the first service is upgraded, the upgrade operation is optionally performed based on the gray scale upgrade policy. That is, the present application may set a grayscale upgrade policy in the declaration file implementing the impl. Based on the gray scale upgrading strategy in the declaration file of the realization impl, the realization is firstly carried out on the first service used by one part of users so that the one part of users start to use the new version of the first service, and the other part of users continue to use the current version of the first service, so that after the upgrading of the first service used by one part of users is finished, the version upgrading operation is carried out on the first service used by the other part of users, and finally all users are migrated to the new version of the first service by gradually expanding the use range of the new version of the first service. In this way, the adverse influence range caused by version upgrading can be reduced, so that the upgrading strategy can be dynamically adjusted based on the use feedback of the user in the service upgrading process, and the satisfaction degree of the user for using the service can be improved.

In order to more clearly understand the present application, explanation is made below by way of specific examples.

Illustratively, assuming that the first service that needs to be upgraded is service yy, upgrade plug-in 130 may determine from application program interface layer 13 that the first target application program interface API corresponding to first service yy is API-x1. Further, upgrade plug-in 130 determines a corresponding first target implementation, imal-xa, from data plane version management module 120 based on API-x1, and determines a target declaration file based on a version mapping relationship between API-x1 and imal-xa, as specifically shown in Table 1 below:

TABLE 1

As can be seen from the above table 1, the declaration file determined based on the version mapping relationship between API-x1 and impl-xa includes: version declaration files of API-x1 to impl-xa and declaration files of impl-xa.

The dependency information of the data plane attribute is specifically the jar of the implementation. And, the data plane attribute is specifically: com. Netease. Music: fe-boot-rpc-microaut: 3.2.3

-com.netease.music:obsidian-rpc-client:2.3.2

-com.netease.music:obsidian-rpc:2.3.2

-com.netease.cloudmusic:demote-client:1.4.6

Further, the upgrade plug-in 130 may obtain an upgrade package by packaging the declaration file in table 1, and then perform an upgrade operation on the upgrade package to upgrade the first service yy.

It should be noted that, the service upgrade schedule in the control plane 11 may be dynamically updated according to the service upgrade requirement. For example, the developer manually updates the service upgrade schedule, etc., which the present application does not limit in any way.

In some alternative embodiments, the service control module 110 further includes: service plane 14 and drive plane 15, see fig. 3.

The service plane 14 is configured to determine a second target application program interface from the application program interface layer 13 according to the received service access request, determine a second target implementation in the data plane that has a mapping relationship with the second target application program interface based on the second target application program interface, and access the second target implementation.

The driving surface 15 is used to drive the operation of the data surface 12.

In this application, the driving plane 15 may be understood as an engine plane, and the engine may be alternatively a fence engine.

It should be appreciated that the business surface 14 in the service control module 110 is user-oriented, i.e., the user may perform access operations such as service queries and service applications through the business surface 14, while the data surface 12 is not visible to the user as well as the business surface 14.

Considering that the user performs a service access operation based on service plane 14, the operation of service plane 14 needs to depend on the object beans prepared by data plane 12. Therefore, the data plane 12 is started based on the driving plane 15, and after the data plane 12 is started successfully, the service plane 14 can acquire the second target application program interface API corresponding to the identification information of the service to be accessed from the application program interface layer 13 based on the identification information of the service to be accessed carried by the access request of the user. Business surface 14 may then determine a second target implementation image from data surface version management module 120 based on the second target application program interface API that has a mapping relationship with the second target application program interface API. Thus, the user can access the second object implementation in the data plane 12 to achieve the access objective of the service to be accessed. In this application, the user accesses the second target implementation impl in the data plane 12, specifically accesses the object Bean associated with the second target implementation impl.

The identification information of the service to be accessed may be any information capable of uniquely determining the identity of the service to be accessed, such as the name of the service to be accessed or the ID of the service to be accessed, which is not limited in this application.

The deployment of the data plane 12, the application program interface layer 13, the service plane 14, and the driving plane 15 in the service control module 110 will be described with reference to fig. 4 and 5. As shown in fig. 4, the data plane 12 is configured with a data plane class loader (PanelClassLoader) and a first container (first Ioc container); the service plane 14 is configured with a service plane class loader (serviceslassloader) and a second container (second Ioc container); the application interface layer 13 is configured with a common class loader (common classloader) and a third container (third Ioc container); the driving surface 15 is configured with a driving surface class loader (BootClassLoader) and a fourth container (fourth Ioc container).

The first container, the second container, the third container and the fourth container in fig. 4 are independent from each other; and the first container, the second container, the third container and the fourth container are control reversing containers. The advantage of this is that the data plane 12, the application interface layer 13, the service plane 14 and the driver plane 15 each have separate containers, which serve the purpose of isolating object Bean containers from each other.

In fig. 5, a first end of a common class loader is connected with a first end of a driving class loader, and a second end of the common class loader is connected with a service class loader; the second end of the driving surface class loader is connected with the data surface class loader.

Based on fig. 4 and 5, the data plane 12, the application program interface layer 13, the service plane 14, and the driving plane 15 have the following characteristics:

for the application interface layer 13, the application interface layer 13 is a parent layer in which the application interface APIs of each data plane 12 and the set of application interface APIs of each implementation of the impl in each data plane 12 are placed. The application program interface API set is arranged under a public directory of a public class loader in a jar mode. And, the application program interface API set displays a declaration in the dependency management of the application program in advance, so that any application program interface API in the application program interface layer 13 can be called based on the display declaration. In addition, the common class loader described above is a parent class loader of the data plane class loader in data plane 12 and the traffic plane class loader in traffic plane 14.

For the driving plane 15, the driving plane 15 is a core implementation module of the service grid 100, and is an entry started by the service grid 100, and is used for driving each part in the service grid 100, such as the data plane 12, the service plane 14, and the application program interface layer 13, so that the data plane 13 is started based on the driving of the driving plane 15 to prepare an object Bean that needs to be used for the service plane 14. Referring to fig. 4, the drive face 15 is provided with a separate drive face class loader and fourth IoC container. In this application, the fourth IoC container may be selected by a different technique from the service plane 14, for example, a Compile Dependency Inject type frame is used as the fourth IoC container. And, jar packages of the driver plane 15 can be dynamically parsed and loaded at each build time, and support independent upgrade of the driver plane 15 functionality.

Considering that the IoC container has multi-tenant characteristics, the data plane 12 and the driving plane 15 in the application can be selected as independent tenant containers, so that no additional central processing unit (Central Processing Unit, CPU) and memory are needed on the premise of realizing data isolation and independent upgrading, and conditions are provided for large-scale deployment.

In addition, driver plane 15 may also define a set of standard components for data plane 12 development, i.e., driver plane 15 may define a set of standard formats for data plane 12 that data plane 12 is capable of recognizing, such that data plane 12 builds data plane 12 components based on the standard formats, and is thus relied upon by data plane 12. That is, the driving plane 15 defines a set of standard components for the data plane 12, so that the problem of API standardization of the application program interface of the data plane 12 can be solved, and the expandability and maintainability of the data plane 12 can be improved.

For data plane 12, the data plane 12 has independent data plane class loader and Ioc container, and the parent class loader of the data plane class loader is the driving plane class loader. In addition, jar packages of data plane 12 may be dynamically parsed and loaded at each build time and support independent upgrades of data plane 12 and implementation of the repl functions in upgrade data plane 12.

It is contemplated that two or more object beans may be included within the Ioc container corresponding to one data plane 12, and that a user typically accesses only a portion of the object beans at a time when accessing any object Bean in the data plane 12 based on the business plane 14. Therefore, to avoid that too many object beans are exposed in the data plane 12, data security problems are caused. According to the method and the device, the object beans in the data surface 12 can be accessed according to the service surface 14, and the object beans stated to be accessed are displayed in the data surface 12, so that the problem that the data security is low due to the fact that all object beans in the data surface 12 are displayed and stated can be avoided.

Optionally, an object Bean to be accessed by the service plane 14 is displayed in the data plane 12, and an adjustable declaration rule may be configured in the data plane 12 during development, so that when the data plane 12 receives an object Bean access request of the service plane 14, identification information of the object Bean to be accessed carried by the request to be accessed is firstly analyzed based on the adjustable declaration rule, and then the object Bean to be accessed is declared. Business surface 14 may then access the object Bean to be accessed based on the object Bean declared by data surface 12.

For business surface 14, business surface 14 may be referenced by an application in a dependent manner. And, the parent class loader of the service plane 14 is a common class loader.

It should be noted that, although the jar packets in the service plane 14 and the data plane 12 are both located in the jar class container in the API layer in the present application, the jar space of the service plane 14 is isolated from the jar space of the data plane 12, so that the problem of mutual influence does not occur.

That is, the present application can realize zero performance loss by providing the service management module 110 including the data plane 12 and the service plane 14 in the service grid 100, and communicating the data plane 12 and the service plane 14 in the same virtual machine, so that no additional overhead such as external communication and programming is added. In addition, the deployment of the data plane 12, the application program interface API layer 13, the service plane 14 and the driving plane 15 in the service management module 110 adopts a single container deployment mode, the data plane 12 and the service plane 14 are arranged in the same virtual machine through the service management module to be started, the data plane 12 adopts an asynchronous initialization parallel mode, and the deployment starting time is not additionally increased, so that the service upgrading time can be shortened. In addition, on the premise of ensuring isolation and independent upgrading, no additional CPU and memory are needed, and powerful conditions are provided for large-scale deployment of service grids.

The service grid 100 without proxy mode is constructed based on the service control module 110, the data plane 12 and the application program interface layer 13, the data plane version management module 120 and the upgrade plug-in 130, so that automatic upgrade operation can be realized for any service of an application program through the service grid 100, service upgrade can be performed in the proxy-free mode of the service network 100, proxy processes do not need to be independently deployed for each service, and standardized processing can be performed on the existing component protocol, so that the existing component protocol has better expansibility and maintainability, service upgrade speed can be improved, and service upgrade cost is saved.

Based on the service grid provided by the foregoing embodiment, the present application further provides a service upgrade method based on the service grid. A service upgrade method based on the service grid will be explained with reference to fig. 6. Wherein the service grid comprises: the system comprises a service control module, a data plane version management module and an upgrade plug-in, wherein the service control module comprises: control plane, data plane and application program interface layer.

As shown in fig. 6, the method may include the steps of:

s101, upgrading and publishing the first service according to the service upgrading list through the control surface.

The service upgrade list in the control plane may be selected to be preconfigured in the control plane by a developer according to an upgrade requirement of the application program. And the service upgrade list can be dynamically adjusted according to the function improvement of the application program and the like so as to meet the service upgrade requirements under different conditions.

That is, the control plane in the service grid automatically triggers the upgrade operation of at least one service decomposed from the application program based on the service upgrade list, so that service developer intervention is not needed when service upgrade is performed each time, and service upgrade cost can be saved.

In some alternative embodiments, the present application determines, by the control plane, whether the current point in time is an upgrade point in time for any service based on a pre-configured service upgrade schedule. If the current time point is not the upgrade time point of any one service, the control plane continues to perform service upgrade management and other management operations based on the service upgrade schedule. The control plane may perform an upgrade release operation on the first service if the current point in time is an upgrade point in time of the first service.

S102, determining a first target application program interface from an application program interface layer through an upgrade plug-in according to upgrade release operation, determining a first target implementation with a mapping relation with the first target application program interface from a data surface version management module, and upgrading the first target implementation according to the version mapping relation between the first target application program interface and the first target implementation so as to upgrade the first service.

Wherein the first object is implemented as an arbitrary implementation in the data plane, and the implementation in the data plane is in a one-to-one relationship with the service.

Optionally, if the upgrade plug-in receives the upgrade release operation for the first service sent by the control plane, the upgrade plug-in may determine the identification information of the first service by analyzing the upgrade release operation of the first service. Then, an application program interface API corresponding to the identification information of the first service is determined from the application program interface layers storing the application program interface APIs corresponding to the realization of the impl based on the identification information of the first service, and the application program interface API is determined as a first target application program interface API corresponding to the first service. Next, the upgrade plug-in determines, from the data plane version management module, an implementation impl having a mapping relationship with the first target application program interface API based on the first target application program interface API, and determines the implementation impl as a first target implementation impl. Then, the upgrade plug-in determines a version declaration file from the first target application program interface API to the first target implementation impl and a declaration file of the first target implementation impl based on a version mapping relation between the first target implementation impl and the first target application program interface API provided by the data plane version management module. And further, packaging the statement file to obtain an upgrade package. And then upgrading the first target implementation image from the current version to a new version in the upgrade package based on the upgrade package so as to realize the purpose of upgrading the first service.

In some optional implementations, when the upgrade plugin packages the declaration file, the declaration file is optionally read in real time through a gitlab openapi (network request), and the upgrade package is packaged according to the structure shown in fig. 2.

In this embodiment of the present application, the structure of the upgrade package may be selected as a fat jar.

That is, the version mapping relationship between the application program interface and the implementation in the data plane version management module includes: an implemented declaration file; wherein the declaration file of the implementation includes: dependency information for data plane attributes.

Upgrading the first target implementation according to the version mapping relation between the first target application program interface and the first target implementation, including: acquiring a declaration file of the first target implementation from a version mapping relation between the first target application program interface and the first target implementation; packaging the declaration file realized by the first target according to a preset packaging structure to obtain an upgrade package; and upgrading the first target implementation based on the upgrade package. The preset packaging interface is the fat jar.

In some alternative implementations, considering that multiple users may all use the first service, by performing the upgrade operation on the first service used by all users at one time, an error may occur in the upgrade, which may cause an adverse effect on the version upgrade of the first service. Therefore, when the first service is upgraded, the upgrade operation is optionally performed based on the gray scale upgrade policy. That is, the present application may set a gray scale upgrade policy in the declaration file for implementing the impl, and upgrade the first target implementation according to the gray scale upgrade policy and the version mapping relationship between the first target application program interface and the first target implementation. Therefore, the first service used by one part of users is firstly upgraded, so that the one part of users start to use the new version of the first service, and the other part of users continue to use the current version of the first service, so that after the first service used by one part of users is upgraded, the first service used by the other part of users is upgraded, and the new version of the first service is gradually expanded, so that all users are finally migrated to the new version of the first service. In this way, the adverse influence range caused by version upgrading can be reduced, so that the upgrading strategy can be dynamically adjusted based on the use feedback of the user in the service upgrading process, and the satisfaction degree of the user for using the service can be improved.

The above gray scale upgrade strategy may be understood as a rule or a method for performing upgrade operations on the first service in multiple times according to a preset ratio, which is not limited in this application. The preset ratio may be flexibly set according to the number of users using the first service, for example, the number of users using the first service is 1000, and then the preset ratio may be selected to be 100:200:200:500. That is, the first service is upgraded four times according to the preset ratio of 100:200:200:500, 100 people are randomly selected from 1000 people for the first upgrade, the first service used by the 100 people is upgraded in version, and the remaining 900 people continue to use the first service which is not upgraded. After the first batch of upgrade is completed, a second upgrade is performed, 200 people are randomly selected from the remaining 900 people of the first upgrade, the first service used by the 200 people is upgraded in version, and the remaining 700 people continue to use the first service which is not upgraded. After the second upgrade is completed, the third upgrade is performed to randomly select 200 people from the remaining 700 people of the second upgrade, and version upgrade is performed on the first service used by the 200 people, and the remaining 500 people continue to use the first service which is not upgraded. After the third upgrade is completed, the fourth upgrade is performed to upgrade the version of the first service used by the remaining 500 persons for the third upgrade, thereby realizing a batch-wise gradual upgrade effect on the first service.

The service control module of the service grid provided by the application also comprises a service plane, considering that the service decomposed by the application program can be accessed by a user. Correspondingly, the user can access the service through the service surface, and when the service surface receives the service access request sent by the user, the service surface can firstly analyze the identification information of the service to be accessed carried in the service access request. Further, a second target implementation image having a mapping relation with the identification information of the service to be accessed is obtained from the application program interface API layer based on the identification information of the service to be accessed. And when the second target implementation image is determined, performing access operation on the second target implementation image to realize access operation of the service to be accessed.

It is contemplated that two or more object beans may be included in an Ioc container corresponding to one data plane, and that a user typically accesses only a portion of the object beans at a time when accessing any object Bean in the data plane based on the traffic plane. Therefore, to avoid that too many object beans in the data plane are exposed by the display, data security problems are caused. According to the method and the device for displaying the object Bean, the object Bean which is stated to be accessed can be displayed in the data surface according to the object Bean which is to be accessed by the service surface, so that the problem that the data security is low due to the fact that all object beans in the data surface are displayed and stated can be avoided.

Optionally, an object Bean to be accessed by the service plane is displayed in the data plane, and an adjustable declaration rule can be configured in the data plane during development, so that when the data plane receives an object Bean access request of the service plane, identification information of the object Bean to be accessed carried by the request to be accessed is firstly analyzed based on the adjustable declaration rule, and then the object Bean to be accessed is displayed and declared. The business surface may then access the object to be accessed object Bean to be accessed based on the object Bean declared by the data surface.

That is, before the second objective is achieved by the present application, the method further includes: a screening rule is preset in the data surface, and a second target implementation is determined according to the service access request; the second object implementation display is declared in the data plane. The preset implementation screening rule is the adjustable statement rule.

According to the service upgrading method based on the service grid, the service decomposed by the application program is upgraded through the service grid without the proxy mode, so that service upgrading can be performed in the service grid without the proxy mode, proxy processes do not need to be independently deployed for each service, and meanwhile, standardized processing can be performed on the existing component protocol, so that the existing component protocol has better expansibility and maintainability, service upgrading speed can be improved, and service upgrading cost is saved.

A service upgrade apparatus based on a service grid according to an embodiment of the present application will be described below with reference to fig. 7. Fig. 7 is a schematic block diagram of a service upgrade apparatus based on a service grid according to an embodiment of the present application. In this application, the service grid includes: the system comprises a service control module, a data plane version management module and an upgrade plug-in, wherein the service control module comprises: control plane, data plane and application program interface layer.

As shown in fig. 7, the service upgrade apparatus 200 based on the service grid includes: upgrade distribution module 210 and service upgrade module 220.

The upgrade publishing module 210 is configured to perform upgrade publishing operation on the first service according to the service upgrade list through the control plane;

a service upgrade module 220, configured to determine, by using the upgrade plug-in, a first target application program interface from the application program interface layer according to the upgrade publishing operation, determine, from the data plane version management module, a first target implementation having a mapping relationship with the first target application program interface, and upgrade the first target implementation according to a version mapping relationship between the first target application program interface and the first target implementation, so as to upgrade the first service;

An optional implementation manner of this embodiment of the present application, a version mapping relationship between an application program interface and an implementation in the data plane version management module includes: an implemented declaration file;

An optional implementation manner of the embodiment of the present application, the service upgrade module 220 is specifically configured to: acquiring a statement file of the first target implementation from a version mapping relation between the first target application program interface and the first target implementation; packaging the declaration file realized by the first target according to a preset packaging structure to obtain an upgrade package; and upgrading the first target implementation based on the upgrade package.

An optional implementation manner of the embodiment of the present application, where the declaration file of the implementation further includes: a gray scale upgrading strategy;

correspondingly, the service upgrade module 220 is specifically configured to: and upgrading the first target implementation according to the gray scale upgrading strategy and according to the version mapping relation between the first target application program interface and the first target implementation.

An optional implementation manner of the embodiment of the present application, the service control module further includes: the service plane, the apparatus 200 further includes:

In an alternative implementation manner of the embodiment of the present application, the apparatus 200 further includes:

According to the service upgrading device based on the service grid, the service decomposed by the application program is upgraded through the service grid without the proxy mode, so that service upgrading can be performed in the service grid without the proxy mode, proxy processes do not need to be independently deployed for each service, and meanwhile, standardized processing can be performed on the existing component protocol, so that the existing component protocol has better expansibility and maintainability, service upgrading speed can be improved, and service upgrading cost is saved.

It should be understood that apparatus embodiments and method embodiments may correspond with each other and that similar descriptions may refer to the method embodiments. To avoid repetition, no further description is provided here. Specifically, the apparatus 200 shown in fig. 7 may perform the method embodiment corresponding to fig. 6, and the foregoing and other operations and/or functions of each module in the apparatus 200 are respectively for implementing the corresponding flow in each method in fig. 6, and are not further described herein for brevity.

The apparatus 200 of the embodiments of the present application is described above in terms of functional modules in connection with the accompanying drawings. It should be understood that the functional module may be implemented in hardware, or may be implemented by instructions in software, or may be implemented by a combination of hardware and software modules. Specifically, each step of the method embodiments in the embodiments of the present application may be implemented by an integrated logic circuit of hardware in a processor and/or an instruction in software form, and the steps of the method disclosed in connection with the embodiments of the present application may be directly implemented as a hardware decoding processor or implemented by a combination of hardware and software modules in the decoding processor. Alternatively, the software modules may be located in a well-established storage medium in the art such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, and the like. The storage medium is located in the memory, and the processor reads the information in the memory, and combines the hardware to complete the steps in the method embodiment.

Fig. 8 is a schematic block diagram of an electronic device provided in an embodiment of the present application.

As shown in fig. 8, the electronic device 300 may include:

a memory 310 and a processor 320, the memory 310 being adapted to store a computer program and to transfer the program code to the processor 320. In other words, the processor 320 may call and run a computer program from the memory 310 to implement the service grid-based service upgrade method in the embodiments of the present application.

For example, the processor 320 may be configured to perform the above-described method embodiments according to instructions in the computer program.

In some embodiments of the present application, the processor 320 may include, but is not limited to:

a general purpose processor, digital signal processor (Digital Signal Processor, DSP), application specific integrated circuit (Application Specific Integrated Circuit, ASIC), field programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like.

In some embodiments of the present application, the memory 310 includes, but is not limited to:

volatile memory and/or nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (Double Data Rate SDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), and Direct memory bus RAM (DR RAM).

In some embodiments of the present application, the computer program may be partitioned into one or more modules that are stored in the memory 310 and executed by the processor 320 to perform the methods provided herein. The one or more modules may be a series of computer program instruction segments capable of performing the specified functions, which are used to describe the execution of the computer program in the electronic device.

As shown in fig. 8, the electronic device may further include:

a transceiver 330, the transceiver 330 being connectable to the processor 320 or the memory 310.

The processor 320 may control the transceiver 330 to communicate with other devices, and in particular, may send information or data to other devices or receive information or data sent by other devices. Transceiver 330 may include a transmitter and a receiver. Transceiver 330 may further include antennas, the number of which may be one or more.

It will be appreciated that the various components in the electronic device are connected by a bus system that includes, in addition to a data bus, a power bus, a control bus, and a status signal bus.

The embodiment of the application also provides a computer readable storage medium, which is used for storing a computer program, and the computer program makes a computer execute the service upgrading method based on the service grid according to the method embodiment, and particularly shown in fig. 9. Wherein the computer readable storage medium is 400 in fig. 9 and the computer program is 410.

The embodiment of the application also provides a computer program product containing program instructions, which when run on an electronic device, cause the electronic device to execute the service grid-based service upgrading method of the method embodiment.

When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces, in whole or in part, a flow or function consistent with embodiments of the present application. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

Those of ordinary skill in the art will appreciate that the various illustrative modules and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, and for example, the division of the modules is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple modules or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or modules, which may be in electrical, mechanical, or other forms.

The modules illustrated as separate components may or may not be physically separate, and components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. For example, functional modules in the embodiments of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A service grid, the service grid comprising: the system comprises a service control module, a data plane version management module and an upgrade plug-in, wherein the service control module comprises: a control plane, a data plane and an application interface layer;

2. The service grid of claim 1, wherein the version mapping relationship between the application program interface and the implementation in the data plane version management module comprises: an implemented declaration file;

3. The service grid of claim 2, wherein the declaration file of the implementation further includes: gray scale upgrade strategy.

4. The service grid of claim 1, wherein the service control module further comprises: a service plane;

5. The service grid of claim 1, wherein the service control module further comprises: a driving surface; the driving surface is used for driving the operation of the data surface.

6. The service grid according to any one of claims 1-5, wherein,

7. A service upgrade method based on a service grid, wherein the service grid comprises: the system comprises a service control module, a data plane version management module and an upgrade plug-in, wherein the service control module comprises: a control plane, a data plane and an application program interface layer, the method comprising:

8. A service upgrade apparatus based on a service grid, the service grid comprising: the system comprises a service control module, a data plane version management module and an upgrade plug-in, wherein the service control module comprises: control plane, data plane and application program interface layer, including:

9. An electronic device, comprising:

a processor and a memory for storing a computer program, the processor for invoking and running the computer program stored in the memory to perform the service grid based service upgrade method of any of claims 7.

10. A computer-readable storage medium storing a computer program for causing a computer to execute the service grid-based service upgrade method according to any one of claims 7.