WO2024001679A1 - Data publishing method and system - Google Patents

Abstract

The present application relates to the technical field of communications. Disclosed are a data publishing method and system. One-key full-amount data export and one-key data publishing can be performed by means of just one configuration, thereby reducing manual operations in a data publishing process. The method comprises: a terminal device initiating a data export instruction to a configuration environment server; in response to the data export instruction and according to a preset target configuration file, the configuration environment server determining a target export actuator and a target data set, which correspond to a target micro-service; using the target export actuator to export data indicated by the target data set from the configuration environment server to a code management server, wherein the data indicated by the target data set is part of data in configuration data corresponding to the target micro-service; storing the data indicated by the target data set in a first warehouse corresponding to the configuration data of the target micro-service; and packaging, into a service data packet, all configuration data in the first warehouse that is indicated by the target data set, and publishing the service data packet into at least one target environment server.

Description

Data publishing method and system

This application claims priority to the Chinese patent application submitted to the State Intellectual Property Office on June 29, 2022, with application number 202210749103.2 and the application name "Data Publishing Method and System", the entire content of which is incorporated into this application by reference.

Technical field

This application relates to the field of communication technology, and in particular to a data publishing method and system.

Background technique

Usually microservice projects have requirements for configuration data release, such as publishing the same business data in multiple configuration environments. Currently, conventional technology generally uses database script management to release configuration data, for example, using database version control tools such as Flyway or Liquibase. These tools are all run based on the command line or Maven Project Object Model (POM), and are essentially based on migrating data to change the database, such as migrating data based on Structured Query Language (SQL) to change different configuration environments. database. However, when updating configuration data in different configuration environments based on SQL migration data, manual editing of database scripts is required, making the configuration data publishing process heavy and cumbersome.

Contents of the invention

The embodiments of this application provide a data publishing method and system. The user only needs to configure the configuration file once, and then can export the configuration data in full to the code management system with one click, and then publish the data to multiple target environments with one click. , reducing manual operations in the data publishing process. Furthermore, for imported business data packages, preset callback operations can be intelligently processed and executed in the target environment, such as clearing caches, rebuilding indexes, pushing data to the integration platform, returning emails to publish result reports, and other callback operations without the need for manual labor. Intervention avoids a lot of duplication of work, greatly shortens the project launch cycle, and reduces subsequent operation and maintenance costs.

In a first aspect, this application provides a data publishing method. The method includes: a terminal device initiates a data export instruction to a configuration environment server, and the data export instruction is associated with the target microservice; the configuration environment server responds to the The data export instruction determines the target export executor and target data set corresponding to the target microservice according to the preset target configuration file, wherein the target configuration file is used to define the target microservice and the target data set. and the corresponding relationship between the target export executors; the configuration environment server uses the target export executor to export the data indicated by the target data set from the configuration environment server to the code management server; the target The data indicated by the data set is part of the data in the configuration data corresponding to the target microservice; the code management server saves the data indicated by the target data set to the first warehouse corresponding to the target microservice; The first warehouse is a warehouse in the code management server used to store the configuration data of the target microservice, and the first warehouse is the same as the warehouse used in the code management server to store application data of the target microservice. different;

The code management server packages all the configuration data in the first warehouse indicated by the target data set into a business data package, and publishes the business data package to at least one target environment server, wherein the business data package The data package includes all configuration data of the target microservice, excluding application data of the target microservice. It is understandable that once the user configures the configuration file, he or she can then export the configuration data in full with one click and publish the data with one click. according to. The target data set may include one or more data sets, and the corresponding target export executor may include multiple sub-export executors. Specifically, the target export executor can be used to crawl the data indicated by the target data set.

In a possible implementation of the above first aspect, the target data set is also used to define a preset change type; the method further includes: when the change type of data indicated by the target data set meets the preset change type; In the case of a change type, the at least one target environment server imports the data indicated by the target data set. In this way, when the data is imported into the target environment, it can be determined whether the change type of the data to be imported matches the preset change type. If it matches, the data import will be performed. Otherwise, the data import will not be allowed, ensuring the accuracy of the data import. .

In a possible implementation manner of the above first aspect, the above method further includes: the configuration environment server parses the name of the target microservice from the data export instruction; the configuration environment server determines the name of the target microservice according to the target The name of the microservice, and the target export executor corresponding to the target data set is found from the target configuration file corresponding to the target microservice.

In a possible implementation of the first aspect, the target data set includes multiple sub-data sets, the target export executor includes multiple sub-export executors, and one of the sub-data sets corresponds to one sub-export execution. and the source data in a part of the multiple sub-data sets is the source data of the target microservice, and the source data in another part of the sub-data set is the source data of a microservice different from the target microservice. . That is to say, this application supports the release of data other than this service, which improves the convenience of data release.

It should be noted that the above target data set indicates multiple data sets defined in the target configuration file below. That is, the plurality of sub-datasets in the above target data set are equivalent to the plurality of data sets indicated by the target configuration file below.

In a possible implementation of the above first aspect, the data type of the source data in the plurality of sub-data sets includes at least one of database scripts, pictures, portable document formats, tables, and documents. That is to say, this application supports multi-source data release, which improves the convenience of data release.

In a possible implementation of the above first aspect, the above method further includes: a first target environment server parsing out the target data set in the data packet, the first target environment server being the at least one Any one of the target environment servers; the first target environment server uses a target import executor to import the target data set into the first target environment server according to the target configuration table corresponding to the target microservice; The target configuration table is used to define the corresponding relationship between the target microservice, the target data set, and the target import executor. It can be understood that servers corresponding to other environments in at least one target environment server can also specify similar operations. Refer to the relevant description of the first target environment server.

In a possible implementation of the first aspect, the method further includes: the first target environment server executing a target callback operation corresponding to the target data set; wherein the target configuration table is also used to define Correspondence between the target data set and target callback information, the target data set includes multiple sub-data sets, the target callback information includes multiple sub-callback information, and one sub-callback operation corresponds to one sub-data set. That is, the target environment server can intelligently process and execute preset callback operations, such as clearing the cache, rebuilding the index, pushing data to the integration platform, returning and publishing result reports by email, and other callback operations without manual intervention, avoiding a lot of duplication. work, greatly shortening the project launch cycle and reducing subsequent operation and maintenance costs.

In a possible implementation of the first aspect, the method further includes: the terminal device initiating a data release instruction to the code management server, and the data release instruction is associated with the target microservice; wherein, The business data package is released by the code management server to the at least one target environment server with one click in response to the data release instruction.

In a possible implementation of the first aspect, the method further includes: the server corresponding to the code management system records release information corresponding to the configuration information of the target microservice; wherein the release information includes the following At least one item: the name of the target microservice, the name release time of the business data package, release status information, and the change type of the target data set indication data in the business data package; and, in the release information The comparison result between the change type of the indicated data contained in the target data set and the preset change type predefined in the target data set is used as the judgment result for judging the correctness of the business data package. It can be understood that if the change type of the data indicated by the target data set in the release information is the same as the preset change type defined by the target data set, it means that the business data package is accurate; otherwise, it means that the business data package is inaccurate. In this way, in the embodiment of the present application, when the user queries the release information of the business data package, he can intuitively see the business change type before the data indicated by each data set in the business data package is exported and released, and then can verify the data indicated by each data set. Whether the data is exported and released under the preset business change type is used to determine the accuracy of the business data package and thereby verify the accuracy of the data export and release.

In a possible implementation of the above first aspect, the above change type is new data, changed data or deleted data.

In a possible implementation of the first aspect, the method further includes: the terminal device receiving a publishing query request corresponding to the service data packet; and the terminal device initiating a query request to a server corresponding to the code management system. A release query request corresponding to the business data package; the service corresponding to the code management system returns the release information to the terminal device; the terminal device displays the release information, release button, and rollback button through the query interface and publish log button; wherein, the publish button is used to trigger the re-publishing of the business data package to the at least one target environment server, and the rollback button is used to trigger the re-publishing of the service data package in the at least one target environment server. The service data performs a rollback operation, and the release log button is used to trigger the terminal device to display historical release information of the service data package.

In a possible implementation manner of the above first aspect, the above target microservice is applied to Internet financial products or Internet insurance products.

In a second aspect, this application provides a data publisher system. The system includes: the system includes a terminal device, a configuration environment server, a code management server, and at least one target environment server; the terminal device is used to provide configuration information to the configuration server. The environment server initiates a data export instruction, and the data export instruction is associated with the target microservice; the configuration environment server is used to respond to the data export instruction and determine the data corresponding to the target microservice according to the preset target configuration file. The target export executor and the target data set, wherein the target configuration file is used to define the correspondence between the target microservice, the target data set and the target export executor; the configuration environment server uses the The target export executor exports the data indicated by the target data set from the configuration environment server to the code management server; the data indicated by the target data set is part of the data in the configuration data corresponding to the target microservice. ; The code management server is also used to save the data indicated by the target data set to the first warehouse corresponding to the target microservice; the first warehouse is used in the code management server to store all A warehouse for the configuration data of the target microservice, and the first warehouse is different from the warehouse used to store the application data of the target microservice in the code management server; the code management server is also used to store the target data Pack all the configuration data in the first warehouse indicated by the set into a business data package, and publish the business data package to at least one target environment server, where the business data package includes the target microservice All configuration data, excluding the application data of the target microservice.

In a possible implementation of the second aspect above, the target data set is also used to define a preset change type, When the change type of the data indicated by the target data set matches the preset change type, it is exported to the code management server.

In a possible implementation of the second aspect, the system further includes: the configuration environment server parses the name of the target microservice from the data export instruction; the configuration environment server performs the following tasks according to the target: The name of the microservice, and the target export executor corresponding to the target data set is found from the target configuration file corresponding to the target microservice.

In a possible implementation of the second aspect, the target data set includes multiple sub-data sets, the target export executor includes multiple sub-export executors, and one of the sub-data sets corresponds to one sub-export execution. and the source data in a part of the multiple sub-data sets is the source data of the target microservice, and the source data in another part of the sub-data set is the source data of a microservice different from the target microservice. .

It should be noted that the above target data set indicates multiple data sets defined in the target configuration file below. That is, the plurality of sub-datasets in the above target data set are equivalent to the plurality of data sets indicated by the target configuration file below.

In a possible implementation of the above second aspect, the data type of the source data in the plurality of sub-data sets includes: at least one of database scripts, pictures, portable document formats, tables, and documents.

In a possible implementation of the second aspect, the system further includes: a first target environment server parsing out the target data set in the data packet, and the first target environment server is the at least one Any one of the target environment servers; the first target environment server uses a target import executor to import the target data set into the first target environment server according to the target configuration table corresponding to the target microservice; The target configuration table is used to define the corresponding relationship between the target microservice, the target data set, and the target import executor.

In a possible implementation of the above second aspect, the above system further includes: the first target environment server performs a target callback operation corresponding to the target data set; wherein the target configuration table is also used to define Correspondence between the target data set and target callback information, the target data set includes multiple sub-data sets, the target callback information includes multiple sub-callback information, and one sub-callback operation corresponds to one sub-data set.

In a possible implementation of the second aspect, the system further includes: the terminal device initiating a data release instruction to the code management server, and the data release instruction is associated with the target microservice; wherein, The business data package is released by the code management server to the at least one target environment server with one click in response to the data release instruction.

In a possible implementation of the above second aspect, the above system further includes: the server corresponding to the code management system records release information corresponding to the configuration information of the target microservice; wherein the release information includes the following At least one item: the name of the target microservice, the name release time of the business data package, release status information, and the change type of the target data set indication data in the business data package; and, in the release information The comparison result between the change type of the indicated data contained in the target data set and the preset change type predefined in the target data set is used as the judgment result for judging the correctness of the business data package.

In a possible implementation of the above second aspect, the above change type is new data, changed data or deleted data.

In a possible implementation of the second aspect, the system further includes: the terminal device receiving a publishing query request corresponding to the service data packet; and the terminal device initiating a query request to the server corresponding to the code management system. Publish query request corresponding to the service data package; the service corresponding to the code management system returns to the terminal device Return the release information; the terminal device displays the release information, release button, rollback button and release log button through the query interface; wherein the release button is used to trigger re-release of the business data packet to the In at least one target environment server, the rollback button is used to trigger a rollback operation on the business data in the at least one target environment server, and the publish log button is used to trigger the terminal device to display the business data package. historical release information.

In a possible implementation manner of the above second aspect, the above target microservice is applied to Internet financial products or Internet insurance products.

In a third aspect, embodiments of the present application provide a computer-readable storage medium. Instructions are stored on the computer-readable storage medium. When executed on a terminal device, the instructions cause the electronic device to perform data publishing as in the first aspect. method.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium. Instructions are stored on the computer-readable storage medium. When the instructions are executed on a server, they cause the server to perform the data publishing method in the first aspect.

In a fifth aspect, embodiments of the present application provide a terminal device, including: a memory for storing instructions executed by one or more processors of the electronic device, and a processor, when the instructions are processed by one or more When the processor is executed, the processor is configured to execute the data publishing method executed by the terminal device described in the first aspect.

In a sixth aspect, embodiments of the present application provide a server, including: a memory for storing instructions executed by one or more processors of an electronic device, and a processor, when the instructions are executed by one or more processors, When executing, the processor is configured to execute the data publishing method executed by the code management server or the server in the at least one target environment server in the first aspect.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or description of the prior art will be briefly introduced below. Obviously, the drawings in the following description are only for the purpose of the present application. For some embodiments, for those of ordinary skill in the art, other drawings can be obtained based on these drawings without exerting creative efforts.

Figure 1 shows a schematic diagram of a configuration data publishing process according to some embodiments of the present application;

Figure 2 shows a schematic diagram of a configuration data release scenario according to some embodiments of the present application;

Figure 3 shows a code schematic diagram of business data according to some embodiments of the present application;

Figure 4 shows a code schematic diagram of business data according to some embodiments of the present application;

Figure 5 shows a schematic diagram of a display method of business data according to some embodiments of the present application;

Figure 6 shows a schematic flow chart of a data publishing method according to some embodiments of the present application;

Figure 7 shows a schematic diagram of the hardware structure of a terminal device according to some embodiments of the present application.

Detailed ways

Illustrative embodiments of the present application include, but are not limited to, a data publishing method and system.

In order to make the purpose, technical solutions and advantages of the present application more clear, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described here are only used to explain the present application and are not used to limit the present application.

The data publishing method provided by the embodiment of this application is mainly used for the maintenance and management of business data of microservices. Specifically, this application can store the application data and business data of microservices in different warehouses in the code management system to achieve separation of microservice applications and data. On this basis, refer to the configuration data release process shown in Figure 1: For configuration Configuration data such as business data in the environment; export (or submit) the configuration data to the warehouse corresponding to the configuration data of the relevant microservices in the code management system according to the preset configuration file; transfer all configuration data in the current warehouse The business data package is packaged; at the user's request, the business data package is published (or imported) to multiple target environments with one click, for example, imported into the database, file management system and other containers of the target environment shown in Figure 1 . In this way, users only need to configure the configuration file once, and then can export the configuration data in full to the code management system with one click, and then publish the data to multiple target environments with one click, reducing manual operations in the data release process. Furthermore, for imported business data packages, preset callback operations can be intelligently processed and executed in the target environment, such as clearing caches, rebuilding indexes, pushing data to the integration platform, returning emails to publish result reports, and other callback operations without the need for manual labor. Intervention avoids a lot of duplication of work, greatly shortens the project launch cycle, and reduces subsequent operation and maintenance costs. In addition, due to the separation of microservice applications and data, the data set in the configuration data is not limited to database scripts, but can also be pictures, Portable Document Format (PDF), excel (i.e. table), doc (document) and other types of multi-source data, which greatly improves the convenience of data release.

In some embodiments provided in this application, microservice applications (or microservice projects) are applications built based on spring boot, run under the Spring Cloud architecture, and are provided externally through the Hyper Text Transfer Protocol (HTTP) Serve.

In some embodiments of this application, the microservice environment involved includes a research and development environment, a test environment, an integration environment, and a production environment. In some embodiments, the R&D environment, test environment, and integration environment are used to lay the foundation for a safe and stable production environment. Therefore, configuration data such as business data in the three environments of R&D environment, test environment, and integration environment need to be consistent with the production environment. Based on this, the embodiment of the present application publishes configuration data among the R&D environment, test environment, integration environment and production environment, so that the configuration data remains consistent throughout the system. In the following embodiments, the data release method provided by this application is mainly explained by taking the release of configuration data involved between the R&D environment, the test environment, and the integration environment as an example.

Refer to Figure 2, which is a schematic diagram of a configuration data release scenario provided by an embodiment of the present application. The scenario shown in Figure 2 includes a data release management system 10, a code management system 20, a research and development environment 30, a test environment 40 and an integration environment 50.

As an example, the data release management system 10 is used to trigger the export or submission of configuration data such as business data in the R&D environment 30 to the code management system 20, and trigger the packaging of the configuration data in the code management system 20 into business data packages and Publish to the test environment 40 and integration environment 50, and view the data release status, etc.

In some embodiments, the above-mentioned data release management system 10 can be implemented through software, and provides a user interaction interface to support functions such as user triggering of data release and subsequent query of data release status. As an example, the above-mentioned data release management system 10 can be provided in a terminal device 100, and the terminal device 100 is a device with a display screen. For example, the terminal device 100 applicable to the present application may be a desktop computer, a portable computer, a palmtop computer, a mobile phone, a tablet computer, etc., which are not limited in the embodiments of the present application.

In the embodiment of this application, the code management system 20 is used to store application data and configuration data (such as business data) of microservices in different warehouses, and package the configuration data into compressed files such as business data packages. As an example, the above-mentioned code management system 20 may be a distributed version control system (Git) or a version control system (Subversion, SVN), etc. In some embodiments of the present application, the code management system 20 can be implemented through gitlab. Among them, gitlab is an online code warehouse software based on git. It is generally used to build git private servers in internal networks of enterprises, schools, etc. It can be regarded as a simple github. Correspondingly, the warehouse instructions in the code management system 20 involved in this application is the gitlab repository.

In some embodiments, the code management system 20 may be installed in a server 200, and the server 200 (also referred to as a code management server) may be an independent server or a cloud server. Among them, the independent server owns all the software and hardware resources of the entire server, and can allocate and implement a variety of network function services on its own. For example, it can independently store the application data and configuration data of microservices. In addition, the cloud server may be a hardware server or may be embedded in a virtualized environment. For example, according to some embodiments of the present application, the cloud server may be a virtual machine executed on a hardware server including one or more other virtual machines.

The above-mentioned test environment 40 and integration environment 50 are used to parse the business data packages imported from the code management system 20 and automatically execute preset callback operations. As an example, the research and development environment 30, the test environment 40 and the integration environment 50 can be applied to the server 300, the server 400 and the server 500 respectively. In addition, each of the R&D environment 30 , the test environment 40 and the integration environment 50 may also include terminal devices that interact with servers and other devices used to complete microservice-related tasks such as R&D, testing and integration, which will not be described in detail here. .

In some embodiments, each of the above-mentioned servers 300, 400 and 500 may be an independent server or a cloud server. Refer to the relevant description of the server 200 above, which will not be described again here.

It can be understood that in the embodiment of the present application, in the data publishing scenario shown in Figure 2, the data publishing method can be implemented through interaction between the terminal device 100, the server 200, the server 300, the server 400 and the server 500. That is, the terminal device 100 interacts with the server to implement the data publishing process, and the terminal device 100 and each server can interact through HTTP protocol requests.

In the following embodiments of the present application, the configuration environment to be exported is the R&D environment 30, and the target environments to be imported are the test environment 40 and the integration environment 50 as examples to illustrate the data release method provided by the embodiments of the present application. At this time, the target environment servers are the server 400 in the test environment 40 and the server 500 in the integration environment 50 .

In some embodiments of this application, the microservices involved in this application can be microservices provided for products such as insurance products or financial products, and configuration data such as business data include basic data or rules of the product, such as insurance rules, claims rules, continued Insurance rules, risk control configuration, insurance plan copy, merchant number, insurance type, liability, terms, rate schedule, etc. Correspondingly, as an example, configuration data can be divided into the following types: insurance rules, claims rules, renewal rules, risk control configuration, protection plan copy, merchant number, insurance type, liability, terms, rate schedule, etc. It can be understood that the configuration data release involved in this application can be any type of configuration data among the above types.

Next, the configuration file preset before data export in the embodiment of the present application is first described below.

In the embodiment of this application, the server in the configuration environment exports configuration data such as business data based on the preset configuration file. Among them, the configuration file is usually configured manually by technicians, so the configuration file can remain unchanged during subsequent data export and publishing processes, and users do not need to repeatedly modify it manually.

It should be noted that in the embodiment of the present application, the code management management system 20 can store configuration data such as application data and business data of microservices in two warehouses respectively, thereby realizing separation of applications and data. Then, due to the separation of applications and data of microservices, configuration data such as business data of microservices can be separately exported to the code management system 20 and released. Furthermore, unified and centralized management of classified configuration data stored in the code management system 20 can be achieved. As an example, in the data corresponding to the configuration data of the microservice in the code management system 20, different types of data (such as insurance business data, insurance user information, etc.) are stored according to preset directories.

Specifically, in some embodiments, the above configuration file is used to define a data set, define microservice parameters such as the name of a microservice associated with the data set, and define an export executor corresponding to each data set in the configuration environment. in, A configuration file corresponds to a microservice, a configuration file defines one or more data sets, and a data set corresponds to an export executor.

It can be understood that since the data export in this application does not rely on database migration in the prior art, the source data of the above data set is not limited to database scripts, but can also be multi-source data such as pictures, pdf, excel, doc, etc. In other words, this application is not limited to the source data export and release of database scripts, but supports the export and release of multi-source data, which greatly improves the convenience of data release.

In some embodiments, one or more data sets defined in the configuration file contain the source data of the corresponding microservice in the configuration environment, and each defined data set has a name. Multiple data sets defined in the configuration file are the source data of the same current microservice; or, part of the data sets defined in the configuration file contains the source data of the current microservice (recorded as the target microservice), and another part of the data set contains other data sets. Source data for microservices. In other words, this application can export and publish the configuration data of other microservices while exporting and publishing the configuration data of the target microservice. That is to say, the data publishing method provided by the embodiment of this application supports exporting and publishing data other than the own server, further improving the convenience of data export and publishing.

In some embodiments, the above-mentioned export executor is used to export the corresponding data set from the server where the configuration environment is located (such as the server 300 in the R&D environment 30) to the code management system 20. As an example, the export executor is used to grab the source data in the corresponding dataset from the configuration environment. In addition, in some embodiments, an export executor may be an interface used to export the data indicated by the corresponding data set from the configuration environment to the code management system 20 , and the interface is used to indicate to the warehouse in the code management system 20 The path of a directory, that is, the export executor corresponding to a data set is also used to indicate the directory in the warehouse in the code management system 20 where the data set is stored.

In addition, the name of each data set and the name of the target microservice will be configured in the configuration environment and the database of each target environment. That is to say, the name of each microservice and the name of each data set are consistent in the configuration environment, the target environment, and the terminal device 100 . In some embodiments, the terminal device 100 can pre-set the above configuration file in the configuration environment 30 , such as pre-stored in the database of the server 300 in the R&D environment 30 .

In some embodiments, in order to ensure that the names of the microservices and the names of each data set are consistent in the configuration environment, the target environment and the terminal device 100, while storing the above configuration file in the configuration environment, the configuration can be pre-stored in the target environment. surface. Specifically, the configuration table in the target environment is used to define the data set, define microservice parameters such as the name of the microserver associated with the data set, define the import executor corresponding to each data set in the target environment, and define each data Set the corresponding callback information. For example, the callback operations indicated by the callback information can be clearing the cache, rebuilding the index, pushing data to the integration platform, and returning a publishing result report via email, etc. Among them, a configuration table corresponds to a microservice, a configuration table defines one or more data sets, and a data set corresponds to an import executor. It can be understood that the name of the defined data set and the name of the microservice are consistent in the configuration table of the target environment and the configuration file in the configuration environment.

Further, the format and content of the configuration file involved in this application are described in detail. In addition, the format of the configuration table in the target environment can refer to the relevant description of the configuration file, which will not be described in detail in this article.

In some embodiments, the configuration file is a file in Extensible Markup Language (Extensible Markup Language, xml) format and follows a custom Extensible Markup Language Schema Definition (XML Schema Definition, xsd) standard.

More specifically, the configuration file consists of two parts. The first part is the table definition, which is used to define the table name, primary key, foreign key, business primary key, sorting field (or sorting key), etc. The second part is the data set definition, which is used to define the data that needs to be exported. Table collections, conditions, parameters, etc.

Among them, primary key: refers to a column or a combination of multiple columns, whose value can uniquely identify each row in the table, through which the entity integrity of the table can be enforced. The primary key is mainly used to associate foreign keys with other tables, as well as modify and delete text records.

Foreign key: used to maintain data consistency and integrity. The main purpose is to control the data stored in the foreign key table and associate the primary key table and the foreign key table. Foreign keys can only reference columns in the foreign key table. value or use a null value.

Business primary key: In relational database design, the business primary key is a key composed of attributes that already exist in the world. In other expressions, a business primary key is a candidate key that is logically related to an in-row attribute. The business primary key ensures that there will be only one corresponding row for each business primary key.

Sort key: When creating a table, you generally do not need to specify the primary key, just the sort key. When the primary key is not specified, the column following order by will be used as the primary key. You can specify both the sort key (order by) and the primary key (primary key), but the primary key is best the prefix of the sort key.

When the specified primary key and sort key are different: the sort key is used to sort the data fragments, and the primary key is used to write marks in the index file.

Among them, the configuration file contains the name of the target microservice. For example, the table definition in the first part contains the name of the target microservice. The configuration file contains the name of each data set. For example, a table name of the table collection defined in the data set definition in the second part can be the name of a data set.

Further, as an example, if the target microservice serves a rule engine, then a Rule.xml file will be defined as the configuration file, that is, the name of the rule engine service is defined as "Rule". Among them, the first part of the Rule.xml file contains the table t_rm_rule that needs to be exported, which contains the primary key rule_id. The primary key rule_id is used to uniquely identify the table in the Rule.xml file. In addition, the second part of Rule.xml is a data set. Each data set can be named. The data set contains a collection of tables that need to be exported, t_rm_rule, t_rm_rule_group, etc. The export condition is rule_id in (ruleIds) (that is, the primary key rule_id is in the preset Assuming the parameter ruleIds), the data type of the parameter ruleIds is an array (Array) type. It is understandable that the name of the rule engine service is "Rule", and multiple data sets include a data set named t_rm_rule and a data set named t_rm_rule_group. In addition, in some embodiments, each data set in the above data sets is also used to define a preset change type. Furthermore, when the data indicated by a data set changes according to the preset change type defined by the data set, the data that triggers the data set indication is exported to the code management system 20 .

Next, check the configuration file for the primary key, foreign key, sort key, etc. in a table in the configuration file, the primary key, foreign key, sort key, etc. of a piece of data in the table, and the primary key of the table associated with the foreign key. Primary keys, foreign keys, and sort keys are described in .

As another example, the T_RM_EVENT table is a rule transaction table under the product rules of an insurance product. For example, the T_RM_EVENT table is a table in the Rule.xml file corresponding to the above-mentioned rule engine service. For example, in this table, the primary key (PrimaryKey) can be defined by the code "private Long eventId;" that is, the primary key is eventId; the business primary key (BusinessKey) can be defined by the code "private String name;"; the sorting key (orderKey, or sorting Field) is defined by the code "private String code;"; the foreign key (ReferenceKey) is defined by the code "@JoinColumn(name="DRIVER_ID")", that is, the foreign key is DRIVER_ID. It should be noted that in some embodiments, the business primary key is used to define the name of the business in the table definition, the sort key is used to sort each table in the table definition; the foreign key is used to define the name of the business outside the target microservice. Tables corresponding to the source data of other microservices.

In addition, the table in the configuration file includes multiple pieces of data, each piece of data including primary key, foreign key, sort key and business key. Service primary key, etc. It can be understood that at least one piece of data among multiple pieces of data in the configuration file can be used to define a data set.

As an example, refer to Figure 3, which is a piece of data in the T_RM_EVENT table in the above database, and this data is "underwriting rule inspection". Specifically, as shown in the dotted box in Figure 3, the primary key in this piece of data is -1, the name is UnderwritingRuleCheck, and the foreign key is -1, which is associated with the primary key DRIVER_ID in the T_RM_DRIVER (ie t_rm_driver) table. In addition, the sort key (orderKey) and business primary key (BusinessKey) are both UnderwritingRuleCheck, that is, the names of the primary key, business primary key, and sort key are the same.

Further, as an example, refer to the data in the parent table T_RM_DRIVER associated with the "underwriting rule verification" data shown in Figure 3, as shown in Figure 4, as shown in the dotted box in Figure 6. Indicates that the primary key of this piece of data is DRIVER_ID, which is used to associate it with the sub-table T_RM_EVENT. The name of this conditional data is UnderwritingRuleCheck.

In some embodiments, the server side can interact with the PC side to send data such as the "underwriting rule verification" data shown in Figure 4 stored on the server side to the PC side, and then display it to the operator through the PC side interface. . Among them, the above-mentioned server side refers to the server in various environments such as the research and development environment 30, or the server in the code management system 20. The above-mentioned PC side refers to the above-mentioned terminal device 100, or the terminal device in various environments such as the R&D environment 30 that interacts with the server to support the operator to query or modify data on the server side.

As an example, the operator can initiate a data request from the terminal device 100 to the server (such as the server 300), so that the server returns the "underwriting rule verification" data in response to the request, and then displays the data.

In some embodiments, when the operator queries the "Underwriting Rules Verification" data in the terminal device 100, the terminal device 100 can display the "Underwriting Rules Verification" data, and/or display the "Underwriting Rules Verification" data according to a preset style. Check” the main information in the data. For example, the terminal device 10 can display the two contents on the same interface, or can display the two contents on different interfaces respectively.

Further, as an example, for the "Underwriting Rule Check" data, that is, the data with the primary key of -1 and the name of UnderwritingRuleCheck, as shown in Figure 5, the "Underwriting Rule Check" data is displayed according to the preset style. main information. Among them, for the "Underwriting Rules Check" data, the main information shown in Figure 5 includes the following: the data code name "Event Code" 81 is "UnderwritingRuleCheck"; the data name "Event Name" 82 is "UnderwritingRuleCheck"; data description information "Description" 83 is "UnderwritingRuleCheck"; the data type "Event Type" 84 is DIRECT; the data associated data name "Driver" 85 is "UnderwritingRuleCheck", and the "Underwriting Rule Check" data is associated with Driver information through the primary key DriverId: -1 ; The rule group "Rule Group" 86 includes Cloud_Application_API_Validation (cloud application API interface takes effect), Cloud_Application_API (cloud application interface), AutoTest_Preset_UWRule_Group (automatic test preset underwriting rule inspection group), and UWcheckGroup (underwriting rule inspection rule) and other information.

Next, based on the multiple devices in the scenario shown in Figure 2 using the configuration files and data shown in Figures 3 to 5, with reference to the data publishing method flow shown in 9, the data publishing method provided by the embodiment of the present application is described in detail. Introduction, the method includes the following steps:

Step 601: The terminal device 100 sends a first request to the server 300 in the R&D environment 30. The first request is used to request to export the data indicated by the data set defined by the target configuration file in the server 300 where the R&D environment is located to the code management system. 20. It can be understood that the above-mentioned first request may also be called a data export instruction. Among them, the R&D environment 300 is a configuration environment, and the server 300 is a configuration environment server.

In some embodiments, the above-mentioned first request includes the name of the target data set and the name of the target microservice. As an example, the name of the target microservice in the first request is Rule shown above, that is, the rule engine service identified by the primary key rule_id; the name of the target data set can be t_rm_rule or t_rm_rule_group.

In some other embodiments, the above-mentioned first request also includes a target configuration file corresponding to the target microservice, or a target file parameter used to uniquely identify the target configuration file. Correspondingly, in response to the first request, the terminal device 100 may also send the target file parameters or the target configuration file to the server 300 . For example, as an example, the above target file parameter may be the file name of the target configuration file, such as the name "rule" of the file rule.xml mentioned above.

As an example, the configuration environment is R&D environment 30. The above-mentioned target data set is one or more data sets to be exported in the server of the R&D environment 30, and the above-mentioned target microservice is the microservice to which the target data set belongs. At this time, the data indicated by the data set to be processed can be configuration data such as business data of the target microservice. For example, one of the tables defined in the target data set is the T_RM_EVENT table shown in Figure 3. At this time, the target data set includes a table identified by the primary key -1 and the name UnderwritingRuleCheck. Furthermore, it is convenient to subsequently search the table in the target data set according to the primary key to find the data indicated by the target data set, so as to export and publish the data indicated by the data set to be processed.

In some embodiments, the target data set may include one or more sub-data sets, and the name of the target data set is included in a preconfigured configuration file corresponding to the target microservice.

Usually in scenarios where a new version is released uniformly or a hotfix is required, data export and release are performed on configuration data such as business data of the target microservice.

It can be understood that the above-mentioned first request may be manually initiated by the user.

In a possible implementation, the data publishing system 10 in the terminal device 100 can provide a trigger data export interface, which is responsible for sending the name of the target data set and the name of the target microservice to the server 300 . As an example, the interface for triggering data export may provide a first input box for inputting or selecting a data set name, a second input box for inputting or selecting a microservice name, and an export button for triggering data export. Then, after the user inputs the name of the target data set through the first input box, enters the name of the target microservice through the second input box, and operates the export button, the terminal device 100 can automatically generate the first request. At this time, the user's operation of the export button can trigger a one-click full export of the configuration data in the configuration environment. That is, the configuration file only needs to be configured once in advance, and then the data export can be easily and conveniently triggered. As an example, combined with the examples of Figures 4 to 5 above, the name of the data set entered by the user in the first input box can be UnderwritingRuleCheck (ie, underwriting rule check), and the target entered in the second input box The name of the microservice is UnderwritingRuleCheck.

Step 602: The server 300 finds the target export executor from the configuration file according to the name of the target data set and the name of the target microservice.

Specifically, the server 300 matches the target export executor corresponding to the target data set from the configuration file according to the name of the target data set and the name of the target microservice. Among them, a sub-export executor is matched for each sub-target sub-data set in the target data set.

As an example, for the data whose name is UnderwritingRuleCheck (underwriting rule check), the corresponding export executor can be found from the configuration file so that subsequent export operations can be performed on it.

Step 603: The server 300 exports the configuration data in the target data set to the first warehouse in the code management system 20 in the server 200 through target export execution. As an example, the UnderwritingRuleCheck data can be exported to the first warehouse in the code management system 20 through a target export executor corresponding to the data set in which the data is located.

In some embodiments, the above-mentioned first warehouse is a warehouse corresponding to the configuration data of the target microservice in the code management system 20 . In some embodiments, after exporting the configuration data in the target data set, the configuration data can be submitted to the code management system 20 according to a preset file directory structure.

It can be understood that the first warehouse in the code management system 20 not only contains the configuration data indicated by the target data set, but may also contain other configuration data.

In some embodiments, the above-mentioned first warehouse is a warehouse used to store configuration data of the target microservice in the code management system, and the first warehouse is different from the warehouse used to store application data of the target microservice in the code management system. In this way, every time data is published, all configuration data in the first warehouse only needs to be packaged, without processing the application data of the target microservice, which is beneficial to reducing the time and resource consumption of the data packaging process, making The data publishing process takes less time.

In addition, in some embodiments, the server 200 saves the configuration data in the target data set in the code management system 20 and can also record the version information in the configuration data in the first warehouse.

Step 604: The terminal device 100 sends a second request to the server 200. The second request is used to request the release of the configuration data of the target microservice in the target environment. It can be understood that the above-mentioned first request can also be called a data release instruction, and the second request is associated with the target microservice.

Wherein, the above-mentioned second request includes target environment parameters and the name of the target microservice. The target environment parameters are the address or name of the server in the target environment where the data is to be released, etc. Specifically, the second request is used to request to release the configuration data in the first warehouse corresponding to the target microservice in the code management system 20 to the target environment. As an example, the target environments may be the test environment 40 and the integration environment 50 .

It can be understood that the above second request may be manually initiated by the user.

In a possible implementation, the data publishing system 10 in the terminal device 100 can provide a triggering business data publishing interface, which is used to trigger the business data package corresponding to the target microservice in the code management system 20 and the target microservice. The name of the service is sent to the server of the target environment, that is, the user triggers the release of configuration data in the target environment.

As an example, the triggering business data publishing interface may provide a third input box for inputting or selecting the name of the microservice, a fourth input box for inputting or selecting target environment parameters, and a publishing button for triggering data publishing. Then, after the user inputs the name of the target microservice through the third input box, enters the target environment parameters through the fourth input box, and operates the publish button, the terminal device 100 can automatically generate the second request. At this time, the user's operation on the publish button can realize one-click publishing of configuration data. As an embodiment, the name of the microservice entered in the third input box may be UnderwritingRuleCheck, and the target environment parameters entered in the fourth input box may include the identification of the test environment 40 (such as the name of the test environment 40 or the name of the server 400 or address, etc.) and the identification of the integrated environment 50 (such as the name of the integrated environment 50 or the name or address of the server 500, etc.).

In some embodiments, when receiving the user's operation on the publish button, the data release management system 10 can also provide a verification interface for verifying the configuration data to be released, and prompts the verification result. If the verification is correct , then perform subsequent steps 605 and other steps, wherein verifying the configuration data to be released specifically includes verifying the correctness and integrity of the configuration data to be released, and may also verify the surrounding systems of the configuration data to be released, for example Commission allocation system. As an example, the data indicated by the target data set can be displayed in the verification interface, so that the user can intuitively see the data exported and published this time in the configuration data to be published, so as to verify the accuracy of the data to be published.

As an example, when receiving a user's operation on the release button, the data release management system 10 may also provide a peripheral verification button in the verification interface. At this time, the following steps may also be included after the above step 604: when receiving When the verification command is issued through the peripheral verification button, the peripheral system of the configuration data to be released is verified, such as the commission configuration system. If the verification passes, continue to perform subsequent steps such as step 605.

Step 605: The server 200 packages the configuration data in the first warehouse of the code management system 20 to obtain a business data package.

It can be understood that the server 200 packages all configuration data in the first warehouse. Moreover, the packaged service data package may be a compressed package.

Step 606: The server 200 publishes the service data package in the server 400 and server 500 corresponding to the target environment according to the target environment parameters.

The server 300 finds the corresponding export executor from the configuration file according to the name of the target data set and the name of the target microservice, and exports the configuration data in the target data set to the first warehouse in the code management system 20 through export execution.

In some embodiments, the code management system 20 can call the import interface corresponding to the test environment 40 and the import interface corresponding to the integration environment 50 through the server 200 to publish the business data package.

In some embodiments, the above target data set is also used to define a preset change type. When the change type of the data indicated by the target data set matches the corresponding preset change type, it is imported to the target environment server, such as the server of the test environment 40 400 and integrated environment 50 for server 500.

More specifically, in the embodiment of the present application, when the server 200 releases a service data package to the server 400 and the server 500, any server in the server 400 and the server 500 can determine whether the service data package is consistent with the current version of the service in the server. Whether there are differences between the data packets, for example, determine whether the MD5 Message-Digest Algorithm codes corresponding to the two data packets are the same to determine whether there are differences between the two data packets. If they are different, it means that the business data package to be imported has changed and is different from the current version of the business data package. If they are the same, it means that the data in the business data package to be imported has not changed and does not exist with the current version of the business data package. difference. Furthermore, when it is determined that there is a difference between the business data package to be imported and the business data package of the current version, the data in the business data package to be imported and the data in the business data package of the current version are obtained and compared, Determine the change type of data in the business data package to be imported, and obtain the change type of data indicated by each data set. Furthermore, the change type of the data indicated by each data set in the business data package to be imported is compared with the predefined preset change type in the corresponding data set. Only the change type of the data indicated by the data set matches the corresponding preset change type. The data indicated by this dataset will be imported into the target environment. For example, when the change type of the data indicated by the data set matches the preset change type predefined in the target data set, the data indicated by the data set is imported to the server in the target environment. In this way, it can be verified whether the data indicated by each data set is imported into the target environment in compliance with the preset change types to verify the accuracy of data release and import.

Step 607: The server 200 records all files released by the data and their corresponding release status. This enables subsequent repeated releases or rollback releases to achieve configuration data version control.

Among them, in some embodiments, all files (ie, release information) of data release include: the name of the business data package (ie, the name of the configuration data), version information, release time (including start time and end time), and release time. Status information (such as successful release, failed release, publishing in progress) and release logs (including historical version numbers, historical release time, historical version configuration data, etc.) and change types (such as new data, changed data, or deleted data, etc.) wait.

Specifically, the release log may also include a version tree formed based on the version information (such as version number) of the configuration data. Then, version comparison and rollback are performed based on the version tree to ensure that the release action is safe and reliable.

It should be noted that users check the change type in the release information and compare the change type with the corresponding preset change type to verify the correctness of data release and import. For example, for the change type of data indicated by the target data set recorded in the release information of the business data package, the comparison result of the change type with the preset change type predefined in the target data set can be used to determine the data indicated by the target data set. The judgment result of the import accuracy is used as the judgment result to judge the correctness of the business data package. For example, if the change type comparison result is different, it means that the business data package is imported incorrectly.

In addition, in some other embodiments, all files published by the data may also include business data packages.

It can be understood that repeated publishing can be implemented by repeatedly executing the above steps 604 to 606.

Step 608: The terminal device 100 obtains all files for data release and their corresponding release status from the server 200.

Wherein, the terminal device 100 may send a third request to the server 200, where the third request is used to obtain all files published by the data and their corresponding publishing status from the server 200.

In some embodiments, the third request may include the name of the target microservice, or information such as release time, which will be used as query conditions for querying the release status of the business data package.

It can be understood that the above third request can be manually initiated by the user.

In a possible implementation, the data publishing system 10 in the terminal device 100 can provide a business data publishing status interface, which is used to provide functions such as querying data publishing status, data change records (such as rollback publishing), etc. Specifically, the data release status interface can trigger querying information such as the release status of the business data package corresponding to the target microservice from the code management system 20 .

As an example, the business data release status interface can query the corresponding business data release status through release time, the name of the microservice to which the business data package belongs, and other query conditions. Among them, the business data release status interface can provide an input box for the user to input or select the release time, the name of the target microservice and other query conditions to trigger the query of the release status of the business data package.

As an embodiment, the user can select the name of the microservice UnderwritingRuleCheck in the business data release status interface to trigger the search for the data release status.

In addition, as another example, the business data release status interface can also provide the user with a re-publish button that triggers the re-publishing of the business data package of the target microservice through the release time, and a callback button that triggers the rollback of the business data package of the target microservice. Roll publish button etc.

Specifically, the query result of the queried business data package on the business data release status interface can include the following content: release status, release start time, end time, version number, release log entry, re-publish button, rollback release Buttons etc. For example, after the user clicks on the release log entry, the data release management system 10 displays a configuration history interface to display all versions of the configuration data, and the configurer can select any two version configurations for comparison. In addition, the configuration history interface can also provide a comparison between the version to be released and the online effective version, and provide a release button and a peripheral verification button.

Step 609: The server 400 parses the target service data packet and obtains the data indicated by the target data set in the target service data packet. As an example, the server 400 parses the target business data packet and can obtain "Underwriting Rule Check" data named UnderwritingRuleCheck in a target data set.

Step 610: The server 400 searches the configuration table for the first import executor and the first callback corresponding to the target data set. information, import the data indicated by the target data set into the server 400 through the first import executor, and execute the first callback operation indicated by the first callback information. Combined with the above example, the server 400 can search the configuration table for the import executor and callback information corresponding to the data set named UnderwritingRuleCheck.

Wherein, when the target data set includes multiple sub-data sets, the first import executor is specifically a plurality of sub-import executors. In addition, the first callback information also includes multiple sub-callback information, and each callback information indicates a callback operation.

As an example, the first callback operation can be clearing the cache, rebuilding the index, pushing data to the integration platform, returning the publishing result report via email, etc. For example, clearing the cache refers to clearing the cache in the server 400 to store service data packets. Rebuilding the index refers to the index rebuilt on the server 400 for the service data packet. Pushing data to the integration platform refers to pushing the data in the business data package into the data release management system 10 . In addition, the return of the publishing result report by email means that the server 400 sends the result of successful or failed business data publishing to a preset mailbox in the form of an email for technical personnel to view.

In some embodiments, the callback operation can be extended by inheriting the callback interface of the publishing service (such as the import interface above), and is embodied in the microservice in the form of a spring bean (that is, a microservice project, such as the above-mentioned target microservice). Specifically, the callback information of the data set can be achieved through the following steps: first, configure the corresponding spring bean name (for example, the above target is the name of the server) in the database of the target environment in advance; then, obtain it through the spring bean name spring bean, and finally execute the fixed method in the spring bean for callback.

Step 611: The server 500 parses the target service data packet and obtains the data indicated by the target data set in the target service data packet.

Step 612: The server 500 searches for the second import executor and the second callback information corresponding to the target data set from the configuration table, imports the data indicated by the target data set into the server 500 through the second import executor, and executes the second callback information. Indicates the second callback operation.

Similarly, the description of steps 611 and 612 may refer to the above description of step 609 and step 610, which will not be described again here. Wherein, the second callback information is the same as or different from the first callback information.

It should be noted that in the embodiment of the present application, the target environment is only the test environment 40 and the integration environment 50 as an example. The actual application may be more or less target environments.

It can be understood that in this embodiment of the present application, the server 400 and the server 500 can perform callback operations before, during, and after data is released.

In the embodiment of this application, when publishing configuration data based on configuration files, multi-source data publishing can be supported. In addition, you only need to configure the configuration file once, and then you can export all the configuration data with one click, and then publish the data with one click and handle callback operations intelligently. Manual intervention is no longer required, a large amount of duplication of work is avoided, the project launch cycle is greatly shortened, and subsequent operation and maintenance costs are reduced.

In a possible implementation manner, as shown in FIG. 7 , it is a schematic diagram of the hardware structure of a terminal device 100 provided by an embodiment of the present invention. The terminal device 100 shown in FIG. 7 includes: a processor 1001, a communication unit 1002, a memory 1003, a user interface 1004 and a bus interface 1005. In FIG. 7 , the bus architecture may include any number of interconnected buses and bridges, specifically one or more processors represented by processor 1001 and various circuits of the memory represented by memory 1003 linked together. The bus architecture can also link together various other circuits such as peripherals, voltage regulators, and power management circuits, which are all well known in the art and therefore will not be described further herein. The bus interface provides the interface. The communication unit 1002 may be a plurality of elements, including a transmitter and a receiver, providing means for communicating with various other devices over a transmission medium. For different management devices, the user interface 1004 can also It is an interface that can be connected to external and internal devices. The connected devices include but are not limited to keyboards, monitors, speakers, microphones, joysticks, mice, etc. The processor 1001 is responsible for managing the bus architecture and general processing, and the memory 1003 can store data used by the processor 1001 when performing operations. The display screen 1006 is used to provide a human-computer interaction interface.

In addition, the terminal device 100 also includes some not-shown functional modules, which will not be described again here.

The display screen in the user interface 1004 is used to provide the trigger data export interface, trigger data release interface, data release status interface, etc. in the data release management system 10 . Furthermore, the keyboard and mouse in the user interface 1004 can be used to support the user in inputting the name of the data set, the name of the target microservice and other information in the data release management system 10, and to receive the input of the number of users to trigger the operation of exporting all data with one click. , as well as trigger operations to publish data with one click, etc. The communication unit 1002 is configured to send a first request to trigger data export to the server that configures the environment, send a second request to trigger data release to the server 200 where the code management system 20 is located, and send a username to the server 200 where the code management system 20 is located. The third request for querying the data release status, etc. The processor 1001 is configured to generate a first request according to the user's input, and control the communication unit 1002 to initiate a request to the server.

In a possible implementation manner, as shown in FIG. 7 , it is a schematic diagram of the hardware structure of a terminal device 100 provided by an embodiment of the present invention. The terminal device 100 shown in FIG. 7 includes: a processor 1001, a communication interface 1002, a memory 1003, a user interface 1004 and a bus interface 1005. In FIG. 7 , the bus architecture may include any number of interconnected buses and bridges, specifically one or more processors represented by processor 1001 and various circuits of the memory represented by memory 1003 linked together. The bus architecture can also link together various other circuits such as peripherals, voltage regulators, and power management circuits, which are all well known in the art and therefore will not be described further herein. The bus interface provides the interface. Communication interface 1002 may be a plurality of elements, including a transmitter and a receiver, providing means for communicating with various other devices over a transmission medium. For different management devices, the user interface 1004 can also be an interface that can connect external and internal required devices. The connected devices include but are not limited to keyboards, monitors, speakers, microphones, joysticks, mice, etc. The processor 1001 is responsible for managing the bus architecture and general processing, and the memory 1003 can store data used by the processor 1001 when performing operations. The display screen 1006 is used to provide a human-computer interaction interface.

In addition, the terminal device 100 also includes some not-shown functional modules, which will not be described again here.

The display screen in the user interface 1004 is used to provide the trigger data export interface, trigger data release interface, data release status interface, etc. in the data release management system 10 . Furthermore, the keyboard and mouse in the user interface 1004 can be used to support the user in inputting the name of the data set, the name of the target microservice and other information in the data release management system 10, and to receive the input of the number of users to trigger the operation of exporting all data with one click. , as well as trigger operations to publish data with one click, etc. The communication interface 1002 is used to send a first request to trigger data export to the server that configures the environment, send a second request to trigger data release to the server 200 where the code management system 20 is located, and send a username to the server 200 where the code management system 20 is located. The third request for querying the data release status, etc. The processor 1001 is configured to generate a first request according to the user's input, and control the communication interface 1002 to initiate a request to the server.

Embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium includes computer instructions. When the computer instructions are run on the above-mentioned electronic device, the electronic device causes the electronic device to execute the mobile phone 10 ( Such as each function or step performed by each device in the mobile phone 10.

Embodiments of the present application also provide a computer program product. When the computer program product is run on a computer, it causes the computer to perform various functions performed by the mobile phone 10 (such as each component in the mobile phone 10) in the above method embodiment, or step.

Various embodiments of the mechanisms disclosed in this application may be implemented in hardware, software, firmware, or a combination of these implementation methods. middle. Embodiments of the present application may be implemented as a computer program or program code executing on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and/or storage elements) , at least one input device and at least one output device.

Program code may be applied to input instructions to perform the functions described herein and to generate output information. Output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any processor having a processor such as, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor. system.

Program code may be implemented in a high-level procedural language or an object-oriented programming language to communicate with the processing system. When necessary, assembly language or machine language can also be used to implement program code. In fact, the mechanisms described in this application are not limited to the scope of any particular programming language. In either case, the language may be a compiled or interpreted language.

In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried on or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be operated by one or more processors Read and execute. For example, instructions may be distributed over a network or through other computer-readable media. Thus, machine-readable media may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including, but not limited to, floppy disks, optical disks, optical disks, read-only memories (CD-ROMs), magnetic Optical disc, Read Only Memory (ROM), Random Access Memory (RAM), Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Memory Read memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), magnetic or optical card, flash memory, or used to use the Internet to transmit information through electrical, optical, acoustic or other forms of propagation signals (for example, carrier waves, infrared signals, digital signals etc.) tangible machine-readable storage. Thus, machine-readable media includes any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, computer).

In the drawings, some structural or methodological features may be shown in specific arrangements and/or orders. However, it should be understood that such specific arrangement and/or ordering may not be required. Rather, in some embodiments, the features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of structural or methodological features in a particular figure is not meant to imply that such features are required in all embodiments, and in some embodiments these features may not be included or may be combined with other features.

It should be noted that each unit/module mentioned in each device embodiment of this application is a logical unit/module. Physically, a logical unit/module can be a physical unit/module, or it can be a physical unit/module. Part of the module can also be implemented as a combination of multiple physical units/modules. The physical implementation of these logical units/modules is not the most important. The combination of functions implemented by these logical units/modules is what solves the problem of this application. Key technical issues raised. In addition, in order to highlight the innovative part of this application, the above-mentioned equipment embodiments of this application do not introduce units/modules that are not closely related to solving the technical problems raised by this application. This does not mean that the above-mentioned equipment embodiments do not exist. Other units/modules.

It should be noted that in the examples and descriptions of this patent, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply There is no such actual relationship or sequence between these entities or operations. Furthermore, the terms "comprises,""comprises," or any other variations thereof are intended to cover a non-exclusive inclusion such that a process, method, article, or device includes a list of elements. Equipment includes not only those elements but also other elements not expressly listed or elements inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a" does not exclude the presence of additional identical elements in a process, method, article, or device that includes the stated element.

Although the present application has been illustrated and described with reference to certain preferred embodiments thereof, it will be understood by those of ordinary skill in the art that various changes may be made in form and detail without departing from the present invention. The spirit and scope of the application.

Claims (13)

A data publishing method, characterized in that the method includes: The terminal device initiates a data export instruction to the configuration environment server, and the data export instruction is associated with the target microservice; In response to the data export instruction, the configuration environment server determines the target export executor and target data set corresponding to the target microservice according to a preset target configuration file, wherein the target configuration file is used to define the The correspondence between the target microservice, the target data set and the target export executor; The configuration environment server uses the target export executor to export the data indicated by the target data set from the configuration environment server to the code management server; the data indicated by the target data set corresponds to the target microservice Part of the data in the configuration data; The code management server saves the data indicated by the target data set into the first warehouse corresponding to the target microservice; the first warehouse is a storage space in the code management server used to store the target microservice. Configure a warehouse of data, and the first warehouse is different from the warehouse used to store application data of the target microservice in the code management server; The code management server packages all the configuration data in the first warehouse indicated by the target data set into a business data package, and publishes the business data package to at least one target environment server, wherein the business data package The data package includes all configuration data of the target microservice, excluding application data of the target microservice. The method according to claim 1, characterized in that the target data set is also used to define a preset change type; The method also includes: If the change type of the data indicated by the target data set complies with the preset change type, the at least one target environment server imports the data indicated by the target data set. The method according to claim 1 or 2, characterized in that, the method further includes: The configuration environment server parses the name of the target microservice from the data export instruction; The configuration environment server searches for the target export executor corresponding to the target data set from the target configuration file corresponding to the target microservice according to the name of the target microservice. The method according to any one of claims 1 to 3, characterized in that the target data set includes multiple sub-data sets, the target export executor includes multiple sub-export executors, and one of the sub-data sets Corresponds to a sub-exported executor; and, The source data in a part of the multiple sub-data sets is the source data of the target microservice, and the source data in another part of the sub-data set is the source data of a microservice different from the target microservice. The method according to claim 4, wherein the data type of the source data in the plurality of sub-data sets includes at least one of database scripts, pictures, portable document formats, tables, and documents. The method according to any one of claims 1 to 5, characterized in that the method further includes: The first target environment server parses out the target data set in the data packet, and the first target environment server is any one of the at least one target environment server; The first target environment server uses a target import executor to import the data indicated by the target data set according to the target configuration table corresponding to the target microservice; Wherein, the target configuration table is used to define the target microservice, the target data set and the target import Correspondence between actuators. The method of claim 6, further comprising: The first target environment server executes a target callback operation corresponding to the target data set; Wherein, the target configuration table is also used to define the corresponding relationship between the target data set and target callback information. The target data set includes multiple sub-data sets, and the target callback information includes multiple sub-callback information. One The sub-callback operation corresponds to one of the sub-data sets. The method according to any one of claims 1 to 7, characterized in that the method further includes: The terminal device initiates a data release instruction to the code management server, and the data release instruction is associated with the target microservice; Wherein, the business data package is released by the code management server to the at least one target environment server with one click in response to the data release instruction. The method of claim 2, further comprising: The server corresponding to the code management system records the release information corresponding to the configuration information of the target microservice; Wherein, the release information includes at least one of the following: the name of the target microservice, the name release time of the business data package, release status information, and changes in the target data set indication data in the business data package. type; and, The comparison result between the change type of the target data set indication data contained in the release information and the preset change type predefined in the target data set is used as a judgment result to determine the correctness of the business data package. The method according to claim 9, characterized in that the change type is at least one of newly added data, changed data and deleted data. The method according to claim 9 or 10, characterized in that, the method further includes: The terminal device receives a publishing query request corresponding to the service data packet; The terminal device initiates a release query request corresponding to the service data package to the server corresponding to the code management system; The service corresponding to the code management system returns the publishing information to the terminal device; The terminal device displays the release information, release button, rollback button and release log button through the query interface; Wherein, the publish button is used to trigger the re-publishing of the business data package to the at least one target environment server, and the rollback button is used to trigger execution of the business data in the at least one target environment server. In the rollback operation, the release log button is used to trigger the terminal device to display the historical release information of the service data package. The method according to any one of claims 1 to 11, characterized in that, The target microservice is applied to Internet financial products or Internet insurance products. A data publishing system, characterized in that the system includes a terminal device, a configuration environment server, a code management server, and at least one target environment server; The terminal device is used to initiate a data export instruction to the configuration environment server, where the data export instruction is associated with the target microservice; The configuration environment server is configured to respond to the data export instruction and determine the target export executor and target data set corresponding to the target microservice according to a preset target configuration file, wherein the target configuration file is used to Define the corresponding relationship between the target microservice, the target data set and the target export executor; The configuration environment server uses the target export executor to export the data indicated by the target data set from the The configuration environment server exports to the code management server; the data indicated by the target data set is part of the data in the configuration data corresponding to the target microservice; The code management server is also used to save the data indicated by the target data set to the first warehouse corresponding to the target microservice; the first warehouse is used in the code management server to store the A warehouse for the configuration data of the target microservice, and the first warehouse is different from the warehouse used to store the application data of the target microservice in the code management server; The code management server is also configured to package all configuration data in the first warehouse indicated by the target data set into a business data package, and publish the business data package to at least one target environment server, wherein , the business data package includes all configuration data of the target microservice, excluding application data of the target microservice.