A microservice architecture for multi-regional enterprise service data

Abstract

The present invention proposes a microservice architecture for multi-regional enterprise service data, including: an Nginx load balancing cluster distributes requests to a front-end server cluster, achieving balanced distribution of requests through the Nginx load balancing cluster; a Zuul gateway cluster performs preliminary security verification and protocol conversion on requests; a Eureka registration center cluster registers services with a microservice application service cluster and receives service discovery feedback from the microservice application service cluster; obtains a service list from the microservice application service cluster; an Admin monitoring center cluster monitors the operating status, resource usage, and request processing progress of each cluster in real time; issues an alarm and takes corresponding adjustment measures when an anomaly is detected; and a database cluster provides data support according to instructions from the microservice application service cluster. The present invention distributes user requests to different servers through load balancing technology to improve the overall processing capacity and availability of the system.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a microservice architecture for multi-regional enterprise service data. Background Technology

[0002] To better assist private market entities in overcoming difficulties and protect the legitimate rights and interests of private enterprises, it is necessary to optimize the comprehensive service platform for private enterprises. In particular, the following problems exist in multi-level enterprise service platforms involving autonomous regions, leagues, cities, banners, and counties:

[0003] (1) The existing league-level and banner-level platforms are independent, each with its own set of standards. The interfaces, functions, interfaces and management of each platform lack uniformity, which makes it impossible for different platforms to interconnect.

[0004] (2) The platform data transmission is insecure and lacks encryption.

[0005] (3) The system has security vulnerabilities, is prone to security incidents, and cannot be quickly recovered after being damaged by external malicious attacks, resulting in damage to system platform resources and leakage of user information. Summary of the Invention

[0006] The purpose of this invention is to at least address one of the aforementioned technical deficiencies.

[0007] Therefore, one objective of this invention is to propose a microservice architecture for multi-regional enterprise service data, in order to solve the problems mentioned in the background art and overcome the shortcomings of the prior art.

[0008] To achieve the above objectives, embodiments of the present invention provide a microservice architecture for multi-regional enterprise service data, comprising: an Nginx load balancing cluster, a front-end server cluster, a TCP server, a Zuul gateway cluster, a microservice application service cluster, a Eureka registry cluster, an Admin monitoring center cluster, and a database cluster, wherein...

[0009] When an enterprise user initiates a service request via the HTTP protocol from the front end, the service request is first transmitted over the network through the TCP / IP protocol stack before reaching the Nginx load balancing cluster.

[0010] The Nginx load balancing cluster receives service requests through the Nginx reverse proxy server, which then distributes the requests to the front-end server cluster, achieving balanced distribution of requests through the Nginx load balancing cluster.

[0011] The TCP server receives requests from CEMS devices and high-definition monitoring IPC / NVR devices via the TCP protocol, and forwards the requests to the Nginx load balancing cluster.

[0012] The Zuul gateway cluster is used to receive requests from the front-end server cluster and TCP server sent by the Nginx load balancing cluster; to perform preliminary security verification and protocol conversion on the requests; and after confirming the legality and standardization of the requests, to send the requests to the microservice application service cluster.

[0013] The Eureka registry cluster registers services with the microservice application service cluster, receives service discovery feedback from the microservice application service cluster, and then pulls the service list from the Zuul gateway cluster.

[0014] The microservice application service cluster, under the guidance of the Eureka registry cluster, obtains the service list and determines the service to be invoked.

[0015] The Admin monitoring center cluster is used to monitor the running status, resource usage, and request processing progress of each cluster in real time; when an anomaly is detected, an alarm is issued and corresponding adjustment measures are taken.

[0016] The database cluster is used to provide data support according to the instructions of the microservice application service cluster. When a user requests to view user group information, the database cluster retrieves and returns relevant user data. After collaborative processing by various clusters, the required service results are finally returned to the front end and presented to the enterprise user.

[0017] Preferably, in any of the above solutions, the enterprise user issues a service request through the front end, including: the enterprise user issues a service request through an official account, mini program, mobile terminal or management platform.

[0018] Preferably, in any of the above schemes, the Nginx load balancing cluster sends static files from users to the CDN cache.

[0019] Preferably, in any of the above schemes, the Eureka registry cluster records the location and status information of each microservice in the microservice application service cluster.

[0020] Preferably, in any of the above schemes, Ribbon client load balancing and Hystix service circuit breaking are implemented between the microservice application service cluster and the Zuul gateway cluster; the microservice application service cluster pushes / pulls configuration information to the Config configuration center cluster.

[0021] Preferably, in any of the above schemes, the Admin monitoring center cluster registers services with the microservice application service cluster and receives service monitoring information from the microservice application service cluster.

[0022] Preferably, in any of the above schemes, the microservice application service cluster reads information from the OSS object storage cluster; the RabbitMQ message queue cluster sends messages to the microservice application service cluster; and the third-party messages are sent to the microservice application service cluster via the HTTP protocol.

[0023] Preferably, in any of the above schemes, the database cluster includes: a Redis cache database cluster, a MySQL relational database cluster, and an Elasticsearch / MongoDB document-oriented data zone cluster, and the microservice application service cluster transmits data with the Redis cache database cluster, the MySQL relational database cluster, and the Elasticsearch / MongoDB document-oriented data zone cluster.

[0024] Preferably, in any of the above schemes, the microservice application service cluster transmits data with the Redis cache database cluster and the Elasticsearch / MongoDB document-oriented data area cluster in a low-frequency write and high-frequency read manner;

[0025] The microservice application service cluster transmits data to the MySQL relational database cluster in a high-frequency write and low-frequency read manner.

[0026] Preferably, the database cluster cache invalidation strategy and cache update mechanism described above ensure that the data in the Redis cache database cluster is consistent with the data in the MySQL relational database cluster.

[0027] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows:

[0028] 1. Implement server-side load balancing using an Nginx cluster. Load balancing technology distributes user requests to different servers to improve the overall processing capacity and availability of the system. This handles the concurrent request pressure on application services, achieving the goal of high concurrency.

[0029] 2. The database design employs methods such as database sharding, read-write separation, hot and cold data isolation, and data redundancy to distribute the database storage pressure, improve database response speed, and achieve the goal of strong real-time performance.

[0030] 3. The database and cache use MySQL and Redis, a cache-based NoSQL database, to alleviate database performance pressure and improve database query speed.

[0031] 4. The system employs a large number of middleware, such as message queue middleware like Rabbi, to distribute instantaneous database requests and alleviate the processing pressure on the database under high concurrency.

[0032] 5. For static files (such as images, CSS, JS, etc.), configure a Content Delivery Network (CDN) to accelerate file distribution and reduce server load.

[0033] 6. Cached databases reduce the number of database accesses, thereby alleviating the pressure on these databases.

[0034] 7. Implement cache invalidation strategies (such as LRU, LFU, etc.) and cache update mechanisms (such as post-write update, subscription update, etc.) to ensure that the data in the cache is consistent with the data in the main database.

[0035] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0036] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments with reference to the accompanying drawings, in which:

[0037] Figure 1 This is a structural diagram of a microservice architecture for multi-regional enterprise service data according to an embodiment of the present invention;

[0038] Figure 2 This is a schematic diagram of a microservice architecture for multi-regional enterprise service data according to an embodiment of the present invention. Detailed Implementation

[0039] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0040] like Figure 1 and Figure 2 As shown, the microservice architecture for multi-regional enterprise service data in this embodiment of the invention includes: an Nginx load balancing cluster 1, a front-end server cluster 2, a TCP server 2, a Zuul gateway cluster 3, a microservice application service cluster 4, a Eureka registry cluster 5, an Admin monitoring center cluster 6, and a database cluster 7.

[0041] Specifically, when an enterprise user initiates a service request via the HTTP protocol through the front end, the service request is first transmitted over the network through the TCP / IP protocol stack before reaching the Nginx load balancing cluster 1.

[0042] In embodiments of the present invention, enterprise users send service requests through the front end, including: enterprise users sending service requests through official accounts, mini programs, mobile terminals or management platforms.

[0043] Nginx load balancing cluster 1 receives service requests through the Nginx reverse proxy server. The Nginx reverse proxy server distributes the requests to the front-end server cluster 2, thus achieving balanced distribution of requests through Nginx load balancing cluster 1.

[0044] Specifically, when an enterprise user sends a service request via HTTP from the front end, the request is first transmitted over the network through the TCP / IP protocol stack. Upon arrival at the system, the user's HTTP request is first received by the Nginx reverse proxy server. Nginx is responsible for distributing the request to a node in Server Cluster 2. The Nginx load balancing cluster 1 then balances the request distribution, acting like an intelligent traffic controller, quickly allocating and scheduling requests. Based on the load of each node, the Nginx load balancing cluster 1 appropriately distributes the requests to the gateway cluster.

[0045] Nginx load balancing cluster 1 sends static files from users to the CDN cache.

[0046] Specifically, for static files (such as images, CSS, JS, etc.), a Content Delivery Network (CDN) is configured to accelerate file distribution and reduce server load.

[0047] TCP server 2 receives requests sent via TCP protocol from CEMS devices and HD monitoring IPC / NVR devices, and forwards the requests to Nginx load balancing cluster 1.

[0048] The gateway cluster acts as the first line of defense, performing initial security verification and protocol conversion on requests. After confirming the legitimacy and compliance of the request, it forwards it to the microservice application service cluster 4.

[0049] Specifically, Zuul gateway cluster 3 is used to receive requests from front-end server cluster 2 and TCP server 2 sent by Nginx load balancer cluster 1; it performs preliminary security verification and protocol conversion on the requests, and after confirming the legality and standardization of the requests, it sends the requests to microservice application service cluster 4.

[0050] Eureka registry cluster 5 records the location and status information of each microservice in microservice application service cluster 4. Eureka registry cluster 5 registers services with microservice application service cluster 4, receives service discovery feedback from microservice application service cluster 4, and then pulls the service list from Zuul gateway cluster 3.

[0051] Under the guidance of Eureka registry cluster 5, the microservice application service cluster 4 obtains the service list and determines the service to be invoked.

[0052] Specifically, the various service components in microservice application service cluster 4 collaborate closely. Eureka registry cluster 5 plays a crucial role. Eureka registry cluster 5 acts as a precise directory, recording the location and status information of each microservice in microservice application service cluster 4. Guided by Eureka registry cluster 5, microservice application service cluster 4 can quickly obtain the service list and identify the specific service to be invoked.

[0053] In addition, Ribbon client load balancing and Hystix service circuit breaking are implemented between microservice application service cluster 4 and Zuul gateway cluster 3; microservice application service cluster 4 pushes / pulls configuration information to the Config configuration center cluster.

[0054] Microservice application service cluster 4 reads information from the OSS object storage cluster; RabbitMQ message queue cluster sends messages to microservice application service cluster 4; and third-party messages are sent to microservice application service cluster 4 via HTTP protocol.

[0055] The Admin monitoring center cluster 6 remains vigilant throughout, monitoring the operational status, resource usage, and request processing progress of each cluster in real time; when an anomaly is detected, it issues an alert and takes corresponding adjustment measures.

[0056] The Admin monitoring center cluster 6 registers services with the microservice application service cluster 4 and receives service monitoring information from the microservice application service cluster 4.

[0057] Database cluster 7 provides data support based on instructions from microservice application service cluster 4. When a user requests to view user group information, database cluster 7 retrieves and returns relevant user data. After collaborative processing by various clusters, the required service results are finally returned to the front end and presented to the enterprise user.

[0058] Specifically, database cluster 7 provides accurate and complete data support based on instructions from microservice application service cluster 4. For example, when a user requests to view user group information, database cluster 7 quickly retrieves and returns the relevant user data. Through collaborative processing by various clusters, the required service results are ultimately returned accurately to the front end and presented to the enterprise user.

[0059] In an embodiment of the present invention, the database cluster 7 includes: a Redis cache database cluster 7, a MySQL relational database cluster 7, and an Elasticsearch / MongoDB document-oriented data area cluster. The microservice application service cluster 4 transmits data with the Redis cache database cluster 7, the MySQL relational database cluster 7, and the Elasticsearch / MongoDB document-oriented data area cluster.

[0060] Microservice application service cluster 4 transmits data with Redis cache database cluster 7 and Elasticsearch / MongoDB document-oriented database cluster using a low-frequency write, high-frequency read approach. Microservice application service cluster 4 also transmits data with MySQL relational database cluster 7 using a high-frequency write, low-frequency read approach.

[0061] In addition, the database cluster 7 has a cache invalidation policy and a cache update mechanism to ensure that the data in the Redis cache database cluster 7 is consistent with the data in the MySQL relational database cluster 7.

[0062] In this embodiment of the invention, database cluster 7 is configured with a master database and slave databases. The master database is the primary storage point for data in the system and is responsible for handling all data write operations. These operations include new data submitted by users and updates to existing data. The master database ensures data consistency and integrity through transaction management. All modifications to data are first executed on the master database and then synchronized to other slave databases through a replication mechanism. Although the master database is responsible for handling all write operations, the system typically configures multiple master database instances (through database clustering or distributed database technology) to improve availability and fault tolerance. When a master database instance fails, other instances can take over its work.

[0063] The slave database is primarily used to handle data read operations, reducing the load on the master database. Through read / write separation, the system can distribute a large number of read requests to the slave database, thereby improving overall system performance and response speed. The slave database is also an important source of data backup. By periodically synchronizing data from the master database, the slave database ensures data recovery in the event of a system failure.

[0064] Cached databases are used to store frequently accessed data in a system, such as user session information and policy information. By storing this data in memory, cached databases can significantly improve data retrieval speed. Cached databases reduce the number of accesses to the primary and secondary databases, thereby alleviating the pressure on these databases.

[0065] When a system receives a read request, a cached database first checks if the required data exists in the cache. If it does, the data is read directly from the cache without accessing the primary or secondary database. While cached databases provide fast data access, they also introduce data consistency issues. Therefore, the system needs to implement cache invalidation policies (such as LRU, LFU, etc.) and cache update mechanisms (such as post-write updates, subscription updates, etc.) to ensure that the data in the cache is consistent with the data in the primary database.

[0066] Throughout the process, the various clusters cooperated closely and worked together efficiently to ensure that every service request was processed in a timely and accurate manner, providing enterprise users with a high-quality and stable service experience.

[0067] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0068] It will be readily understood by those skilled in the art that this invention includes any combination of the inventive description and specific embodiments outlined in the foregoing specification, as well as the various parts shown in the accompanying drawings. Due to space limitations and for the sake of brevity, not all of these combinations have been described in detail. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

[0069] Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention without departing from the principles and spirit of the invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A microservice architecture for serving data in multi-regional enterprises, characterized in that, include: The system consists of an Nginx load balancer cluster, a front-end server cluster, a TCP server cluster, a Zuul gateway cluster, a microservice application service cluster, a Eureka registry cluster, an Admin monitoring center cluster, and a database cluster. When an enterprise user initiates a service request via the HTTP protocol from the front end, the service request is first transmitted over the network through the TCP / IP protocol stack before reaching the Nginx load balancing cluster. The Nginx load balancing cluster receives service requests through the Nginx reverse proxy server, which distributes the requests to the front-end server cluster. The Nginx load balancing cluster then achieves balanced distribution of requests. The Nginx load balancing cluster also sends static files from users to the CDN cache. The TCP server receives requests from CEMS devices and high-definition monitoring IPC / NVR devices via the TCP protocol, and forwards the requests to the Nginx load balancing cluster. The Zuul gateway cluster is used to receive requests from the front-end server cluster and TCP server sent by the Nginx load balancing cluster; to perform preliminary security verification and protocol conversion on the requests; and after confirming the legality and standardization of the requests, to send the requests to the microservice application service cluster. The Eureka registry cluster registers services with the microservice application service cluster, receives service discovery feedback from the microservice application service cluster, and then pulls the service list from the Zuul gateway cluster. The microservice application service cluster, guided by the Eureka registry cluster, obtains a service list and determines the services to be invoked; the microservice application service cluster and the Zuul gateway cluster implement Ribbon client load balancing and Hystix service circuit breaking; the microservice application service cluster pushes / pulls configuration information to the Config configuration center cluster; the microservice application service cluster reads information from the OSS object storage cluster; the RabbitMQ message queue cluster sends messages to the microservice application service cluster; and the three-way messages are sent to the microservice application service cluster via HTTP protocol. The Admin monitoring center cluster is used to monitor the running status, resource usage, and request processing progress of each cluster in real time; when an anomaly is detected, an alarm is issued and corresponding adjustment measures are taken; the database cluster is used to provide data support according to the instructions of the microservice application service cluster; when a user requests to view user group information, the database cluster retrieves and returns relevant user data, and after collaborative processing by each cluster, the required service results are finally returned to the front end and presented to the enterprise user.

2. The microservice architecture for multi-regional enterprise service data as described in claim 1, characterized in that, The enterprise user sends a service request through the front end, including: the enterprise user sends a service request through an official account, mini program, mobile terminal or management platform.

3. The microservice architecture for multi-regional enterprise service data as described in claim 1, characterized in that, The Eureka registry cluster records the location and status information of each microservice in the microservice application service cluster.

4. The microservice architecture for multi-regional enterprise service data as described in claim 1, characterized in that, The Admin monitoring center cluster registers services with the microservice application service cluster and receives service monitoring information from the microservice application service cluster.

5. The microservice architecture for multi-regional enterprise service data as described in claim 1, characterized in that, The database cluster includes a Redis cache database cluster, a MySQL relational database cluster, and an Elasticsearch / MongoDB document-oriented data zone cluster. The microservice application service cluster transmits data with the Redis cache database cluster, the MySQL relational database cluster, and the Elasticsearch / MongoDB document-oriented data zone cluster.

6. The microservice architecture for multi-regional enterprise service data as described in claim 5, characterized in that, The microservice application service cluster transmits data with the Redis cache database cluster and the Elasticsearch / MongoDB document-oriented data area cluster in a low-frequency write and high-frequency read manner; The microservice application service cluster transmits data to the MySQL relational database cluster in a high-frequency write and low-frequency read manner.

7. The microservice architecture for multi-regional enterprise service data as described in claim 1, characterized in that, The database cluster cache invalidation strategy and cache update mechanism are described to ensure that the data in the Redis cache database cluster is consistent with the data in the MySQL relational database cluster.

Images