CN117435201A

CN117435201A - Distributed service generation method, system, computing device and storage medium

Info

Publication number: CN117435201A
Application number: CN202210820850.0A
Authority: CN
Inventors: 董克钦
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2022-07-13
Filing date: 2022-07-13
Publication date: 2024-01-23
Also published as: WO2024012101A1

Abstract

The application provides a distributed service generation method, a system, a computing device and a storage medium, wherein the distributed service generation method comprises the following steps: program source code of the application is obtained, the program source code of the application comprises a plurality of marks, and the plurality of marks comprise a first mark for marking a sub-application module in the application and a second mark for marking an interface method in the sub-application module. And compiling the program source codes of the application according to the plurality of marks to obtain the distributed service corresponding to each sub-application module in the application. In this manner, applications may be deployed as distributed services.

Description

Distributed service generation method, system, computing device and storage medium

Technical Field

The present disclosure relates to the field of distributed services, and in particular, to a distributed service generation method, system, computing device, and storage medium.

Background

With the increasing size of applications, an application often needs to be deployed as a corresponding distributed service. At present, the application is usually deployed into the distributed service by using frames such as gRPC, dubbo and Spring Cloud, but the gRPC frame has a relatively lacking function and cannot meet the requirement of the distributed service on multiple slices or multiple copies, and the Dubbo frame and the Spring Cloud frame have the problems of increasing the debugging difficulty of the distributed service and the like. Thus, how to deploy applications as distributed services remains an urgent issue to be addressed.

Disclosure of Invention

The application provides a distributed service generation method, a distributed service generation system, a computing device and a storage medium, which can deploy an application into a distributed service.

In a first aspect, an embodiment of the present application provides a distributed service generating method, where the method includes: program source code of the application is obtained, wherein the program source code of the application comprises a plurality of marks, and the plurality of marks comprise a first mark used for marking a sub-application module in the application and a second mark used for marking an interface method in the sub-application module. And compiling the program source codes of the applications according to the marks to obtain distributed services corresponding to the sub-application modules, wherein the distributed services comprise sub-services realized when the interface methods in the sub-application modules corresponding to the distributed services are executed. It should be appreciated that after each sub-application module in an application is deployed as a distributed service, the application is deployed as a corresponding distributed service.

In a possible implementation manner of the first aspect, compiling the program source code of the application according to the plurality of marks to obtain the distributed service corresponding to the sub-application module includes: compiling the program source code of the application to obtain the business logic of the application; obtaining a calling code of the distributed service according to the plurality of marks by using at least one code generating tool, wherein the calling code of the distributed service is used for indicating a client of the distributed service to call a sub-service on a service side of the distributed service; and combining the business logic of the application, the calling code of the distributed service and the frame code associated with the distributed service to obtain the distributed service. Through the implementation mode, a user does not need to write the calling code of the distributed service, so that the workload of the user is reduced, and compared with the prior art, the method provided by the embodiment of the invention can reduce the development difficulty and cost of the distributed service by writing the program source code related to the business logic of the application and writing the communication code of the distributed service.

In a possible implementation manner of the first aspect, the obtaining, using at least one code generating tool, call codes of distributed services corresponding to the sub application modules according to a plurality of labels includes: and using a remote procedure call (Remote Procedure Call, RPC) server code generation tool to obtain an RPC server according to a plurality of marks, wherein the RPC server is used for providing a service interface for the server of the distributed service, so that the client of the distributed service calls the sub-service on the server of the distributed service through the RPC server.

In one possible implementation manner of the first aspect, the client of the distributed service includes an RPC client. The obtaining, using at least one code generation tool, call codes of the distributed service according to the plurality of marks includes: and obtaining the RPC client according to the plurality of marks by using an RPC client code generating tool, wherein the RPC client obtains sub-services on the service end of the distributed service by calling the RPC service end.

In a possible implementation manner of the first aspect, the server side of the distributed service includes a plurality of copies, and the client side of the distributed service includes a copy client side. The obtaining, using at least one code generation tool, call codes of the distributed service according to the plurality of marks includes: and obtaining a copy client according to the plurality of marks by using a copy client code generating tool, wherein the copy client is used for indicating to call a sub-service on one copy of the plurality of copies. In the implementation manner, the sub-application module in the application can be deployed into the distributed service comprising a plurality of copies, so that the reliability of the distributed service is improved, and the remote call of the service is realized through the copy client.

Further, in the multi-copy scenario, each copy includes one RPC server, and the copy client includes multiple RPC clients, where each RPC client corresponds to one RPC server, which is equivalent to one RPC client corresponding to one copy. Therefore, one RPC client of the plurality of RPC clients can be called through the copy client, and then the corresponding RPC server is called by the RPC client, so that the sub-service on the copy corresponding to the RPC server is called.

In a possible implementation manner of the first aspect, the service end of the distributed service includes a plurality of slices, and the client of the distributed service includes a slice client. The obtaining, using at least one code generation tool, call codes of the distributed service according to the plurality of marks includes: and obtaining the slicing client according to the plurality of marks by using a slicing client code generating tool, wherein the slicing client is used for indicating to call sub-services on at least one slicing in the plurality of slices. Through the implementation manner, the sub-application modules in the application can be deployed into the distributed service comprising a plurality of fragments, so that the capacity and throughput of the distributed service are provided, and the remote invocation of the service is realized through the fragment client.

Further, in a multi-slice scenario, each slice may have at least one copy, where the slice client includes at least one copy client, and each copy client corresponds to one slice, so that part or all of the at least one copy client may be called by the slice client, then the RPC client below the part or all of the at least one copy client may be called by the part or all of the at least one copy client, and then the RPC client may call the corresponding RPC server, thereby calling the service on the copy of the corresponding slice.

In a possible implementation manner of the first aspect, the clients of the distributed service include clustered clients. The obtaining, using at least one code generation tool, call codes of the distributed service according to the plurality of marks includes: and obtaining cluster clients according to the plurality of marks by using a cluster client code generating tool, wherein the cluster clients are used for acquiring state information of the service ends of the distributed services and creating instances of the client ends of the distributed services according to the state information. In this way, the availability of clients of the distributed service may be ensured.

Further, the cluster client may invoke a shard client, a replica client, or an RPC client. Specifically, in a multi-slice scenario, a cluster client invokes a slice client; in a multi-copy scene, a cluster client calls a copy client; in a scenario where the service end of the distributed service is not deployed as multiple slices and multiple copies, i.e. the client end of the distributed service does not include a slice client end and a copy client end, the cluster client end calls the RPC client end.

In a possible implementation manner of the first aspect, the method further includes: and debugging the distributed service according to the calling code of the distributed service. Therefore, the user can conveniently locate and correct the faults of the related codes of the distributed service.

In a second aspect, an embodiment of the present application provides a distributed service generation system, which includes an acquisition unit and a compiling unit. The system comprises an acquisition unit, a storage unit and a storage unit, wherein the acquisition unit is used for acquiring program source codes of an application, the program source codes of the application comprise a plurality of marks, and the marks comprise a first mark used for marking a sub-application module in the application and a second mark used for marking an interface method in the sub-application module; the compiling unit is used for compiling the program source codes of the applications according to the plurality of marks to obtain distributed services corresponding to the sub-application modules, wherein the distributed services comprise sub-services realized when the interface methods in the corresponding sub-application modules are executed.

In a possible implementation manner of the second aspect, the compiling unit is configured to compile program source codes of an application to obtain service logic of the application; obtaining a calling code of the distributed service according to the plurality of marks by using at least one code generating tool, wherein the calling code of the distributed service is used for indicating a client of the distributed service to call a sub-service on a service side of the distributed service; and combining the business logic of the application, the calling code of the distributed service and the frame code associated with the distributed service to obtain the distributed service.

In a possible implementation manner of the second aspect, the compiling unit is configured to obtain, using an RPC server code generating tool, an RPC server according to a plurality of labels, where the RPC server is configured to provide a service interface for a server of the distributed service, so that a client of the distributed service invokes a sub-service on the server of the distributed service through the RPC server.

In one possible implementation manner of the second aspect, the client of the distributed service includes an RPC client. The compiling unit is used for obtaining the RPC client according to the plurality of marks by using an RPC client code generating tool, wherein the RPC client obtains the sub-service on the service end of the distributed service by calling the RPC service end.

In a possible implementation manner of the second aspect, the server side of the distributed service includes a plurality of copies, and the client side of the distributed service includes a copy client side. The compiling unit is used for obtaining a copy client according to the plurality of marks by using a copy client code generating tool, wherein the copy client is used for indicating to call a sub-service on one copy in the plurality of copies.

In a possible implementation manner of the second aspect, the service end of the distributed service includes a plurality of slices, and the client of the distributed service includes a slice client. The compiling unit is used for obtaining the slicing client according to the plurality of marks by using a slicing client code generating tool, wherein the slicing client is used for indicating to call sub-services on at least one slicing in the plurality of slicing.

In a possible implementation manner of the second aspect, the clients of the distributed service include clustered clients. The compiling unit is used for obtaining the cluster client according to the plurality of marks by using a cluster client code generating tool, wherein the cluster client is used for acquiring the state information of the server side of the distributed service and creating an instance of the client side of the distributed service according to the state information.

In a possible implementation manner of the second aspect, the system further includes a debugging unit, where the debugging unit is configured to debug the distributed service according to the call code of the distributed service.

In a third aspect, embodiments of the present application provide a computing device comprising a processor and a memory, the processor executing computer program code in the memory to implement some or all of the methods described in the foregoing first aspect and any implementation of the first aspect.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium storing computer program code which, when executed by a computing device, performs some or all of the methods described in the foregoing first aspect and any implementation manner of the first aspect.

In a fifth aspect, embodiments of the present application provide a computer program product, which may be software or a program product containing instructions, capable of running on a computing device or being stored in any available medium. The computer program product, when run on at least one computing device, causes the at least one computing device to perform some or all of the methods described in the first aspect and any implementation of the first aspect.

Drawings

Fig. 1 is an application scenario schematic diagram of a distributed service generation system provided in an embodiment of the present application;

FIG. 2 is a schematic diagram of a distributed service provided in an embodiment of the present application;

fig. 3 is a schematic flow chart of a distributed service generation method according to an embodiment of the present application;

FIG. 4 is a diagram of a relationship between service codes of an application service in a distributed service according to an embodiment of the present application;

FIG. 5 is a diagram of a relationship between service codes of an application service in another distributed service provided by an embodiment of the present application;

FIG. 6 is a diagram of a relationship between service codes of an application service in another distributed service provided by an embodiment of the present application;

FIG. 7 is a diagram of a relationship between service codes of an application service in another distributed service provided by an embodiment of the present application;

FIG. 8 is a diagram of a relationship between service codes of an application service in another distributed service provided by an embodiment of the present application;

fig. 9 is a schematic structural diagram of a distributed service corresponding to an application Map according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of another distributed service corresponding to an application Map according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of another distributed service corresponding to an application Map according to an embodiment of the present application;

FIG. 12 is a schematic diagram of a distributed service generation system according to an embodiment of the present application;

fig. 13 is a schematic structural diagram of a computing device according to an embodiment of the present application.

Detailed Description

In order to make the technical solution provided in the present application clearer, related terms related to the present application are explained first.

A single application refers to an application in which modules having different functions are integrated in one process. It is a physically tightly coupled implementation, though it performs the functional division of the modules in a logical architecture, which results in the monolithic application being developed as a whole and deployed to specific hardware devices to implement the corresponding functions. Monomer applications have advantages such as easy development and debugging, but with the continuous expansion of application scale, monomer applications also expose more and more problems, such as: the reliability is low (namely, the whole application can be affected by the diffusion when a certain module fails), the maintenance and upgrading cost is high, and the expansibility is poor.

Based on the method, the single application is transformed into a distributed service, and the single application becomes a necessary development trend. The service transformation includes transforming different modules of the single application into independent application services (such as micro services), and the application services can be understood as small services formed by a single application program and are used for being responsible for an independent business logic to complete a part of functions of the application. Moreover, the application services can be independently constructed and deployed, so that each application service included in the application can be decoupled from each other and can be independently replaced, upgraded and stretched, thereby being beneficial to a developer to update and maintain the application, and when a single application service fails, other application services can still work continuously, and the reliability of the application is improved.

Each application service in the application cooperates with each other to realize the functions of the application, in other words, the communication requirements exist between each application service. To address the communication problem between application services, RPC frameworks have been developed.

An RPC framework is a framework that can implement the RPC protocol. The RPC protocol is a protocol that requests services from a remote computer program through a network without knowing the underlying network technology, so using the RPC framework can enable a client to call a remote service interface like a local function.

The RPC framework is mainly composed of four parts: the system comprises a server side, an RPC client side and a client side. Wherein the service end is a provider of the service; the RPC server side is used for providing a service interface for the service on the server side so that the service can be called by the client side; the RPC client is used for calling the service on the server through the RPC server and returning the result to the client so that the client obtains the service; the client is the caller of the service. In a specific implementation, when a client wants to call a service on a server, the client will call an RPC client first, so that the RPC client initiates a service call request to the RPC server, and after receiving the service call request from the RPC client, the RPC server controls the server to implement a corresponding service and returns the service to the client via the RPC client. Thus, the specific process and communication details of the service call can not be perceived by the client and the server through the RPC client and the RPC server.

It should be noted that, when the RPC client and the RPC server communicate (e.g., the RPC client sends a service call request to the RPC server, and the RPC server returns an execution result to the RPC client), the RPC client needs to perform serialization (serialization) and deserialization (deserialization) on the data to be transmitted. The serialization refers to serializing data to be transmitted into byte arrays for network transmission; deserialization refers to the restoration of the byte array read from the network to the original object (i.e., the data to be transmitted) to facilitate subsequent business logic operations.

At present, a distributed service framework is often used to split an application into a plurality of application services, and several distributed service frameworks that implement communication between application services using an RPC framework are described below:

(1) gRPC framework

The gRPC framework is a high-performance and general open source RPC framework, is developed based on ProtoBuf serialization protocol, and supports multiple development languages (such as Java and C). When developing a distributed service using the gRPC framework, a user needs to write a proto file, and then call related commands to generate corresponding codes, a server (i.e., a provider of the service) needs to implement an interface in the codes, and a client (i.e., a caller of the service) needs to call a function in the codes to implement remote call of the service.

While the gRPC framework may enable communication between application services, for a complex distributed service, the application services may be deployed in clusters (i.e., the application service itself is also a distributed service), such as: the application service comprises a plurality of fragments and copies, and the gRPC framework can only solve the communication between the RPC client and the RPC server, but cannot solve the problem of calling the fragments and the copies in the application service.

(2) Dubbo frame

The Dubbo framework is a high performance, lightweight, open source RPC framework that provides remote method invocation, fault tolerance and load balancing, automatic registration of services, automatic discovery of services, and the like. When the Dubbo framework is used to develop the distributed service, the user needs to provide a service registry (such as a ZooKeeper), the service end (i.e. the provider of the service) can issue information (such as a service interface and a service address) to the service registry, and accordingly, the service registry can push relevant information of the service end to the client, so that the client can conveniently call the remote service. In addition, the service interface and the service implementation class are required to be configured at the service end, and the service interface class required to be called is configured at the client end, so that the client end can obtain an example of the packaged service interface, and the remote service is called like local call.

Compared to the gRPC framework, the Dubbo framework proposes a corresponding solution for the invocation of fragments and copies in application services, but in this framework, the application layer protocol used between the client and the server is a proprietary protocol, while the hypertext transfer protocol (hyper text transfer protocol, HTTP) protocol is often used between application services, which makes the coordination between the framework and the application services difficult. In addition, when the framework is Java-based reflection mechanism (reflection) to generate clients, this increases the difficulty of fault localization and code debugging of the distributed service.

(3) Spring Cloud frame

The Spring Cloud framework provides a one-stop solution for micro-service development, which includes various toolkits, such as: configuration management, message bus, service registration and discovery, routing, gateway, security control and fusing, etc. Compared with the gRPC framework, the framework provides a corresponding solution for calling fragments and copies in the application service; in contrast to the Dubbo framework, the framework uses the HTTP protocol as an application layer protocol between the client and the server; the framework is also a Java-based reflection mechanism to generate clients and thus distributed services developed using the framework are more difficult to implement for fault localization and code debugging.

In view of the above problems, embodiments of the present application provide a distributed service generation system capable of deploying an application into a distributed service. In a specific implementation, the system realizes inter-service call based on the RCP framework, but compared with the prior art, in the process of generating the distributed service, codes for realizing inter-service call can be generated, which is equivalent to abstracting the complex realization of the distributed service into the system, in other words, the system can reduce the workload of handwriting codes of users and reduce the development difficulty and cost of the distributed service. In addition, the generated codes are also used for facilitating fault location and debugging of distributed services.

The distributed service generation system may be a compilation aid or a software development kit. Fig. 1 exemplarily shows an application scenario schematic of the distributed service generation system. As shown in fig. 1, a user divides an application into at least one sub-application module based on a function which the application to be developed wants to realize, and determines an interface method in each sub-application module, wherein the sub-application module refers to a functional module in the application and can be used for realizing a part of functions of the application; the interface method refers to a method in the sub-application module, which can be called by other sub-application modules, and can be specifically a function or a method composed of a plurality of functions. And then marking the determined sub-application modules and the interface methods in the sub-application modules in the program source codes of the application, and compiling the marked program source codes by using the distributed service generation system provided by the embodiment of the application. In the compiling process, the distributed service generating system can automatically identify the marks in the program source codes, and compile each sub-application module in the application into corresponding distributed services according to the marks, so that the application is deployed into the corresponding distributed services.

It should be noted that, the above-mentioned sub-application module is a logical concept, and in practical application, a user may divide an application to be developed into at least one sub-application module according to a function and following a rule of "high internal cohesion of the sub-application module and low coupling between the sub-application modules" (i.e. the internal connection of the sub-application modules is tight and the coupling degree between the sub-application modules is low).

By way of example, an application may be deployed as a distributed service 100 as shown in FIG. 2 using the distributed service generation system described above. Wherein the distributed service 100 comprises at least one application service 110 (fig. 2 exemplifies application service a and application service B) and a cluster management node 120.

The application services 110 correspond to sub-application modules in the application, i.e., each sub-application module in the application is deployed as a respective application service 110 after the application is deployed as a distributed service 100. Each application service 110 in the distributed service 100 may be deployed on a different computing node, or two or more may be deployed on the same computing node, where the computing node on which the application service 110 is deployed may include a server, a Virtual Machine (VM), a container, and the like.

Because of the need for communication between the sub-application modules of the application, the application services 110 in the distributed service 100 also need to communicate with each other, and in this embodiment, the at least one application service 110 may communicate with each other through an RPC (i.e. remote service invocation). In addition, it is considered that the sub-application module includes at least one interface method, and thus the application service 110 includes at least one sub-service implemented when the at least one interface method is executed, wherein one interface method corresponds to one sub-service, i.e., executing one interface method implements one sub-service.

In some embodiments, the application service 110 is also a distributed service, as shown in fig. 2, where the application service 110 includes a server and a client, and the server of the application service 110 and the client of the application service 110 are deployed on different computing nodes. Wherein, the service end of the application service 110 is a service provider for providing at least one sub-service included in the application service 110; the client of the application service 110 is a caller of the service and is configured to call the at least one sub-service provided by the service side of the application service 110. It should be noted that, taking an example that the application service B wants to call a sub-service on the application service a, the application service B needs to send a service call request to the client of the application service a, and then the client of the application service a calls the server of the application service a to provide a corresponding sub-service for the application service B.

The service end of the application service 110 includes an RPC service end. The RPC server side is used for providing at least one service interface for the at least one sub-service, one sub-service corresponds to one service interface, and the sub-service can be called through the corresponding service interface. Clients of application service 110 include RPC clients. The RPC client is used for calling the RPC server to obtain the at least one sub-service. For example: the service end of the application service a may provide the service 1 and the service 2, and the RPC service end of the application service a may provide a service interface of the service 1 (hereinafter referred to as service interface 1) and a service interface of the service 2 (hereinafter referred to as service interface 2), and the RPC client of the application service a includes a code for calling the service interface 1 and a code for calling the service interface 2. When the client of the application service a wants to call the service 1, the client of the application service a calls the service interface 1 provided by the RPC server through the RPC client, so that the server of the application service a executes the interface method corresponding to the service 1, and thus, the server of the application service a can provide the service 1 for the client of the application service a.

Optionally, in order to improve the reliability of the application service 110, the service end of the application service 110 includes multiple copies (replicas), where each copy is used to provide the at least one sub-service. In a multi-copy scenario, how to determine which sub-service on the copy needs to be invoked, and how to implement the invocation? For this purpose, the embodiments of the present application propose: each of the plurality of copies includes an RPC server and the clients of the application service 110 include copy clients. The copy client comprises a plurality of RPC clients, each RPC client corresponds to one RPC server, and the corresponding one RPC client corresponds to one copy. In this way, the sub-service on which of the multiple copies is invoked may be indicated by the copy client, namely: the copy client calls one RPC client in a plurality of RPC clients, and the RPC client calls the corresponding RPC server, so as to call the sub-service on the copy corresponding to the RPC server.

Further, to increase the capacity and throughput of the application service 110, the service end of the application service 110 may include a plurality of slices (shards), where each slice is used to provide one or more of the at least one sub-service. In a multi-slice scenario, how to determine which slice of services needs to be invoked, and how to implement the invocation of? For this purpose, the embodiments of the present application propose: the clients of the application service 110 may also include a sharding client, where the sharding client is configured to instruct which of the plurality of shards to invoke a sub-service on.

In some embodiments, each tile may have at least one copy (hereinafter the copy of the tile is simply referred to as a tile copy), i.e., the tile copies of the same tile provide the same service. In a multi-shard and multi-replica scenario, how does it determine which of the services on the sharded replica need to be invoked, and how does it implement the invocation? For this purpose, the embodiments of the present application propose: the slicing client comprises a plurality of replica clients, and each replica client corresponds to one slicing, wherein the slicing client is used for indicating which one or more slicing sub-services in the plurality of slicing are called, and the replica client is used for indicating which slicing replica in one slicing is called, namely: the method comprises the steps that a slicing client calls at least one of a plurality of replica clients, at least one replica client calls an RPC client below the at least one replica client respectively, and the RPC client calls a corresponding RPC server, so that services on the corresponding slicing replica are called.

Optionally, the clients of the application service 110 also include cluster clients. The cluster client establishes a connection (such as a heartbeat connection) with the cluster management node 120, so as to obtain the state information of the service end of the application service 110 from the cluster management node 120, and create an instance of the client (including at least one of the sharded client, the duplicate client and the RPC client) of the application service 110 according to the obtained state information, so that the validity of the client of the application service 110 can be ensured. For example: in the case of multiple slices and multiple copies, the cluster management node 120 may store the slice configuration information of the server side of the application service a (i.e., the server side of the application service a includes 2 slices, each slice has 5 copies), and the cluster client of the application service a may obtain the slice configuration information from the cluster management node 120, and create an instance of the slice client, an instance of 2 copy clients, and an instance of 10 RPC clients according to the slice configuration information, thereby creating the slice client, 2 copy clients, and 10 RPC clients. When the number of fragments of the service end of the application service a increases to 3, the cluster management node 120 updates the locally stored fragment configuration information of the service end of the application service a (in this case, the service end of the application service a includes 3 fragments, each fragment has 5 copies), and correspondingly, the cluster client also obtains the updated fragment configuration information in time, and recreates the instance of the client of the application service a according to the updated fragment configuration information, that is: the instance of the sharded client, the instance of the 3 replica clients and the instance of the 15 RPC clients, thereby creating the sharded client, the 3 replica clients and the 15 RPC clients.

In addition, the cluster client is further configured to receive a service call request sent by the cluster client of the other application service 110, or send a service call request to the cluster client of the other application service 110, so as to implement service call between different application services 110. For example: when the application service B wants to call a sub-service (such as service 1 or service 2) included in the application service a, the cluster client of the application service B sends a service call request to the cluster client of the application service a, and after the cluster client of the application service a receives the service call request, the partition client, the copy client and the RPC client are sequentially called, and then the RPC client calls the corresponding RPC server, so that a service on the service end of the application service a corresponding to the RPC server is called.

The cluster management node 120 is used for a registration (register) service and a discovery (discover) service. Wherein the services herein include at least one sub-service included by the application service 110. "registration service" refers to a service that a service end of application service 110 registers with cluster management node 120 that it can provide, for example: register a service name, service interface, service address, etc. "discovery service" refers to a service provider that a client of application service 110 determines from cluster management node 120 that it wants to invoke. For example: the service end of the application service a may provide the service 1 and the service 2, and the service end of the application service B may provide the service 3, and then the service end of the application service a registers information such as service names, service interfaces, service addresses, and the like of the service 1 and the service 2 with the cluster management node 120, and the service of the application service B registers a service interface of the service 3 with the cluster management node 120, and when the application service B wants to call the service 1, the application service B determines a provider of the service 1 (i.e., the service end of the application service a) from the cluster management node 120, so that the service 1 provided by the service end of the application service a is called through the service interface of the service 1.

The specific process of deploying an application into a distributed service 100 by the above-described distributed service generation system is described below in connection with the distributed service generation method illustrated in fig. 3. Wherein the method is performed by the distributed service generation system described above.

S101: and acquiring the program source code of the application.

Application source code refers to an unencoded text file written in accordance with certain programming language (e.g., java, C language) specifications for implementing a particular function (i.e., the function that a user desires an application to implement), and is a series of human-readable computer language instructions.

The program source code of the application includes a plurality of tags, and optionally, each tag in the plurality of tags may be an annotation (e.g., a Java annotation) to a section of program source code, or program code adjacent to a section of program source code that is provided with a predetermined syntax, where the predetermined syntax is a syntax that can be recognized by the distributed service generation system.

The plurality of labels includes a first label for marking the sub-application module in the application and a second label for marking the interface method in the sub-application module. In this embodiment, a first label is used to label a sub-application module, a second label is used to label an interface method, and the number of first labels and the number of second labels in the plurality of labels may be one or more. In a specific implementation, the first tag may be an annotation added at a location adjacent to the program source code corresponding to the sub-application module, for example: adding corresponding notes on the upper line or the lower line of the program source code for defining the sub application module; alternatively, the first flag may be a program code using a predetermined syntax added at a position adjacent to the program source code corresponding to the sub-application module, for example: at the end of the last line or the same line of program source code used to define the sub-application module, a piece of program code written in a predetermined syntax is added. Likewise, the second tag may be an annotation added at a location adjacent to the program source code corresponding to the interface method, such as: adding corresponding notes on the upper line or the lower line of the program source code for defining the interface method; alternatively, the second flag may be a program code using a predetermined syntax added at a position adjacent to the program source code corresponding to the interface method, for example: at the end of the last line or the same line of program source code for defining the interface method, a piece of program code written in a predetermined syntax is added.

In some embodiments, the distributed service generation system may obtain program source code for an application in one or more of the following ways:

in mode 1, the distributed service generating system provides a file uploading interface (such as an application programming interface (application programming interface, API) or a User Interface (UI)), through which a user can upload program codes of a written application to the distributed service generating system, so that the distributed service generating system can obtain program source codes of the application.

Mode 2, the distributed service generation system provides an online programming interface (e.g., an API or UI) through which a user can write program source code for an application on the distributed service generation system.

Further, the distributed service generation system can prompt the user to add a first mark for a sub-application module in the application and add a second mark for an interface method in the sub-application module when the user writes the program source code of the application.

S102: compiling the program source codes of the application according to the plurality of marks to obtain application services 110 corresponding to each sub-application module in the application, thereby obtaining the distributed service 100 corresponding to the application.

Since the application service 110 is also a distributed service, the "obtaining the application service 110 corresponding to each sub-application module in the application" in this step is equivalent to "obtaining the distributed service corresponding to each sub-application module in the application". However, in order to clearly distinguish between the "distributed service corresponding to an application" and the "distributed service corresponding to a sub-application module", the "distributed service corresponding to a sub-application module" is referred to herein as "application service 110 corresponding to a sub-application module".

In some embodiments, the distributed service generating system compiles program source codes of the applications according to the plurality of marks to obtain application services 110 corresponding to each sub-application module in the applications, thereby obtaining distributed services 100 corresponding to the applications, including: and compiling the program source code of the application by the distributed service generation system to obtain the service logic of the application. The at least one code generating tool is used to obtain the calling code of the at least one application service 110 according to the plurality of marks, where the calling code of each application service 110 is used to instruct a client of the application service 110 to call a sub-service on a service side of the application service 110, and specifically may include at least one of the RPC service side, the RPC client, the replica client, the sharding client, and the cluster client described above. Then, combining the business logic of the application, the calling code of the at least one application service 110 and the frame code associated with the at least one application service 110 to obtain the at least one application service 110, thereby obtaining the distributed service 100 corresponding to the application, wherein the frame code associated with the at least one application service 110 comprises: code related to implementing the functionality of the at least one application service 110, other than the business logic of the application and the invocation code of the at least one application service 110, such as: code for implementing functions of the cluster management node 120, code for implementing data synchronization between multiple copies, code for implementing data migration, and the like, and the frame code associated with the at least one application service 110 may be provided in advance by a developer of the distributed service generation system or provided to the distributed service generation system by the user. In this way, the method is equivalent to decoupling the business logic of the application and the complex implementation of the distributed service 100 (including the calling process between the application services 110 in the distributed service 100), and implementing the complex implementation of the distributed service 100 by the distributed service generation system, thereby simplifying the work of the user (including the user without writing the calling code of the at least one application service 110), and reducing the difficulty and cost of deploying the application into the distributed service 100.

The at least one code generation tool is provided by a distributed service generation system for identifying a plurality of tags in program source code of an application and generating call code for at least one application service 110 based on the plurality of tags, such as: when the plurality of tags are Java annotations, the at least one code generation tool may be a Java self-contained tool (i.e., abstract processor), which can intercept the annotations in the code, and the developer of the distributed service generation system further develops the tool to further have a function of generating the calling code of the at least one application service 110 according to the intercepted annotations, so as to obtain the at least one code generation tool in this embodiment.

In some embodiments, the distributed service generation system uses at least one code generation tool to obtain the calling code of at least one application service 110 from the plurality of tags, including one or more of the following implementations:

mode 1, the at least one code generation tool comprises an RPC server code generation tool, and the plurality of indicia comprises parameters for indicating generation of the at least one RPC server. Then the steps include: the distributed service generation system uses an RPC server code generation tool to obtain at least one RPC server according to the plurality of marks. Each RPC server is configured to provide a service interface for a server of a corresponding application service 110, and in particular, provide a corresponding service interface for each sub-service in the application service 110, so that a client of the application service 110 may call the sub-service on the server of the application service 110 through the RPC server.

More specifically, after obtaining the program source code of the application, the distributed service generating system uses an RPC server code generating tool to determine a plurality of marks from the program source code of the application, then obtains the program source code corresponding to at least one RPC server according to parameters used for indicating to generate the at least one RPC server in the plurality of marks, and compiles the program source code corresponding to the at least one RPC server to obtain the at least one RPC server. It should be noted that, each RPC server is executable code, where the executable code is code obtained by compiling program source code and that can be loaded and executed by a processor (e.g., a central processing unit (central processing unit, CPU)).

Mode 2, the at least one code generation tool comprises an RPC client code generation tool, the plurality of tags comprising parameters for indicating generation of the at least one RPC client. Then the steps include: the distributed service generation system uses an RPC client code generation tool to obtain at least one RPC client according to the plurality of marks. Each RPC client is configured to call a corresponding RPC server to obtain a sub-service on a server of the application service 110 corresponding to the RPC server.

More specifically, after obtaining the program source code of the application, the distributed service generating system uses an RPC client code generating tool to determine a plurality of marks from the program source code of the application, then obtains the program source code corresponding to at least one RPC client according to parameters used for indicating to generate the at least one RPC client in the plurality of marks, and then compiles the program source code corresponding to the at least one RPC client to obtain the at least one RPC client. Wherein the at least one RPC client is executable code.

Mode 3, the at least one code generation tool comprises a replica client code generation tool, and the plurality of indicia comprises parameters for indicating generation of the at least one replica client. Then the steps include: the distributed service generation system uses a replica client code generation tool to obtain at least one replica client from the plurality of tags. Wherein each replica client is configured to instruct invoking a sub-service on one of the plurality of replicas in a case where the service side of the corresponding application service 110 includes the plurality of replicas.

More specifically, after obtaining the program source code of the application, the distributed service generating system uses a copy client code generating tool to determine a plurality of marks from the program source code of the application, then obtains the program source code corresponding to at least one copy client according to parameters used for indicating to generate the at least one copy client in the plurality of marks, and then compiles the program source code corresponding to the at least one copy client to obtain the at least one copy client. Wherein the at least one replica client is executable code.

Mode 4, the at least one code generation tool comprises a sharded client code generation tool, the plurality of indicia comprising parameters for indicating generation of the at least one sharded client. Then the steps include: the distributed service generation system uses a sharded client code generation tool to obtain at least one sharded client from the plurality of tokens. Wherein, each shard client is configured to instruct to invoke a sub-service on at least one of the plurality of shards in a case that the service side of the corresponding application service 110 includes the plurality of shards.

More specifically, after obtaining program source codes of an application, the distributed service generating system uses a slicing client code generating tool to determine a plurality of marks from the program source codes of the application, then obtains the program source codes corresponding to at least one slicing client according to parameters used for indicating to generate the at least one slicing client in the plurality of marks, and compiles the program source codes corresponding to the at least one slicing client to obtain the at least one slicing client. Wherein the at least one shard client is executable code.

Mode 5, the at least one code generation tool comprises a cluster client code generation tool, the plurality of indicia comprising parameters for indicating generation of the at least one cluster client. Then the steps include: the distributed service generation system uses a cluster client code generation tool to obtain at least one cluster client from the plurality of tags. Each cluster client is configured to obtain state information of a corresponding server of the application service 110, and create an instance of the client of the application service 110 according to the state information.

More specifically, after obtaining program source codes of an application, the distributed service generating system uses a cluster client code generating tool to determine a plurality of marks from the program source codes of the application, then obtains the program source codes corresponding to at least one cluster client according to parameters used for indicating to generate the at least one cluster client in the plurality of marks, and then compiles the program source codes corresponding to the at least one cluster client to obtain the at least one cluster client. Wherein the at least one cluster client is executable code.

It should be noted that, details of the RPC server, the RPC client, the replica client, the sharding client, and the cluster client described above may be referred to fig. 2 and the related description thereof, and will not be described herein. However, in order to more clearly understand the functions of the several service codes, an application service 110 is taken as an example, and the relationships between the several service codes are described in connection with fig. 4-8.

As shown in fig. 4, when the service codes of the application service 110 include an RPC service end and an RPC client end, the relationship between the two service codes is: the RPC client invokes the RPC server (specifically, invokes a service interface provided by the RPC server), so that the server of the application service 110 executes an interface method corresponding to the invoked service interface, thereby providing the corresponding sub-service to the client of the application service 110.

As shown in fig. 5, when the service codes of the application service 110 include an RPC service end, an RPC client end, and a cluster client end, the relationship between the three service codes is: the cluster client invokes the RPC client, and the RPC client invokes the RPC server (specifically, invokes a service interface provided by the RPC server), so that the server of the application service 110 executes an interface method corresponding to the invoked service interface, thereby providing the corresponding sub-service to the client of the application service 110.

As shown in fig. 6, in the multi-copy scenario, the service end of the application service 110 includes M copies (that is, copy 1, copy 2, …, copy M, where M is an integer greater than 1), and thus, the service code of the application service 110 includes a copy client, M RPC clients, and M RPC servers, where one copy includes one RPC server and one RPC server corresponds to one RPC client. In addition, in a multi-copy scenario, since the application service 110 is deployed in a cluster, the service code of the application service 110 also includes cluster clients. The relationship between these several service codes is: the cluster client calls the copy client, determines the copy to be called (supposing to be the copy 2) through the copy client, calls the RPC client corresponding to the copy 2 through the copy client, and finally calls the RPC server corresponding to the RPC client (namely, the RPC server included in the copy 2) through the RPC client, so that the copy 2 provides the corresponding sub-service for the client of the application service 110.

As shown in fig. 7, in the multi-slice scenario, the service end of the application service 110 includes N slices (i.e., slice 1, slice 2, …, and slice N, N is an integer greater than 1), and thus, the service code of the application service 110 includes a slice client, N RPC service ends, and N RPC clients, where one slice includes one RPC service end and one RPC service end corresponds to one RPC client. In addition, in the case of multi-shard, since the application service 110 is deployed in the form of a cluster, the service code of the application service 110 also includes a cluster client. The relationship between these several service codes is: the cluster client calls the slice client, the slice to be called (assume to be slice 1) is determined through the slice client, then the slice client calls the RPC client corresponding to the slice 1, and finally the RPC client calls the RPC server corresponding to the slice client (namely, the RPC server included in the slice 1), so that the slice 1 provides corresponding sub-services for the client of the application service 110.

As shown in fig. 8, in the multi-slice and multi-copy scenario, the server of the application service 110 includes N slices (i.e., slice 1, slice 2, …, slice N), each slice includes M copies (i.e., copy 1, copy 2, …, copy M), in other words, the server of the application service 110 includes m×n slice copies (i.e., slice copy 11 (i.e., copy 1 under slice 1), slice copy 12 (i.e., copy 2 under slice 1), …, slice copy 1M (i.e., copy M under slice 1), …, and slice copy NM (i.e., copy M under slice N)). Thus, the service code of the application service 110 includes a cluster client, a sharding client, M replica clients, m×n RPC clients, and m×n RPC servers, where a sharding corresponds to one replica client, a sharding replica includes one RPC server, and one RPC server corresponds to one RPC client. The relationship between these several service codes is: the cluster client calls the slicing client, determines the slicing to be called (assume that the slicing client is slicing 1), then calls the copy client corresponding to the slicing 1 (assume that the slicing client is replica client 1), determines the copy to be called (assume that the copy 2) under the slicing 1 through the copy client 1, calls the RPC client corresponding to the slicing copy 12 through the copy client 1, and finally calls the corresponding RPC server (namely, the RPC server included in the slicing copy 12) through the RPC client, so that the slicing copy 12 provides corresponding sub-services for the client of the application service 110.

It should be appreciated that after the distributed service generation system performs S101-S102 described above, the application may be deployed as distributed service 100. The distributed service 100 includes at least one application service 110, and remote invocation of services between the at least one application service 110 may be accomplished by invocation code of the at least one application service 110. In addition, since the application service 110 is also a distributed service, the application service 110 (i.e., the client of the application service 110 and the server of the application service 110) can also implement remote invocation of the service through the invocation code of the application service 110.

In addition, the distributed service generation system may optionally perform the following steps, considering that the distributed service 100 is typically debugged after development is completed:

s103: the at least one application service 110 is debugged according to the service invocation code of the at least one application service 110, thereby enabling debugging of the distributed service 100.

Specifically, the distributed service generating system debugs at least one application service 110 according to the business logic of the application, the service call code of at least one application service 110, and the frame code associated with at least one application service 110, so as to achieve the purpose of debugging the distributed service 100.

Further, the distributed service generating system may also return a debug result to the user, where the debug result indicates a code with an error (such as a syntax error, a logic error, etc.), so that the user may correct the relevant code according to the debug result to ensure the normal operation of the distributed service 100.

The above-described distributed service generation method is described further below by taking Java as an example.

Before the description, first, the related knowledge related to Java will be briefly introduced: java is an object-oriented programming language, and therefore its core is an object (also called an instance). In Java, an interface is generally declared using a keyword interface, and the interface is a set of methods, that is, the interface includes one or more methods, so when a user writes program source code of an application using Java, a sub-application module in the application may be defined as an interface, and an interface method in the sub-application module may be defined as an interface method in a corresponding interface. In addition, since the method is only declared in the interface and cannot be implemented, but the interface can be implemented by a class, all the interface methods described in the interface can be implemented when the class implements the interface, and thus, for a sub-application module defined as an interface, its specific implementation can be defined as a class. In addition, when the user writes the program source code of the application by using Java, the sub-application module in the application can be directly defined as a class, and the interface method in the sub-application module is defined as a method in the class. However, compared with the former mode, the former mode can lead the programming of the program source code to be more concise and clearer.

The Map in the Java standard library corresponds to a dictionary for storing object (i.e., key) -value pairs) having a mapping relationship. The Map providing method comprises the following steps: put (), get (), and size (), wherein put () is used to add key-value pairs; the get () is used for returning a value corresponding to the designated key; size () is used to query the number of key-value pairs that have been currently stored.

In this embodiment, the Map is used as an application, and a detailed description is given of a process of deploying the Map into the distributed service 100:

firstly, considering that the Map has a single function, the application is not further divided here, in other words, the application only includes a sub-application module, and the sub-application module is the application itself. For convenience in correspondence with the above-described distributed service generation method, "application Map" will be hereinafter referred to as "sub-application module Map". Therefore, when the user writes the program source code of the application using the Java language, the sub application module Map may be defined as an interface IMap, and the class for implementing the interface IMap may be defined as a class mapamp, where the specific definition manner of the interface IMap may be referred to as examples 1 to 3 below.

Example 1:

in the above program source code, "clusteringservice" is an interface predefined by the distributed service generation system, and all sub-application modules that need to generate the calling code of the application service 110 need to implement this interface, so that in the above program source code, the sub-application module Map is represented by asserting the interface IMap to inherit the interface clusteringservice, which is a sub-application module that needs to generate the calling code of the application service 110.

The program source code includes 2 kinds of marks, respectively: @ Cluster, @ ClusterMethod. The mark @ Cluster belongs to a first mark, and is used for marking a sub-application module Map (i.e. an interface IMap); the tag @ Cluster Method belongs to a second tag, and 3 tags are used for marking interface methods put (), get () and size () in the sub-application module Map respectively in the program source code.

In addition to the definition of the interface IMap, the program source code of the sub-application module Map further includes other parts, for example: the program source code of the sub-application module Map further includes a service end of the sub-application module Map (i.e., a service end of the application service 110 in fig. 2, hereinafter abbreviated as MapServer), a client end of the sub-application module Map (i.e., a client end of the application service 110 in fig. 2, hereinafter abbreviated as mapfile), and related program source code of the mapmpl-like implementation interface IMap. Moreover, in order to enable the MapServer to provide services, the user creates an instance of the class mapamp in the main program source code of the MapServer and registers the instance of the class mapamp in the RPC server. Similarly, to enable MapClient to invoke a service on MapServer, the user will also create an instance of the RPC client in MapClient's main program source code and specify the IP address and port number of MapServer in the parameters of the instance.

Optionally, the program source code of the sub application module Map further includes a cluster configuration file, where the cluster configuration file is the code for implementing the function of the cluster management node 120 in S102.

The default parameters of the first mark in the program source code include parameters for indicating to generate the RPC server, parameters for indicating to generate the RPC client, parameters for indicating to not generate the duplicate client, parameters for indicating to not generate the fragment client, and parameters for indicating to generate the cluster client, so that in the compiling process of the program source code of the sub-application module Map, a plurality of code generating tools provided by the distributed service generating system can obtain the RPC server, the RPC client and the cluster client according to the plurality of marks, and cannot obtain the duplicate client and the fragment client. The specific process is as follows:

(1) RPC server

The RPC server code generation tool firstly identifies a mark @ Cluster in the program source code, thereby determining that an RPC server needs to be generated for a sub-application module IMap indicated by the mark; and then sequentially identifying 3 marks @ ClusterMethod in the program source code to obtain an RPC server, wherein the RPC server is used for providing a service interface of an interface method put () (hereinafter referred to as put interface), a service interface of an interface method get () (hereinafter referred to as get interface) and a service interface of an interface method size () (hereinafter referred to as size interface).

(2) RPC client

The RPC client code generating tool firstly identifies a mark @ Cluster in the program source code, thereby determining that the RPC client needs to be generated for the sub-application module Map indicated by the mark; and then sequentially identifying 3 marks @ ClusterMethod in the program source code to obtain an RPC client, wherein the RPC client is used for calling an RPC server and specifically comprises the following steps: the method is used for calling the put interface, the get interface and the size interface provided by the RPC server side, so that the interface method put (), the interface method get (), and the interface method size () are called.

(3) Cluster client

The Cluster client code generating tool firstly identifies a mark @ Cluster in the program source code, so as to determine that a Cluster client needs to be generated for a sub-application module IMap indicated by the mark; and then sequentially identifying 3 marks @ ClusterMethods in the program source codes to obtain a cluster client, wherein the cluster client is used for calling the RPC client so that the RPC client calls a certain interface provided by the RPC server, the cluster client is also used for reading a cluster configuration file and establishing connection with a cluster management node 120 configured in the cluster configuration file, after the connection is established, acquiring state information of a MapServer from the cluster management node 120, and establishing an instance of the RPC client according to the state information of the MapServer.

The RPC server, the RPC client, and the cluster client are call codes of the application service 110 in the S102, so, as shown in fig. 9, after the distributed service generation system obtains the RPC server, the RPC client, and the cluster client, the RPC server, the RPC client, and the cluster client through the service logic of the sub-application module Map, the related framework codes (including codes for implementing functions of the cluster management node 120) are combined, so that the application service 110 corresponding to the sub-application module Map, that is, the distributed service 100 corresponding to the application Map can be obtained.

Example 2:

unlike the program source code given in example 1, the following are: (1) the first token in example 2 also includes a parameter "replica=true" that indicates that the MapServer needs to be deployed in multiple copies, that is, needs to generate a copy client for the sub-application module Map. (2) The second flag for marking the interface method put () in example 2 further includes a parameter "value=write able" for indicating that when the interface method put () on MapServer is called, the interface method put () on the leader (leader) node among the plurality of copies is preferentially called, and after the leader node executes the interface method put (), the following (follower) node among the plurality of copies is notified of data synchronization (i.e., the above key-value is written to the following node).

The default parameters of the first mark in the program source code include parameters for indicating to generate the RPC server, parameters for indicating to generate the RPC client, parameters for indicating to not generate the fragment client and parameters for indicating to generate the cluster client, and in combination with the parameter "replica=true" in the first mark, in the compiling process of the program source code of the sub-application module Map, a plurality of code generating tools provided by the distributed service generating system can obtain the RPC server, the RPC client, the replica client and the cluster client according to the plurality of marks, so that the fragment client cannot be obtained. The procedure of obtaining the RPC client and the cluster client by the distributed service generating system is similar to that of the above example 1, and thus will not be described here, and only the procedure of obtaining the RPC server and the replica client by the distributed service generating system will be described below.

(1) RPC server

The RPC server code generating tool firstly identifies a first mark in the program source code, thereby determining that an RPC server needs to be generated for a sub-application module IMap indicated by the mark; then, 3 second marks in the program source code are identified, so that an RPC server is obtained, where when the second mark (i.e., @ cluster method (value=write table)) for marking the interface method put () is identified, the RPC server code generating tool is used to generate a put () interface, and also is used to start a copy synchronization function at the MapServer. The distributed service generation system then deploys the RPC server for each copy.

(2) Replica client

The copy client code generating tool firstly identifies a first mark (namely @ Cluster (duplicate=true)) in the program source code, so as to determine that a corresponding copy client needs to be generated for the sub-application module Map indicated by the mark; and then sequentially identifying 3 second marks in the program source code to obtain a copy client, wherein the copy client comprises codes for realizing the following functions: when the MapCLIent needs to call the interface method put (), the interface method put () (specifically, the RPC client corresponding to the leader node is called, and then the RPC client calls the RPC server included in the leader node, so as to realize the call of the interface method put () on the leader node is called, after the leader node executes the interface method put (), the key-value pair is recorded in a local pre-written log, and then the following node is notified to perform data synchronization so as to write the key-value pair into the following node. When the MapClient needs to call interface method get () or interface method size, the MapClient selects one copy from the multiple copies according to a load balancing algorithm and calls the interface method get () or interface method size on the copy (specifically, calls an RPC client corresponding to a copy according to the load balancing algorithm, and calls an RPC server included in the copy by the RPC client, thereby realizing the call of the interface method get () or size () on the copy).

The RPC service end, the RPC client end, the replica client end and the cluster client end are call codes of the application service 110 in the S102, so, as shown in fig. 10, after the distributed service generating system obtains the RPC service end, the RPC client end, the replica client end and the cluster client end, the application service 110 corresponding to the sub-application module Map, that is, the distributed service 100 corresponding to the application Map, is obtained by combining the service logic of the sub-application module Map, the RPC service end, the RPC client end, the replica client end and the cluster client end, and related frame codes (including codes for realizing functions of the cluster management node 120 and codes for realizing data synchronization among multiple copies).

Example 3:

unlike the program source code given in example 2, the following are: (1) the first token in example 3 also includes a parameter "shards=shards strategy. CONSISTENT_HASH", which is used to indicate that MapServer needs to be deployed in the form of multiple shards, and the sharding policy that is followed is a consistent HASH (consistent hashing) policy, that is, a sharding client needs to be generated for the sub-application module Map. (2) The second flag for marking the interface method size () in example 3 further includes a parameter "TRAVERSE" for indicating that when MapClient needs to call the interface method size (), the interface method size () on all the copies of the MapServer is called at the same time, and after the interface method size () is executed on the copies of the map server, the execution results are summarized, and the summarized results are returned to the MapClient. For example: mapServer comprises 2 slices (slice 1 and slice 2), each slice comprises 2 copies (copy 1 and copy 2), then the parameter "TRAVERSE" is used to indicate that when MapClient needs to call interface method size (), then both copy 1 under slice 1 (or copy 2 under slice 1) and copy 1 under slice 2 (or interface method size ()'s on copy 2 under slice 2) will be called; after executing interface method size () on copy 1 under slice 1 (or copy 2 under slice 1), obtaining the number of key-value pairs stored in the slice copy, and after executing interface method size () on copy 1 under slice 2 (or copy 2 under slice 2), obtaining the number of key-value pairs stored in the slice copy; then, the sum of the number of key-value pairs stored in the above 2 sliced copies is calculated and the sum value is returned to mapfile. (3) In example 3 "@ Id" is an identification of a key (i.e., "String key" in program source code), and "@ Id" is added before the key to indicate that the key is unique, in a specific implementation, the sharding client determines the shard to be invoked from among the plurality of shards by performing a consistent hash calculation on "@ Id".

The default parameters of the first mark in the program source code include parameters for indicating to generate the RPC server, parameters for indicating to generate the RPC client, and parameters for indicating to generate the cluster client, and parameters of "replica=true" and "shards=shards strategy. The process of obtaining the RPC client, the RPC server, the replica client, and the cluster client by the distributed service generation system is similar to that of example 2, and thus will not be described here, and only the process of obtaining the sharded client by the distributed service generation system will be described below:

the method comprises the steps that a first mark (namely @ Cluster (shards=shards strategy. CONSISTENT_HASH, duplicate=true)) in the program source code is firstly identified by a fragment client code generation tool, so that a fragment client needs to be generated for a sub-application module Map indicated by the mark; and then sequentially identifying 3 second marks in the program source codes to obtain a slicing client, wherein the slicing client comprises codes for realizing the following functions: when the MapClient needs to call the interface method size (), on all the copies of the fragments of the MapServer, is called simultaneously (specifically, the copy client corresponding to each fragment is called simultaneously, then each copy client calls any one of the RPC clients below the copy client, and further calls the RPC server included in each fragment copy, thereby realizing the call of the interface method size (), and after the interface method size () is executed on all the copies of the fragments, the execution results are summarized, and the summarized results are returned to the MapClient. When the MapClient needs to call interface method put () or get (), determining a slice from a plurality of slices according to a consistent hash algorithm and the identifier of a key (namely "@ Id"), and calling the interface method put () or get () (specifically, calling a copy client corresponding to the slice, then calling a certain RPC client below the copy client by the copy client, and calling a corresponding RPC server, thereby realizing the call of the interface method put () and get () on a certain copy below the slice).

The RPC service end, the RPC client, the replica client, the sharding client, and the cluster client are call codes of the application service 110 in the S102, so, as shown in fig. 11, after the distributed service generating system obtains the RPC service end, the RPC client, the replica client, the sharding client, and the cluster client, the application service 110 corresponding to the sub-application module Map, that is, the distributed service 100 corresponding to the application Map, is obtained by combining the service logic of the sub-application module Map, the RPC service end, the RPC client, the replica client, the sharding client, and the cluster client, and related frame codes (including codes for implementing functions of the cluster management node 120, codes for implementing data synchronization between multiple replicas, and codes for implementing data migration).

The functions of the distributed service generation system provided in the embodiments of the present application are described in detail above with reference to fig. 2 to 11, and the detailed description thereof is developed from the structural aspect of the system with reference to fig. 12.

Fig. 12 exemplarily shows a schematic structural diagram of the above-described distributed service generation system. As shown in fig. 12, the distributed service generation system 200 includes an acquisition unit 210 and a compiling unit 220, and optionally, a debugging unit 230. Wherein the obtaining unit 210, the compiling unit 220 and the debugging unit 230 cooperate to implement the steps performed by the distributed service generating system in the above-described method embodiment. Specifically, the acquiring unit 210 is configured to perform S101 described above; the compiling unit 220 is configured to execute S102 described above; the debug unit 230 is configured to perform S103 described above.

In this embodiment, the obtaining unit 210, the compiling unit 220 and the debugging unit 230 may be implemented by software, or may be implemented by hardware. Illustratively, an implementation of the acquisition unit 210 is described next taking the acquisition unit 210 as an example. Similarly, the implementation of compiling unit 220 and debugging unit 230 may refer to the implementation of obtaining unit 210.

As an example of a software functional unit, the acquisition unit 210 may comprise code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container, among others. Further, the above-described computing examples may be one or more. For example, the acquisition unit 210 may include code running on multiple hosts/virtual machines/containers. It should be noted that, multiple hosts/virtual machines/containers for running the code may be distributed in the same region (region), or may be distributed in different regions. Further, multiple hosts/virtual machines/containers for running the code may be distributed in the same availability zone (availability zone, AZ) or may be distributed in different AZs, each AZ comprising a data center or multiple geographically close data centers. Wherein typically a region may comprise a plurality of AZs.

Also, multiple hosts/virtual machines/containers for running the code may be distributed in the same virtual private cloud (virtual private cloud, VPC) or in multiple VPCs. In general, one VPC is disposed in one region, and a communication gateway is disposed in each VPC for implementing inter-connection between VPCs in the same region and between VPCs in different regions.

As an example of a hardware functional unit, the acquisition unit 210 may comprise at least one computing device, such as a server or the like. Alternatively, the acquisition unit 210 may be a device or the like implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (programmable logic device, PLD). The PLD may be implemented as a complex program logic device (complex programmable logical device, CPLD), a field-programmable gate array (FPGA), a general-purpose array logic (generic array logic, GAL), or any combination thereof.

The multiple computing devices included in the acquisition unit 210 may be distributed in the same region or may be distributed in different regions. The plurality of computing devices included in the acquisition unit 210 may be distributed in the same AZ or may be distributed in different AZ. Also, the plurality of computing devices included in the acquisition unit 210 may be distributed in the same VPC or may be distributed in a plurality of VPCs. Wherein the plurality of computing devices may be any combination of computing devices such as servers, ASIC, PLD, CPLD, FPGA, and GAL.

It should be noted that, in other embodiments, the obtaining unit 210 may be configured to perform any of the steps S101 to S103, the compiling unit 220 may be configured to perform any of the steps S101 to S103, the debug unit 230 may be configured to perform any of the steps S101 to S103, the steps that the obtaining unit 210, the compiling unit 220 and the debug unit 230 are responsible for implementing may be specified as needed, and the obtaining unit 210, the compiling unit 220 and the debug unit 230 implement different steps in the distributed service generating method (including the steps S101 to S103) respectively to implement all functions of the distributed service generating system.

The embodiment of the application also provides a computing device. As shown in fig. 13, computing device 300 includes a bus 310, a processor 320, a memory 330, and a communication interface 340. Communication between processor 320, memory 330, and communication interface 340 is via bus 310. Computing device 300 may be a server or a terminal device. It should be understood that embodiments of the present application are not limited in the number of processors, memories in computing device 300.

Bus 310 may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one line is shown in fig. 13, but not only one bus or one type of bus. Bus 310 may include a path for transferring information between various components of computing device 300 (e.g., memory 330, processor 320, communication interface 340).

The processor 320 may include any one or more of a CPU, a graphics processor (graphics processing unit, GPU), a Microprocessor (MP), or a digital signal processor (digital signal processor, DSP).

Memory 330 may include volatile memory (RAM), such as random access memory (random access memory). The processor 320 may also include a non-volatile memory (non-volatile memory), such as read-only memory (ROM), flash memory, a mechanical hard disk (HDD) or a solid state disk (solid state drive, SSD).

The memory 330 stores therein executable program codes that the processor 320 executes to implement the functions of the aforementioned acquisition unit 210, compiling unit 220, and debugging unit 230, respectively, thereby implementing the aforementioned distributed service generation method (including the aforementioned S101 to S103). That is, the memory 330 has stored thereon instructions for performing the distributed service generation method described above.

Communication interface 340 enables communication between computing device 300 and other devices or communication networks using a transceiver module such as, but not limited to, a network interface card, transceiver, or the like.

Embodiments of the present application also provide a computer program product comprising instructions. The computer program product may be software or a program product containing instructions that can be run on a computing device or stored in any available medium. The computer program product, when run on at least one computing device, causes the at least one computing device to perform the distributed service generation method described hereinbefore.

Embodiments of the present application also provide a computer-readable storage medium. The computer readable storage medium may be any available medium that can be stored by the computing device or a data storage device such as a data center containing one or more available media, where the available media may be magnetic media (e.g., floppy disk, hard disk, tape), optical media (e.g., DVD), or semiconductor media (e.g., solid state disk), etc. The computer-readable storage medium includes instructions, wherein the instructions instruct the computing device to perform the distributed service generation method described above, or instruct the computing device to perform the distributed service generation method described above.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting thereof; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; these modifications or substitutions do not depart from the essence of the corresponding technical solutions from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A distributed service generation method, comprising:

acquiring program source code of an application, wherein the program source code of the application comprises a plurality of marks, and the marks comprise a first mark for marking a sub-application module in the application and a second mark for marking an interface method in the sub-application module;

compiling the program source codes of the application according to the plurality of marks to obtain distributed services corresponding to the sub-application modules, wherein the distributed services comprise sub-services realized when the interface method is executed.

2. The method of claim 1, wherein compiling the program source code of the application according to the plurality of tags to obtain the distributed service corresponding to the sub-application module comprises:

compiling the program source code of the application to obtain service logic of the application;

obtaining calling codes of the distributed service according to the plurality of marks by using at least one code generating tool, wherein the calling codes of the distributed service are used for indicating clients of the distributed service to call sub-services on a service side of the distributed service;

And combining the business logic of the application, the calling code of the distributed service and the frame code associated with the distributed service to obtain the distributed service.

3. The method of claim 2, wherein the deriving the call code for the distributed service from the plurality of tags using at least one code generation tool comprises:

and using a Remote Procedure Call (RPC) server code generation tool to obtain an RPC server according to the plurality of marks, wherein the RPC server is used for providing a service interface for the server of the distributed service, so that the client of the distributed service calls the sub-service on the server of the distributed service through the RPC server.

4. The method of claim 3, wherein the clients of the distributed service comprise RPC clients;

the using at least one code generation tool to obtain the calling code of the distributed service according to the plurality of marks includes:

and obtaining the RPC client according to the plurality of marks by using an RPC client code generating tool, wherein the RPC client obtains sub-services on the service side of the distributed service by calling the RPC service side.

5. The method of claim 3, wherein the server of the distributed service comprises a plurality of copies, and wherein the client of the distributed service comprises a copy client;

and obtaining the copy client according to the plurality of marks by using a copy client code generating tool, wherein the copy client is used for indicating to call a sub-service on one copy of the plurality of copies.

6. The method of claim 3, wherein the server side of the distributed service comprises a plurality of shards, and wherein the client side of the distributed service comprises a shard client side;

and obtaining the slicing client according to the plurality of marks by using a slicing client code generating tool, wherein the slicing client is used for indicating to call sub-services on at least one slicing in the plurality of slicing.

7. The method of claim 3, wherein the clients of the distributed service comprise clustered clients;

and obtaining the cluster client according to the plurality of marks by using a cluster client code generating tool, wherein the cluster client is used for acquiring the state information of the service end of the distributed service and creating an instance of the client of the distributed service according to the state information.

8. The method according to any one of claims 2-7, further comprising:

and debugging the distributed service according to the calling code of the distributed service.

9. A distributed service generation system, comprising:

an obtaining unit, configured to obtain program source code of an application, where the program source code of the application includes a plurality of labels, where the plurality of labels includes a first label for marking a sub-application module in the application and a second label for marking an interface method in the sub-application module;

and the compiling unit is used for compiling the program source codes of the application according to the plurality of marks to obtain the distributed service corresponding to the sub-application module, wherein the distributed service comprises the sub-service realized when the interface method is executed.

10. The system of claim 9, wherein the system further comprises a controller configured to control the controller,

the compiling unit is used for compiling the program source codes of the application to obtain service logic of the application; obtaining calling codes of the distributed service according to the plurality of marks by using at least one code generating tool, wherein the calling codes of the distributed service are used for indicating clients of the distributed service to call sub-services on a service side of the distributed service; and combining the business logic of the application, the calling code of the distributed service and the frame code associated with the distributed service to obtain the distributed service.

11. The system of claim 10, wherein the system further comprises a controller configured to control the controller,

the compiling unit is configured to obtain an RPC server according to the plurality of labels by using a remote procedure call protocol RPC server code generating tool, where the RPC server is configured to provide a service interface for a server of the distributed service, so that a client of the distributed service invokes a sub-service on the server of the distributed service through the RPC server.

12. The system of claim 11, wherein the clients of the distributed service comprise RPC clients;

The compiling unit is configured to obtain the RPC client according to the plurality of labels by using an RPC client code generating tool, where the RPC client obtains a sub-service on a service end of the distributed service by calling the RPC service end.

13. The system of claim 11, wherein the server of the distributed service comprises a plurality of copies, and wherein the client of the distributed service comprises a copy client;

the compiling unit is used for obtaining the copy client according to the plurality of marks by using a copy client code generating tool, wherein the copy client is used for indicating to call a sub-service on one copy of the plurality of copies.

14. The system of claim 11, wherein the server side of the distributed service comprises a plurality of shards, and wherein the client side of the distributed service comprises a shard client side;

the compiling unit is configured to obtain the slicing client according to the plurality of labels by using a slicing client code generating tool, where the slicing client is configured to instruct to invoke a sub-service on at least one slice in the plurality of slices.

15. The system of claim 11, wherein the clients of the distributed service comprise clustered clients;

the compiling unit is configured to obtain, using a cluster client code generating tool, the cluster client according to the plurality of labels, where the cluster client is configured to obtain state information of a server of the distributed service, and create an instance of the client of the distributed service according to the state information.

16. The system according to any one of claims 10-15, further comprising:

and the debugging unit is used for debugging the distributed service according to the calling code of the distributed service.

17. A computing device comprising a processor and a memory, the processor executing computer program code in the memory to implement the method of any of the preceding claims 1-8.

18. A computer readable storage medium, characterized in that a computer program code is stored, which, when executed by a computing device, performs the method of any of the preceding claims 1-8.