Heterogeneous service interactive calling method and device, electronic equipment and storage medium

Abstract

The invention discloses an interactive calling method and device for heterogeneous services, electronic equipment and a storage medium, and relates to the technical field of computer distributed architecture or other related fields, the method comprises the following steps: bridging a service gateway to a micro-service architecture and an SOA architecture, establishing a first proxy relationship between the service gateway and the micro-service architecture, and establishing a second proxy relationship between the service gateway and the micro-service architecture; and a second proxy relationship between the service gateway and the SOA architecture; issuing the clouded micro-service in the micro-service architecture to the SOA architecture based on the first proxy relationship, and issuing the SOA service in the SOA architecture to the micro-service architecture based on the second proxy relationship; receiving and forwarding a service request related to heterogeneous calling to a service gateway, and determining actual address information of a target service; and forwarding the service request to the target architecture based on the actual address information, calling the target service, and returning a calling result. According to the invention, the technical problem that service mutual access between the SOA architecture and the micro-service architecture cannot be carried out in the prior art is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of computer distributed architecture, and in particular to a method and device for interactively calling heterogeneous services, an electronic device, and a storage medium. Background Art

[0002] With the in-depth application of cloud computing technology, more and more enterprises' internal information system architectures are gradually transforming from service-oriented SOA architectures to microservice architectures.

[0003] Service-oriented architecture (SOA) divides daily business applications into separate business function services and processes, and links these services through well-defined interfaces and standard protocols. Based on the loose coupling between services in the SOA architecture, users can build, deploy and integrate services without relying on applications and their operating platforms, thereby improving the flexibility of business processes, speeding up development and reducing development costs.

[0004] Microservices are based on business service-oriented SOA architecture, and further decompose services into a series of independent and fine-grained services to facilitate iteration and reuse. However, the microservice architecture does not advocate uncontrolled decomposition. It focuses more on the governance of fragmented services, making the infrastructure transparent to applications and reducing costs. It is a series of infrastructure components and standard interface specifications, as well as the concept of out-of-the-box use, to achieve the purpose of allowing applications to focus on business.

[0005] In the process of architectural transformation, how to elegantly solve the cross-service architecture mutual access between services under the SOA architecture and cloud-based microservices under the microservice architecture has become an important issue.

[0006] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0007] The embodiments of the present invention provide a method and device for interactively calling heterogeneous services, an electronic device, and a storage medium, so as to at least solve the technical problem in the related art that service mutual access between SOA architecture and microservice architecture cannot be performed.

[0008] According to one aspect of an embodiment of the present invention, a method for interactive calling of heterogeneous services is provided, which is applied to a microservice architecture and a service-oriented architecture (SOA), and includes: bridging a service gateway to the microservice architecture and the SOA architecture respectively, establishing a first proxy relationship between the service gateway and the microservice architecture, and a second proxy relationship between the service gateway and the SOA architecture; publishing the cloudified microservices in the microservice architecture to the SOA architecture based on the first proxy relationship, and publishing the SOA services in the SOA architecture to the microservice architecture based on the second proxy relationship, to complete heterogeneous service publishing; receiving and forwarding service requests involving heterogeneous calls to the service gateway, and the service gateway determining the actual address information of the target service according to the service request; forwarding the service request to the target architecture based on the actual address information, and calling the target service under the target architecture, and returning the calling result.

[0009] Furthermore, the step of publishing the cloud-based microservices in the microservice architecture to the SOA architecture based on the first proxy relationship includes: obtaining a microservice list based on the service registration center under the microservice architecture, wherein the microservice list records the registration information of all the cloud-based microservices deployed under the microservice architecture; obtaining the node information of the service gateway based on the first proxy relationship, and using the node information to replace the microservice instance information in the registration information to obtain a microservice publishing list; adding the microservice publishing list to the service directory under the SOA architecture to complete the heterogeneous service publishing of the microservice architecture to the SOA architecture.

[0010] Furthermore, the step of publishing the SOA service in the SOA architecture to the microservice architecture based on the second proxy relationship includes: obtaining a service directory under the SOA architecture, wherein the service directory records the registration information of all the SOA services deployed under the SOA architecture; for each SOA service in the service directory, creating virtual microservice instance information based on the registration information; obtaining the node information of the service gateway based on the second proxy relationship, and using the node information to replace the SOA service address information in the virtual microservice instance information to obtain a virtual microservice list; adding the virtual microservice list to the service registration center under the microservice architecture to complete the heterogeneous service publishing of the SOA architecture to the microservice architecture.

[0011] Furthermore, the step of receiving and forwarding a service request involving heterogeneous calls to the service gateway includes: when the SOA service architecture receives the service request involving heterogeneous calls, obtaining the service directory under the SOA service architecture; querying the service directory based on the target service name carried by the service request to obtain a first query result, wherein the first query result is used to record the microservice name that matches the target service name in the service directory, and the node information of the service gateway corresponding to the microservice name; forwarding the service request to the service gateway with the node information indicated by the first query result as the target address; after forwarding the service request to the service gateway, the step of determining the actual address information of the target service according to the service request through the service gateway includes: determining that the target service is a cloud microservice based on the service request; querying the microservice information cache in the service gateway to obtain the actual address information of the cloud microservice in the microservice architecture.

[0012] Furthermore, the step of forwarding the service request to the target architecture based on the actual address information includes: determining that the target architecture is a microservice architecture based on the actual address information, and obtaining the health status information of all service nodes in the microservice architecture and each of the service nodes; determining the target service node to be forwarded among all the service nodes based on the health status information and the load balancing strategy; formatting the request message of the service request through the protocol conversion strategy in the service gateway; and forwarding the request message after format conversion to the target service node.

[0013] Further, the step of receiving and forwarding a service request involving a heterogeneous call to the service gateway also includes: when the microservice architecture receives the service request involving a heterogeneous call, obtaining the virtual microservice list from the service registration center under the microservice architecture; querying the virtual microservice list based on the target service name carried by the service request to obtain a second query result, wherein the second query result is used to record the SOA service name matching the target service name in the virtual microservice list, and the node information of the service gateway corresponding to the SOA service name; forwarding the service request to the service gateway with the node information indicated by the second query result as the target address; after forwarding the service request to the service gateway, the step of determining the actual address information of the target service according to the service request by the service gateway includes: determining that the target service is a SOA service based on the service request; and querying the SOA service information cache in the service gateway based on the service request to obtain the actual address information of the SOA service in the SOA architecture.

[0014] Furthermore, the step of forwarding the service request to the target architecture based on the actual address information also includes: determining that the target architecture is an SOA architecture based on the actual address information, and obtaining the health status information of all ESB nodes in the SOA architecture and each of the ESB nodes, wherein the ESB node refers to a service bus ESB node; determining the target ESB node to be forwarded among all the ESB nodes based on the health status information and the load balancing strategy; performing format conversion on the request message of the service request through the protocol conversion strategy in the service gateway, and forwarding the request message after format conversion to the target ESB node.

[0015] According to another aspect of an embodiment of the present invention, there is also provided an interactive calling device for heterogeneous services, which is applied to a microservice architecture and a service-oriented architecture (SOA), and includes: an establishing unit, which is used to bridge a service gateway to the microservice architecture and the SOA architecture respectively, and establish a first proxy relationship between the service gateway and the microservice architecture, and a second proxy relationship between the service gateway and the SOA architecture; a publishing unit, which is used to publish the cloudified microservices in the microservice architecture to the SOA architecture based on the first proxy relationship, and to publish the SOA services in the SOA architecture to the microservice architecture based on the second proxy relationship, to complete the heterogeneous service publishing; a forwarding unit, which is used to receive and forward service requests involving heterogeneous calls to the service gateway, and the service gateway determines the actual address information of the target service according to the service request; a calling unit, which is used to forward the service request to the target architecture based on the actual address information, and call the target service under the target architecture, and return the calling result.

[0016] Furthermore, the publishing unit includes: a first acquisition module, used to obtain a microservice list based on the service registration center under the microservice architecture, wherein the microservice list records the registration information of all the cloud-based microservices deployed under the microservice architecture; a second acquisition module, used to obtain the node information of the service gateway based on the first proxy relationship, and use the node information to replace the microservice instance information in the registration information to obtain a microservice publishing list; a first adding module, used to add the microservice publishing list to the service directory under the SOA architecture, and complete the heterogeneous service publishing of the microservice architecture to the SOA architecture.

[0017] Furthermore, the publishing unit also includes: a third acquisition module, used to obtain the service directory under the SOA architecture, wherein the service directory records the registration information of all the SOA services deployed under the SOA architecture; a creation module, used to create virtual microservice instance information for each SOA service in the service directory based on the registration information; a fourth acquisition module, used to obtain the node information of the service gateway based on the second proxy relationship, and use the node information to replace the SOA service address information in the virtual microservice instance information to obtain a virtual microservice list; a second adding module, used to add the virtual microservice list to the service registration center under the microservice architecture, and complete the heterogeneous service publishing of the SOA architecture to the microservice architecture.

[0018] Further, the forwarding unit includes: a fifth acquisition module, which is used to obtain the service directory under the SOA service architecture when the SOA service architecture receives the service request involving heterogeneous calls; a first query module, which is used to query the service directory based on the target service name carried by the service request to obtain a first query result, wherein the first query result is used to record the microservice name matching the target service name in the service directory, and the node information of the service gateway corresponding to the microservice name; a first forwarding module, which is used to forward the service request to the service gateway with the node information indicated by the first query result as the target address; a first determination module, which is used to determine the actual address information of the target service according to the service request through the service gateway after forwarding the service request to the service gateway, including: determining that the target service is a cloud microservice based on the service request; a second query module, which is used to query the microservice information cache in the service gateway to obtain the actual address information of the cloud microservice in the microservice architecture.

[0019] Furthermore, the calling unit includes: a sixth acquisition module, used to determine that the target architecture is a microservice architecture based on the actual address information, and to obtain the health status information of all service nodes in the microservice architecture and each of the service nodes; a second determination module, used to determine the target service node to be forwarded among all the service nodes based on the health status information and the load balancing strategy; a first format conversion module, used to perform format conversion on the request message of the service request through the protocol conversion strategy in the service gateway; and a second forwarding module, used to forward the request message after format conversion to the target service node.

[0020] Further, the forwarding unit also includes: a seventh acquisition module, which is used to obtain the virtual microservice list from the service registration center under the microservice architecture when the microservice architecture receives the service request involving heterogeneous calls; a third query module, which is used to query the virtual microservice list based on the target service name carried by the service request to obtain a second query result, wherein the second query result is used to record the SOA service name matching the target service name in the virtual microservice list, and the node information of the service gateway corresponding to the SOA service name; a third forwarding module, which is used to forward the service request to the service gateway with the node information indicated by the second query result as the target address; a third determination module, which is used to determine the actual address information of the target service according to the service request through the service gateway after forwarding the service request to the service gateway, including: determining that the target service is a SOA service based on the service request; a fourth query module, which is used to query the SOA service information cache in the service gateway based on the service request to obtain the actual address information of the SOA service in the SOA architecture.

[0021] Furthermore, the calling unit also includes: an eighth acquisition module, used to determine that the target architecture is an SOA architecture based on the actual address information, and obtain the health status information of all ESB nodes in the SOA architecture and each of the ESB nodes, wherein the ESB node refers to a service bus ESB node; a fourth determination module, used to determine the target ESB node to be forwarded among all the ESB nodes based on the health status information and the load balancing strategy; a second format conversion module, used to perform format conversion on the request message of the service request through the protocol conversion strategy in the service gateway, and forward the request message after format conversion to the target ESB node.

[0022] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is also provided, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned heterogeneous service interactive calling methods.

[0023] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the above-mentioned methods for interactively calling heterogeneous services.

[0024] In the present invention, a method for interactive calling of heterogeneous services is proposed, which first bridges the service gateway to the microservice architecture and the SOA architecture respectively, establishes a first proxy relationship between the service gateway and the microservice architecture, and a second proxy relationship between the service gateway and the SOA architecture, and then publishes the cloud microservices in the microservice architecture to the SOA architecture based on the first proxy relationship, and publishes the SOA services in the SOA architecture to the microservice architecture based on the second proxy relationship, completes the heterogeneous service publishing, and then receives and forwards the service request involving heterogeneous calls to the service gateway, which determines the actual address information of the target service according to the service request, and finally forwards the service request to the target architecture based on the actual address information, calls the target service under the target architecture, and returns the calling result.

[0025] In the present invention, a service gateway is used as an intermediary agency to establish an agency relationship between the service gateway and different architectures, and a two-way agency mechanism is used to help the microservice architecture and SOA architecture complete cross-architecture service publishing and cross-architecture service access. In the process of cross-architecture service access, after the service request reaches the gateway, the gateway will forward the request to the target architecture according to the type of request and the actual address information of the target service and call the corresponding service in the target architecture. The gateway will also return the call result to the service requester. Through the above-mentioned bridging and forwarding mechanism, the service gateway effectively solves the protocol differences and data format mismatch problems between SOA and microservice architectures, realizes seamless mutual access of services, and thus solves the technical problem that service mutual access between SOA architecture and microservice architecture cannot be performed in the related technology.

[0026] The present invention utilizes a bridging and forwarding mechanism based on a service gateway to not only ensure that services between different architectures can access each other, but also supports dynamic discovery and forwarding of service addresses, ultimately achieving integration and collaboration of heterogeneous service systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0028] Figure 1 is a flow chart of an optional method for interactively calling heterogeneous services according to an embodiment of the present invention;

[0029] Figure 2 is a schematic diagram of an optional bridging deployment of a service gateway according to an embodiment of the present invention;

[0030] Figure 3 This is a flowchart of an optional proxy publishing module processing a scheduled task according to an embodiment of the present invention;

[0031] Figure 4 This is a schematic diagram of data interaction of an optional SOA service requesting a cloud-based microservice according to an embodiment of the present invention;

[0032] Figure 5 This is an optional data interaction diagram of a cloud-based microservice requesting an SOA service according to an embodiment of the present invention;

[0033] Figure 6 is a schematic diagram of an optional device for interactively calling heterogeneous services according to an embodiment of the present invention;

[0034] Figure 7 The present invention is a hardware structure block diagram of an electronic device (or mobile device) for an interactive calling method for heterogeneous services according to an embodiment of the present invention. DETAILED DESCRIPTION

[0035] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0036] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0037] The following embodiments of the present invention can be applied to various systems / applications / devices that need to perform code testing for cross-architecture service publishing and access, and can implement architecture bridging and request forwarding mechanisms based on service gateways. The present invention uses a service gateway as an intermediary to establish an agent relationship between the service gateway and different architectures, and helps microservice architectures and SOA architectures complete cross-architecture service publishing and cross-architecture service access through a two-way agent mechanism, effectively solving the protocol differences and data format mismatch problems between SOA and microservice architectures.

[0038] The present invention is described in detail below in conjunction with various embodiments.

[0039] Embodiment 1

[0040] According to an embodiment of the present invention, an embodiment of a method for interactive calling of heterogeneous services is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0041] The implementation subject of the embodiment of the present invention can be a microservice distributed control system (MDCS), which uses a service gateway as an intermediary agency to establish an agency relationship between the service gateway and different architectures, and helps the microservice architecture and SOA architecture to complete cross-architecture service publishing through a two-way proxy mechanism, thereby realizing cross-architecture service access.

[0042] The service-oriented SOA architecture generally uses WebService or ESB as an implementation plan. Among them, WebService is an application component that allows different applications to communicate through formatted messages based on standard protocols. It mainly responds to Web application scenarios and uses the SOAP (Simple Object Access) protocol for information exchange. In order to reduce the complexity and coupling of interactions between systems, an ESB (Enterprise Service Bus) implementation plan can be adopted. In a narrow sense, ESB is a pipeline used to connect various service nodes and assume the role of interactive services. In a broad sense, ESB expands its scope to management services and process services, providing functions such as service catalog management, runtime monitoring and service aggregation.

[0043] Compared with traditional monolithic applications, microservice architecture deploys more fine-grained cloud microservices, which solves the service complexity problem by decomposing huge monolithic applications, enabling each microservice to be independently developed, deployed, and expanded.

[0044] An embodiment of the present invention proposes a service gateway that realizes mutual calls between services in a microservice architecture and an SOA architecture, and at the same time, it acts as an agent for the service release of each cloud (micro) service in the microservice architecture in the SOA architecture and the service release of services in the SOA architecture in the microservice architecture; the service gateway communicates with the microservices using gRPC, and communicates with the ESB bus of the SOA architecture using an internal TCP-based protocol, and the service gateway implements conversion between the two protocols internally, thereby supporting communication between the microservices and the ESB bus, and then using the ESB to connect various services under the SOA architecture.

[0045] Figure 1is a flowchart of an optional method for interactively calling heterogeneous services according to an embodiment of the present invention. Figure 1 As shown, the method comprises the following steps:

[0046] Step S101, bridge the service gateway to the microservice architecture and the SOA architecture respectively, establish a first proxy relationship between the service gateway and the microservice architecture, and a second proxy relationship between the service gateway and the SOA architecture.

[0047] Step S102: Based on the first proxy relationship, the cloud-based microservices in the microservice architecture are published to the SOA architecture, and based on the second proxy relationship, the SOA services in the SOA architecture are published to the microservice architecture, thereby completing the heterogeneous service publishing.

[0048] Through the proxy publishing mechanism of step S101 and step S102, the service gateway and the first proxy relationship can be used to realize the publishing and updating of the service catalog of each cloud microservice in the microservice architecture in the SOA architecture, so as to support the service bus ESB to address the target cloud service when the service in the SOA architecture sends a request to the cloud service; the service gateway and the second proxy relationship can also be used to realize the service publishing and updating of the business service in the SOA architecture in the microservice architecture, so as to support the addressing of the target service when the cloud service in the microservice architecture initiates a request to the SOA service.

[0049] In order to specifically illustrate the logical relationship between the different deployments of the service gateway bridging the microservice architecture and the SOA architecture and the business interconnection between the two parties, the embodiment of the present invention illustrates the bridging logic. Figure 2 is a schematic diagram of an optional bridging deployment of a service gateway according to an embodiment of the present invention, such as Figure 2 As shown in the figure, the service gateway is mainly composed of four modules: proxy publishing, node detection, protocol adaptation and data forwarding. Among them, the proxy publishing module can communicate with the service registration center under the microservice architecture and the service directory under the SOA architecture to realize the interactive publishing function of cross-architecture services. The data forwarding module can forward the request of cloud service to SOA service to the ESB bus under the SOA architecture, and forward the request of SOA service to cloud service from the ESB bus to the specific microservice node, realizing the message conversion based on protocol adaptation.

[0050] The following describes the intermediary communication function of the service gateway based on the specific functional modules in the service gateway.

[0051] First, the proxy release module is designed to solve the global release of a service in multiple different architecture deployments.

[0052] The proxy publishing module obtains the list of cloud-deployed microservices by listening to the service registration center under the microservice architecture, and adds it to the service directory under the SOA architecture to realize the service publishing of cloud-based microservices in the SOA architecture. In the service publishing process, the node information of the service gateway is used to replace the real microservice instance information, and the specific microservice instance information is shielded from the ESB.

[0053] The proxy publishing module also listens to the service directory under SOA, creates virtual microservice instance information based on the obtained service directory, and registers it in the service registration center under the microservice architecture to realize the service publishing of SOA services in the microservice architecture. In the process of constructing the service instance information, the node information of the service gateway is also used to replace the real SOA service address information.

[0054] The above mechanism lays the foundation for the service gateway to bridge different deployments under the microservice architecture and SOA architecture and realize traffic proxy.

[0055] Optionally, the step of publishing the cloud-based microservices in the microservice architecture to the SOA architecture based on the first proxy relationship in step S102 includes: obtaining a microservice list based on the service registration center under the microservice architecture, wherein the microservice list records the registration information of all cloud-based microservices deployed under the microservice architecture; obtaining the node information of the service gateway based on the first proxy relationship, and using the node information to replace the microservice instance information in the registration information to obtain a microservice publishing list; adding the microservice publishing list to the service directory under the SOA architecture to complete the heterogeneous service publishing of the microservice architecture to the SOA architecture.

[0056] Optionally, the step of publishing the SOA service in the SOA architecture to the microservice architecture based on the second proxy relationship in step S102 includes: obtaining a service directory under the SOA architecture, wherein the service directory records the registration information of all SOA services deployed under the SOA architecture; for each SOA service in the service directory, creating virtual microservice instance information based on the registration information; obtaining the node information of the service gateway based on the second proxy relationship, and using the node information to replace the SOA service address information in the virtual microservice instance information to obtain a virtual microservice list; adding the virtual microservice list to the service registration center under the microservice architecture to complete the heterogeneous service publishing of the SOA architecture to the microservice architecture.

[0057] In addition, the service gateway bridges different deployments under the microservice architecture and SOA architecture, and the protocol adaptation module realizes the conversion and adaptation of protocols between different deployments, so that existing deployments and services do not need to add new adaptation components, making it non-invasive to existing systems.

[0058] In the process of SOA service requesting cloudified microservices, the SOA service sends the request to the service bus ESB. Because the service gateway uses the information of the service gateway as the node information of the microservice instance when publishing the service of the proxy microservice under the SOA architecture, the ESB sends the request to the service gateway, and the service gateway forwards the request to the specific microservice instance node.

[0059] The data forwarding module first addresses the target service in the request based on the service publishing information obtained from the service registration center, then selects the specific node to be forwarded based on the health check status of the service node and the load balancing strategy, and forwards the data after completing the message conversion.

[0060] In the process of cloud-based microservices in the microservice architecture requesting SOA services, the service gateway uses the information of the service gateway as the node information of the microservice instance when proxying the service release of the SOA service under the microservice architecture. Therefore, the downstream microservice sends the request to the service gateway. The service gateway selects the ESB node to be forwarded based on the health check status and load balancing strategy of the ESB node, and forwards the data after completing the message conversion.

[0061] Step S103, receiving and forwarding a service request involving a heterogeneous call to a service gateway, and the service gateway determines the actual address information of the target service according to the service request.

[0062] Step S104, forwarding the service request to the target architecture based on the actual address information, calling the target service under the target architecture, and returning the calling result.

[0063] It should be noted that the service requests involving heterogeneous calls in step S103 and step S104 mainly include the following two types: heterogeneous call requests from cloud-based microservices to SOA services, and heterogeneous call requests from SOA services to cloud-based microservices. They are introduced in turn below.

[0064] When a heterogeneous call request for a SOA service from a cloud-based microservice is received, optionally, the step of receiving and forwarding the service request involving heterogeneous calls to a service gateway in step S103 includes: when the SOA service architecture receives a service request involving heterogeneous calls, obtaining a service directory under the SOA service architecture; querying the service directory based on the target service name carried in the service request to obtain a first query result, wherein the first query result is used to record the microservice name that matches the target service name in the service directory, and the node information of the service gateway corresponding to the microservice name; forwarding the service request to the service gateway using the node information indicated by the first query result as the target address; after forwarding the service request to the service gateway, determining the actual address information of the target service according to the service request through the service gateway includes: determining that the target service is a cloud-based microservice based on the service request; and querying the microservice information cache in the service gateway to obtain the actual address information of the cloud-based microservice in the microservice architecture.

[0065] Optionally, the step of forwarding the service request to the target architecture based on the actual address information in step S104 includes: determining that the target architecture is a microservice architecture based on the actual address information, and obtaining all service nodes in the microservice architecture and the health status information of each service node; determining the target service node to be forwarded among all service nodes based on the health status information and the load balancing strategy; formatting the request message of the service request through the protocol conversion strategy in the service gateway; and forwarding the request message after format conversion to the target service node.

[0066] It should be noted that the health status information is obtained based on the health check mechanism. The node detection module of the service gateway implements both active and passive health checks. Under the active check mechanism, the status of the target node is updated by periodically detecting the target node IP and service port. For example, if it succeeds / fails for three consecutive times, the status of the target node is considered to be healthy / unhealthy; under the passive check mechanism, with the help of the connection with the target node, when sending or receiving data succeeds / fails, the health / unhealthy status count value of the target node is updated. If the count value reaches a certain threshold, the status of the target node is considered to be healthy / unhealthy.

[0067] When a heterogeneous call request for a cloudified microservice is received from an SOA service, optionally, the step of receiving and forwarding the service request involving heterogeneous calls to a service gateway in step S103 further includes: when the microservice architecture receives a service request involving heterogeneous calls, obtaining a virtual microservice list from a service registration center under the microservice architecture; querying the virtual microservice list based on the target service name carried in the service request to obtain a second query result, wherein the second query result is used to record the SOA service name in the virtual microservice list that matches the target service name, and the node information of the service gateway corresponding to the SOA service name; forwarding the service request to the service gateway using the node information indicated by the second query result as the target address; after forwarding the service request to the service gateway, determining the actual address information of the target service according to the service request through the service gateway includes: determining that the target service is a SOA service based on the service request; and querying the SOA service information cache in the service gateway based on the service request to obtain the actual address information of the SOA service in the SOA architecture.

[0068] Optionally, the step of forwarding the service request to the target architecture based on the actual address information in step S104 also includes: determining that the target architecture is an SOA architecture based on the actual address information, and obtaining the health status information of all ESB nodes in the SOA architecture and each ESB node, wherein the ESB node refers to the service bus ESB node; determining the target ESB node to be forwarded among all ESB nodes based on the health status information and the load balancing strategy; formatting the request message of the service request through the protocol conversion strategy in the service gateway, and forwarding the request message after format conversion to the target ESB node.

[0069] Through the above steps S101 to S104, the service gateway can be bridged to the microservice architecture and the SOA architecture respectively, and a first proxy relationship between the service gateway and the microservice architecture and a second proxy relationship between the service gateway and the SOA architecture can be established. Then, based on the first proxy relationship, the cloud microservices in the microservice architecture can be published to the SOA architecture, and based on the second proxy relationship, the SOA services in the SOA architecture can be published to the microservice architecture to complete the heterogeneous service publishing. Then, the service requests involving heterogeneous calls are received and forwarded to the service gateway, and the service gateway determines the actual address information of the target service according to the service request. Finally, the service request is forwarded to the target architecture based on the actual address information, and the target service is called under the target architecture to return the call result.

[0070] In an embodiment of the present invention, a service gateway is used as an intermediary agency to establish a proxy relationship between the service gateway and different architectures, and a two-way proxy mechanism is used to help the microservice architecture and SOA architecture complete cross-architecture service publishing and cross-architecture service access. In the process of cross-architecture service access, after the service request reaches the gateway, the gateway will forward the request to the target architecture according to the type of request and the actual address information of the target service and call the corresponding service in the target architecture. The gateway will also return the call result to the service requester. Through the above-mentioned bridging and forwarding mechanism, the service gateway effectively solves the protocol differences and data format mismatch problems between SOA and microservice architectures, realizes seamless mutual access of services, and thus solves the technical problem that service mutual access between SOA architecture and microservice architecture cannot be performed in the related technology.

[0071] The embodiment of the present invention utilizes a bridging and forwarding mechanism based on a service gateway to not only ensure that services between different architectures can access each other, but also supports dynamic discovery and forwarding of service addresses, ultimately achieving integration and collaboration of heterogeneous service systems.

[0072] The present invention is described below in conjunction with another specific implementation manner.

[0073] The embodiments of the present invention propose a method and device for realizing mutual calling between services under microservice architecture and SOA architecture. Through an independent service gateway, different deployments under microservice architecture and SOA architecture are bridged to realize business interconnection between services under different architectures. By utilizing the proxy publishing and data forwarding mechanism of the service gateway, services under different architectures do not need to perceive each other, thereby reducing the intrusion into the existing system.

[0074] The key problem in the implementation of the present invention is how to solve the global publishing of a service in multiple different architecture deployments and how to achieve reliable data forwarding between services under different architectures.

[0075] In order to realize the service publishing in different architecture deployments, a proxy publishing module is designed in the service gateway, which listens to the service registration center under the microservice architecture and the service directory in the SOA architecture, and acts as a proxy for the service publishing of various services in heterogeneous deployments.

[0076] In terms of implementation, two scheduled tasks are started respectively: scheduled task A and scheduled task B. Scheduled task A realizes the publication of the service catalog of each cloud service in the microservice architecture in the SOA architecture and the update in the local cache; scheduled task B realizes the service publication of the business service in the SOA architecture in the microservice architecture and the update in the local cache.

[0077] Figure 3 FIG. 1 is a flowchart of an optional proxy publishing module processing a scheduled task according to an embodiment of the present invention. Figure 3 As shown, Figure 3 The flowchart on the left is used to record the implementation steps of scheduled task A for service release of each cloud service in the proxy microservice architecture in the SOA architecture deployment, and the flowchart on the right is used to record the implementation steps of scheduled task B for service release of each service in the proxy SOA architecture under the microservice architecture.

[0078] The implementation steps of scheduled task A include:

[0079] Step 1. Establish a connection with the service registration center under the microservice architecture, and obtain the registration information of all cloud microservices from the service registration center. If successful, execute step 2; otherwise, record the error information and jump to step 7.

[0080] Step 2. Parse the response from the service registration center. If the microservice registration information changes, update the microservice information cache and keep the latest registration information of each microservice in the cache so that the data forwarding module can address the microservice name when receiving the request forwarded by EBS.

[0081] Step 3. Compare the currently stored microservice list with the microservice list parsed from the response result of the registration center. If a new service is found, execute step 4. If a service is deregistered, jump to step 6.

[0082] Step 4: Replace the node information of the newly added service with the node information of the service gateway, and combine to generate a corresponding relationship between the service name and the service address for storage in the service directory under the SOA architecture.

[0083] Step 5. Call the interface of the service catalog component under the SOA architecture to implement the service publishing of all new services under the SOA architecture, and then jump to step 7.

[0084] Step 6. Call the interface of the service catalog component under the SOA architecture to realize the offline of all deregistration services under the SOA architecture.

[0085] Step 7. The task is completed.

[0086] The implementation steps of scheduled task B include:

[0087] Step 1. Establish a connection with the service catalog component in the SOA architecture, and obtain the registration information of all deployed services from the service catalog. If successful, execute step 2; otherwise, record the error information and jump to step 7.

[0088] Step 2. Parse the response result of the service directory component interface, compare the currently stored SOA service information with the service information parsed from the response result, and if a new service is found, execute step 3; if a service is found to be reduced, jump to step 5.

[0089] Step 3. For all newly added services, based on the properties of the microservice-oriented gRPC service provided by the service gateway, replace the node information of the newly added service with the node information of the service gateway as the service instance information, and use the name of the newly added service as the microservice name to construct the property information of the newly added SOA service when it is published as a standard microservice under the microservice architecture.

[0090] Step 4. Call the registration interface of the service registration center to implement the service release of SOA services under the microservice architecture, and then jump to step 6.

[0091] Step 5. Call the service deregistration interface of the service registration center to implement service deregistration of all offline services under the microservice architecture.

[0092] Step 6. The task is completed.

[0093] The service gateway in the embodiment of the present invention uses the health check of the node when selecting the cloud microservice target node or the SOA architecture service bus ESB node to be sent. This function is completed by the node detection module. The node detection module uses the active detection of the node and the passive health status update attached to the business request to implement the service gateway to update the health status of each node. The implementation steps of the node detection module include:

[0094] Step 1. Create a node health status shared memory for use by the node detection module and the data forwarding module.

[0095] Step 2. Obtain the node information of each service instance from the microservice information cache updated by the proxy publishing module, put it into the node list of interest, and add the node information of the service bus ESB under the SOA architecture to the node list.

[0096] Step 3. For each node in the list, start a scheduled task to actively detect the service port of the node. If successful, the health status value of the node in the shared memory is increased by 1, and the unhealth value is set to 0; if unsuccessful, the unhealth status value of the node in the shared memory is increased by 1, and the health value is set to 0; if the health value or unhealth value reaches the set threshold, it indicates that the node status is consistent after multiple consecutive detections, and the status of the node in the shared memory is set to available or unavailable according to the status.

[0097] Step 4. While actively detecting activity, use the results of sending and receiving messages in the data forwarding module to update the health status value and unhealth status value. If the sending or receiving is successful, the health status value is +1 and the unhealth value is set to 0. Otherwise, if it fails, the unhealth status value is +1 and the health value is set to 0. The health status is quickly updated according to the forwarding result of the request.

[0098] Using the above active detection and passive check mechanisms, the node detection component implements efficient health checks between nodes.

[0099] After solving the global release of services in multiple different architecture deployments, the data forwarding module combines the functions of the protocol conversion module and the node activation module to realize the business interconnection between SOA architecture services and microservices in the microservice architecture. Depending on the request initiator, it is divided into two scenarios: access from SOA architecture to microservices under microservice architecture and access from microservice architecture to services under SOA architecture.

[0100] Figure 4 FIG. 1 is a schematic diagram of data interaction of an optional SOA service request cloud microservice according to an embodiment of the present invention. Figure 4 As shown, under the premise that the proxy publishing module of the service gateway completes the information publishing of the target microservice in the service directory under the SOA architecture, the data interaction of the microservice scenario under the open service request microservice architecture in the SOA architecture, the specific implementation steps include:

[0101] Step 1: The requester (SOA open service S1) processing node sends the request to the service bus ESB.

[0102] Step 2: The service bus ESB forwards the request to the service gateway based on the target service S2 information found in the service directory.

[0103] Step 3: The service gateway parses the request header, obtains the target microservice name S2 to be sent, obtains all instance node information of the service from the microservice information cache according to the microservice name, selects the currently available instance node in combination with the node status information provided by the node detection component, and selects the target node to be sent according to the load balancing strategy. The protocol conversion module is used to complete the conversion of the received request to the gRPC interface parameters, and the gRPC interface of the target service is called to send data.

[0104] Step 4: After processing, the cloud-based microservice S2 returns a response to the service gateway.

[0105] Step 5: After receiving the response from the service provider S2 (target microservice), the service gateway converts it into the data format of the internal protocol under the SOA architecture and returns the response to the service bus ESB.

[0106] Step 6: The service bus ESB returns the response to the requester (SOA open service S1) processing node, and the process ends.

[0107] Figure 5 is a schematic diagram of data interaction of an optional cloud-based microservice requesting an SOA service according to an embodiment of the present invention, such as Figure 5As shown, the proxy publishing module of the service gateway completes the service registration of the SOA open service under the microservice architecture, and uses the node information of the service gateway as the instance information of the service during registration. The cloud microservice requests data interaction of the open service scenario in the SOA architecture. The specific implementation steps include:

[0108] Step 1: The requester (microservice S3) node establishes a gRPC connection with the service gateway based on the instance information of the target service (SOA service S4) provided by the service registry, assembles the request and sends it to the service gateway node.

[0109] Step 2: The service gateway selects the currently available ESB node based on the service bus ESB node information in the cache and the node status information provided by the node detection component, and selects the target node to be sent according to the load balancing strategy. The protocol conversion module is used to complete the data format conversion of the received request to the internal protocol under the SOA architecture, and the request is sent to the service bus ESB.

[0110] Step 3: The service bus ESB in the SOA architecture sends the request to the processing node of the target service provider (SOA service S4).

[0111] Step 4: After the processing is completed, the SOA open service S4 sends a response to the service bus ESB.

[0112] Step 5: ESB receives the response returned by service provider S4 and forwards the response to the service gateway.

[0113] Step 6: The service gateway constructs a gRPC response result based on the received response and returns it to the request initiator (cloud microservice S3) processing node, and the process ends.

[0114] The beneficial effects brought by the embodiments of the present invention include:

[0115] Through independent service gateways, different deployments under microservice architecture and SOA architecture are bridged, and business interconnection between services under different architectures is realized. The proxy publishing function of the service gateway realizes the global publishing of services in multiple different architecture deployments. The service gateway realizes the conversion between gRPC and SOA internal protocols in the microservice architecture, so that from the perspective of the microservice architecture, the newly added service gateway can interact with other microservices as a standard microservice; from the perspective of the SOA architecture, the newly added service gateway is a service that uses the internal common protocol and does not require protocol adaptation development. The newly added service gateway is non-invasive to the microservice architecture and SOA architecture, ensuring the stability of the system.

[0116] The present invention is described below in conjunction with another optional embodiment.

[0117] Embodiment 2

[0118] The interactive calling device of a heterogeneous service provided in this embodiment includes multiple implementation units, and each implementation unit corresponds to each implementation step in the above-mentioned embodiment 1.

[0119] Figure 6 is a schematic diagram of an optional heterogeneous service interactive calling device according to an embodiment of the present invention, such as Figure 6 As shown, the device may include: an establishing unit 61, a publishing unit 62, a forwarding unit 63, and a calling unit 64.

[0120] Among them, the establishing unit 61 is used to bridge the service gateway to the microservice architecture and the SOA architecture respectively, establish a first proxy relationship between the service gateway and the microservice architecture, and a second proxy relationship between the service gateway and the SOA architecture.

[0121] The publishing unit 62 is used to publish the cloud microservices in the microservice architecture to the SOA architecture based on the first proxy relationship, and to publish the SOA services in the SOA architecture to the microservice architecture based on the second proxy relationship, so as to complete the heterogeneous service publishing.

[0122] The forwarding unit 63 is used to receive and forward the service request involving heterogeneous calls to the service gateway, and the service gateway determines the actual address information of the target service according to the service request.

[0123] The calling unit 64 is used to forward the service request to the target architecture based on the actual address information, call the target service under the target architecture, and return the calling result.

[0124] The above-mentioned interactive calling device for heterogeneous services can first bridge the service gateway to the microservice architecture and the SOA architecture respectively through the establishment unit 61, establish a first proxy relationship between the service gateway and the microservice architecture, and a second proxy relationship between the service gateway and the SOA architecture, and then publish the cloud microservices in the microservice architecture to the SOA architecture based on the first proxy relationship through the publishing unit 62, and publish the SOA services in the SOA architecture to the microservice architecture based on the second proxy relationship, completing the heterogeneous service publishing, and then receive and forward the service request involving heterogeneous calls to the service gateway through the forwarding unit 63, and the service gateway determines the actual address information of the target service according to the service request, and finally forwards the service request to the target architecture based on the actual address information through the calling unit 64, and calls the target service under the target architecture, and returns the calling result.

[0125] In an embodiment of the present invention, a service gateway is used as an intermediary agency to establish an agent relationship between the service gateway and different architectures, and a two-way agent mechanism is used to help the microservice architecture and SOA architecture complete cross-architecture service publishing and cross-architecture service access. In the process of cross-architecture service access, after the service request reaches the gateway, the gateway will forward the request to the target architecture according to the type of request and the actual address information of the target service and call the corresponding service in the target architecture. The gateway will also return the call result to the service requester. Through the above-mentioned bridging and forwarding mechanism, the service gateway effectively solves the protocol differences and data format mismatch problems between SOA and microservice architectures, realizes seamless mutual access of services, and thus solves the technical problem of the inability to perform service mutual access between SOA architecture and microservice architecture in related technologies.

[0126] The embodiment of the present invention utilizes a bridging and forwarding mechanism based on a service gateway to not only ensure that services between different architectures can access each other, but also supports dynamic discovery and forwarding of service addresses, ultimately achieving integration and collaboration of heterogeneous service systems.

[0127] Optionally, the publishing unit includes: a first acquisition module, used to obtain a microservice list based on a service registration center under the microservice architecture, wherein the microservice list records the registration information of all cloud-based microservices deployed under the microservice architecture; a second acquisition module, used to obtain the node information of the service gateway based on the first proxy relationship, and use the node information to replace the microservice instance information in the registration information to obtain a microservice publishing list; a first adding module, used to add the microservice publishing list to the service directory under the SOA architecture, and complete the heterogeneous service publishing of the microservice architecture to the SOA architecture.

[0128] Optionally, the publishing unit also includes: a third acquisition module, used to obtain a service directory under the SOA architecture, wherein the service directory records the registration information of all SOA services deployed under the SOA architecture; a creation module, used to create virtual microservice instance information for each SOA service in the service directory based on the registration information; a fourth acquisition module, used to obtain the node information of the service gateway based on the second proxy relationship, and use the node information to replace the SOA service address information in the virtual microservice instance information to obtain a virtual microservice list; a second adding module, used to add the virtual microservice list to the service registration center under the microservice architecture, and complete the heterogeneous service publishing of the SOA architecture to the microservice architecture.

[0129] Optionally, the forwarding unit includes: a fifth acquisition module, which is used to obtain the service directory under the SOA service architecture when the SOA service architecture receives a service request involving heterogeneous calls; a first query module, which is used to query the service directory based on the target service name carried in the service request to obtain a first query result, wherein the first query result is used to record the microservice name in the service directory that matches the target service name, and the node information of the service gateway corresponding to the microservice name; a first forwarding module, which is used to forward the service request to the service gateway with the node information indicated by the first query result as the target address; a first determination module, which is used to determine the actual address information of the target service according to the service request through the service gateway after forwarding the service request to the service gateway, including: determining that the target service is a cloud microservice based on the service request; a second query module, which is used to query the microservice information cache in the service gateway to obtain the actual address information of the cloud microservice in the microservice architecture.

[0130] Optionally, the calling unit includes: a sixth acquisition module, used to determine that the target architecture is a microservice architecture based on actual address information, and obtain all service nodes in the microservice architecture and the health status information of each service node; a second determination module, used to determine the target service node to be forwarded among all service nodes based on the health status information and the load balancing strategy; a first format conversion module, used to format the request message of the service request through the protocol conversion strategy in the service gateway; and a second forwarding module, used to forward the request message after format conversion to the target service node.

[0131] Optionally, the forwarding unit also includes: a seventh acquisition module, which is used to obtain a virtual microservice list from a service registration center under the microservice architecture when the microservice architecture receives a service request involving heterogeneous calls; a third query module, which is used to query the virtual microservice list based on the target service name carried in the service request to obtain a second query result, wherein the second query result is used to record the SOA service name in the virtual microservice list that matches the target service name, and the node information of the service gateway corresponding to the SOA service name; a third forwarding module, which is used to forward the service request to the service gateway with the node information indicated by the second query result as the target address; a third determination module, which is used to determine the actual address information of the target service according to the service request through the service gateway after forwarding the service request to the service gateway, including: determining that the target service is a SOA service based on the service request; a fourth query module, which is used to query the SOA service information cache in the service gateway based on the service request to obtain the actual address information of the SOA service in the SOA architecture.

[0132] Optionally, the calling unit also includes: an eighth acquisition module, used to determine that the target architecture is an SOA architecture based on the actual address information, and obtain all ESB nodes in the SOA architecture and the health status information of each ESB node, wherein the ESB node refers to the service bus ESB node; a fourth determination module, used to determine the target ESB node to be forwarded among all ESB nodes based on the health status information and the load balancing strategy; a second format conversion module, used to convert the format of the request message of the service request through the protocol conversion strategy in the service gateway, and forward the request message after format conversion to the target ESB node.

[0133] The above-mentioned interactive calling device for heterogeneous services may also include a processor and a memory. The above-mentioned establishment unit 61, publishing unit 62, forwarding unit 63, calling unit 64, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize corresponding functions.

[0134] The above processor includes a kernel, which calls the corresponding program unit from the memory. One or more kernels can be set to receive and forward service requests involving heterogeneous calls to the service gateway by adjusting kernel parameters. The service gateway determines the actual address information of the target service according to the service request, forwards the service request to the target architecture based on the actual address information, and calls the target service under the target architecture, returning the call result.

[0135] The above-mentioned memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one storage chip.

[0136] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing a program that initializes the following method steps: bridging the service gateway to the microservice architecture and the SOA architecture respectively, establishing a first proxy relationship between the service gateway and the microservice architecture, and a second proxy relationship between the service gateway and the SOA architecture; publishing the cloud microservices in the microservice architecture to the SOA architecture based on the first proxy relationship, and publishing the SOA services in the SOA architecture to the microservice architecture based on the second proxy relationship, completing heterogeneous service publishing; receiving and forwarding service requests involving heterogeneous calls to the service gateway, and the service gateway determining the actual address information of the target service based on the service request; forwarding the service request to the target architecture based on the actual address information, and calling the target service under the target architecture, and returning the call result.

[0137] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute the interactive calling method of heterogeneous services of any one of the above-mentioned embodiments.

[0138] According to another aspect of an embodiment of the present invention, there is also provided an electronic device, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors implement the interactive calling method of heterogeneous services of any one of the above-mentioned embodiments one.

[0139] Figure 7 1 is a hardware structure block diagram of an electronic device (or mobile device) for an interactive calling method for heterogeneous services according to an embodiment of the present invention. Figure 7 As shown, the electronic device may include one or more ( Figure 7 The processor 702 (the processor 702 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 704 for storing data. In addition, the following may also be included: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a keyboard, a power supply and / or a camera. It will be understood by those skilled in the art that Figure 7 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 7 More or fewer components as shown, or with Figure 7 Different configurations are shown.

[0140] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0141] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0142] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0143] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0144] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0145] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0146] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for interactively calling heterogeneous services, characterized in that: Applied to microservice architecture and service-oriented architecture SOA, including: Bridge the service gateway to the microservice architecture and the SOA architecture respectively, establish a first proxy relationship between the service gateway and the microservice architecture, and a second proxy relationship between the service gateway and the SOA architecture; Based on the first proxy relationship, the cloud-based microservices in the microservice architecture are published to the SOA architecture, and based on the second proxy relationship, the SOA services in the SOA architecture are published to the microservice architecture, thereby completing heterogeneous service publishing; Receiving and forwarding a service request involving a heterogeneous call to the service gateway, and the service gateway determining the actual address information of the target service according to the service request; The service request is forwarded to the target architecture based on the actual address information, and the target service is called under the target architecture, and the calling result is returned.

2. The interactive calling method according to claim 1, characterized in that: The step of publishing the cloud-based microservice in the microservice architecture to the SOA architecture based on the first proxy relationship includes: Acquire a microservice list based on a service registration center under the microservice architecture, wherein the microservice list records registration information of all the cloud-based microservices deployed under the microservice architecture; Obtaining node information of the service gateway based on the first proxy relationship, and using the node information to replace the microservice instance information in the registration information to obtain a microservice publishing list; The microservice publishing list is added to the service directory under the SOA architecture to complete the heterogeneous service publishing of the microservice architecture to the SOA architecture.

3. The interactive calling method according to claim 1, characterized in that: The step of publishing the SOA service in the SOA architecture to the microservice architecture based on the second proxy relationship includes: Obtaining a service catalog under the SOA architecture, wherein the service catalog records registration information of all the SOA services deployed under the SOA architecture; For each of the SOA services in the service catalog, create virtual microservice instance information based on the registration information; Obtaining the node information of the service gateway based on the second proxy relationship, and using the node information to replace the SOA service address information in the virtual microservice instance information to obtain a virtual microservice list; The virtual microservice list is added to the service registration center under the microservice architecture to complete the heterogeneous service publishing of the SOA architecture to the microservice architecture.

4. The interactive calling method according to claim 2, characterized in that: The step of receiving and forwarding a service request involving heterogeneous calls to the service gateway comprises: When the SOA service framework receives the service request involving heterogeneous calls, obtaining the service catalog under the SOA service framework; Querying the service directory based on the target service name carried in the service request to obtain a first query result, wherein the first query result is used to record the microservice name in the service directory that matches the target service name, and the node information of the service gateway corresponding to the microservice name; forwarding the service request to the service gateway using the node information indicated by the first query result as the target address; After forwarding the service request to the service gateway, the step of determining the actual address information of the target service according to the service request by the service gateway includes: Determining, based on the service request, that the target service is a cloud-based microservice; The microservice information cache in the service gateway is queried to obtain the actual address information of the cloud-based microservice in the microservice architecture.

5. The interactive calling method according to claim 4, characterized in that: The step of forwarding the service request to the target architecture based on the actual address information comprises: Determine that the target architecture is a microservice architecture based on the actual address information, and obtain all service nodes in the microservice architecture and health status information of each of the service nodes; Determine a target service node to be forwarded among all the service nodes based on the health status information and the load balancing strategy; Performing format conversion on the request message of the service request through the protocol conversion strategy in the service gateway; The request message after format conversion is forwarded to the target service node.

6. The interactive calling method according to claim 3, characterized in that: The step of receiving and forwarding a service request involving a heterogeneous call to the service gateway further includes: When the microservice architecture receives the service request involving heterogeneous calls, obtaining the virtual microservice list from the service registration center under the microservice architecture; Query the virtual microservice list based on the target service name carried in the service request to obtain a second query result, wherein the second query result is used to record the SOA service name in the virtual microservice list that matches the target service name, and the node information of the service gateway corresponding to the SOA service name; forwarding the service request to the service gateway using the node information indicated by the second query result as the target address; After forwarding the service request to the service gateway, the step of determining the actual address information of the target service according to the service request by the service gateway includes: Determining, based on the service request, that the target service is a SOA service; The SOA service information cache in the service gateway is queried based on the service request to obtain the actual address information of the SOA service in the SOA architecture.

7. The interactive calling method according to claim 6, characterized in that: The step of forwarding the service request to the target architecture based on the actual address information further includes: Determine that the target architecture is an SOA architecture based on the actual address information, and obtain all ESB nodes in the SOA architecture and health status information of each of the ESB nodes, wherein the ESB node refers to a service bus ESB node; Determine a target ESB node to be forwarded among all the ESB nodes based on the health status information and the load balancing strategy; The request message of the service request is format-converted by the protocol conversion strategy in the service gateway, and the request message after format conversion is forwarded to the target ESB node.

8. An interactive calling device for heterogeneous services, characterized in that: Applied to microservice architecture and service-oriented architecture SOA, including: An establishing unit, used to bridge the service gateway to the microservice architecture and the SOA architecture respectively, establish a first proxy relationship between the service gateway and the microservice architecture, and a second proxy relationship between the service gateway and the SOA architecture; A publishing unit, configured to publish the cloud-based microservices in the microservice architecture to the SOA architecture based on the first proxy relationship, and to publish the SOA services in the SOA architecture to the microservice architecture based on the second proxy relationship, thereby completing heterogeneous service publishing; A forwarding unit, configured to receive and forward a service request involving a heterogeneous call to the service gateway, wherein the service gateway determines the actual address information of the target service according to the service request; The calling unit is used to forward the service request to the target architecture based on the actual address information, call the target service under the target architecture, and return the calling result.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located is controlled to execute the method for interactively calling heterogeneous services as described in any one of claims 1 to 7.

10. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the interactive calling method of heterogeneous services described in any one of claims 1 to 7.

Images