CN112463181B - Software product distribution method, device, equipment and storage medium under multi-cloud scene - Google Patents
Software product distribution method, device, equipment and storage medium under multi-cloud scene Download PDFInfo
- Publication number
- CN112463181B CN112463181B CN202110142117.3A CN202110142117A CN112463181B CN 112463181 B CN112463181 B CN 112463181B CN 202110142117 A CN202110142117 A CN 202110142117A CN 112463181 B CN112463181 B CN 112463181B
- Authority
- CN
- China
- Prior art keywords
- cloud
- dependency
- data
- software product
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24564—Applying rules; Deductive queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Computational Linguistics (AREA)
- Stored Programmes (AREA)
Abstract
The application relates to a software product distribution method, a device, equipment and a storage medium under a multi-cloud scene, belonging to the field of Internet, wherein the method comprises the following steps: acquiring data generated in a continuous integration, research and development environment and a test environment from a first data source, and analyzing the data to obtain a service dependency relationship of a software product as a basic dependency requirement; acquiring data generated by the cloud areas under respective service operation scenes from a second data source, and analyzing the data to obtain the service dependency relationship of the software product of each cloud area as the actual dependency requirement of each cloud area; summarizing the actual dependence requirements and the basic dependence requirements of the cloud areas respectively to generate distribution rules of the cloud areas; and distributing the software product to the cloud areas according to the distribution rules. Bandwidth costs and storage costs can be saved while the efficiency of distribution of software products is improved.
Description
Technical Field
The present application relates to the field of internet technologies, and in particular, to a method, an apparatus, a device, and a storage medium for distributing software products in a multi-cloud scenario.
Background
With the improvement of the delivery capability of the application software of the internet of things, continuous integration and continuous delivery (CI/CD) become a standard configuration of the development and delivery processes of many enterprise software. With the development of cloud products and technologies, demands for improving reliability and multi-region delivery characteristics of software in various cloud scenes are raised. In the following, a few common cloud environments are briefly introduced: the public cloud is a cloud service built for the public, and each user can acquire the use of cloud resources through the Internet, so that the public cloud has the advantages of low cost and good expansibility and has the defect of low security of confidential data; the private cloud is a cloud service constructed for the user to use independently, and the security of the confidential data is high; the 'hybrid cloud' comprises a public cloud and a private cloud, and integrates the convenience and the convenience of the public cloud and the safety and the stability of the private cloud; the "multi-cloud" is a cloud architecture, which is formed by combining a plurality of cloud services, and can include both public clouds and private clouds.
In particular, in a "hybrid cloud", "multi-cloud", or other environment, for delivery of software, it is necessary to push software artifacts (typically "software packages" or "container images") that are the products of a CI/CD flow into an artifact library of each cloud for use at deployment time. The software product is a binary file generated by compiling and packaging source codes, different development languages correspond to the binary files with different formats, and the binary files can be directly operated on a server. The product library is used for managing the constructed product after the source code is compiled, and supports common product library types such as Docker, Maven, Helm, npm and PyPI packages. The product library can be used for performing versioning control in cooperation with source codes, can be seamlessly combined with local building tools and continuous integration and continuous deployment on the cloud, supports the characteristics of vulnerability scanning and the like, and is a standardized mode for processing all package types generated in the software development process of enterprises.
Currently, software products are generally uploaded to a public cloud or private cloud product library through a client, or automatically distributed through an integrated third party SDK. These approaches have the following drawbacks:
(1) when the micro-service is mature, the service adding speed is high, the distribution strategy needs to be updated every time the service is added, incomplete distributed software products caused by configuration omission easily exist, and the manual configuration efficiency is low.
(2) Service dependence conditions in service operation environments of different cloud areas may be different, and software products are distributed to the cloud areas according to the same strategy, so that the distribution bandwidth cost and the storage cost of the software products are increased, resource waste is caused, and the distribution efficiency is influenced.
At present, no effective solution is provided for how to save bandwidth cost and storage cost and improve the distribution efficiency of software products in the related art.
Disclosure of Invention
The embodiment of the application provides a software product distribution method, a device, equipment and a storage medium under a multi-cloud scene, so as to at least solve the problem of how to save bandwidth cost and storage cost and improve the distribution efficiency of software products in the related technology.
In a first aspect, an embodiment of the present application provides a software product distribution method in a cloudy scene, including: acquiring first data generated in a continuous integration, research and development environment and a test environment from a first data source, and analyzing the first data to obtain a service dependency relationship of a software product as a basic dependency requirement; acquiring second data generated by a plurality of cloud areas under respective service operation scenes from a second data source, and analyzing the second data to obtain a service dependency relationship of the software product of each cloud area as an actual dependency requirement of each cloud area; summarizing the actual dependence requirements and the basic dependence requirements of the cloud areas respectively to generate distribution rules of the cloud areas; and distributing the software product to the cloud areas according to the distribution rules.
In some of these embodiments, the first data source comprises at least one of a CMDB (Configuration Management Database), a link tracking system, a Configuration center, and Helm Chart.
In some of these embodiments, the second data source comprises at least one of a link tracking system, a configuration center, a log analyzer, and a network traffic analyzer.
In some embodiments, in the case that the first data source is a CMDB and/or a configuration center, the acquiring first data generated in a continuous integration, development environment and test environment from the first data source, analyzing the first data, and obtaining the service dependency relationship of the software product as the basic dependency requirement includes: acquiring first data generated in a continuous integration, development environment and test environment from the CMDB and/or the configuration center, wherein the first data is stored in a Key-Value Key Value pair form; screening out information related to service dependence by comparing key words of the key value pairs; and removing the duplicate of the screened information to obtain the service dependency relationship of the software product as a basic dependency requirement.
In some embodiments, the distribution rules are presented by a list of dependent requirements, and after the distributing the software product to each cloud area according to each distribution rule, the method further comprises: and updating and removing the expired dependent demands in the dependent demand list regularly.
In some embodiments, after generating the distribution rule of each cloud area, the software product distribution method in the multi-cloud scenario further includes: correcting and supplementing the dependency requirement list of each cloud area according to the actual dependency requirement of each cloud area, wherein the actual dependency requirement comprises online service configuration data and software calling historical data.
In some embodiments, said distributing the software product to each cloud area according to each distribution rule includes: uploading a software product through a client or an SDK under the scene of a public cloud or a private cloud with a product library; when a container mirror image warehouse is provided, uploading a software product through a Docker client mirror image; in the scenario of a public cloud or a private cloud without an article library, the software article is uploaded using HTTP, FTP, SFTP, or SSH protocols.
In a second aspect, an embodiment of the present application provides a software product distribution apparatus in a cloudy scene, including: the system comprises an external data source docking module, a dependency analysis processing module, a dependency summary storage module and a product distribution module, wherein the external data source docking module is used for acquiring first data generated in a continuous integration, research and development environment and a test environment from a first data source; acquiring second data generated by the cloud areas under respective service operation scenes from a second data source; the dependence analysis processing module is used for analyzing the first data to obtain a service dependence relation of the software product as a basic dependence requirement; analyzing the second data of each cloud area to obtain a service dependency relationship of the software product of each cloud area as an actual dependency requirement of each cloud area; the dependence summarizing storage module is used for summarizing the actual dependence requirements and the basic dependence requirements of the cloud areas respectively to generate distribution rules of the cloud areas; the product distribution module is used for distributing the software products to the cloud areas according to the distribution rules.
In a third aspect, an embodiment of the present application provides an electronic device, including a processor and a storage medium storing a computer program, where the computer program, when executed by the processor, implements the software product distribution method in a cloudy scene according to any one of the foregoing descriptions.
In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the software product distribution method in a cloudy scene according to any one of the foregoing.
According to the content, the software product distribution method in the multi-cloud scene in the embodiment of the application comprises the following steps: acquiring data generated in a continuous integration, research and development environment and a test environment from a first data source, and analyzing the data to obtain a service dependency relationship of a software product as a basic dependency requirement; acquiring data generated by the cloud areas under respective service operation scenes from a second data source, and analyzing the data to obtain the service dependency relationship of the software product of each cloud area as the actual dependency requirement of each cloud area; summarizing the actual dependence requirements and the basic dependence requirements of the cloud areas respectively to generate distribution rules of the cloud areas; and distributing the software product to the cloud areas according to the distribution rules. Distribution rules (namely dependence requirements) can be automatically configured aiming at each cloud area, and configuration efficiency is improved; moreover, based on the distribution rule, the software products are distributed to the cloud areas under different service scenes according to the requirements, all the software products are prevented from being distributed to all the cloud areas according to the same strategy, the bandwidth cost and the storage cost are saved, and the distribution efficiency of the software products is improved. In addition, unnecessary synchronization of software products can be reduced by timely rejecting expired dependent services, storage cost and bandwidth cost are reduced, and synchronization efficiency is improved.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a flowchart of a software product distribution method in a cloudy scenario according to an embodiment of the present application;
FIG. 2 is a schematic diagram of stages of a software product distribution method in a cloudy scenario according to an embodiment of the present application;
fig. 3 is a schematic relationship diagram of a software product distribution device and data sources in a multi-cloud scenario according to an embodiment of the present application;
fig. 4 is a block diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments provided in the present application without any inventive step are within the scope of protection of the present application.
As described above, configuring the distribution strategy of software products by traditional manual configuration means is clearly not applicable to modern internet where today's microservices bloom throughout. In an environment with thousands of microservices, both post-manual configuration error correction and efficiency reduction in the process are incremental costs to the enterprise.
The embodiment of the application mainly solves the technical problems existing at present from the following two angles:
(1) automatically acquiring service dependency (i.e., dependency requirements), eliminating manual configuration:
the method comprises the steps of acquiring data from an existing data source capable of reflecting software service dependency, integrating distribution rules of cloud areas, and automatically distributing software products to a cloud end needing to run the software only by contrasting the distribution rules when uploading (including synchronization) the software products.
(2) Aiming at a multi-cloud area, distribution rules are independently analyzed, redundancy is reduced, and storage cost is saved:
the basic dependency requirements and the actual dependency requirements during running are acquired and calculated separately, so that the distribution rule of each cloud area can be obtained, the software products are distributed to the cloud areas according to the distribution rules, all the software products are prevented from being distributed to all the cloud areas according to a uniform distribution strategy, storage and bandwidth are paid, and partial areas are charged higher, for example, the software products are delivered overseas at home, so that the software product distribution method under the multi-cloud scene provided by the embodiment of the application can save storage cost and bandwidth cost, and meanwhile, the distribution efficiency of the software products is improved.
The terms "dependency", "service dependency", "dependency requirement" and "software call dependency" described below refer to dependencies between software services upstream and downstream, and different expressions are used for the sake of sentence passing and understanding by the reader. Fig. 1 is a flowchart of a software product distribution method in a cloudy scene according to an embodiment of the present application, and as shown in fig. 1, the flowchart includes:
s100: acquiring first data generated in a continuous integration, research and development environment and a test environment from a first data source, and analyzing the first data to obtain a service dependency relationship of a software product as a basic dependency requirement;
s200: acquiring second data generated by the cloud areas under respective service operation scenes from a second data source, and analyzing the second data to obtain the service dependency relationship of the software products of the cloud areas as the actual dependency requirements of the cloud areas;
s300: summarizing the actual dependence requirements and the basic dependence requirements of the cloud areas respectively to generate distribution rules of the cloud areas;
s400: and distributing the software product to the cloud areas according to the distribution rules.
According to the content, distribution rules can be automatically configured for each cloud area, and configuration efficiency is improved; moreover, based on the distribution rule, the software products are distributed to the cloud areas under different service scenes according to the requirements, all the software products are prevented from being distributed to all the cloud areas according to the same strategy, the bandwidth cost and the storage cost are saved, and the distribution efficiency of the software products is improved.
Hereinafter, each step of the software product distribution method in the cloud scenario according to the embodiment of the present application will be described in detail.
Step S100: first data generated under continuous integration, development environment and test environment are obtained from a first data source, and the first data are analyzed to obtain the service dependency relationship of the software product to serve as a basic dependency requirement. Fig. 2 is a schematic diagram of stages of a software product distribution method in a multi-cloud scenario according to an embodiment of the present application, please refer to fig. 2, in a continuous integration, development, and testing stage, first data is obtained from a first data source (preferably, multiple data sources), where the first data is metadata, and business information recorded for each first data source is analyzed to obtain service dependencies on upstream and downstream of the software product, where the first data source includes, but is not limited to, a CMDB, a link tracking system, a configuration center, and Helm Chart.
Specifically, the CMDB is usually a relational database, and includes information of the full life cycle of the configuration items and relationships (including physical relationships, real-time communication relationships, non-real-time communication relationships, and dependency relationships) between the configuration items; the link tracking system is generally a distributed link tracking service realized based on OpenTracing specification, and can acquire a series of process information in a service calling process; the configuration center is generally configured with addresses and related parameters of databases, middleware and other software services which are depended by the application, and the addresses and the related parameters are stored in a text form, so that keywords can be extracted to judge whether a dependency relationship exists; the above Helm Chart: the container deployment orchestration service Helm's orchestration management file, because it is the orchestration that is used as the service itself, can directly resolve the dependency of the service from it. Among them, it is preferable to acquire data of the CMDB, which is the most widely used infrastructure by enterprises as a configuration management database and from which data acquisition is easy.
As an example, first, a suitable first data source recording service dependencies in a continuous integration, development, and testing environment is found and docked. Service dependencies are typically available through some external system, such as the CMDB and/or configuration center described above. Specifically, data can be acquired through the API interface, the data is usually stored in a Key-Value Key Value pair form, and information related to service dependence is screened out by comparing Key words of the Key Value pair. The keyword comparison is to compare the names of various infrastructures and services with or without the dependency of the configuration, such as the keywords mysql, kafka, foo, bar, where mysql and kafka are common infrastructures, and foo and bar are names of other services inside the company, for example, by reading the data of the configuration center through the API interface, two key-value pairs are obtained: mysql _ addr: 127.0.0.1 and mysql _ port: 3306, the information of these two key-value pairs is service dependent of software, meaning that the address information providing mysql database service is: addr 127.0.0.1 and port 3306. And then, the screened information is deduplicated to obtain the service dependency relationship of the software product to be used as a basic dependency requirement. Therefore, the dependency relationship between the newly created service and the online service can be acquired when the software product is not distributed. For example, the basic dependency requirements obtained at this stage are:
step S200: and acquiring second data generated by the cloud areas under respective service operation scenes from a second data source, and analyzing the second data to obtain the service dependency relationship of the software products of the cloud areas as the actual dependency requirements of the cloud areas. The second data source includes, but is not limited to, a link tracking system, configuration center data, a log analyzer, and possibly other products that the enterprise can directly or indirectly feedback to analyze the call between services, such as a "network traffic analyzer". The second data is metadata, and is service information recorded for each second data source. Preferably, the data of the configuration center is acquired, and differences of software in each environment are generally brought by different configurations, and the configuration often reflects dependence items applied to the current environment more accurately. It should be noted that, the data sources in step S100 and step S200 may be replaced as long as the actual software call dependency can be reflected. Only, the first data source in step S100 is more focused on the data source that can be used in the software production running phase, i.e. the production environment, and is more focused on the dependency items of various configurations; the second data source in step S200 focuses more on the analysis of the actual software call dependencies. The emphasis is in accordance with the current general status of internet companies.
As shown in fig. 2, for example, the cloudy area includes a cloud area α and a cloud area β, and the cloud area α and the cloud area β may be in any form of a private cloud, a public cloud, or the like. In a service operation scenario of the cloud area α, data generated by the second data source is collected, and then a service dependency relationship between upstream and downstream software is analyzed to serve as an actual dependency requirement of the cloud area α, for example:
similarly, in a service operation scenario of the cloud area β, data generated by the second data source is collected, and it should be noted here that, since the service operation scenarios of the cloud area α and the cloud area β may be independent, a selection of the second data source of the cloud area β may be different from a selection of the second data source of the cloud area α. Then, analyzing the service dependency relationship upstream and downstream of the software according to the collected data to serve as the actual dependency requirement of the cloud area β, for example:
step S300: and summarizing the actual dependence requirements and the basic dependence requirements of the cloud areas respectively to generate the distribution rules of the cloud areas. Based on the above steps S100 and S200, for the cloud area α, the actual dependency requirement and the basic dependency requirement of the cloud area α may be summarized, so that the distribution rule of the cloud area α is obtained as follows:
the distribution rule may be presented by a dependency requirement list containing the aggregated dependency requirements of the actual dependency requirements and the base dependency requirements of the cloud area α.
Similarly, for the cloud region β, the actual dependency requirement and the basic dependency requirement of the cloud region β may be summarized, so that the distribution rule of the cloud region β is obtained as follows:
the distribution rule may be presented by a dependency requirement list containing the aggregated dependency requirements of the actual dependency requirements and the base dependency requirements of the cloud region β.
Step S400: and distributing the software product to the cloud areas according to the distribution rules. For example, when the software product is distributed (including synchronized) to the cloud area α, whether the software product is to be sent (including synchronized) to the product library of the cloud area α can be determined by determining whether the software product is in the dependent requirement list of the cloud area α; when the software product is distributed (including synchronized) to the cloud area β, whether to send (including synchronizing) the software product to the product library of the cloud area β can be determined by determining whether the software product is in the dependent demand list of the cloud area β.
The cloud areas including the cloud area α and the cloud area β are only exemplary, and actually, the cloud areas of the embodiment of the present application may include more than two cloud areas, and the cloud areas may be private clouds or public clouds.
Therefore, the software product distribution method under the multi-cloud scene in the embodiment of the application can distribute the software products to the cloud areas under different business scenes according to needs, and avoids distributing all the software products to all the cloud areas according to a uniform distribution strategy in a 'one-shot' manner, so that the purposes of saving storage cost and bandwidth cost and improving the software product distribution efficiency are achieved. For further example, if the unified distribution policy corresponding to the cloud area x and the cloud area y includes the dependency requirement { a, b, c, d, e, f, g, h } according to the conventional software product distribution method, the software product needs to be sent to the cloud area x and the cloud area y according to the dependency requirement { a, b, c, d, e, f, g, h }. By adopting the scheme of the embodiment of the application, for example, the basic dependency requirements are { a, b, c }, the actual dependency requirements of the cloud area x are { d, e, f }, and the actual dependency requirements of the cloud area y are { g, h }, so that after the basic dependency requirements are analyzed, the dependency requirement list of the cloud area x comprises the dependency requirements { a, b, c, d, e, f }, and the dependency requirement list of the cloud area y comprises the dependency requirements { a, b, c, g, h }, is obtained, and then software products are distributed to the cloud area x and the cloud area y according to the respective dependency requirement lists. Therefore, the process realizes the distribution of the software products according to the needs, not only reduces the total amount of the software products to be sent, reduces the bandwidth cost and improves the distribution efficiency, but also reduces the total amount of the software products respectively received (including synchronization) by the cloud area x and the cloud area y and saves the storage cost.
It is worth noting that the embodiment of the present application needs to collect not only basic dependency requirements but also actual dependency requirements of each cloud area, because the basic dependency requirements only represent dependencies recorded in a system and in a non-online running process, and cannot cover the dependencies of software in an actual running process, and generally, software has dependency items with different configurations in each environment, and thus, the dependencies in each environment are different.
According to the method and the device, not only are actual dependence requirements of all cloud areas collected, but also basic dependence requirements are collected, because the existing software iteration speed is high, a plurality of pieces of software are deployed in a micro-service framework, newly increased dependence requirements among services are common, and when the newly increased dependence requirements of the services are not on-line operated, the dependence relationship can be recorded or explored by an off-line system, so that corresponding software products can be prepared in advance.
Therefore, according to the above, delivery requirements (i.e., distribution rules) customized for each cloud area can be generated and applied to the automatic distribution flow of the software product. Thereby enabling distribution of software products to cloud regions according to distribution rules.
In addition, after extraction, analysis and summarization, the obtained target data can reflect the calling and dependency relationship among services, and can be used as the basis for product delivery and distribution, and can also be used for technologies such as service safety analysis and service network flow analysis.
In the embodiment of the present application, there are also multiple ways for uploading (including synchronization) a software product, and in a scenario of a public cloud or a private cloud having a product library, for example, the method includes:
(1) product libraries compatible with multiple formats: uploading by using a special client or an SDK thereof;
(2) an object storage service: uploading the software product through a client or an SDK, and downloading the software product during deployment;
(3) container mirror image warehouse: and carrying out mirror image uploading by using the Docker client.
As one example, the distribution of software artifacts is done using a client or SDK of a public cloud or private cloud artifact library service. In the case of a public cloud or a private cloud without a product library, a general-purpose protocol such as HTTP, FTP, SFTP, SSH, or the like may be used as a software product distribution method.
As an implementation manner, a "multi-copy synchronization" function of container mirroring may be provided around a "multi-copy synchronization" function of a software product, such as an open source container mirroring center "Harbor", and in the synchronization function, a specific product meeting requirements may be filtered through a regular expression. But such functionality does not meet the need for "synchronization on demand".
Therefore, further, the software product distribution method in the multi-cloud scenario in the embodiment of the present application further includes: and correcting and supplementing the dependency requirement list of each cloud area according to the actual dependency requirement of each cloud area, wherein the actual dependency requirement comprises online service configuration data and software calling historical data. Therefore, the dependency requirement list can be updated according to the actual running condition on the line, and the purpose of synchronization according to the requirement is achieved. For example, when a new service (i.e., configuration of a new dependency item) is added to a certain cloud region, the dependency requirement list of the cloud region is also updated, so as to implement on-demand synchronization.
Furthermore, the expired dependencies in the dependency requirement list are updated and removed regularly, unnecessary synchronization of the software products can be reduced by timely removing the expired service dependencies, bandwidth cost and storage cost are reduced, and distribution efficiency of the software products is improved. Optionally, if no existing dependent item is detected in the dependency requirement list within a specified time limit, it may be determined that the service of the dependent item is offline in the corresponding cloud area.
The embodiment of the application also provides a software product distribution device in a multi-cloud scene, and the device is used for realizing the embodiment and the preferred embodiment. The term "module" as used below may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated. Fig. 3 is a schematic relationship diagram of a software product distribution apparatus and data sources in a multi-cloud scenario according to an embodiment of the present application, and as shown in fig. 3, the apparatus includes: the system comprises an external data source docking module, a dependency analysis processing module, a dependency summary storage module and a product distribution module, wherein:
the external data source docking module is used for acquiring data generated in a continuous integration, research and development environment and a test environment from a first data source; and acquiring data generated by the cloud areas under respective service operation scenes from a second data source. The module comprises an API docking layer for integrating all data sources, is used for initiating requests to acquire data, and is serialized and standardized in format.
The dependency analysis processing module is used for analyzing the first data to obtain a service dependency relationship of the software product as a basic dependency requirement; and analyzing the second data of each cloud area to obtain the service dependency relationship of the software product of each cloud area as the actual dependency requirement of each cloud area, wherein the first data and the second data are metadata and are business information recorded by each data source. For example, the obtained data is used for comparing key words and key value pairs, and the dependency requirements are obtained through analysis.
The dependency summarizing storage module is used for summarizing the actual dependency requirements of the cloud areas and the basic dependency requirements respectively, generating distribution rules of the cloud areas, and persistently storing generated results.
The product distribution module is used for distributing the software products to the cloud areas according to the distribution rules. For example, software artifacts are distributed (including synchronized) to the artifact libraries of the various cloud regions using clients of a public cloud artifact library service or SDKs or general transport protocols within the internet.
As an embodiment, each module of the software product distribution device in the cloudy scene executes the following steps:
step 1: the external data source docking module docks each data source API and receives metadata information, wherein the metadata is service information recorded by each data source;
step 2: processing the data acquired in the step 1 in a dependency analysis processing module, screening out information related to service dependency in metadata by a keyword matching method, and sending the screened information to a dependency summary storage module after the screened information is deduplicated;
and step 3: the dependence summarizing storage module analyzes dependence requirements for each cloud area to generate a dependence requirement list, and performs persistent storage on the generated dependence requirement list of each cloud area, and provides the dependence requirement list to the product distribution module, and the product distribution module can call data of the dependence requirement list when needed. If the data is the data of the release area, the data needs to be aligned and periodically updated, and the offline service is removed in time.
And 4, step 4: when the product distribution module distributes (including synchronization) the software products, the software products can be distributed to the corresponding cloud areas according to the dependency requirement list generated in the step 3, and then the software products can be distributed to the corresponding cloud area product libraries as required.
The above modules may be functional modules or program modules, and may be implemented by software or hardware. For a module implemented by hardware, the modules may be located in the same processor; or the modules can be respectively positioned in different processors in any combination.
Fig. 4 is a block diagram of an electronic device according to an embodiment of the present application, and as shown in fig. 4, the electronic device may include a processor 81 and a memory 82 storing computer program instructions.
Specifically, the processor 81 may include a Central Processing Unit (CPU), or A Specific Integrated Circuit (ASIC), or may be configured to implement one or more Integrated circuits of the embodiments of the present Application.
The memory 82 may be used to store or cache various data files for processing and/or communication use, as well as possible computer program instructions executed by the processor 81.
The processor 81 reads and executes the computer program instructions stored in the memory 82 to implement the software product distribution method in any one of the above-described embodiments in a cloudy scene.
In some of these embodiments, the electronic device may also include a communication interface 83 and a bus 80. As shown in fig. 4, the processor 81, the memory 82, and the communication interface 83 are connected via the bus 80 to complete communication therebetween.
The communication interface 83 is used for implementing communication between modules, devices, units and/or equipment in the embodiment of the present application. The communication interface 83 may also enable communication with other components such as: the data communication is carried out among external equipment, image/data acquisition equipment, a database, external storage, an image/data processing workstation and the like.
The bus 80 includes hardware, software, or both to couple the components of the electronic device to one another. Bus 80 includes, but is not limited to, at least one of the following: data Bus (Data Bus), Address Bus (Address Bus), Control Bus (Control Bus), Expansion Bus (Expansion Bus), and Local Bus (Local Bus). By way of example, and not limitation, Bus 80 may include an Accelerated Graphics Port (AGP) or other Graphics Bus, an Enhanced Industry Standard Architecture (EISA) Bus, a Front-Side Bus (FSB), a Hyper Transport (HT) Interconnect, an ISA (ISA) Bus, an InfiniBand (InfiniBand) Interconnect, a Low Pin Count (LPC) Bus, a memory Bus, a microchannel Architecture (MCA) Bus, a PCI (Peripheral Component Interconnect) Bus, a PCI-Express (PCI-X) Bus, a Serial Advanced Technology Attachment (SATA) Bus, a Video Electronics Bus (audio Electronics Association), abbreviated VLB) bus or other suitable bus or a combination of two or more of these. Bus 80 may include one or more buses, where appropriate. Although specific buses are described and shown in the embodiments of the application, any suitable buses or interconnects are contemplated by the application.
In addition, in combination with the software product distribution method in the foregoing embodiment under a cloudy scene, embodiments of the present application may provide a computer-readable storage medium to implement the method. The computer readable storage medium having stored thereon computer program instructions; the computer program instructions, when executed by a processor, implement the software product distribution method in any one of the above embodiments in a cloudy scenario.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.
Claims (9)
1. A software product distribution method under a multi-cloud scene is characterized by comprising the following steps:
acquiring first data generated under continuous integration, development environment and test environment from a first data source, and analyzing the first data to obtain a service dependency relationship of a software product as a basic dependency requirement, wherein the first data source comprises at least one of a CMDB, a link tracking system, a configuration center and Helm Chart;
acquiring second data generated by a plurality of cloud areas under respective service operation scenes from a second data source, and analyzing the second data to obtain a service dependency relationship of the software product of each cloud area as an actual dependency requirement of each cloud area;
summarizing the actual dependence requirements of each cloud area and the basic dependence requirements respectively to generate distribution rules of each cloud area, wherein the distribution rules are presented by a dependence requirement list, and the dependence requirement list comprises the summarized actual dependence requirements and the basic dependence requirements;
and distributing the software product to the cloud areas according to the distribution rules.
2. The method for software product distribution in a cloudy scenario according to claim 1, wherein the second data source comprises at least one of a link tracking system, a configuration center, a log analyzer, and a network traffic analyzer.
3. The method for distributing software products under the cloudy scenario according to claim 1, wherein in a case that the first data source is a CMDB and/or a configuration center, the obtaining first data generated in the continuous integration, development environment and test environment from the first data source, analyzing the first data, and obtaining the service dependency relationship of the software product as the basic dependency requirement comprises:
acquiring first data generated in a continuous integration, development environment and test environment from the CMDB and/or the configuration center, wherein the first data is stored in a Key-Value Key Value pair form;
screening out information related to service dependence by comparing key words of the key value pairs;
and removing the duplicate of the screened information to obtain the service dependency relationship of the software product as a basic dependency requirement.
4. The method for distributing software products under the cloudy scenario according to claim 1, wherein after distributing the software products to the cloud areas according to the distribution rules, the method further comprises:
and updating and removing the expired dependent demands in the dependent demand list regularly.
5. The method for distributing software products under the multi-cloud scenario of claim 4, wherein after generating the distribution rules for each cloud area, the method further comprises:
correcting and supplementing the dependency requirement list of each cloud area according to the actual dependency requirement of each cloud area, wherein the actual dependency requirement comprises online service configuration data and software calling historical data.
6. The method for distributing software products under the cloudy scene according to claim 1, wherein the distributing software products to the cloud areas according to the distribution rules comprises:
uploading a software product through a client or an SDK under the scene of a public cloud or a private cloud with a product library; when a container mirror image warehouse is provided, uploading a software product through a Docker client mirror image;
in the scenario of a public cloud or a private cloud without an article library, the software article is uploaded using HTTP, FTP, SFTP, or SSH protocols.
7. A software product distribution apparatus in a cloudy scene, comprising:
the external data source docking module is used for acquiring first data generated in a continuous integration, research and development environment and a test environment from a first data source; acquiring second data generated by the cloud areas under respective service operation scenes from a second data source;
the dependence analysis processing module is used for analyzing the first data to obtain a service dependence relation of the software product as a basic dependence requirement; analyzing the second data of each cloud area to obtain a service dependency relationship of the software product of each cloud area as an actual dependency requirement of each cloud area;
the dependency summary storage module is configured to summarize the actual dependency requirements of each cloud area and the basic dependency requirements, and generate distribution rules of each cloud area, where the distribution rules are presented by a dependency requirement list, and the dependency requirement list includes the summarized actual dependency requirements and the basic dependency requirements;
and the product distribution module is used for distributing the software products to the cloud areas according to the distribution rules.
8. An electronic device comprising a processor and a storage medium storing a computer program, wherein the computer program, when executed by the processor, implements the method for software product distribution in a cloudy scene according to any one of claims 1 to 6.
9. A computer-readable storage medium, on which a computer program is stored, which, when executed by a processor, implements a method for software product distribution in a cloudy scenario according to any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110142117.3A CN112463181B (en) | 2021-02-02 | 2021-02-02 | Software product distribution method, device, equipment and storage medium under multi-cloud scene |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110142117.3A CN112463181B (en) | 2021-02-02 | 2021-02-02 | Software product distribution method, device, equipment and storage medium under multi-cloud scene |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112463181A CN112463181A (en) | 2021-03-09 |
| CN112463181B true CN112463181B (en) | 2021-06-01 |
Family
ID=74802754
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110142117.3A Active CN112463181B (en) | 2021-02-02 | 2021-02-02 | Software product distribution method, device, equipment and storage medium under multi-cloud scene |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112463181B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113542433B (en) * | 2021-09-15 | 2021-12-21 | 广州嘉为科技有限公司 | DevOps-based product synchronization method and device |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014058411A1 (en) * | 2012-10-08 | 2014-04-17 | Hewlett-Packard Development Company, L.P. | Hybrid cloud environment |
| CN104754055A (en) * | 2015-04-03 | 2015-07-01 | 易云捷讯科技（北京）有限公司 | Safety cloud storage method for use in multi-cloud environment |
| CN111651168A (en) * | 2020-05-13 | 2020-09-11 | 无锡江南计算技术研究所 | Operating system customization method oriented to cloud native application scene |
| CN111835820A (en) * | 2020-05-21 | 2020-10-27 | 上海灏拓智能科技有限公司 | System and method for realizing cloud management |
-
2021
- 2021-02-02 CN CN202110142117.3A patent/CN112463181B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN112463181A (en) | 2021-03-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111736775B (en) | Multi-source storage method, device, computer system and storage medium | |
| CN112559475B (en) | Data real-time capturing and transmitting method and system | |
| CN113535856B (en) | Data synchronization method and system | |
| CN107896170B (en) | Insure the monitoring method and device of application system | |
| CN112527649A (en) | Test case generation method and device | |
| CN106777046A (en) | A kind of data analysing method based on nginx daily records | |
| US8417688B2 (en) | Converting two-tier resource mapping to one-tier resource mapping | |
| CN112463181B (en) | Software product distribution method, device, equipment and storage medium under multi-cloud scene | |
| CN110309206B (en) | Order information acquisition method and system | |
| CN112070504A (en) | Content checking method and device for block chain transaction | |
| CN112016285B (en) | Logistics information processing method and processing system | |
| CN114679458B (en) | Privatized deployment method and device applicable to multiple clouds | |
| CN113282347B (en) | Plug-in operation method, device, equipment and storage medium | |
| CN110688355A (en) | Method and device for changing container state | |
| CN111401819B (en) | Intersystem data pushing method and system | |
| CN111274316B (en) | Method and device for executing multi-level data stream task, electronic equipment and storage medium | |
| CN115695587A (en) | Service data processing system, method, device and storage medium | |
| CN114490509A (en) | Tracking change data capture log history | |
| CN113704203A (en) | Log file processing method and device | |
| CN113568966A (en) | Data processing method and system used between ODS layer and DW layer | |
| CN112799797A (en) | Task management method and device | |
| US10528400B2 (en) | Detecting deadlock in a cluster environment using big data analytics | |
| US20220300462A1 (en) | Optimizing synchronization of content management servers | |
| CN113760836B (en) | Wide table calculation method and device | |
| CN110740046A (en) | Method and device for analyzing service contract |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |