Business processing method and device based on database migration and electronic equipment

Abstract

This application discloses a business processing method, apparatus, and electronic device based on database migration. Relating to the distributed computing field, the method includes: for each microservice, upon startup, detecting whether a database migration script to be executed exists in the target storage area based on the database information of the database associated with the microservice, wherein different microservices are associated with different databases; if a database migration script to be executed exists, executing the database migration script on the database associated with the microservice; and, if all database migration scripts to be executed have been completed, or if no database migration script to be executed exists in the target storage area, starting the microservice's business service for business processing. This application solves the problem in related technologies where all microservices share a database, requiring the pausing and restarting of all microservices during database migration, resulting in low reliability of business processing.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and more specifically, to a business processing method, apparatus, and electronic device based on database migration. Background Technology

[0002] With the rapid development of internet technology, the scale and complexity of software systems are constantly increasing. Traditional monolithic architectures, due to their high coupling and poor scalability, are no longer able to meet the development needs of large-scale systems. Against this backdrop, microservice architecture has emerged. Microservice architecture breaks down a complete application system into multiple independent, autonomous microservices. Each microservice focuses on implementing a specific business function, and modules interact through lightweight communication protocols. Currently, microservice architecture is widely used in e-commerce, finance, logistics, healthcare, and many other industries, becoming the mainstream architectural pattern for building large-scale distributed application systems. However, in the practical application of microservice architecture, data governance, especially database migration management, faces many challenges. How to efficiently and securely update and maintain the database structure has become one of the key issues affecting the stability and availability of microservice architecture.

[0003] Traditional microservice architecture database migration solutions typically employ a "centralized migration" model. This means all microservices share a single database migration strategy and script. When database structure adjustments are needed (such as adding tables, modifying fields, or deleting indexes), a unified database migration operation is executed. The process generally involves developers writing a unified database migration script, then operations personnel pausing all microservices within a specified time window, applying the migration script to the database using a dedicated migration tool, and finally restarting all microservices after the migration is complete. This approach is barely applicable in scenarios with a small number of microservices and infrequent business changes. However, in large-scale microservice architectures (containing dozens or even hundreds of microservices) and rapidly iterating business requirements, once a database migration is performed, all microservices must be paused, leading to a significant reduction in overall system availability. Especially for core business systems, prolonged downtime results in substantial economic losses and a degraded user experience, resulting in low business processing reliability.

[0004] There is currently no effective solution to the aforementioned problems in the relevant technologies. Summary of the Invention

[0005] The main purpose of this application is to provide a business processing method, apparatus, and electronic device based on database migration, so as to solve the problem of low business processing reliability in related technologies where all microservices share a database and all microservices need to be paused and restarted during database migration.

[0006] To achieve the above objectives, according to one aspect of this application, a business processing method based on database migration is provided. The method includes: for each microservice, upon startup of the microservice, detecting whether a database migration script to be executed exists in the target storage area based on the database information of the database associated with the microservice, wherein different microservices are associated with different databases; if a database migration script to be executed exists, executing the database migration script on the database associated with the microservice; and if all database migration scripts to be executed have been completed, or if no database migration script to be executed exists in the target storage area, starting the microservice's business service to perform business processing.

[0007] Optionally, the business processing method based on database migration also includes: determining the version number of the historical database migration script from the database information; and detecting whether there is a database migration script to be executed in the target storage area based on the version number of the historical database migration script.

[0008] Optionally, the business processing method based on database migration also includes: determining the latest version number of the historical database migration script; detecting whether the target database migration script exists in the target storage area, wherein the version number of the target database migration script is greater than the latest version number; if the target database migration script exists, determining that the target database migration script is the database migration script to be executed in the target storage area; if the target database migration script does not exist, determining that there is no database migration script to be executed in the target storage area.

[0009] Optionally, the business processing method based on database migration also includes: determining whether there are multiple database migration scripts to be executed; if there are multiple database migration scripts to be executed, determining the execution order of the multiple database migration scripts based on their version numbers; and executing the multiple database migration scripts on the database associated with the microservice in the execution order.

[0010] Optionally, the business processing method based on database migration may also include: determining the dependencies between multiple microservices; determining the startup order of multiple microservices based on the dependencies, or determining the order in which multiple microservices execute database migration scripts based on the dependencies.

[0011] Optionally, the business processing method based on database migration also includes: obtaining database information from the target data table of the database before detecting whether there is a database migration script to be executed in the target storage area based on the database information of the database associated with the microservice; after executing the database migration script on the database associated with the microservice, detecting whether the database migration script has been executed successfully; and if the database migration script has been executed successfully, recording the script information of the database migration script into the database information in the target data table.

[0012] Optionally, the business processing method based on database migration also includes: after detecting whether the database migration script has been executed successfully, if the database migration script fails to execute, prohibiting the startup of microservice business services and generating error logs.

[0013] To achieve the above objectives, according to another aspect of this application, a business processing apparatus based on database migration is provided. This apparatus is applied to a target processing system, which includes multiple microservices. The apparatus includes: a first detection module, configured to, for each microservice, upon startup, detect whether a database migration script to be executed exists in a target storage area based on the database information of the database associated with the microservice, wherein different microservices are associated with different databases; a first processing module, configured to execute the database migration script on the database associated with the microservice if the script exists; and a second processing module, configured to start the business service of the microservice for business processing after all the database migration scripts to be executed have been completed, or if no database migration script exists in the target storage area.

[0014] Optionally, the first detection module further includes: a first determination submodule, used to determine the version number of the historical database migration script from the database information; and a detection submodule, used to detect whether there is a database migration script to be executed in the target storage area based on the version number of the historical database migration script.

[0015] Optionally, the detection submodule further includes: a first determining unit, used to determine the latest version number of the historical database migration script; a detection unit, used to detect whether the target database migration script exists in the target storage area, wherein the version number of the target database migration script is greater than the latest version number; a second determining unit, used to determine that the target database migration script is the database migration script to be executed in the target storage area if the target database migration script exists; and a third determining unit, used to determine that there is no database migration script to be executed in the target storage area if the target database migration script does not exist.

[0016] Optionally, the first processing module further includes: a judgment submodule, used to determine whether there are multiple database migration scripts to be executed; a second determination submodule, used to determine the execution order of multiple database migration scripts based on their version numbers when there are multiple database migration scripts to be executed; and a processing submodule, used to execute multiple database migration scripts on the database associated with the microservice in the execution order.

[0017] Optionally, the business processing device further includes: a first determining module for determining the dependencies between multiple microservices; and a second determining module for determining the startup order of multiple microservices based on the dependencies, or determining the order in which multiple microservices execute database migration scripts based on the dependencies.

[0018] Optionally, the business processing device further includes: an acquisition module, used to acquire database information from the target data table of the database before detecting whether there is a database migration script to be executed in the target storage area based on the database information of the database associated with the microservice; a second detection module, used to detect whether the database migration script has been executed successfully after executing the database migration script on the database associated with the microservice; and a third processing module, used to record the script information of the database migration script into the database information in the target data table if the database migration script has been executed successfully.

[0019] Optionally, the business processing device also includes: a fourth processing module, used to prevent the microservice from starting its business services and generate error logs in the event that the database migration script fails to execute.

[0020] To achieve the above objectives, according to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the above-described database migration-based business processing method.

[0021] To achieve the above objectives, according to another aspect of this application, an electronic device is provided, the electronic device including a memory storing an executable program; and a processor for running the program, wherein the program executes the above-described database migration-based business processing method during runtime.

[0022] To achieve the above objectives, according to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the above-described database migration-based business processing method.

[0023] In this embodiment, multiple microservices in the target processing system are designed to be associated with different databases. When there are database migration scripts to be executed, the database migration scripts are executed on the databases associated with the microservices. When all database migration scripts to be executed have been completed, or when there are no database migration scripts to be executed in the target storage area, the business service is started directly. This achieves a decentralized migration model for database migration. The database migration operation of each microservice can be executed independently, and the database migration operations between microservices no longer affect each other. Other microservices that do not need to be migrated can be started quickly, thereby significantly reducing the downtime of microservices and improving the reliability of business processing.

[0024] Therefore, the method provided in this application achieves the goal of migrating the database using a decentralized migration model for microservices, thereby improving the technical effect of business processing reliability. It solves the technical problem in related technologies where all microservices share a database, and all microservices need to be paused and restarted during database migration, resulting in low business processing reliability. Attached Figure Description

[0025] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0026] Figure 1 This is a hardware structure block diagram of a computer terminal provided according to an embodiment of this application;

[0027] Figure 2 This is a flowchart of a business processing method based on database migration provided in the embodiments of this application;

[0028] Figure 3 This is a schematic diagram of the target processing system provided according to an embodiment of this application;

[0029] Figure 4 This is a schematic diagram of a business processing method based on database migration provided in an embodiment of this application;

[0030] Figure 5 This is a schematic diagram of a business processing apparatus provided according to an embodiment of this application;

[0031] Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0035] Example 1

[0036] According to an embodiment of this application, an embodiment of a business processing method based on database migration is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1A hardware block diagram of a computer terminal (or mobile device) for implementing a database migration-based business processing method is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor (MCU) or a field-programmable gate array (FPGA), etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output (I / O) interface, a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0038] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0039] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the database migration-based business processing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned database migration-based business processing method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0040] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0041] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0042] Under the aforementioned operating environment, this application provides the following: Figure 2 The database migration-based business processing method shown is applied to the target processing system, which includes multiple microservices. Figure 2 This is a flowchart of a business processing method based on database migration according to Embodiment 1 of this application.

[0043] Step S201: For each microservice, when the microservice is started, detect whether there is a database migration script to be executed in the target storage area based on the database information of the database associated with the microservice. Different microservices are associated with different databases.

[0044] In an alternative embodiment, Figure 3 This is a schematic diagram of the target processing system provided according to an embodiment of this application, such as... Figure 3As shown, the target processing system may include a service gateway, multiple independent microservices, a registry center, a configuration center, and a database cluster. The service gateway receives client requests and forwards them to the corresponding microservices according to request routing rules. Each microservice corresponds to a specific business domain (such as user service, monitoring service, process management service, etc.) and executes corresponding business functions to provide corresponding business services. Each microservice has an independent code repository, development and deployment process, and database instance. The registry center is used for microservice registration and discovery, enabling dynamic communication between modules. The configuration center centrally manages the configuration information of all microservices (such as database connection information, automatic migration component configuration parameters, etc.) and supports dynamic configuration updates. The database cluster adopts a "one module, one database" or "one module, multiple databases" design pattern, meaning that one microservice is associated with at least one database, and different microservices are associated with different databases. Each microservice's database is independent of other microservices' databases, avoiding data coupling.

[0045] like Figure 3 As shown, each microservice registers its key information with the Service Registry and Discovery Center upon startup. The Configuration Center provides unified configuration management services for each microservice. Upon startup, each microservice retrieves necessary configuration information from the Configuration Center, such as database connection parameters, third-party service interface addresses, and business rule configurations. Each microservice represents an independent business functional unit (such as user service, monitoring service, process management service, etc.). Each business module has its own automatic migration component.

[0046] The aforementioned database cluster employs a decentralized database architecture, with each microservice associated with a specific database within the cluster. Database design, data storage, and migration operations are all managed autonomously by the corresponding microservice. For scenarios involving cross-module data interaction, data sharing is achieved through service calls, rather than direct access to other microservices' databases, ensuring the independence and security of each microservice's database.

[0047] In an optional embodiment, the microservice may include an auto-migration component. Upon microservice startup, the auto-migration component reads parameters from the configuration center, including database connection information and the storage path of the database migration scripts. Then, the auto-migration component queries the target data table "xxx_schema_history" to retrieve database information, which at least records the latest version number of the historical database migration scripts associated with the microservice. Next, it scans all database migration scripts in the target storage area (i.e., the storage area pointed to by the storage path) and, based on the latest version number in the database information, detects whether a database migration script to be executed exists in the target storage area. The database migration scripts are used to perform structural changes or data adjustments to the database.

[0048] For example, the automatic migration component queries the "xxx_schema_history" table in the database to obtain the current database version number; it then compares the script version number with the current database version number to select the migration scripts that need to be executed.

[0049] In an optional embodiment, the target data table can be stored in the database associated with the microservice. The target data table will differ for different microservices. The database information in the target data table may include the version number, script name, script execution time, script execution result, and database file verification information of the database migration script for each migration operation, thereby achieving accurate management of the database version.

[0050] Step S202: If there is a database migration script to be executed, execute the database migration script on the database associated with the microservice.

[0051] In an optional embodiment, a database migration script is executed on the database associated with the microservice via an auto-migration component within the microservice. The target processing system can integrate the auto-migration component into the microservice in the following ways:

[0052] (1) Introduce the relevant dependency packages of the automatic migration component into the project dependencies of the microservice.

[0053] (2) Configure the automatic migration component parameters in the microservice configuration file, including database connection information, migration script storage path, pre-migration checks, whether automatic migration is allowed, and handling strategies after migration failure.

[0054] (3) Store the database migration scripts of the microservices in the specified script path (i.e., storage path) according to the naming convention of the automatic migration component (e.g., version number__migration description.sql).

[0055] (4) Add automatic migration component initialization logic to the startup process of the microservice module so that when the microservice module starts, the automatic migration component automatically loads and executes the migration script, and then starts the business service of the microservice after execution, so that the database state is consistent with the code version of the microservice module.

[0056] In an optional embodiment, when the microservice starts, it first loads the auto-migration component configuration parameters (database connection information, script paths, etc.) from the configuration center. Then, it initializes the auto-migration component and establishes a connection to the microservice's dedicated database. Upon detecting a database migration script to be executed, the auto-migration component executes the script on the database associated with the microservice. The database migration script may be used to perform structural updates to the database, such as creating tables, modifying fields, or adding indexes.

[0057] Step S203: After all pending database migration scripts have been executed, or if no pending database migration scripts exist in the target storage area, start the microservice's business service to perform business processing.

[0058] Optionally, after confirming that all pending database migration scripts have been successfully executed, or that no pending database migration scripts exist in the target storage area, the microservice can start its business services. At this stage, the microservice will load the business logic-related code and begin listening on its specific port or queue, ready to accept external requests and perform business processing.

[0059] Optionally, if a new database migration operation is required on the database associated with a microservice during its operation, the target processing system can first store the required new database migration script in the target storage area, and then control the microservice to restart. During the next startup, the microservice checks whether the database migration script to be executed exists in the target storage area and performs subsequent steps based on the detection result. This allows only the microservices requiring database migration to be restarted during database migration, without needing to restart all microservices, thereby improving the reliability of microservice business processing.

[0060] In related technologies, because migration scripts for all microservices are managed uniformly, database change requirements for different microservices are prone to interference, increasing the difficulty of script writing and maintenance, and also raising the risk of errors during migration. Therefore, by decoupling the databases corresponding to microservices in this embodiment, maintenance difficulty can be effectively reduced, thereby improving the reliability of business processing. Furthermore, related technologies cannot selectively upgrade based on the business needs of different microservices; they can only perform unified migration of the databases of all microservices, making it difficult to meet the needs of scenarios where only some microservices need to be updated individually. Therefore, the decoupling scheme in this embodiment can also effectively improve the flexibility of database migration, that is, improve the flexibility of business processing.

[0061] In this embodiment, multiple microservices in the target processing system are designed to be associated with different databases. When there are database migration scripts to be executed, the database migration scripts are executed on the databases associated with the microservices. When all database migration scripts to be executed have been completed, or when there are no database migration scripts to be executed in the target storage area, the business service is started directly. This achieves a decentralized migration model for database migration. The database migration operation of each microservice can be executed independently, and the database migration operations between microservices no longer affect each other. Other microservices that do not need to be migrated can be started quickly, thereby significantly reducing the downtime of microservices and improving the reliability of business processing.

[0062] Therefore, the method provided in this application achieves the goal of migrating the database using a decentralized migration model for microservices, thereby improving the technical effect of business processing reliability. It solves the technical problem in related technologies where all microservices share a database, and all microservices need to be paused and restarted during database migration, resulting in low business processing reliability.

[0063] Optionally, in the business processing method based on database migration provided in the embodiments of this application, detecting whether there is a database migration script to be executed in the target storage area according to the database information of the database associated with the microservice includes: determining the version number of the historical database migration script of the database from the database information; and detecting whether there is a database migration script to be executed in the target storage area according to the version number of the historical database migration script.

[0064] Optionally, the database information includes the version numbers of all database migration scripts that have been executed for the current database (i.e., the database associated with the microservice). These previously executed database migration scripts are also known as historical database migration scripts.

[0065] After obtaining the version number of the historical database migration script, the target processing system can detect whether there is a database migration script to be executed in the target storage area based on the version number of the historical database migration script.

[0066] It should be noted that by comparing historical version numbers, microservices can accurately identify which scripts need to be executed, avoiding missed or redundant database updates and improving the reliability of database migration.

[0067] Optionally, in the database migration-based business processing method provided in this application embodiment, detecting whether there is a database migration script to be executed in the target storage area according to the version number of the historical database migration script includes: determining the latest version number of the historical database migration script; detecting whether there is a target database migration script in the target storage area, wherein the version number of the target database migration script is greater than the latest version number; if there is a target database migration script, then determining that the target database migration script is a database migration script to be executed in the target storage area; if there is no target database migration script, then determining that there is no database migration script to be executed in the target storage area.

[0068] Optionally, the latest version number of the historical database migration script can be understood as the version number of the last successfully executed database migration script recorded in the database information.

[0069] After determining the latest version number, the microservice checks if the target database migration script exists in the target storage region. If a database migration script with a version number greater than the historical latest version number is detected, the microservice lists it as a database migration script to be executed. If the target database migration script is not found in the target storage region, it is determined that no database migration script exists in the target storage region.

[0070] In an optional embodiment, a three-part version numbering rule of "major version number, minor version number, revision number" or a fixed-digit sequence of numbers generated using timestamps can be used as the version number of the database migration script. The migration script's name can include the version number and script description, and can also distinguish whether the migration script is an upgrade script, rollback script, or re-execution script, so that the automatic migration component can perform the corresponding database changes when the module starts. Each migration script has a unique version number to avoid version conflicts. For example, the name of a database migration script can be represented in the following form:

[0071] (1) Database migration script for upgrade type: V<version number>__<script description>.sql (e.g., V1.0.0__init_user_schema.sql);

[0072] (2) Rollback type database migration script: U<version number>__<script description>.sql (e.g., U1.0.0__rollback_init_user_schema.sql);

[0073] (3) Data migration scripts that are executed repeatedly: R<version number>__<script description>.sql (e.g., R1.0.0__refresh_user_data.sql, used for repetitive operations such as data initialization, statistical data updates, etc.).

[0074] For example, the automatic migration component reads the version number from the migration script in the target storage area and compares it with the latest version number recorded in the "xxx_schema_history" table in the database to determine the migration operation to be performed. When it detects that a version number has not been executed, it automatically executes these scripts in version number order and records the execution result (success / failure) in the aforementioned table, while updating the database's historical migration script version number. When the script type is rollback, it executes the corresponding version of the rollback script to restore the database structure to the target version state.

[0075] In an optional embodiment, the latest version number corresponding to historical database migration scripts of different script types is determined from the database information. Then, for a script in the target storage area, it is determined whether the script is a target database migration script based on the latest version number corresponding to the script type. In simpler terms, each script type has an independent latest version number, and the existence of a corresponding target database migration script for that script type is determined independently based on the latest script number of that script type.

[0076] In an optional embodiment, if it is determined that the target database migration script does not exist in the target storage area, and if the script type is repetitive execution, then it is checked whether a first database migration script exists in the target storage area, and the version number of the first database migration script is equal to the latest version number. If the first database migration script exists in the target storage area, the first database migration script is determined as the database migration script to be executed in the target storage area; if the first database migration script does not exist in the target storage area, it is determined that there is no database migration script to be executed in the target storage area.

[0077] It should be noted that comparing the latest version number in the database information with the version number of the script in the target storage area to detect the script to be executed can effectively improve the accuracy of the detection results.

[0078] Optionally, in the business processing method based on database migration provided in the embodiments of this application, executing database migration scripts on the database associated with the microservice includes: determining whether there are multiple database migration scripts to be executed; if there are multiple database migration scripts to be executed, determining the execution order of the multiple database migration scripts based on the version numbers of the multiple database migration scripts; and executing the multiple database migration scripts on the database associated with the microservice according to the execution order.

[0079] Optionally, if there is only one database migration script to be executed, the database migration script can be executed directly.

[0080] Optionally, if there are multiple database migration scripts to be executed, the detected scripts will be sorted according to their version numbers. The version numbers follow an ascending order. For example, script V1.0.1 will be placed before V1.0.2, and so on. The order in which the database migration scripts are listed will determine the execution order. That is, migration scripts with smaller version numbers were generated earlier and will be executed first.

[0081] Once the execution order is determined, the automatic migration component will start executing the first script, and after its success, it will continue to execute the next script until all scripts to be executed are completed.

[0082] It should be noted that determining the execution order based on the version number avoids execution conflicts between scripts and improves the accuracy of the determined execution order, thereby improving the reliability of database migration and, consequently, the reliability of business processing.

[0083] Optionally, in the business processing method based on database migration provided in the embodiments of this application, the method further includes: determining the dependencies between multiple microservices; determining the startup order of multiple microservices according to the dependencies, or determining the order in which multiple microservices execute database migration scripts according to the dependencies.

[0084] When designing a microservice architecture, the development team defines the dependencies between services based on business processes and data flows, and records this information in a configuration center or service registration and discovery center. For example, a payment service may depend on a user service and an order service; this dependency can be reflected through inter-service API calls or message queue subscription relationships.

[0085] For microservices with dependencies (such as the process management service depending on the user ID of the user service), the database migration operation of the dependent party (process management service) needs to be later than the data migration of the dependent party (user service) to ensure that the data structure of the dependent party meets the requirements when the dependent party is migrated, and to avoid problems in cross-service data interaction.

[0086] In an optional embodiment, a migration priority can be set for each microservice through a configuration center. When multiple microservices need to be started, migration operations are performed in descending order of priority (e.g., the migration of the dependent module is performed first, followed by the migration of the dependent module). This approach can be achieved by controlling the startup order of microservices, or by controlling the order in which the database migration scripts are executed by the microservices after they have started.

[0087] For example, when multiple microservices need to undergo database migration, the system controls the startup of the highest-priority microservice based on their dependencies. The microservice with the highest priority is started first, and its database migration is completed. Alternatively, after the business service is started, the next highest-priority microservice is started. After the database migration is complete, each microservice can report its migration status (success / failure) or business service startup status to the registry center.

[0088] For example, when multiple microservices need to migrate their databases, the system first starts the multiple microservices. At this stage, the microservices do not perform the database migration operation themselves; instead, they perform the migration only after receiving a migration-ready instruction from the registry center. Each microservice reports its migration status (success / failure) to the registry center after completing the migration. The registry center, upon receiving a notification that a microservice has completed its migration, sends a migration-ready instruction to the microservices that depend on it. In an optional embodiment, other microservices can also query the migration status of their dependent microservices through the registry center, so that they only begin their own migration operation after the dependent microservice has successfully migrated.

[0089] In an alternative embodiment, a distributed lock (e.g., a database table-based distributed lock) can be introduced into the database cluster. When multiple microservices need to operate on shared resources (e.g., a common configuration table across modules), the distributed lock ensures that only one microservice performs the migration operation at the same time, thus avoiding data conflicts.

[0090] It's worth noting that by introducing dependency analysis between microservices and determining the startup order of microservices and the execution order of database migration scripts accordingly, the stability and data consistency of the microservice architecture are effectively improved. This approach effectively avoids service startup conflicts and data inconsistencies in a microservice environment, thereby enhancing the reliability of business processing.

[0091] Optionally, in the business processing method based on database migration provided in the embodiments of this application, before detecting whether there is a database migration script to be executed in the target storage area according to the database information of the database associated with the microservice, the method further includes: obtaining database information from the target data table of the database; after executing the database migration script on the database associated with the microservice, the method further includes: detecting whether the database migration script has been executed successfully; if the database migration script has been executed successfully, recording the script information of the database migration script into the database information in the target data table.

[0092] In an optional embodiment, the target data table is stored in the database associated with the microservice. For example, a target data table named "xxx_schema_history" is created in the database to record information such as the version number, migration script name, execution time, execution result, and database file checksum for each migration operation, thereby achieving effective management of database versions.

[0093] After executing the database migration script on the database associated with the microservice, check whether the database migration script was executed successfully. If it was executed successfully, write the script's version number, name, execution time, execution result, migration file checksum and other information into the "xxx_schema_history" table.

[0094] Optionally, if all migration scripts execute successfully and the automatic migration component initialization is complete, the microservice can continue to start business services and provide services to the outside world.

[0095] It's worth noting that this solution achieves precise control over database migration through a version number management mechanism, supporting flexible rollback and selective upgrade operations. When database migration errors occur, developers can quickly locate the problematic version based on the version records in the target data table and execute the corresponding rollback script to restore the database to its previous stable state, avoiding the complex manual backup recovery operations of traditional solutions. Furthermore, based on business needs, only the databases of specific microservices can be upgraded, while other modules retain their original versions, meeting the differentiated update requirements of different business modules. In addition, the automatic migration component supports various types of migration scripts and custom migration logic, adapting to different scenarios such as relational databases and non-relational databases, further enhancing the flexibility of the solution.

[0096] Optionally, in the business processing method based on database migration provided in the embodiments of this application, after detecting whether the database migration script has been executed successfully, the method further includes: if the database migration script fails to execute, prohibiting the startup of microservice business services and generating error logs.

[0097] Optionally, if all migration scripts execute successfully, the automatic migration component initialization is complete, and the microservice continues to start business services and provide services to the outside world; if a script fails to execute, the migration operation is stopped immediately according to the configured failure policy, and the microservice startup process is terminated, that is, the microservice's business services are prohibited from starting, and error logs are output to facilitate developers to troubleshoot problems.

[0098] Error logs can include the specific reason for script execution failure, the name of the failed script, its version number, and possible error codes or descriptions. Logs are recorded in the microservice's local log file and can also be sent to a centralized log server via the logging system for easier troubleshooting and repair.

[0099] It should be noted that by introducing the above-mentioned failure handling mechanism, the reliability of database migration can be further improved, thereby improving the reliability of business processing.

[0100] In an alternative embodiment, Figure 4 This is a schematic diagram of a business processing method based on database migration provided in an embodiment of this application. Figure 4 An optional application process of this embodiment will be described. For example... Figure 4 As shown, the target processing system can perform the following steps:

[0101] Step 1: When the microservice starts, it first loads the configuration parameters (database connection information, script path, etc.) of the automatic migration component in the configuration center.

[0102] Step 2: Initialize the automatic migration component and establish a connection with the database dedicated to this module.

[0103] Step 3: The automatic migration component queries the target data table (i.e., the metadata table) "xxx_schema_history" to obtain the latest version number for the current database. After the automatic migration component initializes, it immediately checks if a metadata table recording migration history exists in the database. If it doesn't exist, it creates the metadata table; if it exists, it reads all migration scripts from the migration script directory.

[0104] Step 4: Scan the migration scripts under the specified path of the microservice (i.e. the migration script directory) and sort the scripts according to the version number rule.

[0105] Step 5: Compare the script version number with the latest version number of the corresponding database to select the migration scripts that need to be executed (e.g., upgrade scripts, scripts that are repeatedly executed, etc.).

[0106] Step 6: Execute the selected migration scripts in order of version number. For each script that is successfully executed, write the script's version number, name, execution time, execution result, migration file checksum and other information into the "xxx_schema_history" table.

[0107] Step 7: If all migration scripts execute successfully, the automatic migration component initialization is complete, and the microservice continues to start business services and provide services to the outside world; if a script fails to execute, according to the configured failure policy, the migration operation is immediately stopped and rolled back, and the microservice startup process is terminated. At the same time, error logs are output to facilitate developers to troubleshoot problems.

[0108] It's important to note that this solution adheres to the "autonomy" principle of microservice architecture. Each microservice autonomously manages its own database migration, with migration scripts, version control, and execution processes decoupled from other modules. This avoids the coupling issues caused by all microservices sharing migration scripts in traditional solutions. Furthermore, cross-module data interaction is achieved through service calls, rather than direct access to other modules' databases, further reducing data coupling between modules. This allows each microservice to iterate and upgrade independently, improving the system's scalability and maintainability.

[0109] This solution automates database migration through an automatic migration component. Migration scripts are executed automatically upon microservice startup, eliminating the need for manual intervention by developers or operations personnel and reducing the risk of human error. Simultaneously, the migration scripts are managed alongside the microservice code (e.g., stored in the same data warehouse), improving code version consistency with the database version and avoiding version inconsistencies caused by the separation of code and scripts in traditional solutions. From an operations perspective, the database version and migration history of each microservice can be viewed in real-time through the target data table, facilitating monitoring of migration status and troubleshooting by operations personnel. For large-scale microservice clusters, the automatic migration component configurations for all modules can be centrally managed through a configuration center, supporting dynamic configuration updates without requiring individual module configuration modifications, significantly reducing operational costs. After adopting this solution, the development team's database migration-related work time can be reduced by approximately 60%, and the operations team's troubleshooting efficiency can be improved by approximately 50%.

[0110] In an optional embodiment, the database driver class name, database connection URL, username, and password can be configured in the database connection information to ensure that the microservice can correctly connect to the database. Simultaneously, to implement database migration functionality, an automatic migration component dependency can be introduced. For example, a specific dependency can be added to the project's configuration file. The automatic migration component functionality can be enabled through configuration, specifying the storage location of the migration scripts. When a table exists in the database but lacks metadata, a baseline migration is automatically performed, and the baseline version is set to 1.0.0.

[0111] In an optional embodiment, the hardware configuration required to run the microservice architecture and database can be reasonably selected based on the actual business volume and concurrent access conditions. The server's CPU can be a multi-core high-performance processor. When the business volume is small and the concurrent access is low, a processor with 4 cores and 8 threads can meet the basic requirements; while for scenarios with large business volume and frequent concurrent access, a processor with 16 cores and 32 threads or more can be used to improve the system's response speed and throughput.

[0112] In terms of memory, if the number of microservices is small and the amount of data is not large, 16GB of memory can ensure the stable operation of the system; however, when there are many microservices and a large amount of data storage and processing are involved, 32GB or even 64GB or more of memory will help improve system performance and avoid system lag and performance degradation caused by insufficient memory.

[0113] For storage, high-speed solid-state drives (SSDs) can be used to improve data read and write speeds. For applications with smaller data volumes, 256GB of SSD storage is generally sufficient; however, for enterprise-level applications with larger data volumes, 1TB or more SSDs can be configured to provide ample space for storing various types of data generated by microservices, while ensuring fast data read and write speeds and improving overall system performance. Furthermore, network bandwidth is also crucial. The network bandwidth should be determined based on actual business needs and user traffic to ensure smooth communication between microservices and between microservices and external clients.

[0114] Optionally, during project development, a series of dependency libraries can be introduced to meet the functional requirements of microservice architecture and database migration. For example, first, dependencies are introduced to build the microservice development framework. Next, to implement database migration functionality, dependencies related to the automatic migration component can be introduced, providing basic database migration functions, including version control and migration script execution. Simultaneously, to connect to the database, database driver dependencies can be introduced. This dependency provides the driver program for interacting with the database, ensuring that the microservices can correctly connect to the database and perform various database operations. Furthermore, other dependency libraries may be introduced depending on the specific needs of the project. By appropriately introducing these dependency libraries, rich functional support is provided for the development of the example project, ensuring the smooth implementation of microservice architecture and database migration functionality.

[0115] In an optional embodiment, the script type may further include an initial migration script type. The initial migration script is primarily used to create the database table structure and perform necessary data initialization operations, providing a foundation for subsequent business function implementation. Optionally, other migration scripts can be added in the same directory according to an agreed version order. These include database update scripts, rollback scripts, and repeatedly executed scripts. When the microservice starts, the automatic migration component initialization is triggered first. After the automatic migration component initialization is complete, it immediately queries the database to check if a metadata table recording migration history exists (e.g., the table name is xxx_schema_history).

[0116] If the metadata table does not exist in the database, the automatic migration component will create it based on the pre-configured baseline version and baseline description, and mark the current database state as the baseline version. This step ensures that the automatic migration component can accurately record the starting point of the database migration, providing a basis for subsequent migration operations.

[0117] After confirming the existence of the metadata table, the automatic migration component reads all migration scripts in the migration script directory. These migration scripts are arranged in ascending order of version number. The automatic migration component checks the version number of each migration script one by one and compares it with the latest version number recorded in the database. If the version number of a migration script is greater than the latest version number recorded in the database, it means that the script has not yet been applied to the database, and the automatic migration component will execute the script.

[0118] During the execution of the migration script, the automatic migration component monitors the execution status in real time. If any errors occur during execution, the automatic migration component will immediately stop the migration operation and log the error information. At the same time, the automatic migration component will attempt to roll back the executed migration script according to the pre-configured rollback strategy, restoring the database to its state before the migration.

[0119] Once all unapplied migration scripts have successfully completed execution, the automatic migration component records the migration results in the metadata table, including detailed information such as the migration version number, description, and execution time. This completes a full database migration process. During subsequent microservice startups, the automatic migration component repeats the above process, automatically detecting and applying new migration scripts based on the current database state and any updates to the migration scripts, thus enabling continuous database upgrades and management.

[0120] Therefore, the method provided in this application achieves the goal of migrating the database using a decentralized migration model for microservices, thereby improving the technical effect of business processing reliability. It solves the technical problem in related technologies where all microservices share a database, and all microservices need to be paused and restarted during database migration, resulting in low business processing reliability.

[0121] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0122] Example 2

[0123] This application also provides a business processing apparatus based on database migration. It should be noted that the business processing apparatus of this application can be used to execute the business processing method for database migration provided in this application. The business processing apparatus provided in this application is described below.

[0124] According to an embodiment of this application, an apparatus for implementing the above-described database migration-based business processing method is also provided, such as... Figure 5 As shown, the device includes:

[0125] The first detection module 501 is used to detect, for each microservice, whether there is a database migration script to be executed in the target storage area based on the database information of the database associated with the microservice when the microservice is started. Different microservices are associated with different databases.

[0126] The first processing module 502 is used to execute the database migration script for the database associated with the microservice when there is a database migration script to be executed.

[0127] The second processing module 503 is used to start the microservice's business service for business processing after all pending database migration scripts have been executed, or when there are no pending database migration scripts in the target storage area.

[0128] In this embodiment, multiple microservices in the target processing system are designed to be associated with different databases. When there are database migration scripts to be executed, the database migration scripts are executed on the databases associated with the microservices. When all database migration scripts to be executed have been completed, or when there are no database migration scripts to be executed in the target storage area, the business service is started directly. This achieves a decentralized migration model for database migration. The database migration operation of each microservice can be executed independently, and the database migration operations between microservices no longer affect each other. Other microservices that do not need to be migrated can be started quickly, thereby significantly reducing the downtime of microservices and improving the reliability of business processing.

[0129] Therefore, the method provided in this application achieves the goal of migrating the database using a decentralized migration model for microservices, thereby improving the technical effect of business processing reliability. It solves the technical problem in related technologies where all microservices share a database, and all microservices need to be paused and restarted during database migration, resulting in low business processing reliability.

[0130] Optionally, in the business processing apparatus provided in this application embodiment, the first detection module further includes: a first determination submodule, used to determine the version number of the historical database migration script of the database from the database information; and a detection submodule, used to detect whether there is a database migration script to be executed in the target storage area based on the version number of the historical database migration script.

[0131] Optionally, in the business processing apparatus provided in this application embodiment, the detection submodule further includes: a first determining unit, configured to determine the latest version number of the historical database migration script; a detection unit, configured to detect whether a target database migration script exists in the target storage area, wherein the version number of the target database migration script is greater than the latest version number; a second determining unit, configured to determine that if a target database migration script exists, the target database migration script is a database migration script to be executed in the target storage area; and a third determining unit, configured to determine that if a target database migration script does not exist, there is no database migration script to be executed in the target storage area.

[0132] Optionally, in the business processing apparatus provided in this application embodiment, the first processing module further includes: a judgment submodule, used to determine whether there are multiple database migration scripts to be executed; a second determination submodule, used to determine the execution order of multiple database migration scripts based on the version numbers of the multiple database migration scripts when there are multiple database migration scripts to be executed; and a processing submodule, used to execute the multiple database migration scripts on the database associated with the microservice in the execution order.

[0133] Optionally, in the business processing apparatus provided in the embodiments of this application, the business processing apparatus further includes: a first determining module, used to determine the dependency relationship between multiple microservices; and a second determining module, used to determine the startup order of multiple microservices according to the dependency relationship, or to determine the order in which multiple microservices execute database migration scripts according to the dependency relationship.

[0134] Optionally, in the business processing apparatus provided in this application embodiment, the business processing apparatus further includes: an acquisition module, used to acquire database information from the target data table of the database before detecting whether there is a database migration script to be executed in the target storage area based on the database information of the database associated with the microservice; a second detection module, used to detect whether the database migration script has been executed successfully after executing the database migration script on the database associated with the microservice; and a third processing module, used to record the script information of the database migration script into the database information in the target data table if the database migration script has been executed successfully.

[0135] Optionally, in the business processing apparatus provided in the embodiments of this application, the business processing apparatus further includes: a fourth processing module, used to prohibit the startup of microservice business services and generate error logs when the database migration script fails to execute.

[0136] It should be noted that the first detection module 501, the first processing module 502, and the second processing module 503 mentioned above correspond to steps S201 to S203 in Embodiment 1. The three modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0137] Example 3

[0138] Embodiments of this application may provide an electronic device. Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 6 As shown, the electronic device may include: one or more ( Figure 6 (Only one is shown) processor 1002, memory 1004, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0139] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0140] The processor can invoke information and applications stored in memory via a transmission device to execute the following steps: For each microservice, upon startup, based on the database information of the database associated with the microservice, detect whether there is a database migration script to be executed in the target storage area, where different microservices are associated with different databases; if there is a database migration script to be executed, execute the database migration script for the database associated with the microservice; if all database migration scripts to be executed have been completed, or if there is no database migration script to be executed in the target storage area, start the microservice's business service to perform business processing.

[0141] The processor can also invoke information and applications stored in memory via a transmission device to perform the following steps: determine the version number of the historical database migration script from the database information; and detect whether there is a database migration script to be executed in the target storage area based on the version number of the historical database migration script.

[0142] The processor can also invoke information and applications stored in the memory via the transmission device to perform the following steps: determine the latest version number of the historical database migration script; detect whether the target database migration script exists in the target storage area, wherein the version number of the target database migration script is greater than the latest version number; if the target database migration script exists, determine that the target database migration script is the database migration script to be executed in the target storage area; if the target database migration script does not exist, determine that there is no database migration script to be executed in the target storage area.

[0143] The processor can also invoke information and applications stored in memory via a transmission device to perform the following steps: determine whether there are multiple database migration scripts to be executed; if there are multiple database migration scripts to be executed, determine the execution order of the multiple database migration scripts based on their version numbers; and execute the multiple database migration scripts on the databases associated with the microservices in the execution order.

[0144] The processor can also invoke information and applications stored in memory via a transmission device to perform the following steps: determine the dependencies between multiple microservices; determine the startup order of multiple microservices based on the dependencies, or determine the order in which multiple microservices execute database migration scripts based on the dependencies.

[0145] The processor can also invoke information and applications stored in memory via a transmission device to perform the following steps: before detecting whether a database migration script to be executed exists in the target storage area based on the database information of the database associated with the microservice, obtain database information from the target data table of the database; after executing the database migration script on the database associated with the microservice, detect whether the database migration script was executed successfully; if the database migration script was executed successfully, record the script information of the database migration script into the database information in the target data table.

[0146] The processor can also access information and applications stored in memory via a transmission device to perform the following steps: after detecting whether the database migration script has been executed successfully, if the database migration script fails to execute, prevent the microservice's business services from starting and generate an error log.

[0147] In this embodiment, multiple microservices in the target processing system are designed to be associated with different databases. When there are database migration scripts to be executed, the database migration scripts are executed on the databases associated with the microservices. When all database migration scripts to be executed have been completed, or when there are no database migration scripts to be executed in the target storage area, the business service is started directly. This achieves a decentralized migration model for database migration. The database migration operation of each microservice can be executed independently, and the database migration operations between microservices no longer affect each other. Other microservices that do not need to be migrated can be started quickly, thereby significantly reducing the downtime of microservices and improving the reliability of business processing.

[0148] Therefore, the method provided in this application achieves the goal of migrating the database using a decentralized migration model for microservices, thereby improving the technical effect of business processing reliability. It solves the technical problem in related technologies where all microservices share a database, and all microservices need to be paused and restarted during database migration, resulting in low business processing reliability.

[0149] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 6This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0150] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0151] Example 4

[0152] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the database migration-based business processing method provided in Embodiment 1.

[0153] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0154] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing business processing method steps based on database migration.

[0155] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0156] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0157] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0158] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0159] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0160] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0161] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A business processing method based on database migration, characterized in that, Applied to a target processing system, which includes multiple microservices, the method includes: For each microservice, when the microservice is started, the system detects whether there is a database migration script to be executed in the target storage area based on the database information of the database associated with the microservice. Different microservices are associated with different databases. If a database migration script exists to be executed, execute the database migration script on the database associated with the microservice; Once all pending database migration scripts have been executed, or if no pending database migration scripts exist in the target storage area, the microservice's business service is started to perform business processing.

2. The method according to claim 1, characterized in that, Based on the database information of the database associated with the microservice, detect whether there is a database migration script to be executed in the target storage area, including: Determine the version number of the historical database migration script from the database information; Based on the version number of the historical database migration script, detect whether there is a database migration script to be executed in the target storage area.

3. The method according to claim 2, characterized in that, Based on the version number of the historical database migration script, detect whether there is a database migration script to be executed in the target storage area, including: Determine the latest version number of the historical database migration script; Detect whether a target database migration script exists in the target storage area, wherein the version number of the target database migration script is greater than the latest version number; If the target database migration script exists, then the target database migration script is determined to be the database migration script to be executed in the target storage area; If the target database migration script does not exist, it is determined that there is no database migration script to be executed in the target storage area.

4. The method according to claim 1, characterized in that, Execute the database migration script on the database associated with the microservice, including: Determine if there are multiple database migration scripts to be executed; In the case of multiple database migration scripts to be executed, the execution order of the multiple database migration scripts is determined based on their version numbers; The multiple database migration scripts are executed on the databases associated with the microservices in the order described.

5. The method according to claim 1, characterized in that, The method further includes: Determine the dependencies between the multiple microservices; The startup order of the multiple microservices is determined based on the dependencies, or the order in which the multiple microservices execute database migration scripts is determined based on the dependencies.

6. The method according to claim 1, characterized in that, Before detecting whether a database migration script to be executed exists in the target storage area based on the database information of the database associated with the microservice, the method further includes: Retrieve the database information from the target data table in the database; After executing the database migration script on the database associated with the microservice, the method further includes: Check whether the database migration script was executed successfully; If the database migration script is executed successfully, the script information of the database migration script is recorded in the database information of the target data table.

7. The method according to claim 6, characterized in that, After detecting whether the database migration script has been executed successfully, the method further includes: If the database migration script fails to execute, the business services of the microservice will be prevented from starting, and an error log will be generated.

8. A business processing device based on database migration, characterized in that, The device is applied to a target processing system, which includes multiple microservices, and comprises: The first detection module is used to detect, for each microservice, whether a database migration script to be executed exists in the target storage area based on the database information of the database associated with the microservice when the microservice is started, wherein different microservices are associated with different databases; The first processing module is used to execute the database migration script associated with the microservice when there is a database migration script to be executed. The second processing module is used to start the business service of the microservice to perform business processing after all the database migration scripts to be executed have been completed, or when there are no database migration scripts to be executed in the target storage area.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to perform the business processing method based on database migration as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program executes the database migration-based business processing method according to any one of claims 1 to 7 when it runs.

Images