CN110704061B - Running method and device for deploying and delivering payment pieces based on micro-services - Google Patents
Running method and device for deploying and delivering payment pieces based on micro-services Download PDFInfo
- Publication number
- CN110704061B CN110704061B CN201910863539.2A CN201910863539A CN110704061B CN 110704061 B CN110704061 B CN 110704061B CN 201910863539 A CN201910863539 A CN 201910863539A CN 110704061 B CN110704061 B CN 110704061B
- Authority
- CN
- China
- Prior art keywords
- service
- module
- calling
- package
- modules
- 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/40—Transformation of program code
- G06F8/41—Compilation
-
- 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)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The application provides a method and a device for operating a deployed delivery part based on micro-services, wherein the method comprises the following steps: when an actual service requirement exists, acquiring an implementation packet corresponding to each module contained in the actual service requirement from an implementation packet set; the implementation package set issues independent implementation packages compiled by aiming at a plurality of modules, the modules are obtained by splitting services according to predefined service requirements, and each module in the modules provides at least one service; determining that a service call corresponding to the actual service requirement is from an internal module to invoke an internal call service, and from an external module to invoke an external call service; aggregating the obtained implementation packages into a deployment package to generate a deployment delivery part corresponding to the actual service requirement; and calling the internal calling service by adopting a local calling process, and calling the external calling service by adopting a remote calling process so as to run the deployment delivery member.
Description
Technical Field
The present application relates to the field of micro service system technologies, and in particular, to a method and an apparatus for deploying a delivery part based on micro services.
Background
Service splitting is an important part of the design phase when building microservice systems. In the development phase, services can be split by function to corresponding modules (each module providing a specific service), and a developer compiles a deployment package of the respective modules. The finer the granularity of service splitting, the simpler the function realized by each module, so that the lower the development complexity, and the advantage of micro-service development can be fully embodied. And in the operation and maintenance deployment stage, the deployment package is used as a deployment delivery member for deployment and operation and maintenance. When the granularity of service splitting is fine, a large number of deployment deliverables will cause difficulty in deployment and operation and maintenance. Therefore, from the point of view of deploying the operation and maintenance, the number of deployed deliverables should be minimized. In summary, service splitting faces a contradiction: the finer the granularity of the service split is, the better the development is; and the smaller the number of deployed deliverables the better when deploying the operation and maintenance.
In the related art, in order to reduce the pressure of deploying operation and maintenance, the granularity of service splitting is controlled within a certain reasonable range by balancing the advantages and disadvantages of splitting and delivering.
However, the compromise of the granularity of splitting the service increases the development complexity, so that the advantages of the micro-service system in the development process cannot be exerted, and the development efficiency is reduced. Meanwhile, the combination between services is not flexible and free enough, and the basic module codes are difficult to multiplex under different service scenes.
Disclosure of Invention
In view of this, the present application provides an operating method and apparatus for deploying and delivering pieces based on micro-services, an electronic device, and a computer-readable storage medium, which can freely aggregate a specified number of deploying and delivering pieces according to business requirements without limiting granularity of service splitting.
In order to achieve the above purpose, the present application provides the following technical solutions:
according to a first aspect of the present application, a method for operating a microservice-based deployment delivery part is provided, comprising:
when an actual service demand exists, acquiring an implementation package corresponding to each module contained in the actual service demand from an implementation package set; the implementation package set issues independent implementation packages compiled by aiming at a plurality of modules, the modules are obtained by splitting services according to predefined service requirements, and each module in the modules provides at least one service;
determining that a service call corresponding to the actual service requirement is from an internal call service of an internal module and from an external call service of an external module;
aggregating the obtained implementation packages into a deployment package to generate a deployment delivery part corresponding to the actual service requirement;
and calling the internal calling service by adopting a local calling process, and calling the external calling service by adopting a remote calling process so as to run the deployment delivery member.
According to a second aspect of the present application, there is provided an operating apparatus for deploying a delivery part based on a micro service, comprising:
the system comprises an acquisition unit, a service processing unit and a service processing unit, wherein the acquisition unit is used for acquiring an implementation package corresponding to each module contained in an actual service demand from an implementation package set when the actual service demand exists; the implementation package set issues independent implementation packages compiled by aiming at a plurality of modules, the modules are obtained by splitting services according to predefined service requirements, and each module in the modules provides at least one service;
the service determining unit is used for determining that the service corresponding to the actual service requirement calls an internal calling service from an internal module and calls an external calling service from an external module;
the aggregation unit is used for aggregating the acquired implementation packages into a deployment package so as to generate a deployment delivery piece corresponding to the actual service requirement;
and the operation unit is used for calling the internal calling service by adopting a local calling process and calling the external calling service by adopting a remote calling process so as to operate the deployment delivery part.
According to a third aspect of the present application, there is provided an electronic device comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of operating a microservice-based deployment delivery component as described in any of the above embodiments by executing the executable instructions.
According to a fourth aspect of the present application, a computer-readable storage medium is proposed, on which computer instructions are stored, which instructions, when executed by a processor, carry out the steps of the method according to any of the previous embodiments.
According to the technical scheme, the development layer and the delivery layer are separated, the granularity of service splitting is not limited during development, the service can be split to the corresponding module and the implementation packages of the modules can be compiled at the development layer according to predefined business requirements, the implementation packages are independent of one another, and the development difficulty is reduced. During delivery, the implementation packages corresponding to the required modules can be aggregated into the deployment package according to actual service requirements on a delivery layer so as to generate the deployment delivery piece of the service, so that the implementation packages can be freely combined and referenced as required, and the efficiency of generating the deployment delivery piece is improved. Meanwhile, the realization packets of the same module can be multiplexed under different service scenes.
Drawings
FIG. 1 is a flow chart illustrating a method for generating a microservice-based deployment delivery in accordance with an exemplary embodiment of the present application.
FIG. 2 is a flow chart illustrating another method for generating a microservice-based deployment delivery in accordance with an exemplary embodiment of the present application.
Fig. 3 is a schematic diagram of an aggregate implementation package according to an exemplary embodiment of the present application.
Fig. 4 is a schematic structural diagram of an electronic device according to an exemplary embodiment of the present application.
FIG. 5 is a block diagram illustrating an apparatus for generating a microservice-based deployment delivery in accordance with an exemplary embodiment of the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the application, as detailed in the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if," as used herein, may be interpreted as "at \8230; \8230when" or "when 8230; \823030when" or "in response to a determination," depending on the context.
Service splitting is an important part of the design phase when building microservice systems. In the development phase, services can be split to corresponding modules according to functions, and deployment packages of the modules are compiled by developers. The finer the granularity of the service split, the simpler the functionality each module can implement. On one hand, each module independently maintains codes, developers only need to care about the service interface provided by each module without paying attention to the whole architecture, and therefore quality and progress can be controlled more favorably, and development speed is increased. On the other hand, the finer the module is split, the finer the granularity of code authority control, and the better the advantage of microservice development can be utilized. And in the operation and maintenance deployment stage, the deployment package is used as a deployment delivery part for deployment and operation and maintenance. When the granularity of the service split is fine, the operation and maintenance cost of the micro-service system is positively correlated with the number of the deployed delivery parts, and the deployment and operation and maintenance difficulty is large due to the large number of the deployed delivery parts. On one hand, the system for deploying the delivery part in a large scale has higher dependence on technical means such as configuration management, log management, monitoring, fault alarm and the like. On the other hand, dependency management and version control between services, and version management and continuous delivery of mass-deployed delivery parts all present great challenges. Therefore, from the point of view of deploying the operation and maintenance, the number of deployed deliverables should be minimized. In summary, service splitting faces a contradiction: the finer the granularity of the service split is, the better the development is; and the smaller the number of deployed deliverables the better when deploying the operation and maintenance.
In the related art, a compromise mode of 'compromise' is adopted, and the granularity of service splitting is controlled within a certain reasonable range, so that the pressure of deploying operation and maintenance is reduced. However, the compromise of the granularity of splitting the service increases the development complexity, so that the advantages of the micro-service system in the development process cannot be exerted, and the development efficiency is reduced. Meanwhile, the combination between services is not flexible and free enough, and the basic module codes are difficult to multiplex under different service scenes.
Therefore, the method and the device for generating the deployment delivery pieces are improved to solve the technical problems in the related art, and the specified number of deployment delivery pieces can be freely aggregated according to business requirements under the condition that the granularity of service splitting is not limited. The following examples are given for illustrative purposes.
FIG. 1 is a flow chart illustrating a method for generating a microservice-based deployment delivery for an exemplary embodiment of the present application. As shown in fig. 1, the method applied to the client on the developer side may include the following steps:
And 104, compiling an independent implementation package for each module, and issuing the implementation package into an implementation package set.
And 106, when an actual service requirement exists, acquiring an implementation package corresponding to each module contained in the actual service requirement from the implementation package set.
And 108, aggregating the acquired implementation packages into a deployment package to generate a deployment delivery piece corresponding to the actual service requirement.
In the embodiment, a development layer and a delivery layer are separated, services are split to each module on the development layer in advance according to predefined business requirements (the granularity of service splitting is not limited), and a corresponding implementation package is compiled; on the delivery layer, instead of using the deployment package compiled by the development layer (generated by packaging the implementation package and the running library relied on for running test), the implementation packages corresponding to the modules included in the service to be aggregated (i.e. the service corresponding to the actual service requirement) are aggregated to obtain the deployment package corresponding to the service, so as to generate the deployment delivery member corresponding to the actual service requirement. By the method for generating the deployment delivery pieces, the granularity of service splitting is not limited, and the deployment delivery pieces with the specified quantity can be freely aggregated according to the service requirements.
Since the development layer and the delivery layer are separated, the present application involves the following problems:
1. separating deployment packages from implementation packages
Because the deployment package compiled by the development layer is not directly used at the delivery layer, the implementation package of each module can be separated from the deployment package, and the implementation package of each module is released to a local private warehouse, so that version control and dependency management of the delivery layer are facilitated.
2. Supporting multiple data sources
After the service is split, since the implementation packages corresponding to the modules need to be independently run and tested in the development stage (i.e., the implementation packages and the dependent runtime libraries are packaged to generate corresponding deployment packages for running and testing), a corresponding database can be configured for each module, and the database is used for the corresponding module to read and write related data. By configuring the corresponding database for each module, the complexity of subsequent aggregation services can be reduced, and the aggregation efficiency can be improved. Of course, the number of the databases can be flexibly configured according to actual conditions. For example, a database may also be configured for every two modules, or the same database may be configured for all modules; this application is not intended to be limiting. In the subsequent aggregation service, in order to reduce the complexity, the data driving framework needs to support multiple data source configurations. Meanwhile, when initiating a database operation, the data sources need to be distinguished using module identifications.
Based on the support of multiple data sources, in order to ensure the transparent access of development teams to a database (namely, the database configuration used by each development team exists in the production environment at the same time, the traditional access configuration and access mode of the database only having a single module can be adopted), support the aggregate release, and provide the capability of being compatible with multiple data sources, the database access can be isolated according to the module database configuration according to each module configuration based on a dynamic agent technology, and the agent class is responsible for managing the corresponding relation between each module and the database configuration, so that the transparent access to multiple data sources is realized. For example, the service S includes a module a and a module B, before the service S comes online, the module a and the module B are developed and implemented by respective independent development teams, the module a and the module B are configured based on different databases, and the corresponding relationship between the package name of the module and the database is configured by agents; then, when the service S initiates a database operation, the corresponding database can be determined according to the corresponding relationship.
3. Versions of unified third party data packages
There is a possibility of aggregation between different modules, which are likely to rely on the same third party data package. Therefore, in order to improve the efficiency of aggregation, the versions of the third-party data packets may be uniformly constrained, that is, the versions of the same third-party data packets depended on by different modules are the same. Based on the mechanism of the uniform version, the uniform version of all the third-party data packages can be declared by the top-level data package; the version of the third party data package on which any module depends may then be described in the following way: declaring the version of the top level packet to be used, and the packets on which any of the modules depends. The version of the data packet depended on by any module can be described by only declaring the version of the top-level data packet without respectively describing the versions of all the data packets, so that the efficiency of declaring the version of the third-party data packet is improved, and the efficiency of subsequent aggregation is favorably accelerated.
4. Identifying call relationships between services
The micro service system has a large number of calling relations among services, the source of the service called by the service to be aggregated after aggregation may change, and the service called by the module included in the service to be aggregated may change from external calling to internal calling. Therefore, before the aggregation operation is executed, the internal calling service from the internal module and the external calling service from the external module are determined to be called by the business corresponding to the actual business requirement; wherein, when the deployment delivery piece is running, the internal calling service is called by a local calling process, and the external calling service is called by a remote calling process. By determining the external calling service and the internal calling service, the internal calling service from the internal module can be prevented from being called by adopting a remote calling process, so that the efficiency of calling the service when the delivery part is subsequently deployed is improved.
Specifically, the provision service sub-lists of the modules may be merged to generate an aggregated provision service list, the provision service sub-lists are used to record services provided by the corresponding modules, the provision service list is used to record services provided by the service to be aggregated, and the call service sub-lists of the modules are merged to generate an aggregated call service list, the call service sub-lists are used to record services called by the corresponding modules, and the call service lists are used to record services called by the service to be aggregated; and then determining the repeated service which is the same in the providing service list and the calling service list, taking the repeated service as the internal calling service, and taking other services which are different from the repeated service in the calling service list as the external calling service.
According to the technical scheme, the development layer and the delivery layer are separated, the granularity of service splitting is not limited during development, the service can be split to the corresponding module and the implementation packages of the modules can be compiled at the development layer according to predefined business requirements, the implementation packages are independent from one another, and the development difficulty is reduced. During delivery, the implementation packages corresponding to the required modules can be aggregated into the deployment package according to actual service requirements on a delivery layer so as to generate the deployment delivery piece of the service, so that the implementation packages can be freely combined and referenced as required, and the efficiency of generating the deployment delivery piece is improved. Meanwhile, the realization packet of the same module can be multiplexed under different service scenes.
For the convenience of understanding, the following takes java development as an example, and the technical solution of the present application is further explained with reference to the drawings. When the technical scheme based on the application is realized, the processing process can be divided into two stages: 1) The first stage is as follows: a design stage; 2) And a second stage: a polymerization stage; these two stages are described in detail below.
1) Design phase
In the design stage, a developer can split services into corresponding modules according to predefined business requirements on a development layer, the splitting granularity can be as fine as possible, and each module provides at least one service. For example, services may be split to modules such as e-commerce, orders, members, merchandise, offers, payments, returns, chargebacks, and the like. After the service is split, each module is handed to different development teams to be compiled to generate an implementation package (in the embodiment, each implementation package is a jar package), and the implementation packages are distributed to an implementation package set, and each team only needs to care about the dependency of interfaces. During development of each module, the implementation package and the dependent runtime library may be packaged to generate a corresponding deployment package (in this embodiment, a war package) for the runtime test. Of course, the granularity of the split (i.e. the predefined business requirement) can be flexibly set by the developer according to the actual situation, which is not limited in this application.
2) Polymerisation stage
Based on the compiling of the implementation packages of the modules in the design stage, the implementation packages of the modules can be selected according to the actual service requirements of the services to be aggregated, so as to aggregate the deployment packages of the services to be aggregated. Referring to fig. 2, fig. 2 is a flowchart illustrating another method for generating a microservice-based deployment delivery according to an exemplary embodiment of the present application. As shown in fig. 2, the method applied to the client on the developer side may include the following steps:
In this embodiment, the implementation package corresponding to each module included in the service to be aggregated may be obtained according to an actual service requirement. The implementation packages of the modules included in the service to be aggregated are compiled and generated in advance by a developer in a design stage. For example, assuming that the service to be aggregated is "purchase goods", the implementation package of the modules "goods", "offers", and "payments" may be acquired.
In this embodiment, it is determined that the traffic to be aggregated (i.e., the traffic corresponding to the actual traffic demand) calls an internal invocation service from the internal module, and calls an external invocation service from the external module.
In this embodiment, the source of the service called by the service to be aggregated after aggregation may change, and the service called by the module included in the service to be aggregated may change from an external call to an internal call. Thus, internal and external invocation services may be identified prior to performing the aggregation operation. And when the subsequent deployment delivery piece of the service to be aggregated operates, the internal calling service is called by adopting a local calling process, and the external calling service is called by adopting a remote calling process. By identifying the internal calling service and the external calling service, the internal calling service from the internal module can be prevented from being called by adopting a remote calling process, so that the efficiency of calling the service when the delivery part is subsequently deployed is improved.
For example, suppose that service 1 comprises modules a, B, D, and the situation of each module providing and invoking a service is shown in table 1:
| module | Providing a sub-list of services | Invoking a service sublist |
| A | a.service_1 | b.service_2 |
| B | b.service_1、b.service_2 | / |
| D | / | c.service_1 |
TABLE 1
Then, before aggregation, the service profile of module a is:
Provider:a.service_1；
Consumer:b.service_2。
the service profile of module B is:
Provider:b.service_1、b.service_2。
the service profile of module D is:
Consumer:c.service_1。
wherein, the "Provider" represents the service provided by the module; the "Consumer" represents a module calling an external calling service from an external module.
The provision service list can be obtained by merging the provision service sub-lists of the respective modules: a.service _1, b.service _2; and combining the call service sub-lists of the modules to obtain a call service list: b.service _2, c.service _1. Wherein, the duplicate service in the providing service list and the calling service list can be determined as b.service _2. Then, in the aggregated service 1, the internal call service is b.service _2, and the external call service is c.service _1. Meanwhile, before aggregation, a module A calls b.service _2, and a remote calling process is needed; after the aggregation, since the module a and the module B are in the same service, the module a calls b.service _2 only by adopting a local calling process.
Based on the above identification process, the service declaration file of the aggregated service 1 is:
Provider：a.service_1、b.service_1、b.service_2；
Consumer:c.service_1。
In this embodiment, an aggregation operation is implemented at a delivery layer, and the obtained implementation package and the runtime library on which each implementation package depends are jointly packaged and aggregated into a deployment package of the service to be aggregated. The deployment package of the service is obtained by aggregating the implementation packages corresponding to the modules contained in the service to be aggregated so as to generate the deployment delivery pieces corresponding to the service to be aggregated, so that the granularity of service splitting is not limited, the specified number of deployment delivery pieces can be freely aggregated according to service requirements, the implementation packages can be freely combined and quoted according to requirements, and the efficiency of generating the deployment delivery pieces is improved. Meanwhile, the realization packet of the same module can be multiplexed under different service scenes.
For example, as shown in fig. 3, assuming the service 2 includes modules a and C, for example, as described above. Then, the deployment package 1 of the service 1 can be formed by obtaining the implementation packages of the modules a, B, and D and packing and aggregating the implementation packages together with the runtime libraries on which the implementation packages of the modules a, B, and D depend; the deployment package 2 of the service 2 is formed by obtaining the implementation packages of the modules A and C and packaging and aggregating the implementation packages and the operation libraries depended on by the implementation packages of the modules A and C. Wherein, the implementation package of module a is used in both service 1 and service 2.
In the technical solution of the present application, since the development layer and the delivery layer are separated, the present application involves the following problems:
1. separating deployment packages from implementation packages
Since the deployment package compiled by the development layer is not directly used at the delivery layer, the implementation package of each module can be separated from the deployment package, and the implementation package of each module (i.e., the implementation package in the implementation package set) is released to the local private warehouse, so as to facilitate version control and dependency management of the delivery layer. For example, the jar packages of modules A, B, C, D in FIG. 3 can be published uniformly to the maven library.
2. Supporting multiple data sources
A respective database may be configured for each module, the database being used for the respective module to read and write the relevant data. By configuring the corresponding database for each module, the complexity of subsequent aggregation services can be reduced, and the aggregation efficiency can be improved. Of course, the number of the databases can be flexibly configured according to actual conditions. For example, a database may also be configured for every two modules, or the same database may be configured for all modules; this application is not intended to be limiting.
For example, as shown in fig. 3, a service 1 aggregates three modules a, B, and D, and configures databases a, B, and D for the modules a, B, and D, respectively, to read and write related data. It should be noted that, in the design phase, a developer needs to package each implementation package (implementation package a, B, D) and the dependent runtime library to generate a corresponding deployment package (deployment package a, B, D) for running test, and at this time, the databases a, B, D are used; when the service 1 is operated after aggregation, the deployment package 1 corresponding to the service 1 is operated, and the databases a, B, and D are also required to read and write the relevant data of the modules a, B, and D, respectively. Meanwhile, 3 database connections need to be established when the service 1 operates, the connection pools can be named as sql-factor-a, sql-factor-b and sql-factor-c respectively, and when the service A initiates database operation, databases of different modules can be distinguished by specifying the names of the connection pools. Similarly, corresponding to service 2, the manner of configuring and using the database is similar to that of service 1, and is not described herein again.
Based on the support for multiple data sources, in order to ensure transparent access of development teams to databases (namely, database configurations used by each development team exist in a production environment at the same time, the traditional access configuration and access mode of databases with only a single module can be adopted), support aggregation release, and provide the capability of being compatible with multiple data sources, the database access can be isolated according to the module database configuration according to each module configuration based on a dynamic agent technology, and the agent is responsible for managing the corresponding relation between each module and the database configuration, so that the transparent access for multiple data sources is realized.
For example, the service 1 includes a module a, a module B, and a module D, before the service 1 is online, the module a, the module B, and the module D are developed and implemented by respective independent development teams, the module a, the module B, and the module D are configured based on different databases, and a corresponding relationship between a package name of the module and the database shown in table 2 is configured by an agent:
| module | Package name of module | Database with a plurality of databases |
| Module A | a.b.a | A |
| Module B | a.b.b | B |
| Module D | a.b.d | D |
TABLE 2
Then, when the service 1 initiates a database operation, the package names of the modules are determined, the corresponding database is determined according to the determined package names and the corresponding relationship in the table 2, and then the determined database is accessed.
3. Versions of unified third party data packages
There is a possibility of aggregation between different modules, which are likely to rely on the same third party data package. Therefore, in order to improve the aggregation efficiency, uniform constraint can be performed on the versions of the third-party data packets, that is, the versions of the same third-party data packets depended on by different modules to be aggregated are the same. Specifically, the versions of the third-party data packages can be maintained and managed uniformly at the top layer, all modules rely on the top-layer data packages to declare the versions of the third-party data packages, and each module only declares the relied third-party data packages and does not declare the versions of the data packages.
For example, assume that the service Q includes a module a, a module B, and a module C, and the configuration of each module depending on the third-party data packet is shown in table 3:
| module A | Module B | Module C | |
| Data packet a | Version 1.0 | Version 2.0 | Version 1.1 |
| Data packet b | Version 1.0 | / | Version 1.0 |
| Data packet c | Version 1.0 | / | Version 2.1 |
| Data packet d | / | Version 1.0 | Version 1.1 |
TABLE 3
When the module a, the module B, and the module C are aggregated into the service Q, the version summary condition of the third-party data packet is as follows:
the data packet a has three versions, namely 1.0 version, 2.0 version and 1.1 version;
packet b has 1.0 version;
packet c exists in two versions, 1.0 and 2.1;
there are two versions of packet d, 1.0 and 1.1.
It can be seen that, except for the data packet b, other data packets have version conflict problems.
Then a unified version of the global third party package may be declared by the top level package. For example, the top level package version 1.0 may declare that the global third party package is uniformly deployed in the following versions: data packet a-2.0 version; version b-1.0 of packet; packet c-1.0 version; packet d-1.1 version. It should be noted that the unified version of each third-party data packet can be flexibly set according to the actual situation, which is not limited in the present application; also, there may be multiple different versions of the top level packet to declare different "unified versions".
Based on the declaration of the top-level data package, the third-party data package on which each module depends is described as follows:
a module A: top level packet version-1.0; a data packet a; a data packet b; a data packet c;
and a module B: top level packet version-1.0; a data packet a; a data packet d;
and a module C: top layer packet version-1.0; a data packet a; a data packet b; a data packet c; and (5) a data packet d.
Taking the module A as an example: the module A depends on the 1.0 version of the top-level data packet, the 2.0 version of the data packet, the 1.0 version of the data packet b and the 1.0 version of the data packet c; however, in the description of the third-party data packet on which the module a depends, besides declaring the version of the top-level data packet, the versions of other data packets inherit from the top-level data packet, and the versions used by the data packets do not need to be declared. The version of the data packet depended on by any module can be described by only declaring the version of the top-level data packet without respectively describing the versions of all the data packets, so that the efficiency of declaring the version of the third-party data packet is improved, and the efficiency of subsequent aggregation is favorably accelerated.
According to the technical scheme, the development layer and the delivery layer are separated, the granularity of service splitting is not limited during development, the service can be split to the corresponding module and the implementation packages of the modules can be compiled at the development layer according to predefined business requirements, the implementation packages are independent of one another, and the development difficulty is reduced. During delivery, the implementation packages corresponding to the required modules can be aggregated into the deployment package according to actual service requirements on a delivery layer so as to generate the deployment delivery piece of the service, so that the implementation packages can be freely combined and referenced as required, and the efficiency of generating the deployment delivery piece is improved. Meanwhile, the realization packet of the same module can be multiplexed under different service scenes.
Fig. 4 shows a schematic structural diagram of an electronic device according to an exemplary embodiment of the present application. Referring to fig. 4, at the hardware level, the electronic device includes a processor 402, an internal bus 404, a network interface 406, a memory 408 and a non-volatile memory 410, but may also include hardware required for other services. The processor 402 reads the corresponding computer program from the non-volatile memory 410 into the memory 408 and runs it, forming a means for generating a microservice-based deployment delivery on a logical level. Of course, besides the software implementation, the present application does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Referring to fig. 5, in a software implementation, the apparatus for generating a microservice-based deployment delivery part may include a splitting unit 501, a compiling unit 502, an obtaining unit 503, and an aggregating unit 504. Wherein:
a splitting unit 501, which splits a service according to predefined service requirements to obtain a plurality of modules, wherein each module provides at least one service;
a compiling unit 502 for compiling an independent implementation package for each module and issuing the implementation package to an implementation package set;
an obtaining unit 503, configured to obtain, when there is an actual service requirement, an implementation package corresponding to each module included in the actual service requirement from the implementation package set;
and an aggregating unit 504, configured to aggregate the obtained implementation packages into a deployment package, so as to generate a deployment delivery part corresponding to the actual service requirement.
Optionally, the implementation packages in the implementation package set are issued to a local private warehouse.
Optionally, a corresponding database is configured for each module, the database is used for the corresponding module to read and write related data, and the agent class configures the corresponding relationship between the package name of each module and the database; the method further comprises the following steps:
a first determining unit 505, configured to determine, when any service initiates a database operation, a package name of each module included in the any service;
a second determining unit 506, determining a corresponding database according to the determined package name and the corresponding relationship;
an accessing unit 507 performs data access on the determined database.
Optionally, versions of the same third-party data package depended on by different modules are the same; the unified version of all third party data packages is declared by the top level data package; the version of the third party data package on which any module depends is described by:
declaring the version of the top level packet to be used, and the packets on which any of the modules depends.
Optionally, the method further includes:
a third determining unit 508, which determines that the service corresponding to the actual service requirement calls an internal calling service from an internal module and calls an external calling service from an external module before performing the aggregation operation;
wherein, when the deployment delivery piece is running, the internal calling service is called by a local calling process, and the external calling service is called by a remote calling process.
Optionally, the determining unit 508 is specifically configured to:
combining the providing service sub-lists of the modules to generate an aggregated providing service list, wherein the providing service sub-list is used for recording the services provided by the corresponding modules, and the providing service list is used for recording the services provided by the service to be aggregated;
merging the calling service sub-lists of the modules to generate an aggregated calling service list, wherein the calling service sub-lists are used for recording the services called by the corresponding modules, and the calling service lists are used for recording the services called by the service to be aggregated;
and determining the same repeated service in the providing service list and the calling service list, taking the repeated service as the internal calling service, and taking other services which are different from the repeated service in the calling service list as the external calling service.
The specific details of the implementation process of the functions and actions of each unit in the above device are the implementation processes of the corresponding steps in the above method, and are not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.
In an exemplary embodiment, there is also provided a non-transitory computer readable storage medium, such as a memory, including instructions executable by a processor of a device for generating a microservices-based deployment delivery to perform the above method, which may include:
splitting a service according to predefined service requirements to obtain a plurality of modules, wherein each module provides at least one service;
compiling an independent implementation package for each module and issuing the implementation package to an implementation package set;
when an actual service requirement exists, acquiring an implementation packet corresponding to each module contained in the actual service requirement from the implementation packet set;
and aggregating the obtained implementation packages into a deployment package to generate a deployment delivery piece corresponding to the actual service requirement.
Optionally, the implementation packages in the implementation package set are issued to a local private warehouse.
Optionally, a corresponding database is configured for each module, the database is used for the corresponding module to read and write related data, and the agent configures the corresponding relationship between the package name of each module and the database; the method further comprises the following steps:
when any service initiates database operation, determining the package name of each module contained in the service;
determining a corresponding database according to the determined package name and the corresponding relation;
and performing data access on the determined database.
Optionally, versions of the same third-party data package depended on by different modules are the same; the unified version of all third party data packages is declared by the top level data package; the version of the third party data package on which any module depends is described by:
declaring the version of the top level package to be used, and the package on which any of the modules depends.
Optionally, the method further includes:
determining that a service corresponding to the actual service requirement calls an internal calling service from an internal module and calls an external calling service from an external module before performing an aggregation operation;
wherein, when the deployment delivery piece is running, the internal calling service is called by a local calling process, and the external calling service is called by a remote calling process.
Optionally, the determining that the service corresponding to the actual service requirement calls an internal call service from an internal module, and calls an external call service from an external module includes:
combining the providing service sub-lists of the modules to generate an aggregated providing service list, wherein the providing service sub-list is used for recording the services provided by the corresponding modules, and the providing service list is used for recording the services provided by the service to be aggregated;
merging the calling service sub-lists of the modules to generate an aggregated calling service list, wherein the calling service sub-lists are used for recording the services called by the corresponding modules, and the calling service lists are used for recording the services called by the service to be aggregated;
and determining the same repeated service in the providing service list and the calling service list, taking the repeated service as the internal calling service, and taking other services which are different from the repeated service in the calling service list as the external calling service.
The non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc., which is not limited in this application.
The above description is only a preferred embodiment of the present application and should not be taken as limiting the present application, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present application should be included in the protection scope of the present application.
Claims (12)
1. A method of operating a microservice-based deployment delivery, comprising:
when an actual service requirement exists, acquiring an implementation packet corresponding to each module contained in the actual service requirement from an implementation packet set; the implementation package set issues independent implementation packages compiled by aiming at a plurality of modules, the modules are obtained by splitting services according to predefined service requirements, and each module in the modules provides at least one service;
determining that a service call corresponding to the actual service requirement is from an internal call service of an internal module and from an external call service of an external module;
aggregating the obtained implementation packages into a deployment package to generate a deployment delivery part corresponding to the actual service requirement;
and calling the internal calling service by adopting a local calling process, and calling the external calling service by adopting a remote calling process so as to run the deployment delivery member.
2. The method of claim 1, wherein determining that the service call corresponding to the actual service requirement is an internal call service from an internal module and an external call service from an external module comprises:
combining the providing service sub-lists of the modules to generate an aggregated providing service list, wherein the providing service sub-list is used for recording the services provided by the corresponding modules, the providing service list is used for recording the services provided by the services to be aggregated, and the services to be aggregated are the services corresponding to the actual service requirements;
merging the calling service sub-lists of the modules to generate an aggregated calling service list, wherein the calling service sub-lists are used for recording the services called by the corresponding modules, and the calling service lists are used for recording the services called by the service to be aggregated;
and determining the repeated service in the providing service list and the calling service list, taking the repeated service as the internal calling service, and taking other services which are different from the repeated service in the calling service list as the external calling service.
3. The method according to claim 1, wherein a corresponding database is configured for each module, the database is used for the corresponding module to read and write related data, and the agent class configures the corresponding relationship between the package name of each module and the database; the method further comprises the following steps:
when any service initiates database operation, determining the package name of each module contained in the service;
determining a corresponding database according to the determined package name and the corresponding relation;
and performing data access on the determined database.
4. The method of claim 1, wherein the versions of the same third party data packages that different modules rely on are the same; the unified version of all third party data packages is declared by the top level data package; the version of the third party data package on which any module depends is described by:
declaring the version of the top level package to be used, and the package on which any of the modules depends.
5. The method of claim 1, wherein an implementation package in the set of implementation packages is published into a local private repository.
6. An apparatus for operating a microservice-based deployment delivery component, comprising:
the system comprises an acquisition unit, a service processing unit and a service processing unit, wherein the acquisition unit is used for acquiring an implementation package corresponding to each module contained in an actual service demand from an implementation package set when the actual service demand exists; the implementation package set issues independent implementation packages compiled by aiming at a plurality of modules, the modules are obtained by splitting services according to predefined service requirements, and each module in the modules provides at least one service;
the service determining unit is used for determining that the service corresponding to the actual service requirement calls the internal calling service from the internal module and calls the external calling service from the external module;
the aggregation unit is used for aggregating the acquired implementation packages into a deployment package so as to generate a deployment delivery piece corresponding to the actual service requirement;
and the operation unit is used for calling the internal calling service by adopting a local calling process and calling the external calling service by adopting a remote calling process so as to operate the deployment delivery part.
7. The apparatus according to claim 6, wherein the service determination unit is specifically configured to:
combining the providing service sub-lists of the modules to generate an aggregated providing service list, wherein the providing service sub-list is used for recording the services provided by the corresponding modules, the providing service list is used for recording the services provided by the services to be aggregated, and the services to be aggregated are the services corresponding to the actual service requirements;
merging the calling service sub-lists of the modules to generate an aggregated calling service list, wherein the calling service sub-lists are used for recording the services called by the corresponding modules, and the calling service lists are used for recording the services called by the service to be aggregated;
and determining the same repeated service in the providing service list and the calling service list, taking the repeated service as the internal calling service, and taking other services which are different from the repeated service in the calling service list as the external calling service.
8. The device according to claim 6, wherein a database is configured for each module, the database is used for the corresponding module to read and write related data, and the agent configures the corresponding relationship between the package name of each module and the database; the device further comprises:
the system comprises a packet name determining unit, a database operation unit and a database operation unit, wherein the packet name determining unit is used for determining the packet name of each module contained in any service when the database operation is initiated by the service;
the database determining unit is used for determining a corresponding database according to the determined package name and the corresponding relation;
and the access unit is used for performing data access on the determined database.
9. The apparatus of claim 6, wherein the versions of the same third party data packages that different modules rely on are the same; the unified version of all third party data packages is declared by the top level data package; the version of the third party package on which any module depends is described by:
declaring the version of the top level package to be used, and the package on which any of the modules depends.
10. The apparatus of claim 6, wherein an implementation package in the set of implementation packages is published into a local private repository.
11. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of any one of claims 1-5 by executing the executable instructions.
12. A computer-readable storage medium having stored thereon computer instructions, which when executed by a processor, perform the steps of the method according to any one of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910863539.2A CN110704061B (en) | 2017-12-26 | 2017-12-26 | Running method and device for deploying and delivering payment pieces based on micro-services |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910863539.2A CN110704061B (en) | 2017-12-26 | 2017-12-26 | Running method and device for deploying and delivering payment pieces based on micro-services |
| CN201711429206.6A CN108182068B (en) | 2017-12-26 | 2017-12-26 | The generation method and device, storage medium of part are delivered in deployment based on micro services |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711429206.6A Division CN108182068B (en) | 2017-12-26 | 2017-12-26 | The generation method and device, storage medium of part are delivered in deployment based on micro services |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110704061A CN110704061A (en) | 2020-01-17 |
| CN110704061B true CN110704061B (en) | 2022-11-25 |
Family
ID=62547552
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910863539.2A Active CN110704061B (en) | 2017-12-26 | 2017-12-26 | Running method and device for deploying and delivering payment pieces based on micro-services |
| CN201711429206.6A Active CN108182068B (en) | 2017-12-26 | 2017-12-26 | The generation method and device, storage medium of part are delivered in deployment based on micro services |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711429206.6A Active CN108182068B (en) | 2017-12-26 | 2017-12-26 | The generation method and device, storage medium of part are delivered in deployment based on micro services |
Country Status (1)
| Country | Link |
|---|---|
| CN (2) | CN110704061B (en) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109165021A (en) * | 2018-08-02 | 2019-01-08 | 中国联合网络通信集团有限公司 | Interface Isolation Management method, apparatus, equipment and storage medium |
| CN109120708B (en) * | 2018-08-31 | 2021-08-27 | 鼎富智能科技有限公司 | Business module construction method, calling method and device based on micro-service component |
| CN111225014B (en) * | 2018-11-27 | 2023-04-11 | 中兴通讯股份有限公司 | Method, device and equipment for generating microservice and storage medium |
| CN112241285A (en) * | 2019-07-16 | 2021-01-19 | 腾讯科技（深圳）有限公司 | Configuration method, device and equipment of operation program |
| CN110708201B (en) * | 2019-10-14 | 2021-08-10 | 中国人民解放军32039部队 | Operation and maintenance service management and control method and device |
| CN111193803A (en) * | 2019-12-31 | 2020-05-22 | 四川省公安科研中心 | Spring group-based micro-service construction method and spring group micro-service framework |
| CN111522535A (en) * | 2020-03-26 | 2020-08-11 | 杭州数跑科技有限公司 | Data source aggregation method and device, storage medium and computer equipment |
| CN113472550A (en) * | 2020-03-30 | 2021-10-01 | 阿里巴巴集团控股有限公司 | Distributed management method and system, and management system |
| CN111861445B (en) * | 2020-06-29 | 2024-08-23 | 杭州数梦工场科技有限公司 | Shared delivery method based on micro-service, metering and charging system, medium and equipment |
| CN111796834B (en) * | 2020-06-30 | 2022-10-14 | 福信富通科技股份有限公司 | Method, device and equipment for deploying combinable micro-service development framework |
| CN112068809A (en) * | 2020-08-25 | 2020-12-11 | 筑客网络技术（上海）有限公司 | Module development method for multiple financial institutions |
| CN111966389B (en) * | 2020-08-31 | 2024-08-23 | 北京水滴科技集团有限公司 | Dependency information processing method and device based on software service and electronic equipment |
| CN112506560A (en) * | 2020-12-15 | 2021-03-16 | 上海银基信息安全技术股份有限公司 | Microservice JAR packet management method and device and computer equipment |
| CN116860260A (en) * | 2023-04-26 | 2023-10-10 | 安元科技股份有限公司 | Tailorable operation and maintenance deployment method under micro front end architecture |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106610836A (en) * | 2016-12-23 | 2017-05-03 | 国网信息通信产业集团有限公司 | Micro-service operation management tool |
| CN106845947A (en) * | 2017-02-10 | 2017-06-13 | 中国电建集团成都勘测设计研究院有限公司 | The method and system that a kind of enterprise's micro services based on cloud are persistently paid |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8954952B2 (en) * | 2007-11-30 | 2015-02-10 | Red Hat, Inc. | Portable business process deployment model across different application servers |
| US10069891B2 (en) * | 2015-09-30 | 2018-09-04 | Bank Of America Corporation | Channel accessible single function micro service data collection process for light analytics |
| CN105550130A (en) * | 2015-12-14 | 2016-05-04 | 中电科华云信息技术有限公司 | Container based dynamic arrangement method for application environment and system applying method |
| CN107102847A (en) * | 2016-02-23 | 2017-08-29 | 中国水电工程顾问集团有限公司 | Software development methodology, apparatus and system based on micro services |
| CN106874052B (en) * | 2017-02-24 | 2020-06-26 | 北京中电普华信息技术有限公司 | Deployment method and device of application program |
| CN107391142B (en) * | 2017-07-26 | 2020-11-06 | 北京中电普华信息技术有限公司 | Application splitting method and device |
-
2017
- 2017-12-26 CN CN201910863539.2A patent/CN110704061B/en active Active
- 2017-12-26 CN CN201711429206.6A patent/CN108182068B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106610836A (en) * | 2016-12-23 | 2017-05-03 | 国网信息通信产业集团有限公司 | Micro-service operation management tool |
| CN106845947A (en) * | 2017-02-10 | 2017-06-13 | 中国电建集团成都勘测设计研究院有限公司 | The method and system that a kind of enterprise's micro services based on cloud are persistently paid |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108182068B (en) | 2019-09-17 |
| CN108182068A (en) | 2018-06-19 |
| CN110704061A (en) | 2020-01-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110704061B (en) | Running method and device for deploying and delivering payment pieces based on micro-services | |
| US20210132930A1 (en) | Application blueprints based on service templates to deploy applications in different cloud environments | |
| CN110187914B (en) | Application development method, system and device | |
| US9880837B2 (en) | Artifact manager for release automation | |
| US11182206B2 (en) | Event proxies for functions-as-a-service (FAAS) infrastructures | |
| US11074154B2 (en) | Identifying a source file for use in debugging compiled code | |
| US9411702B2 (en) | Flexible and modular load testing and monitoring of workloads | |
| CN109725911A (en) | A kind of multi-environment project dispositions method, device, storage medium and processor | |
| US20190138276A1 (en) | Distributed component model | |
| WO2015195418A1 (en) | Software package management | |
| US11200048B2 (en) | Modification of codified infrastructure for orchestration in a multi-cloud environment | |
| CN109445937B (en) | Componentized programming and seamless execution method | |
| US11080027B2 (en) | Curated image management in a FaaS infrastructure | |
| JP2022545422A (en) | Method, apparatus, apparatus, and medium for parallel execution of smart contracts | |
| US20150339219A1 (en) | Resilient mock object creation for unit testing | |
| US20220129301A1 (en) | Architectural design for universal software automation pipelines | |
| JP5794513B2 (en) | Computer system, method, and computer program for providing quality of service functions to event processing applications in a multi-processing environment | |
| CN117270864A (en) | Code compiling method, device, equipment and storage medium | |
| EP4025994A1 (en) | Enhanced virtual machine image management system | |
| CN110928941A (en) | Data fragment extraction method and device | |
| CN111367796B (en) | Application program debugging method and device | |
| CN114791884A (en) | Test environment construction method and device, storage medium and electronic equipment | |
| CN113377415A (en) | Application publishing method and device | |
| US10761914B2 (en) | Replacing generated procedure calls with generated inter-process communication | |
| CN113867776A (en) | Method and device for publishing middle station application, electronic equipment and storage medium |
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 |