Service traffic migration method, computer equipment, medium and program product

Abstract

The invention relates to the technical field of data processing, in particular to a service flow migration method, computer equipment for implementing the method, a computer readable storage medium and a computer program product. The method comprises the following steps: analyzing an application migration demand of a user to determine configuration information and a type of an application system to be migrated; on the basis of the configuration information, determining a calling relationship among the micro-services in the application system; based on the calling relation, determining an optimal migration path of each micro-service according to the time consumption index; based on the optimal migration path and type, generating a service flow migration scheme comprising a migration sequence and a flow distribution strategy of each micro-service; and gradually importing the business traffic according to the business traffic migration scheme so as to realize smooth migration of each micro-service from the virtual machine to the containerized service in the application system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and more particularly to a business traffic migration method, a computer device implementing the method, a computer readable storage medium and a computer program product. BACKGROUND

[0002] In today's era of increasing popularity of cloud computing and microservice architecture, how to safely and smoothly migrate existing application systems from traditional virtual machine environments to containerized platforms has become an important challenge for many enterprises. Traditional application migration methods often rely on manual operations, which are tedious, time-consuming and prone to errors. For example, manually analyzing the dependency relationships, configuration information of the application system, and adjusting the service configuration one by one, not only is inefficient, but also is difficult to cope with complex application scenarios, which can easily lead to service interruption or performance degradation. In addition, the traditional method lacks automation and intelligent means, and is difficult to dynamically adjust according to the actual running state and resource demand of the application system, resulting in resource waste or service bottlenecks.

[0003] To address the above problems, some migration tools have emerged in the industry, but these tools mostly focus on infrastructure-level migration, such as virtual machine image conversion, network configuration migration, etc., and ignore the characteristics of the application system itself and the smooth transition of business traffic. Existing solutions often use a one-size-fits-all migration strategy, migrating all services to the containerized platform at once, which can easily lead to business interruption or performance jitter. In addition, these tools lack intelligent analysis capabilities for application systems and dependency relationships, making it difficult to choose the right migration strategy, which can easily lead to migration failure or resource waste.

[0004] It is to be noted that the information disclosed in the above BACKGROUND section is only used to strengthen the understanding of the background of the present application, and therefore can include information that does not constitute prior art known to those of ordinary skill in the art. SUMMARY

[0005] To solve or at least alleviate one or more of the above problems, embodiments of the present application provide a business traffic migration method, a computer device implementing the method, a computer readable storage medium and a computer program product, which can reduce the risk and cost of manual operation, ensure the continuity and stability of business, and achieve smooth migration of application systems from virtual machines to containerized services.

[0006] According to a first aspect of the present application, a service traffic migration method is provided, which comprises the following steps: analyzing application migration requirements of a user to determine configuration information and a type of an application system to be migrated; determining a calling relationship between microservices in the application system based on the configuration information; determining an optimal migration path of each microservice according to a time consumption index based on the calling relationship; generating a service traffic migration scheme including a migration sequence of each microservice and a traffic distribution strategy based on the optimal migration path and the type; and gradually importing service traffic according to the service traffic migration scheme to realize smooth migration of each microservice in the application system from a virtual machine to a containerized service.

[0007] As an alternative or supplement to the above scheme, the service traffic migration method according to an embodiment of the present application further comprises: splitting the application system into a plurality of independent, containerizable deployment microservices; constructing a container image for each microservice to ensure that each microservice and its dependencies are encapsulated in a respective container; uploading the constructed container image to a container image repository; and generating a container orchestration description file for describing the deployment mode and dependency relationship of each microservice.

[0008] As an alternative or supplement to the above scheme, in the service traffic migration method according to an embodiment of the present application, analyzing the application migration requirements of the user comprises: using natural language processing technology to analyze the application migration requirements input by the user to determine an identity of the application system to be migrated and a user intention.

[0009] As an alternative or supplement to the above scheme, in the service traffic migration method according to an embodiment of the present application, analyzing the application migration requirements of the user further comprises: based on the identity of the application system, obtaining configuration information of the application system from a configuration management database, the configuration information including one or more of the following: a number of centers of the application system, a deployment topology, module information, a number of containers, synchronous and asynchronous calling information; and determining the type of the application system based on the configuration information.

[0010] As an alternative or supplement to the above scheme, in the service traffic migration method according to an embodiment of the present application, the type of the application system includes: a single-center pure backend system, a single-center non-pure backend system, a multi-center pure backend system, and a multi-center non-pure backend system.

[0011] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, determining the calling relationship between each microservice in the application system based on the configuration information comprises: querying the calling chain data related to the application system from a calling chain tracking system, the calling chain data comprising request identification, service name, calling time and time consumption information; and constructing a calling chain relationship graph describing the calling relationship between microservices based on the calling chain data, wherein a node represents a microservice and an edge represents a calling relationship.

[0012] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, determining the optimal migration path of each microservice according to the time consumption index based on the calling relationship comprises: taking each most upstream microservice in the calling chain relationship graph as a starting point, traversing the downstream microservices thereof, and searching for all reachable calling paths; calculating the time consumption of each reachable calling path in the traversal process; and selecting the path with the shortest total time consumption from all reachable calling paths as the optimal migration path.

[0013] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, calculating the time consumption of each reachable calling path comprises:

[0014] The time consumption in a time slice period is smoothed by using a sliding window algorithm, wherein the sliding average time consumption duration t is determined by the following formula:

[0015] duration t =α·duration t-1 +(1-α)·duration

[0016] wherein duration is the sampling time consumption of the current time slice period, duration t-1 is the sliding average time consumption of the previous time slice period, and a is a smoothing factor.

[0017] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, generating a service traffic migration scheme comprising the migration order of each microservice and the traffic allocation strategy based on the optimal migration path and the type comprises: determining the migration order of each microservice according to the optimal migration path; and determining the corresponding traffic allocation strategy according to the type of the application system.

[0018] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, determining the corresponding traffic distribution strategy according to the type of the application system comprises: if the application system is a single-center pure backend system or a multi-center pure backend system, the determined traffic distribution strategy comprises: gradually increasing the traffic proportion of the containerized service and gradually reducing the traffic proportion of the virtual machine service to realize traffic migration between internal services.

[0019] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, for microservices based on a registration discovery mechanism, the gradual reduction of the traffic proportion of the virtual machine service is realized by adjusting the service weight of the service registry; and for microservices using a service mesh architecture, the gradual reduction of the traffic proportion of the virtual machine service is realized by gradually removing the isolation of the microservice module.

[0020] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, determining the corresponding traffic distribution strategy according to the type of the application system comprises: if the application system is a single-center non-pure backend system or a multi-center non-pure backend system, the determined traffic distribution strategy comprises: first, gradually increasing the traffic proportion of the containerized service and gradually reducing the traffic proportion of the virtual machine service to realize traffic migration between internal services, and then gradually adjusting the configuration of the entry traffic management component to realize entry-side traffic migration.

[0021] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, determining the corresponding traffic distribution strategy further comprises: during the traffic migration process, acquiring system performance indicators and user experience indicators at a predetermined frequency, and triggering a rollback strategy when the indicators are abnormal, so as to restore to the state before migration within a predetermined time.

[0022] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, gradually introducing service traffic according to the service traffic migration scheme comprises: during the process of gradually introducing service traffic, first, a small traffic proportion is used for exploratory migration, and after confirming that the system is running stably, the traffic proportion of the service is gradually increased.

[0023] As an alternative or supplement to the above solution, in the service traffic migration method according to an embodiment of the present application, the determination of the configuration information and type, the determination of the calling relationship, and the determination of the optimal migration path are all realized by corresponding intelligent agents.

[0024] According to a second aspect of the present application, there is provided a computer device comprising: a memory; a processor; and a computer program stored on the memory and executable on the processor, execution of the computer program causing any one of the service traffic migration methods according to the first aspect of the present application to be performed.

[0025] According to a third aspect of the present application, there is provided a computer-readable storage medium comprising instructions which, when executed, perform any one of the service traffic migration methods according to the first aspect of the present application.

[0026] According to a fourth aspect of the present application, there is provided a computer program product comprising a computer program which, when executed by a processor, implements any one of the service traffic migration methods according to the first aspect of the present application.

[0027] The service traffic migration scheme according to one or more embodiments of the present application overcomes many drawbacks of conventional application system migration schemes, and realizes automatic, intelligent and smooth migration from virtual machines to containerized services. Specifically, the scheme first analyzes the user's application migration requirements to provide accurate basic data for subsequent migration decisions; secondly, through intelligent analysis of the calling relationship between each microservice in the application system, combined with time-consuming indicators, the optimal migration path is planned to ensure that the impact on the business is minimized during the migration process; more importantly, the scheme can intelligently generate a corresponding service traffic migration scheme according to the type of the application system, including the migration order of each microservice and the traffic allocation strategy, thereby realizing fine-grained traffic control. BRIEF DESCRIPTION OF DRAWINGS

[0028] The above and / or other aspects and advantages of the present application will become more apparent and more readily appreciated from the following description of various aspects of the present application, taken in conjunction with the accompanying drawings in which like reference numerals refer to like elements throughout. In the drawings:

[0029] Figure 1 is a schematic block diagram of a microservice application architecture according to one or more embodiments of the present application;

[0030] Figure 2 is a schematic flowchart of a service traffic migration method 20 according to one or more embodiments of the present application;

[0031] Figure 3 is a schematic diagram of a generated service traffic migration scheme according to one embodiment of the present application;

[0032] Figure 4 is a schematic block diagram of a computer device 40 according to one or more embodiments of the present application. DETAILED DESCRIPTION

[0033] The following detailed description is merely exemplary in nature and is not intended to limit the disclosed technology or the application and uses of the disclosed technology. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background or the following detailed description.

[0034] In the following detailed description of embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it will be apparent to one of ordinary skill in the art having the benefit of this disclosure that the technology disclosed can be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0035] The terms such as "comprising" and "including" represent that the technical solutions of the present application do not exclude other units and steps having no direct and explicit representation in the specification. The terms such as "first" and "second" do not represent the order of units in time, space, size, etc., but only distinguish the units.

[0036] Hereinafter, the exemplary embodiments according to the present application will be described in detail with reference to the accompanying drawings.

[0037] First of all, it needs to be pointed out that the business traffic migration method provided by the present application can be widely applied to various scenarios where the application system needs to be migrated from a virtual machine environment to a containerized environment, and is especially suitable for industries such as finance, e-commerce, and government affairs, which have extremely high requirements for system stability and business continuity. Specifically, for example, a credit card business system of a certain bank, which was deployed on a physical server using a traditional monolithic architecture in the early stage, gradually evolved into a complex microservice architecture and was gradually migrated to a virtual machine environment as the business rapidly developed. However, as the business scale continues to grow, the resource utilization rate of the virtual machine environment gradually decreases, and the operation and maintenance cost also increases day by day. In order to improve resource utilization, reduce operation and maintenance cost, and realize elastic scaling, the bank plans to migrate the credit card business system to a Kubernetes container cloud platform. Since the credit card business system has a huge transaction volume and involves a large number of payment and settlement operations, any service interruption or performance degradation may cause serious economic losses and reputation risks. Therefore, by using the business traffic migration method provided in the embodiments of the present application, the continuity and stability of the credit card business during the migration process can be ensured, and the negative impact on user experience and business income can be avoided.

[0038] Secondly, it needs to be explained that the business traffic migration method provided by the application is used to migrate the application system from the virtual machine environment to the containerized environment, so the application system to be migrated should have been deployed as a microservice architecture. With the rapid development of Internet technology and cloud computing technology, more and more enterprises choose to build their own services based on cloud platforms and provide services in the form of Web or mobile application APP. With the growth of the user scale, in order to cope with the demand of high concurrency and low delay, more and more applications use distributed microservices to deploy to meet the growing business needs. Microservice architecture is a design method that uses individual small services to build applications. By dividing business functions, it ensures that individual service functions are highly cohesive and loosely coupled between multiple services. With microservice architecture, each module is relatively independent and decoupled, making it very convenient to implement horizontal scaling and deployment of modules, thereby improving the scalability and availability of the system.

[0039] Reference will now be made to the drawings, Figure 1 is a schematic block diagram of a microservice application architecture according to one or more embodiments of the present application. The architecture mainly includes an access layer, an application layer and a data layer. The request is initially received by the access layer, which is responsible for functions such as access, authentication, authorization and routing of user requests, and forwards the request to the service layer; the service layer can be composed of multiple microservices, each of which constitutes an independent functional unit, and the processing of the request is completed through the collaborative call between them; the data layer includes databases and caches, which interact with part of the service layer to complete the read and write operations of data.

[0040] As mentioned earlier, each application under the microservice architecture is independently deployed, and there may be different requirements for the deployment environment, and the application layer also has the demand for unified management of a large number of microservice modules. In this context, containerization technology based on Kubernetes can be widely used in microservice architecture. Docker container is a lightweight virtualization technology built on the operating system, providing a lightweight, independent (isolation), portable runtime environment. Docker container contains all the resources needed to run a certain software, including code, runtime environment, library, environment variable and configuration file, etc. Therefore, Docker container is like a lightweight, portable "software packaging box", which can package the application and its runtime environment together, so that the application running is no longer limited to a specific system and environment. Docker container provides the following advantages for microservices:

[0041] 1) Environment isolation and consistency: Docker provides environment isolation through container technology, ensuring that each microservice runs in a completely independent environment and does not interfere with each other. This avoids application failures caused by environment differences and improves system stability.

[0042] 2) Fast deployment and scaling: Docker containers can be quickly started and stopped, which is very helpful for fast deployment and automatic scaling in microservices architecture. With simple commands, a new microservice instance can be quickly deployed and added to the cluster, achieving fast scaling.

[0043] 3) Continuous Integration and Continuous Deployment (CI / CD): Using Docker, it is easier to implement automated build, test and deployment processes. Through Docker images, developers can ensure that the same application environment is deployed every time, which is crucial for implementing continuous integration and continuous deployment.

[0044] 4) Service governance and monitoring: Docker containers can be managed by orchestration tools such as Kubernetes, which provide functions such as service discovery, load balancing, health checks, etc., which are very suitable for the management and monitoring of microservices architecture.

[0045] Docker and microservices architecture together provide strong support for software development. By breaking down applications into small, independent services and packaging and deploying them through Docker containers, highly scalable, easy-to-manage and maintain application systems can be built. This combination greatly improves development efficiency and system stability.

[0046] In one or more embodiments of the present application, the application system to be migrated can be transformed into a container-based microservices architecture by the following means: first, the application system is divided into multiple independent, container-deployable microservices, ensuring that each microservice has a clear responsibility and relatively independent business logic; build a container image for each microservice, ensuring that each microservice and its dependencies are encapsulated in their respective containers. Container images are lightweight, portable software packages that contain all files, libraries and configuration information for microservices and their dependencies. By encapsulating microservices and their dependencies in container images, environment consistency and portability can be achieved, avoiding application failures caused by environment differences; then, upload the built container images to a container image repository such as Docker Hub; finally, generate container orchestration description files that describe the deployment method and dependency relationship of each microservice. These description files define the number of replicas, resource limits, network configuration, health checks, etc. of microservices, and are used to guide the container orchestration engine to automatically deploy and manage microservices.

[0047] After completing the microservices deployment and containerization of the application system, the core process of business traffic migration will follow. Figure 2A schematic flowchart of a service traffic migration method 20 according to one or more embodiments of the present application. The method 20 details how to gradually and smoothly migrate service traffic from the original virtual machine environment to the containerized environment, thereby realizing the overall migration of the application system.

[0048] As shown in FIG. 2, in step 201, the user's application migration requirements are analyzed to determine the configuration information and type of the application system to be migrated. Figure 2

[0049] Step 201 aims to clarify the overall situation of the application system to be migrated, laying the foundation for the subsequent formulation of migration strategies. The core of this step is to extract key information, including the configuration information and type of the application system. The configuration information can cover multiple aspects such as deployment architecture, resource allocation, dependency relationship, etc. of the application system. The type of the application system is used to distinguish different migration scenarios, and different application system types may require different migration strategies. Accurate analysis of user requirements can avoid deviations in subsequent steps and ensure the smooth progress of the migration process.

[0050] In order to realize automation and intelligentization, some embodiments of the present application use natural language processing (NLP) technology to analyze the user's input application migration requirements. Users can describe their migration requirements in natural language, such as "migrate the order management system to the Kubernetes cluster", and then the NLP module automatically identifies the application system to be migrated (such as the order management system) and the user's intention (such as migrating to the Kubernetes cluster). The NLP module can first perform preprocessing operations such as word segmentation, part-of-speech tagging, and syntax analysis on the user input, and then based on a pre-trained model, identify key entities and relationships such as application system identification, user intention, target platform, etc. Through NLP technology, the use threshold of users can be reduced, the interaction efficiency can be improved, and support can be provided for the subsequent automated migration process.

[0051] ​In one or more embodiments of the present application, after identifying the application system identifier based on the NLP technology, detailed configuration information of the application system can be obtained from a configuration management database (CMDB). The CMDB is a database that centrally stores and manages IT infrastructure configuration information, covering various aspects such as deployment architecture, resource allocation, dependency relationship, etc. of the application system, for example, the number of centers of the application system, deployment topology, module information, container quantity, and synchronous and asynchronous call information, etc. Among them, the number of centers of the application system determines whether it is single-center deployment or multi-center deployment, the deployment topology affects the calling relationship between services, the module information provides the division of internal modules of the application, the container quantity refers to the number of container replicas (i.e. the number of container PODs) of a single module, and the synchronous and asynchronous call information affects resource planning and traffic scheduling. By querying the CMDB, the current situation of the application system can be comprehensively understood, providing a basis for the subsequent formulation of migration strategies.

[0052] Further, the type of the application system can also be automatically identified based on the configuration information obtained from the CMDB. In embodiments of the present application, the types of the application system include but are not limited to: single-center pure backend system, single-center non-pure backend system, multi-center pure backend system, and multi-center non-pure backend system. The division of these types is mainly based on the number of centers of the application system, the deployment topology, and the business nature. The type of the application system determines the selection of the subsequent migration strategy. For example, some types of application systems only involve backend traffic, while some other types of application systems also involve entry traffic. Since the migration of internal service traffic and the migration of external user access traffic are fundamentally different in strategy, different migration strategies should be adapted for different types of application systems. By accurately identifying the type of the application system, a suitable migration strategy can be ensured, thereby improving the success rate and efficiency of migration.

[0053] In step 203, based on the configuration information, the calling relationship between the microservices in the application system is determined.

[0054] The calling relationship reveals the dependency between services, and therefore is the cornerstone of building a stable and efficient migration strategy. Traditional application migration methods often rely on static configuration information, such as service registry or API documentation, to infer the dependency relationship between services. However, these static information often fails to reflect the actual runtime calling situation, which can easily lead to unexpected problems during the migration process. For example, some services may have hidden dependencies, or the calling relationship between some services may be outdated. If these actual calling relationships are ignored during the migration process, it may cause service interruption, performance degradation, or even migration failure. Therefore, accurately identifying the calling relationship between microservices is a key prerequisite for business traffic migration.

[0055] In one or more embodiments of the present application, first, the application system related call chain data is queried from the call chain tracking system. The call chain tracking system is a tool for monitoring and analyzing the service call relationship in a distributed system, which can record the call path, service name, call time and time-consuming information of each request and other key data. The MCP (Microservice Call Platform) service as a platform specially used for collecting and analyzing microservice call chain data can provide more comprehensive and accurate call chain information. Through the call chain tracking system, especially the MCP service, the actual call relationship between each microservice in the application system can be obtained, not just the static configuration information.

[0056] After obtaining the call chain data, based on these data, a call chain relationship graph describing the call relationship between microservices can be constructed. The call chain relationship graph is a graphical representation for visualizing the call relationship between microservices, where nodes represent microservices and edges represent call relationships. Through the call chain relationship graph, the dependency relationship between services can be more intuitively understood, so as to better formulate the migration strategy. Illustratively, the process of constructing the call chain relationship graph usually includes the following steps: cleaning the original data obtained from the call chain tracking system, filtering out invalid data and duplicate data; extracting the call relationship between microservices from the cleaned data, such as service A calling service B; creating a node for each microservice and adding the node to the graph; creating an edge for each call relationship and adding the edge to the graph; optimizing the relationship graph, such as merging duplicate edges, deleting isolated nodes, etc.

[0057] In step 205, based on the call relationship, the optimal migration path of each microservice is determined according to the time-consuming index.

[0058] Under the microservice architecture, there are complex dependency relationships between each microservice, and the order of service migration will directly affect the stability and performance of the entire application system. Therefore, the "migration path" refers to a strategic solution for guiding microservice migration, which defines the specific migration order of migrating the application system from a virtual machine environment to a containerized environment. An inappropriate migration path may cause service dependency interruption, performance bottlenecks or migration failure, etc. To this end, the optimal migration path aims to find a migration solution that can shorten the migration time and reduce the migration risk as much as possible while ensuring business stability. It should be noted that traditional migration methods often use random or fixed migration order, and such methods lack consideration of the dependency relationship between services, which can easily lead to dependency conflicts, performance bottlenecks and other problems during the migration process, thereby affecting the normal operation of the business. Therefore, determining the optimal migration path is a key step to achieve smooth migration.

[0059] In one or more embodiments of the present application, the optimal migration path can be determined in the following manner. First, starting from each most upstream microservice in the call chain graph, traverse its downstream microservices to search for all reachable call paths. The most upstream microservice refers to a microservice without upstream dependencies, i.e., the entry service of the request. Starting from the most upstream microservice for traversal ensures that in the migration process, services without dependencies are migrated first, and services with dependencies are migrated later, thereby avoiding service interruption due to un-migrated dependent services. During the traversal process, all reachable call paths need to be recorded for subsequent calculation of the time consumption of each path.

[0060] During the traversal process, the embodiments of the present application calculate the time consumption of each reachable call path. Time consumption refers to the time taken from the entry service of the request to the exit service, which can reflect the performance and efficiency of the service. The method of calculating time consumption can use simple addition calculation, or more complex models, such as considering network delay, CPU load, etc.

[0061] In particular, synchronous / asynchronous call patterns have a significant impact on the calculation of the time consumption of the migration path. The characteristic of synchronous call is that the upstream microservice does not process until the downstream microservice processing is completed and a response is given. The characteristic of asynchronous call is that when the upstream microservice calls the downstream microservice, it does not wait for the downstream microservice to complete execution and return, and the upstream microservice continues to execute. Asynchronous calling microservices are usually used to complete data writing, log reporting, and other business logic unrelated to user response logic. Since the downstream microservice of asynchronous call does not block the running of the upstream microservice, asynchronous call does not cause the increase of the end-to-end response time of the user, and the asynchronous calling microservice does not participate in the time consumption calculation of the migration path. Therefore, when determining the migration path, the calling mode between services needs to be fully considered.

[0062] Further, to improve the accuracy of time consumption calculation, some embodiments of the present application use a sliding window algorithm to smooth the time consumption in a time slice period. The sliding window algorithm is a time series data processing method that can effectively eliminate noise and outliers, thereby improving the stationarity and reliability of the data. Specifically, the sliding average time consumption of the current time slice period can be calculated using the following formula:

[0063] duration t =α·duration t-1 +(1-α)·duration

[0064] wherein duration is the sampling time consumption of the current time slice period, duration t-1The sliding average time for the previous time slice period is the time consumption, and the smoothing factor a is used to control the degree of smoothing. The value of the smoothing factor a ranges from 0 to 1. The greater the value of a, the more obvious the smoothing effect, but the lower the sensitivity to data; the smaller the value of a, the less obvious the smoothing effect, but the higher the sensitivity to data. According to actual conditions, a suitable value of a can be selected to achieve the best smoothing effect. For example, for services with large fluctuations in time consumption, a larger value of a can be preset to reduce the impact of noise; for services with small fluctuations in time consumption, a smaller value of a can be preset to improve the sensitivity to data.

[0065] Finally, the optimal migration path can be selected from all reachable call paths as the path with the shortest total time consumption. The path with the shortest total time consumption usually means that the impact on the service during the migration process is the smallest, and the continuity and stability of the service can be maximized. This is because the path with the shortest time consumption usually means that the dependency relationship between services is more reasonable, and the probability of dependency conflicts during the migration process is lower. By selecting the optimal migration path, the embodiments of the present application can realize a smoother and more efficient migration process, reduce the migration risk, and ensure the continuity and stability of the service.

[0066] In order to realize the automation and intelligentization of the migration process, the determination of the configuration information and the type (step 201), the determination of the call relationship (step 203), and the determination of the optimal migration path (step 205) in the embodiments of the present application can be realized by the corresponding agents. An agent is an entity that can perceive the environment, make decisions, and take actions to achieve a specific goal. By using agents, the complexity of manual operation can be reduced, the migration efficiency can be improved, and the migration strategy can be dynamically adjusted according to actual conditions, thereby improving the flexibility and reliability of the migration. For example, the configuration analysis agent responsible for determining the configuration information and the type can automatically obtain the relevant information of the application system from the configuration management system such as CMDB, and classify the type of the application system according to the information, thereby providing a basis for subsequent migration strategy formulation. The call chain analysis agent responsible for determining the call relationship can automatically analyze the call chain data of the application system, identify the dependency relationship between services, and thereby provide support for determining the optimal migration path. The migration trajectory calculation agent responsible for determining the optimal migration path can automatically calculate the optimal migration path according to the dependency relationship between services and performance indicators, thereby ensuring the smoothness and efficiency of the migration process.

[0067] Further, some embodiments of the present application also introduce a multi-source collaborative analysis core agent. As a unified decision center, the agent can obtain specific information of the target application system, such as application system type, calling relationship, optimal migration path, etc., through scheduling of each sub-agent (such as the configuration analysis agent, the calling chain analysis agent, and the migration trajectory calculation agent). The multi-source collaborative analysis core agent takes these specific information as the scenario entry condition for searching the knowledge base, matches the pre-defined business progressive import scheme in the knowledge base, and combines the migration path obtained by the migration trajectory calculation agent to finally output the specific migration scheme of the application system.

[0068] In step 207, based on the optimal migration path and type, a business traffic migration scheme including the migration order of each microservice and the traffic allocation strategy is generated.

[0069] The business traffic migration scheme is a guiding document for the entire migration process, which describes how to smoothly transition the business traffic from the virtual machine environment to the containerized environment while maximizing the continuity and stability of the business. A perfect business traffic migration scheme can reduce uncertainty in the migration process, improve migration efficiency, reduce human intervention, and thus reduce migration costs.

[0070] In one or more embodiments of the present application, the specific steps of generating the business traffic migration scheme are as follows. First, the migration order of each microservice can be determined according to the optimal migration path. The optimal migration path describes the order of service migration, on the basis of which the specific migration time point and migration steps of each microservice can be determined. For example, all microservices can be divided into multiple batches according to the optimal migration path, and migrated in turn according to the batch order. Second, the corresponding traffic allocation strategy is determined according to the type of the application system. The traffic allocation strategy describes how to gradually transfer the traffic from the virtual machine environment to the containerized environment. Different application system types may require different traffic allocation strategies. The traffic allocation strategies of the following four types of application systems, single-center pure back-end system, multi-center pure back-end system, single-center non-pure back-end system, and multi-center non-pure back-end system, will be introduced one by one.

[0071] For single-center pure backend systems, since the system usually adopts the call between internal services, without the direct access of external users, for such systems, the traffic migration strategy adopted by some embodiments of the present application can include: at the beginning of the start of the containerized service, instead of directly providing services to the outside, first conduct sufficient testing and verification internally to ensure its stability and reliability; then, in a way of gradually increasing the traffic proportion of the containerized service while gradually reducing the traffic proportion of the virtual machine service, realize batch-by-batch and step-by-step import. This strategy is particularly suitable for pure backend systems with extremely high stability requirements, because it can minimize migration risks and ensure business continuity and stability. Specifically, for microservices based on a registration discovery mechanism, gradually increasing the traffic proportion of the containerized service can be achieved by adjusting the service weight of the service registry. The service registry is a key component in the microservices architecture, which is responsible for maintaining a list of all available service instances and routing requests to different service instances according to certain strategies (such as weight, load). By adjusting the weight of the virtual machine service and / or the containerized service in the service registry, traffic can be gradually transferred from the virtual machine service to the containerized service. For example, the weight of the containerized service can be set to 1% first, and then gradually increased to 10%, 50%, 100% after checking that there are no problems, until the virtual machine service is completely replaced. For microservices using a service mesh architecture, gradually reducing the traffic proportion of the virtual machine service is achieved by gradually removing the isolation of the microservice module. Gradually removing the isolation of the microservice module means gradually lifting the traffic restrictions on the newly deployed containerized microservice module, allowing it to gradually receive traffic and eventually completely replace the original virtual machine module. This way can achieve more precise traffic control and facilitate advanced traffic management strategies such as blue-green deployment.

[0072] For multi-center pure backend systems, the traffic can be gradually imported based on the migration scheme for single-center pure backend systems for each center.

[0073] For single-center non-pure backend systems, such systems usually contain both internal service calls and direct access by external users. For such systems, the determined traffic allocation strategy can include: first, traffic migration between internal services is achieved by gradually increasing the traffic proportion of containerized services while gradually reducing the traffic proportion of virtual machine services (the specific way can refer to the traffic allocation strategy of single-center pure backend systems), and then the entry-side traffic migration is achieved by gradually adjusting the configuration of the entry traffic management component. The entry traffic management component usually refers to a load balancer (such as Nginx, HAProxy) or an API gateway, which is responsible for routing requests from external users to service instances in the backend. By gradually adjusting the configuration of the entry traffic management component, the proportion of external traffic entering the virtual machine service and the containerized service can be controlled. Exemplarily, the front-end traffic entry Nginx proxy can be first configured to route most (e.g., 99%) of the traffic to the original virtual machine service and a small amount of traffic (e.g., 1%) to the newly deployed containerized service. As the stability of the containerized service is verified, its weight in Nginx is gradually increased, and the weight of the virtual machine service is correspondingly reduced.

[0074] For multi-center non-pure backend systems, for the backend traffic part, the traffic can be gradually introduced based on the migration scheme of single-center pure backend systems for each center; for the entry-side traffic part, the entry-side traffic part of the migration scheme for single-center non-pure backend systems can be referred to for gradual introduction.

[0075] In addition, in order to ensure the stability and reliability of the traffic migration process, some embodiments of the present application also design a rollback strategy. Specifically, during the traffic migration process, system performance indicators (such as CPU utilization, memory usage, response time) and user experience indicators (such as error rate, request delay) are obtained at a predetermined frequency, and the rollback strategy is triggered when the indicators are abnormal, so as to recover to the state before migration within a predetermined time. Exemplarily, the specific implementation of the rollback strategy can include: when the system performance indicators or user experience indicators exceed the preset threshold, the system automatically switches the traffic back to the virtual machine service; or when the operation and maintenance personnel find that the system is abnormal, manually trigger the rollback operation.

[0076] In step 209, the business traffic is gradually introduced according to the business traffic migration scheme to achieve smooth migration of each microservice in the application system from a virtual machine to a containerized service.

[0077] This step is the core execution phase of the entire migration process, and the goal is to gradually transfer the actual business traffic from the old environment (virtual machine) to the new environment (container) according to the pre-prepared migration strategy, and ensure the continuity, stability and performance of the business are not affected during the entire process.

[0078] In one or more embodiments of the present application, gradually introducing business traffic according to the business traffic migration scheme includes: in the process of gradually introducing business traffic, first using a small traffic ratio for exploratory migration, and then gradually increasing the business traffic ratio after confirming that the system is stable. The core idea of this strategy is to introduce a small amount of traffic in the production environment for testing, verify the stability and performance of the new version, and then gradually expand the release range until all traffic uses the new version. In the scenario of the present application, a small amount of traffic can be introduced into the containerized microservice first to verify whether it can normally handle business requests, and the performance indicators such as response time, error rate, etc. are monitored. If any abnormal situation is found, the traffic introduction can be stopped immediately, and rolled back to the original virtual machine environment.

[0079] In the following, a specific embodiment will be used to illustrate how to use the scheme proposed in the present application to perform container migration of an application system.

[0080] In this embodiment, the user inputs an instruction about the application migration requirement: "I have an application system named M that needs to be containerized and migrated, and needs to be lossless during migration and implemented in multiple windows. Please provide a specific scheme."

[0081] After receiving the natural language input of the user, the large language model performs requirement analysis to obtain the identification (M) of the target system and the migration intention (container migration, providing a gradual traffic introduction scheme) of the user who needs to perform container business migration, and other key information.

[0082] Subsequently, the multi-source collaborative analysis core agent schedules a configuration analysis agent, which calls the configuration information MCP service to obtain the related configuration information of the application system from the configuration database integrated with the CMDB data synchronization mechanism. After determining the target system, the configuration analysis agent reads the CMDB configuration library information and confirms that the application system is a single-center deployment architecture. In addition, through the CMDB configuration information, the agent also identifies that the application system is a pure backend system, that is, the system only exists internal system calls and does not exist external traffic requests.

[0083] The multi-source collaborative analysis core agent further schedules and calls the call chain analysis agent to obtain the call chain relationship diagram of the target application system. The call chain analysis agent can obtain the call information of the current application system by calling the call chain information MCP service.

[0084] The multi-source collaborative analysis core agent then schedules a migration trajectory calculation agent to calculate the optimal migration path based on the previously obtained configuration information and call information. In this example, according to the preset migration path calculation algorithm, the following optimal migration path is obtained:

[0085] POD2→POD4→POD1→POD3→POD5, POD6

[0086] The migration path indicates that the traffic needs to be migrated to each POD in the above order, so as to realize the gradual service migration process.

[0087] Finally, the multi-source collaborative analysis intelligent agent obtains the service migration scheme from the knowledge base, combines the information obtained from each sub-agent, comprehensively analyzes, and presents the final migration scheme steps to the user. The migration scheme can include migration order, traffic proportion, monitoring index, rollback strategy, and other detailed information to guide the user to complete the service traffic migration. Exemplarily, the service traffic migration scheme output by the intelligent agent is as shown in Figure 3

[0088] Figure 4 A schematic block diagram of a computer device 40 according to one or more embodiments of the present application. The computer device 40 comprises a memory 410, a processor 420, and a computer program 430 stored on the memory 410 and executable on the processor 420, the execution of the computer program 430 causing the method 20 described above to be performed.

[0089] In addition, as described above, the present application can also be implemented as a computer readable storage medium, in which a program for causing the flow of the method 20 described above to be performed is stored. Here, as the computer readable storage medium, various modes of computer readable storage media such as a disk type (e.g., a magnetic disk, an optical disk, etc.), a card type (e.g., a memory card, an optical card, etc.), a semiconductor memory type (e.g., a ROM, a non-volatile memory, etc.), a tape type (e.g., a magnetic tape, a cassette tape, etc.), and the like can be used.

[0090] The present application can also be implemented as a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the method 20 described above.

[0091] In applicable cases, various embodiments provided by the present application can be implemented using hardware, software, or a combination of hardware and software. Moreover, in applicable cases, various hardware components and / or software components set forth herein can be combined into a composite component including software, hardware, and / or both without departing from the scope of the present application. In applicable cases, various hardware components and / or software components set forth herein can be divided into sub-components including software, hardware, or both without departing from the scope of the present application. In addition, in applicable cases, it is contemplated that a software component can be implemented as a hardware component, and vice versa.

[0092] ​Software (such as program code and / or data) according to this application can be stored on one or more computer-readable storage media. It is also contemplated that software identified herein can be implemented using one or more general purpose or special purpose computers and / or computer systems, networked and / or otherwise. Where applicable, the order of the blocks can be changed, combined into composite blocks and / or separated into sub- blocks to provide for code efficiency, for controllability or

[0093] The embodiments and examples set forth herein are presented to best explain the embodiments of the present application and its specific application to provide those skilled in the art with the information needed to best use the present application and its application. However, those skilled in the art will appreciate that the description and examples are provided for the purpose of illustration and example only. The description is not intended to be exhaustive or to limit the application to the precise forms disclosed.

Claims

1. A method of traffic flow migration, the method comprising: The method comprises the following steps: analyzing the application migration requirements of a user to determine the configuration information and type of the application system to be migrated; based on the configuration information, determining the calling relationship between each microservice in the application system; based on the calling relationship, determining the optimal migration path of each microservice according to the time consumption index; based on the optimal migration path and the type, generating a business traffic migration scheme including the migration sequence of each microservice and the traffic allocation strategy; and gradually introducing business traffic according to the business traffic migration scheme to achieve the smooth migration of each microservice in the application system from a virtual machine to a containerized service.

2. The service traffic migration method of claim 1, wherein, The method further comprises: splitting the application system into multiple independent, containerizable deployment microservices; building a container image for each microservice to ensure that each microservice and its dependencies are encapsulated in a separate container; uploading the built container image to a container image repository; and generating a container orchestration description file describing the deployment method and dependency relationship of each microservice.

3. The method of claim 1, wherein, Analyzing the application migration requirements of a user comprises: using natural language processing technology to analyze the application migration requirements input by the user to determine the identity and user intent of the application system to be migrated.

4. The service traffic migration method of claim 3, wherein, Analyzing the application migration requirements of a user further comprises: based on the identity of the application system, obtaining the configuration information of the application system from a configuration management database, the configuration information including one or more of the following: the number of application system centers, deployment topology, module information, container quantity, synchronous and asynchronous call information; and determining the type of the application system based on the configuration information.

5. The service traffic migration method of claim 1 or 4, wherein, The type of the application system includes: single-center pure backend system, single-center non-pure backend system, multi-center pure backend system, and multi-center non-pure backend system.

6. The method of claim 1, wherein, Based on the configuration information, determining the calling relationship between each microservice in the application system comprises: querying the call chain data related to the application system from a call chain tracking system, the call chain data including request identification, service name, call time, and time consumption information; and based on the call chain data, building a call chain relationship graph describing the calling relationship between microservices, where nodes represent microservices and edges represent calling relationships.

7. The method of claim 1, wherein, Based on the calling relationship, determining the optimal migration path of each microservice according to the time consumption index comprises: taking each most upstream microservice in the call chain relationship graph as the starting point, traversing its downstream microservices, and searching for all reachable calling paths; during the traversal process, calculating the time consumption of each reachable calling path; and selecting the path with the shortest total time consumption from all reachable calling paths as the optimal migration path.

8. The method of claim 7, wherein, Calculating the time consumption of each reachable calling path comprises: The sliding window algorithm is used to smooth the time consumption in a time slice period, wherein the sliding average time consumption duration of the current time slice period t is determined by the following formula: duration t = a duration t-1 + (1 - a) duration Wherein, duration is the sampling time consumption of the current time slice period, duration t-1 is the moving average time consumption of the previous time slice period, and is the α smoothing factor.

9. The method of claim 1, wherein, based on the optimal migration path and the type, generating a business traffic migration scheme including the migration sequence of each microservice and the traffic allocation strategy comprises: determining the migration sequence of each microservice according to the optimal migration path; and determining the corresponding traffic allocation strategy according to the type of the application system.

10. The method of claim 9, wherein, Determining the corresponding traffic allocation strategy according to the type of the application system comprises: If the application system is a single-center pure backend system or a multi-center pure backend system, the determined traffic distribution strategy includes: realizing traffic migration between internal services by gradually increasing the traffic proportion of containerized services while gradually reducing the traffic proportion of virtual machine services.

11. The service traffic migration method of claim 10, wherein, for the microservices based on the registration discovery mechanism, the gradually reducing the traffic proportion of the virtual machine services is realized by adjusting the service weight of the service registry; and for the microservices adopting the service mesh architecture, the gradually reducing the traffic proportion of the virtual machine services is realized by gradually removing the isolation of the microservice modules. If the application system is a single-center pure backend system or a multi-center pure backend system, the determined traffic distribution strategy includes: realizing traffic migration between internal services by gradually increasing the traffic proportion of containerized services while gradually reducing the traffic proportion of virtual machine services. Determining the corresponding traffic distribution strategy includes:

12. The method of claim 9, wherein, If the application system is a single-center non-pure backend system or a multi-center non-pure backend system, the determined traffic distribution strategy includes: first realizing traffic migration between internal services by gradually increasing the traffic proportion of containerized services while gradually reducing the traffic proportion of virtual machine services, and then realizing ingress-side traffic migration by gradually adjusting the configuration of the ingress traffic management component. Determining the corresponding traffic distribution strategy further includes: during the traffic migration process, acquiring system performance indicators and user experience indicators at a predetermined frequency, and triggering a rollback strategy when the indicators are abnormal, so as to restore to the state before migration within a predetermined time.

13. The traffic migration method of any of claims 10-12, wherein, Gradually introducing business traffic according to the service traffic migration scheme includes:

14. The method of claim 1, wherein, During the process of gradually introducing business traffic, a small traffic proportion is first used for exploratory migration, and then the business traffic proportion is gradually increased after confirming that the system is running stably.

15. The service traffic migration method of claim 1, wherein the configuration information and type determination, the call relationship determination, and the optimal migration path determination are all realized by corresponding intelligent agents. The computer program is stored on the memory and executable on the processor, and the execution of the computer program causes the following operations:

16. A computer device, comprising: Analyzing the user's application migration requirements to determine the configuration information and type of the application system to be migrated; Based on the configuration information, determining the call relationship between each microservice in the application system; Based on the call relationship, determining the optimal migration path of each microservice according to the time consumption index; Based on the optimal migration path and the type, generating a service traffic migration scheme including the migration order of each microservice and the traffic distribution strategy; and Gradually introducing business traffic according to the service traffic migration scheme to realize the smooth migration of each microservice in the application system from a virtual machine to a containerized service. The execution of the computer program further causes the following operations:

17. The computer device of claim 16, wherein, Splitting the application system into multiple independent, containerizable deployment microservices; Building a container image for each microservice to ensure that each microservice and its dependencies are encapsulated in a separate container; Uploading the built container image to a container image repository; and Generating a container orchestration description file describing the deployment method and dependency relationship of each microservice. Analyzing the user's application migration requirements includes:

18. The computer device of claim 16, wherein, ​ The application migration demand input by the user is parsed by using a natural language processing technology to determine an identity of the application system to be migrated and a user intention.

19. The computer device of claim 18, wherein, The parsing of the application migration demand of the user further includes: Based on the identity of the application system, configuration information of the application system is obtained from a configuration management database, and the configuration information includes one or more of the following: a number of centers of the application system, a deployment topology, module information, a number of containers, and synchronous and asynchronous calling information; and Based on the configuration information, a type of the application system is determined.

20. The computer device of claim 16 or 19, wherein, The type of the application system includes: a single-center pure backend system, a single-center non-pure backend system, a multi-center pure backend system, and a multi-center non-pure backend system.

21. The computer device of claim 16, wherein, Based on the configuration information, a calling relationship between microservices in the application system is determined, including: Querying calling chain data related to the application system from a calling chain tracking system, and the calling chain data includes a request identity, a service name, a calling time, and time consumption information; and Based on the calling chain data, a calling chain relationship graph describing the calling relationship between the microservices is constructed, wherein a node represents a microservice and an edge represents a calling relationship.

22. The computer device of claim 16, wherein, Based on the calling relationship, an optimal migration path of each microservice is determined according to a time consumption index, including: Taking each most upstream microservice in the calling chain relationship graph as a starting point, traversing downstream microservices thereof, and searching for all reachable calling paths; In the traversal process, time consumption of each reachable calling path is calculated; and From all the reachable calling paths, a path with the shortest total time consumption is selected as the optimal migration path.

23. The computer device of claim 22, wherein, The calculation of the time consumption of each reachable calling path includes: The sliding window algorithm is used to smooth the time consumption in a time slice period, wherein the sliding average time consumption duration of the current time slice period t is determined by the following formula: duration t = a duration t-1 + (1 - a) duration Wherein, duration is the sampling time consumption of the current time slice period, duration t-1 is the moving average time consumption of the previous time slice period, and is the α smoothing factor.

24. The computer device of claim 16, wherein, Based on the optimal migration path and the type, a business traffic migration scheme including a migration order of each microservice and a traffic allocation strategy is generated, including: Determining the migration order of each microservice according to the optimal migration path; and Determining a corresponding traffic allocation strategy according to the type of the application system.

25. The computer device of claim 24, wherein, Determining the corresponding traffic allocation strategy according to the type of the application system includes: If the application system is a single-center pure backend system or a multi-center pure backend system, the determined traffic allocation strategy includes: gradually increasing a traffic proportion of containerized services and gradually reducing a traffic proportion of virtual machine services to realize traffic migration between internal services.

26. The computer device of claim 25, wherein For microservices based on a registration discovery mechanism, the gradual reduction of the traffic proportion of the virtual machine services is achieved by adjusting a service weight of a service registry; and For microservices using a service mesh architecture, the gradual reduction of the traffic proportion of the virtual machine services is achieved by gradually removing isolation of the microservice modules.

27. The computer device of claim 24, wherein, Determining the corresponding traffic allocation strategy according to the type of the application system includes: If the application system is a single-center non-pure backend system or a multi-center non-pure backend system, the determined traffic allocation strategy includes: first, gradually increasing a traffic proportion of containerized services and gradually reducing a traffic proportion of virtual machine services to realize traffic migration between internal services, and then gradually adjusting a configuration of an entry traffic management component to realize entry side traffic migration.

28. The computer device of any of claims 25-27, wherein, The determining of the corresponding traffic distribution strategy further comprises: acquiring system performance indexes and user experience indexes at a predetermined frequency during the traffic migration, and triggering a rollback strategy when the indexes are abnormal, so as to restore to the state before the migration within a predetermined time.

29. The computer device of claim 16, wherein, The step of gradually introducing the service traffic according to the service traffic migration scheme comprises: During the gradual introduction of the service traffic, a small traffic proportion is used for tentative migration first, and the service traffic proportion is gradually increased after it is confirmed that the system is stable.

30. The computer device of claim 16, wherein the configuration information and type determination, the call relationship determination, and the optimal migration path determination are all implemented by corresponding agents.

31. A computer readable storage medium, characterized in that, The computer readable storage medium comprises instructions which, when executed, perform the method of any one of claims 1-15.

32. A computer program product, characterised in that, The computer program product comprises a computer program which, when executed by a processor, implements the steps of the method of any one of claims 1-15.

Images