CN109995713B

CN109995713B - Service processing method in micro-service framework and related equipment

Info

Publication number: CN109995713B
Application number: CN201711485852.4A
Authority: CN
Inventors: 杨健
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2017-12-30
Filing date: 2017-12-30
Publication date: 2020-11-27
Anticipated expiration: 2037-12-30
Also published as: CN109995713A

Abstract

The present application relates to the field of micro-service technologies, and in particular, to a service processing method in a micro-service framework and a related device. The method comprises the steps that a first micro service SDK receives a service calling request, wherein the service calling request carries a service name of a second service, and the second service comprises at least two service instance nodes; and the first micro-service SDK sends the service calling request to a corresponding service instance node in the second service according to a routing distribution rule and service registration information of the second service, wherein the routing distribution rule is a rule set according to the service registration information and distribution parameters, and the service registration information comprises the address of the service instance node and the service name of the second service. According to the embodiment of the application, the shunting parameter is applied to the route shunting rule, after the service calling request is initiated, the first micro service SDK can execute the service shunting rule to shunt the service calling request, and the issuing party and the calling party of the service do not need any additional development, so that the development cost is saved.

Description

Service processing method in micro-service framework and related equipment

Technical Field

The present application relates to the field of micro-service technologies, and in particular, to a service processing method in a micro-service framework and a related device.

Background

Microservices have become a very popular architecture in current enterprise-level development, under which previous monolithic applications are cut into individual services, and Remote Procedure Call (RPC) communication is performed between the services through a microservices framework. The micro-service framework is a framework comprising three parts, namely a service publishing terminal, a service invoking terminal and a service registration center. Micro service Software Development Kit (SDK) is deployed on both the service publishing side and the service invoking side.

The frame may be executed by a publisher of the service to develop a new service using a micro service SDK at a service publishing end, and automatically publish service metadata information to a service registry, where the service metadata information includes a service name, an Internet Protocol (IP), a port, and the like; the service caller requests the relevant information of the service that oneself needs to call to the registration center of the service through the microservice SDK of the service call end; and finally, the service caller initiates remote calling to the corresponding service according to the acquired metadata information (including service name, parameter information, publisher IP and port) of the service. It can be seen that the micro service framework in the process shields various details and complexities of remote network communication for development, and a developer can realize remote method calling like a local calling mode.

For services, in an actual operation process, it is easy to happen that the same service has a plurality of different high and low versions at the same time, services provided by services of different versions may also be different, and for a service caller, the service caller is not aware of the situation, so that a call request issued by a service call terminal needs to be reasonably shunted; in the micro-service architecture, such a service with simultaneous multiple versions may be referred to as a grayscale upgrade, i.e., a way to smoothly transition between the high and low versions of the service. For a received request for the service, the system may offload the request according to some condition, so that the request is forwarded to the corresponding service version, which may be referred to as offload or grayscale offload.

However, since the microservice framework simulates remote invocation as local invocation, encapsulating complex inter-network communication and routing mechanisms in the distributed system, a user can invoke a remote service interface as if invoking a local service interface; however, with the popularity of grayscale upgrading, this advantage of the micro-service framework also brings a problem that the user cannot flexibly control the actual routing of the invocation request. For developers, the gray level splitting logic of each service needs to be coded separately, and in different services, the gray level splitting logic is difficult to abstract and share, and the code of the splitting logic needs to be copied once again.

Disclosure of Invention

The embodiment of the application provides a service processing method in a micro-service framework and related equipment to solve the problems of high development complexity and high development cost of service implementation brought by application gray scale upgrading in the existing micro-service framework.

In the method, a first microservice SDK of a first service receives a service invocation request sent by the first service, the service invocation request is mainly used for initiating service invocation to a second service, the request also carries a name of the second service, and for the second service, the request at least comprises two service instance nodes; when the first micro-service SDK determines that the second service is provided with a routing distribution rule from the service name, the request is distributed according to the routing distribution rule and service registration information and sent to the corresponding service instance node, the service registration information comprises the address of the service instance node and the service name of the second service, the routing distribution rule is specifically a rule set by the service registration center according to the service registration information reported by the second micro-service SDK and distribution parameters, and the service registration information is information registered in the service registration center when the second service is issued.

As can be seen, by setting the offloading parameter, the offloading parameter is applied to the routing offloading rule, and after the first service serving as the service invocation end initiates the service invocation request, the first microservice SDK can execute the service offloading rule to offload the service invocation request; the method is simple, supports micro-service gray level distribution in a service non-invasive way, and has no need of any additional development for a service publisher and a service caller; the cost of subsequent upgrading is low.

In some embodiments, the second service comprises at least two service versions, each said service version corresponding to at least one service instance node. That is, the route splitting rule can be applied to a scenario in which the service versions are different and each service version corresponds to at least one service instance node, so that the request for the second service can be effectively guided.

In some embodiments, the route splitting rule includes a mapping relationship between a value in a value set of a splitting parameter of the second service enabling splitting and a service instance node, that is, one value may correspond to one service instance node, and the route splitting rule further includes a service name of the second service enabling splitting and a service version of the service instance node; the service registration information includes a service name of a second service enabling shunting and a service version of a service instance node, and shunting parameters serving as shunting dimensions act on service interface parameters of the second service, wherein the shunting parameters include names and types of the shunting parameters. Therefore, how the second service is shunted can be known through the routing shunting rule, and the request sent to each version of service instance node in the second service is controlled according to the routing shunting rule.

In some embodiments, the first microservice SDK receives service registration information and a route splitting rule issued by the service registration center, that is, the route splitting rule is issued by the service registration center, and the route splitting rule is a rule generated by the service registration center according to the service registration information and the splitting parameter reported by the second microservice SDK, and the service registration center issues a rule that ensures that the sources of the route splitting rule are consistent, and in addition, the service registration information includes information such as addresses of service instance nodes shown in the route splitting rule, so that the first service can directly access the service instance node.

In some embodiments, before receiving a route splitting rule issued by a service registration center, a first microservice SDK further executes a request operation, that is, the first microservice SDK sends a first request to the service registration center, where the first request carries a service name of the second service, and the request enables the service registration center to determine the route splitting rule corresponding to the service name in the first request; and sending the routing distribution rule to the first microservice SDK. Namely, the method is a mode that the first micro service SDK actively acquires a route distribution rule from the service registration center.

In some embodiments, the first micro service SDK receives first information sent by a service registration center, where the first information is used to notify the first micro service SDK of information on opening or closing offloading of the second service, so that the first micro service SDK can determine whether to open offloading of the current second service, and perform forwarding of a reasonable service invocation request.

In some embodiments, when the first microservice SDK determines, according to the first information, that offloading for the second service is started for the first information, the service invocation request is forwarded according to the route offloading rule. When the default forwarding strategy is set on the first microservice SDK, if the first microservice SDK can confirm that the shunting of the second service is started, forwarding is carried out according to the routing shunting rule, otherwise, forwarding is carried out according to the default forwarding strategy.

In some embodiments, before the first micro-service SDK receives the first information sent by the service center, the first micro-service SDK may further send a second request to the service registration center, where the second request is used to obtain, from the service registration center, information on starting or closing of offloading of the second service, and the second request carries a service name of the second service. That is, for the first information, the first microservice SDK may actively obtain the first information from the service registration center through the second request, or, of course, the first information may be actively sent to the first microservice SDK after the service registration center establishes a connection with the first microservice SDK.

In some embodiments, the first information is included in a route offload rule or the service registration information. That is, in this case, the first information is carried in the route splitting rule and sent, so that for the first microservice SDK, before the route splitting rule is updated, the first information is unchanged, and only when the route splitting rule is updated next time, the first information is carried in the first microservice SDK, so that the first microservice SDK can use the updated first information to determine the split-on status of the second service.

In some embodiments, the route offload rule is a rule that a user configures by invoking an interface provided by the service registry. The service registry comprises an interface and an application program calling interface for the user, and the content edited on the interface by the user can call the corresponding method through the preset application program calling interface.

In some embodiments, the update of the route offload rule is also performed by the user by invoking an interface configuration provided by the service registry, in which case, the first microservice SDK receives the updated route offload rule.

In some embodiments, after receiving the service invocation request sent by the first micro service SDK, the second micro service SDK of the second service further includes a verification process before initiating invocation to the service instance node of the corresponding version, where the verification mainly verifies a route splitting rule of the second service, and when the verification passes, the invocation initiation operation is performed.

A second aspect of the present application further provides a service processing method in a micro service framework, including:

a second micro-service SDK serving as a second service of a service publisher receives a service invocation request sent by a first service serving as a service invoker through a first micro-service SDK of the first service; the service call request is a first micro service SDK of a first service, and initiates service call to a second service according to a routing distribution rule, the second service comprises at least two service instance nodes, the service call request carries a service name of the second service and an address of a target service instance node, the target service instance node is any service instance node of the second service, the routing distribution rule is a rule set by a service registration center according to service registration information and distribution parameters reported by the second micro service SDK, the distribution parameters serving as distribution dimensions are parameters set by the second service through notes, the distribution parameters act on service interface parameters of the second service, and the distribution parameters comprise names and types of the distribution parameters; then the second micro service SDK initiates calling to the service instance node of the corresponding version in the route shunting rule according to the service calling request; in this case, the second microservice SDK may obtain the route splitting rule, and the service registration information includes an address of the service instance node and a service name of the second service.

As can be seen, by setting the offloading parameter, the offloading parameter is applied to the route offloading rule, and after the first service serving as the service invocation end initiates the service invocation request, the first microservice SDK can execute the service offloading rule to offload the service invocation request; the method is simple, supports micro-service gray level distribution in a service non-invasive way, and has no need of any additional development for a service publisher and a service caller; the cost of subsequent upgrading is low.

In some embodiments, in the service release phase, the second microservice SDK receives the service registration information and the offload parameters released by the second service; and then, the second micro service SDK sends the service registration information and the distribution parameters to the service registration center.

In some embodiments, the second service comprises at least two service versions, each of said service versions corresponds to at least one service instance node, and the service registration information comprises a service name of said second service enabling forking and a service version of a service instance node. That is, the route splitting rule can be applied to a scenario in which the service versions are different and each service version corresponds to at least one service instance node, so that the request for the second service can be effectively guided.

In some embodiments, the route splitting rule includes a mapping relationship between a value in a value set of a splitting parameter of the second service enabling splitting and a service instance node, that is, one value may correspond to one service instance node, and the route splitting rule further includes a service name of the second service enabling splitting; and the shunting parameters serving as shunting dimensions act on service interface parameters of the second service, and the shunting parameters comprise names and types of the shunting parameters. Therefore, how the second service is shunted can be known through the routing shunting rule, and the request sent to each version of service instance node in the second service is controlled according to the routing shunting rule.

In some embodiments, after receiving a service invocation request sent by a first service through a first micro service SDK of the first service, a second micro service SDK of a second service further executes a verification step, that is, the second micro service SDK verifies a route splitting rule of the second service, and initiates invocation on the service instance node of the corresponding version according to the route splitting rule when the verification is passed. The design has the advantages that if the received request is found not to be sent by the routing distribution rule, the request can not be processed, so that the processing resource is saved, and the processing efficiency is improved.

A third aspect of the present embodiment further provides a method for processing a service in a micro service framework, where a service registration center first receives service registration information and a offloading parameter sent by a second micro service SDK of a second service, where the service registration information is information registered in the service registration center when the second service is published, the service registration information includes an address of a service instance node of the second service enabling offloading and a service name of the second service, and the offloading parameter serving as an offloading dimension is a parameter set by the second service through an annotation, and the offloading parameter acts on a service interface parameter of the second service; then, the service registration center generates a route distribution rule according to the service registration information and the distribution parameter, wherein the route distribution rule comprises the mapping rule of the service registration information and the distribution parameter; finally, the service registration center can send the route distribution rule and the service registration information to a first micro service SDK of the first service, so that the first micro service SDK sends the service calling request to a service instance node of a corresponding service version according to the route distribution rule, wherein the service registration information is information registered in the service registration center when the second service is issued.

In some embodiments, in a service release stage, a second microservice SDK may receive service registration information and a splitting parameter released by a second service, where the service registration information includes a service name of the second service for which splitting is enabled and a service version of a service instance node, and the splitting parameter serving as a splitting dimension is a parameter set by an annotation for the second service, and the splitting parameter acts on a service interface parameter of the second service, and the splitting parameter includes a name and a type of the splitting parameter; and then, the second micro service SDK sends the service registration information and the distribution parameters to the service registration center, so that the service registration center sets a routing distribution rule according to the service registration information and the distribution parameters.

In some embodiments, the specific step of the service registry generating the route splitting rule according to the service registration information and the splitting parameter may be that the service registry calls an interface of the service registry through a user and sets the route splitting rule according to the service registration information and the splitting parameter received by the service registry. It can be understood that the service registration center provides service registration information and distribution parameters, an interface and an interface, a user can set a route distribution rule for a service according to the resources, and the set route distribution rule of a certain service can be changed on the basis that the service registration information and the distribution parameters are not changed.

In some embodiments, the user may invoke an interface of the service registry and update the route splitting rule according to the service registration information and the splitting parameter received by the service registry, where the update has two cases, one is that the distribution information of the second service enabling splitting is changed and updated; the other is that the published information of the second service is updated without being changed; for the first type, the updated routing distribution rule and the service registration information need to be sent to the first micro service SDK at the same time; for the second kind, only the routing offload rule needs to be sent to the first microservice SDK.

In some embodiments, before the service registration center sends the route splitting rule to the first micro service SDK of the first service, a first request sent by the first micro service SDK may also be received by the service registration center, where the first request carries a service name of the second service; the first request may be a request sent to the service registration center when the first service is initially connected to the service registration center, where the request may carry a name of the second service, and the service registration center determines the corresponding route splitting rule according to the service name. The realizability of the embodiment of the application can be improved.

In some embodiments, after receiving the first request sent by the first microservice SDK, the service registration center may, in addition to directly sending the service name to determine the corresponding route splitting rule, notify the first microservice SDK of information on opening or closing splitting of the second service through the first information, where the information may indicate a forwarding policy of the first microservice SDK. For some scenarios, the first microservice SDK itself stores a default forwarding policy, and after knowing the first information, the first microservice SDK may be responsible for forwarding according to the route split, instead of the default forwarding policy.

In some embodiments, the first information may be obtained in multiple ways, one of which is that the first microservice SDK actively obtains from the service registration center, in this case, the service registration center receives a second request sent by the first microservice SDK, where the second request carries a service name of the second service; the service registration center may determine, according to the second request, opening or closing information of the offload of the second service corresponding to the service name.

In some embodiments, another way for the first micro-service SDK to obtain the first information is further provided, that is, the service registration center includes the first information in the route splitting rule, so that the service registration center notifies the enabling condition of splitting of the second service each time the service registration center issues the route splitting rule to the first micro-service SDK, so that the enabling condition of splitting of the second service on the first micro-service SDK is the latest.

A fourth aspect of the embodiments of the present application provides a client, where the client is a first client disposed on a service invocation end device, and the first server component includes:

a transceiver module, configured to receive a service invocation request sent by the service invocation end device through a first service running on the service invocation end device, where the service invocation request is used to initiate service invocation to a second service issued by a service issue end device, where the service invocation request carries a service name of the second service, and the second service includes at least two service instance nodes;

and the processing module is used for sending the service calling request to a corresponding service instance node in the service publishing terminal through the transceiver module according to a routing distribution rule and service registration information of the second service, wherein the routing distribution rule is a rule set by a server according to service registration information and distribution parameters reported by a second client, the service registration information is information registered in the service registration center when the second service is published, and the service registration information comprises an address of the service instance node and a service name of the second service.

In some embodiments, the second service comprises at least two service versions, each of the service versions corresponding to at least one service instance node.

In some embodiments, the route splitting rule includes a mapping relationship between a value in a value set of a splitting parameter of the second service enabling splitting and a service instance node, and the route splitting rule further includes a service name of the second service enabling splitting and a service version of the service instance node; the service registration information includes a service name of a second service for setting offloading and a service version of the service instance node, and an offloading parameter serving as an offloading dimension acts on a service interface parameter of the second service, and the offloading parameter includes a name and a type of the offloading parameter.

In some embodiments, the transceiver module is further configured to:

and receiving the routing distribution rule and the service registration information sent by the server.

In some embodiments, the transceiver module is further configured to:

sending a first request to the service registration center, so that the server determines a route distribution rule corresponding to a service name in the first request; and sending the route distribution rule to the first client, wherein the first request carries the service name of the second service.

In some embodiments, the transceiver module is further configured to:

and receiving first information sent by a server, wherein the first information is used for notifying the first client of the information on opening or closing the shunting of the second service.

In some embodiments, when the processing module determines that offloading for the second service is started according to the first information, the transceiver module forwards the service invocation request to a corresponding service instance node in the service distributor according to the routing offloading rule.

In some embodiments, before the transceiver module receives the first information sent by the server, the transceiver module is further configured to:

and sending a second request to the server, where the second request is used to obtain information on opening or closing of the offloading of the second service from the server, and the second request carries a service name of the second service.

In some embodiments, the first information is included in the route offload rule or the service registration information.

In some embodiments, when the user updates the configured route forking rule by invoking an interface provided by the service registry, the transceiver module is further configured to:

and receiving the route distribution rule updated by the server.

A fifth aspect of the embodiments of the present application provides a client, where the client is a second client disposed on a service distributor device, and the second client includes:

a transceiver module, configured to receive a service invocation request sent by a service invocation end device through a first client of the service invocation end device, where the service invocation request is a service invocation initiated by a first micro service SDK of a first service to a second service according to a routing splitting rule, the second service includes at least two service instance nodes, the service invocation request carries a service name of the second service, an address of a target service instance node and a service name of the second service, the target service instance node is any one of the service instance nodes of the second service, the routing splitting rule is a rule set by the server according to service registration information and splitting parameters reported by the second micro service SDK, the splitting parameters are parameters set by the service publishing end device through annotations, and the splitting parameters act on service interface parameters of the second service, the shunting parameters comprise names and types of the shunting parameters;

and the processing module is used for calling the corresponding service instance node according to the address of the target service instance node, the second client obtains the route distribution rule, and the route distribution rule is a rule set by the server according to the service registration information and the distribution parameter reported by the second client.

In some embodiments, the transceiver module is further configured to:

receiving service registration information and distribution parameters issued by the service issuing end equipment, wherein the service registration information comprises a service name of a second service on the service issuing end which enables distribution and a service version corresponding to the service instance node, the distribution parameters serving as distribution dimensions are parameters set by the service issuing end equipment through notes, the distribution parameters act on service interface parameters of the second service, and the distribution parameters comprise the name and the type of the distribution parameters;

and the transceiver module sends the service registration information and the distribution parameter to the server so that the server sets a routing distribution rule according to the service registration information and the distribution parameter.

In some embodiments, the route splitting rule includes a mapping relationship between a value in a value set of a splitting parameter of the second service enabling splitting and a version service instance node, and the route splitting rule further includes a service name of the second service enabling splitting and a service version of the service instance node.

In some embodiments, the processing module is further to:

and checking the route distribution rule of the second service, and when the check is passed, initiating call to the service instance node of the corresponding version according to the route distribution rule.

A sixth aspect of the present embodiment provides a server, where the client includes at least one unit configured to execute the service processing method in the micro-service framework provided in the third aspect or any implementation manner of the third aspect.

A seventh aspect of the present embodiment further provides a service processing system in a micro-service framework, where the system includes any one of the fifth aspect or the fifth aspect, which provides a client, and any one of the sixth aspect or the sixth aspect, which provides a server.

An eighth aspect of the embodiments of the present application further provides a communication apparatus, where the communication apparatus may include an entity such as a terminal device or a chip, and the communication apparatus includes: a processor, a memory; the memory is to store instructions; the processor is configured to execute the instructions in the memory to cause the communication device to perform the method of any of the preceding first, second or third aspects.

A ninth aspect of the present embodiment further provides a chip system, which includes a processor, configured to support a network device to implement the functions referred to in the foregoing aspects, for example, to transmit or process data and/or information referred to in the foregoing methods. In one possible design, the system-on-chip further includes a memory for storing program instructions and data necessary for the network device. The chip system may be formed by a chip, or may include a chip and other discrete devices.

Yet another aspect of the present application provides a computer-readable storage medium having stored therein instructions, which when executed on a computer, cause the computer to perform the method of the above-described aspects.

Yet another aspect of the present application provides a computer program product containing instructions which, when run on a computer, cause the computer to perform the method of the above-described aspects.

Drawings

FIG. 1 is a schematic diagram of a micro-service architecture;

FIG. 2 is a schematic diagram of request forking for a microservice framework;

FIG. 3 is a schematic diagram illustrating a service processing method in a micro-service framework according to an embodiment of the present application;

FIG. 4 is a diagram illustrating an embodiment of a method for processing services in a micro-service framework according to an embodiment of the present application;

fig. 5 is a schematic diagram illustrating a process of setting a route splitting rule in a service processing method in a micro-service framework according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a service processing method in a micro-service framework according to an embodiment of the present application applied to IoT;

fig. 7 is a diagram of an embodiment in which a service processing method in a micro-service framework according to an embodiment of the present application is applied to an IoT scenario;

FIG. 8 is a diagram of one embodiment of a client of an embodiment of the present application;

FIG. 9 is a diagram of one embodiment of a client of an embodiment of the present application;

FIG. 10 is a diagram of one embodiment of a server according to an embodiment of the present application;

FIG. 11 is a diagram of one embodiment of a service processing system in a microservice framework of an embodiment of the present application;

fig. 12 is a schematic structural diagram of a server according to an embodiment of the present application.

Detailed Description

The embodiment of the application provides a service processing method and related equipment in a micro-service framework, and by setting a routing distribution rule, a service calling request can be reasonably distributed to a corresponding service instance node, and a service initiator and a service caller can realize gray scale upgrading without any additional development, thereby reducing the development complexity and reducing the cost of development and subsequent service upgrading.

In order to make the technical field better understand the scheme of the present application, the following description will be made on the embodiments of the present application with reference to the attached drawings.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Furthermore, the terms "comprises," "comprising," or "having," and any variations thereof, are intended to cover non-exclusive inclusions, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

The micro-service architecture comprises a service publishing terminal, a service invoking terminal and a service registration center. Referring to fig. 1, fig. 1 is a schematic structural diagram of a microservice architecture, in which a service invocation end and a service distribution end are both connected to a service registration center, and both the service distribution end and the service invocation end are provided with microservice SDKs. The service issuing end is used as one end to which the service provider belongs, provides an access interface (the main flow mode is RPC and Restful API) with a determined format for the outside, and each interface can provide a service function. The service calling end is used as one end to which the service caller belongs, and calls an interface provided by a service issuing end in a remote network communication mode to acquire data or realize functions; the registry of services is one of the typical differences between the microservice framework and the traditional intersystem communication model; the method has the functions of storing metadata information related to the service provided by the service issuing end and providing query capability for the outside.

It should be noted that a mature microservice framework applicable to a production environment will generally have some components for service administration and monitoring of operation and maintenance, but is not the focus of the present application. The micro-service framework is described below by taking a common forum system as an example:

the forum system comprises a user information management module and a login authentication module; the user information management module is responsible for storing and maintaining personal identity and authority information of a user, such as an id, a password, a contact way, a user type and the like, and the login authentication module processes a login request of the user; when a general user logs in a forum, the user firstly accesses a login authentication module, the login authentication module extracts relevant information required by authentication, such as a user id and a password, from a user request, after basic format verification, the login authentication module calls a user information management module to inquire whether the account and the password of the user are matched, if so, the user type (such as a common user, a plate owner or a super manager) is inquired, and then the login authentication module jumps to a corresponding user interface according to the specific user type.

Certainly, after the micro service architecture of such forum system is modified, the user information management module will become a publishing end of the service, and provide the user information query and management service to the outside, and the relevant information of the service (service name, service interface, node IP and port providing the service, and the like, and the relevant concepts are described in detail later) will be published to the registration center of the service by the publishing end of the service; the login authentication module is generally a calling end, acquires the relevant information of the service from the registration center of the service, and calls the service in the code logic to read the user data to complete the authentication work of user login.

In this case, the microservice framework workflow may include the steps of:

1. the publisher of the service uses the microservice SDK to develop new services.

2. The microservice SDK automatically publishes service metadata information (service name, IP, port, etc.) to the service registry.

3. The service caller requests the service registry for the relevant information that the caller needs to invoke the service.

4. And the service caller initiates remote calling to the corresponding service according to the acquired metadata information (including service name, parameter information, publisher IP and port) of the service.

It can be seen that in the whole process, the micro service framework shields various details and complexities of remote network communication for development, and a developer can realize remote method calling like LPC. The micro-service framework mainly aims to meet the requirements of communication and service governance among micro-services, and compared with the traditional communication mode, the micro-service framework provides a simpler programming interface, automatic registration and discovery of services, load balancing, failure retry, isolation, current limiting, fusing and other service governance capabilities.

After using the microservice framework, the communication between remote services will become very simple, and the release end code of the service is as follows, taking Java language as an example:

the section code defines a service name devicemgmservice and a service interface, wherein the service interface comprises device data and a function of inquiring a device history data list, and the list comprises an application ID, a home page value and a page size.

At this time, when the service calling terminal wants to call the service, it only needs to write the following code:

“DeviceMgmtService deviceMgmtService＝ServiceCenter。

getService(DeviceMgmtService。class)；

the calling mode and the access local service interface are the same

List<DeviceData>deviceDataList＝deviceMgmtService。

queryDeviceDataList(“iot_app_1”，1，50)；”

The method for calling the service from the service center through the service name devicemgmservice is defined in the section of code, the calling is identical to the accessing of the local service interface, and the specific parameters of the service interface are that the application ID is "iot _ app _ 1", the home page value is "1", and the page size is "50".

After the micro-service framework is used, the remote communication between services needs to be handled, and socket communication, IO multiplexing, concurrency, thread management, service parameter serialization, transmission, stability, fault detection and the like do not need to be considered by a user, and are handled by the micro-service framework instead.

The gray scale upgrading or gray scale release in the present application is explained below, the gray scale release does not have a clear standard and specification at present, and different organizations and IT practitioners may be used to different names in their respective environments; in microservice architecture, it generally refers to a way to smoothly transition upgrades between high and low versions of a service.

In a gray scale release system, each request in gray scale release is shunted, one type of request which accords with a certain established rule accesses a low version service, and the other type of request accesses a high version service; of course, the actual operation may be divided into multiple service versions, and the request may be divided into multiple categories correspondingly.

The shunting process in the gray scale distribution in the present application is generally referred to as shunting or gray scale shunting; the specific implementation point of the gray level splitting may be different according to different scenes and schemes, and may be implemented at a service publishing end or a service invoking end, but in any case, the gray level splitting generally includes the following key parts:

the first is the dimension of splitting, and for any splitting, a dimension is necessary, and the dimension is mainly used for dividing the request types; for example, in a social application scenario, the dimension of the split is generally the user ID, and in an e-commerce scenario, the dimension of the split may be the order ID; in some anonymous applications, such as search engines, the dimension of the diversion is more suitable for using the request source IP address; in many practical scenarios, the splitting dimension may also be a combination of multiple dimensions.

The second is a forking rule, and after the forking dimension is determined, when the forking is performed, specific rules in the dimension need to be known, for example, a request for forking to the high version service with a user ID less than 10000 or a request for forking to the high version service with a source IP segment of 211.13. -; these rules may be set by the user or may have some default settings. The above is only the most basic principle of gray level shunting, and in actual development, more complex scenes may occur; the core of the shunting in the gray scale distribution lies in the control of the request routing.

It can be seen that the micro-service framework mainly simulates remote invocation as local invocation, encapsulates complex inter-network communication and routing mechanisms in the distributed system, and enables a user to invoke a remote service interface as a local service interface, thereby greatly simplifying the difficulty of network programming. In the micro service framework, if offloading is to be performed, the request offloading schematic diagram shown in fig. 2 and the micro service framework in fig. 2 may be adopted, and it can be seen that, if serviceA needs to request serviceB, if service B has two versions, such as serviceB _ v1 and serviceB _ v 2.

For example, if the offloading is performed according to the device ID, the identifier field of the offloading may be set to device ID, and at this time, the following code needs to be written:

in the segment of code, if the device id in the request is compliant with the devicedet, the flow is branched to the service b _ v2, and if not, the flow is branched to the service b _ v 1.

For another example, if the splitting is performed according to the user ID, the identifier field of the splitting may be set to the user ID, and the code that needs to be written at this time is as follows:

in the segment of code, if the user id in the request is the user id set, the flow is branched to the serviceB _ v2, and if not, the flow is branched to the serviceB _ v 1.

It can be seen that setting gray level shunting in the current micro-service framework, for each service, a developer needs to write a code to implement, the above parts are only key parts for implementing the scheme, and in actual development, how to obtain shunting dimension fields from service invocation requests, how to set, store and distribute shunting rules, how to implement shunting logic as universal as possible, and the like, all need to be handled by the developer, so that the development process is a complex and huge working process.

As can be concluded from the above analysis, the current implementation of gray-scale splitting in the microservice framework has the following problems.

1. Grayscale shunting implementations are opaque to service developers, who need to encode the shunting logic themselves.

2. The gray level shunting logic is difficult to abstract and use, and the code needs to be copied once every time a caller of a service is added; the logic also needs to be implemented once for each new service invoked, and the different services are difficult to multiplex.

3. All the callers must be matched with the change and reissued when any shunting field and shunting logic of the service issuing end are changed; for the basic principle of inter-microservice decoupling.

4. Due to the difference of application scenes, different services have various different implementation schemes when realizing the gray level distribution of the micro service, and the different schemes have no portability.

In view of the foregoing problems, an embodiment of the present application provides a method for processing a service in a micro-service framework, where sampling of the method is similar to the architecture shown in fig. 1, and no additional component is needed, and in the method, a forking parameter Greykey is introduced, where the Greykey corresponds to a forking dimension and is used to identify which dimensions are used for forking in a forking process. Please refer to fig. 3 and fig. 4, fig. 3 is a schematic diagram of a service processing method architecture in a micro-service framework of the embodiment of the present application, fig. 4 is an embodiment diagram of a service processing method in a micro-service framework of the embodiment of the present application, fig. 3 also includes a service registration center, a ServiceB as a service publishing end, and a ServiceA as a service calling end, the ServiceB also includes at least two service versions, for example, in fig. 3, two versions including a ServiceB _ V1 and a ServiceB _ V2 are included in the architecture of the method of the embodiment of the present application, a ServiceB _ V1 corresponds to two service instance nodes, a ServiceB _ V2 corresponds to one service instance node, and service interfaces provided by the ServiceB _ V1 and the ServiceB _ V2 are the same but the implementation logic is not through; the dashed lines in fig. 3 represent the service publishing and registration process, and the solid lines represent the service invocation process. The processing procedure of the method of the embodiment of the present application applying the architecture shown in fig. 3 is shown in fig. 4, and the method includes:

401. the first micro service SDK of the first service receives a service calling request sent by the first service. The service invocation request is used for initiating service invocation to a second service, the service invocation request carries a service name of the second service and an address of a service instance node, the second service in the embodiment includes at least two service instance nodes, and a routing splitting rule can map a splitting parameter of a first service with the service name or the address of the service instance node, for example, the splitting parameter is a device ID of a device using the first service or a user ID of a user using the first service, so that the service invocation request can be sent to the corresponding service instance node according to the binding relationship during routing splitting. Wherein the address of the service instance node may be a network address, such as an IP address or the like

Optionally, the second service includes at least two service versions, and each service version corresponds to at least one service instance node. In the routing offloading rule, the service version may be mapped with an offloading parameter, so that the second service of which version the service invocation request is specifically sent to may be determined according to the offloading parameter.

It should be noted that the route splitting rule includes a mapping relationship between a value in a value set of a splitting parameter of the second service enabling splitting and a service instance node, that is, which value corresponds to which service instance node of which service version, and different values may correspond to different service instance nodes of different service versions or different service instance nodes of the same service version. And all the set of values can correspond to the service instance nodes of all the service versions.

In addition, the route splitting rule further comprises a service name of the second service enabling splitting; the service registration information comprises a service name of a second service for setting shunting and a service version of a service instance node, shunting parameters serving as shunting dimensions act on service interface parameters of the second service, and the shunting parameters comprise names and types of the shunting parameters.

It should be noted that, in the scenario of this embodiment, before the first service is connected to the service registry for the first time, the first service only knows that the second service is disposed on the service registry, and the first service knows the name of the second service, but does not know whether the second service is registered on the service registry and can be called. Therefore, when the first service is connected to the service registration center for the first time, a first request is sent to the service registration center, the destination address of the request is the address of the service registration center, then, when the service registration center receives the service call request, whether the corresponding second service is issued or not is determined according to the service name, and the second service is provided with a route distribution rule, if yes, the service registration center sends the route distribution rule and service registration information registered by the second service on the service registration center to the first microservice SDK, and the service registration information comprises the addresses of service instance nodes of the second service. After the above process is completed, the service invocation request is sent to the second service in step 401, so that the first microservice SDK can correctly send the service invocation request to the corresponding service instance node by combining the address of each service instance node when executing the route splitting rule.

Certainly, the service registration information and the route distribution rule issued by the service registration center are not always directly sent to the first microservice SDK, and an intermediate node may be further configured, and when the first microservice SDK needs to acquire the service registration information and the route distribution rule, the service registration information and the route distribution rule may be directly acquired from the node.

Optionally, after sending the first request, the first microservice SDK may further receive first information sent by a service registration center, where the first information is used to notify the first microservice SDK of the opening or closing information of the offloading of the second service, and after having the first information, the first microservice SDK forwards the service invocation request according to the route offloading rule when the first microservice SDK determines, according to the first information, that the offloading for the second service is opened for the first information. When the default forwarding strategy is set on the first microservice SDK, if the first microservice SDK can confirm that the shunting of the second service is started, forwarding is carried out according to the routing shunting rule, otherwise, forwarding is carried out according to the default forwarding strategy.

It should be noted that the first information may be acquired by the first microservice SDK in three ways; first, the service registry can actively send the first microservice SDK; second, a second request may be sent from the first microservice SDK to the service registry, and the second request may cause the service registry to send the first information to the first microservice SDK. Certainly, in another mode, the service center carries the first information in the routing offload rule or the service registration information, and sends the first information to the first microservice SDK.

Please refer to fig. 5, wherein fig. 5 is a schematic diagram illustrating a process of setting a routing offload rule in a service processing method in a micro service framework according to an embodiment of the present application. The process may include:

501. the second service calls the second micro service SDK to issue the service, and sets the shunt parameters acting on the service interface of the second service in an annotation mode.

In the process that the second service calls the second micro-service SDK to issue the service, some service registration information and the offloading parameter are sent to the second micro-service SDK, for example, the service name and the service version of the second service, and the name and the type of the offloading parameter. It should be noted that the second service may be only one service, or may be a set capable of carrying multiple services, and in this embodiment, the description is given by taking only the second service as one service and the service as a service that needs to be configured to offload; if the second service includes a plurality of services, the process of setting the route splitting rule of a certain service that needs to be split is similar to that of this embodiment, and details are not described here.

For example, in a Java environment, the forking parameter Greykey exists in the code in the form of a comment, and the comment can be marked on a parameter field of a service call method that needs to be shunted; for example, taking the code of the issuing end as an example, after adding the Greykey annotation mode, the code is changed into the following mode:

as can be seen from the above codes, annotation of a shunting parameter GreyKey is performed on both appId of a string type and deviceId of the string type to identify shunted dimension field information; the two annotations correspond to the service interface queryDeviceDataList and the service name DeviceDataService.

It should be noted that, the above example annotates with the GreyKey, and actually, the GreyKey is only one identifier, and the same effect can be achieved by using other character strings for identification, as long as the character strings in the service registration center, the service publishing end, and the service invoking end are predefined as annotation shunting parameters.

502. And the second micro-service SDK receives the service registration information and the distribution parameters issued by the second service and sends the service registration information and the distribution parameters to the service registration center.

The service registration information may include a service version and a service name of the enabled offloading service, and the offloading parameter may include a parameter name and a parameter type of the offloading parameter; after acquiring the service registration information and the offloading parameter, the second microservice SDK sends the service registration information and the offloading parameter to the service registration center.

503. And the user calls an interface of the service registration center and configures a routing distribution rule through the service registration information and the distribution parameter.

Wherein, an entrance for setting shunting rules is provided for a user in the service registry, and comprises a Portal interface and a Restful API; portal is an interface, Restful API is a functional structure interface, and a user can set the value range of the shunt field to the service registry through the Portal interface and the API. The route distribution rule configured by the user comprises the service name for starting distribution and the mapping relation between the value in the value set of the distribution parameter and the service instance node. For example, a route splitting rule may be a how far group like:

{serviceName，Set<Map<key，Value>，version>}

the routing distribution rule comprises a service name servername, wherein the mapping relation Set of values in a Value Set of a distribution parameter and service instance nodes is Set < Map < key, Value > and version >, wherein the key represents the name of the distribution parameter, such as userID or deviceiD, and the name is only used as the identifier of the distribution parameter, the Value is the type of the distribution parameter, the version is the service version of a second service, and the values of the key and the Value can be mapped with each version through the Set < Map < key, Value > and version >, so that the routing distribution rule is formed.

504. And the service registration center sends the configured route distribution rule and the service registration information to the first micro service SDK.

After the generation of the route distribution rule is completed, the route distribution rule and the service registration information are sent to the first micro-service SDK together, so that the first micro-service SDK can acquire the address of the service instance node of the second service through the service registration information and send a service calling request to the corresponding service instance node according to the route distribution rule.

505. The first microservice SDK stores the route splitting rule.

It should be noted that, when the routing offload rule needs to be changed, step 506, step 507, and step 508 similar to step 503, step 504, and step 505 may be executed again, the offload rule is set again through step 506, the updated routing offload rule is sent to the first microservice SDK through step 507, and finally, in step 508, the first microservice SDK also stores the updated routing offload rule correspondingly.

402. And the first micro-service SDK judges whether the service is provided with a routing distribution rule or not according to the service name in the service calling request, if so, the step 403 is executed, and if not, the service corresponding to the service name is forwarded.

After receiving the service call request, the first microservice SDK determines whether a route distribution rule is set for the service of the service name according to the service name, and executes different branches. The format of the route splitting rule is as described in step 503, and the first microservice SDK can determine whether the service has the route splitting rule only by comparing the service name with the route splitting rule.

403. And the first micro-service SDK sends the service calling request to a corresponding service instance node in the second service according to a routing distribution rule and service registration information.

The first micro-service SDK acquires the route distribution rule, and the route distribution rule is a rule set by the service registration center according to the service registration information and the distribution parameters reported by the second micro-service SDK. The service registration center comprises a service name, a service version of the service instance node and an address of the service instance node, so that after the corresponding service instance node is obtained from the routing distribution rule, a service calling request can be sent to the service instance node according to the service registration information, and the destination address of the request is the obtained address of the service instance node.

404. And the first micro service SDK receives a call return result returned by the second service.

And the calling return result is a return result obtained by calling a service instance node of a corresponding version of the second service after the second micro-service SDK of the second service receives the service calling request, and the routing distribution rule is stored in the second micro-service SDK.

It should be noted that, after receiving the service invocation request, the second microservice SDK may check the route splitting rule of the service invoked by the service invocation request, call the service instance node corresponding to the route splitting rule only if the check is passed, after receiving the invocation request, the second service initiates invocation on the upper layer service logic, and then returns the execution result to the second microservice SDK, which returns the invocation result returned by the corresponding service instance node to the first microservice SDK.

405. And the first micro service SDK returns the calling return result to the first service.

After receiving the return result corresponding to the service invocation request, the first microservice SDK returns the invocation result to the first service to complete the execution process of the service invocation request.

It should be noted that step 404 and step 405 are optional steps in the embodiment of the present application, and after steps 401 to step 403 are completed, offloading of different service instance nodes or different service instance nodes of different versions can be already solved.

The following describes a service processing method in the micro service framework according to the embodiment of the present application by using the micro service framework according to the embodiment of the present application in an IOT scenario. Referring to fig. 6 and 7, fig. 6 is a schematic structural diagram illustrating that a service processing method in a micro service framework according to an embodiment of the present disclosure is applied to an internet of things (IoT) scenario, and fig. 7 is an exemplary diagram illustrating that the service processing method in the micro service framework according to an embodiment of the present disclosure is applied to the IoT scenario. In fig. 6, a service registry is included, and an Elastic Load Balance (ELB) is connected to the service registry, and in the ELB, a service registry entry, a low version service entry and a high version service entry are arranged, however, if a certain service has more than two versions, the service is represented in a manner similar to the first, second and third, or high, medium and low, etc. Also included in fig. 6 are two versions of ServiceA and two versions of ServiceX, i.e., ServiceA _ v1 and ServiceX _ v1 in the low version, and ServiceA _ v2 and ServiceX _ v2 in the high version. The ServiceX and the ServiceA carry out communication service and do not participate in actual gray level shunting processing; in addition, an IoTAgent connected to the ELR is also included, the IoTAgent serves as a service calling end, that is, the iota corresponds to the first service in the embodiment shown in fig. 4, and an extension rule base connected to the service registry is also included in fig. 6, and is used for setting some extension rules.

It should be noted that, compared to the embodiment shown in fig. 4, the service registry in this embodiment has the capability of managing the grayscale splitting information in addition to the capability of managing the microservice registration information. The IoTAgent module is deployed in user equipment and bears certain service logic; the embedded micro service SDK is used for initiating calling to a service issuing end through the Internet; the ServiceA is a service distributor, i.e., the second service in the embodiment shown in fig. 4, because gray splitting is to be performed, there are two versions (actually, multiple versions) of the ServiceA here, ServiceA _ v1 and ServiceA _ v2, each of which represents a group of service instances of the corresponding version.

The following explains the implementation of the method: referring to fig. 7, the method may include:

701. the service is called by the serviceA to issue service through the micro service SDK of the serviceA, and shunt parameters acting on a service interface of the serviceA are set through an annotation mode.

The service publishing and offloading parameters of the ServiceA are similar to the descriptions of step 501 and step 401 in the embodiment shown in fig. 5, and are not described here again.

702. The micro-service SDK of the ServiceA receives the service registration information and the distribution parameters issued by the ServiceA and sends the service registration information and the distribution parameters to the service registration center.

After the service registration information and the offloading parameter are obtained, the service registration information and the offloading parameter are sent to a service registration center.

703. The service registration center registers the access address and port information for opening the service registration on the ELB and reports the information to the microservice registration center.

Wherein, this process is for the reason that the lotagent can access the service registry through the ELB.

704. The instance of ServiceA _ V1 and the instance of ServiceA _ V2 register their own service address and port, respectively, on the ELB.

In step 703 and step 704, the service registry and the services of the service ServiceA versions are registered on the ELB, so that the ELB performs load balancing management.

705. And the user calls an interface of the service registration center and configures a routing distribution rule through the service registration information and the distribution parameter.

The process of setting the route splitting rule in step 705 is similar to step 503 shown in fig. 5 and the description for step 503, and is not described here again.

706. The method comprises the steps that a long communication connection is established between a micro service SDK and a service registration center in an IoT Agent, and own equipment identity (device id) is reported.

707. The service registration center returns a message of an access address and a port of a corresponding version service on the ELB to the micro-service SDK of the IoT Agent according to the value of the configured distribution parameter (including the device id in the embodiment) and the mapping rule of the service instance node of the service version.

Wherein, the return message format is similar: { device _ ID, service _ name, version, < IP, port > }, device _ ID field including device ID, service _ name field of service name, version field of service version, and IP address and port.

708. The micro-service SDK of the IoT Agent receives the message and stores the information in the message locally.

It should be noted that the process from step 701 to step 708 is a setting process of a routing splitting rule similar to the embodiment shown in fig. 5, and the following step 709 to step 713 are calling processes. In addition, if the service registration center has the route distribution rule updated according to the steps, the micro-service SDK in the IoT Agent acquires the latest service version address and port through long connection and updates the information stored locally.

709. The IoT Agent receives the service call request sent by the IoT Agent through the micro service SDK of the IoT Agent.

Here, the step 709 is similar to the step 401 of the embodiment shown in fig. 4 and the description of the step 401, and is not repeated here.

710. And the micro-service SDK of the IoT Agent judges whether the service is provided with a routing distribution rule or not according to the service name in the service calling request, if so, the step 711 is executed, and if not, the service is forwarded to the service corresponding to the service name.

The step 710 is similar to the step 402 of the embodiment shown in fig. 4 and the description of the step 402, and is not repeated here.

711. And the micro-service SDK of the IoT Agent sends the service calling request to the micro-service SDK of the service A according to the routing distribution rule.

Step 711 is similar to step 403 and the description of step 403 in the embodiment shown in fig. 4, and is not repeated here.

712. The microservice SDK of the ServiceA checks whether the service in the service invocation request has the corresponding route splitting rule, if yes, step 713 is executed.

713. The microservice SDK of the ServiceA initiates a service call to the ServiceA.

714. And initiating a call by the service instance node upper layer service logic of the corresponding service version on the ServiceA to generate a call return result.

715. And the microservice SDK of the ServiceA receives a calling return result returned by the ServiceA.

716. And the microservice SDK of the serviceA sends the calling return result to the microservice SDK of the IoT Agent.

Step 716 is similar to step 404 and the description of step 404 in the embodiment shown in fig. 4, and is not repeated here.

It should be noted that, after receiving the service call request, the microservice SDK of the ServiceA may check the route split rule of the service called by the service call request, and only if the check is passed, initiate a call to the service instance node corresponding to the route split rule, after receiving the call request, the ServiceA initiates a call to the upper service logic, and then return the execution result to the microservice SDK of the ServiceA, and the microservice SDK of the ServiceA returns the call result received from the corresponding service instance node to the microservice SDK of the IoT Agent.

717. And the micro service SDK of the IoT Agent returns the call return result to the IoT Agent.

Here, the step 717 is similar to the step 405 of the embodiment shown in fig. 4 and the description of the step 405, and is not repeated here.

The service processing method in the micro service framework of the embodiment of the present application is described above, and two clients of the embodiment of the present application are described below. The client in the embodiment of the application is a component or a runtime library running in a runtime framework or a runtime environment where the first service or the second service and the like are located. The client needs to operate with either the first service or the second service. The client and the server form a micro-service framework system, and provide services of a micro-service framework for the first service, the second service and the like.

Referring to fig. 8, fig. 8 is a diagram of an embodiment of a client, which is a first client disposed on a service invocation end device according to an embodiment of the present application, where the client 8 includes:

a transceiver module 801, configured to receive a service invocation request sent by the service invocation end device through a first service running on the service invocation end device, where the service invocation request is used to initiate a service invocation to a second service issued by a service issue end device, where the service invocation request carries a service name of the second service, and the second service includes at least two service instance nodes;

a processing module 802, configured to send the service invocation request to a corresponding service instance node in the service publishing end through the transceiver module according to a route splitting rule and service registration information of the second service, where the route splitting rule is a rule set by a server according to service registration information and a splitting parameter reported by a second client, the service registration information is information registered in the service registration center when the second service is published, and the service registration information includes an address of the service instance node and a service name of the second service.

It should be noted that the functions of the transceiver module 801 and the processing module 802 may specifically refer to the steps of the embodiment shown in fig. 4 and descriptions for the steps, which are not described herein again; wherein, the transceiver module 801 can implement the functions of step 401, step 404 and step 405 in the embodiment shown in fig. 4; the processing module 802 can implement the function of step 402 in the embodiment shown in fig. 4, and the transceiver module 801 and the processing module 802 can implement the function of step 403 in the embodiment shown in fig. 4 in cooperation.

Optionally, the second service includes at least two service versions, and each service version corresponds to at least one service instance node.

It should be noted that, for the description that the second service includes at least two service versions, reference may be made to the description of step 401 in the embodiment shown in fig. 4, and details are not described here again.

Optionally, the route splitting rule includes a mapping relationship between a value in a value set of a splitting parameter of the second service enabling splitting and a service instance node, and the route splitting rule further includes a service name of the second service enabling splitting and a service version of the service instance node; the service registration information includes a service name of a second service for setting offloading and a service version of the service instance node, and an offloading parameter serving as an offloading dimension acts on a service interface parameter of the second service, and the offloading parameter includes a name and a type of the offloading parameter.

It should be noted that, for the description of the route splitting rule, the mapping relationship, the splitting parameter, and the service registration information, reference may be made to the description of step 401 in the embodiment shown in fig. 4 and the description of step 503 in the embodiment shown in fig. 5, which is not described herein again.

Optionally, the transceiver module 801 is further configured to:

It should be noted that, for the description of the step of receiving the route splitting rule and the service registration information sent by the server, reference may be made to the description of step 401 in the embodiment shown in fig. 4, and details are not described here.

Optionally, the transceiver module 801 is further configured to:

It should be noted that, for the description of the first request, reference may be made to the description of step 401 in the embodiment shown in fig. 4, and details are not described here again.

Optionally, the transceiver module 801 is further configured to:

It should be noted that, for the description of the first information, reference may be made to the description of step 401 in the embodiment shown in fig. 4, and details are not described here again.

Optionally, when the processing module 802 determines that offloading for the second service is started according to the first information, the transceiver module 801 forwards the service invocation request to a corresponding service instance node in the service distribution end according to the routing offloading rule.

It should be noted that, for the application manner of the first information, reference may be made to the description of step 401 in the embodiment shown in fig. 4, and details are not described here again.

Optionally, before the transceiver module 801 receives the first information sent by the server, the transceiver module 801 is further configured to:

It should be noted that, for the description of the second request, reference may be made to the description of step 401 in the embodiment shown in fig. 4, and details are not described here again.

Optionally, the route splitting rule or the service registration information includes the first information.

It should be noted that, for the description of the carrying manner of the first information, reference may be made to the description of step 401 in the embodiment shown in fig. 4, and details are not described here again.

Optionally, when the user updates the configured rule by calling the interface provided by the service registry, the transceiver module 801 is further configured to:

and receiving the route distribution rule updated by the server.

It should be noted that, for the update process of the route splitting rule, reference may be made to the relevant description of step 505 in the embodiment shown in fig. 5, and details are not described here again.

In the above description on the client as the invoking party in the embodiment of the present application, please refer to fig. 9, where fig. 9 is a diagram of an embodiment of a client as a service publishing party in the embodiment of the present application, the client is a second client disposed on a service publishing device, and the second client 9 includes:

a transceiver module 901, configured to receive a service invocation request sent by a service invocation end device through a first client of the service invocation end device, where the service invocation request is a service invocation initiated by a first micro service SDK of a first service to a second service according to a routing splitting rule, the second service includes at least two service instance nodes, the service invocation request carries a service name of the second service, an address of a target service instance node and a service name of the second service, the target service instance node is any service instance node of the second service, and the routing splitting rule is a rule set by the server according to service registration information and a splitting parameter reported by the second micro service SDK;

a processing module 902, configured to initiate a call to a corresponding service instance node according to the address of the target service instance node, where the second client obtains the route splitting rule, and the route splitting rule is a rule set by the server according to the service registration information and the splitting parameter reported by the second client.

It should be noted that the functions of the transceiver module 901 and the processing module 902 may specifically refer to the steps of the embodiment shown in fig. 5 and descriptions for the steps, which are not described herein again; wherein, the transceiver module 901 can implement the function of step 502 in the embodiment shown in fig. 5; the processing module 902 can cooperate with the transceiver module 901 to implement the functions of step 501 in the embodiment shown in fig. 5.

Optionally, the transceiver module 901 is further configured to:

It should be noted that, for the description of the service registration information and the offloading parameter, reference may be made to the description of step 503 in the embodiment shown in fig. 5 and the description of step 401 in the embodiment shown in fig. 4, which is not described herein again.

Optionally, the route splitting rule includes a mapping relationship between a value in a value set of a splitting parameter of the second service enabling splitting and a version service instance node, and the route splitting rule further includes a service name of the second service enabling splitting and a service version of the service instance node.

It should be noted that, for the description of the step 401 in the embodiment shown in fig. 4, the description of the mapping relationship may be referred to, and is not repeated here.

Optionally, the processing module 902 is further configured to:

and checking the route distribution rule of the second service, and initiating dispatching to the service instance node of the corresponding version according to the route distribution rule when the check is passed.

It should be noted that, the verification process may refer to the description of step 404 in the embodiment shown in fig. 4, and is not described herein again.

With reference to fig. 10, fig. 10 is a diagram of an embodiment of a server according to an embodiment of the present application, where the server 10 may include:

a transceiver module 1001, configured to receive service registration information and a splitting parameter sent by a second client of a service publisher device, where the service registration information is information registered in the server when a second service of the second client is published, the service registration information includes an address of a service instance node of the second service enabling splitting and a service name of the second service, the splitting parameter serving as a splitting dimension is a parameter set by the service publisher device through an annotation, and the splitting parameter acts on a service interface parameter of the second service;

a processing module 1002, configured to generate a routing splitting rule according to the service registration information and the splitting parameter;

the transceiver module 1001 is further configured to send the route splitting rule and the service registration information to a first client of a service invocation end device, so that the first client sends the service invocation request to a corresponding service instance node according to the address of the service instance node.

It should be noted that the functions of the transceiver module 1001 and the processing module 1002 may specifically refer to each step of the embodiment shown in fig. 5 and descriptions for each step, which are not described herein again; wherein, the transceiver module 1001 can implement the functions of step 502 and step 504 in the embodiment shown in fig. 5; the processing module 1002 is capable of implementing the functionality of step 503 in the embodiment shown in fig. 5.

Optionally, the route splitting rule includes a mapping relationship between a value in a value set of a splitting parameter of the second service enabling splitting and a version service instance node, and the route splitting rule further includes a service name and a service version of the second service enabling splitting; the service registration information further includes a service version of a service instance node of a second service to be set for offloading, and the offloading parameter includes a name and a type of the offloading parameter.

Optionally, the processing module 1002 is specifically configured to:

and the user calls an interface of the server and sets the routing distribution rule according to the service registration information and the distribution parameters received by the server.

Optionally, the processing module 1002 is further configured to:

the user calls an interface of the server and updates the routing distribution rule according to the service registration information and the distribution parameters received by the server;

the transceiver module 1001 is further configured to send the updated route splitting rule to the first client.

It should be noted that, for a description of the updating process of the route splitting rule, reference may be made to the description of step 503 in the embodiment shown in fig. 5, and details are not described here again.

Optionally, the transceiver module 1001 is further configured to:

receiving a first request sent by the first micro service SDK, wherein the first request carries a service name of the second service;

the processing module 1002 is further configured to determine a corresponding routing splitting rule according to the service name.

It should be noted that, for the description of the first request, reference may be made to the description of step 401 in the embodiment shown in fig. 4, and details are not described here.

Optionally, the transceiver module 1001 is further configured to:

and sending first information to the first client, wherein the first information is used for notifying the first client of the information of opening or closing the shunting of the second service.

It should be noted that, for the description of the application manner of the first information, reference may be made to the description of step 401 in the embodiment shown in fig. 4, and details are not described here again.

Optionally, the transceiver module 1001 is further configured to receive a second request sent by the first client, where the second request carries a service name of the second service;

The processing module 1002 determines, according to the second request, opening or closing information of offloading of the second service corresponding to the service name.

With reference to fig. 11, fig. 11 is a diagram of an embodiment of a service processing system in a micro service framework according to an embodiment of the present application, where the service processing system 11 includes a client according to the embodiment shown in fig. 9 as a second client 1101 and a server 1102 according to the embodiment shown in fig. 10 as a service registration center, and the processing system 11 as a whole provides a service to a client 8 (as a first client 1103) according to the embodiment shown in fig. 8.

Referring to the server of the embodiment of the present application, fig. 12 is a schematic structural diagram of a server 1200 provided by the embodiment of the present application, which may have a relatively large difference due to different configurations or performances, and may include one or more Central Processing Units (CPUs) 1222 (e.g., one or more processors) and a memory 1232, and one or more storage media 1230 (e.g., one or more mass storage devices) storing an application program 1242 or data 1244. Memory 1232 and storage media 1230 can be, among other things, transient storage or persistent storage. The program stored in the storage medium 1230 may include one or more modules (not shown), each of which may include a series of instruction operations for the server. Still further, the central processor 1222 may be configured to communicate with the storage medium 1230, to execute a series of instruction operations in the storage medium 1230 on the server 1200.

The server 1200 may also include one or more power supplies 1226, one or more wired or wireless network interfaces 1250, one or more input-output interfaces 1258, and/or one or more operating systems 1241, such as Windows Server, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

The steps performed by the server in the embodiment shown in fig. 10 may be based on the server structure shown in fig. 12. In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product.

The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the invention to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can store or a data storage device, such as a server, a data center, etc., that is integrated with one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.

Claims

1. A service processing method in a micro-service framework is characterized by comprising the following steps:

a first micro service Software Development Kit (SDK) of a first service receives a service calling request sent by the first service, wherein the service calling request is used for initiating service calling to a second service, the service calling request carries a service name of the second service, and the second service comprises at least two service instance nodes;

the first micro-service SDK sends the service call request to a corresponding service instance node in the second service according to a routing distribution rule and service registration information of the second service, wherein the routing distribution rule is a rule set by the service registration center according to service registration information and distribution parameters reported by the second micro-service SDK, the routing distribution rule comprises a mapping relation between values in a distribution parameter value set of the second service enabling distribution and the service instance node, the service registration information is information registered in the service registration center when the second service is issued, and the service registration information comprises an address of the service instance node and a service name of the second service.

2. The method of claim 1, wherein the second service comprises at least two service versions, and wherein each service version corresponds to at least one service instance node.

3. The method of claim 2, wherein the route offload rule further comprises a service name of the offload-enabled second service and a service version of a service instance node; the service registration information further includes a service version of the service instance node of the second service enabling offloading, and an offloading parameter serving as an offloading dimension acts on a service interface parameter of the second service, where the offloading parameter includes a name and a type of the offloading parameter.

4. The method according to any one of claims 1 to 3, further comprising:

and the first micro-service SDK receives service registration information and a route distribution rule issued by a service registration center.

5. The method of claim 4, wherein before the first microservice SDK receives the route offload rule and the service registration information issued by the service registration center, the method further comprises:

the first micro service SDK sends a first request to the service registration center so that the service registration center determines a routing distribution rule and service registration information corresponding to a service name in the first request; and sending the routing distribution rule and the service registration information to the first micro service SDK, wherein the first request carries the service name of the second service.

6. The method of claim 4, wherein after the first microservice SDK sends the first request to the service registry, the method further comprises:

and the first micro service SDK receives first information issued by the service registration center, wherein the first information is used for informing the first micro service SDK of the opening or closing information of the shunting of the second service.

7. The method of claim 6, wherein sending, by the first microservice SDK, the service invocation request to the corresponding service instance node in the second service according to the route splitting rule of the second service comprises:

and when the first micro-service SDK judges that the distribution aiming at the second service is started according to the first information, the first micro-service SDK sends the service calling request to a corresponding service instance node in the second service according to a routing distribution rule of the second service.

8. The method according to claim 1 or 2, wherein the route offload rule is a rule configured by a user by invoking an interface provided by a service registry.

9. The method of claim 8, wherein when the user updates the configured route offload rule by invoking an interface provided by the service registry, the method further comprises:

and the first micro service SDK receives the updated routing distribution rule of the service registration center.

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

a second micro service SDK of the second service receives a service calling request sent by the first micro service SDK;

and the second micro service SDK verifies the route distribution rule of the second service, when the verification is passed, the second micro service SDK calls the service instance node of the corresponding version, and the second micro service SDK acquires the route distribution rule.

11. A service processing method in a micro-service framework is characterized by comprising the following steps:

a second micro service SDK of a second service receives a service call request sent by a first service through the first micro service SDK of the first service, wherein the service call request is that the first micro service SDK of the first service initiates service call to the second service according to a routing distribution rule, the second service comprises at least two service instance nodes, the service call request carries a service name of the second service and an address of a target service instance node, the target service instance node is any one of the service instance nodes of the second service, the routing distribution rule is a rule set by a service registration center according to service registration information and distribution parameters reported by the second micro service SDK, the routing distribution rule comprises a mapping relation between values in a distribution parameter value set of the second service enabling distribution and version service instance nodes, and the service registration information comprises the address of the service instance node and the service name of the second service, the distribution parameters serving as distribution dimensions are parameters set by the second service through annotations, the distribution parameters act on service interface parameters of the second service, and the distribution parameters comprise names and types of the distribution parameters;

and the second micro-service SDK initiates calling to the corresponding service instance node according to the address of the target service instance node.

12. The method of claim 11, further comprising:

the second micro service SDK receives service registration information and distribution parameters issued by the second service;

and the second micro service SDK sends the service registration information and the distribution parameters to the service registration center.

13. The method according to claim 11 or 12, wherein the second service comprises at least two service versions, each service version corresponding to at least one service instance node, and wherein the service registration information further comprises service versions of service instance nodes of the second service enabling forking.

14. The method of claim 13, wherein the route offload rule further comprises a service name of the offload-enabled second service and service version service registration information for a service instance node.

15. The method of claim 14, wherein after the second microservice SDK of the second service receives the service invocation request sent by the first service through the first microservice SDK of the first service, the method further comprises:

and the second micro service SDK verifies the routing distribution rule of the second service, and when the verification is passed, the second micro service SDK initiates calling to the service instance node of the corresponding version according to the routing distribution rule.

16. A service processing method in a micro-service framework is characterized by comprising the following steps:

the method comprises the steps that a service registration center receives service registration information and shunting parameters sent by a second micro service SDK of a second service, wherein the service registration information is information registered in the service registration center when the second service is issued, the service registration information comprises an address and a service name of a service instance node of the second service enabling shunting, the shunting parameters serving as shunting dimensions are parameters set by the second service through notes, and the shunting parameters act on service interface parameters of the second service;

the service registration center generates a routing distribution rule according to the service registration information and the distribution parameters, wherein the routing distribution rule comprises a mapping relation between values in a value set of distribution parameters of the second service for enabling distribution and version service instance nodes;

and the service registration center sends the routing distribution rule and the service registration information to a first micro service SDK of a first service, so that the first micro service SDK sends the service call request to a service instance node of a corresponding service version according to the routing distribution rule and the service registration information.

17. The method of claim 16, wherein the second service comprises at least two service versions, and wherein each service version corresponds to at least one service instance node.

18. The method of claim 17, wherein the route offload rule further comprises a service name of the offload-enabled second service and a service version of a service instance node; the service registration information further includes a service version of the service instance node of the second service to be set up for offloading, and the offloading parameter includes a name and a type of the offloading parameter.

19. The method of claim 16, wherein the service registration center generating a routing offload rule according to the service registration information and offload parameters comprises:

and the user calls an interface of the service registration center and sets the routing distribution rule according to the service registration information and the distribution parameters received by the service registration center.

20. The method of claim 19, further comprising:

the user calls an interface of the service registration center and updates the routing distribution rule according to the service registration information and the distribution parameters received by the service registration center;

and the service registration center sends the updated route distribution rule to a first micro service SDK of the first service.

21. The method of claim 16, wherein before the service registry sends the route offload rule to the first microservice SDK for the first service, the method further comprises:

the service registration center receives a first request sent by the first micro service SDK, wherein the first request carries a service name of the second service;

and the service registration center determines a corresponding route distribution rule according to the service name.

22. The method as claimed in claim 21, wherein after the service registry receives the first request sent by the first microservice SDK, the method further comprises:

and the service registration center sends first information to the first micro-service SDK, wherein the first information is used for informing the first micro-service SDK of the information of opening or closing the shunting of the second service.

23. A client in a microservice framework, the client being a first client disposed on a service invocation end device, the first client comprising:

the processing module is configured to send the service invocation request to a corresponding service instance node in the service publishing end through the transceiver module according to a routing offload rule and service registration information of the second service, where the routing offload rule is a rule set by a server according to service registration information and offload parameters reported by a second client, the routing offload rule includes a mapping relationship between a value in a value set of offload parameters of the second service enabling offload and the service instance node, the service registration information is information registered in a service registration center when the second service is published, and the service registration information includes an address of the service instance node and a service name of the second service.

24. A client in a microservice framework, wherein the client is a second client disposed on a service issuer device, the second client comprising:

a transceiver module, configured to receive a service invocation request sent by a service invocation end device through a first client of the service invocation end device, where the service invocation request is a service invocation initiated by a first micro service SDK of a first service to a second service according to a routing splitting rule, the second service includes at least two service instance nodes, the service invocation request carries a service name of the second service, an address of a target service instance node and a service name of the second service, the target service instance node is any one of the service instance nodes of the second service, the routing splitting rule is a rule set by the server according to service registration information and splitting parameters reported by the second micro service SDK, and the routing splitting rule includes a mapping relationship between values in a value set of splitting parameters of the second service enabling splitting and the service instance nodes, the shunting parameter is a parameter set by the service publishing terminal equipment through an annotation, the shunting parameter acts on a service interface parameter of a second service, and the shunting parameter comprises a name and a type of the shunting parameter;

25. A server, comprising:

the server comprises a receiving and sending module, a service registration module and a distribution module, wherein the receiving and sending module is used for receiving service registration information and distribution parameters sent by a second client of a service publishing terminal device, the service registration information is information registered in the server when a second service of the second client is published, the service registration information comprises an address of a service instance node of the second service enabling distribution and a service name of the second service, the distribution parameters serving as distribution dimensions are parameters set by the service publishing terminal device through notes, and the distribution parameters act on service interface parameters of the second service;

the processing module is used for generating a routing distribution rule according to the service registration information and the distribution parameters, wherein the routing distribution rule comprises a mapping relation between values in a value set of distribution parameters of the second service for enabling distribution and service instance nodes;

the transceiver module is further configured to send the route splitting rule and the service registration information to a first client of a service invocation end device, so that the first client sends the service invocation request to a corresponding service instance node according to the address of the service instance node.

26. The server according to claim 25, wherein the second service comprises at least two service versions, each of the service versions corresponding to at least one service instance node.

27. The server of claim 26, wherein the route offload rule further comprises a service name and a service version of the offload-enabled second service; the service registration information further includes a service version of a service instance node of a second service to be set for offloading, and the offloading parameter includes a name and a type of the offloading parameter.

28. The server according to claim 26, wherein the processing module is specifically configured to:

29. The server according to any one of claims 26 to 28, wherein the processing module is further configured to:

the transceiver module is further configured to send the updated route splitting rule to the first client.

30. The server according to claim 26, wherein the transceiver module is further configured to:

receiving a first request sent by a first micro Service (SDK), wherein the first request carries a service name of the second service;

the processing module is further configured to determine a corresponding routing splitting rule according to the service name.

31. The server according to claim 26, wherein the transceiver module is further configured to:

32. A service processing system in a microservice framework, comprising a service publisher device and a client according to claim 24, the service registry being disposed on the service publisher device, the service processing system further comprising a server according to any of claims 25 to 31, the service publisher device being in communication with the server via the client.

33. A computer-readable storage medium comprising instructions which, when executed on a computer, cause the computer to perform the service handling method in the microservice framework of any of claims 1-22.