A large-scale global production factor data distributed access method based on a micro-service architecture

Abstract

The application provides a large-scale global production factor data distributed access method based on a micro-service architecture, relates to the technical field of digital information transmission and network data access, and comprises the following steps: acquiring an access state of global production factor I / O points and a bearing state of a plurality of access micro-service instances, forming an I / O access bearing unit according to an access state correlation relationship between the production factor I / O points, and establishing an access mapping relationship between the I / O access bearing unit and the access micro-service instances. The large-scale global production factor data distributed access method based on the micro-service architecture determines a takeover object of a candidate access micro-service instance by constructing a production factor I / O access bearing unit and combining effective access capacity, an access capacity gap and a target takeover load, so that the instance expansion process corresponds to the actual I / O access load bearing state, and the expansion completion is avoided to be determined only according to the instance start state or the nominal capacity.

Description

Technical Field

[0001] This invention relates to the field of digital information transmission and network data access technology, specifically a method for large-scale, full-domain distributed access of production factor data based on a microservice architecture. Background Technology

[0002] As industrial production systems become increasingly digitalized, production equipment, energy systems, environmental monitoring equipment, and production support systems continuously generate production factor data. The I / O points corresponding to these field devices undertake data access tasks. In large enterprises and cross-regional production scenarios, the number of I / O points can reach hundreds of thousands or even millions, with the access process characterized by a large number of connections, long durations, and varying collection cycles. Existing production factor data access systems mostly adopt a microservice architecture, dividing the data access function into multiple access microservice instances, each deployed on different computing nodes. A load balancer maintains the set of instances providing access services and allocates I / O point access requests based on instance running status, connection count, request count, or resource usage. When the access load changes, the system adds or removes access microservice instances according to preset scaling rules, adjusting the service scale of the access system. Some systems also include protocol adaptation, data format conversion, and caching components to handle the access, conversion, and temporary storage of data from different devices.

[0003] Existing microservice elastic access solutions typically require the startup, registration, and addition of microservice instances to the set of serviceable instances as conditions for scaling up. The access relationships of production factor I / O points exhibit persistent connectivity and state maintenance characteristics. Before newly added microservice instances have stably taken over the existing I / O access load, the system has already calculated the overall service capacity after scaling up based on the number of instances or their nominal processing capacity. This results in a discrepancy between the nominal access capacity of the set of serviceable instances and the actual access capacity. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a method for large-scale, full-domain distributed access to production factor data based on a microservice architecture. The technical problem this invention aims to solve is: how to resolve the inconsistency between the effective access capability and the actual access capability of the serviceable instance set during the elastic scaling of microservices through the construction of production factor I / O access bearing units, the takeover of candidate access microservice instances, the confirmation of load balancing between the two ends, and the update of effective access capability.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for large-scale, full-domain distributed access to production factor data based on a microservice architecture, comprising:

[0006] S1. Obtain the access status of all production element I / O points and the bearing status of multiple access microservice instances. Form an I / O access bearing unit based on the access status association between the production element I / O points. Establish an access mapping relationship between the I / O access bearing unit and the access microservice instances. Determine a set of valid serviceable instances from the multiple access microservice instances. Determine the effective access capability of the set of valid serviceable instances based on the bearing status of each access microservice instance in the set of valid serviceable instances.

[0007] S2. Determine the access capacity gap based on the current access load formed by the I / O access bearer unit and the effective access capacity. When the access capacity gap meets the instance expansion conditions, the load balancer starts candidate access microservice instances. Determine the target takeover load based on the access capacity gap and determine the takeover set based on the target takeover load. Before the candidate access microservice instance is added to the effective serviceable instance set, the effective access capacity of the effective serviceable instance set is not updated with the nominal access capacity registered when the candidate access microservice instance is started.

[0008] S3. For each I / O access bearer unit in the set to be taken over, determine the handover boundary between the corresponding source access microservice instance and the candidate access microservice instance, and adjust the access mapping relationship according to the handover boundary so that the I / O access bearer unit in the set to be taken over is taken over by the candidate access microservice instance;

[0009] S4. Based on the handover boundary corresponding to the same I / O access bearer unit, determine the source end access release load formed by the source access microservice instance and the candidate end continuous access load formed by the candidate access microservice instance respectively. Determine the smaller of the source end access release load and the candidate end continuous access load as the confirmed takeover load of the corresponding I / O access bearer unit, and determine the net takeover load of the candidate access microservice instance according to the confirmed takeover load of each I / O access bearer unit in the takeover set.

[0010] S5. When the net takeover load meets the takeover confirmation condition corresponding to the target takeover load, the load balancer adds the candidate access microservice instance to the set of valid serviceable instances, and updates the valid access capability of the set of valid serviceable instances with the net takeover load as the valid access capability increment of the candidate access microservice instance, and allocates the access request of the production element I / O point based on the updated set of valid serviceable instances.

[0011] Preferably, the I / O access bearer unit consists of multiple production element I / O points belonging to the same production equipment, accessing through the same continuous communication session, and sharing the session state of the continuous communication session. The production element I / O points in the same I / O access bearer unit are taken over as a whole among the access microservice instances and are not split into different access microservice instances.

[0012] Preferably, the bearer status includes at least two of the following: the number of I / O access bearer units currently being handled by the access microservice instance, the amount of continuously accessed data, the amount of accessed data to be processed, and the access processing latency.

[0013] Preferably, the set to be taken over is determined from the I / O access bearer units currently hosted by the access microservice instances in the set of valid serviceable instances. Each I / O access bearer unit in the set to be taken over has data generated by the production element I / O points continuously received by the corresponding access microservice instance at the time of determination, is not in other takeover processes, and a single I / O access bearer unit in the set to be taken over is not split into different access microservice instances. The current access load corresponding to the set to be taken over is not less than the target takeover load.

[0014] Preferably, the handover boundary includes the data sequence identifier of the source access microservice instance of the corresponding I / O access bearer unit before adjusting the access mapping relationship, and the access status version identifier corresponding to the data sequence identifier.

[0015] Preferably, the source-end access release load is determined based on the access load actually processed by the source access microservice instance within the equal-length statistical period before and after the handover boundary of the same I / O access bearer unit. The access load actually processed by the source access microservice instance within the equal-length statistical period before the handover boundary is determined as the pre-handover access load, and the access load still actually processed by the source access microservice instance within the equal-length statistical period after the handover boundary is determined as the residual access load. The reduction of the pre-handover access load relative to the residual access load represents the source-end access release load.

[0016] Preferably, the candidate endpoint continuous access load is determined based on the data generated by the production element I / O points in the same I / O access bearer unit that the candidate access microservice instance continuously receives after the handover boundary. When the candidate access microservice instance receives data generated by the production element I / O points in the corresponding I / O access bearer unit within no less than two consecutive collection cycles, and the received data sequence continuously advances according to the data sequence order after the handover boundary, the access load formed by the I / O access bearer unit within the consecutive collection cycle is included in the candidate endpoint continuous access load.

[0017] Preferably, the confirmed takeover load is only determined for I / O access bearer units that simultaneously generate the source end access release load and the candidate end continuous access load within the same preset confirmation period after the access mapping relationship is adjusted according to the corresponding handover boundary. The source end access release load or candidate end continuous access load generated outside the preset confirmation period is not included in the confirmed takeover load of the corresponding I / O access bearer unit.

[0018] Preferably, the takeover confirmation condition includes that the net takeover load is not less than the target takeover load in two consecutive preset confirmation periods of the same length.

[0019] Preferably, the step of allocating access requests for the production element I / O points based on the updated set of valid serviceable instances includes, after the candidate access microservice instance is added to the set of valid serviceable instances, using the candidate access microservice instance as one of the target access microservice instances for new access requests, and ensuring that the access load formed by the new access requests allocated to the candidate access microservice instance does not exceed the increment of the valid access capacity of the candidate access microservice instance.

[0020] This invention provides a method for large-scale, distributed access to production factor data across the entire domain based on a microservice architecture. It offers the following advantages:

[0021] This method for distributed access to large-scale, full-domain production factor data based on a microservice architecture constructs production factor I / O access bearing units and determines the takeover targets of candidate access microservice instances by combining effective access capabilities, access capability gaps, and target takeover loads. This ensures that the instance expansion process corresponds to the actual I / O access load bearing status, avoiding the judgment of expansion completion based solely on instance startup status or nominal capabilities.

[0022] The confirmed takeover load is determined by a dual-end confirmation method that involves releasing load at the source end and continuously connecting load at the candidate end. The effective access capacity is updated with the net takeover load, so that the capacity statistics after expansion are based on the actual takeover results, reducing the premature or duplicate inclusion of capacity, and improving the consistency between the allocation of subsequent access requests and the actual carrying capacity. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the overall system architecture of the present invention;

[0024] Figure 2 This is the main flowchart of the overall method of the present invention;

[0025] Figure 3 This is a flowchart illustrating the formation and expansion triggering process of the carrier unit in this invention.

[0026] Figure 4This is a flowchart illustrating the handover boundary and load calculation process of the present invention.

[0027] Figure 5 This is a flowchart illustrating the takeover confirmation and update allocation process of this invention. Detailed Implementation

[0028] The technical solutions in the embodiments of the present invention have been clearly and completely described. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0029] Example 1

[0030] like Figure 1-5 As shown, this embodiment of the invention provides a method for distributed access to large-scale, full-domain production factor data based on a microservice architecture, including:

[0031] S1. Obtain the access status of all production element I / O points and the carrying status of multiple access microservice instances. Based on the access status relationships between production element I / O points, form I / O access carrying units. Establish an access mapping relationship between I / O access carrying units and access microservice instances. Determine a set of valid serviceable instances from multiple access microservice instances, and determine the valid access capability of the valid serviceable instance set based on the carrying status of each access microservice instance in the valid serviceable instance set. An I / O access carrying unit consists of multiple production element I / O points belonging to the same production device, accessing through the same persistent communication session, and sharing the session status of the persistent communication session. Production element I / O points within the same I / O access carrying unit are uniformly carried across access microservice instances and are not split into different access microservice instances. The carrying status includes at least two of the following: the number of I / O access carrying units currently carried by the access microservice instance, the amount of continuously accessed data, the amount of pending access data, and the access processing latency.

[0032] S2. Determine the access capacity gap based on the current access load and effective access capacity formed by the I / O access bearer units. When the access capacity gap meets the instance expansion conditions, the load balancer starts candidate access microservice instances. Determine the target takeover load based on the access capacity gap, and determine the takeover set based on the target takeover load. Before the candidate access microservice instances are added to the effective serviceable instance set, the effective access capacity of the effective serviceable instance set is not updated with the nominal access capacity registered when the candidate access microservice instances are started. The takeover set is determined from the I / O access bearer units currently handled by the access microservice instances in the effective serviceable instance set. Each I / O access bearer unit in the takeover set has data generated by production element I / O points continuously received by the corresponding access microservice instance at the time of determination, is not in other takeover processes, and a single I / O access bearer unit in the takeover set is not split into different access microservice instances. The current access load corresponding to the takeover set is not less than the target takeover load.

[0033] S3. For each I / O access bearer unit in the set to be taken over, determine the handover boundary between the corresponding source access microservice instance and the candidate access microservice instance, and adjust the access mapping relationship according to the handover boundary so that the I / O access bearer units in the set to be taken over are transferred to the candidate access microservice instances. The handover boundary includes the data sequence identifier that the source access microservice instance of the corresponding I / O access bearer unit last confirmed and processed before adjusting the access mapping relationship, and the access status version identifier corresponding to the data sequence identifier.

[0034] S4. Based on the handover boundary corresponding to the same I / O access bearer unit, determine the source-end access release load formed by the source access microservice instance and the candidate-end continuous access load formed by the candidate access microservice instance. The smaller of the source-end access release load and the candidate-end continuous access load is determined as the confirmed takeover load of the corresponding I / O access bearer unit. The net takeover load of the candidate access microservice instance is determined based on the confirmed takeover load of each I / O access bearer unit in the takeover set. The source-end access release load is determined based on the access load actually processed by the source access microservice instance within the equal-length statistical period before and after the handover boundary for the same I / O access bearer unit. The access load actually processed by the source access microservice instance within the equal-length statistical period before the handover boundary is determined as the pre-handover access load. The access load still actually processed by the source access microservice instance within the equal-length statistical period after the handover boundary is determined as the residual access load. The reduction in the pre-handover access load relative to the residual access load characterizes the source-end access release load. The candidate endpoint continuous access load is determined based on the data generated by the production element I / O points in the same I / O access bearer unit continuously received by the candidate access microservice instance after the handover boundary. If a candidate access microservice instance receives data generated by the production element I / O points in the corresponding I / O access bearer unit within at least two consecutive collection cycles, and the received data sequence continuously advances according to the data sequence order after the handover boundary, the access load formed by the I / O access bearer unit within the consecutive collection cycles is included in the candidate endpoint continuous access load. Confirmed takeover load is only determined for I / O access bearer units that simultaneously generate source endpoint access release load and candidate endpoint continuous access load within the same preset confirmation period after the access mapping relationship is adjusted according to the corresponding handover boundary. Source endpoint access release load or candidate endpoint continuous access load generated outside the preset confirmation period is not included in the confirmed takeover load of the corresponding I / O access bearer unit.

[0035] S5. When the net takeover load meets the takeover confirmation condition corresponding to the target takeover load, the load balancer adds the candidate access microservice instance to the set of valid serviceable instances. The net takeover load is used as the increment of the valid access capacity of the candidate access microservice instance to update the valid access capacity of the set of valid serviceable instances. Access requests for production element I / O points are allocated based on the updated set of valid serviceable instances. The takeover confirmation condition includes that the net takeover load is not less than the target takeover load for two consecutive preset confirmation periods of equal length. Allocating access requests for production element I / O points based on the updated set of valid serviceable instances includes, after the candidate access microservice instance is added to the set of valid serviceable instances, using the candidate access microservice instance as one of the target access microservice instances for new access requests, and ensuring that the access load formed by the new access requests allocated to the candidate access microservice instance does not exceed the increment of the valid access capacity of the candidate access microservice instance.

[0036] This invention further clarifies the relationship between the current access load, the effective serviceable instance set, and the effective access capability, ensuring that the access capability gap, the target takeover load, and the set to be taken over use a consistent load measurement benchmark. Candidate access microservice instances are not included in the effective service capability before actual takeover confirmation, avoiding premature expansion of system availability based solely on instance startup status or nominal access capability.

[0037] This invention also unifies the state reference of source end release and candidate end takeover by the handover boundary, and jointly confirms the source end access release load and the candidate end continuous access load within the same confirmation period, using the net takeover load as the basis for the candidate instance's ability to participate in subsequent scheduling. This method can reduce the artificial increase in capacity caused by repeated takeover, instantaneous load, and incomplete takeover, ensuring that the service capacity of the expanded instance is consistent with the actual I / O access bearing state.

[0038] Example 2

[0039] This embodiment is used to verify the effectiveness of the dual-end confirmation method of source end access to release load and candidate end continuous access to load in identifying the actual load taken over by the I / O access bearer unit.

[0040] The production site is equipped with 100,000 production element I / O points, including equipment operating status, temperature, pressure, flow rate, and energy consumption data. I / O access units are formed according to production equipment, continuous communication sessions, and session status. Access load is uniformly represented by the average data rate corresponding to the amount of effective production element data processed within a statistical period, in MB / s.

[0041] The system is configured with four valid access microservice instances, A1 to A4. Using the continuous access data volume and access processing latency within the preceding 30-second statistical period as bearer status parameters, the effective access capacity of the set of valid serviceable instances is determined to be 24.20 MB / s. The current access load during the same period is 28.20 MB / s, resulting in an access capacity gap of 4.00 MB / s. The instance expansion threshold is set to 3.00 MB / s; therefore, candidate access microservice instance A5 is initiated. A5 registers a nominal access capacity of 8.00 MB / s upon startup, but this is not included in the effective access capacity until access bearer confirmation is completed.

[0042] 1. Determine the set to be taken over

[0043] Based on the access capacity gap of 4.00MB / s, the target takeover load of A5 is determined to be 4.00MB / s.

[0044] U1, U2, and U3 were selected from the existing I / O access bearer units to form a takeover set. U1, under the control of A1, contains 1200 production factor I / O points with a data acquisition period of 100ms; U2, under the control of A2, contains 860 production factor I / O points with a data acquisition period of 200ms; and U3, under the control of A3, contains 1050 production factor I / O points with a data acquisition period of 100ms. All three I / O access bearer units are in a continuous access state and have not entered any other takeover process.

[0045] Within 10 seconds before the handover, the access loads of U1, U2 and U3 were 1.62MB / s, 1.31MB / s and 1.42MB / s respectively, totaling 4.35MB / s, which is not less than the target takeover load.

[0046] 2. Determine the handover boundary

[0047] Before adjusting the access mapping relationship, record the last confirmation data sequence identifier and access status version identifier of the three I / O access bearer units respectively.

[0048] The data sequence identifier for U1 is 583214, and the access status version identifier is V37. The data sequence identifier for U2 is 416820, and the access status version identifier is V19. The data sequence identifier for U3 is 761503, and the access status version identifier is V28.

[0049] After completing the handover boundary record, the access mapping relationship of U1, U2, and U3 is switched to A5. A5 takes over the continuous data sequences after 583215, 416821, and 761504 respectively, and keeps the access status version consistent with the handover boundary.

[0050] 3. Determine the source end connection to release load.

[0051] The 10 seconds before and after each boundary are used as equal-length statistical time periods.

[0052] In the 10 seconds before the handover, the actual access load processed by A1 was 1.62 MB / s. In the 10 seconds after the handover, A1 still processed 0.08 MB / s, and the source-end access release load was 1.54 MB / s.

[0053] U2 was actually processed by A2 at 1.31 MB / s in the 10 seconds before the handover. After the handover, the residual access load was 0.04 MB / s, and the source end access release load was 1.27 MB / s.

[0054] U3 was actually processed by A3 at 1.42 MB / s in the 10 seconds before handover, and the residual access load after handover was 0.10 MB / s, while the source end access release load was 1.32 MB / s.

[0055] 4. Determine the continuous load of candidate endpoints.

[0056] Candidate end statistics use the same 10-second confirmation period as the source end after handover. U1 and U3 cover 100 consecutive acquisition cycles within 10 seconds, and U2 covers 50 consecutive acquisition cycles, all exceeding the confirmation requirement of two consecutive acquisition cycles.

[0057] During the statistical period, the data sequences of U1, U2, and U3 all progressed continuously in the order after their respective handover boundaries, without any sequence rollback, and the access status versions remained consistent. A5 generated a continuous access load of 1.49 MB / s for candidate endpoints for U1, 1.25 MB / s for U2, and 1.36 MB / s for U3.

[0058] 5. Determine the net load on the pipeline.

[0059] The load released by the source end of U1 was 1.54MB / s, the load of the candidate end continuously accessing was 1.49MB / s, and the load of the takeover was confirmed to be 1.49MB / s.

[0060] The two loads corresponding to U2 are 1.27MB / s and 1.25MB / s, respectively, and the takenover load has been confirmed to be 1.25MB / s.

[0061] The two loads corresponding to U3 are 1.32MB / s and 1.36MB / s, respectively, and the confirmed takeover load is 1.32MB / s. The candidate end's exceedance of the source end's release amount by 0.04MB / s did not obtain corresponding verification of the source end's release status and is not included in the confirmed takeover load.

[0062] The confirmed takeover loads of U1, U2, and U3 total 4.06 MB / s, forming the net takeover load of A5, achieving the target takeover load of 4.00 MB / s.

[0063] The results show that simultaneously verifying the load release at the source end and the continuous acceptance status at the candidate end under a unified handover boundary and confirmation period can eliminate load changes that occur only on one side. The confirmed takeover load is constrained by both the actual release amount at the source end and the continuous acceptance amount at the candidate end, reducing the artificial increase in takeover load caused by overlapping handovers and incomplete acceptance, so that the net takeover load corresponds to the actual production factor I / O access load that has been transferred.

[0064] Example 3

[0065] This embodiment is used to verify the implementation effect of adding candidate access microservice instances to the set of valid serviceable instances and participating in the allocation of new access requests after continuous takeover confirmation.

[0066] The production factor I / O access simulation environment is configured with 1,000,000 I / O points, of which 999,680 I / O points have established continuous access relationships, and the remaining 320 I / O points are reserved for new access. Simulation data includes equipment status, temperature, pressure, flow rate, power, and switching quantities. Access load is represented by the average data rate corresponding to the amount of effective production factor data processed within the statistical period.

[0067] Before expansion, the effective access capacity of the set of serviceable instances was 62.00 MB / s, the current access load was 67.50 MB / s, and the access capacity gap was 5.50 MB / s. The instance expansion threshold was set to 5.00 MB / s, and the load balancer accordingly launched candidate access microservice instance B7, setting the target takeover load at 5.50 MB / s. B7's nominal access capacity registered at startup was 12.00 MB / s, which was not included in the effective access capacity until the takeover confirmation was completed.

[0068] 1. Forming a takeover load

[0069] The set of I / O points to be taken over is determined from those I / O points that have established continuous access relationships, and the access mapping relationship is adjusted according to the handover boundary of the corresponding I / O access bearer unit.

[0070] The source access microservice instance uses the same load statistics caliber as B7, and within the same confirmation period, it separately generates source access release load and candidate continuous access load, and then determines the confirmed takeover load of each I / O access bearer unit. After the preceding takeover process is completed, it enters the continuous confirmation phase.

[0071] 2. Perform continuous takeover confirmation

[0072] Set two consecutive preset confirmation periods, each with a duration of 15 seconds.

[0073] During the first confirmation period, the net takeover load of B7 was 5.74 MB / s, and during the second confirmation period, the net takeover load was 5.61 MB / s. The net takeover load in both confirmation periods was not less than the target takeover load of 5.50 MB / s, thus meeting the takeover confirmation criteria.

[0074] The net takeover load at the end of the second confirmation period is 5.61 MB / s. If the net takeover load is lower than 5.50 MB / s in any confirmation period, B7 remains a candidate and is not included in the set of available serviceable instances.

[0075] 3. Update effective access capabilities

[0076] After the continuous takeover is confirmed, the load balancer adds B7 to the set of available serviceable instances, with an effective access capacity increment of 5.61 MB / s for B7.

[0077] Before the expansion, the effective access capacity was 62.00 MB / s, and after the update, it is 67.61 MB / s. The 12.00 MB / s registered when B7 starts is only used as the instance's nominal capacity limit and does not directly replace the effective access capacity increment confirmed by the takeover.

[0078] 4. Allocate new access requests

[0079] After B7 is added to the set of available service instances, the remaining 320 production element I / O points initiate new access requests. The load balancer includes B7 in the target access microservice instances and allocates 320 I / O points to B7 during the 30-second scheduling and statistics period.

[0080] The average access load generated by the 320 I / O points within 30 seconds was 0.08 MB / s, less than the 5.61 MB / s effective access capacity increment of B7. After the new access request, the system's current access load increased from 67.50 MB / s to 67.58 MB / s, still within the updated effective access capacity of 67.61 MB / s. The access load borne by B7 increased from 5.61 MB / s at the time of takeover confirmation to 5.69 MB / s, below the nominal access capacity limit of 12.00 MB / s.

[0081] The results show that using the continuously confirmed net takeover load as the incremental effective access capacity of candidate microservice instances can establish a correspondence between the time when an instance enters an effective service state and the continuous takeover state. New access requests are constrained by both the confirmed effective access capacity and the actual carrying capacity of the instance, preventing the nominal access capacity from being prematurely included or the takeover load from being reused with the new load, thus ensuring consistency between the expanded effective access capacity, the current access load, and the request allocation results.

[0082] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for large-scale, full-domain distributed access to production factor data based on a microservice architecture, characterized in that, include: S1. Obtain the access status of all production element I / O points and the bearing status of multiple access microservice instances. Form an I / O access bearing unit based on the access status association between the production element I / O points. Establish an access mapping relationship between the I / O access bearing unit and the access microservice instances. Determine a set of valid serviceable instances from the multiple access microservice instances. Determine the effective access capability of the set of valid serviceable instances based on the bearing status of each access microservice instance in the set of valid serviceable instances. S2. Determine the access capacity gap based on the current access load formed by the I / O access bearer unit and the effective access capacity. When the access capacity gap meets the instance expansion conditions, the load balancer starts candidate access microservice instances. Determine the target takeover load based on the access capacity gap and determine the takeover set based on the target takeover load. Before the candidate access microservice instance is added to the effective serviceable instance set, the effective access capacity of the effective serviceable instance set is not updated with the nominal access capacity registered when the candidate access microservice instance is started. S3. For each I / O access bearer unit in the set to be taken over, determine the handover boundary between the corresponding source access microservice instance and the candidate access microservice instance, and adjust the access mapping relationship according to the handover boundary so that the I / O access bearer unit in the set to be taken over is taken over by the candidate access microservice instance; S4. Based on the handover boundary corresponding to the same I / O access bearer unit, determine the source end access release load formed by the source access microservice instance and the candidate end continuous access load formed by the candidate access microservice instance respectively. Determine the smaller of the source end access release load and the candidate end continuous access load as the confirmed takeover load of the corresponding I / O access bearer unit, and determine the net takeover load of the candidate access microservice instance according to the confirmed takeover load of each I / O access bearer unit in the takeover set. S5. When the net takeover load meets the takeover confirmation condition corresponding to the target takeover load, the load balancer adds the candidate access microservice instance to the set of valid serviceable instances, and updates the valid access capability of the set of valid serviceable instances with the net takeover load as the valid access capability increment of the candidate access microservice instance, and allocates the access request of the production element I / O point based on the updated set of valid serviceable instances.

2. The method for large-scale, full-domain distributed access to production factor data based on a microservice architecture as described in claim 1, characterized in that: The I / O access bearer unit consists of multiple production element I / O points that belong to the same production equipment, are accessed through the same continuous communication session, and share the session state of the continuous communication session. The production element I / O points in the same I / O access bearer unit are taken over as a whole among the access microservice instances and are not split to different access microservice instances.

3. The method for large-scale, full-domain distributed access to production factor data based on a microservice architecture as described in claim 1, characterized in that: The bearer status includes at least two of the following: the number of I / O access bearer units currently being handled by the access microservice instance, the amount of continuously accessed data, the amount of accessed data to be processed, and the access processing latency.

4. The method for large-scale, full-domain distributed access to production factor data based on a microservice architecture as described in claim 1, characterized in that: The set to be taken over is determined from the I / O access bearer units currently handled by the access microservice instances in the set of valid serviceable instances. Each I / O access bearer unit in the set to be taken over has data generated by the production element I / O points continuously received by the corresponding access microservice instance at the time of determination, is not in other takeover processes, and a single I / O access bearer unit in the set to be taken over is not split into different access microservice instances. The current access load corresponding to the set to be taken over is not less than the target takeover load.

5. The method for large-scale, full-domain distributed access to production factor data based on a microservice architecture as described in claim 1, characterized in that: The handover boundary includes the data sequence identifier of the source access microservice instance of the corresponding I / O access bearer unit before adjusting the access mapping relationship, and the access status version identifier corresponding to the data sequence identifier.

6. The method for large-scale, full-domain distributed access to production factor data based on a microservice architecture according to claim 1, characterized in that: The source-end access release load is determined based on the access load actually processed by the source access microservice instance within the equal-length statistical period before and after the handover boundary of the same I / O access bearer unit. The access load actually processed by the source access microservice instance within the equal-length statistical period before the handover boundary is determined as the pre-handover access load, and the access load still actually processed by the source access microservice instance within the equal-length statistical period after the handover boundary is determined as the residual access load. The reduction of the pre-handover access load relative to the residual access load represents the source-end access release load.

7. The method for large-scale, full-domain distributed access to production factor data based on a microservice architecture according to claim 1, characterized in that: The candidate endpoint continuous access load is determined based on the data generated by the production element I / O points in the same I / O access bearer unit that the candidate access microservice instance continuously receives after the handover boundary. When the candidate access microservice instance receives data generated by the production element I / O points in the corresponding I / O access bearer unit within no less than two consecutive collection cycles, and the received data sequence continuously advances according to the data sequence order after the handover boundary, the access load formed by the I / O access bearer unit within the consecutive collection cycle is included in the candidate endpoint continuous access load.

8. A method for large-scale, full-domain distributed access to production factor data based on a microservice architecture as described in claim 1, characterized in that: The confirmed takeover load is determined only for I / O access bearer units that simultaneously generate the source end access release load and the candidate end continuous access load within the same preset confirmation period after the access mapping relationship is adjusted according to the corresponding handover boundary. Source end access release load or candidate end continuous access load generated outside the preset confirmation period are not included in the confirmed takeover load of the corresponding I / O access bearer unit.

9. A method for large-scale, full-domain distributed access to production factor data based on a microservice architecture as described in claim 1, characterized in that: The takeover confirmation condition includes that the net takeover load is not less than the target takeover load in two consecutive preset confirmation periods of the same length.

10. A method for large-scale, full-domain distributed access to production factor data based on a microservice architecture as described in claim 1, characterized in that: The method of allocating access requests for the production element I / O points based on the updated set of valid serviceable instances includes, after the candidate access microservice instance is added to the set of valid serviceable instances, using the candidate access microservice instance as one of the target access microservice instances for new access requests, and ensuring that the access load formed by the new access requests allocated to the candidate access microservice instance does not exceed the increment of the valid access capacity of the candidate access microservice instance.

Images