Method, system, equipment and medium for splitting and deploying micro-service

Abstract

The invention relates to the field of micro-service deployment, and provides a method, a system, equipment and a medium for splitting and deploying micro-services, and the method comprises the following steps: deploying a micro-service file deployment environment in a product; the method comprises the following steps: splitting a product into a plurality of micro-service applications according to business requirements, and configuring starting scripts and exposure settings in subdirectories of the micro-service applications; in response to the received input parameter, scanning a subdirectory of the micro-service application based on the input parameter, and loading a starting script to start the micro-service; in response to performing the micro-service registration discovery, other micro-service applications are notified that call is allowed by exposure settings. According to the method, the original program file is split into a plurality of independent micro-services, and each micro-service is independently deployed and managed. The flexibility and maintainability of the application program are improved, and the development efficiency and the stability of the system are improved. Meanwhile, by implementing mechanisms such as service registration and discovery and log management, the availability and reliability of the system are further enhanced.

Description

Technical Field

[0001] The present invention relates to the field of microservice deployment, and particularly to a method, system, device and medium for microservice splitting and deployment. Background Art

[0002] With the development of information technology, large software applications such as enterprise resource planning (ERP) have become increasingly complex and huge. These systems usually integrate multiple functional modules, such as finance, supply chain management, tax processing, etc., resulting in slower startup speed and decreased stability. Often, a problem in a small module causes the entire application to be unavailable.

[0003] In some special scenarios at the present stage, such as irreplaceable classified scenarios and some non-virtualized scenarios, an application server is often relatively large, and the memory can reach 256G or even higher. In this case, deploying a set of applications is a waste, and if a set of applications has problems, it will cause relatively significant impacts.

[0004] If multiple sets of applications are deployed, then the workload of application update and synchronization, as well as debugging when problems occur, is relatively large. Deploying multiple sets and isolating them from each other makes the update more complex on the one hand, and on the other hand, more components need to be replaced when problems occur. Summary of the Invention

[0005] In view of this, the present invention provides a method, system, device and medium for microservice splitting and deployment, which uses scripts to dynamically insert loadable information, configures a custom class loader, only loads part of the application, and realizes a set of deployment files to achieve multiple service deployment scenarios.

[0006] Based on the above purpose, the present invention provides a method for microservice splitting and deployment, including:

[0007] Deploy a microservice file deployment environment in the product;

[0008] According to business requirements, split the product into multiple microservice applications, and configure startup scripts and exposure settings in the subdirectories of the microservice applications;

[0009] In response to receiving input parameters, scan the subdirectories of the microservice applications based on the input parameters, and load the startup scripts to start the microservices;

[0010] In response to microservice registration discovery, notify other microservice applications through the exposure settings to allow calls.

[0011] In some embodiments, the method further includes:

[0012] When deploying multiple microservice applications, set multiple sets of corresponding logging for different microservice applications.

[0013] In some embodiments, the startup script includes a service name, a port, logs, memory configuration, and a loading path.

[0014] In some embodiments, the step of configuring the startup script in the sub-directory of the microservice application includes:

[0015] Design a corresponding deployment strategy for the microservice application;

[0016] Define the microservice application interfaces and protocols;

[0017] Set the folders of the microservices to be loaded in this process and the dependent folders.

[0018] In some embodiments, the step of deploying the microservice file deployment environment in the product includes:

[0019] Deploy the registration and discovery software for multiple microservice applications;

[0020] Modify the default configuration of the product.

[0021] In some embodiments, the step of, in response to microservice application registration and discovery, notifying other microservice applications of the allowable calls through exposure settings includes:

[0022] Set the sub-directory of the microservice application as the smallest loading unit;

[0023] In response to microservice application registration and discovery, perform the exposure settings of the microservice according to the sub-directory of the microservice application, and inform other microservice applications that this microservice application can be called.

[0024] In some embodiments, the method further includes:

[0025] Execute different startup scripts on the same machine or different machines to start multiple corresponding microservices.

[0026] The present invention provides a system for microservice splitting and deployment, including:

[0027] A deployment unit configured to deploy a microservice file deployment environment in a product;

[0028] A splitting unit configured to split a product into multiple microservice applications according to business requirements, and configure startup scripts and exposure settings in the sub-directories of the microservice applications;

[0029] A startup unit configured to, in response to receiving input parameters, scan the sub-directories of microservice applications based on the input parameters, and load the startup scripts to start the microservices;

[0030] A discovery unit, configured to, in response to microservice registration discovery, notify other microservice applications that they are allowed to call by exposing settings.

[0031] The present invention provides a computer device, including:

[0032] At least one processor; and a memory storing a computer program that can run on the processor, and when the processor executes the program, it executes the steps of the method for microservice splitting and deployment.

[0033] The present invention provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, it executes the steps of the method for microservice splitting and deployment.

[0034] The present invention has at least the following beneficial technical effects:

[0035] 1. By splitting the original program file into multiple independent microservices and performing independent deployment and management for each microservice, the present invention realizes the modularization, componentization, and service orientation of the application program. This architecture not only enables each functional module in the system to be developed, tested, deployed, and upgraded independently, thereby greatly improving the development efficiency and system maintainability, but also allows each microservice to flexibly configure startup scripts and exposure settings according to specific business requirements.

[0036] Therefore, this method not only enhances the flexibility of the system, but also enables the entire application to adapt to market dynamics more quickly, significantly improving the overall development and operation and maintenance efficiency. Enterprises can maintain efficient operations while more agilely responding to changing business requirements.

[0037] 2. By splitting a large and complex software application into multiple small and independent microservices, each service running in its own process and communicating using lightweight communication protocols, the present invention significantly improves the scalability, flexibility, and maintainability of the application program. Adopting this microservice architecture not only enables each service to be developed, deployed, and extended independently, but also further enhances the reliability and stability of the system by implementing a service registration and discovery mechanism.

[0038] Specifically, service instances can register their own information with the registration center, and other services can obtain the required service information through the registration center to achieve efficient mutual communication and collaboration. In this way, even if a certain service fails, it will not affect the normal operation of the entire system, because other services can still find alternative service instances through the registration center, ensuring the high availability and stability of the system.

[0039] Therefore, this method not only improves the overall performance of the system, but also makes it more adaptable to changing requirements and load conditions, ensuring business continuity and reliability.

[0040] 3. The present invention significantly optimizes resource utilization and reduces operation and maintenance costs through the way of microservice splitting and deployment. In an application server environment with high memory configuration, the traditional monolithic application deployment method often leads to a large amount of resource waste because they need to load the entire application program regardless of whether all components are required during actual operation. In contrast, the present invention only loads the necessary parts of the application, avoiding unnecessary resource consumption, thus greatly improving resource utilization.

[0041] In addition, multiple sets of logging mechanisms set independent log directories for different microservice applications, preventing the logs of different applications from overwriting each other. This not only simplifies the problem troubleshooting and debugging process, but also further reduces the operation and maintenance complexity and cost.

[0042] Through this refined resource management and log management strategy, the system can operate more efficiently, while reducing the additional overhead caused by log chaos or resource waste, ensuring higher operation and maintenance efficiency and lower total cost of ownership (TCO). In this way, enterprises can achieve a more economical and sustainable operation mode while ensuring high performance.

[0043] 4. The present invention can flexibly scan and load corresponding microservice applications according to input parameters by dynamically inserting loading information and configuring a custom class loader, thus meeting diverse business needs and significantly enhancing the availability and scalability of the system.

[0044] Specifically, the service registration and discovery mechanism not only supports starting multiple corresponding microservices by executing different startup scripts on the same machine or different machines, but also can inform other microservice applications of the allowable calls according to the exposure settings in the subdirectory. This mechanism ensures efficient communication and collaboration between microservices, enabling the system to easily scale to more service instances and maintain consistent operation effects in different environments.

[0045] In addition, through this way, the system can quickly respond to changes in business requirements and achieve more agile service deployment and adjustment. Generally speaking, this method not only enhances the availability and flexibility of the system, but also provides a solid foundation for its future expansion, ensuring that the system can continuously and stably operate under changing requirements and load conditions. In this way, enterprises can manage their service architectures more efficiently while ensuring high reliability and performance.

[0046] 5. The present invention significantly simplifies the update and deployment process and improves the user experience by adopting an independently deployed microservice architecture. Each microservice can be updated and maintained without affecting other services, thereby reducing the downtime of the overall system and ensuring that the system remains highly available during the change process.

[0047] In addition, the automated deployment and update process, including building packaging, deploying modules, and accepting modules, ensures the continuous deployment and update of software services. This automated mechanism not only improves development and operation efficiency, but also greatly simplifies operation work, allowing the team to focus more on the implementation and optimization of business logic.

[0048] Specifically, by dynamically inserting loading information and configuring a custom class loader, the corresponding microservice applications can be flexibly scanned and loaded according to the input parameters to meet diverse business needs. This approach not only supports rapid response to changes in market demand, but also ensures efficient collaboration and communication between microservices, further enhancing the flexibility and scalability of the system. Overall, these measures work together to provide enterprises with an efficient, reliable, and easy-to-manage service architecture, greatly improving overall operational efficiency and user satisfaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other embodiments can be obtained based on these drawings without paying creative work.

[0050] Figure 1 A flow chart of the method for splitting and deploying microservices provided by the present invention;

[0051] Figure 2 A system module diagram for performing microservice splitting and deployment provided by the present invention;

[0052] Figure 3 A flowchart of an embodiment of a method for splitting and deploying microservices provided by the present invention;

[0053] Figure 4 A schematic diagram of the structure of an embodiment of a computer device provided by the present invention;

[0054] Figure 5 A schematic diagram of the structure of an embodiment of a computer-readable storage medium provided by the present invention. DETAILED DESCRIPTION

[0055] To make the objectives, technical solutions, and advantages of the present invention more clearly understood, the following further elaborates on the embodiments of the present invention in detail with reference to specific embodiments and the accompanying drawings.

[0056] It should be noted that in all the descriptions using "first" and "second" in the embodiments of the present invention, they are used to distinguish two entities or parameters with the same name but different identities. It can be seen that "first" and "second" are only for the convenience of expression and should not be construed as limitations on the embodiments of the present invention. This will not be elaborated one by one in the subsequent embodiments.

[0057] The present invention proposes a method for microservice splitting and deployment, as Figure 1 and Figure 3 shown, including,

[0058] S1: Deploy a microservice file deployment environment in the product;

[0059] S2: Split the product into multiple microservice applications according to business requirements, and configure startup scripts and exposure settings in the subdirectories of the microservice applications;

[0060] S3: In response to receiving input parameters, scan the subdirectories of the microservice applications based on the input parameters, and load the startup scripts to start the microservices;

[0061] S4: In response to microservice registration discovery, notify other microservice applications through the exposure settings to allow calls.

[0062] The present invention mainly modifies the class loader in the product, which can read configurations, perform scans and loads. The specific method is: according to the input parameter name, scan the subdirectories under the application jar package directory, and load the configured directory for service startup settings.

[0063] Deploying a microservice file deployment environment in the product is one of the important steps to implement the microservice architecture, which lays a foundation for subsequent microservice splitting, deployment, and management.

[0064] This includes environment preparation, performing hardware resource and software environment preparation.

[0065] Hardware resources include: servers: ensure there are sufficient physical or virtual servers to host microservice applications. Each server should have sufficient computing power (CPU), memory, and storage space;

[0066] Network facilities: ensure stable and high-speed network connections between servers for inter-service communication.

[0067] Software environment preparation includes: operating system: select an operating system suitable for running microservices, such as Linux (CentOS, Ubuntu, etc.) or Windows Server.

[0068] Containerization technology: It is recommended to use containerization technologies such as Docker to provide a consistent running environment and simplify the deployment process.

[0069] Orchestration tools: Such as Kubernetes (K8s), which are used to manage and coordinate the deployment, scaling, and operation of containerized applications.

[0070] Split the product into multiple microservice applications according to business requirements, analyze the original program files to determine the splittable modules and components, as well as their dependencies and communication methods. According to the analysis results, split the original program files into multiple independent microservices. Each microservice should have clear functional boundaries and responsibilities and be able to run and upgrade independently.

[0071] In addition, in the configuration startup script, design the directory structure, create independent subdirectories for each microservice, including its code, configuration files, and startup script.

[0072] Write the startup script, which is responsible for initializing environment variables, loading configuration files, and starting the microservice.

[0073] In addition, configure the exposure settings, including service registration and discovery. In order for microservices to call each other, it is necessary to configure a service registration and discovery mechanism. Common tools include Eureka, Consul, and Zookeeper, etc.

[0074] Use an API gateway (such as Spring Cloud Gateway or Nginx) to uniformly manage and route requests for microservices. The API gateway can forward requests to the corresponding microservices according to the request path and provide functions such as load balancing and flow limiting.

[0075] Integrate a health check interface in each microservice for external monitoring systems (such as Prometheus, Grafana) to monitor.

[0076] The present invention realizes the modularization, componentization, and serviceization of the application program by splitting the original program files into multiple independent microservices and performing independent deployment and management on each microservice. It improves the flexibility and maintainability of the application program, reduces the complexity of the system, improves the development efficiency and system stability. At the same time, by implementing mechanisms such as service registration and discovery and log management, the availability and reliability of the system are further enhanced.

[0077] The microservice architecture splits large and complex software applications into multiple small and independent services. Each service runs in its own process and communicates using lightweight communication protocols. This architectural style helps to improve the scalability, flexibility, and maintainability of the application program.

[0078] In response to receiving the input parameters, scan the subdirectories of the microservice application based on the input parameters, and load the startup script to start the microservice.

[0079] Design of input parameters

[0080] First, it is necessary to define and understand the input parameters. These parameters typically include, but are not limited to, the following: service name, specifying the specific microservice to be started; port number, specifying the port on which the microservice runs; environment variables, such as log path, memory configuration, etc.; dependencies, specifying other resources or services required when the microservice starts.

[0081] Parameter parsing and processing

[0082] After receiving the input parameters, the system needs to parse these parameters and perform corresponding operations according to their contents. A scripting language (such as Shell, Python) can be used to implement this process.

[0083] Scan subdirectories and start microservices

[0084] According to the service name in the input parameters, the script needs to scan the corresponding subdirectories, find the corresponding startup script, and execute the startup command. This includes,

[0085] Parse the input parameters to obtain the input parameters from the command line or API request; determine the service directory, and determine the corresponding subdirectory path according to the service name; check the directory existence to ensure that the service directory exists, otherwise throw an error message; load the configuration file, read and load the configuration file (such as application.properties) to set more runtime parameters; execute the startup command: use Java or other commands to start the microservice, passing the necessary parameters.

[0086] Automated deployment and management

[0087] To further simplify the operation, CI / CD tools (such as Jenkins, GitLab CI) and container orchestration tools (such as Kubernetes) can be combined to achieve automated deployment and management.

[0088] Through the above steps, we can achieve dynamic scanning of the subdirectories of the microservice application based on the input parameters, and load the startup script to start the microservice. This method not only improves the flexibility and maintainability of the system, but also makes the management and expansion of microservices more convenient and efficient. Combined with automated tools, it can further improve the development and operation and maintenance efficiency, and ensure the high availability and stability of the system.

[0089] Responding to microservice registration discovery and notifying other microservice applications through exposure settings to allow calls is a key step in ensuring efficient communication and collaboration between microservices. Specifically,

[0090] Microservice registration and discovery: Each microservice instance in a microservice architecture needs to register its own information with a registration center when starting up so that other services can discover and call it. Common registration and discovery tools include Eureka, Consul, and Zookeeper, etc.

[0091] Select a registration center such as Eureka, Consul, Zookeeper, etc. Among them,

[0092] Eureka, a service discovery component open-sourced by Netflix, is suitable for the Spring Cloud ecosystem.

[0093] Consul, developed by HashiCorp, supports service registration, health checks, and service discovery.

[0094] Zookeeper, a distributed coordination service of Apache, is widely used in the Hadoop ecosystem.

[0095] Configure microservices to support registration and discovery:

[0096] Add dependencies. First, add the corresponding dependencies to the pom.xml or build.gradle file in each microservice project. Add the client configuration to the configuration file (such as application.properties or application.yml) of each microservice. Add annotations to the main class of the microservice to enable the client function.

[0097] Exposure settings. To enable other microservices to call the current service, it is necessary to configure the exposed interfaces and endpoints. This can usually be achieved through REST APIs.

[0098] Among them, define a REST controller. Define a REST controller in each microservice to provide specific business logic interfaces. Configure CORS. If the calls between microservices involve cross-origin requests, the CORS policy can be configured.

[0099] Implement service calls:

[0100] Among them, configure the service consumer. In the application that needs to call other microservices, configure RestTemplate or Feign clients for remote calls.

[0101] Use RestTemplate. Use RestTemplate in the service call code.

[0102] Use a Feign client and use it in the service call code.

[0103] Through the above steps, the registration and discovery mechanism of microservices is implemented, and other microservice applications are notified to allow calls by exposing settings. This method not only improves the flexibility and maintainability of the system, but also makes the communication between microservices more efficient and reliable. Combined with automated deployment tools and container orchestration tools (such as Kubernetes), the scalability and high availability of the system can be further enhanced to ensure the stable operation of the entire system in a complex environment.

[0104] In some embodiments, such as Figure 1 and Figure 3 shown, the method further includes:

[0105] In response to deploying multiple microservice applications, set multiple sets of corresponding logging to record different microservice applications.

[0106] Deploy an application on the application server, and then set subdirectories for multiple sets of logs, etc., to store product logs, GC logs and other log information. Avoid different applications overwriting each other, etc.

[0107] Perform log management for each microservice. Collect the log information of the microservice and display and analyze it through a visualization dashboard. Log management helps to discover and solve problems in a timely manner and ensure the stable operation of the system.

[0108] Specifically, the log directory structure design

[0109] Set up an independent log directory for each microservice to ensure that log files do not overwrite each other. A unified log root directory can be created on the application server, and subdirectories can be created for each microservice.

[0110] Configure the log recording path

[0111] Specify the storage path of the log file in the configuration file of each microservice. Usually, configuration files such as logback-spring.xml or log4j2.xml of Spring Boot can be used to achieve this.

[0112] Set the GC log path

[0113] For Java applications, the storage path of the garbage collection (GC) log can be set through JVM parameters.

[0114] Centralized log management

[0115] To better manage and analyze log information, it is recommended to use a centralized log management system such as the ELK Stack (Elasticsearch, Logstash, Kibana) or Graylog.

[0116] Among them, in the ELK Stack configuration, Elasticsearch is used to store and index log data. Logstash is used to collect and parse log data. Kibana is used to visualize and analyze log data.

[0117] Visualization dashboard

[0118] Create a dashboard through Kibana or other visualization tools for real-time monitoring and analysis of log information.

[0119] The steps to create a Kibana Dashboard include

[0120] Import log data: Ensure that Logstash has imported log data into Elasticsearch.

[0121] Create an index pattern: Create a new index pattern (e.g., microservices-*) in Kibana to identify all relevant log data.

[0122] Create visualization charts: Use visualization tools such as bar charts and line charts to display information such as the number of logs and error distribution; use tables to display specific log content.

[0123] Build a dashboard: Combine various visualization charts into a dashboard for overall viewing and analysis.

[0124] Monitoring and alarm

[0125] In addition to log management, it is also necessary to set up monitoring and alarm mechanisms to promptly detect and handle abnormal situations in the system.

[0126] Use Prometheus + Grafana in combination, where

[0127] Prometheus is used to collect and store metric data. Grafana is used for visualization and alarm.

[0128] Configure Prometheus, integrate the Prometheus client library in each microservice, and expose the health check interface.

[0129] Configure Grafana, add a Prometheus data source in Grafana, and create corresponding panels and dashboards. Set up alarm rules to trigger alarms when certain key metrics (such as response time, memory usage) exceed the thresholds.

[0130] Through the above steps, we have achieved the log management of multiple microservice applications, set up independent log directories, and avoided the mutual overwriting of logs between different applications. At the same time, with the use of a centralized log management system (such as the ELK Stack) and a visualization dashboard (such as Kibana), it is convenient to collect, store, analyze, and display logs. In addition, combined with monitoring and alarm mechanisms (such as Prometheus and Grafana), problems in the system can be detected and solved in a timely manner to ensure the stable operation of the system. This method not only improves the efficiency of log management but also enhances the maintainability and reliability of the system.

[0131] In some embodiments, such as Figure 1 and Figure 3 shown, the startup script includes the service name, port, log, memory configuration, and loading path.

[0132] Write a startup script, and the script content mainly includes:

[0133] Injection of different service names, such as FI - Financial Microservice, SCM - Supply Chain Microservice, TAX - Tax Microservice, etc.;

[0134] Different ports, similar to the settings of Dserver.port, etc. To avoid conflicts on the same application server;

[0135] Different logs, GC log directories, and different microservices select different log storage paths;

[0136] Different memory configurations, to cope with different service configurations, and set CPU quantity limits, etc., to avoid excessive usage;

[0137] Loading path, the folder of the microservice that this process needs to load, and the dependent folders. For example, for FI and the platform address, FI and PT, etc. need to be written.

[0138] In some embodiments, such as Figure 1 and Figure 3 shown, the steps of configuring the startup script in the sub - directory of the microservice application include:

[0139] Design a corresponding deployment strategy for the microservice application;

[0140] Define the microservice application interface and protocol;

[0141] Set the folders of microservices to be loaded in this process and the dependent folders.

[0142] In some embodiments, such as Figure 1 and Figure 3 shown, the steps of deploying the microservice file deployment environment in the product include:

[0143] Deploy the registration and discovery software for multiple microservice applications;

[0144] Modify the default configuration of the product.

[0145] In the application server, multiple microservices can be deployed and run. These microservices cooperate with each other through the unified interfaces and specifications provided by the application server to jointly complete the complex business logic of the application program.

[0146] The service registration and discovery component is the core component in the microservice architecture, and it is responsible for service registration and discovery. A service instance can register its own service information into the registration center, including information such as the IP of the host where the service is located, the port providing the service, the status of the service itself, and the access protocol. At the same time, a service instance can also obtain the service information it depends on from the registration center. This makes the communication and cooperation between services more flexible and efficient. Using the registration and discovery software can achieve multi-node deployment, thus supporting high availability. This avoids single-point failures and improves the availability and reliability of the system.

[0147] In some embodiments, such as Figure 1 and Figure 3 shown, the steps of, in response to microservice application registration and discovery, notifying other microservice applications that they are allowed to call through exposure settings include:

[0148] Set the subdirectory of the microservice application as the smallest loading unit;

[0149] In response to microservice application registration and discovery, perform the exposure settings of the microservice according to the subdirectory of the microservice application, and inform other microservice applications that they can call this microservice application.

[0150] The product needs to improve a set of systems, set the application subdirectory as the smallest loading unit, and be able to expose services according to the directory, be able to perform service registration and discovery, and inform other applications that they can call themselves.

[0151] To achieve communication and cooperation between microservices, a service discovery and registration mechanism can be configured. Each microservice instance registers its own information with the registration center when starting, and other microservices can discover the addresses and ports of other services through the registration center, thus achieving mutual communication.

[0152] In some embodiments, such as Figure 1 andFigure 3 As shown, the method further includes:

[0153] Execute different startup scripts on the same machine or different machines to start multiple corresponding microservices.

[0154] In the application server, each microservice can be deployed and run as an independent module or component. The application server provides a unified running environment and management tools for these microservices, enabling them to cooperate with each other to jointly fulfill the business requirements of the application program. Use separate startup scripts to start the services. Implement a set of original files for convenient processing of starting multiple services.

[0155] The present invention proposes a system for microservice splitting and deployment, as Figure 2 shown, including:

[0156] A deployment unit 100, configured to deploy a microservice file deployment environment in a product;

[0157] A splitting unit 200, configured to split a product into multiple microservice applications according to business requirements, and configure startup scripts and exposure settings in the subdirectories of the microservice applications;

[0158] A startup unit 300, configured to, in response to receiving input parameters, scan the subdirectories of the microservice applications based on the input parameters, and load the startup scripts to start the microservices;

[0159] A discovery unit 400, configured to, in response to microservice registration and discovery, notify other microservice applications through the exposure settings to allow calls.

[0160] The present invention proposes a system for microservice splitting and deployment, which uses script dynamic insertion to load information that can be loaded, configures a custom class loader, and only loads part of the application, realizing a set of deployment files and achieving multiple service deployment scenarios.

[0161] Based on the same inventive concept, according to another aspect of the present invention, as Figure 4 shown, an embodiment of the present invention further provides a computer device 30, which includes a processor 310 and a memory 320 in the computer device 30. The memory 320 stores a computer program 321 that can run on the processor, and the processor 310 executes the steps of the above method when executing the program.

[0162] Based on the same inventive concept, according to another aspect of the present invention, as Figure 5 shown, an embodiment of the present invention further provides a computer-readable storage medium 40, and the computer-readable storage medium 40 stores a computer program 410 that executes the above method when executed by a processor.

[0163] The embodiment of the present invention may also include a corresponding computer device. The computer device includes a memory, at least one processor, and a computer program stored in the memory and executable on the processor, and the processor executes any one of the above methods when executing the program.

[0164] The memory, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as program instructions / modules in the embodiments of the present application. The processor executes various functional applications and data processing of the device by running the non-volatile software programs, instructions and modules stored in the memory, that is, implementing the above method.

[0165] The memory may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the device, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In an embodiment, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the local module via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0166] Finally, it should be noted that a person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the storage medium of the program can be a disk, an optical disk, a read-only storage memory (ROM) or a random access memory (RAM), etc. The above-mentioned computer program embodiments can achieve the same or similar effects as the corresponding above-mentioned arbitrary method embodiments.

[0167] It will also be appreciated by those skilled in the art that various exemplary logic blocks, modules, circuits and algorithm steps described in conjunction with the disclosure herein can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, a general description has been given to the functions of various schematic components, blocks, modules, circuits and steps. Whether this function is implemented as software or hardware depends on specific applications and the design constraints imposed on the entire system. Those skilled in the art can implement the function in various ways for each specific application, but this implementation decision should not be interpreted as causing a departure from the disclosed scope of the embodiments of the present invention.

[0168] The above are exemplary embodiments disclosed by the present invention. However, it should be noted that various changes and modifications can be made without departing from the scope of the embodiments disclosed by the present invention as defined by the claims. The functions, steps, and / or actions of the method claims according to the disclosed embodiments herein do not need to be performed in any specific order. The serial numbers of the disclosed embodiments of the present invention above are only for description and do not represent the superiority or inferiority of the embodiments. In addition, although the elements disclosed by the embodiments of the present invention can be described or claimed in an individual form, they can also be understood as plural unless explicitly limited to the singular form.

[0169] It should be understood that, as used herein, unless the context clearly supports an exception, the singular form "a" is also intended to include the plural form. It should also be understood that the "and / or" used herein refers to any and all possible combinations of one or more of the related listed items.

[0170] Those of ordinary skill in the art should understand that the discussion of any of the above embodiments is only exemplary and is not intended to imply that the scope of the disclosure of the embodiments of the present invention (including the claims) is limited to these examples; under the concept of the embodiments of the present invention, the technical features between the above embodiments or different embodiments can also be combined, and there are many other variations in different aspects of the embodiments of the present invention as above, which are not provided in detail for the sake of brevity. Therefore, any omission, modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiments of the present invention shall be included within the protection scope of the embodiments of the present invention.

Claims

1. A method for splitting and deploying microservices, characterized in that: include, Deploy the microservice file deployment environment in the product; Split the product into multiple microservice applications based on business needs, and configure startup scripts and exposure settings in the subdirectories of the microservice applications; In response to receiving the input parameter, scanning the subdirectory of the microservice application based on the input parameter, and loading the startup script to start the microservice; In response to performing microservice registration discovery, other microservice applications are notified through the exposure setting to allow calls.

2. The method for splitting and deploying microservices according to claim 1, characterized in that: The method also includes: In response to deploying multiple microservice applications, multiple sets of corresponding log records are set for different microservice applications.

3. The method for splitting and deploying microservices according to claim 1, characterized in that: The startup script includes the service name, port, log, memory configuration and loading path.

4. The method for splitting and deploying microservices according to claim 3, characterized in that: The step of configuring a startup script in a subdirectory of the microservice application includes: Design a corresponding deployment strategy for the microservice application; Defining the microservice application interface and protocol; Set the folder of the microservices that need to be loaded in this process and the folder of dependencies.

5. The method for splitting and deploying microservices according to claim 1, characterized in that: The steps of deploying the microservice file deployment environment in the product include: Deploy registration and discovery software for multiple microservice applications; Modify the default configuration of the product.

6. The method for splitting and deploying microservices according to claim 1, characterized in that: In response to performing microservice application registration discovery, the step of notifying other microservice applications through the exposure setting to allow invocation includes: Set the subdirectory of the microservice application as the smallest unit for loading; In response to performing a microservice application registration discovery, the microservice exposure setting is performed according to the subdirectory of the microservice application to inform other microservice applications that they can call the microservice application.

7. The method for splitting and deploying microservices according to claim 1, characterized in that: The method also includes: Execute different startup scripts on the same machine or different machines to start multiple corresponding microservices.

8. A system for splitting and deploying microservices, characterized in that: include: A deployment unit, configured to deploy a microservice file deployment environment in production; A splitting unit, configured to split the product into multiple microservice applications according to business requirements, and configure startup scripts and exposure settings in subdirectories of the microservice applications; A startup unit, configured to, in response to receiving an input parameter, scan a subdirectory of the microservice application based on the input parameter, and load a startup script to start the microservice; The discovery unit is configured to, in response to performing microservice registration discovery, notify other microservice applications to allow invocation through the exposure setting.

9. A computer device comprising: at least one processor; and a memory storing a computer program executable on the processor, wherein the processor executes the steps of the method for splitting and deploying microservices as described in any one of claims 1 to 7 when executing the program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method for splitting and deploying microservices as described in any one of claims 1 to 7 are performed.

Images