Service access method and device

Abstract

The present application discloses a service access method and device, which relates to the field of communication network technology. The method includes: obtaining a service access request, the service access request is used to request access to a target service; detecting whether the target service is a service in a service whitelist; if the target service is a service in the service whitelist, modifying the Pod network interconnection protocol IP of the target service to a service name service name, and calling the target service according to the service name; if the target service is not a service in the service whitelist, calling the target service according to the Pod IP of the target service. The problem that the existing design cannot meet the needs of business scenarios is solved, and the application-level architecture upgrade can be achieved in the form of a service whitelist, so that the network call of microservices supports both Spring Cloud and Service Mesh mechanisms, thereby making the architecture upgrade smoother and more stable.

Description

Technical Field

[0001] The invention relates to a service access method and device, and belongs to the technical field of communication networks. Background Art

[0002] In the existing Spring Cloud system, the service call is that the client service obtains the Pod information of the server service from Consul through the service name, and then directly connects to the Pod to make a network call. During the transition period from the Spring Cloud system to ServiceMesh, in order to ensure the stability of the service, a small number of services are often upgraded first, and some services remain unchanged. After the upgraded services are stable, the full upgrade is performed. However, the two existing network calls can only run independently in their own way, which cannot meet the needs of real business scenarios. Summary of the invention

[0003] The purpose of the present invention is to provide a service access method and device to solve the problems existing in the prior art.

[0004] In order to achieve the above object, the present invention provides the following technical solutions:

[0005] According to a first aspect, an embodiment of the present invention provides a service access method, the method comprising:

[0006] Obtaining a service access request, wherein the service access request is used to request access to a target service;

[0007] Detecting whether the target service is a service in a service whitelist;

[0008] If the target service is a service in the service whitelist, the Pod network interconnection protocol IP of the target service is modified to the service name service name, and the target service is called according to the service name;

[0009] If the target service is not a service in the service whitelist, the target service is called according to the PodIP of the target service.

[0010] Optionally, calling the target service according to the service name includes:

[0011] The service access request is forwarded to the sidecar of ServiceMesh through the iptables routing policy according to the service name, and the target service is called.

[0012] Optionally, calling the target service according to the service name includes:

[0013] The service access request accessed through the service name is intercepted by Envoy, and the target service is called through Envoy.

[0014] Optionally, if the service is called in Feign, the detection of whether the target service is a service in the service whitelist includes:

[0015] Select a service instance from at least two service instances through a load balancing algorithm;

[0016] Whether the target service is a service in a service whitelist is detected by the selected service instance.

[0017] Optionally, modifying the Pod network interconnection protocol IP of the target service to a service name service name includes:

[0018] If the target service is a service in the service whitelist, the PodIP in the Pod Server Info is changed to the service name.

[0019] Optionally, if the service is called in a gRPC calling manner, the detecting whether the target service is a service in a service whitelist includes:

[0020] When gRPC Starter creates a NettyChannel through the builder, it detects whether the target service is a service in the service whitelist.

[0021] Optionally, modifying the Pod network interconnection protocol IP of the target service to a service name service name, and calling the target service according to the service name includes:

[0022] Modify the PodIP of the target service to the service name, and execute the created NettyChannel.

[0023] Optionally, the method further includes:

[0024] After receiving the service access request, the PodIP corresponding to the service name is obtained from Consul according to the service name of the target service.

[0025] In a second aspect, a service access device is provided, the device comprising:

[0026] An acquisition module, used to acquire a service access request, wherein the service access request is used to request access to a target service;

[0027] A detection module, used to detect whether the target service is a service in a service whitelist;

[0028] The calling module is used to modify the Pod network interconnection protocol IP of the target service to a service name service name when the target service is a service in the service whitelist, and call the target service according to the service name; when the target service is not a service in the service whitelist, call the target service according to the Pod IP of the target service.

[0029] By obtaining a service access request, the service access request is used to request access to the target service; detecting whether the target service is a service in the service whitelist; if the target service is a service in the service whitelist, modifying the Pod network interconnection protocol IP of the target service to the service name service name, and calling the target service according to the service name; if the target service is not a service in the service whitelist, calling the target service according to the Pod IP of the target service. This solves the problem that the existing design cannot meet the needs of business scenarios, and achieves the goal of implementing application-level architecture upgrades in the form of service whitelists, allowing microservice network calls to support both SpringCloud and Service Mesh mechanisms, thereby making architecture upgrades smoother and more stable.

[0030] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention and implement it according to the contents of the specification, the following is a detailed description of the preferred embodiments of the present invention in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A method flow chart of a service access method provided by an embodiment of the present invention;

[0032] Figure 2 A schematic diagram of the structure of a service access device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0033] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0034] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.

[0035] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0036] In addition, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0037] First, for ease of understanding, a brief introduction to the professional terms that may be involved in this application is given. Among them:

[0038] Spring Cloud: A microservice architecture commonly used in Java technology systems.

[0039] Service Mesh: Service mesh.

[0040] Feign: http call middleware.

[0041] gRPC: Network call middleware.

[0042] Kubernetes: containerized orchestration system.

[0043] Service: The definition of a service in Kubernetes.

[0044] Pod: The minimum definition of an instance under a Service in Kubernetes. A Service can have multiple Pods.

[0045] Please refer to Figure 1 , which shows a method flow chart of a service access method provided by an embodiment of the present application, such as Figure 1 As shown, the method includes:

[0046] Step 101, obtaining a service access request, wherein the service access request is used to request access to a target service;

[0047] When access to a target service is required, the client may issue a service access request to access the target service.

[0048] Step 102, detecting whether the target service is a service in a service whitelist;

[0049] The service whitelist can be the default service list of the system or a custom list. In actual implementation, the service whitelist can also update the list content as needed. In actual implementation, the services in the service whitelist can be services that have been upgraded to Service Mesh.

[0050] Optionally, in the Spring Cloud microservice system, there are two common service-to-service calling methods: Feign and gRPC. Based on the different calling methods, the detection methods in this step are also different. Therefore, in a possible implementation method, this step may include the following two possible implementation methods:

[0051] The first possible implementation method is to use Feign to call the service. This step includes:

[0052] First, a service instance is selected from at least two service instances through a load balancing algorithm;

[0053] When calling a service using Feign, you can add IstioProperties to receive the configured whitelist service. In order to maintain the retry mechanism and the fuse mechanism, after obtaining the Pod Server List in Consul through the Watch mechanism in Feign Starter, first select a Server Info through the load balancing algorithm.

[0054] Second, the selected service instance is used to detect whether the target service is a service in a service whitelist.

[0055] After selecting Server Info, you can check whether the target service is in the service whitelist.

[0056] The second possible implementation method is to use gRPC to call the service. This step includes:

[0057] When the calling method adopted is gRPC, add IstioProperties to receive the configured whitelist service, and when gRPC Starter creates NettyChannel through builder, detect whether the target service is a service in the service whitelist.

[0058] Step 103: if the target service is a service in the service whitelist, modify the PodIP (Internet Protocol) of the target service to a service name service name, and call the target service according to the service name;

[0059] When the target service is a service in the service whitelist, the PodIP of the target service is replaced with the servicename, and then the target service is called according to the service name.

[0060] Among them, when the service calling method used in step 102 is Feign, this step can be implemented by changing the PodIP in PodServer Info to the service name, and then forwarding the service access request to call the target service.

[0061] When the calling method used in step 102 is gRPC, this step can be implemented by directly changing the PodIP to the service name and executing builder.build() to create the NettyChannel.

[0062] After changing the PodIP to the service name, the step of calling the target service includes: forwarding the service access request to the sidecar of the Service Mesh through the iptables routing policy according to the servicename, and calling the target service.

[0063] Optionally, the service access request accessed through the service name can be intercepted by Envoy, and the target service can be called through Envoy.

[0064] Step 104: If the target service is not a service in the service whitelist, the target service is called according to the Pod IP of the target service.

[0065] If the detection result is that the target service is not a service in the service whitelist, the target service is directly called according to the Pod IP.

[0066] In a possible embodiment of this embodiment, taking Feign as an example, when the server service is started, the meta information of the instance will be registered with consul, including IP and Port; when the client service calls the server service, the instance set of the corresponding server service can be found from consul according to the service name of the called target service; then, an instance is selected from the instance information set according to the load balancing algorithm, and it is detected whether the target service is a service in the whitelist. If so, PodIP is replaced with service name. At this time, the service access request accessed through the service name will be intercepted by Envoy, and the service server2 corresponding to PodIP is obtained through Envoy's service discovery mechanism, such as XDS mechanism; if the target service is not a service in the whitelist, server1 is called directly through PodIP.

[0067] In summary, by obtaining a service access request, the service access request is used to request access to the target service; detecting whether the target service is a service in the service whitelist; if the target service is a service in the service whitelist, the Pod network interconnection protocol IP of the target service is modified to the service name service name, and the target service is called according to the service name; if the target service is not a service in the service whitelist, the target service is called according to the Pod IP of the target service. This solves the problem that the existing design cannot meet the needs of business scenarios, and achieves the goal of implementing application-level architecture upgrades in the form of service whitelists, allowing the network calls of microservices to support both Spring Cloud and Service Mesh mechanisms, thereby making architecture upgrades smoother and more stable.

[0068] Please refer to Figure 2 , which shows a schematic diagram of the structure of a service access device provided by an embodiment of the present application, such as Figure 2 As shown, the service access device may include:

[0069] An acquisition module 310 is used to acquire a service access request, where the service access request is used to request access to a target service;

[0070] A detection module 320, configured to detect whether the target service is a service in a service whitelist;

[0071] The calling module 330 is used to modify the Pod network interconnection protocol IP of the target service to a service name service name when the target service is a service in the service whitelist, and call the target service according to the service name; when the target service is not a service in the service whitelist, call the target service according to the Pod IP of the target service.

[0072] In summary, by obtaining a service access request, the service access request is used to request access to the target service; detecting whether the target service is a service in the service whitelist; if the target service is a service in the service whitelist, the Pod network interconnection protocol IP of the target service is modified to the service name service name, and the target service is called according to the service name; if the target service is not a service in the service whitelist, the target service is called according to the Pod IP of the target service. This solves the problem that the existing design cannot meet the needs of business scenarios, and achieves the goal of implementing application-level architecture upgrades in the form of service whitelists, allowing the network calls of microservices to support both Spring Cloud and Service Mesh mechanisms, thereby making architecture upgrades smoother and more stable.

[0073] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0074] The above-mentioned embodiments only express several implementation methods of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

Claims

1. A service access method, characterized in that: The method comprises: Obtaining a service access request, wherein the service access request is used to request access to a target service; Detecting whether the target service is a service in a service whitelist; If the target service is a service in the service whitelist, the Pod network interconnection protocol IP of the target service is modified to the service name service name, and the target service is called according to the service name; If the target service is not a service in the service whitelist, calling the target service according to the Pod IP of the target service; The calling of the target service according to the service name includes: Forward the service access request to the ServiceMesh sidecar through the iptables routing policy according to the service name, and call the target service. The calling the target service according to the service name includes: The service access request accessed through the service name is intercepted by Envoy, and the target service is called through Envoy.

2. The method according to claim 1, characterized in that If the service is called using Feign, the detection of whether the target service is a service in the service whitelist includes: Select a service instance from at least two service instances through a load balancing algorithm; Whether the target service is a service in a service whitelist is detected by the selected service instance.

3. The method according to claim 2, characterized in that The step of modifying the Pod network interconnection protocol IP of the target service to a service name service name includes: If the target service is a service in the service whitelist, the PodIP in Pod ServerInfo is changed to the service name.

4. The method according to claim 1, characterized in that: If the service is called in the gRPC calling mode, the detection of whether the target service is a service in the service whitelist includes: When gRPC Starter creates a NettyChannel through the builder, it detects whether the target service is a service in the service whitelist.

5. The method according to claim 4, characterized in that The step of modifying the Pod network interconnection protocol IP of the target service to a service name service name, and calling the target service according to the service name, includes: Modify the PodIP of the target service to the service name, and execute the created NettyChannel.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: After receiving the service access request, the PodIP corresponding to the service name is obtained from Consul according to the service name of the target service.

7. A service access device, characterized in that: The device comprises: An acquisition module, used to acquire a service access request, wherein the service access request is used to request access to a target service; A detection module, used to detect whether the target service is a service in a service whitelist; A calling module, used for modifying the Pod network interconnection protocol IP of the target service to a service name service name when the target service is a service in the service whitelist, and calling the target service according to the service name; when the target service is not a service in the service whitelist, calling the target service according to the PodIP of the target service; The calling of the target service according to the service name includes: Forward the service access request to the ServiceMesh sidecar through the iptables routing policy according to the service name, and call the target service. The calling the target service according to the service name includes: The service access request accessed through the service name is intercepted by Envoy, and the target service is called through Envoy.

Images