WO2024040930A1

WO2024040930A1 - Software deployment architecture management method and related device

Info

Publication number: WO2024040930A1
Application number: PCT/CN2023/081000
Authority: WO
Inventors: 曾正阳; 李款; 叶锋
Original assignee: 华为云计算技术有限公司
Priority date: 2022-08-24
Filing date: 2023-03-13
Publication date: 2024-02-29

Abstract

The present application provides a method, which is executed by a software deployment architecture management system. The method comprises: the management system acquires metadata of software; the management system generates architecture element relationship models of software deployment architectures at different stages in the life cycle of the software by means of a same language according to the metadata of the software; the management system compares the architecture element relationship models of the software deployment architectures at different stages to obtain a comparison result of the software deployment architectures. According to the method, by generating the architecture element relationship models of the software deployment architectures at different stages by means of the same language, the difficulty of comparison is reduced, and the accuracy of comparison is improved; moreover, automatic comparison can be implemented, thereby overcoming the disadvantages of manual comparison; early warning is supported, thereby avoiding significant impact on production environments, and ensuring the service reliability and stability.

Description

A management method and related equipment for software deployment architecture

This application requires the priority of the Chinese patent application submitted to the State Intellectual Property Office of China on August 24, 2022, with the application number 202211019405.0 and the invention title "A management method for software deployment architecture and related equipment", and requires that it be filed in 2022 Priority is granted to a Chinese patent application filed with the State Intellectual Property Office of China on November 30, 2020, with the application number 202211520292.2 and the invention title "A management method for software deployment architecture and related equipment", the entire content of which is incorporated into this application by reference. middle.

Technical field

The present application relates to the field of software management technology, and in particular to a management method, system, computing device cluster, computer-readable storage medium and computer program product for a software deployment architecture.

Background technique

The software development process includes architects designing software architecture and developers developing software based on the software deployment architecture designed by architects. As the software industry continues to iterate and upgrade, architects often need to maintain the overall life cycle of software, specifically including the various stages of software deployment architecture design, software development, operation and maintenance.

The key to maintaining the overall life cycle of software lies in the care of the software deployment architecture. The care of software deployment architecture includes checking the consistency of software deployment architecture in different stages (such as design stage and operation stage), monitoring possible architectural risks in a timely manner and sending alarms.

Currently, architects usually manually compare software deployment architectures at different stages to find out the differences between different software deployment architectures. However, software deployment architectures at different stages are usually generated using different methods. Due to differences in technical implementation, the comparison work is complex and cannot provide early warning. Often, when differences are discovered, they have already had a significant impact on the production environment, affecting business reliability and stability. .

Contents of the invention

In response to the above problems, this application provides a software deployment method. This method uses the same language to generate architectural element relationship models of software deployment architectures at different stages, which reduces the difficulty of comparison, improves the accuracy of comparison, and can realize automation. Comparison overcomes the disadvantages of manual comparison, supports early warning, avoids major impact on the production environment, and ensures business reliability and stability. This application also provides a management system for software deployment architecture, a computing device cluster, a computer-readable storage medium, and a computer program product corresponding to the above method.

In the first aspect, this application provides a management method for software deployment architecture. The method is performed by a management system of the software deployment architecture. For ease of description, it is referred to as the management system below. The management system may be a software system, and the software system may be a software development platform such as an integrated development environment (Integrated Development Environment, IDE), or a plug-in that depends on the software development platform. The software system can be deployed in a computing device cluster, such as a computing device cluster in a cloud environment or a computing device cluster in a local computing center. The computing device cluster executes the program code of the software system, thereby executing the management method of the software deployment architecture of this application. . In some examples, the management system may also be a hardware system, such as a computing device cluster with the management capability of the software deployment architecture. When the hardware system is running, the management method of the software deployment architecture of the present application is executed.

Specifically, the management system can obtain the metadata of the software, and then the management system generates architectural element relationship models of the software deployment architecture at different stages in the life cycle of the software based on the metadata of the software through the same language, and then the management system generates architectural element relationship models based on the software at different stages. Compare the architectural element relationship models of the deployment architecture to obtain the comparison results of the software deployment architecture. Among them, the comparison results of the software deployment architecture include the comparison results of the architecture element relationship models.

In this method, the management system uses the same language to generate architectural element relationship models of the software deployment architecture at different stages, which reduces the difficulty of comparison, improves the accuracy of comparison, and can realize automated comparison and overcome the disadvantages of manual comparison. , supports early warning to avoid major impact on the production environment and ensure business reliability and stability.

In some possible implementations, the metadata of software can be different at different stages. The management system can obtain the metadata of the software in the design phase and the metadata of the software in the running phase. Correspondingly, when comparing the architectural element models, the management system can compare the dependency relationship of the first architectural element in the architectural element relationship model of the first software deployment architecture with the second architecture in the architectural element relationship model of the second software deployment architecture. Compare the dependencies of elements. Among them, the first software deployment architecture is the software deployment architecture in the design stage. The second software deployment architecture is the software deployment architecture of the running phase. The first architectural element is the architectural element corresponding to the metadata of the software in the design phase, and the second architectural element is the architectural element corresponding to the metadata of the software in the running phase.

This method can specifically compare the dependencies of the first architectural element in the architectural element relationship model of the first software deployment architecture and the dependencies of the second architectural element in the architectural element model of the second software deployment architecture based on metadata at different stages. relationship, which can improve comparison efficiency.

In some possible implementations, in response to different metadata in different stages, the management system can establish a mapping relationship between the metadata of the software in the design stage and the metadata in the runtime. For example, the design state element "system" can be mapped to the runtime metadata. The state element "application" is bound, and the design state element "service" is bound to the running state element "sub-application". This lays a solid foundation for the subsequent comparison between the design state and the running state of the deployment architecture.

In some possible implementations, the metadata of the software can also be the same at different stages of the software's life cycle. For example, when architects design the architecture, they first design the metadata of the software (for example, a service) based on the Configuration Management Database (CMDB), then perform architecture design based on this metadata to obtain the deployment model and process model. In this way, the metadata of the software in the design phase and the metadata of the software in the runtime phase can be regarded as the same. Since the metadata are the same, the management system does not need to perform the steps of establishing a mapping relationship between metadata, thus improving the comparison efficiency.

In some possible implementations, the metadata of the software in the design phase includes the process model. The process model describes the architectural elements and calling relationships in the design phase. The metadata of the software in the running phase includes call chain information. The call chain information describes the running phase. Architectural elements and calling relationships. Correspondingly, the management system can generate the architectural element relationship model in the design phase based on the process model, and use the same language to generate the architectural element relationship model in the running phase based on the call chain information.

This method converts each service element information and calling relationship in the process model into a unified architecture element data relationship model. At the same time, it obtains the service architecture elements and calling relationships from the call chain information such as the call chain topology map, and also converts it into a data relationship model. Unify the comparison language to lay the foundation for automatic comparison of architectures.

In some possible implementations, the management system may generate at least one of a first dependency table or a first dependency graph based on the dependency of the first architectural element in the architectural element relationship model of the first software deployment architecture. or more, and the dependency relationship of the second architectural element in the architectural element relationship model of the second software deployment architecture, Generate at least one or more of the second dependency table or the second dependency graph. The management system then compares the first dependency relationship table with the second dependency relationship table, and/or compares the first dependency relationship graph with the second dependency relationship graph.

On the one hand, comparison based on dependency graphs or dependency tables can improve comparison efficiency; on the other hand, comparison results can be displayed intuitively through dependency graphs or dependency tables.

In some possible implementations, the management system displays the architecture element relationship model comparison results in the dependency table or the dependency graph. For example, the management system can flag inconsistencies or missing areas in a dependency table or dependency diagram. This allows users to quickly view the differences in software deployment architecture at different stages and helps with subsequent decision-making.

In some possible implementations, the same language includes a domain-specific language DSL. Among others, different domains can have different domain-specific languages. In some fields, the field-specific language can be JS Object Notation (JSON), and in other fields, the field-specific language can be Structured Query Language (SQL).

This method uses a unified domain-specific language to convert metadata at different stages into a unified language model, thereby realizing automatic model comparison. This can achieve automatic consistent care of the software deployment architecture, improve care efficiency, and reduce costs. the cost of care.

In some possible implementations, the management system can generate a first model tree based on the metadata of the software in the design phase, and generate a second model tree based on the metadata of the software in the running phase, and then the management system can compare The first model tree and the second model tree obtain a model tree comparison result. The comparison result of the software deployment architecture includes the model tree comparison result.

By converting metadata into a model tree, this method can achieve multi-level data comparison, including comparison at the environment, application, component, instance and other levels.

In some possible implementations, the metadata of the software in the design phase includes a deployment model, the deployment model describes architectural elements and the environment in which the architectural elements are located, and the metadata of the software in the running phase includes a resource management model. Correspondingly, the management system may generate a first model tree based on the architectural elements in the deployment model and the environment in which the architectural elements are located. The first model tree is an environment component model tree. The management system performs instantiation based on the resource management model and the call chain information to generate a second model tree. The second model tree is an environment component model tree.

This method realizes the comparison of the deployment model and the resource management model by converting the deployment model in the design stage and the resource management model in the operation stage into model trees respectively. In this way, it can be found that there are inconsistencies between the structure of the deployment model and the structure of the running components. Sexual issues.

In the second aspect, this application provides a management system for software deployment architecture. The system includes:

Interaction module, used to obtain metadata of software;

A model generation module, configured to generate architectural element relationship models of the software deployment architecture at different stages in the life cycle of the software through the same language based on the metadata of the software;

A comparison module, configured to compare according to the architectural element relationship models of the software deployment architecture at different stages to obtain the comparison results of the software deployment architecture. The comparison results of the software deployment architecture include the comparison of the architectural element relationship models. to the results.

In some possible implementations, the interactive module is specifically used to:

Obtain the metadata of the software in the design phase, and obtain the metadata of the software in the running phase;

The comparison module is specifically used for:

Compare the dependency relationship of the first architectural element in the architectural element relationship model of the first software deployment architecture with the dependency relationship of the second architectural element in the architectural element relationship model of the second software deployment architecture, where the first software deployment architecture is The software deployment architecture in the design phase, the second software deployment architecture is the software deployment architecture in the running phase, the first architecture element is the architecture element corresponding to the metadata of the software in the design phase, and the second architecture element is Architectural elements corresponding to the metadata of the software during the running phase.

In some possible implementations, the metadata of the software in the design phase includes a process model, the process model describes the architectural elements and calling relationships of the design phase, and the metadata of the software in the running phase includes call chain information. , the call chain information describes the architectural elements and call relationships of the running phase;

The model generation module is specifically used for:

Generate an architectural element relationship model of the design stage according to the process model;

According to the call chain information, the same language is used to generate the architectural element relationship model of the running phase.

In some possible implementations, the comparison module is specifically used to:

generating at least one or more of a first dependency table or a first dependency graph according to the dependency relationship of the first architectural element in the architectural element relationship model of the first software deployment architecture, and according to the second software Deploy the dependency relationship of the second architecture element in the architecture element relationship model of the architecture, and generate at least one or more of the second dependency relationship table or the second dependency relationship graph;

The first dependency relationship table is compared with the second dependency relationship table, and/or the first dependency relationship graph is compared with the second dependency relationship graph.

In some possible implementations, the interactive module is also used to:

The architecture element relationship model comparison result is displayed in the dependency relationship table or the dependency relationship diagram.

In some possible implementations, the same language includes a domain-specific language DSL.

In some possible implementations, the model generation module is also used to:

Generate a first model tree based on the metadata of the software in the design phase, and generate a second model tree based on the metadata of the software in the running phase;

The comparison module is also used to:

The first model tree and the second model tree are compared to obtain a model tree comparison result, and the comparison result of the software deployment architecture includes the model tree comparison result.

In some possible implementations, the metadata of the software in the design phase includes a deployment model, the deployment model describes architectural elements and the environment where the architectural elements are located, and the metadata of the software in the running phase includes a resource management model;

The model generation module is specifically used for:

Generate a first model tree based on the architectural elements in the deployment model and the environment where the architectural elements are located, where the first model tree is an environment component model tree;

According to the resource management model, instantiation is performed in combination with the call chain information to generate a second model tree, where the second model tree is an environment component model tree.

In a third aspect, this application provides a computing device cluster. The computing device cluster includes at least one computing device, the at least one computing device includes at least one processor and at least one memory, the at least one memory Computer readable instructions are stored in the at least one processor, and the at least one processor executes the computer readable instructions, so that the computing device cluster performs the method as described in the first aspect.

In a fourth aspect, the present application provides a non-transitory computer-readable storage medium. When the non-transitory computer-readable storage medium is executed by a computing device, the computing device runs the aforementioned first aspect or the first aspect. Any possible implementation of the methods provided. The storage medium stores the program. The storage medium includes but is not limited to volatile memory, such as random access memory, and non-volatile memory, such as flash memory, hard disk drive (HDD), and solid state drive (SSD).

In a fifth aspect, the present application provides a computer program product. The computer program product includes computer instructions. When executed by a computing device, the computing device runs the aforementioned first aspect or any possible implementation of the first aspect. provided method.

Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods.

Description of drawings

In order to explain the technical methods of the embodiments of the present application more clearly, the drawings required to be used in the embodiments will be briefly introduced below.

Figure 1 is a system architecture diagram of a software deployment architecture management system provided by an embodiment of the present application;

Figure 2 is an interactive flow chart of a software deployment architecture management method provided by an embodiment of the present application;

Figure 3 is a schematic diagram of a resource management model structure tree provided by an embodiment of the present application;

Figure 4 is a schematic diagram of binding a baseline cloud service and a running cloud service provided by an embodiment of the present application;

Figure 5 is a schematic diagram of metadata collection in the running stage provided by the embodiment of the present application;

Figure 6 is a schematic diagram of a call chain topology provided by an embodiment of the present application;

Figure 7 is a schematic diagram of a model tree comparison result provided by an embodiment of the present application;

Figure 8 is a schematic diagram of a comparison result of an architectural element relationship model provided by an embodiment of the present application;

Figure 9 is a schematic diagram of a cloud service binding method provided by an embodiment of the present application;

Figure 10 is a schematic diagram of a task creation interface provided by an embodiment of the present application;

Figure 11 is a schematic diagram of a consistent care report summary provided by an embodiment of the present application;

Figure 12 is a schematic diagram illustrating the details of a consistent care report provided by an embodiment of the present application;

Figure 13 is a schematic diagram illustrating the details of another consistent care report provided by the embodiment of the present application;

Figure 14 is a schematic structural diagram of a computing device provided by an embodiment of the present application;

Figure 15 is a schematic structural diagram of a computing device cluster provided by an embodiment of the present application;

Figure 16 is a schematic structural diagram of another computing device cluster provided by an embodiment of the present application;

Figure 17 is a schematic structural diagram of another computing device cluster provided by an embodiment of the present application.

Detailed ways

The terms "first" and "second" in the embodiments of this application are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, features defined as "first" and "second" may explicitly or implicitly include one or more of these features.

First, some technical terms involved in the embodiments of this application are introduced.

Software deployment architecture describes the deployment constraints of software deployment entities (also called deployment elements, such as components, functional modules, microservices), and defines the communication associations (also called dependencies).

Deployment constraints refer to the constraints imposed by software deployment entities on deployment nodes. Deployment constraints can usually be divided into the following constraint types: must (meaning it must be deployed on a certain type or node), can (meaning it must be deployed on a certain type or node), or prohibited (meaning it cannot be deployed on a certain type or node). kind of node).

Dependency refers to the calling relationship between a certain software deployment entity and other software deployment entities. Dependencies can be divided into the following types: dependence (A depends on B, which means A will call B when the system is running), dependent (A is dependent on B, which means B will call A when the system is running).

Software deployment architecture can usually be designed and generated by architects through relevant design tools, such as Visio, PPT and other drawing tools. Based on this, the software deployment architecture can be represented by the software deployment architecture diagram exported by the design tool. Among them, architects can design software deployment architecture from different perspectives. Correspondingly, software deployment architecture can be represented by corresponding architectural views according to the architect's perspective when designing. For example, the software deployment architecture may be characterized by at least one of a logical view, a development view, a deployment view, an operational view, and a use case view.

The logical view mainly solves the problems of system analysis and design. It is oriented to system logic analysis and design, describing the logical decomposition of the software system and the relationship between the decomposed logical architecture elements. Logical views include logical models. The logical model describes the logical functional decomposition of the software system, decomposes the software system into corresponding logical architecture elements, and describes the relationship between each logical architecture element. Among them, logical architecture elements can include one or more of components, modules, services, micro services (micro services, ms), and interfaces.

The development view mainly solves the problems of system technology implementation and development. It relies on the logical view to describe the code structure and construction structure of the system. Development view includes code model and build model. The code model defines the code structure and the correspondence between the code and the logical view. Code structure defines the code configuration management of logical architecture elements, such as code warehouse links, types, branches and other attributes. The mapping relationship between the logical view and the code warehouse/code directory can be established in the code model to achieve explicit management of software source code. The build model defines the software compilation and build structure and tool chain, and establishes the mapping and traceability relationship between code and deployable artifacts (such as runtime files).

The deployment view mainly solves the problem of system installation and deployment. It relies on the development view to describe the delivery and deployment relationship of the system. Deployment view includes deployment model and delivery model. The deployment model defines the deployment relationship of the software. It relies on the construction model and the delivery model to describe the deployment dependencies and deployment constraints of each offering and even the corresponding software deployment entity. Offering provides users with a product portfolio of complete capabilities, and the products in the product portfolio include multiple services. When the software is a microservice architecture, the service can include multiple microservices. The delivery model defines the packaging structure of deployable artifacts to offers, the corresponding tool chains, and the mapping relationship between offers and other view elements.

The running view mainly solves the interaction problems during the system runtime. It relies on the development view to model the logic of architectural elements or the interaction between them. The running view includes the process model, which describes the relationship during the system's runtime. It focuses on modeling and describing runtime processes, process groups, threads, inter-process communication and interaction mechanisms.

The use case view provides the context of the software system and the main functional use cases of the software system. It is used to clarify the location of the software system in the network, the interface relationship with surrounding software systems, and the main functional use cases provided by the software system. The use case view includes the context model, which provides the system context and main functional use cases of the system to clarify the location of the system in the network, The interface relationship with surrounding systems and the main functional use cases provided by the system. The use case view can serve as a driving element, driving and validating the design of the other four views.

From the perspective of architectural care, the code model in the development view describes that each service has a corresponding code warehouse, which can achieve consistency care from service to code; the construction model in the development view describes the construction products of each service. From the code repository corresponding to the service, it can realize the consistency management from the code to the construction results; the deployment model in the deployment view describes the deployment of the construction products of the service into the environment corresponding to the service, and exists in the form of service process; process view The process model in , describes the process corresponding to each service, as well as the calling process logic between processes. The above view realizes consistent traceability from service to code warehouse, from code to compilation and build, from build product to deployment environment, and from service to process. In essence, it realizes the design state (design phase) to the development state (development phase). ), the software deployment entities described in the deployment model, the deployment environment, and the inter-process calling relationships described in the process model cannot be guaranteed to be consistent with the real software deployment architecture, thus missing the software deployment architecture from the design state. The ability to maintain consistency in the running state.

At present, the consistency monitoring of software deployment architecture from design state to running state is usually implemented by architects through manual comparison. However, software deployment architectures in the design phase and software deployment architectures in the runtime phase are often generated in different ways. For example, the software deployment architecture in the design phase is usually designed and generated by architects using design tools such as Visio, PPT and other drawing tools. The software deployment architecture in the running phase is usually designed by architects using an application performance management (APM) system to obtain the running environment. Call chain drawing and generation, or drawing and generation based on host agent monitoring data.

Due to differences in technical implementation, the software deployment architecture in the design phase is usually static and abstract, while the software deployment architecture in the run phase is usually dynamic and instantiated. In this way, the comparison work is complicated and no early warning is possible. When differences are discovered, they often have a major impact on the production environment and affect business reliability and stability.

In view of this, this application provides a management system for software deployment architecture. For ease of description, it is referred to as the management system below. The management system can be in the form of software, and the software can be deployed in a computing device cluster. The computing device cluster executes the program code corresponding to the software, thereby executing the management method of the software deployment architecture of the present application. In some examples, the management system may also be in the form of hardware, and the hardware may be, for example, a computing device cluster with a software deployment architecture management function. When the hardware is running, the management method of the software deployment architecture of the present application is executed.

Specifically, the management system obtains the metadata of the software, and then uses the same language to generate the architectural element relationship model of the software deployment architecture at different stages in the life cycle of the software based on the metadata of the software, and then generates the architecture element relationship model of the software deployment architecture at different stages in the life cycle of the software. The element relationship models are compared to obtain the comparison results of the software deployment architecture. The comparison results of the software deployment architecture include the comparison results of the architecture element relationship models.

This method uses the same language to generate architectural element relationship models of software deployment architectures at different stages, which reduces the difficulty of comparison and improves the accuracy of comparison. It can also realize automated comparison, overcome the disadvantages of manual comparison, and support early warning. , to avoid significant impact on the production environment and ensure business reliability and stability.

In order to make the technical solution of the present application clearer and easier to understand, the system architecture of the management system of the present application is introduced below with reference to the accompanying drawings.

Referring to the system architecture diagram of the software deployment architecture management system shown in FIG. 1 , the management system 100 includes an interaction module 102 , a model generation module 104 and a comparison module 106 . The interaction module 102 is used to obtain software metadata and model generation The module 104 is used to generate the architectural element relationship model of the software deployment architecture at different stages in the life cycle of the software through the same language according to the metadata of the software. The comparison module 106 is also used to generate the architectural elements of the software deployment architecture at different stages according to the software life cycle. The relational models are compared to obtain a comparison result of the software deployment architecture. The comparison result of the software deployment architecture includes a comparison result of the architecture element relationship model.

Among them, the metadata of the software can be different at different stages of the software life cycle. For example, metadata for software during the design phase may differ from metadata for software during the runtime phase. The metadata of the software in the design phase can include one or more of the context model, logical model, code model, construction model, delivery model, deployment model, and process model. The metadata of the software during the running phase may include one or more of call chain information and resource management models. The call chain information may be a topology map.

In this way, the management system 100 can be connected to the design system 200 and the application performance management system 300 respectively. Among them, the design system 200 is a product or service that supports architectural design. Product forms of the design system 200 include client tools or web services. For example, the design system 200 may include Visio, a unified modeling language (UML) tool, or PPT. Based on the drawing elements of these products and services, static deployment architecture diagrams can be designed. The application performance management system 300 refers to a product or service that monitors and manages application performance. Similarly, the product form of the application performance management system 300 includes client tools or Web services. For example, the application performance management system 300 can be an APM system such as pinpoint, zipking, jeager, skywaking, etc.

Correspondingly, the interaction module 102 in the management system 100 is used to obtain metadata of the software in the design phase from the design system 200 and obtain metadata of the software deployed in the production environment in the running phase through the application performance management system 300 .

Further, the management system 100 may also include a mapping module 108 for establishing a mapping relationship between the metadata of the software in the design phase and the metadata of the software in the running phase. In this way, when comparing, the comparison module 106 can compare the dependency relationship of the first architectural element in the architectural element relationship model of the first software deployment architecture with the dependency relationship of the second architectural element in the architectural element relationship model of the second software deployment architecture. Make a comparison. Among them, the first software deployment architecture is the software deployment architecture in the design phase, the second software deployment architecture is the software deployment architecture in the running phase, and the first architecture element and the second architecture element have a mapping relationship.

Furthermore, the comparison module 106 can also compare the structures. For example, the comparison module 106 can compare the structures of the software at different stages before comparing the architectural metadata relationship models of the software at different stages. Specifically, the comparison module 106 is also configured to generate a first model tree based on the metadata of the software in the design phase, and generate a second model tree based on the metadata of the software in the running phase, and then compare the first model tree and the second model tree. Model tree, obtain model tree comparison results. Among them, the comparison results of software deployment architecture include model tree comparison results. This enables multi-level data comparison, including comparison at the environment, application, component, instance and other levels.

It should be noted that at different stages of the software life cycle, the metadata of the software can also be the same. For example, when architects design the architecture, they first design the metadata of the software (for example, a service) based on the Configuration Management Database (CMDB), then perform architecture design based on this metadata to obtain the deployment model and process model. In this way, the metadata of the software in the design phase and the metadata of the software in the runtime phase can be regarded as the same. The management system 100 can call the application performance management system 300 to obtain the metadata of the software. Since the metadata are the same, the management system 100 does not need to perform the step of establishing a mapping relationship between metadata.

Next, we will introduce the management method of the software deployment architecture of this application in a scenario where the software is a cloud service and the metadata of the cloud service in the design phase is different from the metadata in the operation phase.

Referring to the interactive flow chart of the management method of the software deployment architecture shown in Figure 2, the method includes:

S202: The management system 100 obtains cloud service offering information from the product information system.

The product information system is used to provide product information query functions. Among them, the product information system may include one or more of product basic information (Product Base Information, PBI) and cloud service basic information (Cloud Service Base Information, CSBI).

In this example, the management system 100 may obtain the offering information of the cloud service specified by the user from CSBI. The offer information of the cloud service is specifically the offer information to which the cloud service belongs. It should be noted that the management system 100 can periodically (or regularly) synchronize the offering information of the cloud service, or obtain the offering information of the cloud service when triggered by a task.

Furthermore, the management system 100 can perform data cleaning on the product information that does not require modeling in the offering information of the cloud service. For example, the management system 100 can perform data cleaning on the information whose offer status is inactive, including but not limited to information such as test use and sunset. Clean up and save the offer information that needs to be modeled.

S204: The management system 100 obtains the metadata of the cloud service in the design phase from the design system 200 according to the offering information of the cloud service.

Specifically, the management system 100 can regularly obtain the architectural element data (4+1 view data) of the cloud service from the design system 200 based on the cloud service's offer information, including use case view, logical view, development view, deployment view and running view. 5 views to obtain metadata of cloud services. The metadata of cloud services may include models in the above views, such as one or more of the context model, logical model, code model, construction model, delivery model, deployment model, and process model.

It should be noted that the model in the above view is designed or modeled using UML tools based on semantic drawing elements. Therefore, the management system 100 can directly identify the model in the above view and obtain the metadata of the cloud service. In some possible implementations, when the model in the view is designed through tools such as Visio or PPT, the management system 100 can also provide an annotation interface, and the user manually annotates the semantics of the corresponding drawing elements through the annotation interface, and then the management system 100 based on the drawing Semantics of elements,extracting metadata of cloud services.

The above S202 and S204 are an implementation method for the management system 100 to obtain the metadata of the cloud service in the design stage. In other possible implementations of the embodiments of this application, the metadata of the cloud service in the design stage can also be obtained through other methods. For example, the management system 100 can directly obtain the metadata of the cloud service in the design phase from the design system 200 .

S206: The management system 100 performs model integrity check and normative check based on the metadata of the cloud service in the design stage. When the inspection result indicates that the inspection fails, S208 is executed; when the inspection result indicates that the inspection passes, S210 is executed.

The management system 100 can check the model integrity of the cloud service based on the context model, logical model, code model, construction model, delivery model, deployment model, and process model. The management system 100 may also check whether the above model complies with the model specification according to the model specification, thereby checking the model specification of the cloud service.

S208: The management system 100 sends the inspection results to the user.

Inspection results can be divided into inspection pass and inspection failure. When the inspection result is that the inspection fails, the inspection result may also include one or more of the location, cause, and level. Among them, the model in the view usually has a responsible person, which is recorded as model owner. The management system 100 can send the above model owner to a user, such as an architect, to notify the corresponding The model owner solves the problem with level "Error".

The above-mentioned S206 and S208 are optional steps in the embodiment of the present application. The above-mentioned S206 and S208 may not be executed when performing the management method of the software deployment architecture in the embodiment of the present application.

S210: The management system 100 baselines the cloud service based on the logical model.

A product enters a state of formal control through formal reviews at various points in its development cycle, a process called "baselining." The management system 100 can generate a "snapshot" of the source code or output of the cloud service (including microservices and components of the cloud service) in the cloud service project repository based on the logical model, thereby providing a formal standard to the outside world. Work is based on this standard and can only be changed with authorization, thus achieving baseline cloud services.

S212: Based on the logical model and the code model, the management system 100 checks the consistency of the architectural elements in the cloud service, its code warehouse and the pipeline. When the inspection result indicates that the inspection fails, S214 is executed; when the inspection result indicates that the inspection passes, S216 is executed.

The management system 100 can take the microservices/components (MS/Component architecture elements) of the logical model as the baseline, and check whether the code repository of the microservices/components in the code model is consistent with the code repository in the software pipeline, specifically checking the code repository. Check whether the address and branch are consistent, thereby checking whether the designed code repository is consistent with the actual code repository.

S214: The management system 100 sends the inspection results to the user.

Inspection results can be divided into inspection pass and inspection failure. When the inspection result is that the inspection fails, the inspection result may also include one or more of the location, cause, and level.

It should be noted that the above-mentioned inspection results in S208 and S214 can be carried by alarm messages or reports. In order to reduce the number of transmissions and thus the transmission overhead, the management system 100 can also merge the inspection results of S208 and S214, and then send the merged inspection results. The management system 100 may periodically send the combined inspection results.

S216: The management system 100 queries the metadata of the cloud service in the running stage from the CMDB.

Among them, the CMDB includes a resource management model, and the management system can query the resource management model of the cloud service in the running stage from the CMDB. The resource management model defines one or more of applications (cloud services), sub-applications (microservices), components, and environments.

An application represents a business and usually includes the following components and environments. The sub-application represents a sub-module under the application, the component represents the microservice, the environment represents an actual running environment deployed by this microservice due to different configurations, and the instance represents a process instance. An environment can generally include multiple process instances. To facilitate understanding, the embodiment of this application also provides an example. In this example, as shown in Figure 3, the cloud service LubanApm includes multiple microservices such as App-center and App-process.

S218: The management system 100 binds the baseline cloud service and the running cloud service according to the metadata of the cloud service in the running stage.

The management system 100 can bind the metadata of the baseline cloud service in the design phase to the running metadata in a one-to-one correspondence based on the running metadata of applications, sub-applications, components, and environments obtained from the CMDB, so as to provide a basis for subsequent implementation of the deployment architecture. Compare the design state and operating state to lay a solid foundation.

Specifically, refer to the corresponding table of key elements between the design state and the operating state shown in Table 1, as follows:

Table 1 Correspondence table of key elements between design state and operating state

The management system 100 can bind the metadata according to the corresponding relationship in Table 1, thereby binding the baseline cloud service and the running cloud service, and establishing a mapping relationship between metadata. For example, the management system 100 can bind System and application, Service and sub-application, MS/Component and component, Zone and environment, and establish mapping relationships between corresponding metadata.

Further, referring to Figure 4, the management system 100 can also build a design state model tree based on the metadata of the baseline cloud service in the design phase, build a running state model tree based on the running state metadata, and bind the corresponding nodes in the model tree. , thus binding the baseline cloud service and the running cloud service.

S219: The management system 100 queries the metadata of the cloud service in the running stage from the application performance management system 300.

The application performance management system 300 (such as the APM system) generally adopts a non-intrusive method. For example, the java program uses java agent technology to collect performance data. First, as shown in Figure 5, the data collection probe (such as java agent) of the APM system (such as APM server) can run together with the cloud service, with the client's configuration information (such as component name, environment name, etc.) when started. Register with the CMDB on the server side, obtain and match identity information, and then when the cloud service is running, the java agent can collect performance data of the cloud service operation, such as information about the current component environment calling other component environments, and the current component environment calling mysql, kafka, redis Statistics of middleware, information about the current component environment being called by other environments. This information includes the number of calls, average response time (RT), number of errors, etc. The above information can be aggregated on the agent side first and reported to the APM server periodically. Each piece of data carries the identity information of the CMDB. APM server can process and store the above data. Furthermore, the data processing system can also include a data display API to support displaying the above data on the front end.

The management system 100 can read the topology data of the stored call chain information through the APM system, and realize visualization through the call chain topology diagram. Figure 6 shows a call chain topology diagram, which truly depicts the calling relationship between multiple component environments under a business, as well as the calling relationship between the component environment and middleware. The calling relationship can be identified by connecting lines. Each line can contain statistical data detected by the client and server respectively. These data include the number of calls, average RT, number of errors, etc. The above call chain topology diagram truly reflects the software deployment architecture of the cloud service and can be dynamically adjusted. It is more accurate and more real-time than the topological relationship depicted by the design tool.

It should be noted that S219 is based on the example of obtaining metadata in the running stage through the APM system. In other possible implementations of the embodiments of this application, code-free intrusion or code intrusion, based on host data flow monitoring or process data can also be used. Flow monitoring, etc., to obtain metadata (such as deployment architecture data) during the running phase (real environment).

S220: The management system 100 generates a first model tree based on the metadata of the cloud service in the design phase, and generates a second model tree based on the metadata of the cloud service in the running phase.

Metadata for cloud services during the design phase includes deployment models. The deployment model describes the architectural elements and where they are located environment. The management system 100 can convert the deployment model into a first model tree, which is an environment component tree, also called a zone/process model tree.

The metadata of cloud services during the runtime phase includes resource management models. The management system 100 can determine whether the service instance related to the resource is actually running according to the resource management model, combined with the call chain information such as the call chain topology map, and thereby instantiates it to generate a second model tree. The second model tree is Environment component model tree, also called zone/process model tree.

S222: The management system 100 compares the first model tree and the second model tree to obtain a model tree comparison result.

The management system 100 compares the architectural elements with mapping relationships in the first model tree and the second model tree, specifically performs a consistency comparison, thereby obtaining a model tree comparison result.

S224: The management system 100 presents the model tree comparison results to the user.

Specifically, the management system 100 may present the model tree comparison results on the first model tree and the second model tree. To facilitate understanding, the embodiment of this application also provides an example for explanation. Referring to the schematic diagram of the model tree comparison result shown in Figure 7, the management system 100 can present the information that the model tree lacks, such as operating information, in the corresponding position of the model tree in the design state (such as the first model tree). The corresponding position of the model tree (such as the second model tree) presents information that the model tree lacks, such as the design model. In addition, the management system 100 may also present prompt information indicating inconsistent environments at corresponding locations in the model tree in the design state and the model tree in the running state.

S226: The management system 100 generates architectural element relationship models of the software deployment architecture in different stages through the same language based on the metadata of the cloud service in the design stage and the metadata in the running stage.

The metadata of cloud services in the design phase includes a process model, which describes the architectural elements and calling relationships of the design phase. The metadata of the software in the running phase includes call chain information, which describes the architectural elements and calling relationships of the running phase.

The management system 100 can generate an architectural element relationship model in the design phase according to the process model, and generate an architectural element relationship model in the running phase using the same language based on the call chain information. Among them, the same language can be a domain specific language (DSL).

A domain-specific language is a computer programming language with limited expressivity for a certain field. Domain-specific languages may include but are not limited to regular expressions, Structured Query Language (SQL), JS Object Notation (JSON), and Markdown. The above domain-specific languages usually have corresponding semantics. For ease of understanding, the following is an example of an architectural element relationship model that generates software deployment architecture at different stages through JSON.

Specifically, the management system 100 can convert the architectural elements and calling relationships in the process model into a unified architectural element relationship model, and at the same time obtain the architectural elements and calling relationships in the call chain topology diagram, remove redundant information, and also use JSON to convert it into a unified Architectural element relationship model.

The architecture element relationship model is a data relationship model, defined through JSON, etc. The embodiment of this application also provides an example of an architectural element relationship model, as shown below:

S228: The management system 100 compares the architectural element relationship models of the software deployment architecture at different stages, and obtains the architectural element relationship model comparison results.

Specifically, the management system 100 may generate at least one or more of the first dependency table or the first dependency graph according to the dependency of the first architecture element in the architecture element relationship model of the first software deployment architecture, and generating at least one or more of a second dependency table or a second dependency graph according to the dependency of the second architectural element in the architectural element relationship model of the second software deployment architecture. Among them, the dependency table describes the service information that each architectural element (such as components, microservices, etc.) depends on/is dependent on. The dependency graph can be generated based on the architectural element relationship model using vis/Echat, etc.

Correspondingly, when performing dependency comparison, the management system 100 may compare the first dependency table with the second dependency table, and/or compare the first dependency graph with the third dependency table. Compare the two dependency diagrams to obtain the comparison results of the architectural element relationship models.

S230: The management system 100 presents the architectural element relationship model comparison results to the user.

Specifically, the management system 100 may display the architecture element relationship model comparison result in the dependency relationship table or the dependency relationship graph. To facilitate understanding, the embodiment of this application also provides an example for explanation. Referring to the schematic diagram of the comparison results of the architecture element relationship models shown in Figure 8, the management system 100 can highlight the differences in dependencies in the first dependency table and the second dependency table, such as the number of dependencies and the number of dependents of cloud service A. The difference, as well as the difference between cloud service A depending on microservice 3 and being dependent on microservice 3. The management system 100 may also display the difference in dependency relationships through different colors or line types in the first dependency relationship diagram and the second dependency relationship diagram. Further, the management system 100 can also associate differences in the dependency relationship table with differences in the dependency relationship graph through arrows.

The information that the model tree lacks, such as running information, is presented at the corresponding position of the model tree in the design state (such as the first model tree), and the information that the model tree lacks is presented at the corresponding position of the model tree in the running state (such as the second model tree). information, such as design Model. In addition, the management system 100 may also present prompt information indicating inconsistent environments at corresponding locations in the model tree in the design state and the model tree in the running state.

It should be noted that the comparison results of the above-mentioned S224 and S230 can also be merged, and then the management system 100 can send the merged comparison results and present the merged comparison results, thereby reducing transmission overhead. The management system 100 may periodically send the combined comparison results and present them to the user. The comparison results of the software deployment architecture include one or more of the model tree comparison results and the architecture element relationship model comparison results.

Based on the above description, this embodiment proposes a method for monitoring the consistency of the software deployment architecture in the design phase and the running phase. This method compares the architecture element relationship model generated in a unified language and solves the problems of manual comparison and consistency monitoring. It also supports early warning to avoid major impact on the production environment and ensure business reliability and stability.

Next, the management method of the software deployment architecture of the embodiment of the present application will be introduced based on an application scenario.

In this scenario, the management system 100 can first bind the baseline cloud service and the running cloud service.

Refer to the schematic diagram of cloud service binding method shown in Figure 9, and bind the design state metadata and running state metadata of the baseline cloud service in one-to-one correspondence, such as System and application, Service and sub-application, MS/Component and component. , Zone and environment are bound in one-to-one correspondence. This method supports automatic and manual binding. The automatic binding and manual binding methods are described in detail below.

The management system 100 can automatically read data in the product information system and scan the CMDB for services with the same name to establish binding relationships. In order to ensure the accuracy of the binding relationship, the management system 100 supports users to manually confirm the binding relationship established by automatic binding.

When there is no matching service with the same name, the management system 100 can trigger manual binding. As shown in Figure 9, the Offering tree displays multiple cloud services. Users can select cloud services from the dashboard offering tree. The Offering tree can display the baseline status of a selected cloud service and provide links to cloud service 4+1 model projects and cloud services. CMDB link. When users click on the link of the cloud service 4+1 model project, they can be linked to the modeling tool to view the 4+1 view modeling data of the cloud service, including 5 views: use case view, logical view, development view, deployment view and running view. , the user can click on the component or microservice in the view to select the component or microservice, and then click on the CMDB link to select the running component instance or microservice instance. When the binding is confirmed, the binding relationship can be established .

Then, the management system 100 supports users (such as architects) to create new design state and running state consistency care tasks.

Referring to the schematic diagram of the task creation interface shown in Figure 10, users can configure the task name, CMDB environment, model branch, execution cycle, and notifier through the task creation interface, thereby creating a consistency care task between the design state and the running state. It should be noted that the execution cycle is an optional configuration, and the task can be a periodic task or aperiodic task.

When the management system 100 receives the design state and operating state consistency care task created by the user, it can execute the method of the embodiment shown in FIG. 2 to generate a design state and operating state consistency care report summary. FIG. 11 shows a schematic diagram of a summary of the consistency care report between the design state and the operation state. The summary shows the problems discovered by the management system 100 when performing consistency care, and provides a link to view the details of the consistency care report. When users click on the link, they can also view the details of the consistency care report. The details of the consistency care report can display the model tree comparison results and the architectural element relationship model comparison results.

As shown in Figure 12, the details of the consistency guard report respectively display the zone/process tree of the design metadata and the running The application/component tree after the state metadata is instantiated, and inconsistent elements are marked, including whether the environment is consistent, whether the service elements are consistent, etc.

As shown in Figure 13, the details of the consistency care report display the service list and dependency table in the design state and running state respectively, and distinguish the rows with inconsistent dependencies by separate colors; click on the dependency or dependent number in the list to jump to the graph Customize the display page and identify the relevant calling relationships through other colors.

Based on the management method of software deployment architecture in the foregoing embodiments, this application also provides a management system 100 for software deployment architecture. As shown in Figure 1, the management system 100 includes:

Interaction module 102, used to obtain metadata of software;

The model generation module 104 is configured to generate architectural element relationship models of the software deployment architecture at different stages in the life cycle of the software through the same language according to the metadata of the software;

The comparison module 106 is configured to compare according to the architectural element relationship models of the software deployment architecture at different stages to obtain the comparison results of the software deployment architecture, where the comparison results of the software deployment architecture include the architecture element relationship models. Comparison results.

For example, the above-mentioned interaction module 102, model generation module 104, and comparison module 106 can be implemented by hardware, or can be implemented by software. For ease of description, the comparison module 106 is used as an example below.

When implemented by software, the comparison module 106 may be an application program running on a computing device, such as a computing engine. The application can be provided to users as a virtualized service. Virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, and container (container) services. Among them, the VM service can be a service that uses virtualization technology to virtualize a virtual machine (VM) resource pool on multiple physical hosts (such as computing devices) to provide users with VMs for use on demand. The BMS service is a service that virtualizes BMS resource pools on multiple physical hosts to provide users with BMS on demand. Container service is a service that virtualizes container resource pools on multiple physical hosts to provide users with containers on demand. VM is a simulated virtual computer, that is, a logical computer. BMS is an elastically scalable high-performance computing service. Its computing performance is the same as that of traditional physical machines, and it has the characteristics of safe physical isolation. Containers are a kernel virtualization technology that can provide lightweight virtualization to isolate user space, processes and resources. It should be understood that the VM service, BMS service and container service in the above virtualization services are only specific examples. In actual applications, the virtualization service can also be other lightweight or heavyweight virtualization services, which are not discussed here. Specific limitations.

When implemented by hardware, the comparison module 106 may include at least one computing device, such as a server. Alternatively, the comparison module 106 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). Among them, the above-mentioned PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (field-programmable gate array, FPGA), a general array logic (generic array logic, GAL), or any combination thereof.

In some possible implementations, the interaction module 102 is specifically used to:

Obtain the metadata of the software in the design stage, and obtain the metadata of the software in the running stage;

The comparison module 106 is specifically used for:

Compare the dependency relationship of the first architecture element in the architectural element relationship model of the first software deployment architecture with the second software deployment Compare the dependencies of the second architectural element in the architectural element relationship model of the architecture. The first software deployment architecture is the software deployment architecture in the design phase, and the second software deployment architecture is the software deployment architecture in the running phase. The first architectural element is an architectural element corresponding to the metadata of the software in the design phase, and the second architectural element is an architectural element corresponding to the metadata of the software in the running phase.

The management system 100 may also include a mapping module 108. The mapping module 108 is used to establish a mapping relationship between the metadata of the software in the design phase and the metadata of the software in the running phase. Correspondingly, when comparing, the comparison module 106 can determine the first architecture element and the second architecture element based on the above mapping relationship, and compare the dependency relationship of the first architecture element in the architecture element model of the first software deployment architecture with the second architecture element. Compare the dependencies of the second architectural element in the architectural element model of the software deployment architecture.

Similar to the comparison module 106, the mapping module 108 can also be implemented by hardware, or can be implemented by software.

When implemented by software, the mapping module 108 may be an application program running on a computing device, such as a computing engine or the like. The application can be provided to users as a virtualized service. When implemented by hardware, the mapping module 108 may include at least one computing device, such as a server. Alternatively, the mapping module 108 may also be a device implemented using an application specific integrated circuit (ASIC) or a programmable logic device (PLD).

The model generation module 104 is specifically used to:

In some possible implementations, the comparison module 106 is specifically used to:

In some possible implementations, the interaction module 102 is also used to:

In some possible implementations, the model generation module 104 is also used to:

The comparison module 106 is also used to:

The model generation module 104 is specifically used to:

The present application also provides a computing device 1400. As shown in Figure 14, computing device 1400 includes: bus 1402, processor 1404, memory 1406, and communication interface 1408. The processor 1404, the memory 1406 and the communication interface 1408 communicate through a bus 1402. Computing device 1400 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 1400.

The bus 1402 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of presentation, only one line is used in Figure 14, but it does not mean that there is only one bus or one type of bus. Bus 1402 may include a path that carries information between various components of computing device 1400 (eg, memory 1406, processor 1404, communications interface 1408).

The processor 1404 may include a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP) or a digital signal processor (DSP). any one or more of them.

Memory 1406 may include volatile memory, such as random access memory (RAM). The processor 1404 may also include non-volatile memory (non-volatile memory), such as read-only memory (ROM), flash memory, mechanical hard disk drive (hard disk drive, HDD) or solid state drive (solid state drive). drive, SSD). The memory 1406 stores executable program code, and the processor 1404 executes the executable program code to implement the aforementioned management method of the software deployment architecture. Specifically, the software deployment architecture management system 100 stored on the memory 1406 is used to execute instructions for the software deployment architecture management method.

The communication interface 1408 uses transceiver modules such as, but not limited to, network interface cards and transceivers to implement communication between the computing device 1400 and other devices or communication networks.

An embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

As shown in Figure 15, the computing device cluster includes at least one computing device 1400. The memory 1406 of one or more computing devices 1400 in the computing device cluster may store instructions for the management system 100 of the same software deployment architecture to perform the management method of the software deployment architecture.

In some possible implementations, one or more computing devices 1400 in the computing device cluster may also be used to execute part of the instructions of the management system of the software deployment architecture for executing the management method of the software deployment architecture. In other words, a combination of one or more computing devices 1400 may jointly execute instructions of the software deployment architecture management system 100 for performing the software deployment architecture management method.

It should be noted that the memory 1406 in different computing devices 1400 in the computing device cluster may store different instructions for executing part of the functions of the management system 100 of the software deployment architecture.

Figure 16 shows a possible implementation. As shown in Figure 16, two computing devices 1400A and 1400B are connected through a communication interface 1408. Instructions for executing the functions of the interaction module 102 and the model generation module 104 are stored on the memory in the computing device 1400A. Instructions for performing the functions of comparison module 106 are stored on memory in computing device 1400B. In other words, the memories 1406 of the computing devices 1400A and 1400B jointly store instructions for the management system 100 of the software deployment architecture to execute the management method of the software deployment architecture.

The connection method between computing device clusters shown in Figure 16 can be based on the fact that the management method of the software deployment architecture provided by this application requires a large amount of computing power for model generation. Therefore, it is considered that the functions implemented by the model generation module 104 and the comparison module 106 are executed by different computing devices.

It should be understood that the functions of computing device 1400A shown in FIG. 16 may also be performed by multiple computing devices 1400. Likewise, the functions of computing device 1400B may also be performed by multiple computing devices 1400.

In some possible implementations, one or more computing devices in a cluster of computing devices may be connected through a network. Wherein, the network may be a wide area network or a local area network, etc. Figure 17 shows a possible implementation. As shown in Figure 17, two computing devices 1400C and 1400D are connected through a network. Specifically, the connection to the network is made through a communication interface in each computing device. In this type of possible implementation, instructions for executing the functions of the interaction module 102 and the model generation module 104 are stored in the memory 1406 of the computing device 1400C. At the same time, instructions for performing the functions of the comparison module 106 are stored in the memory 1406 in the computing device 1400D.

The connection method between the computing device clusters shown in Figure 17 can be: Considering that the management method of the software deployment architecture provided by this application requires a large amount of computing power for model generation, the functions implemented by the model generation module 104 and the comparison module 106 are considered handed over to the computing device 1400D for execution.

It should be understood that the functions of computing device 1400C shown in FIG. 17 may also be performed by multiple computing devices 1400. Likewise, the functions of computing device 1400D may also be performed by multiple computing devices 1400.

An embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium may be any available medium that a computing device can store or a data storage device such as a data center that contains one or more available media. The available media may be magnetic media (eg, floppy disk, hard disk, tape), optical media (eg, DVD), or semiconductor media (eg, solid state drive), etc. The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned management method applied to the software deployment architecture by the management system 100 for executing the software deployment architecture.

An embodiment of the present application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions capable of running on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, at least one computing device is caused to execute the above management method of the software deployment architecture.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that it can still be used Modifications are made to the technical solutions described in the foregoing embodiments, or equivalent substitutions are made to some of the technical features; however, these modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims

A management method for software deployment architecture, characterized in that it is executed by a management system of software deployment architecture, and the method includes:

The management system obtains metadata of the software;

The management system generates architectural element relationship models of the software deployment architecture at different stages in the life cycle of the software based on the metadata of the software through the same language;

The management system compares the architectural element relationship models of the software deployment architecture at different stages to obtain the comparison results of the software deployment architecture. The comparison results of the software deployment architecture include the comparison results of the architectural element relationship models. .
The method according to claim 1, characterized in that the management system obtains metadata of the software, including:

The management system obtains metadata of the software in the design stage and obtains metadata of the software in the running stage;

The comparison of architectural element relationship models based on the software deployment architecture at different stages includes:

Compare the dependency relationship of the first architectural element in the architectural element relationship model of the first software deployment architecture with the dependency relationship of the second architectural element in the architectural element relationship model of the second software deployment architecture, where the first software deployment architecture is The software deployment architecture in the design phase, the second software deployment architecture is the software deployment architecture in the running phase, the first architecture element is the architecture element corresponding to the metadata of the software in the design phase, and the second architecture element is Architectural elements corresponding to the metadata of the software during the running phase.
The method according to claim 2, characterized in that the metadata of the software in the design phase includes a process model, the process model describes the architectural elements and calling relationships of the design phase, and the metadata of the software in the running phase The data includes call chain information, which describes the architectural elements and call relationships of the running phase;

The management system uses the same language to generate architectural element relationship models of the software deployment architecture at different stages in the life cycle of the software based on the metadata of the software, including:

The management system generates an architectural element relationship model of the design stage based on the process model;

The management system uses the same language to generate the architectural element relationship model of the running stage based on the call chain information.
The method according to claim 2 or 3, characterized in that the management system performs comparison according to the architectural element relationship models of the software deployment architecture at different stages to obtain the comparison result of the software deployment architecture, including:

The management system generates at least one or more of a first dependency table or a first dependency graph based on the dependency of the first architectural element in the architectural element relationship model of the first software deployment architecture, and based on the Describe the dependencies of the second architecture element in the architecture element relationship model of the second software deployment architecture, and generate at least one or more of the second dependency table or the second dependency graph;

The management system compares the first dependency relationship table with the second dependency relationship table, and/or compares the first dependency relationship graph with the second dependency relationship graph.
The method of claim 4, further comprising:

The management system displays the comparison result of the architecture element relationship model in the dependency relationship table or the dependency relationship graph.
The method according to any one of claims 1 to 5, characterized in that the same language includes domain-specific Language DSL.
The method of claim 2, further comprising:

The management system generates a first model tree based on the metadata of the software in the design phase, and generates a second model tree based on the metadata of the software in the running phase;

The management system compares the first model tree and the second model tree to obtain a model tree comparison result, and the comparison result of the software deployment architecture includes the model tree comparison result.
The method according to claim 7, characterized in that, the metadata of the software in the design phase includes a deployment model, the deployment model describes architectural elements and the environment where the architectural elements are located, and the metadata of the software in the running phase includes resources. management model;

The management system generates a first model tree based on the metadata of the software in the design phase, including:

The management system generates a first model tree based on the architectural elements in the deployment model and the environment where the architectural elements are located, and the first model tree is an environment component model tree;

The management system generates a second model tree based on the metadata of the software in the running stage, including:

The management system performs instantiation based on the resource management model and the call chain information to generate a second model tree, where the second model tree is an environment component model tree.
A management system for software deployment architecture, characterized in that the system includes:

Interaction module, used to obtain metadata of software;

A model generation module, configured to generate architectural element relationship models of the software deployment architecture at different stages in the life cycle of the software through the same language based on the metadata of the software;

A comparison module, configured to compare according to the architectural element relationship models of the software deployment architecture at different stages to obtain the comparison results of the software deployment architecture. The comparison results of the software deployment architecture include the comparison of the architectural element relationship models. to the results.
The system according to claim 9, characterized in that the interactive module is specifically used for:

Obtain the metadata of the software in the design phase, and obtain the metadata of the software in the running phase;

The comparison module is specifically used for:

Compare the dependency relationship of the first architectural element in the architectural element relationship model of the first software deployment architecture with the dependency relationship of the second architectural element in the architectural element relationship model of the second software deployment architecture, where the first software deployment architecture is The software deployment architecture in the design phase, the second software deployment architecture is the software deployment architecture in the running phase, the first architecture element is the architecture element corresponding to the metadata of the software in the design phase, and the second architecture element is Architectural elements corresponding to the metadata of the software during the running phase.
The system according to claim 10, characterized in that, the metadata of the software in the design phase includes a process model, the process model describes the architectural elements and calling relationships of the design phase, and the metadata of the software in the running phase The data includes call chain information, which describes the architectural elements and call relationships of the running phase;

The model generation module is specifically used for:

Generate an architectural element relationship model of the design stage according to the process model;

According to the call chain information, the same language is used to generate the architectural element relationship model of the running phase.
The system according to claim 10 or 11, characterized in that the comparison module is specifically used for:

According to the dependency relationship of the first architectural element in the architectural element relationship model of the first software deployment architecture, a third At least one or more of a dependency relationship table or a first dependency relationship graph, and generating a second dependency relationship table or a third dependency relationship table according to the dependency relationship of the second architecture element in the architecture element relationship model of the second software deployment architecture. 2. At least one or more of the dependency graphs;

The first dependency relationship table is compared with the second dependency relationship table, and/or the first dependency relationship graph is compared with the second dependency relationship graph.
The system according to claim 12, characterized in that the interactive module is also used to:

The architecture element relationship model comparison result is displayed in the dependency relationship table or the dependency relationship diagram.
The method according to any one of claims 9 to 13, characterized in that the same language includes a domain-specific language DSL.
The system according to claim 10, characterized in that the model generation module is also used to:

Generate a first model tree based on the metadata of the software in the design phase, and generate a second model tree based on the metadata of the software in the running phase;

The comparison module is also used to:

The first model tree and the second model tree are compared to obtain a model tree comparison result, and the comparison result of the software deployment architecture includes the model tree comparison result.
The system according to claim 15, wherein the metadata of the software in the design phase includes a deployment model, the deployment model describes architectural elements and the environment where the architectural elements are located, and the metadata of the software in the running phase includes resources. management model;

The model generation module is specifically used for:

Generate a first model tree based on the architectural elements in the deployment model and the environment where the architectural elements are located, where the first model tree is an environment component model tree;

According to the resource management model, instantiation is performed in combination with the call chain information to generate a second model tree, where the second model tree is an environment component model tree.
A computing device cluster, characterized in that the computing device cluster includes at least one computing device, the at least one computing device includes at least one processor and at least one memory, and the at least one memory stores computer-readable Instructions; the at least one processor executes the computer-readable instructions, so that the computing device cluster performs the method according to any one of claims 1 to 8.
A computer program product containing instructions, characterized in that, when the instructions are executed by a cluster of computing devices, they cause the cluster of computing devices to perform the method according to any one of claims 1 to 8.
A computer-readable storage medium, characterized in that it includes computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 8.