CN111245918A

CN111245918A - Service request transmission method and device

Info

Publication number: CN111245918A
Application number: CN202010015101.1A
Authority: CN
Inventors: 龙武
Original assignee: Weimin Insurance Agency Co Ltd
Current assignee: Weimin Insurance Agency Co Ltd
Priority date: 2020-01-07
Filing date: 2020-01-07
Publication date: 2020-06-05

Abstract

The application relates to a service request transmission method and a service request transmission device, wherein the method comprises the following steps: receiving a target service request through a first basic frame process, wherein the target service request is used for requesting to call a target business process, the micro-service architecture comprises a plurality of service modules, each service module in the plurality of service modules is provided with the business process and the basic frame process, the basic frame process is used for forwarding the service request of the business process, the business process is used for processing the service request sent to the service module, and the first business process and the first basic frame process are arranged in the first service module in the plurality of service modules; forwarding the target service request to a target business process through a first basic frame process; and forwarding a target service request response returned by the target service process responding to the target service request through the first basic frame process. The method and the device solve the technical problems of high development difficulty and high maintenance cost of the basic framework in the micro-service architecture in the related technology.

Description

Service request transmission method and device

Technical Field

The present application relates to the field of computers, and in particular, to a method and an apparatus for transmitting a service request.

Background

The existing cross-language micro-service architecture scheme usually realizes a set of basic framework for different programming languages, different services are realized based on different languages, such as Lua, Java and Go, each language needs to provide the basic framework, and the services are communicated with each other on the basis of a gRPC protocol, so that cross-language calling is realized. In the existing architecture scheme, new function development and function optimization of a basic framework require synchronous support of the basic frameworks of different programming languages, and in addition, basic framework codes are coupled with business codes, so that developers are required to be familiar with business requirements and the basic frameworks at the same time. Therefore, different services use different programming languages, and basic frameworks of different programming language versions need to be developed and maintained, so that the labor cost for developing and maintaining the basic frameworks is greatly increased, and the difficulty for introducing emerging programming languages by developers is also increased.

In view of the above problems, no effective solution has been proposed.

Disclosure of Invention

The application provides a service request transmission method and device, which are used for at least solving the technical problems of high development difficulty and high maintenance cost of a basic framework in a micro service architecture in the related technology.

According to an aspect of an embodiment of the present application, there is provided a method for transmitting a service request, including:

receiving a target service request through a first basic frame process, wherein the target service request is used for requesting to call a target business process, the micro-service architecture comprises a plurality of service modules, each service module in the plurality of service modules is provided with a business process and a basic frame process, the basic frame process is used for forwarding the service request of the business process, the business process is used for processing the service request sent to the service module, and the first business process and the first basic frame process are arranged in the first service module in the plurality of service modules;

forwarding, by the first infrastructure process, the target service request to the target business process;

and forwarding a target service request response returned by the target service process responding to the target service request through the first basic framework process.

According to another aspect of the embodiments of the present application, there is also provided a microservice architecture, including: a plurality of service modules, each service module of the plurality of service modules deploying a business process and a base framework process, wherein,

the basic frame process is used for receiving a target service request, forwarding the target service request to a target business process, and forwarding a target service request response returned by the target business process in response to the target service request, wherein the target service request is used for requesting to call the target business process;

and the business process is used for processing the service request sent to each service module.

According to another aspect of the embodiments of the present application, there is also provided a transmission apparatus for a service request, including:

the micro-service architecture comprises a plurality of service modules, wherein each service module in the plurality of service modules is provided with a service process and a basic frame process, the basic frame process is used for forwarding the service request of the service process, the service process is used for processing the service request sent to the service module, and the first service module in the plurality of service modules is provided with a first service process and a first basic frame process;

a first forwarding module, configured to forward the target service request to the target business process through the first infrastructure process;

and the second forwarding module is used for forwarding a target service request response returned by the target service process responding to the target service request through the first basic framework process.

Optionally, the receiving module comprises one of:

a first receiving unit, configured to receive, by using the first basic framework process, a first service request sent by the first service process, where the first service request is used to request to invoke a second service process, a second service module is deployed with the second service process and a second basic framework process, the second basic framework process is used to forward a service request of the second service process, and the second service process is used to process a service request sent to the second service module;

a second receiving unit, configured to receive, through the first basic frame process, a second service request transmitted by a third basic frame process using a target transport protocol, where the second service request is used to request to invoke the first service process, a third service module is deployed with a third service process and the third basic frame process, the third basic frame process is used to forward a service request of the third service process, and the third service process is used to process the service request sent to the third service module.

Optionally, the first forwarding module comprises:

a first obtaining unit, configured to obtain a service instance address of the second service module in a case where the first service request is received;

a first forwarding unit, configured to forward, by the first infrastructure process, the first service request to the second infrastructure process indicated by the service instance address by using a target transport protocol, where the first service request is used to instruct the second infrastructure process to forward the first service request to the second service process.

Optionally, the second forwarding module includes:

a first receiving unit, configured to receive, by the first infrastructure process, a first service request response returned by the second infrastructure process by using the target transport protocol;

a second forwarding unit, configured to forward the first service request response to the first service process through the first infrastructure process.

Optionally, the first forwarding module comprises:

a second obtaining unit, configured to obtain a monitoring address of the first service process when the second service request is received;

a third forwarding unit, configured to forward, by the first infrastructure process, the second service request to the first business process indicated by the listening address.

Optionally, the second forwarding module includes:

a second receiving unit, configured to receive, by the first infrastructure process, a second service request response returned by the first business process;

a fourth forwarding unit, configured to forward, by the first infrastructure process, the second service request response to the third infrastructure process by using the target transport protocol, where the second service request response is used to instruct the third infrastructure process to forward the second service request response to the third business process.

According to another aspect of the embodiments of the present application, there is also provided a storage medium including a stored program which, when executed, performs the above-described method.

According to another aspect of the embodiments of the present application, there is also provided an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the above method through the computer program.

In the embodiment of the application, a target service request is received through a first basic frame process, wherein the target service request is used for requesting to call a target business process, a micro-service framework comprises a plurality of service modules, each service module in the plurality of service modules is provided with a business process and a basic frame process, the basic frame process is used for forwarding the service request of the business process, the business process is used for processing the service request sent to the service module, and the first business process and the first basic frame process are arranged in the first service module in the plurality of service modules; forwarding the target service request to a target business process through a first basic frame process; the method comprises the steps that a first basic frame process forwards a target service process response target service request response returned by a target service request, the service process and the basic frame process are deployed as a whole, the basic frame process is responsible for processing network communication between services, and the service process is responsible for reading a request from the basic frame process for processing and sending the request to the basic frame process for forwarding. The basic framework code and the service code are separately operated, and the independently operated basic framework process supports protocol forwarding and supports the core function of the micro-service architecture. Business processes written in different programming languages forward requests to other services through the basic framework process. Basic frames do not need to be provided for different languages, the basic frames can be developed and maintained by a basic development team familiar with a certain language, service developers only need to pay attention to service requirements, and the requirements on the technical level of the developers are reduced, so that the labor cost can be reduced, and the technical problems of high development difficulty and high maintenance cost of the basic frames in the micro-service architecture in the related technology are solved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without inventive exercise.

Fig. 1 is a schematic diagram of a hardware environment of a transmission method of a service request according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a microservice architecture in accordance with an alternative embodiment of the present application;

FIG. 3 is a schematic diagram of a containerized deployment of a microservice architecture in accordance with an embodiment of the present application;

fig. 4 is a flow chart of an alternative method for transmitting a service request according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a communication method in a microservice architecture according to an alternative embodiment of the present application;

FIG. 6 is a schematic diagram of a service request transmission process according to an alternative embodiment of the present application;

FIG. 7 is a schematic diagram of another service request transmission process according to an alternative embodiment of the present application;

FIG. 8 is a schematic diagram of service request forwarding according to an embodiment of the present application;

FIG. 9 is a schematic flow chart diagram illustrating the processing of a service request in a cross-language microservice architecture in accordance with an alternative embodiment of the present application;

FIG. 10 is a schematic diagram of an alternative transmission device for a service request according to an embodiment of the present application;

and

fig. 11 is a block diagram of a terminal according to an embodiment of the present application.

Detailed Description

In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only partial embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or 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.

According to an aspect of embodiments of the present application, an embodiment of a method for transmission of a service request is provided.

Optionally, in this embodiment, fig. 1 is a schematic diagram of a hardware environment of a transmission method of a service request according to an embodiment of the present application, and the transmission method of a service request may be applied to the hardware environment of the micro-service architecture shown in fig. 1. As shown in fig. 1, the micro-service architecture includes: the system comprises a plurality of Service modules (101-1,101-2, … …, 101-n), wherein each Service module in the plurality of Service modules is provided with a Service process Service and a basic framework process Sidecar, wherein the basic framework process Sidecar is used for receiving a target Service request, forwarding the target Service request to a target Service process and forwarding a target Service request response returned by the target Service process in response to the target Service request, and the target Service request is used for requesting to call the target Service process; and the Service process Service is used for processing the Service request sent to each Service module. Infrastructure is provided in the microservice architecture, such as: registries, monitoring systems, logging systems, message queues and databases, and the like. The infrastructure process Sidecar may make calls to the infrastructure during its operation. The individual service modules may be implemented, but are not limited to, using different programming languages. Cross-language calling can be carried out among the service modules.

Optionally, in this embodiment, the microservice architecture is an architecture concept, which uses a divide-and-conquer approach to decompose a complex system into a set of microservices, each microservice focuses only on one business function, and can be developed by different independent teams, thereby meeting the demand of fast and good time in the internet era.

Optionally, in this embodiment, the basic framework refers to a micro-service basic framework, and is used to implement basic functions of the micro-service framework, such as service registration, service discovery, load balancing, traffic management, operation index acquisition, distributed tracking, and the like.

Optionally, in this embodiment, the basic framework process is an application implemented based on basic framework code, and runs in an independent process manner. Sidecar is used to represent the base framework process. The business process is an application program realized based on business codes and runs in an independent process mode.

In an optional embodiment, fig. 2 is a schematic diagram of a micro service architecture according to an optional embodiment of the present Application, as shown in fig. 2, a client and a background service of a front-end user are connected through an API (Application Programming Interface) gateway in the micro service architecture, a request of the front end is based on an HTTP Protocol (HyperText Transfer Protocol), JSON format (JavaScript object notation), and data transmission is performed through the API gateway, so as to obtain a gprs Protocol and data in a Protocol buffer format, and then the Protocol is routed to a corresponding service instance module. The requests between services are based on the gPRC protocol, Protobuf format data for communication. Different services are realized based on different languages, such as Lua, Java, Go, PHP, Python,. Net, etc., each service module provides a business process and a basic framework process (Sidecar), the basic framework process provided in the micro service architecture is realized by the Go language, and functions of service registration, service discovery, load balancing, traffic management, operation index acquisition, distributed tracking, etc. are provided. Service requests transmitted between services are forwarded by a base framework process (Sidecar) deployed in each service.

As an optional embodiment, a first service module in the plurality of service modules deploys a first business process and a first basic framework process, a second service module in the plurality of service modules deploys a second business process and a second basic framework process, and a third service module in the plurality of service modules deploys a third business process and a third basic framework process, where the first basic framework process is used for one of:

receiving a first service request sent by a first service process, wherein the first service request is used for requesting to call a second service process; acquiring a service instance address of a second service module; forwarding the first service request to a second basic framework process indicated by the service instance address, wherein the first service request is used for indicating the second basic framework process to forward the first service request to the second business process; receiving a first service request response returned by the second basic framework process; forwarding the first service request response to the first business process;

receiving a second service request transmitted by a third basic frame process, wherein the second service request is used for requesting to call the first business process; acquiring a monitoring address of a first service process; forwarding the second service request to the first business process indicated by the monitoring address; receiving a second service request response returned by the first business process; and forwarding the second service request response to the third basic framework process, wherein the second service request response is used for instructing the third basic framework process to forward the second service request response to the third business process.

Optionally, in this embodiment, the cross-language microservice architecture, the infrastructure process is responsible for handling network communications between services, for all traffic ingress and egress of services, and for ensuring fast, reliable and secure communications between services. The business process is responsible for sending requests to the infrastructure process, through which the requests are forwarded to other services. The micro-service architecture decouples the basic framework code and the service code, and greatly reduces the threshold of using a new programming language by service developers.

As an alternative embodiment, the basic framework processes deployed in each service module communicate with each other through a target transport protocol.

Optionally, in this embodiment, the basic framework processes forward the service request by using the target transport protocol, so that the service request implemented by different programming languages does not interfere with the identification of the basic framework process on the requested forwarding path, and the basic framework process can identify the forwarding path of the service request by analyzing the data packet conforming to the target transport protocol, thereby implementing the forwarding of the cross-language service request.

As an alternative embodiment, each service module is deployed in a runtime unit, the business process is deployed in a first container in the runtime unit, and the infrastructure process is deployed in a second container in the runtime unit.

Optionally, in this embodiment, the microservice architecture may be deployed, but is not limited to, by using a containerized deployment platform. For example: the above-mentioned operation unit may include, but is not limited to, a minimum operation unit Pod of Kubernetes, one Pod may include a plurality of Docker containers, and the plurality of Docker containers may include the above-mentioned first container and second container.

Fig. 3 is a schematic diagram of containerized deployment of a micro service architecture according to an embodiment of the present application, where, as shown in fig. 3, the micro service architecture is deployed in a kubernets (K8 s for short) containerized deployment platform, and the micro service architecture includes a GO service module, a Java service module, a.net service module, and so on. Each service module is deployed as a K8s Pod, and the business process and the base framework process included in each service module are respectively deployed as a Docker container.

Fig. 4 is a flowchart of an alternative service request transmission method according to an embodiment of the present application, and as shown in fig. 4, the method may include the following steps:

step S402, receiving a target service request through a first basic frame process, wherein the target service request is used for requesting to call a target business process, a micro-service architecture comprises a plurality of service modules, each service module in the plurality of service modules is provided with a business process and a basic frame process, the basic frame process is used for forwarding the service request of the business process, the business process is used for processing the service request sent to the service module, and the first business process and the first basic frame process are arranged in a first service module in the plurality of service modules;

step S404, forwarding the target service request to the target business process through the first basic framework process;

step S406, forwarding a target service request response returned by the target service process in response to the target service request through the first infrastructure process.

Optionally, in this embodiment, the service provided by the service module may refer to, but is not limited to, a function provided to the caller for calling, such as: the system comprises a game function, a shopping function, a live broadcast function, an audio and video playing function, a picture storing and browsing function, a financing function, a web page browsing function and the like.

Optionally, in this embodiment, the microservice architecture may be, but is not limited to, a cross-language microservice architecture, and the plurality of service modules may be, but is not limited to, implemented using different compiling languages. For example: lua, Java, Go, PHP, Python,. Net, and the like.

Through the above steps S402 to S406, the business process and the infrastructure process are deployed as a whole, the infrastructure process is responsible for processing network communication between services, and the business process is responsible for reading a request from the infrastructure process for processing and is responsible for sending the request to the infrastructure process for forwarding. The basic framework code and the service code are separately operated, and the independently operated basic framework process supports protocol forwarding and supports the core function of the micro-service architecture. Business processes written in different programming languages forward requests to other services through the basic framework process. Basic frames do not need to be provided for different languages, the basic frames can be developed and maintained by a basic development team familiar with a certain language, service developers only need to pay attention to service requirements, and the requirements on the technical level of the developers are reduced, so that the labor cost can be reduced, and the technical problems of high development difficulty and high maintenance cost of the basic frames in the micro-service architecture in the related technology are solved.

In the technical solution provided in step S402, the basic framework may be, but is not limited to, used for implementing some basic functions of the microservice architecture, such as: the method comprises the functions of service registration, service discovery, load balancing, flow management, operation index acquisition, distributed tracking and the like. The basic framework process is an application program realized based on basic framework codes and runs in an independent process mode. The business process is an application program realized based on business codes and runs in an independent process mode.

Optionally, in this embodiment, the target service request is a service request received by the first infrastructure process, and is used to request to invoke a target business process, where the target business process may be a first business process of the first service module or another business process of another service module.

Optionally, in this embodiment, the service request of the business process may be a service request sent by the business process, or may be a service request sent to the business process.

In the technical solution provided in step S404, the first basic framework process is configured to forward a service request of the first business process.

In the technical solution provided in step S406, the first infrastructure process is configured to forward a target service request response returned by the target business process.

Optionally, in this embodiment, the first service module is any one of a plurality of service modules deployed in the micro service architecture. The second service module is used for representing a service module for providing a service function for the first service module, and the third service module is used for representing a service module for calling the service function provided by the first service module.

As an alternative embodiment, receiving the target service request by the first infrastructure process comprises one of:

s11, receive, by the first basic framework process, a first service request sent by the first service process, where the first service request is used to request to invoke a second service process, a second service module is deployed with the second service process and a second basic framework process, the second basic framework process is used to forward a service request of the second service process, and the second service process is used to process a service request sent to the second service module.

S12, receiving, by the first basic frame process, a second service request transmitted by a third basic frame process using a target transport protocol, where the second service request is used to request to invoke the first service process, a third service module is deployed with a third service process and the third basic frame process, the third basic frame process is used to forward the service request of the third service process, and the third service process is used to process the service request sent to the third service module.

Optionally, in this embodiment, the first base framework process is responsible for handling inbound traffic and outbound traffic for the first service module. For both inbound and outbound traffic, under the micro-service architecture, a request for service a to access service B belongs to outbound traffic for service a and to inbound traffic for service B.

Optionally, in this embodiment, for a received first service request sent by a first service process and used for requesting to invoke a second service process, the first infrastructure process is responsible for forwarding the first service request to a second infrastructure process corresponding to the invoked second service process, and the second infrastructure process forwards the first service request to the second service process.

Optionally, in this embodiment, for a received second service request sent by the third infrastructure process and used for requesting to invoke the first business process, the first infrastructure process is responsible for forwarding the second service request to the first business process.

As an alternative embodiment, forwarding the target service request to the target business process through the first infrastructure process comprises:

s21, acquiring the service instance address of the second service module under the condition of receiving the first service request;

s22, forwarding, by the first infrastructure process, the first service request to the second infrastructure process indicated by the service instance address by using a target transport protocol, where the first service request is used to instruct the second infrastructure process to forward the first service request to the second business process.

Optionally, in this embodiment, for the outbound traffic, the first infrastructure process may find the service instance address of the second service module by looking up the service instance address list maintained by the first infrastructure process, so as to forward the first service request.

In an alternative embodiment, fig. 5 is a schematic diagram of a communication method in a micro service architecture according to an alternative embodiment of the present application, as shown in fig. 5, a base framework process (Sidecar) monitors a local port, such as 127.0.0.1:9091, and a service process initialization flow creates a connection with the base framework process. In the service instance operation process, the service process sends a request to the basic framework process, and the basic framework process is responsible for forwarding the service request to the basic framework process of other service instances.

As an optional embodiment, forwarding, by the first infrastructure process, a target service request response returned by the target business process in response to the target service request includes:

s31, receiving a first service request response returned by the second basic framework process by adopting the target transmission protocol through the first basic framework process;

s32, forwarding the first service request response to the first business process through the first base framework process.

Optionally, in this embodiment, the service modules communicate with each other through the infrastructure process, and for the outbound first service request, if the second service module returns a first service request response through the second infrastructure process, the outbound first service request is forwarded to the first business process through the first infrastructure process.

In an optional embodiment, a first service module deploys a first service process and a first basic framework process, a second service module deploys a second service process and a second basic framework process, fig. 6 is a schematic diagram of a service request transmission process according to the optional embodiment of the present application, and as shown in fig. 6, the service request transmission process may include the following steps:

step S602, the first basic framework process receives a first service request sent by the first service process, and determines that the first service request is used to request to invoke the second service process.

In step S604, the first infrastructure obtains the service instance address of the second service module.

In step S606, the first infrastructure process forwards the first service request to the second infrastructure process indicated by the service instance address by using the target transport protocol.

In step S608, the second infrastructure process forwards the first service request to the second service process.

Step S610, the second service process processes the first service request and returns a response of the first service request to the second infrastructure process.

Step S612, the first infrastructure process receives a first service request response returned by the second infrastructure process using the target transport protocol.

In step S614, the first infrastructure process forwards the first service request response to the first business process.

s41, acquiring the monitoring address of the first business process under the condition of receiving the second service request;

s42, forwarding the second service request to the first business process indicated by the listening address through the first infrastructure process.

Optionally, in this embodiment, for the inbound traffic, the first infrastructure process may forward the second service request by obtaining a listening address of the first business process.

In the above alternative embodiment, as shown in fig. 5, the business process monitors a local port, such as 127.0.0.1:8091, and the basic framework process initialization flow creates a connection with the business process. In the service instance operation process, the basic framework process is responsible for forwarding the service request to the local service process.

s51, receiving a second service request response returned by the first business process through the first basic framework process;

s52, forwarding the second service request response to the third infrastructure process by using the target transport protocol through the first infrastructure process, where the second service request response is used to instruct the third infrastructure process to forward the second service request response to the third business process.

Optionally, in this embodiment, the service modules communicate with each other through the infrastructure process, and for the second service request that is inbound, if the first business process returns the second service request response, the second service request response is forwarded to the third infrastructure process through the first infrastructure process, so that the third infrastructure process forwards the second service request response to the third business process.

In an optional embodiment, a first service module deploys a first service process and a first basic framework process, a third service module deploys a third service process and a third basic framework process, fig. 7 is a schematic diagram of another service request transmission process according to the optional embodiment of the present application, and as shown in fig. 7, the service request transmission process may include the following steps:

step S702, the first infrastructure process receives a second service request transmitted by the third infrastructure process using the target transport protocol, and determines that the second service request is used to request to invoke the first service process.

Step S704, the first infrastructure acquires a monitoring address of the first service process.

Step S706, the first infrastructure process forwards the second service request to the first business process indicated by the listening address.

Step S708, the first business process processes the second service request and returns a second service request response to the first infrastructure process.

Step S710, the first infrastructure process forwards the second service request response to the third infrastructure process by using the target transport protocol.

In step S712, the third infrastructure process forwards the second service request response to the third business process.

Optionally, in this embodiment, the basic framework process provided in the cross-language microservice architecture is responsible for handling network communication between different services, and can ensure that communication between services is fast, reliable and secure. Fig. 8 is a schematic diagram illustrating service request forwarding according to an embodiment of the present application, where as shown in fig. 8, a basic framework process (Sidecar) is responsible for registering service information to a service registry and maintaining validity period of the service information; and the system is responsible for viewing the service registry in real time and synchronizing the service information of the dependent service. The basic framework process constructs a request processing chain and provides modules for route control, current-limiting control, load balancing, full-link monitoring data reporting, service authentication, protocol forwarding and the like. When an inbound or outbound request is received, the infrastructure processes process one by one according to the initialized request processing chain sequence, and finally forward the request to the local business process or other serving infrastructure processes. Wherein, the basic framework process and the business process are deployed together, and the two processes can be mutually called as a local process. The service registry is a bridge that connects service providers and service consumers, maintains the latest network location of service provider instances, and may use a distributed, consistent key-value store system to maintain service registration information.

The present application further provides an alternative embodiment, which provides a flow for processing a service request in a cross-language microservice architecture, fig. 9 is a schematic flow diagram for processing a service request in a cross-language microservice architecture according to the alternative embodiment of the present application, and as shown in fig. 9, a basic framework process is responsible for processing inbound traffic and outbound traffic of a service, and the flow includes the following steps:

in step S902, the infrastructure process receives the request.

Step S904, the basic framework process parses and obtains other service names that need to be accessed.

Step S906, the infrastructure process determines whether the request requests the local service process, if so, the request is inbound traffic, otherwise, the request is outbound traffic.

Step S908, for inbound traffic, the infrastructure process obtains a monitoring address of the local service process and forwards the request to the local service process.

Step S910, for the outbound traffic, the basic framework process obtains the service instance addresses of other service instances and forwards the request to the basic framework process of the service instance.

Therefore, the cross-language micro-service architecture scheme based on the gRPC has the advantages that the basic framework process and the service process are separated by stripping the basic framework code and the service code, the basic framework process is realized based on a certain programming language, the service process can be realized by adopting various programming languages, and the cross-language micro-service architecture scheme is really independent of the language. Different programming languages have application scenes suitable for the different programming languages, and the use of multiple programming languages by one company is a normal state. The traditional cross-language micro-service architecture scheme develops and maintains basic frameworks of different programming languages, and basic framework codes are coupled with service codes, so that the technical level requirement on developers is high, and a lot of redundancy exists in the work of the developers. The above-described gRPC-based cross-language microservice architecture scheme solves the above-described problems well. The basic frame codes and the business codes are separated, a business development team is concentrated on business requirement development, and different programming languages can be used for trying to develop business requirements; the basic framework development team is focused on providing a stable, reliable and safe basic framework for the business development team, original functions are optimized through continuous development of new functions, and the technical level of the micro-service architecture is continuously enhanced.

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present application.

According to another aspect of the embodiments of the present application, there is also provided a service request transmission apparatus for implementing the service request transmission method. Fig. 10 is a schematic diagram of an alternative service request transmission apparatus according to an embodiment of the present application, and as shown in fig. 10, the apparatus may include:

a receiving module 102, configured to receive a target service request through a first infrastructure process, where the target service request is used to request to invoke a target business process, a micro-service architecture includes a plurality of service modules, each service module in the plurality of service modules deploys a business process and an infrastructure process, the infrastructure process is used to forward the service request of the business process, the business process is used to process the service request sent to the service module, and a first business process and the first infrastructure process are deployed in a first service module in the plurality of service modules;

a first forwarding module 104, configured to forward the target service request to the target business process through the first infrastructure process;

a second forwarding module 106, configured to forward, through the first infrastructure process, a target service request response returned by the target service process in response to the target service request.

It should be noted that the receiving module 102 in this embodiment may be configured to execute the step S402 in this embodiment, the first forwarding module 104 in this embodiment may be configured to execute the step S404 in this embodiment, and the second forwarding module 106 in this embodiment may be configured to execute the step S406 in this embodiment.

It should be noted here that the modules described above are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the above embodiments. It should be noted that the modules described above as a part of the apparatus may operate in a hardware environment as shown in fig. 1, and may be implemented by software or hardware.

Through the modules, the service process and the basic framework process are deployed as a whole, the basic framework process is responsible for processing network communication between services, and the service process is responsible for reading a request from the basic framework process for processing and sending the request to the basic framework process for forwarding. The basic framework code and the service code are separately operated, and the independently operated basic framework process supports protocol forwarding and supports the core function of the micro-service architecture. Business processes written in different programming languages forward requests to other services through the basic framework process. Basic frames do not need to be provided for different languages, the basic frames can be developed and maintained by a basic development team familiar with a certain language, service developers only need to pay attention to service requirements, and the requirements on the technical level of the developers are reduced, so that the labor cost can be reduced, and the technical problems of high development difficulty and high maintenance cost of the basic frames in the micro-service architecture in the related technology are solved.

As an alternative embodiment, the receiving module includes one of:

As an alternative embodiment, the first forwarding module comprises:

As an optional embodiment, the second forwarding module includes:

As an alternative embodiment, the first forwarding module comprises:

As an optional embodiment, the second forwarding module includes:

It should be noted here that the modules described above are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the above embodiments. It should be noted that the modules described above as a part of the apparatus may be operated in a hardware environment as shown in fig. 1, and may be implemented by software, or may be implemented by hardware, where the hardware environment includes a network environment.

According to another aspect of the embodiment of the present application, there is also provided a server or a terminal for implementing the transmission method of the service request.

Fig. 11 is a block diagram of a terminal according to an embodiment of the present application, and as shown in fig. 11, the terminal may include: one or more processors 1101 (only one of which is shown), a memory 1103, and a transmission means 1105, as shown in fig. 11, the terminal may further include an input/output device 1107.

The memory 1103 may be configured to store software programs and modules, such as program instructions/modules corresponding to the service request transmission method and apparatus in the embodiment of the present application, and the processor 1101 executes various functional applications and data processing by running the software programs and modules stored in the memory 1103, that is, implements the service request transmission method described above. The memory 1103 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 1103 can further include memory located remotely from the processor 1101, which can be connected to the terminal over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmitting device 1105 is used for receiving or sending data via a network, and can also be used for data transmission between the processor and the memory. Examples of the network may include a wired network and a wireless network. In one example, the transmission device 1105 includes a Network adapter (NIC) that can be connected to a router via a Network cable and other Network devices to communicate with the internet or a local area Network. In one example, the transmitting device 1105 is a Radio Frequency (RF) module, which is used to communicate with the internet in a wireless manner.

The memory 1103 is used for storing, among other things, application programs.

The processor 1101 may call an application stored in the memory 1103 through the transmission device 1105 to perform the following steps:

s1, receiving a target service request through a first infrastructure process, where the target service request is used to request to invoke a target business process, a micro-service architecture includes a plurality of service modules, each service module in the plurality of service modules deploys a business process and an infrastructure process, the infrastructure process is used to forward the service request of the business process, the business process is used to process the service request sent to the service module, a first business process and a first infrastructure process are deployed in a first service module in the plurality of service modules, and the first business process is used to process the service request sent to the first service;

s2, forwarding the target service request to the target business process through the first basic framework process;

s3, forwarding the target service request response returned by the target service process responding to the target service request through the first basic framework process.

By adopting the embodiment of the application, a scheme for transmitting the service request is provided. The business process and the basic framework process are deployed as a whole, the basic framework process is responsible for processing network communication between services, and the business process is responsible for reading a request from the basic framework process for processing and sending the request to the basic framework process for forwarding. The basic framework code and the service code are separately operated, and the independently operated basic framework process supports protocol forwarding and supports the core function of the micro-service architecture. Business processes written in different programming languages forward requests to other services through the basic framework process. Basic frames do not need to be provided for different languages, the basic frames can be developed and maintained by a basic development team familiar with a certain language, service developers only need to pay attention to service requirements, and the requirements on the technical level of the developers are reduced, so that the labor cost can be reduced, and the technical problems of high development difficulty and high maintenance cost of the basic frames in the micro-service architecture in the related technology are solved.

Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment is not described herein again.

It can be understood by those skilled in the art that the structure shown in fig. 11 is only an illustration, and the terminal may be a terminal device such as a smart phone (e.g., an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, and a Mobile Internet Device (MID), a PAD, etc. Fig. 11 is a diagram illustrating a structure of the electronic device. For example, the terminal may also include more or fewer components (e.g., network interfaces, display devices, etc.) than shown in FIG. 11, or have a different configuration than shown in FIG. 11.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by a program instructing hardware associated with the terminal device, where the program may be stored in a computer-readable storage medium, and the storage medium may include: flash disks, Read-Only memories (ROMs), Random Access Memories (RAMs), magnetic or optical disks, and the like.

Embodiments of the present application also provide a storage medium. Alternatively, in this embodiment, the storage medium may be used to execute a program code of a transmission method of a service request.

Optionally, in this embodiment, the storage medium may be located on at least one of a plurality of network devices in a network shown in the above embodiment.

Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps:

s1, receiving a target service request through a first infrastructure process, where the target service request is used to request to invoke a target business process, a micro-service architecture includes a plurality of service modules, each service module in the plurality of service modules deploys a business process and an infrastructure process, the infrastructure process is used to forward the service request of the business process, the business process is used to process the service request sent to the service module, and a first business process and the first infrastructure process are deployed in a first service module in the plurality of service modules;

Optionally, in this embodiment, the storage medium may include, but is not limited to: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.

The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

The integrated unit in the above embodiments, if implemented in the form of a software functional unit and sold or used as a separate product, may be stored in the above computer-readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or a part of or all or part of the technical solution contributing to the prior art may be embodied in the form of a software product stored in a storage medium, and including instructions for causing one or more computer devices (which may be personal computers, servers, network devices, or the like) to execute all or part of the steps of the method described in the embodiments of the present application.

In the above embodiments of the present application, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed client may be implemented in other manners. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be 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, units or modules, and may be in an electrical 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 foregoing is only a preferred embodiment of the present application and it should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims

1. A method for transmitting a service request, comprising:

2. The method of claim 1, wherein receiving the target service request by the first infrastructure process comprises one of:

receiving a first service request sent by the first service process through the first basic framework process, wherein the first service request is used for requesting to call a second service process, the second service process and a second basic framework process are deployed in a second service module, the second basic framework process is used for forwarding the service request of the second service process, and the second service process is used for processing the service request sent to the second service module;

receiving, by the first basic frame process, a second service request transmitted by a third basic frame process using a target transport protocol, where the second service request is used to request to invoke the first service process, a third service module is deployed with a third service process and the third basic frame process, the third basic frame process is used to forward a service request of the third service process, and the third service process is used to process a service request sent to the third service module.

3. The method of claim 2, wherein forwarding the target service request to the target business process through the first infrastructure process comprises:

under the condition that the first service request is received, acquiring a service instance address of the second service module;

forwarding, by the first infrastructure process, the first service request to the second infrastructure process indicated by the service instance address using a target transport protocol, where the first service request is used to instruct the second infrastructure process to forward the first service request to the second business process.

4. The method of claim 3, wherein forwarding, by the first infrastructure process, a target service request response returned by the target business process in response to the target service request comprises:

receiving, by the first infrastructure process, a first service request response returned by the second infrastructure process using the target transport protocol;

forwarding, by the first infrastructure process, the first service request response to the first business process.

5. The method of claim 2, wherein forwarding the target service request to the target business process through the first infrastructure process comprises:

under the condition of receiving the second service request, acquiring a monitoring address of the first service process;

forwarding, by the first infrastructure process, the second service request to the first business process indicated by the listening address.

6. The method of claim 5, wherein forwarding, by the first infrastructure process, a target service request response returned by the target business process in response to the target service request comprises:

receiving a second service request response returned by the first business process through the first basic framework process;

forwarding, by the first infrastructure process, the second service request response to the third infrastructure process using the target transport protocol, where the second service request response is used to instruct the third infrastructure process to forward the second service request response to the third business process.

7. A microservice architecture, comprising: a plurality of service modules, each service module of the plurality of service modules deploying a business process and a base framework process, wherein,

8. The microservice architecture of claim 7, wherein a first service module of the plurality of service modules deploys a first business process and a first infrastructure process, wherein a second service module of the plurality of service modules deploys a second business process and a second infrastructure process, wherein a third service module of the plurality of service modules deploys a third business process and a third infrastructure process, wherein the first infrastructure process is configured to one of:

receiving a first service request sent by the first business process, wherein the first service request is used for requesting to call the second business process; acquiring a service instance address of the second service module; forwarding the first service request to the second infrastructure process indicated by the service instance address, wherein the first service request is used for indicating the second infrastructure process to forward the first service request to the second business process; receiving a first service request response returned by the second basic framework process; forwarding the first service request response to the first business process;

receiving a second service request transmitted by the third basic framework process, wherein the second service request is used for requesting to call the first business process; acquiring a monitoring address of the first service process; forwarding the second service request to the first business process indicated by the monitoring address; receiving a second service request response returned by the first business process; forwarding the second service request response to the third base framework process, wherein the second service request response is used for instructing the third base framework process to forward the second service request response to the third business process.

9. The microservice architecture of claim 7, wherein the underlying framework processes deployed in each service module communicate with each other via a target transport protocol.

10. The microservice architecture of claim 7, wherein each service module is deployed in a runtime, wherein the business process is deployed in a first container in the runtime, and wherein the base framework process is deployed in a second container in the runtime.

11. An apparatus for transmitting a service request, comprising:

12. A storage medium, characterized in that the storage medium comprises a stored program, wherein the program when executed performs the method of any of the preceding claims 1 to 6.

13. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor executes the method of any of the preceding claims 1 to 6 by means of the computer program.