Microservice calling method and device, storage medium and gateway equipment

Abstract

The invention discloses a micro-service calling method and device, gateway equipment and a storage medium, and relates to the field of computers. The micro-service calling method comprises the following steps: receiving an external calling request sent by a user through a client; obtaining a grouping identifier corresponding to the network province identifier; querying a target large area group indicated by the group identifier in a large area group set; querying a target provincial node indicated by the network provincial identifier in a plurality of provincial nodes included in the target large area group; the external calling request is forwarded to the target provincial node, so that the target micro-service instance corresponding to the micro-service ID running in the target provincial node responds to the external calling request, and the overall stability and availability of the system are remarkably improved through the measures of partition deployment, fault isolation, ordered updating, efficient resource utilization and the like; and the risk of fault propagation is reduced.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a method, system, device, storage medium and gateway device for calling a microservice. Background Art

[0002] With the in-depth application of microservice architecture in various industries, the service deployment mode has gradually shifted from traditional single application deployment to a more flexible and scalable centralized deployment mode. The centralized deployment mode deploys multiple microservice instances in a unified physical or virtual environment, which significantly improves resource utilization, reduces operation and maintenance costs, and simplifies management processes through efficient resource management and scheduling.

[0003] However, while the centralized deployment model brings many benefits, it is also accompanied by a series of potential risks and challenges. Among them, the most prominent problem is the difficulty of fault isolation. In a centralized deployment environment, each microservice instance shares the same underlying resources (such as network, storage, computing resources, etc.), which means that when a microservice instance fails, its impact may quickly spread to other microservices and even cause the entire system to crash. Summary of the invention

[0004] In order to solve the above-mentioned technical problems, the present application provides a microservice calling method, related devices and storage medium to solve the problem of low reliability of microservice instance operation in related technologies.

[0005] In a first aspect, the present application provides a method for calling a microservice, including:

[0006] Receive an external call request sent by a user through a client, wherein the external call request carries a network province identifier and a microservice ID;

[0007] Obtaining a group identifier corresponding to the network province identifier;

[0008] Querying the target regional group indicated by the group identifier in the regional group set; the target regional group includes a plurality of provincial nodes, each provincial node running a microservice instance;

[0009] Querying a target provincial node indicated by the network provincial identifier among a plurality of provincial nodes included in the target large area group;

[0010] The external call request is forwarded to the target provincial node, so that the target microservice instance corresponding to the microservice ID running in the target provincial node responds to the external call request.

[0011] In a second aspect, the present application provides a service calling device, comprising:

[0012] A receiving unit, configured to receive an external call request sent by a user through a client, wherein the external call request carries a network province identifier and a microservice ID;

[0013] An acquiring unit, configured to acquire a group identifier corresponding to the network province identifier;

[0014] A query unit, configured to query a target regional group indicated by the group identifier in the regional group set; the target regional group includes a plurality of provincial nodes, each provincial node running a microservice instance;

[0015] The query unit is further configured to query a target provincial node indicated by the network provincial identifier among a plurality of provincial nodes included in the target large area group;

[0016] A forwarding unit is used to forward the external call request to the target provincial node, so that the target microservice instance corresponding to the microservice ID running in the target provincial node responds to the external call request.

[0017] In a third aspect, an embodiment of the present application provides a computer storage medium, wherein the computer storage medium stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the above-mentioned method steps.

[0018] In a fourth aspect, an embodiment of the present application provides a gateway device, which may include: a processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the above-mentioned method steps.

[0019] According to the above embodiments, when an application service is abnormal in a specific regional group, due to the adoption of a partition deployment strategy, the fault is effectively limited to the affected regional group and will not affect the applications of other regional groups. This fault isolation mechanism ensures the overall stability and reliability of the system and avoids global service interruptions caused by single point failures. The update of application services is carried out in sequence according to the regional group, which means that during the update process, only the deployment group currently being updated will be temporarily unavailable, while the applications of other regional groups can still run normally. This orderly update strategy reduces the service interruption time caused by the update and improves the availability and user experience of the system. Through partition deployment, the system can use resources more flexibly and dynamically adjust according to the load conditions and business needs of each regional group. This deployment method not only improves the utilization of resources, but also facilitates the horizontal expansion of the system, so that the system can easily cope with the growing business needs and user scale. User requests can access the corresponding regional group nearby according to the network provincial identifier, which greatly reduces network latency and improves user experience. By optimizing the request routing strategy, the system can ensure that user requests reach the target microservice instance at the fastest speed, thereby providing smoother and more efficient services. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0021] Figure 1 This is a network architecture diagram provided by an embodiment of the present application;

[0022] Figure 2 It is a flowchart of a microservice calling method provided in an embodiment of the present application;

[0023] Figure 3 It is a schematic diagram of the mapping relationship between the regional grouping and the provincial nodes provided in the embodiment of the present application;

[0024] Figure 4 This is a schematic diagram of a device provided in an embodiment of the present application.

[0025] Figure 5 It is a structural diagram of a gateway device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0026] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is further described in detail below in conjunction with the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application. At the same time, in the description of the present application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance. It should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits and methods are omitted to prevent unnecessary details from hindering the description of the present application.

[0027] Figure 1 An exemplary system architecture 100 that can be applied to a microservice invocation method or a service invocation device of the present application is shown.

[0028] like Figure 1As shown, the system architecture 100 may include a terminal device 101, a terminal device 102, a terminal device 103, a gateway device 104 and a server 105, each terminal device corresponding to a user. The user of the present application may be a client in the terminal devices 101 to 103, the server 105 is provided with a plurality of large area groups, and the number of servers in the server 105 may be multiple. The gateway device 104 is used to provide a medium for a communication link between the terminal devices 101 to 103. The gateway device 104 may include various types of wired communication links or wireless communication links, for example: a wired communication link includes an optical fiber, a twisted pair or a coaxial cable, and a wireless communication link includes a Bluetooth communication link, a wireless fidelity (WIreless-FIdelity, Wi-Fi) communication link or a microwave communication link, etc.

[0029] It should be noted that the microservice calling method provided in the embodiment of the present application is generally executed by a gateway device, and accordingly, the service calling device is generally set in the gateway.

[0030] It should be understood that Figure 1 The number of terminal devices, gateway devices and servers in the embodiment is only for illustration. According to the implementation requirements, any number of terminal devices, gateway devices and servers may be used.

[0031] In order to illustrate the technical solution described in this application, a specific embodiment is provided below for illustration.

[0032] See also Figure 2 , Figure 2 : is a flow chart of a method for calling a microservice provided in an embodiment of the present application. In an embodiment of the present application, the method includes:

[0033] S201. Receive an external call request sent by a user through a client, where the external call request carries a network province identifier and a microservice ID.

[0034] Among them, after the gateway device is started, it will listen to a specific network port (such as HTTP / HTTPS port) and wait for the client to send a request. When receiving an external call request, the gateway device first parses the request header or request body, and extracts the province ID (ProvinceID) and microservice ID (MicroserviceID) from it. These identifiers usually exist in the form of request parameters, request header fields, or JSON request bodies. While parsing the request, the gateway device can also verify the request, such as checking whether the request format is correct and whether it contains necessary authentication information (such as tokens, signatures, etc.).

[0035] In some embodiments of the present application, based on the user's configuration instructions, the mapping relationship between the regional groupings and the provincial nodes is configured, and the number of microservice instances of the target microservice in each group is configured.

[0036] The gateway device provides a user-friendly interface or command line tool to allow users to enter configuration instructions. The user enters the mapping relationship between the regional group and the provincial node through the interface or command line tool, including the name of the regional group, the list of provincial nodes included, and other information. The gateway device parses the configuration instructions entered by the user and extracts the relevant information of the regional group and the provincial node. The extracted information is verified to ensure that the regional group name is unique and the nodes in the provincial node list are not repeated and valid.

[0037] For example, see Figure 3 The diagram of the mapping relationship between the regional grouping and the provincial nodes shown in the figure shows that the regional grouping is divided into: North China deployment group, East China deployment group, Central China deployment group, ... Northwest deployment group. Multiple provincial nodes are set in each deployment group. Microservice instances are running in the provincial nodes. The number of microservices of a microservice is multiple, and multiple microservice instances may be distributed in different regional groups. For example, for microservice A, 20 microservice instances are created, 10 microservice instances are running in the Central China deployment group, and 10 microservice instances are running in the Southwest deployment group, which improves the reliability of microservice operation in turn.

[0038] Based on the verified information, the gateway device updates the internal mapping table between the regional grouping and the provincial node. The mapping table is used to find the corresponding regional grouping and provincial node according to the network and province identifier in the subsequent steps. The user enters the configuration instructions of the microservice instance through the interface or command line tool of the gateway device. The configuration instructions include information such as the group identifier, the microservice ID, and the number of instances of the microservice in each group. The gateway device parses the configuration instructions entered by the user and extracts information such as the group identifier, the microservice ID, and the number of instances. The extracted information is verified to ensure that the group identifier is valid, the microservice ID is unique, and the number of instances is a positive integer. Based on the verified information, the gateway device updates the internal microservice instance configuration table. The configuration table is used to record the number of instances of each microservice in each group, as well as information such as the running status of the instance. When updating the configuration, the gateway device can also consider factors such as load balancing and fault tolerance to ensure that the distribution of microservice instances is reasonable and efficient.

[0039] Further, in some embodiments of the present application, the gateway device or microservice management platform is first responsible for deploying the code package, configuration file, etc. of the target microservice to a specified server or container. According to the number of microservice instances defined in the configuration file, multiple microservice instances are started. These instances may run on different physical machines, virtual machines, or containers to achieve high availability and load balancing. After startup, each microservice instance will register itself with a microservice registry (such as Eureka, Consul, Nacos, etc.), including information such as the IP address, port number, and service name of the instance. The registry is responsible for recording and managing the information of all microservice instances, and providing service discovery functions, allowing other services or components to find and access these instances.

[0040] The gateway device selects the corresponding microservice instance for each region group according to the user's configuration instructions or preset policies. The selection process may involve the application of load balancing algorithms (such as polling, random, weight, etc.) to ensure that service requests can be evenly distributed to different microservice instances. The gateway device maintains a mapping table internally to record the correspondence between each region group and the selected microservice instance. This mapping table is dynamically updated and can be adjusted according to the actual operation and user configuration.

[0041] The gateway device binds the identifier of the selected microservice instance (such as instance ID, IP address + port number, etc.) with the group identifier of the corresponding zone group. This binding relationship is used to quickly locate the target microservice instance according to the network province identifier and microservice ID when processing user requests later. The gateway device establishes a stable connection with the microservice registration center to obtain the status changes of the microservice instance (such as new additions, offline, failures, etc.) in real time. The gateway device sends heartbeat packets to the registration center regularly or on demand to maintain the validity of the connection. The gateway device instructs the registration center to record the assigned group identifier and the corresponding microservice instance information. After receiving this information, the registration center will update its service list to ensure that service discovery and routing functions can be provided correctly. The gateway device can monitor the running status of the microservice instance in real time, and automatically trigger the fault recovery mechanism (such as restarting the instance, reallocating requests, etc.) when a fault or performance degradation is detected. At the same time, the gateway device can also dynamically adjust the number and distribution of microservice instances according to the load situation to achieve more efficient resource utilization and service performance. Through the above steps, the gateway device can successfully start the target microservice and create multiple microservice instances, select and map them to the specified group, establish a connection with the registration center and record the assigned group identifier.

[0042] In some embodiments of the present application, before step S201, the following steps are further included:

[0043] The gateway device is pre-configured with the HTML template of the login interface and related front-end resources (such as CSS, JavaScript, etc.). These resources are deployed on a web server accessible to the gateway device. When a user attempts to access a resource that requires authentication, the gateway device intercepts the request and redirects it to the login interface. After receiving the redirect instruction, the client (such as a browser) loads and displays the login interface. The login interface contains input fields for the username and password, and a submit button. The user enters his or her username and password in these fields and clicks the submit button. The client encapsulates the username and password entered by the user in an HTTP request and sends it to the gateway device for verification. The request may use the POST method to ensure data security. The gateway device is integrated with an authentication service (such as LDAP, OAuth2, database, etc.). When receiving a user's login request, the gateway device sends the username and password to the authentication service for verification. The authentication service returns the verification result to the gateway device. If the verification is successful, it indicates that the user's identity is legal; if the verification fails, an error message is returned. After successfully verifying the user's identity, the gateway device obtains the user's detailed information from the authentication service or user information database. This information may include the user's name, email address, phone number, provincial region, etc. The gateway device extracts the provincial region where the user is located from the user information. If the provincial region information is not directly included in the user information, it may need to be inferred based on the user's geographic location or other identifiers. The gateway device generates a unique provincial network identifier based on the provincial region where the user is located. The provincial network identifier may be an encrypted or hashed string to ensure its security and uniqueness. The gateway device creates an HTTP cookie with the provincial network identifier as the cookie value. The cookie can be set with appropriate expiration time, path, domain and other attributes to ensure its correct storage and access on the client.

[0044] The gateway device adds the generated cookie to the header of the HTTP response. At the same time, it builds a response body containing login success information, such as user information, permission list, etc. The gateway device sends the HTTP response containing the cookie to the client. After receiving the response, the client (such as a browser) stores the cookie locally according to the instructions in the response header. The client stores the received cookie in the browser's cookie storage area according to the provisions of the HTTP protocol. In subsequent requests, the client will automatically include the relevant cookie in the request header and send it to the server (such as a gateway device).

[0045] Through the above steps, the gateway device successfully displays the login interface on the user client, receives the user name and password entered by the user, verifies the user's identity, obtains the user's provincial region, generates a cookie with the network and provincial identification, and sends the cookie to the client for storage. This provides a basis for providing personalized services and resource access control based on user identity and provincial region.

[0046] S202: Obtain a grouping identifier corresponding to the network province identifier.

[0047] The gateway device maintains a mapping table of province ID to group ID (ProvinceID-to-GroupID Map) inside. The mapping table can be loaded when the gateway device is started, or can be dynamically obtained from a remote configuration center.

[0048] According to the network province identifier extracted in step S201, the gateway device searches for the corresponding group identifier (GroupID) in the mapping table. If found, proceed to the next step; if not found, return an error response to the client.

[0049] S203, querying the target regional group indicated by the group identifier in the regional group set; the target regional group includes multiple provincial nodes, and each provincial node runs a microservice instance.

[0050] The gateway device internally maintains a region group collection, each of which contains multiple provincial nodes. These region group information can be loaded when the gateway device is started, or dynamically obtained from a remote configuration center. According to the group identifier obtained in step S202, the gateway device searches for the corresponding target region group in the region group collection. If found, proceed to the next step; if not found, return an error response to the client.

[0051] S204. Query a target provincial node indicated by a network provincial identifier among a plurality of provincial nodes included in the target region group.

[0052] The gateway device traverses multiple provincial nodes contained in the target region group. For each provincial node, the gateway device checks whether it contains a provincial node that matches the network province identifier extracted in step S201. If a matching provincial node is found, it is regarded as the target provincial node; if no matching node is found after traversing all provincial nodes, an error response is returned to the client.

[0053] S205. Forward the external call request to the target provincial node, so that the target microservice instance corresponding to the microservice ID running in the target provincial node responds to the external call request.

[0054] Among them, the gateway device builds a new HTTP / HTTPS request based on the information of the target provincial node (such as IP address, port number, service path, etc.), and copies the content of the original external call request (including request header, request body, etc.) to the new request. The gateway device sends the constructed forwarding request to the target provincial node through the TCP / IP protocol. This usually involves steps such as establishing a TCP connection, sending an HTTP request header, sending an HTTP request body (if any), and closing the TCP connection. The gateway device waits for the response of the target provincial node. After receiving the forwarding request, the target provincial node will route it to the corresponding microservice instance (matched according to the microservice ID) and return the response of the microservice instance to the gateway device. After receiving the response from the target provincial node, the gateway device returns it directly to the original client. This usually involves steps such as reading the response header, reading the response body (if any), building an HTTP response and sending it to the client.

[0055] In some embodiments of the present application, a lightweight monitoring agent is deployed on each target microservice instance to collect and report the load data of the instance. Select or develop a centralized monitoring platform to receive, store and analyze the load data from each microservice instance. Determine the load indicators that need to be monitored, such as CPU usage, memory occupancy, disk IO, network bandwidth, response time, etc. Set reasonable thresholds or ranges for these indicators based on business requirements and system characteristics. The monitoring agent regularly collects the load data of the microservice instance and reports the data to the centralized monitoring platform. The monitoring platform preprocesses and stores the collected data for subsequent analysis and query.

[0056] The monitoring platform analyzes the collected load data in real time and calculates the current value, average value, maximum value and other statistical information of each indicator. When an indicator exceeds the preset threshold, the monitoring platform triggers the alarm mechanism and notifies relevant personnel through email, SMS, instant messaging and other means.

[0057] According to business needs and system characteristics, formulate strategies for dynamically adjusting the number of microservice instances. Strategies may include threshold adjustment based on load indicators, adjustment based on time series prediction, adjustment based on business traffic, etc. The monitoring platform is integrated with the microservice management platform (such as Kubernetes, Docker Swarm, etc.) to realize the automatic adjustment of microservice instances. When the monitoring platform detects that the load exceeds or falls below the preset threshold, it automatically triggers the scaling mechanism of the microservice management platform to increase or decrease the number of microservice instances. The microservice management platform schedules new microservice instances to run on appropriate nodes based on the current cluster resource situation and policy requirements. The scheduling process may involve adjustments in resource allocation, network configuration, security policies, etc. After adding a new microservice instance, the monitoring platform performs a health check on it to ensure that the instance can run normally and provide services. For microservice instances that fail or have degraded performance, the monitoring platform promptly triggers the fault recovery mechanism, such as restarting the instance, reallocating requests, etc. The monitoring platform and the microservice management platform record the process and results of each dynamic adjustment, including the time, reason, and executed commands of the adjustment. These log records can be used for subsequent audits and troubleshooting to help the team understand the operating status and performance bottlenecks of the system. Through the above steps, you can monitor the load of the target microservice instances in the target region group and dynamically adjust the number of microservice instances according to the load. This helps improve the stability and performance of the system and ensure that the business can run continuously and efficiently.

[0058] Furthermore, in some embodiments of the present application,

[0059] The communication component of the gateway device or microservice framework is responsible for receiving the internal call request from the first microservice. The request usually contains the target microservice (i.e., the second microservice) identification, call parameters, request type (such as synchronous / asynchronous) and other information. The received internal call request is parsed to extract key information such as the target microservice identification and call parameters. According to the configuration or policy, it is determined whether the request needs to be authenticated, permission checked and other security processing.

[0060] According to the parsed identifier of the first microservice (such as microservice ID, service name, etc.), a query request is constructed. The query request may also contain other information, such as the network and province identifier of the current user, so as to locate the correct regional group in subsequent steps. The query request is sent to the microservice registration center. The registration center searches for and returns the identifier of the regional group where the first microservice is located based on the information in the query request.

[0061] Use the region group identifier obtained from the registration center to construct an instance query request for the second microservice. Send the query request to the microservice registration center or the relevant microservice management platform. The registration center or management platform returns all microservice instance information of the second microservice running in the region group based on the query request. The gateway device or microservice framework organizes this instance information into a service instance list, which contains key information such as the IP address, port number, and health status of each instance.

[0062] According to the preset load balancing strategy (such as polling, random, weight, etc.), select a suitable microservice instance from the service instance list. The load balancing strategy may also consider factors such as the health status, response time, and load situation of the instance. After selecting the microservice instance, perform a final health check and availability confirmation on it. If the instance is unavailable (such as abnormal health status, reaching the maximum concurrency, etc.), reselect another instance.

[0063] According to the IP address and port number of the selected microservice instance, a forwarding package for the internal call request is constructed. The forwarding package is sent to the selected microservice instance, instructing it to process and respond to the internal call request of the first microservice. During the request forwarding process, the request tracking mechanism can be enabled to record the flow path, processing time and other information of the request. The monitoring component monitors the request processing process in real time to ensure that the request can reach the target microservice instance correctly and efficiently. Through the above steps, the gateway device or microservice framework can receive the internal call request of the first microservice, query the region group according to the registration center and obtain the list of microservice instances of the second microservice, and finally select and send the request to the selected microservice instance for processing. This realizes internal calls and efficient communication between microservices.

[0064] In the implementation of the embodiment of the present application, when the caller calls the target service, the caller's identity is encrypted using the public key to obtain a call request, and the call request is signed based on the digest algorithm to obtain a digital signature, and the call request and the digital signature are sent to the target service. After the digital signature is verified, the call request is decrypted using the private key to obtain the caller's identity. When the identity is in the preset whitelist, the caller is allowed to call the target service. In this way, the process of calling the service can verify the identity of the caller and the integrity of the call request, avoid illegal calls to the service by a third party, improve the security of the service call and reduce the processing overhead.

[0065] Above Figures 2 to 3 The invocation method of the microservice is described in detail. A structural diagram of a device according to an embodiment of the present application is shown.

[0066] See also Figure 4 , Figure 4It is a structural diagram of a device 4 provided in an embodiment of the present application. The device 4 may include: a receiving unit 401, an acquiring unit 402, a query unit 403, and a forwarding unit 404.

[0067] The receiving unit 401 is used to receive an external call request sent by a user through a client, wherein the external call request carries a network province identifier and a microservice ID;

[0068] An acquisition unit 402 is used to acquire a group identifier corresponding to the network province identifier;

[0069] A query unit 403 is used to query the target regional group indicated by the group identifier in the regional group set; the target regional group includes multiple provincial nodes, each provincial node runs a microservice instance;

[0070] The query unit 403 is further configured to query a target provincial node indicated by the network provincial identifier from among a plurality of provincial nodes included in the target large area group;

[0071] The forwarding unit 404 is used to forward the external call request to the target provincial node, so that the target microservice instance corresponding to the microservice ID running in the target provincial node responds to the external call request.

[0072] In one or more possible embodiments, it further includes:

[0073] The configuration unit is used to configure the mapping relationship between the regional grouping and the provincial node based on the user's configuration instructions, and to configure the number of microservice instances of the target microservice in each grouping.

[0074] In one or more possible embodiments, configuring the number of microservice instances of a microservice in a provincial node includes:

[0075] After starting the target microservice, create multiple microservice instances;

[0076] Selecting a microservice instance from the multiple microservice instances to map with a specified group;

[0077] Bind the grouping identifier of the designated large area grouping to the selected microservice instance, establish a connection with the registration center, and instruct the registration center to record the allocated grouping identifier.

[0078] In one or more possible embodiments, it further includes:

[0079] The adjustment unit is used to monitor the load of the target microservice instances running in the target large area group, and dynamically adjust the number of the target microservice instances in the target large area group according to the load.

[0080] In one or more possible embodiments, it further includes:

[0081] An internal processing unit, configured to receive an internal call request of the first microservice, wherein the internal call request is used to call the second microservice;

[0082] Querying the region group where the first microservice is located according to the registration center, and obtaining the microservice instance of the second microservice running in the queried region group, and generating a service instance list;

[0083] The internal call request is sent to the queried large region group to instruct a microservice instance in the service instance list to respond to the internal call request.

[0084] In one or more possible embodiments, it further includes:

[0085] A generating unit, configured to display a login interface on a user's client and receive a user name and password input by the user on the login interface;

[0086] After verifying the user's identity based on the username and password, the provincial region where the user is located is obtained, and a cookie with a network province identifier is generated based on the provincial region, and the cookie is sent to the user's client for storage.

[0087] In one or more possible embodiments, the network province identifier is hashed and encrypted to generate a cookie, and the cookie is set with an expiration time, path and domain.

[0088] The embodiments of this application and Figure 2 and Figure 3 The method embodiments are based on the same concept, and the technical effects they bring are also the same. The specific process can be referred to Figure 2 and Figure 3 The description of the method embodiment will not be repeated here.

[0089] The present application also provides a computer storage medium, which can store multiple instructions, and the instructions are suitable for being loaded and executed by a processor as described above. Figure 2 and Figure 3 The method steps of the embodiment shown in the figure can be found in the specific implementation process. Figure 2 and Figure 3 The specific description of the illustrated embodiment will not be repeated here.

[0090] The present application also provides a computer program product, which stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the microservice calling method described in the above embodiments.

[0091] See also Figure 5 , which is a schematic diagram of the structure of a gateway device provided in an embodiment of the present application. Figure 5 As shown, the gateway device 500 may include: at least one processor 501 , at least one network interface 504 , a user interface 503 , a memory 505 , and at least one communication bus 502 .

[0092] The communication bus 502 is used to realize the connection and communication between these components.

[0093] The user interface 503 may include a display screen (Display) and a camera (Camera), and the optional user interface 503 may also include a standard wired interface and a wireless interface.

[0094] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0095] Among them, the processor 501 may include one or more processing cores. The processor 501 uses various interfaces and lines to connect the various parts of the entire gateway device 500, and executes various functions and processes data of the gateway device 500 by running or executing instructions, programs, code sets or instruction sets stored in the memory 505, and calling data stored in the memory 505. Optionally, the processor 501 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The processor 501 can integrate one or more combinations of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 501, and it can be implemented separately through a chip.

[0096] Among them, the memory 505 may include a random access memory (Random Access Memory, RAM) and may also include a read-only memory (Read-Only Memory). Optionally, the memory 505 includes a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 505 may also be optionally at least one storage device located away from the aforementioned processor 501. As Figure 5 As shown, the memory 505 as a computer storage medium may include an operating system, a network communication module, a user interface module and an application program.

[0097] exist Figure 5 In the gateway device 500 shown in FIG. 1 , the user interface 503 is mainly used to provide an input interface for the user and obtain the data input by the user; and the processor 501 can be used to call the application stored in the memory 505 and specifically execute the following steps: Figure 2 The specific process can be referred to Figure 2 As shown, no further description is given here.

[0098] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The storage medium can be a disk, an optical disk, a read-only storage memory, or a random access memory, etc.

[0099] The above disclosure is only the preferred embodiment of the present application, which certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A method for calling a microservice, characterized in that: include: Receive an external call request sent by a user through a client, wherein the external call request carries a network province identifier and a microservice ID; Obtaining a group identifier corresponding to the network province identifier; Querying the target region group indicated by the group identifier in the region group set; The target region group includes multiple provincial nodes, each of which runs a microservice instance; Querying a target provincial node indicated by the network provincial identifier among a plurality of provincial nodes included in the target large area group; The external call request is forwarded to the target provincial node, so that the target microservice instance corresponding to the microservice ID running in the target provincial node responds to the external call request.

2. The method according to claim 1, characterized in that Also includes: Based on the user's configuration instructions, the mapping relationship between the regional grouping and the provincial node is configured, and the number of microservice instances of the target microservice in each group is configured.

3. The method according to claim 2, characterized in that The configuration of the number of microservice instances of the microservice in the provincial node includes: After starting the target microservice, create multiple microservice instances; Selecting a microservice instance from the multiple microservice instances to map with a specified group; Bind the grouping identifier of the designated large area grouping to the selected microservice instance, establish a connection with the registration center, and instruct the registration center to record the allocated grouping identifier.

4. The method according to claim 1, 2 or 3, characterized in that: Also includes: Monitor the load of the target microservice instances running in the target region group, and dynamically adjust the number of the target microservice instances in the target region group according to the load.

5. The method according to claim 4, characterized in that Also includes: An internal call request of the first microservice is received, where the internal call request is used to call the second microservice; Querying the region group where the first microservice is located according to the registration center, and obtaining the microservice instance of the second microservice running in the queried region group, and generating a service instance list; The internal call request is sent to the queried large region group to instruct a microservice instance in the service instance list to respond to the internal call request.

6. The method according to claim 1 or 2 or 3 or 5, characterized in that: The receiving of the external call request sent by the user through the client, before the external call request carries the network province identifier and the microservice ID, also includes: Displaying a login interface on the user's client, and receiving a user name and password entered by the user on the login interface; After verifying the user's identity based on the username and password, the provincial region where the user is located is obtained, and a cookie with a network province identifier is generated based on the provincial region, and the cookie is sent to the user's client for storage.

7. The method according to claim 6, characterized in that The network province identifier is hashed and encrypted to generate a cookie, and the cookie is set with an expiration time, path and domain.

8. A microservice calling device, characterized in that: include: A receiving unit, configured to receive an external call request sent by a user through a client, wherein the external call request carries a network province identifier and a microservice ID; An acquiring unit, configured to acquire a group identifier corresponding to the network province identifier; A query unit, configured to query a target regional group indicated by the group identifier in the regional group set; the target regional group includes a plurality of provincial nodes, each provincial node running a microservice instance; The query unit is further configured to query a target provincial node indicated by the network provincial identifier among a plurality of provincial nodes included in the target large area group; A forwarding unit is used to forward the external call request to the target provincial node, so that the target microservice instance corresponding to the microservice ID running in the target provincial node responds to the external call request.

9. A gateway device, characterized in that: The method comprises a processor and a memory, wherein the memory is used to store a computer program, the computer program comprises program instructions, and the processor is used to call the program instructions to execute the method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that: The computer storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a processor, the processor is enabled to perform any one of claims 1 to 6.

Images