Government data interface management system and method

Abstract

The present disclosure provides a government data interface management system and method, belonging to the field of Internet technology, the system includes: an API portal, which is used to receive operation instructions input by users for APIs, and generate API requests based on the operation instructions; an API gateway, which is used to process API requests sent by the API portal; an API manager, which is used to monitor API usage data, and adjust the parameters of the API gateway based on the API usage data. The government data interface management system and method provided by the present disclosure can improve the efficiency and stability of API management.

Description

Technical Field

[0001] The present disclosure belongs to the field of Internet technology, and more specifically, to a government data interface management system and method. Background Art

[0002] In today's era of globalization and informatization, data and information have become important resources for social development. Actively promoting the digital transformation of the government and building a government big data system can improve government governance efficiency and service levels and promote social development.

[0003] In the construction of the government big data system, data assets exist not only in the form of database tables, but also in a large number of APIs (application programming interfaces). APIs have become a key bridge connecting different software applications, services, and devices, and are essential for promoting data sharing and achieving business integration. However, with the rapid development of corporate business and the growing needs of users, traditional API management methods can no longer meet the needs in terms of governance, operation and maintenance monitoring, and security. Therefore, the development of an efficient, stable, and easy-to-use API management platform has become an urgent need in the industry. Summary of the invention

[0004] The purpose of the present disclosure is to provide a government data interface management system and method to improve the efficiency and stability of API management.

[0005] A first aspect of an embodiment of the present disclosure provides a government affairs data interface management system, including:

[0006] An API portal is used to receive operation instructions input by users for the API and generate API requests based on the operation instructions;

[0007] API gateway, used to process API requests sent by the API portal;

[0008] The API manager is used to monitor the usage data of the API and adjust the parameters of the API gateway based on the usage data of the API.

[0009] A second aspect of the embodiments of the present disclosure provides a method for managing a government affairs data interface, including:

[0010] Receive, based on the API portal, an operation instruction input by a user for an API, and generate an API request based on the operation instruction;

[0011] Processing the API request sent by the API portal based on the API gateway;

[0012] Configure the API access control policy based on the API manager, and adjust the parameters of the API gateway based on the API access control policy.

[0013] The beneficial effects of the government data interface management system and method provided by the embodiments of the present disclosure are:

[0014] In the disclosed embodiment, an API portal, an API gateway, and an API manager are used to form a distributed architecture, wherein the API portal provides an intuitive and convenient way for users to input operation instructions, and converts the operation instructions into API requests and sends them to the API gateway. The API gateway serves as a bridge between external requests and internal API servers, and is used to route API requests to the corresponding API server. The API manager is used to monitor the usage data of the API. Based on the monitored API usage data, the API manager can adjust the parameters of the API gateway to optimize the performance and availability of the API.

[0015] The embodiments of the present disclosure adopt a distributed architecture, which can more effectively process high-concurrency requests by distributing the computing load on multiple physical or virtual nodes, thereby improving the scalability and stability of the system and reducing the risk of single point failures. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1 A structural block diagram of a government affairs data interface management system provided in an embodiment of the present disclosure;

[0018] Figure 2 A flowchart of a government data interface management method provided in accordance with an embodiment of the present disclosure. DETAILED DESCRIPTION

[0019] In the following description, specific details such as specific system structures and technologies are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present disclosure. However, it should be clear to those skilled in the art that the present disclosure may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obstructing the description of the present disclosure with unnecessary details.

[0020] In order to make the purpose, technical solutions and advantages of the present disclosure more clear, specific embodiments will be described below in conjunction with the accompanying drawings.

[0021] Please refer to Figure 1 , Figure 1The structural block diagram of the government data interface management system 10 provided in one embodiment of the present disclosure includes:

[0022] The API portal 11 is used to receive operation instructions input by users for the API and generate API requests based on the operation instructions;

[0023] API gateway 12, used to process API requests sent by API portal 11;

[0024] The API manager 13 is used to configure the API's current limiting strategy and adjust the parameters of the API gateway 12 based on the API's current limiting strategy.

[0025] In this embodiment, the API portal serves as an interactive interface for receiving various operation instructions input by users for the API. For example, the API portal can provide users with a function button, and users can fill in query parameters or initiate data update requests by clicking the function button. The API portal can parse the operation instructions input by users to obtain API requests. For example, in the API portal of a map application, the user enters a place name and hopes to obtain the geographic coordinates and surrounding information of the place. The API portal will convert this user instruction into a request for the map API, which contains the place name as a parameter, and send it to the API gateway with a specified HTTP method (such as GET or POST).

[0026] The API gateway is the middle layer that connects the API portal and the backend API server, and is responsible for processing API requests from the API portal. When the API gateway receives an API request, it makes a routing decision based on the characteristics of the API request (such as URL, HTTP method, request header information, etc.) to determine which specific API server to forward the API request to.

[0027] The API manager is used to monitor API usage data, including request volume, response time, error rate, etc. For example, the API manager can use tools such as Prometheus and Grafana to monitor API performance indicators and generate corresponding reports and charts. Based on the monitored API usage data, the API manager can adjust the parameters of the API gateway to optimize the performance and availability of the API. For example, if the API manager finds that the number of requests to a certain API is too large, resulting in a longer response time, it can notify the API gateway to adjust the load balancing strategy and distribute more requests to other available API servers.

[0028] It can be concluded from the above that the embodiment of the present disclosure adopts an API portal 11, an API gateway 12 and an API manager to form a distributed architecture, wherein the API portal 11 provides an intuitive and convenient way for users to input operation instructions, and converts the operation instructions into API requests and sends them to the API gateway 12. The API gateway 12 serves as a bridge between external requests and internal API servers, and is used to route API requests to the corresponding API server. The API manager is used to monitor the usage data of the API. Based on the monitored API usage data, the API manager can adjust the parameters of the API gateway to optimize the performance and availability of the API.

[0029] The embodiments of the present disclosure adopt a distributed architecture, which can more effectively process high-concurrency requests by distributing the computing load on multiple physical or virtual nodes, thereby improving the scalability and stability of the system and reducing the risk of single point failures.

[0030] In one embodiment of the present disclosure, the operation instructions include API browsing, API testing, and API subscription.

[0031] In this embodiment, the user can input operation instructions such as API browsing, API testing and API subscription through the API portal 11, which are the three basic functions of the API portal 11. Among them, the API browsing function allows users to easily find, view and understand the available APIs through the API portal 11. The API portal 11 usually provides an intuitive interface to display a list of APIs, basic information of each API (such as name, description, version, provider, etc.), and detailed documentation of the API (such as request parameters, response format, error handling, etc.). Through concise descriptions and examples, users can quickly understand the purpose and usage of the API. The API portal 11 adds an interactive testing tool that allows developers to test the API directly in the browser without writing any code. This function allows developers to instantly see how their requests are processed by the API and the data returned by the API by providing a request builder and a response viewer. The API portal 11 allows users to subscribe to the APIs they are interested in and manage their API keys, access rights and usage quotas through the control panel. Users can view their API usage statistics, monitor the frequency of API calls, and ensure that they do not exceed the quota limit. The API portal 11 interacts with the approval system in real time and synchronizes the approval results of the interface calls to the API portal 11, so that subscribers can understand the interface approval information at any time.

[0032] In one embodiment of the present disclosure, the API gateway 12 is specifically used for:

[0033] Identify users by API key and set independent rate limits for each API key.

[0034] As the entry point for API requests, the API gateway 12 can identify and verify whether the incoming API request contains a valid API key. The API key is the credential used by users to access the API, usually consisting of a string of random characters, which is unique and confidential. By parsing the API key in the request header, query parameters, or request body, the API gateway 12 can confirm the identity of the requester. After identifying the API key, the API gateway 12 will compare it with the key stored in the database or authentication service to verify the identity of the requester. If the key is valid and has not been revoked, the requester is considered an authenticated user and can continue with the subsequent request processing process.

[0035] To prevent the API from being abused or overloaded, the API gateway 12 sets an independent rate limit for each API key. The specific rate limiting method can adopt a token bucket algorithm, a sliding window counter, etc., or dynamically adjust the rate limit according to the system load and performance indicators to ensure the stability and availability of the service.

[0036] It can be concluded from the above that in this embodiment, the API gateway 12 identifies the user through the API key and sets an independent rate limit for each API key, thereby ensuring the security and stability of the API. At the same time, this mechanism also helps to reasonably allocate resources and prevent malicious requests from overloading and damaging the API.

[0037] In one embodiment of the present disclosure, the API manager 13 is specifically used to:

[0038] Configure the API's access control policy, rate limiting policy, and version control policy; the access control policy is used to manage API access rights, the rate limiting policy is used to determine the maximum number of requests allowed by the API within a set time; the version control policy is used to manage API version upgrades.

[0039] In this embodiment, the API manager is responsible for configuring API policies, such as access control policies, current limiting policies, version control policies, etc. These policies will be passed to the API gateway, which will execute them when processing API requests. For example, the API manager can configure the access control policy of an API to allow only specific IP addresses or user groups to access the API. The API gateway will filter requests based on these policies and reject requests that do not comply with the policies.

[0040] In one embodiment of the present disclosure, the API usage data includes API access data, and the API manager 13 is specifically used to:

[0041] Predict the peak access time and traffic volume of each API based on its historical access data;

[0042] The configuration parameters of multiple API gateways 12 are adjusted based on the peak access period and peak access traffic of each API.

[0043] In this embodiment, by statistically analyzing the historical access data of each API, the corresponding relationship between the access flow of each API and the access time period can be obtained, and then the access peak time period and access peak flow of each API can be obtained. For example, by analyzing the historical access data, it is found that the access volume of a certain API between 10 am and 11 am and between 3 pm and 4 pm on weekdays is significantly higher than that of other time periods, so these two time periods can be predicted as the access peak time periods of the API.

[0044] Considering that during peak access periods, the API needs to process a large number of requests, which places higher requirements on the management of server resources and network resources, it is necessary to formulate corresponding adjustment strategies to optimize the performance and availability of the API gateway, which can include adjusting the load balancing algorithm, increasing cache capacity, optimizing network bandwidth, etc. For example, you can increase the cache capacity during peak access periods to reduce the number of requests to the backend server; or adjust the load balancing weight to distribute more requests to servers with better performance.

[0045] It can be concluded from the above that this embodiment timely adjusts the configuration parameters of multiple API gateways 12 according to the predicted peak access time period and peak access traffic, which can effectively optimize the performance and availability of the API gateway and improve the stability and reliability of the system.

[0046] In one embodiment of the present disclosure, the configuration parameters of the API gateway 12 include routing rule parameters, and the routing rule parameters are used to indicate the API associated with the API gateway 12; the API manager 13 is specifically used to:

[0047] The first screening condition is that the peak access periods of multiple APIs do not overlap with each other, and the second screening condition is that the peak access traffic corresponding to the same period is less than the traffic limit of the API gateway 12, so as to determine the routing rule parameters of each API gateway 12; the peak access traffic corresponding to the same period is calculated based on the peak access traffic of multiple APIs during the peak access period.

[0048] In this embodiment, the routing rule parameters of the API gateway 12 can be adjusted based on the predicted peak access period and peak access traffic. First, consider connecting multiple APIs with non-overlapping peak periods to one gateway. Since the peak periods do not overlap, multiple APIs connected to one gateway can make full use of the gateway's resources at different times to avoid idle resources. In addition, it is also necessary to consider that the access peak traffic corresponding to the same period is less than the traffic limit of the API gateway 12, where the access peak traffic corresponding to the same period can be obtained by accumulating the access traffic corresponding to multiple APIs in the same period.

[0049] It can be concluded from the above that this embodiment configures the routing rule parameters of the API gateway 12 based on the differences in the peak access time periods and peak access traffic of each API, so as to achieve reasonable utilization of the resources of the API gateway 12.

[0050] In one embodiment of the present disclosure, the configuration parameters of the API gateway 12 include load balancing parameters, which are used to indicate the traffic distribution value of multiple API servers corresponding to the same API; the API manager 13 is specifically used to:

[0051] Calculate the traffic ratio of each API server corresponding to the same API based on the request response time, CPU usage, and memory usage of each API server;

[0052] The traffic allocation value of each API server corresponding to the same API is calculated based on the traffic ratio and peak access traffic.

[0053] In this example, considering that the request response time, CPU usage and memory usage of an API server can all characterize its performance, for example, if an API server has a short response time, it means that it can process requests quickly, then the access traffic allocated to it can be appropriately increased to allow it to bear more request loads; conversely, if the response time is long, the access traffic allocated to it can be reduced to avoid further burdening it and causing performance deterioration. For another example, if an API server has a high CPU usage, it means that it is already running at a high load. At this time, the access traffic allocated to it should be reduced to prevent excessive load from causing performance degradation or even system crash; for API servers with low CPU usage, the traffic ratio can be increased to make full use of its idle computing resources and improve the overall processing capacity of the system. For another example, if the memory usage of an API server is close to or exceeds a certain proportion of its available memory, it may affect its ability to process requests. At this time, the access traffic allocated to it should be reduced to avoid performance problems due to insufficient memory; on the contrary, for instances with low memory usage, the traffic ratio can be appropriately increased to give full play to its memory resource advantages.

[0054] Therefore, this embodiment can calculate the traffic ratio of each API server corresponding to the same API based on the request response time, CPU occupancy and memory occupancy of each API server, and then multiply the peak access traffic by the traffic ratio to obtain the traffic allocation value of each API server corresponding to the same API, thereby allocating the peak access traffic to each API server, that is, realizing the configuration of load balancing parameters.

[0055] It can be concluded from the above that this embodiment comprehensively considers the performance of the API server from the perspective of request response time, CPU occupancy, and memory occupancy, and configures load balancing parameters based on the performance of the API server, which is conducive to allocating more traffic to servers with better performance.

[0056] In one embodiment of the present disclosure, the traffic ratio of each API server corresponding to the same API is calculated based on the request response time, CPU occupancy rate and memory occupancy rate of each API server, which can be described in detail as follows:

[0057] The traffic ratio of each API server corresponding to the same API is calculated using the first formula;

[0058] The first formula is:

[0059] ;

[0060] in, Indicates The traffic ratio of each API server, Indicates The benchmark value of the traffic ratio of each API server; Indicates The request response time of the API server, Indicates The maximum request response time of an API server; Indicates The CPU usage of each API server, Indicates The maximum CPU usage of an API server; Indicates The memory footprint of the API servers, Indicates The maximum memory usage of an API server; , , are all weight coefficients.

[0061] In this embodiment, the traffic ratio of each API server corresponding to the same API is quantified by the first formula, which is conducive to reasonably allocating the access traffic of the API to each API server.

[0062] Furthermore, , , The specific value of can be described as follows:

[0063] If the application information of the same API shows that the same API is applied to the first type of scenario, set The value is greater than and ; The first type of scenario is the real-time data interaction scenario.

[0064] If the application information of the same API shows that the same API is applied to the second scenario, set The value is greater than and ;The second scenario is the scenario of concurrent data calculation;

[0065] If the application information of the same API shows that the same API is applied to the third type of scenario, set The value is greater than and ; The third scenario is the concurrent data query scenario.

[0066] In this embodiment, different API usage scenarios have different requirements for request response time, CPU occupancy, and memory occupancy. For real-time data interaction scenarios, such as government service APIs, staff receive citizens' consultation requests through instant messaging tools or online customer service systems and respond in the shortest possible time. This real-time interaction scenario requires the system to be able to respond quickly to citizens' inquiries and provide accurate and timely information. In this scenario, if the request response time is too long, it will seriously affect the user experience. Therefore, when allocating traffic, it is important to consider the request response time. At this time, you can set The value is greater than and . For scenarios with high-concurrency data calculations, such as traffic flow monitoring APIs, the traffic flow monitoring system will collect data from various sensors, such as cameras, ground sensors, etc. These data need to be analyzed and processed in real time to calculate indicators such as vehicle flow, vehicle speed, and congestion. During peak hours, the collection and analysis of traffic flow data will face high concurrency. A large number of sensors will send data at the same time, and the system needs to process the data quickly and provide real-time traffic information to the traffic management center and the public in a timely manner. In this scenario, a large number of mathematical calculations are required. Therefore, when allocating traffic, it is important to consider CPU usage. At this time, you can set The value is greater than and For concurrent data query scenarios, such as in APIs that process large data sets (such as geographic information systems GIS), a large amount of map data needs to be loaded for processing and querying. In this scenario, large content is required. Therefore, when allocating traffic, it is important to consider memory usage. At this time, you can set The value is greater than and .

[0067] It can be concluded from the above that, when calculating the traffic ratio, this embodiment adjusts the corresponding weight coefficient based on the different requirements of each API, thereby further improving the rationality of traffic distribution.

[0068] In one embodiment of the present disclosure, the data update speed based on the same API is Make adjustments.

[0069] In this embodiment, for an API with slow data update speed, such as an API for querying a country list, since the country list is relatively stable, the cache of the API server can be increased. When multiple clients request the API at the same time, the results in the cache can be directly returned. Reduce it to avoid reducing the traffic ratio of the API server due to high memory usage. Specifically, the following calculation formula can be used to calculate Make adjustments:

[0070]

[0071] in, Indicates the adjusted , Indicates the data update speed of the API. Indicates the reference value of the API data update speed.

[0072] It can be concluded from the above that this embodiment adjusts the traffic ratio of the API server based on the data characteristics of the API, further realizing the refined adjustment of the traffic ratio, so that the resources of each API server are fully utilized.

[0073] In one embodiment of the present disclosure, the historical access data includes historical access traffic data corresponding to multiple time periods; the API manager 13 is specifically used to:

[0074] For any API's historical access data, divide the API's historical access data into a training set and a test set;

[0075] Train the prediction model based on the training set, verify the prediction model based on the test set, and return the verification result;

[0076] In response to the verification result being that the verification is passed, obtaining a first access traffic prediction value corresponding to any API in multiple time periods based on the prediction model; determining an access peak time period and access peak traffic based on the first access traffic prediction value;

[0077] In response to the verification result being a verification failure, the maximum value of the historical access traffic data is determined as the access peak traffic, and the access peak period is set to a null value.

[0078] In this embodiment, a specific implementation method is provided for predicting the peak access period and peak access flow of each API based on the historical access data of each API. For any API, the historical access data of the API can be divided into a training set and a test set, and the prediction model is trained based on the training set, and then the prediction model is verified based on the test set. If the verification passes, it indicates that the historical access data of the API has a time pattern, and the peak access period and peak access flow can be determined based on the prediction model. Otherwise, if the verification fails, it indicates that the historical access data of the API has no time pattern, and the corresponding peak access period of the API is set to a null value (NULL), and the maximum value of the historical access flow data is determined as the corresponding peak access flow of the API.

[0079] It can be concluded from the above that, for historical access data with time regularity, this embodiment uses a prediction model to predict the access peak time period and access peak flow of each API, which is conducive to improving the accuracy of the prediction.

[0080] In one embodiment of the present disclosure, the API manager 13 is further used to:

[0081] Merge adjacent time periods in which the errors between the first access traffic prediction values ​​are less than the first difference to obtain second access traffic prediction values ​​corresponding to multiple first time periods; the second access traffic prediction value corresponding to each first time period is the average value of the first access traffic prediction values ​​of multiple time periods corresponding to the first time period;

[0082] The second access traffic prediction values ​​corresponding to multiple first time periods are sorted by size, the first N second access traffic prediction values ​​are determined as access peak traffic, and the second time periods corresponding to the first N second access traffic prediction values ​​are determined as access peak time periods.

[0083] In this embodiment, considering that the access peak periods of each API are different, when training the prediction model, the 24 hours of each day are divided into M periods (for example, 144 periods) as multiple periods in the training set, where each period is 24×60 / M=10 minutes. Correspondingly, the output data of the prediction model is the first access traffic prediction value corresponding to the M periods in a day. Since each period is relatively short, for any API, there may be multiple adjacent periods with the same first access traffic prediction value. At this time, the adjacent multiple periods can be merged to obtain multiple first periods, and the average value of the first access traffic prediction value corresponding to the adjacent multiple periods is used as the second access traffic prediction value of the first period.

[0084] On the basis of obtaining the second access traffic prediction values ​​corresponding to the multiple first time periods, the second access traffic prediction values ​​corresponding to the multiple first time periods can be sorted by size, and the first N second access traffic prediction values ​​are taken as the access peak traffic. Among them, the specific value of N can be pre-set according to actual needs, or one of the second access traffic prediction values ​​can be selected according to a specified rule, and the multiple second access traffic prediction values ​​before the second access traffic prediction value are determined as the first N second access traffic prediction values. The specified rule can be: the difference between the second access traffic prediction value (for example, the Nth) and the second access traffic prediction value after it (for example, the N+1th) is greater than a times the second access traffic prediction value after it, and a is a preset constant.

[0085] From the above, it can be concluded that in this embodiment, after obtaining the first access traffic prediction values ​​corresponding to multiple time periods, multiple adjacent time periods with the same first access traffic prediction values ​​are merged to obtain multiple second access traffic prediction values ​​corresponding to the multiple first time periods, and the peak access time period and peak access traffic are determined based on the multiple second access traffic prediction values ​​corresponding to the first time period, which is more in line with the actual access situation of each API.

[0086] Corresponding to the government affairs data interface management system 10 in the above embodiment, Figure 2This is a flow chart of a method for managing a government data interface provided by an embodiment of the present disclosure. For ease of explanation, only the parts related to the embodiment of the present disclosure are shown. Figure 2 , the government data interface management method includes:

[0087] S201: The API portal 11 receives an operation instruction input by a user for an API, and generates an API request based on the operation instruction;

[0088] S202: Processing the API request sent by the API portal 11 based on the API gateway 12;

[0089] S203: Configure the access control policy of the API based on the API manager 13, and adjust the parameters of the API gateway 12 based on the access control policy of the API.

[0090] The above are only specific embodiments of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present disclosure, and these modifications or replacements should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope of the claims.

Claims

1. A government data interface management system, characterized in that: include: An API portal is used to receive operation instructions input by users for the API and generate API requests based on the operation instructions; API gateway, used to process API requests sent by the API portal; An API manager, used to monitor API usage data and adjust parameters of the API gateway based on the API usage data; The API usage data includes API access data, and the API manager is specifically used to: Predict the peak access time and traffic volume of each API based on its historical access data; Adjust the configuration parameters of multiple API gateways based on the peak access time and access peak traffic of each API; The configuration parameters of the API gateway include routing rule parameters, and the routing rule parameters are used to indicate the API associated with the API gateway; the API manager is specifically used to: The first screening condition is that the peak access time periods of multiple APIs do not overlap with each other, and the second screening condition is that the peak access traffic corresponding to the same time period is less than the traffic limit of the API gateway, and the routing rule parameters of each API gateway are determined; The access peak flow corresponding to the same time period is calculated based on the access peak flow of multiple APIs during the access peak period.

2. The government affairs data interface management system according to claim 1, characterized in that: The operation instructions include API browsing, API testing and API subscription.

3. The government affairs data interface management system according to claim 2, characterized in that: The API gateway is specifically used for: Identify users by API key and set independent rate limits for each API key.

4. The government affairs data interface management system according to claim 1, characterized in that: The API manager is specifically used for: Configure the API's access control policy, rate limiting policy, and version control policy; the access control policy is used to manage the API's access rights, and the rate limiting policy is used to determine the maximum number of requests allowed by the API within a set time; The version control strategy is used for API version upgrade management.

5. The government affairs data interface management system according to claim 1, characterized in that: The configuration parameters of the API gateway include load balancing parameters, which are used to indicate the traffic distribution value of multiple API servers corresponding to the same API; the API manager is specifically used to: Calculate the traffic ratio of each API server corresponding to the same API based on the request response time, CPU usage, and memory usage of each API server; The traffic allocation value of each API server corresponding to the same API is calculated based on the traffic ratio and the access peak traffic.

6. The government affairs data interface management system according to claim 1, characterized in that: The historical access data includes historical access traffic data corresponding to multiple time periods; the API manager is specifically used to: For any API's historical access data, divide the API's historical access data into a training set and a test set; Training a prediction model based on the training set, validating the prediction model based on the test set, and returning a validation result; In response to the verification result being a passed verification, obtaining a first access traffic prediction value corresponding to any one of the APIs in multiple time periods based on the prediction model; Determine the access peak time period and access peak flow rate based on the first access flow rate prediction value; In response to the verification result being a verification failure, the maximum value of the historical access traffic data is determined as the access peak traffic, and the access peak period is set to a null value.

7. The government affairs data interface management system according to claim 6, characterized in that: The API manager is also specifically used for: Merge adjacent time periods in which the errors between the first access traffic prediction values ​​are less than the first difference to obtain second access traffic prediction values ​​corresponding to multiple first time periods; the second access traffic prediction value corresponding to each of the first time periods is the average value of the first access traffic prediction values ​​of the multiple time periods corresponding to the first time period; The second access traffic prediction values ​​corresponding to the multiple first time periods are sorted by size, the first N second access traffic prediction values ​​are determined as access peak traffic, and the second time periods corresponding to the first N second access traffic prediction values ​​are determined as access peak time periods.

8. A method for managing government data interfaces, characterized in that: include: Receive, based on the API portal, an operation instruction input by a user for an API, and generate an API request based on the operation instruction; Processing the API request sent by the API portal based on the API gateway; Monitoring API usage data based on the API manager, and adjusting parameters of the API gateway based on the API usage data; The API usage data includes API access data, and the API manager is specifically used to: Predict the peak access time and traffic volume of each API based on its historical access data; Adjust the configuration parameters of multiple API gateways based on the peak access time and access peak traffic of each API; The configuration parameters of the API gateway include routing rule parameters, and the routing rule parameters are used to indicate the API associated with the API gateway; the API manager is specifically used to: The first screening condition is that the peak access time periods of multiple APIs do not overlap with each other, and the second screening condition is that the peak access traffic corresponding to the same time period is less than the traffic limit of the API gateway, and the routing rule parameters of each API gateway are determined; The access peak flow corresponding to the same time period is calculated based on the access peak flow of multiple APIs during the access peak period.

Images