Micro-service architecture for multi-local-level enterprise service data

Abstract

The invention provides a micro-service architecture for multi-local-level enterprise service data, which comprises the following steps that: an Nginx load balancing cluster distributes requests to a front-end Server cluster, and realizes balanced distribution of the requests through the Nginx load balancing cluster; the Zuul gateway cluster performs preliminary security verification and protocol conversion on the request; the Eureka registration center cluster carries out service registration on the micro-service application service cluster and receives service discovery fed back by the micro-service application service cluster; acquiring a service list from the micro-service application service cluster; the Admin monitoring center cluster monitors the running state, the resource use condition and the request processing progress of each cluster in real time; when abnormity is judged, an alarm is given, and corresponding adjustment measures are taken; and the database cluster provides data support according to an instruction of the micro-service application service cluster. According to the invention, the user requests are distributed to different servers through the load balancing technology, so that the overall processing capability and availability of the system are improved.

Description

Technical Field

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

[0002] In order to better help private market players to solve their 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 the multi-level enterprise service platforms involving autonomous regions, leagues, cities, banners, counties and districts:

[0003] (1) The existing league-level, city-level, banner-level, county-level and district-level platforms are independent of each other, each with its own set of standards. The interfaces, functions, interfaces and management of each platform lack uniformity, resulting in the inability to achieve interconnection between different platforms.

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

[0005] (3) The system has security vulnerabilities, which makes security incidents prone to occur, and the system cannot be quickly restored 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 object of the present invention is to solve at least one of the technical drawbacks.

[0007] To this end, an object of the present invention is to propose a microservice architecture for multi-regional enterprise service data to solve the problems mentioned in the background technology and overcome the deficiencies in the prior art.

[0008] In order to achieve the above-mentioned purpose, an embodiment of the present invention provides a microservice architecture for multi-regional enterprise service data, including: Nginx load balancing cluster, front-end Server cluster, TCP server, Zuul gateway cluster, microservice application service cluster, Eureka registration center cluster, Admin monitoring center cluster and database cluster, wherein:

[0009] When an enterprise user initiates a service request through the front end using the HTTP protocol, the service request is first transmitted over the TCP / IP protocol stack, and then reaches the Nginx load balancing cluster.

[0010] The Nginx load balancing cluster receives service requests through the Nginx reverse proxy server, and the Nginx reverse proxy server distributes the requests to the front-end Server cluster, and realizes 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 by the TCP server;

[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; perform preliminary security verification and protocol conversion on the requests, and after confirming the legitimacy and standardization of the requests, send the requests to the microservice application service cluster;

[0013] The Eureka registration center 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 obtains a service list under the guidance of the Eureka registration center cluster and determines the service to be called;

[0015] The Admin monitoring center cluster is used to monitor the operating status, resource usage and request processing progress of each cluster in real time; when an abnormality is determined, 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, and after collaborative processing by each cluster, the required service results are finally returned to the front end and presented to the enterprise user.

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

[0018] Preferably, any of the above solutions sends the static files from the user to the CDN cache.

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

[0020] Preferably, any of the above solutions implements Ribbon client load balancing and Hystix service fusing between the microservice application service cluster and the Zuul gateway cluster; and the microservice application service cluster pushes / pull configuration information to the Config configuration center cluster.

[0021] Preferably, any of the above solutions is that the Admin monitoring center cluster registers services with the microservice application service cluster and receives service monitoring information fed back by the microservice application service cluster.

[0022] Preferably, any of the above schemes includes: the microservice application service cluster reading information from the OSS object storage cluster; the RabbitMQ message queue cluster sending messages to the microservice application service cluster; and sending the three-party message to the microservice application service cluster via the HTTP protocol.

[0023] Preferably, any of the above schemes comprises: a Redis cache database cluster, a MySQL relational database cluster and an Elasticsearch / MongoDB document data area cluster, and the microservice application service cluster performs data transmission with the Redis cache database cluster, the MySQL relational database cluster and the Elasticsearch / MongoDB document data area cluster.

[0024] Preferably, any of the above solutions transmits data with the Redis cache database cluster and the Elasticsearch / MongoDB document data area cluster in the form of low-frequency writing and high-frequency reading;

[0025] The microservice application service cluster transmits data with the MySQL relational database cluster in the form of high-frequency writing and low-frequency reading.

[0026] Preferably, any of the above solutions uses a cache invalidation strategy and a cache update mechanism for the database cluster to ensure that the data in the Redis cache database cluster remains consistent with the data in the MySQL relational database cluster.

[0027] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0028] 1. Use Nginx cluster to achieve server-side load balancing, and distribute user requests to different servers through load balancing technology to improve the overall processing capacity and availability of the system. Handle the concurrent request pressure of application services to achieve the goal of high concurrency.

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

[0030] 3. The database and cache use MySQL database and cache-type NoSQL databases such as Redis to solve database performance pressure and improve database query speed.

[0031] 4. The system uses a large number of middleware, such as Rabbi and other message queue middleware, to disperse instantaneous database requests and solve the processing pressure of the database under high concurrency.

[0032] 5. For static files (such as pictures, CSS, JS, etc.), configure the content distribution network CDN to speed up file distribution and reduce server load.

[0033] 6. Cache-based databases reduce the number of accesses to databases, thereby alleviating the pressure on these databases.

[0034] 7. Implement cache invalidation strategies (such as LRU, LFU, etc.) and cache update mechanisms (such as write-after-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 present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0038] Figure 2 Schematic diagram of a microservice architecture for multi-regional enterprise service data according to an embodiment of the present invention. DETAILED DESCRIPTION

[0039] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used 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 of an embodiment of the present invention includes: Nginx load balancing cluster 1, front-end Server cluster 2, TCP server 2, Zuul gateway cluster 3, microservice application service cluster 4, Eureka registration center cluster 5, Admin monitoring center cluster 6 and database cluster 7.

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

[0042] In an embodiment of the present invention, an enterprise user issues a service request through a front end, including: an enterprise user issues a service request through a public account, a mini program, a mobile terminal or a management platform.

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

[0044] Specifically, when an enterprise user sends a service request through the front end using the HTTP protocol, the request is first transmitted through the TCP / IP protocol stack. After the user's HTTP request reaches the system, it is first received by the Nginx reverse proxy server. Nginx is responsible for distributing the request to a node in Server cluster 2, and realizing balanced distribution of requests through Nginx load balancing cluster 1. Load balancing cluster 1 is like an intelligent traffic commander, quickly distributing and scheduling requests. Nginx load balancing cluster 1 will reasonably distribute requests to the gateway cluster according to the load conditions of each node.

[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 speed up file distribution and reduce server load.

[0047] TCP server 2 receives requests from CEMS devices and high-definition monitoring IPC / NVR devices through the TCP protocol, and TCP server 2 forwards the requests to Nginx load balancing cluster 1.

[0048] As the first checkpoint, the gateway cluster performs preliminary security verification and protocol conversion on the request. After confirming the legitimacy and standardization of the request, it is passed 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 balancing cluster 1; perform preliminary security verification and protocol conversion on the requests, and after confirming the legitimacy and standardization of the requests, send the requests to microservice application service cluster 4.

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

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

[0052] Specifically, each service component in the microservice application service cluster 4 works closely together. The Eureka registry center cluster 5 plays a key role. The Eureka registry center cluster 5 is like a precise directory, recording the location and status information of each microservice in the microservice application service cluster 4. Under the guidance of the Eureka registry center cluster 5, the microservice application service cluster 4 can quickly obtain the service list and clarify the specific service to be called.

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

[0054] The microservice application service cluster 4 reads the information in the OSS object storage cluster; the RabbitMQ message queue cluster sends a message to the microservice application service cluster 4; and the three-party message is sent to the microservice application service cluster 4 via the HTTP protocol.

[0055] The Admin monitoring center cluster 6 remains vigilant throughout the process, monitoring the operating status, resource usage and request processing progress of each cluster in real time; when an abnormality is determined, an alarm is issued and corresponding adjustment measures are taken.

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

[0057] The database cluster 7 is used to provide data support according to the instructions of the microservice application service cluster 4; when a user requests to view user group information, the database cluster 7 retrieves and returns the 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 users.

[0058] Specifically, the database cluster 7 provides accurate and complete data support according to the instructions of the microservice application service cluster 4. For example, when a user requests to view user group information, the database cluster 7 quickly retrieves and returns the relevant user data, and after the coordinated processing of each cluster, the required service results are finally accurately returned 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 data area cluster, and the microservice application service cluster 4 performs data transmission with the Redis cache database cluster 7, the MySQL relational database cluster 7 and the Elasticsearch / MongoDB document data area cluster.

[0060] The microservice application service cluster 4 transmits data with the Redis cache database cluster 7 and the Elasticsearch / MongoDB document data area cluster in the form of low-frequency writing and high-frequency reading. The microservice application service cluster 4 transmits data with the MySQL relational database cluster 7 in the form of high-frequency writing and low-frequency reading.

[0061] In addition, the database cluster 7 has a cache invalidation strategy 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] The database cluster 7 in the embodiment of the present invention is configured with a master database and a slave database. The master database is the main storage point for data in the system and is responsible for processing all data write operations. These operations include new data submitted by users, updating existing data, etc. The master database ensures data consistency and integrity through transaction management. All modifications to data will first be performed on the master database and synchronized to other slave databases through a replication mechanism. Although the master database is responsible for processing all write operations, the system usually configures multiple master database instances (through database clusters 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 mainly used to process data read operations to reduce the pressure on the master database. Through read-write separation, the system can distribute a large number of read requests to the slave database, thereby improving the overall performance and response speed of the system. The slave database is also an important source of data backup. By regularly synchronizing data from the master database, the slave database can ensure that data can be restored in the event of a system failure.

[0064] Cache databases are used to store frequently accessed data in the system, such as user session information, policy information, etc. By storing this data in memory, cache databases can greatly increase the speed of data reading. Cache databases reduce the number of accesses to the master and slave databases, thereby alleviating the pressure on these databases.

[0065] When the system receives a read request, the cache database will first check whether the required data exists in the cache; if so, it will read the data directly from the cache without accessing the master or slave database. Although the cache database provides fast data access capabilities, it also brings data consistency issues. Therefore, the system needs to implement cache invalidation strategies (such as LRU, LFU, etc.) and cache update mechanisms (such as write-after-update, subscription update, etc.) to ensure that the data in the cache is consistent with the data in the master database.

[0066] Throughout the entire process, each cluster works closely and efficiently together to ensure that every service request is processed promptly and accurately, providing enterprise users with a high-quality and stable service experience.

[0067] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0068] It is not difficult for those skilled in the art to understand that the present invention includes any combination of the invention content and specific implementation methods of the above specification and the various parts shown in the drawings. Due to the limited space and to make the specification concise, the various schemes composed of these combinations are not described one by one. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

[0069] Although the embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and cannot be understood as limiting the present invention. Those skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention without departing from the principles and purpose of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A microservice architecture for multi-regional enterprise service data, characterized in that: include: Nginx load balancing cluster, front-end server cluster, TCP server, Zuul gateway cluster, microservice application service cluster, Eureka registration center cluster, Admin monitoring center cluster and database cluster, among which, When an enterprise user initiates a service request through the front end using the HTTP protocol, the service request is first transmitted over the TCP / IP protocol stack, and then reaches the Nginx load balancing cluster. The Nginx load balancing cluster receives service requests through the Nginx reverse proxy server, and the Nginx reverse proxy server distributes the requests to the front-end Server cluster, and realizes balanced distribution of requests through the Nginx load balancing cluster; 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 by the TCP server; 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; perform preliminary security verification and protocol conversion on the requests, and after confirming the legitimacy and standardization of the requests, send the requests to the microservice application service cluster; The Eureka registration center 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 obtains a service list under the guidance of the Eureka registration center cluster and determines the service to be called; The Admin monitoring center cluster is used to monitor the operating status, resource usage and request processing progress of each cluster in real time; when an abnormality 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 according to 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 a public account, a mini program, a mobile terminal or a management platform.

3. The microservice architecture for multi-regional enterprise service data according to claim 1, characterized in that: The Nginx load balancing cluster sends static files from users to the CDN cache.

4. The microservice architecture for multi-regional enterprise service data according to claim 1, characterized in that: The Eureka registry center cluster records the location and status information of each microservice in the microservice application service cluster.

5. The microservice architecture for multi-regional enterprise service data according to claim 1, characterized in that: The microservice application service cluster and the Zuul gateway cluster implement Ribbon client load balancing and Hystix service fuse; the microservice application service cluster pushes / pull configuration information to the Config configuration center cluster.

6. The microservice architecture for multi-regional enterprise service data according to claim 1, characterized in that: The Admin monitoring center cluster registers services with the microservice application service cluster and receives service monitoring information fed back by the microservice application service cluster.

7. The microservice architecture for multi-regional enterprise service data according to claim 1, characterized in that: The microservice application service cluster reads information in the OSS object storage cluster; the RabbitMQ message queue cluster sends messages to the microservice application service cluster; and the three-party message is sent to the microservice application service cluster via the HTTP protocol.

8. The microservice architecture for multi-regional enterprise service data according to claim 1, characterized in that: The database cluster includes: a Redis cache database cluster, a MySQL relational database cluster and an Elasticsearch / MongoDB document data area cluster, and the microservice application service cluster performs data transmission with the Redis cache database cluster, the MySQL relational database cluster and the Elasticsearch / MongoDB document data area cluster.

9. The microservice architecture for multi-regional enterprise service data according to claim 8, characterized in that: The microservice application service cluster performs data transmission with the Redis cache database cluster and the Elasticsearch / MongoDB document data area cluster in the form of low-frequency writing and high-frequency reading; The microservice application service cluster transmits data with the MySQL relational database cluster in the form of high-frequency writing and low-frequency reading.

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

Images