CN118054974B - Flow control method in private deployment scene - Google Patents
Flow control method in private deployment scene Download PDFInfo
- Publication number
- CN118054974B CN118054974B CN202410450750.2A CN202410450750A CN118054974B CN 118054974 B CN118054974 B CN 118054974B CN 202410450750 A CN202410450750 A CN 202410450750A CN 118054974 B CN118054974 B CN 118054974B
- Authority
- CN
- China
- Prior art keywords
- deployment
- flow
- service
- detection
- external component
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/101—Access control lists [ACL]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention relates to the technical field of computers, in particular to a flow control method in a private deployment scene, which is used for solving the problem that the upgrading stability of a private deployment system cannot be ensured in the prior art, and improving the upgrading speed and the flexibility of the deployment system. The method specifically comprises the steps of establishing a classified installation package; a flow control step before deployment, namely, after the flow entering the system is processed, deployment of classified installation packages is carried out; a deployment completion step; and at the moment, semi-opening of the flow is carried out, gradual opening and gradual detection are carried out, and finally deployment is finished. In the process, all flow inlets are completely cut off in advance, and whether the flow entering the system before the flow inlet is closed is detected completely or not in the scheme, so that no actual user request enters the system in the subsequent deployment process can be ensured, and the problem of resource loss caused by gray scale deployment of the Internet is effectively avoided.
Description
Technical Field
The invention belongs to the technical field of computers, and particularly relates to a flow control method in a private deployment scene.
Background
The product of the software company is iterated continuously, and the iterated product needs to be continuously upgraded. For some special industries, such as finance and medical industry, data security and privacy protection are of paramount importance, and privately deployed data can be stored in an internal environment of an enterprise and managed by the enterprise, so that the risk of data leakage is reduced. A private deployment scenario refers to deploying a software system in a server or cloud environment hosted by a user himself, rather than using a public cloud or hosted services provided by a third party. In this scenario, the user has complete control over the entire system, including hardware, software, networking, security, and the like. The private deployment can be customized according to the specific requirements of the user, so that the personalized function and performance requirements are met.
Based on such a need, there are also proposed in the prior art, for example, patent nos.: 202111657284.8 discloses a private deployment system upgrading method, a private deployment system upgrading device, a computer device and a storage medium. The method comprises the following steps: pulling an image file generated through a pipeline and synchronized to an image warehouse deployed on a public network server, so that a production server actively synchronizes the image file, and upgrading the image file by configuring an image upgrading file; acquiring an iteration version of the script; automatically upgrading the full script and the incremental script in the database according to the iterative version; acquiring an upgrade file of the configuration file; and automatically configuring the file according to the upgrade file of the configuration file. The method can realize automatic image upgrade, database upgrade, configuration file upgrade and activation, and improves the system upgrade efficiency.
In the prior art, when private deployment is performed, two processing schemes exist, one is to prevent external access still existing in the deployment process and possibly cause the loss of accessed information, and certain measures are needed to avoid user access and effective flow in the upgrading process. The measures comprise adjusting the time of private deployment and informing a user in advance so that the user avoids the time period for access; or take some technical means, such as opening a security group, or configuring a firewall to enable forbidden user access. Such processing is conventional, but tends to result in the traffic being left unprocessed in the private deployment. In particular, it may happen that the treatment according to the plan should be completed, but the treatment plan is changed due to the occurrence of an abnormality, while the update plan is unchanged. This results in some of the last processed content in the previous system not being complete and the trace being lost in the updated system.
And the gray level deployment scheme is adopted, and comprises a tag-based scheme in the Internet, so that the new system and the old system are kept at the same time under the condition that the system always has traffic in, and a guiding part begins to request to enter the new system after deployment is finished so as to test whether the new system operates normally. After confirming no error, gradually updating the old system into the new system. However, in this type of gray scale deployment scheme, since massive actual user requests do not interrupt the system, once the new system code logic has a bug, it directly causes user error data of the actual production environment. If funds are involved, this directly results in a loss of funds to the user. The presence of several dirty data in the system causes data pollution, which is difficult to eradicate even if manual intervention is performed. Therefore, in the two processing schemes, on one hand, the system upgrade is possibly influenced by the data flow generated by the user to cause upgrade failure, and on the other hand, the system upgrade also influences the actual use experience of the user, so that the user operation is invalid in the upgrade process to cause loss to the user.
Disclosure of Invention
Aiming at the problem that the upgrading stability of a private deployment system cannot be ensured in the prior art, and at the same time, the invention provides a flow control method in a private deployment scene for improving the upgrading speed and the flexibility of the deployment system.
The method specifically comprises the steps of establishing a classified installation package: generating a dependency graph between the classified installation packages when the classified installation packages are established; flow control step before deployment: closing a system flow inlet, detecting the flow which enters the system before closing the flow inlet through global flow detection, and judging service modules and processing conditions related to the flow; gradually closing service modules which are not involved in the flow, thereby releasing the corresponding thread number, accelerating the processing speed, and carrying out deployment of classified installation packages after the flow entering the system is processed;
The deployment completion step: after the whole system deployment is completed, firstly opening flow to service components forming the basic functions of the whole system, and at the moment, the gateway and the business start to receive requests, so that the service components forming the basic functions of the whole system have the entering request information and the corresponding feedback information; the other modules still remain in the closed state and do not accept any request, so that only the request information is entered, no corresponding feedback information exists, and the deployed system enters a semi-open flow state at the moment; then detecting the working condition of the service component for opening the flow; after the service components forming the basic functions of the whole system normally run, the access rights of other modules are released one by one according to the data access requirements of the users who have made requests and the dependency graph of the classified installation packages, each module is detected in the releasing process, and after all modules are released, the system enters a state with fully opened flow, and the deployment is completed.
Preferably, the deployment is divided into large version update deployment and patch version update deployment; in the large version updating deployment, after the flow entering the system is processed, the closed service modules are required to be opened for secondary review, and after the flow is confirmed to be processed, all the service modules are closed to start deployment. Large version update deployment refers to the process of updating an existing version of a system program to a completely new one-layer version. Large version updates sometimes involve changes to the core algorithm, requiring more updates, and also introducing significant functional changes or error fixes. Whereas patch version updates typically only fix known errors or security vulnerabilities, the update content is small. The corresponding processing methods are also different.
Preferably, the service in the private deployment scene is divided into service component service forming the basic function of the whole system and external component service with the expansion function, a classified installation package is established based on a single service module, a dependency graph of the classified installation package is manually established, the deployment sequence of the classified installation package is planned according to the dependency graph of the classified installation package, the deployment time of the single classified installation package is estimated, after judging that a flow inlet is closed, the time for processing the flow is estimated when the service module related to the residual flow is judged, the initial time of deployment is proposed according to the estimated time, and the estimated installation time of the classified installation package is combined to finally obtain the estimated installation time period.
Preferably, the flow detection step performed after the flow is closed specifically includes: analyzing thread stacks of all working threads through Java intermediate state flow, judging whether each service component service module before deployment is in a working state by combining with an NIO network frame, and sequentially closing the service component service modules in a non-working state, thereby reducing the number of threads and endowing system resources to the service component service modules in the working state; and meanwhile, the number of the current unprocessed messages is obtained through the message queue, and the time required by the residual work is predicted according to the calculated power of the service module after the lifting. Because the private deployment method related by the invention needs to close the flow before deployment, the residual flow processing speed in the system after the flow is closed can also substantially affect the deployment time of the whole system. At the moment, the service module of the service module in the non-working state is shut down, and occupied resources of the service module are released to the service module of the service module in the working state, so that the speed of participating in flow processing can be accelerated, and the overall deployment time is shortened.
Preferably, in the flow detection step before deployment, the temporary database record number corresponding to the service application is obtained through the distributed transaction, whether the service module of the current service assembly is in a working state is judged, once the intermediate state flow is found, the current task is not completed, and the service module of the service assembly is closed after the flow treatment is completed.
Preferably, the specific process of detecting the module in the releasing process comprises the following steps: detecting after opening the flow of the service components forming the basic functions of the whole system, closing the flow if abnormality is detected, manually detecting again, rolling back to a pre-deployment state if abnormality still exists and cannot be eliminated, and checking all the established classified installation packages; when the external component services open the flow one by one, detecting the external component service when one external component service is opened, and opening the next external component service without abnormality; if the external component service is abnormal, manual detection is performed, and if the abnormality still exists and cannot be eliminated, the external component service is rolled back to a state before the external component service is deployed, and analysis and detection are performed on the classified installation package for deploying the external component service.
Preferably, in the automatic detection process, the detection tool is provided with a white list, after the abnormality is determined, the detection tool firstly analyzes whether the abnormality is negligible or not, and the detection tool ignores the tolerable error, so that the robustness of the system is improved, and the manual intervention time is reduced.
Preferably, in the manual detection link, the health status of each service is manually analyzed, and when a very specific abnormality exists in the health status analysis result of a certain service and the abnormality does not have any influence on the service, the abnormality is manually judged to be negligible, and the error rollback reporting process is not needed to be performed; when such an abnormal recurrence occurs, it is written into the white list of the detection tool, thereby enhancing the robustness of the system.
Preferably, after deployment is started, packaging a service module to be updated of an original system into temporary packages and placing the temporary packages into a temporary database, wherein each temporary package in the temporary database is provided with a time threshold formed based on a predicted installation time period, and when the expected response time accumulation in the temporary package does not reach the time threshold in the deployment process, the initial deployment sequence is maintained; when the expected response time accumulation in the temporary package exceeds a time threshold in the deployment process, actively triggering the detection of the update progress, and judging whether to continue updating or stop updating for rollback according to the detection result; and closing the time threshold count of the temporary package after the information which is verified to be correct by the corresponding service module reaches the temporary database until the time threshold count of all the temporary packages is closed, completing the deployment of the new system, and deleting all the temporary packages in the temporary database after the successful detection information is acquired.
Preferably, in the deployment process, when the external component services open the traffic one by one, the traffic which enters the system but is not opened corresponding to the external component services is also stored in the temporary database, the external component services corresponding to the traffic are counted, and the counted value is used for adjusting the deployment sequence of each service module. Thus, the flow in the temporary database is gradually processed after the complete deployment according to the first-in first-out principle; whereas for larger involved; traffic modules of traffic will be considered for preferential deployment.
The invention provides a flow control method in a private deployment scene, which mainly comprises the steps of completely cutting off all flow inlets, deploying a system, opening part of flow inlets, manually detecting and opening all flow inlets when various types of flow are zero during the operation of a detection system. Compared with the gray level deployment scheme of the Internet, the gray level deployment scheme has different problems to be solved, so the implementation thought is completely different. In the gray level deployment scheme, because massive actual user requests do not interrupt the system, once a new system code logic has a bug, user error data of an actual production environment is directly caused, if funds are involved, user funds are directly lost, and a plurality of dirty data in the system need to be manually intervened.
In the scheme, based on the service scene of private deployment, all flow inlets are completely cut off in advance, and whether the flow entering the system before closing the flow inlets is processed or not is detected in the scheme, so that no actual user request enters the system in the subsequent deployment process can be ensured, and the problem of resource loss caused by gray deployment of the Internet is effectively avoided.
And meanwhile, the flow inlet semi-opening and manual detection logic of the core service are adopted in the deployment process, and all flow inlets are opened after the manual detection is passed, so that the problem of user resource loss can be further avoided, and the robustness of private deployment is improved.
Compared with the prior art, the invention has the following advantages:
1. The system must be shut down prior to deployment, with a high degree of cleanliness. The method is convenient for identifying the connection relation of the business before and after the update, and the problem that part of the business is not lost in the deployment process, so that the request of the client cannot be responded correctly due to conflict with the update time is solved.
2. The dependency graph among the classified installation packages is established before deployment, so that the installation is not carried out according to the file packing sequence during deployment, but the installation sequence is set through the dependency graph among the classified installation packages, and the method has the advantage of being more flexible in deployment.
3. And after the traffic is closed, the traffic modules which are not involved in the traffic are gradually closed, so that the corresponding thread numbers are released, the processing speed of the working modules is accelerated, and the overall deployment time is shortened.
4. The business modules of the original system are packed into temporary packages and put into a temporary database and added with time thresholds formed based on the estimated installation time period. When unknown obstruction occurs in deployment, if abnormality cannot be removed in time, rollback is actively activated.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention.
Fig. 1 is a schematic diagram of the overall architecture of a flow control method in a private deployment scenario of the present invention.
Fig. 2 is a class-based installation package type common in a flow control method in a private deployment scenario of the present invention.
Fig. 3 is a dependency graph of a classified installation package commonly used in a flow control method in a private deployment scenario of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant content and not limiting of the present disclosure.
Since the present invention relates to a plurality of similar and different terminology in the field of computers, a one-to-one explanation is first provided herein:
external component service: to the functionality of the system itself for handling external tasks.
Component business module: to corresponding modules employed by the system itself when handling external tasks.
Regarding the deployment of software and the installation of software:
Deployment of software: refers to delivering software to a user or customer and making necessary configuration and adjustments to enable the software to meet the needs and expectations of the user. This process generally includes the steps of: determining a target environment, selecting an appropriate deployment mode, performing necessary configuration and adjustment, testing and verifying software.
And the software is installed: refers to the process of transferring software from a development environment to a target computer or device so that a user can use the software. This process generally includes the steps of: downloading a software installation package, running an installation program and completing installation according to the instruction of an installation guide.
The installation of software can be considered in the present invention as a step in the software deployment process.
Regarding deployment completion and deployment completion:
The deployment completion illustrates the end of the deployment process, indicating that the software has been successfully installed on the target computer or device.
After the deployment is finished, the completion of the deployment work is described, and the software can normally run and meet the requirements of users after being detected after being installed. Only then does the operation end, and the updated system is formally put into use.
Dependency graph of installation package: the method is used for reflecting the interrelationship of the installation packages and guiding the installation sequence of the installation packages.
Based on the above description, we take the global fund vault management system large version update deployment for a certain enterprise as an example to further describe a flow control method in a private deployment scenario related to the present invention.
As shown in fig. 1, the present embodiment includes the step of creating a classified installation package: and generating a dependency graph among the classified installation packages when the classified installation packages are established. Specifically, in the process, the service in the private deployment scene is divided into service component service forming the basic function of the whole system and external component service with the extended function, and the classified installation package is established based on a single service module. The deployment is divided into large version update deployment and patch version update deployment; in the large version updating deployment related to the embodiment, after the flow entering the system is processed, the closed service modules are required to be opened for secondary rechecking, and after the flow is confirmed to be processed, all the service modules are closed to start deployment. It should be noted that, in the updating process, not all service modules of the system need to be replaced, but only the service modules related to the current updating need to be replaced according to the dependency graph.
As shown in fig. 2 and 3, the dependency graph of the classified installation package is manually created, the deployment sequence of the classified installation package is planned according to the dependency graph of the classified installation package, the deployment time of a single classified installation package is estimated, after judging that the traffic inlet is closed, the time for processing the traffic is estimated when the traffic module related to the residual traffic is judged, the initial deployment time is proposed according to the estimated time, and the estimated deployment time of the classified installation package is combined, so that the estimated installation time period is finally obtained.
Flow control step before deployment: closing the system flow inlet.
When the whole system flow is required to be closed, the fully closed interface corresponding to the system service is triggered according to the following instructions:
Flow total switch of// system
action_0(SystemFlowState.full_close, ServiceType.gateway),
action_1(SystemFlowState.full_close, ServiceType.schedule),
action_2(SystemFlowState.full_close, ServiceType.openapi),
action_3(SystemFlowState.full_close, ServiceType.flowhub),
At this time, the full-closing interface is called for the 4 kinds of services involved, and at this time, all internal traffic processing modules in each service are in a closed state and cannot respond to any request.
And detecting the flow which enters the system before closing the flow inlet through global flow detection, and judging the service modules and the processing conditions related to the flow. The flow detection step specifically comprises the following steps: and analyzing the thread stack of each working thread through Java intermediate state flow, and judging whether each service module before deployment is in a working state or not by combining with the NIO network framework. For example:
Use jstack command to get thread stack information
jstack<pid>
# Analysis thread stack
# Recognition class and method related to NIO framework
# Judging thread current working state
# E.g., determine if the Netty thread is in read data state
if "SocketChannel.read()" in stack:
The # thread is in read data state
Sequentially closing service module of service module in non-working state so as to reduce number of threads and endow system resource to service module of service module in working state; and meanwhile, the number of the current unprocessed messages is obtained through the message queue, and the time required by the residual work is predicted according to the calculated power of the service module after the lifting. And acquiring the record number of the temporary database corresponding to the service application through the distributed transaction, judging whether the service module of the current service assembly is in a working state, and closing the service module of the service assembly after the flow processing is finished once the intermediate state flow is found, which indicates that the current task is not finished.
It should be further noted that the function of sequentially turning off service component business modules in a non-operating state, thereby reducing the number of threads is generally limited to large version update deployment. Because the flow monitoring between each module is additionally needed before the process is actually closed in the operation process, resources can be optimized only after the process is gradually closed. And would be uneconomical if used in a patch version update deployment.
In fact, in patch version update deployment, since the number of updated modules is usually small, only the ingress and egress traffic around the traffic module that needs to be updated is needed to achieve internal flow control after traffic is turned off.
Gradually closing service modules which are not involved in the flow, thereby releasing the corresponding thread number, accelerating the processing speed, and carrying out deployment of classified installation packages after the flow entering the system is processed;
the deployment completion step: after the whole system deployment is completed, the flow is opened to the service components forming the basic functions of the whole system, at this time, the gateway and the service start to receive the request, other modules still remain in a closed state without receiving any request, and the flow is in a semi-open state.
When the flow of the whole system needs to be half-opened, the half-opened interface of the corresponding service is triggered according to the following instructions:
Half-open flow rate of/(system)
action_4(SystemFlowState.half_open, ServiceType.flowhub), //
action_5(SystemFlowState.half_open, ServiceType.gateway), //
At this time, the system only opens the basic flow, the gateway and the service can receive the request, and other modules are closed before and do not accept any request at this time, so that the goal of half-open flow is achieved.
For example, in this state, the internal traffic processing module logic of the gateway is empty, so that when the request is half-open, the service can be provided to the outside as a whole, although the traffic is closed.
The internal traffic handling module logic of the timed task schedule is then responsible for implementing the on/off logic to determine whether the internal timed task generation traffic can be truly triggered.
At this time, it is necessary to detect the operation condition of the service component that opens the flow. The specific process of detecting the module in the releasing process comprises the following steps: after the flow is opened to the service components forming the basic functions of the whole system, detecting, if abnormality is detected, closing the flow, and manually detecting again.
Because the basic flow inlet is opened at this time, the system can be logged in manually in response to the complete service request, and whether the service functions are normal is verified, so that whether to continue to execute is determined.
If the abnormality still exists and cannot be eliminated, rolling back to a pre-deployment state, and checking all the established classified installation packages; when the external component services open the flow one by one, detecting the external component service when one external component service is opened, and opening the next external component service without abnormality; if there is an anomaly, then a manual check is made, and in more detail, we analyze the health status of each Java service, such as whether the business level is actually available, and whether the middleware is actually available for connection and use. If the abnormality still exists and cannot be eliminated, the external component service is rolled back to a state before being deployed, and the classified installation package for deploying the external component service is analyzed and detected.
After the service components forming the basic functions of the whole system normally run, the access rights of other modules are released one by one according to the data access requirements of the users who have made requests and the dependency graph of the classified installation packages, each module is detected in the releasing process, after all modules are released, the system enters a state of full flow opening,
When entering a state of full opening of the flow, triggering a full opening interface of the corresponding service according to the following instruction:
flow full on/system
action_6(SystemFlowState.full_open, ServiceType.gateway), //
action_7(SystemFlowState.full_open, ServiceType.schedule), //
action_8(SystemFlowState.full_open, ServiceType.openapi), //
action_9(SystemFlowState.full_open, ServiceType.flowhub), //
At this time, all functions of the system can be used, the goal of fully opening the flow of the system is achieved, and the deployment is completed.
In the automatic detection process, the detection tool is provided with a white list, and after the abnormality is judged, the detection tool firstly analyzes whether the abnormality is negligible or not, and the detection tool ignores tolerable errors, so that the robustness of the system is improved, and the manual intervention time is reduced. In the manual detection link, the health state of each service is manually analyzed, and when the health state analysis result of a certain service is found to have very specific abnormality and the abnormality has no influence on the service, the abnormality is manually judged to be negligible, and the error rollback reporting process is not needed to be performed; when such an abnormal recurrence occurs, it is written into the white list of the detection tool, thereby enhancing the robustness of the system.
Meanwhile, after deployment is started, packaging the business modules to be updated of the original system into temporary packages and placing the temporary packages into a temporary database, wherein each temporary package in the temporary database is provided with a time threshold formed based on a predicted installation time period, and when the expected response time accumulation in the temporary packages does not reach the time threshold in the deployment process, the initial deployment sequence is maintained; when the expected response time accumulation in the temporary package exceeds a time threshold in the deployment process, actively triggering the detection of the update progress, and judging whether to continue updating or stop updating for rollback according to the detection result; and closing the time threshold count of the temporary package after the information which is verified to be correct by the corresponding service module reaches the temporary database until the time threshold count of all the temporary packages is closed, completing the deployment of the new system, and deleting all the temporary packages in the temporary database after the successful detection information is acquired.
In actual operation, there are two scenarios that lead to rollback:
rollback during system traffic half-on:
The system flow state, full_close full closing interface of all modules is called at the moment because the system flow state, half_open half opening interface of all modules is called before.
Rollback in the process of half-switching to full-switching of system flow:
At this time, the following steps are required: system flow state. Full_close,
The systemflowstate.half_open interface places all services in a healthy half-on state.
In the deployment process, when the external component services open the traffic one by one, the traffic which enters the system but is not opened corresponding to the external component services is stored in a temporary database, the external component services corresponding to the traffic are counted, and the counted value is used for adjusting the deployment sequence of each service module.
Due to the adoption of the technical scheme, in large version update deployment in a financial system, the update time is not more than 30 minutes. Although at a slower rate than the most rapid update mode of the prior art. But during those deployments, data that remains in the system after the traffic is shut down is completely killed. The invention avoids the occurrence of disorder to a certain extent caused by the service connection before and after deployment.
The present invention, if it involves patch version update deployment, can typically be deployed within 6 minutes. Minimizing the time consuming deployment process.
While the application has been described in terms of preferred embodiments, it is not intended to limit the scope of the application. It is intended that all modifications within the scope of the application, i.e., all equivalents thereof, be embraced by the application as they come within their scope without departing from the application. In the description of the present specification, reference to the terms "one embodiment/manner," "some embodiments/manner," "example," "a particular example," "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment/manner or example is included in at least one embodiment/manner or example of the application. In this specification, the schematic representations of the above terms are not necessarily for the same embodiment/manner or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments/modes or examples. Furthermore, the various embodiments/modes or examples described in this specification and the features of the various embodiments/modes or examples can be combined and combined by persons skilled in the art without contradiction.
Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present application, the meaning of "plurality" means at least two, for example, two, three, etc., unless specifically defined otherwise.
It will be appreciated by those skilled in the art that the above-described embodiments are merely for clarity of illustration of the disclosure, and are not intended to limit the scope of the disclosure. Other variations or modifications will be apparent to persons skilled in the art from the foregoing disclosure, and such variations or modifications are intended to be within the scope of the present disclosure.
Claims (8)
1. The flow control method in the private deployment scene is characterized by comprising the steps of establishing a classified installation package: generating a dependency graph between the classified installation packages when the classified installation packages are established; flow control step before deployment: closing a system flow inlet, detecting the flow which enters the system before closing the flow inlet through global flow detection, and judging service modules and processing conditions related to the flow; gradually closing service modules which are not involved in the flow, thereby releasing the corresponding thread number, accelerating the processing speed, and carrying out deployment of classified installation packages after the flow entering the system is processed;
the flow detection step after the flow is closed specifically comprises the following steps: analyzing thread stacks of all working threads through Java intermediate state flow, judging whether each service component service module before deployment is in a working state by combining with an NIO network frame, sequentially closing the service component service modules in a non-working state, and endowing system resources to the service component service modules in the working state; meanwhile, the number of the current unprocessed messages is obtained through the message queue, and the time required by the rest work is predicted according to the calculated power of the service module after the lifting;
in the flow detection step before deployment, the temporary database record number corresponding to the service application is obtained through the distributed transaction, whether the current service module is in a working state is judged, once the intermediate state flow is found, the current task is not completed, and the service module is closed after the flow treatment is completed;
The deployment completion step: after the whole system deployment is completed, firstly opening the flow of service components forming the basic functions of the whole system, at the moment, the gateway and the service start to receive the request, other modules still remain in a closed state and do not receive any request, and enter a semi-open state of the flow; detecting the working condition of a service component for opening the flow; after the normal operation of the service components forming the basic functions of the whole system is determined, the access rights of other modules are released one by one according to the data access requirements of the users who have made requests and the dependency graph of the classified installation packages, each module is detected in the releasing process, and after all modules are released, the system enters a state with fully opened flow, and the deployment is completed.
2. The method for flow control in a private deployment scenario according to claim 1, wherein the deployment is divided into a large version update deployment and a patch version update deployment; in the large version updating deployment, after the flow entering the system is processed, the closed service modules are required to be opened for secondary review, and after the flow is confirmed to be processed, all the service modules are closed to start deployment.
3. The flow control method in a private deployment scenario according to claim 1, wherein the traffic in the private deployment scenario is divided into service component traffic forming a basic function of an overall system and external component traffic with an extended function, a classification installation package is established based on a single traffic module, a dependency graph of the classification installation package is manually created, a deployment sequence of the classification installation package is planned according to the dependency graph of the classification installation package, and deployment time of the single classification installation package is estimated; after judging to close the flow inlet, predicting the time for processing the flow when the service module related to the residual flow is judged, and providing the initial time for deployment according to the estimated time, and finally obtaining the estimated installation time period by combining the estimated deployment time of the classified installation package.
4. The method for controlling flow in a private deployment scenario according to claim 1, wherein the specific process of detecting the module during the release process includes: detecting after opening the flow of the service components forming the basic functions of the whole system, closing the flow if abnormality is detected, manually detecting again, rolling back to a pre-deployment state if abnormality still exists and cannot be eliminated, and checking all the established classified installation packages; when the external component services open the flow one by one, detecting the external component service when one external component service is opened, and opening the next external component service without abnormality; if the external component service is abnormal, manual detection is performed, and if the abnormality still exists and cannot be eliminated, the external component service is rolled back to a state before the external component service is deployed, and analysis and detection are performed on the classified installation package for deploying the external component service.
5. The method of claim 4, wherein in the automatic detection process, the detection tool has a white list, and after determining the anomaly, the detection tool first analyzes whether the anomaly is negligible, and the detection tool ignores the tolerable error.
6. The method for controlling flow in private deployment scenario as claimed in claim 5, wherein in the step of manual detection, the health status of each service is manually determined, and when a very specific abnormality is found in the health status analysis result of a certain service, and the abnormality does not have any influence on the service itself, the abnormality is manually determined to be negligible, and the flow of reporting error rollback is not performed; when such an abnormal recurrence occurs, it is written into the white list of the detection tool.
7. The method for controlling flow in private deployment scenario according to claim 5 or 6, wherein after deployment is started, the service modules to be updated of the original system are packaged into temporary packages and put into a temporary database, each temporary package in the temporary database has a time threshold formed based on the estimated installation time period, and when the expected response time accumulation in the temporary package in the deployment process does not reach the time threshold, the initial deployment sequence is maintained; when the expected response time accumulation in the temporary package exceeds a time threshold in the deployment process, actively triggering the detection of the update progress, and judging whether to continue updating or stop updating for rollback according to the detection result; and closing the time threshold count of the temporary package after the corresponding service module verifies that the error-free information reaches the temporary database until the time threshold count of all the temporary packages is closed, completing the deployment of the new system, and deleting all the temporary packages in the temporary database after the successful detection information is acquired.
8. The method for controlling traffic in a private deployment scenario according to claim 7, wherein, in the deployment process, when the external component services open traffic one by one, traffic which enters the system but is not yet opened corresponding to the external component services is also stored in the temporary database, and the external component services corresponding to the traffic are counted, and the obtained count value is used for adjusting the deployment sequence of each service module.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410450750.2A CN118054974B (en) | 2024-04-15 | 2024-04-15 | Flow control method in private deployment scene |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410450750.2A CN118054974B (en) | 2024-04-15 | 2024-04-15 | Flow control method in private deployment scene |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN118054974A CN118054974A (en) | 2024-05-17 |
| CN118054974B true CN118054974B (en) | 2024-07-12 |
Family
ID=91046932
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410450750.2A Active CN118054974B (en) | 2024-04-15 | 2024-04-15 | Flow control method in private deployment scene |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118054974B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778491A (en) * | 2021-09-16 | 2021-12-10 | 山东亿云信息技术有限公司 | A containerized application grayscale upgrade method, system, storage medium and device |
| CN115378809A (en) * | 2022-08-18 | 2022-11-22 | 中国建设银行股份有限公司 | Software version upgrading method and device |
| CN116800755A (en) * | 2023-06-26 | 2023-09-22 | 中国电子科技集团公司第十五研究所 | Multi-form software delivery device and method based on Kubernetes and computer readable storage medium |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7043759B2 (en) * | 2000-09-07 | 2006-05-09 | Mazu Networks, Inc. | Architecture to thwart denial of service attacks |
| US11405969B2 (en) * | 2010-09-29 | 2022-08-02 | International Business Machines Corporation | Enabling interface aggregation of mobile broadband network interfaces |
| CN104580702A (en) * | 2014-12-19 | 2015-04-29 | 龙凤娇 | Method and device for preventing traffic escape of mobile phone |
| US11277426B1 (en) * | 2019-09-13 | 2022-03-15 | Rapid7, Inc. | Anomalous asset detection based on open ports |
| US12200014B2 (en) * | 2020-02-03 | 2025-01-14 | Purdue Research Foundation | Lifelong learning based intelligent, diverse, agile, and robust system for network attack detection |
| KR20220029142A (en) * | 2020-09-01 | 2022-03-08 | 아토리서치(주) | Sdn controller server and method for analysing sdn based network traffic usage thereof |
| CN112257034A (en) * | 2020-10-30 | 2021-01-22 | 北京华维国创电子科技有限公司 | Encryption and authorization algorithm and management system for chip mounter |
| CN112446714A (en) * | 2020-12-11 | 2021-03-05 | 上海中通吉网络技术有限公司 | Server upgrading method, device and equipment for express after-sale work order processing system |
| CN116737436A (en) * | 2023-05-17 | 2023-09-12 | 武汉大学 | Microservice system root cause location method and system for hybrid deployment scenarios |
| CN117851257A (en) * | 2024-01-11 | 2024-04-09 | 南京师范大学常州创新发展研究院 | Distributed software testing environment construction system based on cloud computing |
-
2024
- 2024-04-15 CN CN202410450750.2A patent/CN118054974B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778491A (en) * | 2021-09-16 | 2021-12-10 | 山东亿云信息技术有限公司 | A containerized application grayscale upgrade method, system, storage medium and device |
| CN115378809A (en) * | 2022-08-18 | 2022-11-22 | 中国建设银行股份有限公司 | Software version upgrading method and device |
| CN116800755A (en) * | 2023-06-26 | 2023-09-22 | 中国电子科技集团公司第十五研究所 | Multi-form software delivery device and method based on Kubernetes and computer readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN118054974A (en) | 2024-05-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8850587B2 (en) | Network security scanner for enterprise protection | |
| US10585659B2 (en) | Enabling tenant administrators to initiate request driven peak-hour builds to override off-peak patching schedules | |
| US10824521B2 (en) | Generating predictive diagnostics via package update manager | |
| US9485151B2 (en) | Centralized system management on endpoints of a distributed data processing system | |
| US20140068326A1 (en) | Systems and Methods for Automated Memory and Thread Execution Anomaly Detection in a Computer Network | |
| US20110214021A1 (en) | Systems and methods for initiating software repairs in conjunction with software package updates | |
| US9158606B2 (en) | Failure repetition avoidance in data processing | |
| US9116802B2 (en) | Diagnostic notification via package update manager | |
| JP2019527877A (en) | Automatic distribution of PLC virtual patches and security context | |
| TW200405202A (en) | Method and apparatus for automatic updating and testing of software | |
| US8954949B2 (en) | Smart patch delivery system | |
| CN112925648B (en) | Business strategy issuing method and device | |
| CA3129985A1 (en) | Abnormal operation environment restoration method and device, computer equipment and storage medium | |
| US7246276B2 (en) | Error tolerant modular testing of services | |
| CN118626138A (en) | A method for deploying an application | |
| CN119718385B (en) | Operating system updating method, electronic device, storage medium and program product | |
| CN118054974B (en) | Flow control method in private deployment scene | |
| CN111722853A (en) | A method and device for installation script deployment | |
| US9684586B2 (en) | System test compliance tool | |
| US20250094167A1 (en) | Auto Healing of Runtime Exceptions using Intelligent Building System and Generative AI | |
| US20240211323A1 (en) | Automatically injecting shims into running containers | |
| CN114328067B (en) | Terminal equipment maintenance method and system based on domestic CPU and operating system | |
| Heegaard et al. | Survivability as a generalization of recovery | |
| US20240419439A1 (en) | Automated software validation for continuous deployment in an information processing system | |
| CN119603299B (en) | Method, device, equipment and medium for cross-cloud resource operation based on task orchestration |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |