Distributed system service processing method and device, equipment and medium

Abstract

The invention provides a distributed system service processing method and device, equipment and a medium, and the method comprises the steps: distributing a service request to a gateway layer through a reverse proxy based on a preset load balancing strategy when an access layer receives the service request of a client; the gateway layer obtains an available instance list of a target micro-service in the service layer from a registration / configuration center according to the service request, and routes the service request to a target micro-service instance in the available instance list based on a preset dynamic routing rule; and the target micro-service instance calls the corresponding service logic to process the service request, generates a service processing result of the service request, encapsulates the service processing result and returns the service processing result. According to the invention, through a distributed architecture combining modular layering and a base, the problems of high coupling degree, disordered configuration, low request distribution efficiency, low development efficiency and the like in a distributed system can be effectively solved, and efficient support for multi-terminal collaboration, complex services and high-concurrency scenes is realized.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a distributed system service processing method, device, equipment and medium. Background Art

[0002] With the rapid development of internet technology, distributed systems have been widely adopted in various business scenarios. However, in scenarios involving multi-terminal collaboration, high-concurrency requests, and complex business logic, traditional distributed system architectures still face the following challenges: high coupling, chaotic configuration, inefficient request distribution, and low development efficiency. Therefore, an effective distributed system business processing method is urgently needed to address these issues. Summary of the Invention

[0003] In view of the above problems, the present invention is proposed to provide a distributed system business processing method, apparatus, device and medium that overcome the above problems or at least partially solve the above problems.

[0004] To achieve the above-mentioned and other related objectives, the present invention provides a distributed system service processing method, which is applied to a distributed system. The distributed system includes a registration / configuration center, an access layer, a gateway layer, and a service layer. The method includes:

[0005] When the access layer receives a service request from the client, it distributes the service request to the gateway layer through the reverse proxy based on the preset load balancing strategy;

[0006] The gateway layer obtains a list of available instances of the target microservice in the business layer from the registration / configuration center according to the business request, and routes the business request to the target microservice instance in the list of available instances based on preset dynamic routing rules;

[0007] The target microservice instance calls the corresponding business logic to process the business request, generates a business processing result for the business request, encapsulates the business processing result and returns it.

[0008] Optionally, before the step of distributing the service request to the gateway layer through the reverse proxy when the access layer receives the service request from the client, the method further includes:

[0009] When each microservice in the business layer is started, the registration / configuration center receives and stores the registration information of each microservice; wherein the registration information includes the service name, instance ID, IP address, metadata and status mark of each microservice.

[0010] Optionally, after the step of receiving and storing the registration information of each microservice when each microservice in the business layer is started, the registration / configuration center further includes:

[0011] The registration / configuration center regularly checks the health status of each microservice instance in the registration information through heartbeat detection, and generates a list of available instances of each microservice based on the registration information and the health status.

[0012] Optionally, the gateway layer obtains a list of available instances of the target microservice in the business layer from the registration / configuration center according to the business request, including:

[0013] After receiving the service request, the gateway layer parses the service request to extract the authentication token and verifies the validity and timeliness of the authentication token;

[0014] When it is determined that the authentication token is valid and not expired, parsing the service request to obtain metadata; wherein the metadata includes a service name and a request path;

[0015] According to the service name, the corresponding target microservice of the business layer is determined, and a list of available instances of the target microservice is obtained from the registration / configuration center according to the request path.

[0016] Optionally, the distributed system further includes a monitoring layer, and before the step of routing the service request to the target microservice instance in the available instance list based on a preset dynamic routing rule, the step further includes:

[0017] Obtain the health status of each microservice instance in the available instance list from the registration / configuration center in real time, and obtain the running status of each microservice instance from the monitoring layer in real time;

[0018] Determine whether to perform circuit breaking, degradation, or current limiting based on the health status and operating status of each microservice instance.

[0019] Optionally, the target microservice instance calls corresponding business logic to process the business request and generates a business processing result for the business request, including:

[0020] After the target microservice instance receives the business request, it verifies the authentication token and authority in the business request based on the OAuth2.0 protocol;

[0021] After the authentication token and permission verification are passed, the business request is parsed to obtain request information, and the corresponding business logic is called according to the request information to process the business request and generate a business processing result for the business request; wherein the request information includes the request type and request parameters.

[0022] Optionally, the distributed system further includes a monitoring layer, and after the target microservice calls corresponding business logic to process the business request and generates a business processing result for the business request, the system further includes:

[0023] The monitoring layer records the processing process and results of the business request, generates log information of the business request, and visually displays the log information.

[0024] In a second aspect, the present invention further provides a distributed system service processing device, which is applied to a distributed system, wherein the distributed system includes a registration / configuration center, an access layer, a gateway layer, and a service layer, and the device includes:

[0025] The receiving module is used to distribute the service request from the client to the gateway layer through the reverse proxy based on the preset load balancing strategy when the access layer receives the service request from the client;

[0026] A routing module is used for the gateway layer to obtain a list of available instances of the target microservice in the business layer from the registration / configuration center according to the business request, and to route the business request to the target microservice instance in the available instance list based on preset dynamic routing rules;

[0027] The processing module is used for the target microservice instance to call the corresponding business logic to process the business request, generate the business processing result of the business request, encapsulate the business processing result and return it.

[0028] In a third aspect, the present invention provides an electronic device comprising: a memory and a processor; the memory is used to store computer programs; the processor is used to execute the computer programs stored in the memory, so that the electronic device performs the steps of the distributed system business processing method as described above.

[0029] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by an electronic device, implements the steps of the distributed system business processing method as described above.

[0030] The above one or more technical solutions provided by the present invention may have the following advantages or at least achieve the following technical effects:

[0031] The distributed system business processing method, device, equipment and medium of the present invention are applied to a distributed system, wherein the distributed system includes a registration / configuration center, an access layer, a gateway layer and a business layer, and the method includes: when the access layer receives a business request from a client, based on a preset load balancing strategy, the business request is distributed to the gateway layer through a reverse proxy; the gateway layer obtains a list of available instances of the target microservice in the business layer from the registration / configuration center according to the business request, and routes the business request to the target microservice instance in the list of available instances based on a preset dynamic routing rule; the target microservice instance calls the corresponding business logic to process the business request, generates a business processing result of the business request, encapsulates the business processing result and returns it. The present invention can effectively solve the problems of high coupling, chaotic configuration, inefficient request distribution and low development efficiency in the distributed system by combining a modular layered and base distributed system architecture, and realizes efficient support for multi-terminal collaboration, complex business and high concurrency scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 Shown is a flow chart of a distributed system service processing method according to an embodiment of the present invention;

[0033] Figure 2 Shown is a schematic diagram of the architecture of a distributed system according to an embodiment of the present invention;

[0034] Figure 3 Shown is a schematic diagram of the functional modules of a distributed system service processing device according to an embodiment of the present invention;

[0035] Figure 4 Shown is a schematic diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0036] The following describes the embodiments of the present invention through specific examples. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments. The details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other unless they conflict.

[0037] It should be noted that the illustrations provided in the following embodiments are merely schematic illustrations of the basic concept of the present invention. Therefore, the illustrations only show components related to the present invention and are not drawn according to the number, shape, and size of components in actual implementation. In actual implementation, the type, quantity, and proportion of each component may be changed arbitrarily, and the component layout may also be more complex.

[0038] In the following description, numerous details are discussed to provide a more thorough explanation of the embodiments of the present invention. However, it will be apparent to those skilled in the art that the embodiments of the present invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring the embodiments of the present invention.

[0039] In the description and claims of the embodiments of the present disclosure, as well as in the accompanying drawings, the terms "first," "second," and the like are used to distinguish similar items and are not necessarily used to describe a particular order or precedence. It should be understood that such terms are interchangeable where appropriate for the purposes of describing the embodiments of the present disclosure herein. Furthermore, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions.

[0040] Unless otherwise stated, the term "plurality" means two or more.

[0041] In the embodiments of the present disclosure, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B means: A or B.

[0042] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, "A and / or B" means: A or B, or, A and B.

[0043] Before further explaining the present invention in detail, the nouns and terms involved in the embodiments of the present invention are explained. The nouns and terms involved in the embodiments of the present invention are subject to the following interpretations:

[0044] <1> As the core of a distributed system, the base provides a series of common services and infrastructure that can be shared and efficiently utilized by various microservices in the business layer. By centrally managing configuration information and common facilities, the base effectively avoids duplicate development, simplifies the operation and maintenance process, significantly improves the efficiency and quality of development and operation, and provides a solid guarantee for the stable operation and efficient development of the system. The main functions of the base include:

[0045] The service discovery mechanism, based on the Nacos registry, enables dynamic registration and discovery of microservices, ensuring efficient collaboration among microservice instances.

[0046] Centralized configuration management, leveraging the Nacos Configuration Center tool, enables centralized storage, version management, and dynamic push of configuration information. It supports configuration isolation for different environments (development, testing, and production), avoiding hard-coding of sensitive information and improving the security and timeliness of configuration changes. It also enables microservices to dynamically access configuration information, facilitating unified management and real-time updates.

[0047] The unified authentication and authorization mechanism integrates security frameworks such as OAuth2.0 / JWT / Spring Security to build a security protection system from the gateway layer to the business layer, which can effectively prevent unauthorized access and data leakage.

[0048] Centralized log management, leveraging tools like the ELK stack, enables centralized collection, storage, and analysis of distributed logs across microservices. This allows operations personnel to monitor system status in real time and quickly locate and troubleshoot issues.

[0049] The real-time monitoring and alerting mechanism, based on a Prometheus cluster and a Grafana cluster, collects key microservice metrics (such as QPS (queries per second), response time, and memory usage). A visual interface displays the health status of microservices. Threshold alarm rules can be set, and Alert Manager is used to quickly notify and locate faults. This helps operations personnel identify and resolve problems promptly.

[0050] Message queuing and event-driven development, through the introduction of distributed messaging middleware such as RocketMQ, enables asynchronous decoupling, traffic peak reduction, and eventual consistency communication between microservices. This not only supports asynchronous communication but also effectively handles traffic pressure in high-concurrency scenarios, ensuring stable system operation under high load.

[0051] Distributed cache service, based on Redis, implements localized data caching and distributed cache clustering. The caching mechanism can effectively reduce database pressure and significantly improve system performance and response speed.

[0052] The technical solutions in the embodiments of the present invention will be described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0053] See also Figure 1 An embodiment of the present invention provides a distributed system service processing method, which is applied to a distributed system. The distributed system includes a registration / configuration center, an access layer, a gateway layer, and a service layer. The method may include the following steps S10 to S40:

[0054] Step S10: When the access layer receives a service request from the client, the access layer distributes the service request to the gateway layer through the reverse proxy based on a preset load balancing strategy.

[0055] The distributed system includes: presentation layer, access layer, gateway layer, registration / configuration center, business layer, support layer and monitoring layer. Figure 2 , Figure 2 The following is a schematic diagram of the architecture of a distributed system according to an embodiment of the present invention, wherein:

[0056] The presentation layer serves as the interface for users to interact with the system. It is responsible for displaying data and receiving user input. It supports multiple access methods, including apps, KOL workstations, and user management modules.

[0057] The access layer, as the entrance to the system, is used to receive requests from users of different roles (ordinary users, management users, KOLs (key opinion leaders), platform administrators, etc.), and distribute the requests to backend services according to preset load balancing strategies (such as polling, weighted polling, IP hashing, least connections, response time weighted, random, etc.); the access layer includes components such as CDN (content delivery network), CLB (load balancer) and Nginx (reverse proxy). The combination of the three forms a layered access layer architecture to jointly solve the traffic management problem in distributed systems.

[0058] The gateway layer is used to dynamically distribute requests to specific microservices in the business layer according to preset dynamic routing rules (such as polling, random, and least connections). It consists of a Spring Cloud Gateway cluster and integrates dynamic routing (such as dynamic routing to different service clusters based on request path, request header, or weight strategy), load balancing (such as automatically discovering and removing unavailable instances in conjunction with the registration / configuration center to achieve dynamic traffic distribution), security authentication (such as unified verification of JWT Tokens at the gateway layer), circuit breaking, degradation, and current limiting. It is suitable for distributed system scenarios under the microservice architecture. By unifying traffic entry, it enhances fault tolerance and security protection, effectively improving the stability, scalability, and security of the system.

[0059] The registration / configuration center is built by a Spring CloudAlibaba+Nacos cluster (the Nacos configuration center centrally manages global configurations, covering key information such as database connection pool parameters and Redis configuration. It also relies on the Nacos service registration and discovery mechanism to ensure the efficiency and stability of communication between microservice modules, realizing an integrated solution for configuration management and service governance). It integrates core functions such as service registration and discovery, configuration isolation (configuration isolation is achieved through different namespaces and key-value paths, ensuring that the configuration information of different environments (such as development, testing, and production) or different services can be independent and non-interfering), and dynamic configuration (the base integrates the Nacos configuration center to provide a unified configuration management portal and support dynamic configuration switching for multiple environments (such as development, testing, and production); the business layer accesses configuration information through the configuration tool class provided by the base to avoid hard coding). It is suitable for distributed system scenarios under the microservice architecture.

[0060] The business layer is responsible for implementing specific business logic and handling business needs. It implements secure authentication and authorization based on OAuth2.0 authentication services and Spring Cloud Security (i.e., the authentication and authorization module). Combined with Feign / RPC calls and Seata distributed transactions, it builds a secure, efficient, and data-consistent business layer architecture. Its business logic is split into multiple independent microservices based on the business domain (such as video services, graphic services, live broadcast services, course services, short video services, comment services, message services, etc.). In the business layer, each microservice is built around a specific business function and can be independently developed, deployed, and expanded. Service registration and discovery are implemented through Spring Cloud Alibaba's Nacos. This architecture can effectively avoid direct dependencies between services and improve the system's decoupling, high availability, and dynamic scalability.

[0061] Each microservice module can be split into an API submodule and a Facade submodule. The API submodule is responsible for defining the service interface (i.e., the externally exposed API) and DTO (Data Transfer Object) that can be called by other microservices or clients. The Facade submodule is responsible for encapsulating internal business logic and providing a unified interface to callers. The Facade module relies on the API submodule to separate interface definition and implementation. The layered API and Facade design allows development teams to work in parallel, significantly improving development efficiency and shortening the development cycle by 20%.

[0062] For example, if the microservice identified by the business request is an order service, the API submodule can define the interfaces provided by the order service, such as order creation, order query, and order cancellation. Other services (such as payment services, notification services, and inventory services) can use these interfaces to operate order-related functions. The Facade submodule can encapsulate the complex logic within the order service. When the order query interface is called externally, the Faceda submodule can coordinate multiple internal business logic (such as verifying permissions and querying the database) to complete the query operation.

[0063] The support layer is used to provide the infrastructure and services required by the business layer to support the operation of the business layer. It includes Docker image repositories (deployed through Docker containerization and combined with Docker containerization and Kubernetes to achieve dynamic scaling), automated deployment (such as Jenkins cluster), logs (such as ELK cluster), distributed task scheduling (such as Xxljob, used to manage and schedule scheduled tasks), databases (such as MySQL cluster), caches (such as Redis cluster), message queues (such as RecketMQ), search engines (such as Elasticsearch (ES) cluster) and OSS file servers (cloud storage) and other components. Through the joint collaboration of these components, it can be ensured that the business layer can run efficiently and stably, while having high availability, high scalability and high reliability.

[0064] The monitoring layer is used to monitor the system's operating status (such as resource usage; monitoring the normal operation of each microservice (real-time monitoring of the start, stop, response time and other status information of each microservice; once a microservice fails or responds abnormally, it can quickly discover and locate the problem); data transmission and processing status), provide alarms (such as threshold alarms, abnormal behavior alarms, and support for multiple alarm notification methods, such as SMS, email, instant messaging tools (such as DingTalk, Enterprise WeChat, etc.)) and visual management; it includes service tracking (such as Skywalking cluster), service monitoring (such as Prometheus cluster), visualization (such as Grafana cluster), Alert Manager (alarm management tools, such as SMS, Feishu, etc.) and other components, which can ensure the stable operation of the system, timely discover and solve problems, and improve operation and maintenance efficiency.

[0065] A business request refers to an operation (such as query, order, payment, etc.) or data processing requirement initiated by a client (such as a user browser, app, or third-party system) to a distributed system to complete a specific business. It typically includes the request initiator (including user identity, client information, authentication information, etc.), the request target (the resource or service the request points to, such as the URL, query parameters, etc.), the request data (the data carried in the request, used to transmit information to the server), and the request operation type.

[0066] A load balancing policy refers to the key mechanism that determines how to distribute client requests to backend servers. It can be selected from round-robin, least connections, weighted round-robin, weighted least connections, IP hash, URL hash, random, and source address hash, or a combination of these policies. For example, a combination of weighted round-robin and least connections, or a combination of IP hash and round-robin.

[0067] In the specific implementation, when the access layer receives a service request from the client, it first determines the resource type of the service request (that is, whether it is a dynamic request); when it is determined to be a dynamic request, the CDN of the access layer forwards the service request to the CLB (CLB can achieve load balancing for dynamic requests, ensure load balancing of back-end servers, and avoid overload of a single server), and then the CLB distributes the service request to the back-end Nginx server cluster according to the configured load balancing strategy, and then Nginx can act as a reverse proxy server to forward the service request to the gateway layer cluster.

[0068] It should be noted that when the service request is determined to be a request for static resources (such as images, CSS files, JavaScript files, etc.), if the requested static resources are in the CDN cache, the CDN can directly return the resources from the nearest edge node without forwarding the service request to the backend server, thereby reducing latency and improving user experience. If the static resources are not in the cache, the CDN will obtain the static resources from the backend server, cache them in the edge node, and then return them to the user; by caching static resources, the CDN can reduce requests to the backend server, thereby improving the overall performance of the system and reducing the load on the backend server.

[0069] In step S20, the gateway layer obtains a list of available instances of the target microservice in the business layer from the registration / configuration center according to the business request, and routes the business request to the target microservice instance in the available instance list based on preset dynamic routing rules.

[0070] The target microservice may refer to the specific microservice required to be called in the business request.

[0071] The available instance list refers to the set of microservice instances that are currently running and available to provide services. It typically includes information such as the address of each instance (such as the IP address and port number). When a microservice instance shuts down normally, the registration / configuration center removes it from the available instance list. When the failed instance recovers, the registration / configuration center adds it back to the available instance list.

[0072] Dynamic routing rules refer to a mechanism that dynamically forwards business requests to different microservice instances based on the characteristics of the business requests (such as the source, parameters, type, etc. of the request), thereby achieving functions such as load balancing and failover. It can achieve flexible traffic distribution based on multiple dimensions such as path, header / parameter, weight, service status (based on the status of the target microservice instance, such as health status, load status, etc.), and grayscale release.

[0073] At the same time, the dynamic routing rules at the gateway layer can be combined with Sentinel (a flow control component of distributed systems that can limit flow to prevent the system from crashing due to excessive flow; for example, by configuring Sentinel rules, the QPS of a single port can be limited to 1000, and when the flow exceeds the limit, the degradation processing mechanism is triggered) to achieve efficient flow control and circuit breaker degradation; that is, through the combination of Spring Cloud Gateway and Sentinel: Spring Cloud Gateway, as the gateway layer, is mainly responsible for the configuration of dynamic routing rules and request forwarding; and Sentinel, based on the gateway layer, can set specific flow control rules for each type of traffic; thus, through the synergy of the flow control mechanism of the gateway layer and Sentinel, the system can effectively cope with high concurrency scenarios and reduce the failure rate by 30%.

[0074] For example, if Sentinel detects a high error rate for a microservice instance, it can reduce the instance's routing weight based on dynamic routing rules, routing more requests to other healthy instances. Dynamic routing also provides feedback to Sentinel on the instance's status after routing, helping Sentinel set more accurate flow control and circuit breaker degradation rules.

[0075] The target microservice instance can refer to selecting the most suitable instance from the list of available instances to process the business request.

[0076] In the specific implementation, when the gateway layer receives a business request, it can parse the business request to obtain the service name (such as URL path resolution, request header resolution or custom logic, etc.), and then determine the target microservice of the business layer based on the service name; then it can send a query request to the registration / configuration center to request a list of available instances of the target microservice; then after the registration / configuration center returns the list of available instances of the target microservice, it can select an instance from the available instance list as the target microservice instance to process the business request according to the preset dynamic routing rules, and finally route the business request to the target microservice instance.

[0077] Step S30: The target microservice instance calls the corresponding business logic to process the business request, generates a business processing result for the business request, encapsulates the business processing result and returns it.

[0078] Among them, the business processing result can refer to the final output generated by the target microservice instance after executing internal business logic (such as data processing (calculation, conversion or verification), database operations (querying, inserting, updating or deleting data in the database), calling other external services, etc.), which usually includes data results, status information, error information, metadata and additional information, etc.; the form and content of the business processing result depends on the specific business scenario and request purpose.

[0079] In the specific implementation, after receiving the business request, the target microservice instance executes the corresponding internal business logic (such as data processing, database operations, calling other external services, etc.) according to the content of the business request, and generates the corresponding business processing results after completing the internal business logic execution; then, the support provided by the middleware (such as Spring Boot), tool class or framework can be used to encapsulate the business processing results into a predefined unified data format (such as JSON object, which contains status code, message and data fields, XML, etc.), and then return the encapsulated business processing results (which may include status code, message, data and error information, etc.) to the client through the network, so that the client can perform corresponding processing based on the returned business processing results.

[0080] Furthermore, in one embodiment, before step S10, the method may further include the following step S40:

[0081] Step S40: When each microservice in the business layer is started, the registration / configuration center receives and stores registration information of each microservice; wherein the registration information includes the service name, instance ID, IP address, metadata, and status mark of each microservice.

[0082] The registration information may include but is not limited to: the service name, instance ID (must be unique), IP address, port number, metadata (such as version number, environment, weight, etc.) and status mark (dynamically updated by health check) of each microservice in the business layer.

[0083] In the specific implementation, when each microservice in the business layer is started, it automatically registers its own information (such as instance IP / port, service name, metadata, etc.) with the registration / configuration center through the client SDK or server-side agent, and then the registration / configuration center receives, stores and maintains the registration information of each microservice; among them, the registration information includes the service name, instance ID, IP address, metadata and status mark of each microservice; thus, each microservice in the business layer can complete registration at startup to realize service discovery and communication, and provide basic data support for subsequent load balancing, circuit breaking and degradation, grayscale release, etc.

[0084] Furthermore, in one embodiment, after step S40, the method may further include step S50:

[0085] In step S50, the registration / configuration center periodically checks the health status of each microservice instance in the registration information through heartbeat detection, and generates a list of available instances of each microservice based on the registration information and the health status.

[0086] Among them, the health status can refer to the evaluation result of the registration / configuration center on the current operating status of the microservice instance, which is used to determine whether the instance can process business requests normally; it can include: UP (healthy / available), DOWN (unhealthy / unavailable), OUT_OF_SERVICE (under maintenance, means offline), UNKNOWN (unknown status).

[0087] In the specific implementation, after each microservice in the business layer completes service registration, each microservice instance can regularly send heartbeat requests to the registration / configuration center (such as sending a heartbeat every 30 seconds to indicate that it is in normal operation and avoid routing the request to an invalid instance) to maintain the registration status. If the registration / configuration center does not receive the request within a timeout, it will be marked as invalid (or if the heartbeat is not received for 3 or more consecutive times, the instance will be marked as unhealthy or offline) and the instance will be removed from the registration / configuration center; or the registration / configuration center will regularly send health check requests to the instances of each microservice and judge the health status of each instance based on the response; then the registration / configuration center can register information and health status, dynamically maintain a list of available instances of each microservice, provide support for service discovery, load balancing, failover, monitoring and alarming, etc., and jointly ensure the high availability and scalability of the system.

[0088] It's important to note that the gateway-layer load balancer can be integrated with the heartbeat detection mechanism. Based on the heartbeat detection results, the load balancer can dynamically adjust traffic distribution to ensure that traffic is routed to healthy microservice instances. For example, if a microservice instance's heartbeat is abnormal, the load balancer can automatically remove traffic from that instance, preventing service requests from being sent to the unavailable instance. Furthermore, when the instance returns to normal, the load balancer can re-add it to the traffic distribution.

[0089] Furthermore, in one embodiment, after step S30, the method may further include step S60:

[0090] In step S60 , the monitoring layer records the processing process and results of the business request, generates log information of the business request, and visually displays the log information.

[0091] Among them, log information may include request information (such as IP address, request path and parameters, etc.), processing process (recording key steps, time consumption, resource usage, etc. in the business processing process) and final business processing results (including success or failure, returned status code and data, response timestamp, etc.).

[0092] In the specific implementation, after the target microservice instance calls the corresponding business logic to process the business request, the monitoring layer can record the information related to the business request (such as request information, processing process, and processing results) into the log storage system, such as using the ELK stack to store and analyze log information, and generate corresponding log information, and use visualization tools (such as Grafana cluster) for visual display (such as creating a flowchart of business request processing, showing the processing process of each level and the resources used and time consumed for each step) to monitor and analyze the system operation status, and quickly discover problems, performance and abnormalities in the system and business processes.

[0093] In this embodiment, by combining modular layering and a distributed system architecture of a base, problems such as high coupling, chaotic configuration, inefficient request distribution, and low development efficiency in distributed systems can be effectively solved, thereby achieving efficient support for multi-terminal collaboration, complex business, and high-concurrency scenarios.

[0094] Based on the above embodiments, a second embodiment of the distributed system service processing method of the present invention is proposed. In this embodiment, step S20 may include the following sub-steps S21 to S23:

[0095] In sub-step S21 , after receiving the service request, the gateway layer parses the service request to extract the authentication token, and verifies the validity and timeliness of the authentication token.

[0096] The authentication token may refer to a data credential used to verify the identity of the client, such as JWT (JSON Web Token) or OAuth 2.0 Token.

[0097] Verifying authentication tokens at the gateway layer can intercept unauthorized business requests in advance, preventing illegal requests from reaching backend services, thereby improving system security. If the authentication token is found invalid at the gateway layer, an error response can be directly returned to avoid forwarding the request to the backend service, reducing unnecessary backend processing and improving overall system performance.

[0098] In the specific implementation, after receiving the business request, the gateway layer can parse the business request to extract the authentication token from the business request; then determine whether the authentication token is valid by verifying the signature, expiration time, and user information of the authentication token (that is, verifying whether it matches the user information in the system, etc.); if the verification is successful, the business request can be forwarded to the corresponding back-end service; if the verification fails, the corresponding error response is returned to the client (such as an unauthorized status code), informing the client that the authentication failed and refusing to process the business request.

[0099] Sub-step S22: When it is determined that the authentication token is valid and not expired, parse the service request to obtain metadata; wherein the metadata includes a service name and a request path.

[0100] The metadata includes the service name and request path.

[0101] In a specific implementation, when it is determined that the authentication token is valid and not expired, the business request is parsed to obtain metadata of the business request so as to perform further processing (such as routing, authorization, logging, etc.) based on the metadata; wherein the metadata includes the service name and the request path.

[0102] Sub-step S23: determining the target microservice corresponding to the business layer according to the service name, and obtaining a list of available instances of the target microservice from a registration / configuration center according to the request path.

[0103] In the specific implementation, after obtaining the metadata, the corresponding target microservice of the business layer can be determined according to the service name; then, according to the request path, a request is made to the registration / configuration center to obtain a list of available instances of the target microservice, so that the business request can be routed to the correct target microservice instance in the available instance list.

[0104] Furthermore, in one embodiment, after sub-step S23, the following sub-steps S24 to S25 may be included:

[0105] Sub-step S24: obtaining the health status of each microservice instance in the available instance list from the registration / configuration center in real time, and obtaining the running status of each microservice instance from the monitoring layer in real time;

[0106] Sub-step S25: Determine whether to perform circuit breaking, degradation, or current limiting processing based on the health status and the operating status of each microservice instance.

[0107] Among them, the running status can refer to the real-time running status of each microservice instance (such as running, stopped, starting, stopping, and faulty), which is used to reflect whether the service is working normally, resource usage, and the ability to provide services to the outside world; it can include resource usage (such as CPU usage, memory usage, network bandwidth usage, etc.), performance indicators (such as response time, throughput, error rate, concurrency, etc.), runtime information (such as instance ID, service name, version number, start time, running time, etc.), dependency status (such as normal dependency, dependency failure, circuit breaker status), configuration status (such as configuration file status, environment variable status, dynamic configuration status, etc.), security status (such as authentication status, authorization status, security vulnerabilities, etc.) and custom status (such as business request success rate and failure rate).

[0108] Circuit breaker rules can include various types, such as threshold-based rules (such as response time, request volume, and error rate), time window rules (such as when the average response time of a service exceeds a preset threshold within a specific time window, a circuit breaker is triggered), and dependency rules (based on the dependency between services to trigger a circuit breaker). Through the above-mentioned various types of circuit breaker rules, circuit breaker operations can be triggered in a timely manner when a service or interface fails, ensuring the stability and reliability of the system.

[0109] As an example, when it is detected that the error rate of a microservice instance in the available instance list exceeds a preset threshold (such as 20%) within a certain time window, the circuit breaker mechanism can be triggered, that is, sending requests to the microservice instance is suspended.

[0110] Degradation rules can include various types based on thresholds (such as CPU usage, memory usage, etc.), error rates, circuit breakers, priorities, etc. to ensure that a reasonable response can still be returned when the service is unavailable.

[0111] Current limiting rules can implement effective current limiting logic based on the token mechanism, thereby effectively controlling the processing efficiency of requests; such as the token bucket algorithm (if the tokens in the bucket are consumed, subsequent requests will not be processed temporarily, and will be allocated and processed after the next round of token replenishment) and the leaky bucket algorithm; they can effectively control the processing efficiency of requests and ensure that the system will not be overloaded due to sudden traffic.

[0112] By configuring these (circuit breaking, degradation, and current limiting) rules, you can effectively protect the system from crashing in situations such as high concurrency and unavailable dependent services, thereby improving the system's availability and stability.

[0113] In the specific implementation, before routing the business request to the target microservice instance in the available instance list according to the preset dynamic routing rules, the gateway layer can also obtain the health status of each microservice instance in the available instance list from the registration / configuration center in real time (such as through the heartbeat monitoring mechanism), and can also obtain the running status of each microservice instance in real time from the monitoring layer; and then, combined with the health status and running status of each microservice instance in the available instance list, determine whether circuit breaking, degradation or current limiting processing is required, so as to accurately trigger the fault tolerance mechanism and improve the stability and availability of the system.

[0114] In this embodiment, after receiving the business request, the gateway layer uses a unified authentication and service discovery mechanism to ensure that only authorized users can access the target microservice and obtain the latest list of available instances of the target microservice, thereby achieving correct routing and load balancing.

[0115] Based on the above embodiments, a third embodiment of the distributed system service processing method of the present invention is proposed. In this embodiment, step S30 may include the following sub-steps S31 to S32:

[0116] Sub-step S31: After the target microservice instance receives the business request, it verifies the authentication token and authority in the business request based on the OAuth2.0 protocol.

[0117] In the specific implementation, after the target microservice instance in the business layer receives the business request, it can extract authentication information (such as JWT) from the business request, and then verify the authentication token and permissions in the business request according to the preset OAuth2.0 protocol and Spring Cloud Security, ensuring that only authorized users can access specific resources of the target microservice; if the authentication token is invalid or expired, or the user does not have permission to access specific resources, an error response can be returned.

[0118] Sub-step S32, after the authentication token and permission verification are passed, parse the business request to obtain request information, and call the corresponding business logic to process the business request according to the request information, and generate a business processing result of the business request; wherein the request information includes the request type and request parameters.

[0119] The request information may include request type and request parameters.

[0120] In specific implementations, after the authentication token and permissions are verified, the target microservice instance can parse the business request to obtain request information (including request type and request parameters). It can then call the corresponding business logic based on the request information to process the business request (such as querying, creating, updating, or deleting data) and generate a business processing result. The target microservice instance can then provide business functions, effectively meet the client's business needs, and ensure the security and reliability of the system.

[0121] In this embodiment, after the authentication token and permission verification are passed, the target microservice instance can parse the business request to obtain request information (including request type and request parameters). Based on the request information, the target microservice instance can then call the corresponding business logic to process the business request (such as querying, creating, updating, or deleting data) and generate a business processing result. This allows the target microservice instance to provide business functions, effectively meeting the client's business needs while ensuring system security and reliability.

[0122] Based on the same inventive concept, the fourth embodiment of the present invention also provides a distributed system business processing device corresponding to the distributed system business processing method of the aforementioned embodiment. Since the principle of solving the problem of the device in the fourth embodiment of the present invention is similar to the distributed system business processing method of the aforementioned embodiment of the present invention, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be repeated. Figure 3 The distributed system service processing device of the present invention is applied to a distributed system, wherein the distributed system includes a registration / configuration center, an access layer, a gateway layer, and a service layer. The device may include:

[0123] The receiving module 10 is configured to distribute the service request from the client to the gateway layer through the reverse proxy based on a preset load balancing strategy when the access layer receives the service request from the client;

[0124] The routing module 20 is used for the gateway layer to obtain a list of available instances of the target microservice in the business layer from the registration / configuration center according to the business request, and to route the business request to the target microservice instance in the list of available instances based on preset dynamic routing rules;

[0125] The processing module 30 is used for the target microservice instance to call the corresponding business logic to process the business request, generate a business processing result for the business request, encapsulate the business processing result and return it.

[0126] In addition, the present invention also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the above-mentioned distributed system business processing method is implemented.

[0127] Figure 4Schematic block diagram of an electronic device provided in an embodiment of the present application. Figure 4 As shown, the electronic device includes: at least one processor 401, a memory 402, at least one network interface 403 and a user interface 405. The various components in the electronic device are coupled together via a bus system 404. It is understood that the bus system 404 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 404 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 4 In the text, various buses are labeled as bus systems.

[0128] The user interface 405 may include a display, a keyboard, a mouse, a trackball, a click gun, keys, buttons, a touch pad or a touch screen.

[0129] It will be appreciated that the memory 402 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM) or a programmable read-only memory (PROM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of the present invention are intended to include, but are not limited to, these and any other suitable types of memories.

[0130] The memory 402 in the embodiment of the present invention is used to store various categories of data to support the operation of the electronic device 400. Examples of these data include: any executable program for operating on the electronic device 400, such as an operating system 4021 and an application 4022; the operating system 4021 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks. The application 4022 can include various applications, such as a media player (Media Player), a browser (Browser), etc., for implementing various application services. The distributed system business processing method provided by the embodiment of the present invention can be included in the application 4022.

[0131] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in processor 401 or by software instructions. The above processor 401 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc. Processor 401 can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 401 may be a microprocessor or any conventional processor. The steps of the distributed system service processing method provided in the embodiments of the present invention can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium located in a memory. The processor reads information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0132] In an exemplary embodiment, the electronic device 400 may be configured to execute the aforementioned method by one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs).

[0133] In summary, the present invention can effectively solve problems such as high coupling, chaotic configuration, inefficient request distribution and low development efficiency in distributed systems by combining modular layering and a distributed system architecture of a base, and achieve efficient support for multi-terminal collaboration, complex business and high concurrency scenarios.

[0134] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the present invention. Anyone skilled in the art may modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by one of ordinary skill in the art without departing from the spirit and technical principles disclosed herein are intended to be covered by the claims of the present invention.

Claims

1. A distributed system service processing method, characterized in that: Applied to a distributed system, the distributed system includes a registration / configuration center, an access layer, a gateway layer, and a service layer, the method includes: When the access layer receives a service request from the client, it distributes the service request to the gateway layer through the reverse proxy based on the preset load balancing strategy; The gateway layer obtains a list of available instances of the target microservice in the business layer from the registration / configuration center according to the business request, and routes the business request to the target microservice instance in the list of available instances based on preset dynamic routing rules; The target microservice instance calls the corresponding business logic to process the business request, generates a business processing result for the business request, encapsulates the business processing result and returns it.

2. The method according to claim 1, characterized in that Before the step of distributing the service request to the gateway layer through the reverse proxy when the access layer receives the service request from the client, the method further includes: When each microservice in the business layer is started, the registration / configuration center receives and stores the registration information of each microservice; wherein the registration information includes the service name, instance ID, IP address, metadata and status mark of each microservice.

3. The method according to claim 2, characterized in that After the registration / configuration center receives and stores the registration information of each microservice when each microservice in the business layer is started, the process further includes: The registration / configuration center regularly checks the health status of each microservice instance in the registration information through heartbeat detection, and generates a list of available instances of each microservice based on the registration information and the health status.

4. The method according to claim 1, wherein The gateway layer obtains a list of available instances of the target microservice in the business layer from the registration / configuration center according to the business request, including: After receiving the service request, the gateway layer parses the service request to extract the authentication token and verifies the validity and timeliness of the authentication token; When it is determined that the authentication token is valid and not expired, parsing the service request to obtain metadata; wherein the metadata includes a service name and a request path; According to the service name, the corresponding target microservice of the business layer is determined, and a list of available instances of the target microservice is obtained from the registration / configuration center according to the request path.

5. The method according to claim 1 or 4, characterized in that The distributed system further includes a monitoring layer, and before the step of routing the service request to the target microservice instance in the available instance list based on a preset dynamic routing rule, the system further includes: Obtain the health status of each microservice instance in the available instance list from the registration / configuration center in real time, and obtain the running status of each microservice instance from the monitoring layer in real time; Determine whether to perform circuit breaking, degradation, or current limiting based on the health status and operating status of each microservice instance.

6. The method according to claim 1, characterized in that The target microservice instance calls the corresponding business logic to process the business request and generates a business processing result for the business request, including: After the target microservice instance receives the business request, it verifies the authentication token and authority in the business request based on the OAuth2.0 protocol; After the authentication token and permission verification are passed, the business request is parsed to obtain request information, and the corresponding business logic is called according to the request information to process the business request and generate a business processing result for the business request; wherein the request information includes the request type and request parameters.

7. The method according to claim 1, characterized in that The distributed system further includes a monitoring layer. After the target microservice instance calls corresponding business logic to process the business request and generates a business processing result for the business request, the system further includes: The monitoring layer records the processing process and results of the business request, generates log information of the business request, and visually displays the log information.

8. A distributed system service processing device, characterized in that: Applied to a distributed system, the distributed system includes a registration / configuration center, an access layer, a gateway layer, and a service layer, and the device includes: The receiving module is used to distribute the service request from the client to the gateway layer through the reverse proxy based on the preset load balancing strategy when the access layer receives the service request from the client; A routing module is used for the gateway layer to obtain a list of available instances of the target microservice in the business layer from the registration / configuration center according to the business request, and to route the business request to the target microservice instance in the available instance list based on preset dynamic routing rules; The processing module is used for the target microservice instance to call the corresponding business logic to process the business request, generate the business processing result of the business request, encapsulate the business processing result and return it.

9. An electronic device, characterized in that: The electronic device includes: a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the processor performs the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a program, which, when run, is used to implement the steps of the method according to any one of claims 1 to 7.

Images