CN117573111A

CN117573111A - Micro-service deployment method, device, equipment and storage medium

Info

Publication number: CN117573111A
Application number: CN202311520036.8A
Authority: CN
Inventors: 黎志荣; 陈奇毅; 刘弘胤; 郑伟钿
Original assignee: PCI Technology Group Co Ltd
Current assignee: PCI Technology Group Co Ltd
Priority date: 2023-11-14
Filing date: 2023-11-14
Publication date: 2024-02-20

Abstract

The embodiment of the invention provides a micro-service deployment method, a device, equipment and a storage medium. According to the embodiment of the invention, the single application or the deployment of the micro-service mode can be carried out according to the fund or operation and maintenance resource input conditions of different target clients, and development on different frameworks is not needed in the process of developing the service system, so that the development efficiency of the service system is improved, the maintenance workload is reduced, and the technical problems of low development efficiency and large maintenance workload in the service system in the prior art are solved.

Description

Micro-service deployment method, device, equipment and storage medium

Technical Field

The embodiment of the application relates to the field of micro services, in particular to a method, a device, equipment and a storage medium for deploying micro services.

Background

The existing technology development framework is selected, only one of a single application framework or a micro-service framework can be selected in the system design stage, then the corresponding technology development framework is selected for development and deployment, and only one set of system cannot be developed, so that single application deployment or micro-service deployment can be performed according to the conditions of different target clients. Under the condition that the same service system is provided for clients with two different deployment demands, the two different architectures are required to be developed respectively, the systems cannot be reused, and resources are repeatedly wasted while the development efficiency is reduced. In addition, when the product is upgraded, the two architectures are synchronously upgraded, and the maintenance workload is doubled.

In summary, the service system in the prior art has the technical problems of low development efficiency and large maintenance workload.

Disclosure of Invention

The embodiment of the invention provides a micro-service deployment method, a device, equipment and a storage medium, which can realize single application deployment or micro-service deployment in a development framework, improve the development efficiency of a service system, reduce the maintenance workload of the service system and solve the technical problems of low development efficiency and large maintenance workload of the service system in the prior art.

In a first aspect, an embodiment of the present invention provides a micro-service deployment method, including:

determining a main micro-service in all micro-services, determining other micro-services as auxiliary micro-services, and taking the auxiliary micro-services as dependent items of the main micro-service;

determining a deployment mode of the micro service;

when the main micro service is started, scanning codes of the main micro service and configuration files of all the micro services through a Spring module, wherein an automatic configuration class of each micro service is arranged in the configuration files;

when the deployment mode is single application deployment, scanning all codes of paths where the automatic configuration class of each auxiliary micro service is located through a Spring module to obtain codes of each auxiliary micro service, loading a functional component corresponding to each auxiliary micro service by the Spring module according to the codes of each auxiliary micro service, and loading the functional component corresponding to the main micro service by the Spring module according to the codes of the main micro service;

When the deployment mode is micro-service deployment, loading a functional component corresponding to the main micro-service by a Spring module according to the code of the main micro-service;

calling a MyBatis module to acquire a preset calling interface implementation class from the loaded functional component, acquiring an initialization script corresponding to a target micro-service loaded by the functional component by the MyBatis module through the calling interface implementation class and caching the initialization script, executing the corresponding functional component by the Spring module when the target micro-service is externally called, and acquiring or updating service data corresponding to the target micro-service from a database by executing the initialization script by the MyBatis module, wherein the database is used for storing the service data of the micro-service.

In a second aspect, an embodiment of the present invention provides a micro-service deployment apparatus, including:

the main micro-service determining module is used for determining main micro-services in all micro-services, determining other micro-services as auxiliary micro-services, and taking the auxiliary micro-services as dependent items of the main micro-services;

the deployment mode setting module is used for determining the deployment mode of the micro service;

the service scanning module is used for scanning codes of the main micro service and configuration files of all the micro services through the Spring module when the main micro service is started, and the configuration files are provided with automatic configuration classes of each micro service;

The application deployment module is used for scanning all codes of paths where the automatic configuration class of each auxiliary micro-service is located through the Spring module to acquire codes of each auxiliary micro-service when the deployment mode is single application deployment, loading a functional component corresponding to each auxiliary micro-service by the Spring module according to the codes of each auxiliary micro-service, and loading the functional component corresponding to the main micro-service by the Spring module according to the codes of the main micro-service;

the micro-service deployment module is used for loading a functional component corresponding to the main micro-service by the Spring module according to the code of the main micro-service when the deployment mode is micro-service deployment;

the micro-service execution module is used for calling the MyBatis module to acquire a preset calling interface implementation class from the loaded functional components, the MyBatis module acquires an initialization script corresponding to the target micro-service loaded by the functional components through the calling interface implementation class and caches the initialization script, so that when the target micro-service is externally called, the Spring module executes the corresponding functional components, and the MyBatis module acquires or updates service data corresponding to the target micro-service from a database through executing the initialization script, and the database is used for storing the service data of the micro-service.

In a third aspect, an embodiment of the present invention provides a micro-service deployment device, where the micro-service deployment device includes a processor and a memory;

the memory is used for storing a computer program and transmitting the computer program to the processor;

the processor is configured to execute a micro-service deployment method according to the first aspect according to instructions in the computer program.

In a fourth aspect, embodiments of the present invention provide a storage medium storing computer-executable instructions which, when executed by a computer processor, are configured to perform a micro-service deployment method according to the first aspect.

In the foregoing, the embodiment of the present invention provides a method, an apparatus, a device, and a storage medium for deploying micro services, where in the deployment process of micro services, a user may select a deployment mode according to needs in single application deployment or micro service deployment, and then the embodiment of the present invention may deploy a corresponding micro service according to the deployment mode selected by the user. According to the embodiment of the invention, the single application or the deployment of the micro-service mode can be carried out according to the fund or operation and maintenance resource input conditions of different target clients, and development on different frameworks is not needed in the process of developing the service system, so that the development efficiency of the service system is improved, the maintenance workload is reduced, and the technical problems of low development efficiency and large maintenance workload in the service system in the prior art are solved.

Drawings

Fig. 1 is a schematic diagram of a framework of a single application deployment provided in an embodiment of the present invention.

Fig. 2 is a schematic diagram of a framework for micro-service deployment according to an embodiment of the present invention.

Fig. 3 is a flow chart of a micro-service deployment method according to an embodiment of the present invention.

Fig. 4 is a schematic diagram of packet name planning according to an embodiment of the present invention.

Fig. 5 is a schematic diagram of a method for deploying a micro service according to an embodiment of the present invention.

Fig. 6 is a schematic structural diagram of a micro-service deployment device according to an embodiment of the present invention.

Fig. 7 is a schematic structural diagram of a micro-service deployment device according to an embodiment of the present invention.

Detailed Description

The following description and the drawings illustrate specific embodiments of the application sufficiently to enable those skilled in the art to practice them. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the sequence of operations may vary. Portions and features of some embodiments may be included in, or substituted for, those of others. The scope of the embodiments of the present application encompasses the full ambit of the claims, as well as all available equivalents of the claims. Embodiments may be referred to herein, individually or collectively, by the term "invention" merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed. Various embodiments are described herein in a progressive manner, each embodiment focusing on differences from other embodiments, and identical and similar parts between the various embodiments are sufficient to be seen with each other. The structures, products and the like disclosed in the embodiments correspond to the parts disclosed in the embodiments, so that the description is relatively simple, and the relevant parts refer to the description of the method parts.

At present, if a framework for developing micro services on the market is used for developing a plurality of micro services during development, each micro service can only be deployed by adopting the micro service during deployment, namely, each micro service is independently deployed, and all the micro services cannot be packaged into an independent single application for deployment.

The architecture of the single application deployment is shown in fig. 1, and the single application deployment is an architecture mode of coupling all functions and modules in a system into one application, wherein the single application is constructed as an indivisible unit, and the single application is finally packaged into a deployment package. The advantages of the monolithic application architecture are: (1) the device is easy to operate, the learning cost is low, and the technical stack is simple. (2) The deployment of monolithic applications is much less complex than the deployment of micro services, which is easy to deploy. (3) The method is suitable for developing application program architectures with low business complexity and low requirements on application expansion capacity by small teams. The disadvantages of the single application architecture are: (1) With the increase of application requirements and the expansion of scale, the code complexity of a single application program becomes difficult to maintain due to high code coupling degree, and one typical scenario is as follows: modifying code in any detail affects the overall application, so development, testing, deployment must be coordinated comprehensively. However, this development method makes software iteration slow and delivery efficiency low. (2) poor expansibility: it is difficult to expand a module, and only the whole application program can be expanded, for example, when the IO intensive module and the computation intensive module are mixed together, the independent upgrade and capacity expansion cannot be performed. (3) The technology barrier is high and it is extremely difficult to apply new technology in a single application because the entire application must be rewritten.

Micro-service deployment architecture as shown in fig. 2, the micro-service architecture advocates the division of a single application into multiple small services, each of which can be deployed independently, with the services being coordinated and inter-matched with each other, providing the final value to the user. In a micro-service architecture, services are broken down into independently deployable modules that communicate with each other through remote invocation methods (e.g., HTTP), each of which can be updated, deployed, and extended independently. The advantages of the micro-service architecture are: (1) independent components: all services can be deployed and updated independently, providing greater flexibility. Such as: memory is added for IO intensive services, a CPU of a server is added for computation intensive services, and the like, so that reasonable allocation of resources is achieved. (2) traffic concerns are more concentrated: after breaking up the application into smaller and simpler services, business concerns will be easier to understand and manage, just focusing on the specific services associated with the business objectives. (3) Better scalability-micro services have the further advantage that each service can be scaled independently. Specifically, by combining containerized orchestration management (k 8s, docker, etc.), capacity expansion and scaling of services can be rapidly realized. Such as: during the online shopping peak, e-commerce can rapidly increase the number of micro-service deployments to cope with more concurrency demands. After the peak is passed, the micro service container can be released to recycle the resources. (4) flexibility of selection technique: the engineering team is not limited by the technology, and can freely apply various technologies and frameworks for each microservice, so long as the consistency of the interface communication protocol is ensured. The disadvantages of the micro-service architecture are: (1) coding complexity increases: because the micro-service architecture is a distributed system, the encoding requirements with higher complexity such as distributed database operation, distributed transaction and the like can be generated, reasonable micro-service splitting is needed, service boundaries are determined, high cohesion in the service is ensured, and the occurrence probability of the operations such as the distributed transaction and the like is reduced. (2) additional concerns: microservice deployment requires more additional attention due to its multi-host, distributed deployment: such as unified configuration, unified logging, unified index monitoring, unified running condition checking, etc. (3) difficulty in testing: while the testing complexity of a single service is reduced, the multitude of independently deployable services makes integrated testing more difficult.

Because the economy of different enterprises is different, for enterprises with great capital and great thickness, a large number of servers can be provided to support the operation of micro services, and professional operation and maintenance teams are established to ensure the normal operation of the whole set of micro service system, so that the method is more suitable for adopting micro service deployment. For enterprises with intense funds, if only 1,2 servers can be provided to deploy micro services, and few or no operation and maintenance personnel exist, the method is not suitable for adopting micro service deployment.

In summary, in order to solve the technical problems of low development efficiency and large maintenance workload of the service system in the prior art, an embodiment of the present invention provides a micro-service deployment method, as shown in fig. 3, and fig. 3 is a flowchart of the micro-service deployment method provided by the embodiment of the present invention. The micro-service deployment method provided by the embodiment of the invention can be executed by the micro-service deployment equipment, the micro-service deployment equipment can be realized in a software and/or hardware mode, and the micro-service deployment equipment can be formed by two or more physical entities or can be formed by one physical entity. For example, the micro-service deployment device may be a computer, a mainframe, a tablet, or the like. In addition, the embodiment uses the framework as Isass as an example, isass is called Intelligent System Architecture Service Solution, which is called "intelligent system architecture service solution", and is a full life cycle integration solution focusing on technical development team, including basic facilities and middleware, development framework and process, operation and maintenance deployment and implementation, team management and promotion, etc., and specific content can refer to the prior art, and will not be described in detail in the embodiment. The micro-service deployment method provided by the embodiment of the invention comprises the following steps:

And 101, determining a main micro-service in all micro-services, determining other micro-services as auxiliary micro-services, and taking the auxiliary micro-service as a dependent item of the main micro-service.

In the embodiment of the invention, the primary micro-service is determined in all the micro-services, and other micro-services are determined as the secondary micro-service. For example, an order micro-service order may be determined as a primary micro-service, and other micro-services, such as a user micro-service user and a device micro-service device, may be determined as secondary micro-services. After the primary micro-service is determined, the secondary micro-service needs to be further used as a dependent item of the primary micro-service, namely, the primary micro-service has all codes of all secondary micro-services. Illustratively, the dependent process of adding the user micro-service in the order micro-service is: (1) Maven coordinates of the user microservices are determined, wherein Maven is a Java platform-based project management and integration tool that abstracts the development and management process of a project into a Project Object Model (POM). The developer can automatically complete the tasks of compiling, testing, packaging, publishing, deploying and the like of the project by only carrying out some simple configuration. The specific codes of the Maven coordinates of the user micro-services are determined as follows:

<groupId>vip.isass</groupId>

<artifactId>user-service</artifactId>

(2) Adding the dependence of the user micro-service in the order micro-service, specifically adding in the order micro-service pom file:

the principle of adding the dependence of other auxiliary micro-services to the order micro-services is similar to that described above, and the description thereof is omitted in this embodiment.

Step 102, determining a deployment mode of the micro-service.

After the primary micro service and the secondary micro service are determined, the deployment mode of the micro service needs to be further determined, and in this embodiment, the deployment mode of the micro service is single application deployment or micro service deployment.

Step 103, when the main micro service is started, scanning codes of the main micro service and configuration files of all the micro services through a Spring module, wherein an automatic configuration class of each micro service is arranged in the configuration files.

After the main micro service is started, the code of the main micro service and the configuration files of all the micro services can be scanned through the Spring module, and the configuration files are provided with automatic configuration classes of each micro service, wherein the automatic configuration classes are AutoConfiguration classes, and the automatic configuration classes can be written in the configuration files of each micro service in advance. The Spring module is a Java lightweight container framework, the framework is originally used for solving the problem that EJB (sun's Java EE server side component model is a specification, design targets and core applications are deployment distributed application programs) develop heavy and bulky, the Spring module uses basic Java beans to complete matters completed by EJB, another simple and practical solution is provided for J2EE (Java 2Platform Enterprise Edition), and the Spring module is considered as a low-cost, safe and flexible framework.

In one embodiment, each micro-service includes a deployment package, the deployment package including a scan package and a traffic package, the method further comprising:

pre-writing a micro-service, marking an automatic configuration class in a scanning package of the micro-service, and adding a scanning annotation; marking a servicechannel class in a scanning packet of the micro service, and adding a condition annotation; the scanning annotation is used for configuring the Spring module to scan the automatic configuration class of the non-main micro-service, and the condition annotation is used for configuring the Spring module to execute the creation and loading of the functional components corresponding to the micro-service under the specified condition.

In one embodiment, each micro-service includes a deployment package including a scan package (scanner package) and a business package, and an exemplary package name plan for the micro-service is shown in fig. 4, where vip.isass.auth is the package name prefix of the user micro-service and vip.isass.order is the package name prefix of the order micro-service in fig. 4. Wherein only AutoConfiguration class and Scanner class are stored under the scanning package. When the code of the micro service is written in advance, the embodiment needs to mark the automatic configuration class in the scanning package of the micro service and add the scanning annotation, wherein the scanning annotation is used for configuring the automatic configuration class of the non-main micro service scanned by the Spring module. For example, when the code of the micro service is written, an AuthAutoconfiguration class may be added in a scanner package of the micro service of the user, and an @ componentScan annotation is added, where the @ componentScan annotation is a scanning annotation, and if the class of the annotation is scanned by the Spring module, a path configured by the annotation is also scanned by the Spring module, and the method is used for configuring the Spring module to additionally scan the class of the non-main program catalog, and the specific code is as follows:

In addition, the user also needs to mark the AuthServiceScanner class in the scanner package of the micro-service, and add condition notes, wherein the condition notes are used for configuring the Spring module to execute the creation and loading of the functional components corresponding to the micro-service under the specified conditions, for example, the condition notes can be @ Configuration notes and @ conditional on property notes, and the condition notes are used for loading and creating the functional components (i.e. beans) under the specific conditions, and the function of the condition notes is to judge whether the conditions are met according to the specified attribute values, and if the conditions are met, create the beans corresponding to the conditions. The specific codes are as follows:

the 9 th code uses the conditional on property annotation function of the Spring boot to enable the Spring module to load the configuration item if the configuration item is start. If such is loaded, and thus the class has line 10 @ ComponentScan (value= { "vip. Isass. Auth" }), then the Spring module will scan the deployment package of vip. Isass. Auth.

On the basis of the above embodiment, when the micro service is pre-encoded, the method further includes:

and adding a configuration file in the deployment package of the micro service, and labeling the automatic configuration class in the configuration file.

In one embodiment, when the code of the micro service is pre-written, a configuration file is further added in the deployment package of the micro service, and an automatic configuration class is marked in the configuration file. For example, in this embodiment, the configuration file is a META-INF/spring. Factors file, and the user may add the META-INF/spring. Factors file to the user micro-service in advance and write the authAutoconfiguration class, with specific codes as follows:

#Auto Configure

org.Springframework.boot.autoconfigure.EnableAutoConfiguration＝\

vip.isass.auth.scanner.AuthAutoConfiguration。

thereafter, the user may normally write main entry classes and business codes for the user's micro-services, with exemplary specific codes as follows:

based on the above embodiment, the scanning, in step 103, the code of the primary micro service and the configuration file of the primary micro service by the Spring module includes:

step 1031, scanning a packet path and a sub path of a main micro service entry class through a Spring module to obtain a deployment packet of the main micro service;

step 1032, reading all configuration files in the deployment package.

In this embodiment, after the main micro service is started, the Spring module scans the packet path and the sub path where the main micro service entry class is located, so as to obtain a deployment packet of the main micro service, and reads all configuration files in the deployment packet. It should be further described that, in this embodiment, the Spring module needs to be configured in advance, and a specific configuration process is as follows:

(1) When the primary micro-service is started, all classes of the deployment package under the current primary micro-service directory are scanned by default, and the scanned classes meeting the regulations are instantiated into bean objects and managed by the Spring module. It can be appreciated that the naming of the package name prefix of the deployment package is definitely different for different microservices, for example, the package name prefix of the user microservices is vip.isass.user, and the package name prefix of the order service is vip.isass.order. The main method of the user micro service is generally placed in a primary directory under the user micro service package, for example, the class name is vip.isass.user.userpp, while the main program of the order micro service is generally placed in a primary directory under the order micro service package, for example, the class name is vip.isass.user.ordera pp. If the user micro-service is used as a dependent package and is dependent by the order micro-service only according to the setting of the link, when the order micro-service is started as a single application, the Springboot only scans all the classes under the vip.isass.user, and the order service single application has no function of the user micro-service because the vip.isass.user is not in the scanning range of the Springboot, so that the subsequent setting of the links (2), (3) and (4) is also needed for the Spring module in the embodiment.

(2) The Spring module provides @ ComponentScan annotation, and if the annotated class is scanned, the path configured for the annotation is also scanned by the Spring module.

(3) The Spring module provides @ Configuration and @ Configuration on property notes for Bean loading and creation under specific conditions.

(4) The Spring module provides Spring factors, which is a mechanism similar to Java SPI for configuring the implementation class name of the interface in the META-INF/spring.factors file, and then reads the corresponding configuration file and instantiates in the program. The Spring factors mechanism provides a way to decouple container injection, helping external packages (packages not under the catalog and all sub-catalogs of the main microservice class) register beans into the Spring boot project container.

After the Spring module is configured in advance, after a subsequent main micro service is started, the Spring module can automatically scan a packet path and a sub path where an inlet class of the main micro service is located after the main micro service is started, then read all META-INF/spring.factors files (including the main micro service and the auxiliary micro service) in a deployment packet, then read all configured AutoConfiguration classes in the META-INF/spring.factors files, and scan a packet path and a sub path (xxx.scanner) where the AutoConfiguration class is located to obtain a xxxServicescanner class under the path.

Step 104, when the deployment mode is single application deployment, scanning all codes of paths where the automatic configuration class of each secondary micro-service is located through the Spring module to obtain codes of each secondary micro-service, loading a functional component corresponding to each secondary micro-service by the Spring module according to the codes of each secondary micro-service, and loading a functional component corresponding to the main micro-service by the Spring module according to the codes of the main micro-service.

After the automatic configuration class is acquired, the deployment mode of the main micro service needs to be further judged. If the deployment mode of the main micro-service is single application deployment, the Spring module scans the path of the automatic configuration class of each auxiliary micro-service to acquire the code of each auxiliary micro-service. And then, loading the functional components corresponding to each secondary micro-service by the Spring module according to the codes of each secondary micro-service. For example, the Spring module may load all AutoConfiguration classes in the code as beans. Similarly, the Spring module also needs to load beans corresponding to the primary microservices according to the codes of the primary microservices.

In addition, it should be further noted that spring. Manufacturers record an AutoConfiguration class, and since there is an @ ComponentScan annotation in the AutoConfiguration class, a catalog of AutoConfiguration class is scanned during the scanning process. The catalog also has a Scanner class, and the Scanner class has the function of judging the deployment mode of the micro service, for example, whether the start.micro service.enabled=false is established in the condition annotation can be judged to determine the deployment mode. The business function code of the secondary micro-service is stored in the flat directory of the AutoConfiguration class directory, so that @ ComponentScan annotation is arranged in the AutoConfiguration class, the Spring can only scan the code under the AutoConfiguration directory, and the code of the secondary micro-service cannot be directly scanned by the Spring. The Scanner class also has @ ComponentScan annotation, but this annotation specifies that the scanning range of Spring is extended to the upper level directory, so when the Scanner class determines that the primary micro service is a single deployment, the upper level directory can be scanned through the @ ComponentScan annotation, i.e., the code of the entire secondary micro service can be scanned. The ComponentScan notes in the AutoConfiguration class do not specify the scan range, so the peer and lower directories are scanned by default.

And 105, loading the functional component corresponding to the main micro service by the Spring module according to the code of the main micro service when the deployment mode is micro service deployment.

When the deployment mode is micro-service deployment, the code of the auxiliary micro-service is not required to be acquired, and the Spring module loads the functional component corresponding to the main micro-service according to the code of the main micro-service, namely loads the bean corresponding to the automatic configuration class according to the scanning package of the main micro-service.

And 106, calling the MyBatis module to acquire a preset calling interface implementation class from the loaded functional component, acquiring an initialization script corresponding to the target micro-service loaded by the functional component by the MyBatis module through the calling interface implementation class, caching the initialization script, executing the corresponding functional component by the Spring module when the target micro-service is externally called, and acquiring or updating service data corresponding to the target micro-service from a database by executing the initialization script by the MyBatis module, wherein the database is used for storing the service data of the micro-service.

After loading the bean corresponding to the micro-service, the MyBatis module needs to be further called, wherein the MyBatis module is a persistent layer framework, supports customization of Sql, storage process and advanced mapping, and avoids almost all JDBC (Java DataBase Connectivity, java language connection database) codes and manual setting parameters and obtaining result sets. In the embodiment, when the code of the micro service is compiled, the suitability of the MyBatis module is required to be set, when the MyBatis module is used, a Mapper interface and a series of methods for executing the Sql statement are required to be defined in the java class, the Mapper interface can bind an xml file, the xml file is used for compiling a specific Sql statement, the separation of the java code and the Sql statement is achieved, and the maintainability and the readability of the system are improved. MapperLocation is a configuration of MyBatis module that tells MyBatis module which path to read xml file from, path configuration supports wildcards, e.g. "MyBatis. Map-locations=classpath: map/. Xml", code map directory all files ending in xml. The configuration item is generally written in a configuration file of the Springboot, and when a plurality of micro services are packaged into a single program for deployment, the configuration item can be covered, so that the MyBatis module cannot load xml files of all the micro services correctly. Therefore, in this embodiment, a call interface needs to be newly added to the MyBatis module to obtain xml files corresponding to each micro-service. Specifically, in this embodiment, an imapperlocalprovider interface may be newly added to the MyBatis module to obtain xml files of each microservice. Exemplary, specific codes are as follows:

public interface IMapperLocationProvider{

List<String>getMapperLocations()；

}

Wherein the getMapperLocation () method is a path of returning an xml file of a micro service.

Correspondingly, in the process of programming the micro-services, all the micro-services can respectively realize IMapperLocationProvider. For example, for a user micro-service, the code that needs to be added is:

the code specifies that the xml file of the MyBatis module of the user micro-service is located under the java class path/vip/isass/auth/db, and the file ending with the Mapper. And Classpath represents a directory of the current java executives.

In addition, in this embodiment, an sql session config class needs to be created in the MyBatis module, where sql session factor is a very important object in the MyBatis framework, and its main function is to create sql session. And SqlSession is a key object in MyBatis module for performing persistence operations. The SqlSession bottom layer encapsulates the JDBC connection, and the SqlSession instance can be used for directly executing the mapped Sql statement, and the specific codes are as follows:

line 6 of the code defines a member variable of the IMAppleLocationProvider interface, and the object is automatically assigned by the Spring module, and the value is all the objects which realize the IMAppleLocationProvider interface.

The method defined in line 9 is used to set the xml path to the sqlsessionfactor object.

The method defined in line 16 is used for converting an xml path provided by an object of the IMapperLocationProvider into a Resource object required by the SqlSessionFactoy, so that the MyBatis module obtains an Sql statement in a corresponding xml file. The MyBatis module then caches the Sql statement so that when the business logic of the micro service needs to query the database when the subsequent micro service is invoked, the MyBatis module can query the database using the cached Sql statement.

On the basis of the above embodiment, the method further comprises:

the method comprises the steps of configuring a database in advance, adding the name of the corresponding micro service in a storage path of an initialization script for storing each micro service in the database, and adding the name of the corresponding micro service in data recorded in a history table of the database, wherein the history table is used for recording an execution record of the initialization script corresponding to the micro service.

The database in this embodiment is used to store business data for each micro-service. In this embodiment, since different micro services have different data tables, after all the micro services are packaged into one single application, all the initialization scripts of the micro services are stored together. It should be noted that, the initialization script is an initialization Sql script, which is an initialization script of a database, and is used for executing operations such as table building, adding and deleting and modifying fields in the database, unlike the Sql statement of the MyBatis module (the Sql statement used by service logic, the Sql statement executed when someone calls a service interface), the micro service can update and modify the service data stored in the database by executing the initialization script. Therefore, in this embodiment, the names of the corresponding micro services need to be added in the storage path of the database for storing the initialization script of each micro service, and the names of the corresponding micro services need to be added in the data recorded in the history table of the database, where the history table is used to record the execution record of the initialization script corresponding to the micro service, so as to achieve the purpose that each micro service can independently configure the initialization Sql script, and avoid overlapping each other.

In addition, in this embodiment, the database may be managed by using a Flyway, where Flyway is a database version management tool that is open to source, and it is more prone to a way in which the protocol is better than the configuration. The Flyway can manage and track database changes independent of the application, support automatic upgrading of database versions, and has a default set of specifications without complex configuration. In this embodiment, the workflow of the fly is:

(1) When the method is used for the first time, the bypass creates a bypass_schema_history table for recording the execution record of the initialization Sql script.

(2) After the bypass is started, the bypass automatically scans all the initialized Sql scripts under the project specified path and compares the initialized Sql scripts with the bypass_schema_history table. If the database records the executed initialization Sql script, which is inconsistent with the executed initialization Sql script in the project, the tilting will report the error and stop the project execution.

(3) And if the verification is passed, recording the maximum version number according to the initialized Sql scripts in the table, and ignoring all initialized Sql scripts with the version numbers smaller than the version number. And then executing the rest of the initialized Sql scripts one by one according to the version number from small to large.

In this embodiment, the flyway configuration class needs to be rewritten in the flyway, where the flyway configuration class is a flyway official configuration class, and includes "initialize Sql script code", "initialize Sql script path", "flyway history table name", and the like, and the rewriting code is as follows:

and adding a line 3 code, and adding a getServiceName () to obtain the name of the current micro service.

And newly adding 7 th to 12 th row codes for modifying the path of the initialized Sql script, and splicing micro service names on the path of the initialized Sql script by calling the getServiceName () method newly added by the 3 rd row codes so as to achieve the aim that each micro service can independently configure the initialized Sql script directory and avoid mutual coverage.

And the 14 th line code is added for modifying the name of the default bypass history list so as to splice the micro service names, thereby achieving the purpose that each micro service can independently configure the history list.

In addition, since the code for rewriting the flyway is the getServiceName () newly added, it is also necessary to make all the micro services implement the flyway configuration class individually in this embodiment. For example, in the process of programming a user microservice, the newly added code is as follows:

Wherein, starting from the 4 th line code, the getServiceName () method is rewritten, and the name of the user micro service is returned as a user.

Starting from line 9 code, a method named userfryway is provided, which uses @ Bean annotation tags, i.e., the method is called by Spring management, generates a Bean, which is finally obtained from the startup flow function of the bypass itself, and initializes the user micro-service initialization Sql script.

In addition, an initialization Sql script of the user micro-service needs to be added under the resource directory db/migration/user, and the initialization Sql script is automatically executed by the bypass.

Specifically, in this embodiment, for a target micro-service loaded with a bean, the MyBatis module needs to be further called to obtain a preset call interface implementation class from the loaded bean, that is, obtain an imapplication location provider implementation class, and then call a method for obtaining a Mapper path by using the imapplication location provider implementation class to obtain an initialization script corresponding to the target micro-service loaded with the bean and cache the initialization script. When the target micro-service is called externally, the Spring module executes the corresponding bean, and the MyBatis module acquires or updates the business data corresponding to the target micro-service from the database by executing the initialization script.

On the basis of the above embodiment, the step 106 of calling the MyBatis module to obtain a preset calling interface implementation class from the loaded functional component, and the MyBatis module to obtain and cache an initialization script corresponding to the target micro-service loaded by the functional component through the calling interface implementation class includes:

step 1061, initializing the sqlsessionfactor in the MyBatis module.

In this embodiment, the sqlssessionfactor in the MyBatis module needs to be initialized first.

Step 1062, calling a MyBatis module to obtain a preset calling interface implementation class from the loaded functional component, obtaining an xml file path corresponding to the target micro-service loaded by the functional component by the MyBatis module through the calling interface implementation class, and converting the xml file path into a target object required by the sql session factor, so that the sql session factor obtains and caches an initialization script corresponding to the target micro-service according to the target object.

After the SqlSessionFactoy is initialized, the MyBatis module is further called to acquire IMappLocationProvider realization class from the loaded beans, then the IMappLocationProvider realization class is called to acquire the map path method, the xml file path corresponding to the target micro-service is acquired, and the xml file path is converted into a Resource object required by the SqlSessionFactoy, so that the SqlSessionFactoy acquires and caches the initialization script corresponding to the target micro-service according to the Resource object. In one embodiment, the specific process of the embodiment of the present invention is shown in fig. 5.

In the foregoing, the embodiment of the present invention provides a micro-service deployment method, and in the deployment process of the micro-service, a user may select a deployment mode according to needs in single application deployment or micro-service deployment, and then the embodiment of the present invention may deploy a corresponding micro-service according to the deployment mode selected by the user. According to the embodiment of the invention, the single application or the deployment of the micro-service mode can be carried out according to the fund or operation and maintenance resource input conditions of different target clients, and development on different frameworks is not needed in the process of developing the service system, so that the development efficiency of the service system is improved, the maintenance workload is reduced, and the technical problems of low development efficiency and large maintenance workload in the service system in the prior art are solved.

As shown in fig. 6, fig. 6 is a schematic structural diagram of a micro service deployment device according to an embodiment of the present invention, where the micro service deployment device according to the embodiment of the present invention includes:

a primary micro-service determining module 201, configured to determine a primary micro-service from all micro-services, determine other micro-services as secondary micro-services, and use the secondary micro-services as dependent items of the primary micro-service;

A deployment mode setting module 202, configured to determine a deployment mode of the micro service;

the service scanning module 203 is configured to scan, when the main micro service is started, a code of the main micro service and configuration files of all the micro services through the Spring module, where an automatic configuration class of each micro service is set in the configuration files;

the application deployment module 204 is configured to scan all codes of a path where an automatic configuration class of each secondary micro service is located through the Spring module to obtain a code of each secondary micro service when the deployment mode is single application deployment, load a functional component corresponding to each secondary micro service by the Spring module according to the code of each secondary micro service, and load a functional component corresponding to the main micro service by the Spring module according to the code of the main micro service;

the micro-service deployment module 205 is configured to load, when the deployment mode is micro-service deployment, a functional component corresponding to the main micro-service by the Spring module according to the code of the main micro-service;

the micro-service execution module 206 is configured to invoke the MyBatis module to obtain a preset call interface implementation class from the loaded functional components, the MyBatis module obtains an initialization script corresponding to a target micro-service loaded by the functional components through the call interface implementation class, and caches the initialization script, so that when the target micro-service is externally invoked, the corresponding functional components are executed by the Spring module, and the MyBatis module obtains or updates service data corresponding to the target micro-service from a database by executing the initialization script, where the database is used for storing the service data of the micro-service.

On the basis of the above embodiment, the method further includes a database configuration module, configured to configure a database in advance, add a name of a corresponding micro service in a storage path of an initialization script for storing each micro service in the database, and add a name of a corresponding micro service in data recorded in a history table of the database, where the history table is used to record an execution record of the initialization script corresponding to the micro service.

Based on the above embodiment, the micro service execution module 206 is specifically configured to initialize the sqlsassionfactor in the MyBatis module; calling a MyBatis module to acquire a preset calling interface implementation class from the loaded functional component, acquiring an xml file path corresponding to a target micro-service loaded by the functional component by the MyBatis module through the calling interface implementation class, converting the xml file path into a target object required by the SqlSessionFactory, and acquiring and caching an initialization script corresponding to the target micro-service according to the target object by the SqlSessionFactory.

On the basis of the above embodiment, each micro service includes a deployment package, where the deployment package includes a scan package and a service package, and the micro service deployment device further includes:

The micro-service writing module is used for writing micro-services in advance, marking automatic configuration classes in a scanning package of the micro-services, and adding scanning notes; marking a servicechannel class in a scanning packet of the micro service, and adding a condition annotation; the scanning annotation is used for configuring the Spring module to scan the automatic configuration class of the non-main micro-service, and the condition annotation is used for configuring the Spring module to execute the creation and loading of the functional components corresponding to the micro-service under the specified condition.

On the basis of the embodiment, when the micro service is pre-coded, the micro service writing module is further used for adding a configuration file in a deployment package of the micro service, and labeling an automatic configuration class in the configuration file.

On the basis of the above embodiment, the service scanning module 203 is specifically configured to scan, by using the Spring module, a packet path and a sub path where the main micro service portal class is located, to obtain a deployment packet of the main micro service; and reading all configuration files in the deployment package.

Based on the above embodiment, the micro service deployment module 205 is specifically configured to load, by the Spring module, a bean corresponding to the auto-configuration class according to a scan package of the main micro service.

The micro-service deployment device provided by the embodiment of the invention is contained in the micro-service deployment equipment, can be used for executing the micro-service deployment method provided by the embodiment, and has corresponding functions and beneficial effects.

It should be noted that, in the embodiment of the micro-service deployment device, each unit and module included are only divided according to the functional logic, but not limited to the above-mentioned division, so long as the corresponding functions can be implemented; in addition, the specific names of the functional units are also only for distinguishing from each other, and are not used to limit the protection scope of the present invention.

The embodiment also provides a micro-service deployment device, as shown in fig. 7, fig. 7 is a schematic structural diagram of the micro-service deployment device provided by the embodiment of the present invention, where the micro-service deployment device 30 includes a processor 300 and a memory 301;

the memory 301 is used for storing the computer program 302 and transmitting the computer program 302 to the processor 300;

the processor 300 is configured to perform the steps of one of the micro service deployment method embodiments described above in accordance with instructions in the computer program 302.

By way of example, the computer program 302 may be partitioned into one or more modules/units, which are stored in the memory 301 and executed by the processor 300 to complete the present application. One or more of the modules/units may be a series of computer program instruction segments capable of performing particular functions for describing the execution of the computer program 302 in the micro-service deployment device 30.

The micro-service deployment device 30 may be a computing device such as a desktop computer, a notebook computer, a palm computer, and a cloud server. Micro-service deployment device 30 may include, but is not limited to, a processor 300, a memory 301. Those skilled in the art will appreciate that fig. 7 is merely an example of a micro service deployment device 30 and is not meant to be limiting of the micro service deployment device 30, and may include more or fewer components than shown, or may combine certain components, or different components, e.g., the micro service deployment device 30 may also include input and output devices, network access devices, buses, etc.

The processor 300 may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 301 may be an internal storage unit of the micro-service deployment device 30, such as a hard disk or memory of the micro-service deployment device 30. The memory 301 may also be an external storage device of the micro service deployment device 30, such as a plug-in hard disk, smart Media Card (SMC), secure Digital (SD) Card, flash memory Card (Flash Card) or the like, which are provided on the micro service deployment device 30. Further, the memory 301 may also include both internal storage units and external storage devices of the micro-service deployment device 30. The memory 301 is used to store computer programs and other programs and data required by the micro-service deployment device 30. The memory 301 may also be used to temporarily store data that has been output or is to be output.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of elements is merely a logical functional division, and there may be additional divisions of actual implementation, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present invention may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of the embodiments of the present invention. And the aforementioned storage medium includes: a usb disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media in which computer programs can be stored.

The embodiments of the present invention also provide a storage medium containing computer-executable instructions, which when executed by a computer processor, are for performing a micro-service deployment method comprising the steps of:

determining a deployment mode of the micro-service;

when the main micro service is started, scanning codes of the main micro service and configuration files of all the micro services through a Spring module, wherein the configuration files are provided with automatic configuration classes of each micro service;

when the deployment mode is single application deployment, scanning all codes of paths where the automatic configuration class of each auxiliary micro service is located through a Spring module to acquire codes of each auxiliary micro service, loading a functional component corresponding to each auxiliary micro service by the Spring module according to the codes of each auxiliary micro service, and loading the functional component corresponding to the main micro service by the Spring module according to the codes of the main micro service;

Calling the MyBatis module to acquire a preset calling interface implementation class from the loaded functional components, acquiring an initialization script corresponding to the target micro-service by the MyBatis module through the calling interface implementation class and caching the initialization script, executing the corresponding functional components by the Spring module when the loaded target micro-service of the functional components is externally called, and acquiring or updating service data corresponding to the target micro-service from a database by the MyBatis module through executing the initialization script, wherein the database is used for storing the service data of the micro-service.

Note that the above is only a preferred embodiment of the present invention and the technical principle applied. It will be understood by those skilled in the art that the embodiments of the present invention are not limited to the particular embodiments described herein, but are capable of numerous obvious changes, rearrangements and substitutions without departing from the scope of the embodiments of the present invention. Therefore, while the embodiments of the present invention have been described in connection with the above embodiments, the embodiments of the present invention are not limited to the above embodiments, but may include many other equivalent embodiments without departing from the spirit of the embodiments of the present invention, and the scope of the embodiments of the present invention is determined by the scope of the appended claims.

Claims

1. A method of micro-service deployment, comprising:

determining a deployment mode of the micro service;

2. The method for deploying micro-services according to claim 1, further comprising:

the database is configured in advance, the names of the corresponding micro services are added in a storage path of the initialization script of each micro service, which is used for storing the micro services, and the names of the corresponding micro services are added in the data recorded in the history record table of the database, which is used for recording the execution record of the initialization script corresponding to the micro services.

3. The method for deploying micro-services according to claim 1, wherein the calling MyBatis module obtains a preset calling interface implementation class from the loaded functional component, and the MyBatis module obtains and caches an initialization script corresponding to a target micro-service loaded by the functional component through the calling interface implementation class, including:

initializing an SqlSessionFactory in the MyBatis module;

calling a MyBatis module to acquire a preset calling interface implementation class from the loaded functional component, acquiring an xml file path corresponding to a target micro-service loaded by the functional component by the MyBatis module through the calling interface implementation class, converting the xml file path into a target object required by the SqlSessionFactory, and acquiring and caching an initialization script corresponding to the target micro-service according to the target object by the SqlSessionFactory.

4. The method of claim 1, wherein each of the micro services comprises a deployment package, the deployment package comprising a scan package and a traffic package, the method further comprising:

the micro-service is compiled in advance, the automatic configuration class is marked in a scanning package of the micro-service, and scanning notes are added; marking a ServiceServer class in a scanning packet of the micro service, and adding a condition annotation; the scanning annotation is used for configuring the Spring module to scan the automatic configuration class of the non-main micro-service, and the condition annotation is used for configuring the Spring module to execute the creation and loading of the functional components corresponding to the micro-service under the specified condition.

5. The method for deploying micro-services according to claim 4, wherein when the micro-services are pre-encoded, further comprising:

and adding the configuration file in the deployment package of the micro service, and labeling an automatic configuration class in the configuration file.

6. The method for deploying micro-services according to claim 4, wherein the scanning the code of the main micro-service and the configuration file of the main micro-service by the Spring module comprises:

Scanning a packet path and a sub path of the main micro service entry class through a Spring module to obtain a deployment packet of the main micro service;

and reading all configuration files in the deployment package.

7. The micro service deployment method according to claim 4, wherein the loading of the functional component corresponding to the main micro service by the Spring module according to the code of the main micro service comprises:

and loading beans corresponding to the automatic configuration class by the Spring module according to the scanning package of the main micro service.

8. A micro-service deployment apparatus, comprising:

9. A micro service deployment device, wherein the micro service deployment device comprises a processor and a memory;

the processor is configured to execute a micro service deployment method according to any of claims 1-7 according to instructions in the computer program.

10. A storage medium storing computer executable instructions which, when executed by a computer processor, are adapted to perform a micro service deployment method according to any of claims 1-7.