A database access method and apparatus

Abstract

The application provides a database access method and device. The method comprises the following steps: determining a virtual IP address pre-solidified by a micro-service application; sending a connection request to the virtual IP address, so that a database connection agent on a database server side returns database metadata according to the connection request; receiving the database metadata; determining a target driver type according to a database category, loading a database driver corresponding to the target driver type, and creating a database connection pool by using the database driver according to database connection information. In the method, the micro-service application can receive the database metadata returned by the database connection agent, which comprises a database category and database connection information, by sending a connection request to the virtual IP, and dynamically constructs a database connection pool according to the database metadata. The process does not require the application to perceive information of a real database, shields differences of heterogeneous databases, realizes zero modification of configuration, and significantly reduces the workload of application deployment and operation and maintenance.

Description

Technical Field

[0001] This application relates to the field of distributed system technology, and in particular to a database access method and apparatus. Background Technology

[0002] As enterprises advance their IT infrastructure, traditional monolithic architectures are struggling to meet the demands of rapid business expansion and increasing complexity. As a result, more and more enterprises are adopting distributed microservice architectures to improve the scalability, flexibility, and maintainability of their systems.

[0003] However, in industries with high data security requirements, such as manufacturing, enterprises typically adopt private deployments. Due to differences in IT infrastructure among enterprises, especially in database selection, deploying the same microservice system at different customer sites requires extensive manual adaptation of database configurations. This process is not only inefficient but also prone to system malfunctions due to configuration errors, significantly increasing deployment costs and maintenance complexity.

[0004] Therefore, how to enable the same microservice system to run directly in different database environments without modifying the configuration has become a key issue that needs to be addressed in privately deployed microservice systems. Summary of the Invention

[0005] This application provides a database access method and apparatus to reduce the deployment workload of microservice systems in heterogeneous database environments.

[0006] Specifically, this application provides the following technical solution:

[0007] Firstly, this application provides a database access method, which is applied to a microservice application, and the method includes:

[0008] Determine the pre-defined virtual IP address for the microservice application;

[0009] A connection request is sent to the virtual IP address so that the database connection proxy on the database server side returns database metadata based on the connection request. The database connection proxy is bound to the virtual IP address by the virtual network support layer. The database metadata includes the database category and database connection information of the real database.

[0010] Receive the database metadata;

[0011] The target driver type is determined based on the database category, the database driver corresponding to the target driver type is loaded, and a database connection pool is created using the database driver based on the database connection information.

[0012] Secondly, this application provides a database access method, which is applied to a database connection proxy on the database server side. The database connection proxy is bound to a pre-fixed virtual IP address of a microservice application through a virtual network support layer. The method includes:

[0013] Listen for and receive connection requests sent by microservice applications to the virtual IP address;

[0014] The microservice application is returned database metadata according to the connection request, so that the microservice application can create a database connection pool based on the database metadata, wherein the database metadata includes the database category and database connection information of the real database.

[0015] The microservice application creates a database connection pool based on database metadata in the following way: determining the target driver type based on the database category, loading the database driver corresponding to the target driver type, and using the database driver to create a database connection pool based on the database connection information.

[0016] Thirdly, this application provides a database access device, which is applied to a microservice application, and the device includes:

[0017] The determination module is used to determine the pre-fixed virtual IP address of the microservice application;

[0018] The sending module is used to send a connection request to the virtual IP address so that the database connection proxy on the database server side returns database metadata according to the connection request, wherein the database connection proxy is bound to the virtual IP address by the virtual network support layer, and the database metadata includes the database category and database connection information of the real database.

[0019] A receiving module is used to receive the database metadata;

[0020] A module is created to determine the target driver type based on the database category, load the database driver corresponding to the target driver type, and create a database connection pool using the database driver based on the database connection information.

[0021] Fourthly, this application provides a database access device, which is applied to a database connection proxy on the database server side. The database connection proxy is bound to a virtual IP address pre-fixed by a microservice application through a virtual network support layer. The device includes:

[0022] The listening module is used to listen for and receive connection requests sent by microservice applications to the virtual IP address;

[0023] The return module is used to return database metadata to the microservice application according to the connection request, so that the microservice application can create a database connection pool based on the database metadata, wherein the database metadata includes the database category and database connection information of the real database;

[0024] The microservice application creates a database connection pool based on database metadata in the following way: determining the target driver type based on the database category, loading the database driver corresponding to the target driver type, and using the database driver to create a database connection pool based on the database connection information.

[0025] Fifthly, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described above.

[0026] Sixthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described above.

[0027] The technical solution provided in this application has the following beneficial effects:

[0028] The database connection proxy in this application provides a fixed access point through a virtual IP address, which remains unchanged in different deployment environments. Microservice applications send connection requests to the virtual IP address and receive database metadata, including database type and connection information, returned by the proxy. Based on this metadata, the application dynamically builds a database connection pool. This process eliminates the application's need to be aware of the actual database information, shielding it from the differences between heterogeneous databases, achieving zero configuration changes, and significantly reducing deployment workload.

[0029] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0030] The accompanying drawings, which are incorporated in and form part of this application, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0031] Figure 1 This is a first flowchart illustrating the database access method provided in Embodiment 1 of this application;

[0032] Figure 2 This is a second flowchart illustrating the database access method provided in Embodiment 1 of this application;

[0033] Figure 3 This is a schematic diagram of the components of the database access method provided in Embodiment 1 of this application;

[0034] Figure 4 A schematic diagram illustrating the workflow of the database access method provided in Embodiment 1 of this application;

[0035] Figure 5 This is a flowchart illustrating the database access method provided in Embodiment 2 of this application;

[0036] Figure 6 This is a schematic diagram of the database access device provided in Embodiment 3 of this application;

[0037] Figure 7 This is a schematic diagram of the database access device provided in Embodiment 4 of this application. Detailed Implementation

[0038] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the embodiments of this application is only used to describe specific embodiments of this application and is not intended to limit this application.

[0039] To address the compatibility issues of microservice systems across different database environments, relevant documentation provides a solution for integrating multi-source heterogeneous data. This solution extracts raw data through a data acquisition module, processes the raw data, and stores it in the deployment database, thereby integrating multi-source data into the same system.

[0040] However, in enterprise private deployment scenarios, this approach of data interaction through a data integration system presents numerous problems. On the one hand, this method requires excessive modification to the microservice system, altering the original system's data retrieval logic; on the other hand, building the business system while simultaneously investing significant manpower in developing the data integration system results in substantial resource consumption.

[0041] In real-world scenarios, enterprises often use a single type of database and tend to adapt to the current database rather than aggregate data through a data integration system.

[0042] To address the aforementioned issues, this application provides a database access method, apparatus, computer-readable storage medium, and computer program product. The aim is to enable private deployment of microservice applications and establish a connection between the microservice application and the database.

[0043] In this application, in any customer's private deployment environment (such as a local data center or a dedicated cloud environment), the microservice application only needs to pre-define a "virtual IP address" as the database access entry point. This application, through database connection proxy and virtual IP address technology, enables the microservice application to run directly in different database environments without configuration modifications, achieving "out-of-the-box" functionality. It supports mainstream databases such as MySQL, Oracle, PostgreSQL, and domestic databases, improving cross-environment compatibility, effectively reducing manual intervention, increasing deployment efficiency, and lowering deployment costs. In private deployment scenarios, the microservice application of this application only relies on the virtual IP address, requiring no configuration or code modifications for different databases, achieving "build once, run anywhere" and "zero-configuration awareness."

[0044] The practical application of this application will be described in detail below through specific embodiments. Example

[0045] In Embodiment 1, this application provides a database access method, which is applied to a microservice application, such as... Figure 1 As shown, the method includes the following steps:

[0046] Step 110: Determine the pre-defined virtual IP address for the microservice application;

[0047] The aforementioned virtual IP address is a fixed configuration for the microservice application and will serve as the sole target address for communication between the microservice application and the real database in the deployment environment. The virtual IP address remains unchanged when deployed at different customer sites, achieving zero configuration modifications.

[0048] For example, the virtual IP address mentioned above can be loaded through an application configuration file or stored in the application code.

[0049] In addition to virtual IP addresses, the fixed configuration of microservice applications can optionally include key pairs. These key pairs can be used to encrypt data transmitted between database proxy connections within the microservice application, ensuring the security of data transmission. They can also be used to verify the identity of the deployment environment, ensuring that the deployment environment has the necessary permissions to deploy the microservice application.

[0050] Step 120: Send a connection request to the virtual IP address so that the database connection proxy on the database server side returns database metadata based on the connection request;

[0051] Specifically, the database connection agent is deployed on the database server side. A virtual IP address is created in the deployment environment beforehand, and the virtual IP address is pointed to the database server where the database connection agent is located through a virtual network support layer, such as keepalived.

[0052] The database connection proxy can return database metadata to the microservice application. This metadata includes the database type and connection information of the actual database. Specifically, the database type can be MySQL, Oracle, PostgreSQL, or various domestic databases. The connection information can include authentication information (such as username and password) and location information (such as server address, port, and database name).

[0053] Regarding the process of obtaining database metadata through a database connection proxy, this embodiment provides the following two implementation methods:

[0054] Method 1: Upon initial startup, the proxy communicates with the real database to obtain and store database metadata for real-time maintenance. Subsequent connection requests are then returned to the microservice application with the locally maintained database metadata.

[0055] Method 2: Upon receiving a connection request, the proxy forwards the connection request to the real database according to preset routing rules, thereby obtaining the database metadata and returning it to the microservice application.

[0056] Step 130: Receive database metadata;

[0057] Step 140: Determine the target driver type based on the database category, load the database driver corresponding to the target driver type, and use the database driver to create a database connection pool based on the database connection information.

[0058] Step 140 constructs a database connection pool when the application starts, enabling the microservice application to connect to the real database. The microservice application remains unaware of the real database throughout the entire process. In other words, the microservice application does not need to concern itself with the specific details of the real database; it only needs to communicate through a unified virtual IP address.

[0059] After step 140, the microservice application can use the database connections in the database connection pool to perform database operations on the real database.

[0060] In this embodiment, the microservice application can dynamically load the corresponding database driver at runtime based on the database category returned by the database connection proxy. The database driver is implemented through a dynamic loading mechanism, such as class reflection in Java applications. When the microservice application detects a request to connect to a real database during runtime, it dynamically loads the database driver corresponding to the database category and instantiates the driver using reflection to establish a connection with the real database.

[0061] For example, this embodiment provides the following two methods for loading the database driver corresponding to the target driver type:

[0062] Method 1: Microservice applications do not need to prepare database drivers for various database types in advance for complex project environments. The database connection proxy will return the locally installed database drivers to the microservice application in the form of "accessible IP address + port" (i.e., driver download address). This method can avoid pre-loading various database drivers into the application package, reduce the application package size, and enhance the application's flexibility.

[0063] Specifically, in addition to database metadata, the data returned by the proxy also includes the driver download address. Accordingly, step 140 loads the database driver corresponding to the target driver type in the following way: based on the driver download address returned by the database connection proxy, the database driver corresponding to the target driver type is loaded.

[0064] Method 2: Instead of obtaining the database driver through a database connection proxy, pre-configure the system-supported database driver within the microservice application. Then, select and load the corresponding database driver based on the database type returned by the database connection proxy.

[0065] In this embodiment, the microservice application interacts with the real database through the ORM (Object-Relational Mapping) framework, automatically adapts to the SQL dialect used by the DAO layer (Data Access Object layer), and implements database CRUD functions.

[0066] For SQL statements not supported by the ORM framework, the microservice application selects the corresponding SQL statement from the preset custom SQL statements based on the database category returned by the proxy, thereby implementing database CRUD functions and achieving statement-level compatibility.

[0067] Through the above two-layer design, microservice applications can execute dialect statements of various databases, adapt to the actual database type of the customer's site and run business logic normally, thus enhancing the system's compatibility.

[0068] In other words, after constructing the database connection pool, this embodiment may further include an SQL adaptation process, the steps of which are as follows: Figure 2 As shown:

[0069] Step 210: Determine whether the dialect corresponding to the database category matches the dialect supported by the ORM framework; if the determination result is yes, proceed to step 320, otherwise proceed to step 330.

[0070] Step 220: Generate the first SQL statement using the ORM framework;

[0071] Step 230: Select the second SQL statement corresponding to the database category from the preset custom SQL statements.

[0072] As can be seen, the database access method in this embodiment achieves zero-configuration access to heterogeneous databases by deploying a database connection proxy on the database server side and binding it to a virtual IP address pre-fixed by the microservice application. This method completely decouples the microservice from the database environment, requiring no adjustments to the microservice application's configuration or code. It hides the deployment details of the database connection proxy through the virtual IP address, achieving "zero-configuration awareness." This not only improves the deployment efficiency of microservice applications but also significantly reduces deployment costs and operational complexity.

[0073] This embodiment is applied to the microservice application side and has the following main advantages:

[0074] (1) For microservice applications, only the virtual IP address of the database connection proxy needs to be configured as the sole entry point for database access, without the need for additional database connection information. Even if there are a large number of microservice applications, there is no need to modify the database configuration for each application, which greatly reduces the manpower cost of deployment.

[0075] (2) Microservice applications can dynamically load the corresponding database driver based on the database type returned by the agent. When the agent provides driver resources, the microservice application can download and load the corresponding database driver from the agent based on the driver download link provided by the agent, without having to prepare various database drivers in the application package.

[0076] (3) Microservice applications can create database connection pools using the database connection information provided by the agent, rather than relying on pre-compiled configurations, thus having stronger adaptability.

[0077] (4) Microservice applications do not need to be aware of the detailed information of the real database, nor do they persist any database authentication information. That is, the database connection proxy is decoupled from the microservice application, ensuring the security of sensitive information related to the real database without intruding on the business code.

[0078] (5) Microservice applications can adapt their code based on the database type returned by the database connection agent. For SQL statements that are not supported by the ORM framework, microservice applications can choose custom SQL statements corresponding to the database type to achieve statement-level compatibility.

[0079] Through the above methods, this embodiment provides an efficient, flexible, and secure heterogeneous database access solution for microservice applications.

[0080] The following is combined Figure 3 and Figure 4 The database access method of this embodiment will be further explained.

[0081] The database access method in this embodiment aims to achieve seamless connection between microservice applications and heterogeneous databases without requiring configuration modifications for different database environments. This embodiment achieves zero-configuration deployment by deploying a database connection proxy on the database server side and configuring a unified virtual IP address on the microservice application.

[0082] like Figure 3 As shown, the core components include:

[0083] Microservice applications communicate with database connection proxies via a unified virtual IP address. The application has a built-in dynamic data source builder and SQL adaptation layer, which includes an ORM framework and custom SQL statements.

[0084] Virtual network support layer: responsible for binding virtual IP addresses to database connection proxies, ensuring that the IP address remains unchanged in different deployment environments.

[0085] Database connection proxy: Deployed on the database server side, it is responsible for receiving requests sent to the virtual IP and forwarding the requests to the real database according to internal routing rules.

[0086] like Figure 4 As shown, the workflow is as follows:

[0087] Step 1: Configure a unified and fixed virtual IP address for the microservice application and send a connection request to the virtual IP address;

[0088] Step 2: The database connection proxy receives the connection request and forwards it to the real database according to the preset routing rules;

[0089] Step 3: The database executes the connection request forwarded by the proxy and returns database metadata;

[0090] Step 4: The database connection proxy receives the database metadata and sends the database metadata and driver download address to the microservice application via the virtual IP address. The database connection proxy has multiple pre-installed database drivers, such as MySQL driver, Oracle driver and domestic driver, and returns the database driver to the microservice application in the form of "IP address + port".

[0091] Step 5: In microservice applications, the dynamic data source builder constructs a database connection pool based on database metadata (including database port, account password, etc.) and driver download address.

[0092] This design allows microservice applications to interact only with virtual IP addresses throughout the process, without needing to know the specific type of the real database or connection information. This greatly simplifies the deployment and maintenance of microservice applications and improves the flexibility and scalability of distributed systems. Example

[0093] In Embodiment 2, this application provides a database access method. The method is applied to a database connection proxy on the database server side. The database connection proxy is bound to a virtual IP address pre-fixed by the microservice application through a virtual network support layer.

[0094] like Figure 5 As shown, the method includes:

[0095] Step 510: Listen for and receive connection requests sent by the microservice application to the virtual IP address;

[0096] Step 520: Return database metadata to the microservice application according to the connection request, so that the microservice application can create a database connection pool based on the database metadata, wherein the database metadata includes the database category and database connection information of the real database;

[0097] The microservice application creates a database connection pool based on database metadata in the following way: determining the target driver type based on the database category, loading the database driver corresponding to the target driver type, and using the database driver to create a database connection pool based on the database connection information.

[0098] For example, the database connection proxy returns database metadata to the microservice application in the following way: it forwards the connection request to the real database according to a preset routing rule, obtains the database metadata, and returns it to the microservice application.

[0099] Furthermore, the database connection agent supports dynamic switching between primary and standby database modes, providing database disaster recovery capabilities. This ensures that microservice applications can seamlessly switch to the standby database in the event of a primary database failure, improving system availability and disaster recovery capabilities.

[0100] Furthermore, the database connection agent can dynamically adjust connection pool parameters based on the actual database load. By intelligently adjusting the connection pool size and timeout settings, the performance of database operations can be improved.

[0101] The database access method in this embodiment, when applied to the proxy side, has at least the following advantages:

[0102] (1) The agent feeds back database metadata, including database type and database connection information, to the microservice application for use by the application side. Therefore, the microservice application does not need to be aware of the existence of the real database, which simplifies the configuration and maintenance work.

[0103] (2) The database connection agent can store sensitive database information such as database account passwords and transmit this information to microservice applications through an encrypted channel to ensure the security of database authentication information and prevent the leakage of sensitive information.

[0104] (3) The proxy dynamically forwards the connection requests of the microservice application to the real database according to the preset routing rules. Even if the database side changes, only the preset routing rules of the database connection proxy need to be modified, without modifying the configuration on the microservice application side.

[0105] (4) The database connection agent supports dynamic switching between primary and backup database modes, thereby providing strong disaster recovery capabilities and ensuring that the system can still operate normally when the database fails.

[0106] In summary, the database access method of this embodiment achieves zero-configuration access to heterogeneous databases through proxy technology and virtual IP addresses. It also performs well in terms of security, disaster recovery capabilities, and deployment efficiency, making it particularly suitable for microservice architecture environments that require rapid deployment and efficient operation and maintenance. Example

[0107] This embodiment provides a database access device, which is applied to microservice applications, such as... Figure 6 As shown, the device includes:

[0108] Module 610 is used to determine the pre-fixed virtual IP address of the microservice application;

[0109] The sending module 620 is used to send a connection request to the virtual IP address so that the database connection proxy on the database server side returns database metadata according to the connection request, wherein the database connection proxy is bound to the virtual IP address by the virtual network support layer, and the database metadata includes the database category and database connection information of the real database.

[0110] Receiving module 630 is used to receive the database metadata;

[0111] A creation module 640 is used to determine the target driver type based on the database category, load the database driver corresponding to the target driver type, and use the database driver to create a database connection pool based on the database connection information.

[0112] For example, the sending module 620 is specifically used for:

[0113] A connection request is sent to the virtual IP address so that the database connection proxy on the database server side forwards the connection request to the real database according to the preset routing rules, obtains the database metadata, and returns it to the microservice application.

[0114] For example, the sending module 620 is specifically used for:

[0115] A connection request is sent to the virtual IP address so that the database connection proxy on the database server side returns the locally maintained database metadata to the microservice application based on the connection request.

[0116] For example, the sending module 620 is specifically used for:

[0117] A connection request is sent to the virtual IP address, causing the database connection proxy on the database server side to return database metadata and a driver download address based on the connection request. Accordingly, the creation module 640 loads the database driver corresponding to the target driver type in the following manner: based on the driver download address, it loads the database driver corresponding to the target driver type.

[0118] For example, the creation module 640 loads the database driver corresponding to the target driver type in the following manner:

[0119] Load the database driver corresponding to the target driver type from the database drivers pre-built in the microservice application.

[0120] For example, the apparatus further includes an SQL adaptation module for:

[0121] Determine whether the dialect corresponding to the database category matches the dialects supported by the ORM framework; if the determination result is yes, generate a first SQL statement using the ORM framework; if the determination result is no, select a second SQL statement corresponding to the database category from the preset custom SQL statements. Example

[0122] This embodiment provides a database access device. The device is applied to a database connection proxy on the database server side. The database connection proxy is bound to a virtual IP address pre-fixed by the microservice application through a virtual network support layer.

[0123] like Figure 7 As shown, the device includes:

[0124] The listening module 710 is used to listen for and receive connection requests sent by the microservice application to the virtual IP address;

[0125] Return module 720 is used to return database metadata to the microservice application according to the connection request, so that the microservice application can create a database connection pool according to the database metadata, wherein the database metadata includes the database category and database connection information of the real database;

[0126] The microservice application creates a database connection pool based on database metadata in the following way: determining the target driver type based on the database category, loading the database driver corresponding to the target driver type, and using the database driver to create a database connection pool based on the database connection information.

[0127] For example, the return module 720 returns database metadata to the microservice application in the following ways:

[0128] The connection request is forwarded to the real database according to the preset routing rules, the database metadata is obtained and returned to the microservice application.

[0129] This application also provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the various functions or steps of the above method embodiments.

[0130] The aforementioned computer-readable storage media include, but are not limited to, any of the following: USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and other media capable of storing program code.

[0131] This application also provides a computer program product that, when run on a computer, causes the computer to perform various functions or steps of the above method embodiments.

[0132] The computer-readable storage medium and computer program product provided in the embodiments of this application are used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0133] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various variations or substitutions can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A database access method, characterized by, The method is applied to a micro-service application, and the method comprises: determining a virtual IP address pre-solidified by the micro-service application; sending a connection request to the virtual IP address, so that a database connection agent on a database server side returns database metadata according to the connection request, wherein the database connection agent is bound to the virtual IP address by a virtual network support layer, and the database metadata comprises a database category and database connection information of a real database; receiving the database metadata; determining a target driver type according to the database category, loading a database driver corresponding to the target driver type, and creating a database connection pool according to the database connection information by using the database driver.

2. The method of claim 1, wherein, The method comprises: sending a connection request to the virtual IP address, so that a database connection agent on a database server side forwards the connection request to a real database according to a preset routing rule, obtains database metadata, and returns the database metadata to the micro-service application.

3. The method of claim 1, wherein, The method comprises: sending a connection request to the virtual IP address, so that a database connection agent on a database server side returns locally maintained database metadata to the micro-service application according to the connection request.

4. The method of claim 1, wherein, The method comprises: sending a connection request to the virtual IP address, so that a database connection agent on a database server side returns database metadata and a driver download address to the micro-service application according to the connection request. The method specifically loads the database driver corresponding to the target driver type in the following manner: loading the database driver corresponding to the target driver type according to the driver download address.

5. The method of claim 1, wherein, The method specifically loads the database driver corresponding to the target driver type in the following manner: loading the database driver corresponding to the target driver type from database drivers pre-stored by the micro-service application.

6. The method of claim 1, wherein, The method further comprises: judging whether a dialect corresponding to the database category matches a dialect supported by an ORM framework; if the judgment result is yes, generating a first SQL statement by using the ORM framework; if the judgment result is no, selecting a second SQL statement corresponding to the database category from preset custom SQL statements.

7. A database access method, characterized by, The method is applied to a database connection agent on a database server side, and the database connection agent is bound to a virtual IP address pre-solidified by a micro-service application by a virtual network support layer, and the method comprises: listening to and receiving a connection request sent by the micro-service application to the virtual IP address; returning database metadata to the micro-service application according to the connection request, so that the micro-service application creates a database connection pool according to the database metadata, wherein the database metadata comprises a database category and database connection information of a real database; The micro-service application specifically creates the database connection pool according to the database metadata in the following manner: determining a target driver type according to the database category, loading a database driver corresponding to the target driver type, and creating a database connection pool according to the database connection information by using the database driver.

8. The method of claim 7, wherein, The method specifically returns the database metadata to the micro-service application in the following manner: Forward the connection request to a real database according to a preset routing rule, obtain database metadata, and return to the micro-service application.

9. A database access device, characterized by The device is applied to a micro-service application, and the device comprises: A determination module is configured to determine a virtual IP address pre-solidified by the micro-service application. A sending module is configured to send a connection request to the virtual IP address, so that a database connection agent on a database server side returns database metadata according to the connection request, wherein the database connection agent is bound to the virtual IP address by a virtual network support layer, and the database metadata comprises a database category and database connection information of a real database. A receiving module is configured to receive the database metadata. A creation module is configured to determine a target driver type according to the database category, load a database driver corresponding to the target driver type, and create a database connection pool by using the database driver according to the database connection information.

10. A database access device, characterized by The device is applied to a database connection agent on a database server side, and the database connection agent is bound to a virtual IP address pre-solidified by a micro-service application through a virtual network support layer, and the device comprises: A listening module is configured to listen to and receive a connection request sent by the micro-service application to the virtual IP address. A returning module is configured to return database metadata to the micro-service application according to the connection request, so that the micro-service application creates a database connection pool according to the database metadata, wherein the database metadata comprises a database category and database connection information of a real database. The micro-service application specifically creates the database connection pool according to the database metadata in the following manner: determining a target driver type according to the database category, loading a database driver corresponding to the target driver type, and creating a database connection pool by using the database driver according to the database connection information.

11. A computer-readable storage medium comprising computer instructions, wherein, When the computer instructions run on the electronic device, the electronic device is caused to perform the method in any one of claims 1-8.

12. A computer program product, characterised in that, When the computer program product runs on the computer, the computer is caused to perform the method in any one of claims 1-8.

Images