CN106919590B - Multi-service multiplexing processing method, device and system - Google Patents

Multi-service multiplexing processing method, device and system Download PDF

Info

Publication number
CN106919590B
CN106919590B CN201510993250.4A CN201510993250A CN106919590B CN 106919590 B CN106919590 B CN 106919590B CN 201510993250 A CN201510993250 A CN 201510993250A CN 106919590 B CN106919590 B CN 106919590B
Authority
CN
China
Prior art keywords
service
general
type
operation instruction
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201510993250.4A
Other languages
Chinese (zh)
Other versions
CN106919590A (en
Inventor
周安林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Advantageous New Technologies Co Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201510993250.4A priority Critical patent/CN106919590B/en
Publication of CN106919590A publication Critical patent/CN106919590A/en
Application granted granted Critical
Publication of CN106919590B publication Critical patent/CN106919590B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems

Abstract

The application discloses a multi-service multiplexing processing method, device and system. A multi-service multiplexing processing system includes: the service interface layer is used for receiving a service operation request sent to the system from the outside of the system; the service data routing layer is used for calling a general service operation instruction from the general instruction library, constructing an actual service operation instruction according to the type of the service to be processed and routing the service operation request received by the service interface layer to the corresponding database; a general instruction library: storing a general service operation instruction, wherein the actual storage position of the operation object data is not specified in the general service operation instruction; and the database is used for storing the service data. According to the technical scheme, based on the reusability of the service operation logic, when a new service is added, the service function can be directly realized only by adding a set of new database configuration, and the development and maintenance cost is effectively reduced.

Description

Multi-service multiplexing processing method, device and system
Technical Field
The present application relates to the field of computer application technologies, and in particular, to a method, an apparatus, and a system for multiplexing multiple services.
Background
The development of computer and internet technologies brings unprecedented convenience to people, and at present, the technologies penetrate into various aspects of daily life of people, and for some comprehensive service providers, the technologies can provide services for users in various aspects of various fields.
Taking the internet financial industry as an example, for the assets of the user, a corresponding accounting system is needed for management. According to the existing accounting system design mode, for different types of services, independent accounting systems need to be designed respectively. As shown in fig. 1, for deposit, financing and card and ticket business, three sets of business systems are respectively designed, each set of system has independent business logic, and different physical databases are used to ensure the isolation between data. However, as business models develop and innovate, forms of user assets become more and more abundant, such as: the bank user has a deposit account, a financing account and the like, and the website user has a balance account, a red packet account, a voucher account and the like. According to the design mode of the existing service system, every time one user asset type is added, a set of service system needs to be added for management.
In addition to the financial industry, similar situations exist in other areas, and the problems caused by the situations are that: each additional service requires a certain development and maintenance cost on the new service system. In addition, the use of independent physical databases among different service systems also results in low utilization rate of database resources.
Disclosure of Invention
In view of the above technical problems, the present application provides a method, an apparatus, and a system for multiplexing multiple services, and the technical solution is as follows:
according to a first aspect of the present application, there is provided a multi-service multiplexing processing method for processing two or more types of services including the same operation logic, the method including:
receiving a service operation request, and determining a service type to be processed and a corresponding operation type;
determining the storage position of the service data in the database according to the type of the service to be processed;
according to the operation type of the service to be processed, obtaining a preset general service operation instruction for processing the operation type, wherein the actual storage position of the operation object data is not specified in the general service operation instruction;
constructing an actual service operation instruction by using the determined service data storage position and the obtained general service operation instruction;
and executing the actual business operation instruction to respond to the business operation request.
According to a second aspect of the present application, there is provided a multi-service multiplexing processing apparatus for processing two or more types of services including the same operation logic, the apparatus comprising:
the request receiving module is used for receiving the service operation request and determining the type of the service to be processed and the corresponding operation type;
the storage position determining module is used for determining the storage position of the service data in the database according to the type of the service to be processed;
the device comprises a general operation instruction obtaining module, a data processing module and a data processing module, wherein the general operation instruction obtaining module is used for obtaining a preset general service operation instruction for processing an operation type according to the operation type of a service to be processed, and the actual storage position of operation object data is not specified in the general service operation instruction;
the actual operation instruction construction module is used for constructing an actual service operation instruction by utilizing the determined service data storage position and the obtained general service operation instruction;
and the execution module is used for executing the actual business operation instruction so as to respond to the business operation request.
According to a third aspect of the present application, there is provided a multi-service multiplexing processing system for processing two or more types of services including the same operation logic, the system comprising: the system comprises a service interface layer, a service data routing layer, a general instruction base and a database;
the service interface layer is used for receiving a service operation request sent to the system from the outside of the system;
the service data routing layer is used for calling a general service operation instruction from the general instruction library, constructing an actual service operation instruction according to the type of the service to be processed and routing the service operation request received by the service interface layer to the corresponding database;
a general instruction library: storing a general service operation instruction, wherein the actual storage position of the operation object data is not specified in the general service operation instruction;
and the database is used for storing the service data.
According to the technical scheme, based on the reusability of the service operation logic, when a new service is added, the service function can be directly realized only by adding a set of new database configuration, and the development and maintenance cost is effectively reduced. Furthermore, the use mode of the database can be flexibly configured through a data routing algorithm, so that the optimal utilization of the database resources is realized.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings.
Fig. 1 is a schematic diagram of a prior art accounting system architecture;
fig. 2 is a schematic diagram of the accounting system structure of the present application;
fig. 3 is a schematic flow chart of a multi-service multiplexing processing method according to the present application;
fig. 4 is a schematic structural diagram of a multi-service multiplexing processing apparatus according to the present application.
Detailed Description
It is found through research that in practical applications, although the services processed by many systems are different, the operations actually involved are similar, for example, in the examples mentioned in the background art, no matter the service systems, such as deposit, financing, balance, red packet, etc., all require functions, such as querying, depositing, taking, freezing, unfreezing, etc., from the perspective of database operations, the processing logic corresponding to the same operation among different services is completely the same, and the difference is only different in the target database corresponding to the operation. Based on the situation, the scheme provided by the application is as follows: a set of general database operation logic is developed for multiplexing of multiple services, and when a specific service is processed, the general operation is only required to be directed to the database corresponding to the service.
In order to make those skilled in the art better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be described in detail below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all embodiments. All other embodiments that can be derived from the embodiments given herein by a person of ordinary skill in the art are intended to be within the scope of the present disclosure.
Still taking the accounting system as an example, the service multiplexing scheme provided in the present application is described, and fig. 2 is a schematic diagram of an architecture of a comprehensive accounting system provided in the present application. The system comprises: service interface layer 100, service data routing layer 200, general instruction base 300, and database 400.
Service interface layer 100: the system is responsible for receiving service operation requests sent to the system from the outside of the system. As shown in fig. 1, the integrated financial system can receive operation requests of a plurality of services, such as deposit service, financial service, card and ticket service, and at an interface level, the receiving logic of the operation requests of different services is unified.
Service data routing layer 200: is responsible for routing service operation requests received by the service interface layer 100 to the corresponding database. The main functions include:
calling a corresponding general service operation instruction from the general instruction library 300 according to the operation type;
and determining the actual storage position of the current business operation object data according to the business type, and constructing an actual business operation instruction for processing the current business according to the called general business operation instruction. Depending on the actual usage of the database, the storage location may include two specific information, namely "library location" and "table location", which will be further described in the following embodiments.
The general instruction library 300: a plurality of general service operation instruction codes are stored, such as query operation statements, freezing operation statements, unfreezing operation statements and the like. In these statements, the storage location of the specific operation object in the database does not need to be specified, and the corresponding part in the statement may be left empty or replaced with some sort of identifier. A particular statement may apply to all traffic types. When a general service operation command is called by the service data routing layer 200, it will be reconstructed as an actual service operation command together with the actual storage location of the service operation object data.
The database 400: in the scheme provided by the application, different services can use independent physical databases respectively, and the utilization rate of database resources can be improved by sharing the same physical database. For the latter mode, the data storage locations of different services may be divided in a logical database mode, and the service operation is directed to the corresponding logical database in combination with the routing function of the service data routing layer 200, thereby ensuring data isolation between services.
It can be seen that, in the multi-service multiplexing system provided in the present application, the service data routing layer 200 is a core functional component, and the following will describe the basic functions of the service data routing layer 200 with reference to specific examples:
1) and (3) database configuration:
the scheme provided by the application not only supports different services to use independent physical database resources respectively, but also supports different services to share the same physical database resources. The former way is the same as the database resource using way in the prior art, and is not further described in the application; the latter method can be further divided into the case of storing in a database or a table. Some services have very large access volume, and the databases need to be subjected to database partitioning and table partitioning to support huge service access volume. On the contrary, if the service access amount is not large, resources do not need to be wasted for database division or table division, and only a single database single table or a single database sub table needs to be configured.
Assume that there are M physical databases in the system: db0, db1, … dbM-1, then for any service x:
if x is configured to use a single bank, i.e., the number of sub-banks mx1, any 1 of the M physical databases may be used to store business data;
if x is configured to use sub-banks, i.e. the number of sub-banks is 1<mxM ≦ M, any M of the M physical databases may be usedxStoring the service data;
for the case of a single library, the method can be directly configured as single table storage and can also be configured as sub-table storage; for the case of sub-base, only sub-table storage can be configured. To facilitate uniform computation and expansion, the number n of data tables is typically setxIs set as mxInteger multiples of.
Data tables between different services are distinguished by service identities, for example:
for service x, the data table name it correspondingly uses is: x _000, x _001, x _002, … …
For service y, the data table name used correspondingly is: y _000, y _001, y _002, … …
Of course, the above naming convention is for illustrative purposes only and should not be construed as limiting the scope of the present application.
2) Data routing:
the data routing comprises two parts, namely library routing and table routing, and during actual application, the data routing needs to be accurately routed to a specific sub-library and a specific sub-table according to the service type and certain characteristics of service operation target data.
Suppose that for service x, its user data is stored in m in sequence according to user number accountNoxN of each sub-libraryxIn each sub-table, the library route and table route calculation method is as follows:
library routing:
under the condition of single base, the base position is the service type number% M;
in the case of binning, binning bit ═ (accountNo% nx)/(nx/mx)
Table routing:
in the case of a single table, there is no branch table, and the corresponding table name is "service identifier";
in the case of the sublist, the sublist bit is (accountNo% n)x) The corresponding table name is "service identifier _ sub-table".
In the above formula, "%" represents a remainder operation, and "/" represents an integer division operation.
The following describes the database configuration and data routing scheme of the present application with reference to specific examples:
it is assumed that the system supports deposit, financing and card services simultaneously and has 5 physical databases db0, db1, … db 4. According to the service requirement, the configuration is as follows:
deposit service: using 5 databases and 100 data tables in total, wherein each database comprises 20 data tables;
financing service: using 1 database and 10 data tables in total;
card ticket business: 1 database and 1 data table are used;
specific configuration information is shown in table 1, where "service type code" is used to distinguish different services, "type number" is used to distinguish different sub-libraries, and "type suffix" is used to distinguish sub-tables of different services.
Type of service Service type coding Type numbering Type suffix Whether to divide the warehouse or not Number of sub-banks Whether to divide the table Number of sub-meters
Deposit transaction DTTRANS 0 dt true 5 true 100
Financing service FDTRANS 1 fd false 1 true 10
Card ticket business FDTRANS 2 cp false 1 false 1
TABLE 1
Assuming that the user number accountNo is 2015092201234, the database and the data table corresponding to the data in each service data item can be calculated according to the number and the configuration in table 1.
For a deposit transaction:
mx=5,nx=100;
(accountNo% n)x)/(nx/mx) 34/20 ═ 1, corresponding to the physical database db 1;
epitope (accountNo% n)x) The corresponding table name is dt _034, 34.
For financial services:
mx=1,nx=10
the database sharing position is the service type number% M1, and the corresponding physical database is db 1;
epitope (accountNo% n)x) The corresponding table name is fd _004 ═ 4.
For a card transaction:
mx=1,nx=1
the database dividing position is the service type number% M2, and the corresponding physical database is db 2;
the sub-table bit does not exist and the corresponding table name is cp.
It will be appreciated that the above database configuration and data routing scheme is not the only embodiment of the present application. For example, the following steps are carried out: the single-library bit uses a calculation formula: the number of the service type is% M, which aims to distribute different single-base services to each physical database on average, and there are many actual database configuration modes, for example, for the case that there are 5 physical databases, all the single-base services can be distributed to the database db0, and the sub-base services can be distributed to the databases db 1-db 4, so the data routing calculation formula also needs to be adjusted accordingly. In addition, the naming rules of the database and the data table in practical application, the storage allocation rules of each piece of data, and other factors all affect the corresponding data routing calculation formula. In summary, the above detailed description should not be construed as limiting the present application.
On the basis of the above database configuration and data routing scheme, the present application provides a multi-service multiplexing processing method, where an execution subject of the method is a service data routing layer 200 in a system, and in an execution process, basic information of a service operation needs to be obtained from a service operation request forwarded by a service interface layer 100, a general service operation instruction is called from a general instruction library 300, and a database 400 is used as a final operation object, as shown in fig. 3, the method may include the following steps:
s101, receiving a service operation request, and determining a service type to be processed and a corresponding operation type;
still taking the aforementioned accounting system as an example, the types of the pending transactions may include: deposit, financial, card and ticket transactions, etc., and the corresponding types of operations may include: the query, the storage, the extraction, the freezing, the thawing, and the like, which are all obtained by analyzing the service operation request, are not further described in detail in this application.
S102, determining the storage position of the service data in a database according to the type of the service to be processed;
if the independent physical databases are respectively used among different services, determining the storage position of the service data in the database directly according to the corresponding relation between the service data and the physical databases;
if the same physical database is shared among different services, the method provided in the previous embodiment is adopted to determine the logical storage location of the service data in the general physical database. According to the specific service data storage situation, operations such as determining a sub-library bit, a sub-library bit and the like may be included, and the specific process is not described repeatedly in this embodiment.
In a multi-thread operating environment, each type of processing thread with fixed identification features may be assigned, for example, a service type name is encoded in a specific manner, an interceptor is set at the service interface layer 100, a thread variable is set according to a preset rule, from the perspective of a thread, each thread maintains an implicit reference to a copy of a local variable of the thread, and the thread variable is always valid and accessible during a life cycle of a thread, so that when a data routing layer processes, a service code may be directly extracted according to a variable of a current service processing process, and then a corresponding service data storage location is further determined. The method does not need to really know the service type by the data routing layer, only needs to inquire according to the identification characteristics of the threads, and can better meet the resource sharing problem of multiple threads. Of course, this approach should not be construed as limiting the scope of the claimed subject matter.
S103, acquiring a preset general service operation instruction for processing the operation type according to the operation type of the service to be processed;
in the general instruction library, a plurality of general service operation instruction codes are stored in advance, and only basic processing logic is contained in the instruction codes without indicating the storage position of a specific operation object in the database.
Assuming that the operation type of the service to be processed is "query", taking account information query as an example, the general query instruction code form is as follows:
connect to [ library name ]
The/representation is connected to a designated library, here pseudo code, which is implemented differently in different operating environments;
select from table name, where account no user number
// here is the sql statement
The content in the middle brackets is not specifically indicated, and after the specific content is indicated for the variable in the middle brackets in the subsequent steps, the statement can be correspondingly used for processing inquiry operations of various services such as deposit, financial management, card and ticket services and the like.
It should be noted that the execution order of S102 and S103 is not specifically limited in sequence.
S104, constructing an actual service operation instruction by using the determined service data storage position and the obtained general service operation instruction;
assuming that the user number is 2015092201234, the type of the service to be processed is "deposit service", the operation type is "account information inquiry",
according to the calculation of S102, the service data is stored in the data table dt _034 of the database db1, and the unspecified content is replaced according to the general query instruction code obtained in S103, and the actual service operation instruction code is reconstructed as follows:
connect to db1
// pseudo-code, representing a connection to db 1;
select*from dt_034in where account_no=’2015092201234’
a// sql statement;
and S105, executing an actual service operation instruction to respond to the service operation request.
Therefore, the scheme provided by the application completely isolates different service data based on the horizontal expansion of the database of the service channel, establishes and supports various service systems under different service systems, and provides a complete solution for the access of new services in the future; due to the reusability of the operation logic, when a new service is added, the service function can be directly realized only by adding a set of database configuration, and the development and maintenance cost is effectively reduced. In addition, the use mode of the database can be flexibly configured through a data routing algorithm, so that the optimal utilization of database resources is realized.
In addition, although the above embodiments are described only in terms of accounting system applications, the application scenario should not be construed as limiting the application scheme. For example, in a game platform, the management logic of different in-game information is the same, including user registration, login, points, in-purchase, achievement and the like, the corresponding operation logic can be designed as a general operation instruction, and the scheme of the application realizes the unified management of the same game platform on a plurality of games. Similar application scenarios are not illustrated here, and in summary, according to the solution provided in the present application, a person skilled in the art can design a multi-service multiplexing scheme applied to other scenarios without creative effort.
Corresponding to the above method embodiment, the present application further provides a multi-service multiplexing processing apparatus, which is functionally equivalent to the service data routing layer in the foregoing embodiment, and as shown in fig. 4, the apparatus may include:
a request receiving module 110, configured to receive a service operation request, and determine a service type to be processed and a corresponding operation type;
a storage location determining module 120, configured to determine, according to the type of the service to be processed, a storage location of the service data in the database;
a general operation instruction obtaining module 130, configured to obtain a preset general service operation instruction for processing an operation type according to the operation type of a service to be processed, where an actual storage location of operation object data is not specified in the general service operation instruction;
an actual operation instruction constructing module 140, configured to construct an actual service operation instruction by using the determined service data storage location and the obtained general service operation instruction;
and the execution module 150 is configured to execute the actual service operation instruction to respond to the service operation request.
In a specific embodiment of the present application, each type of service corresponds to a processing thread having a fixed identification feature; accordingly, the storage location determining module 120 may be specifically configured to determine the storage location of the service data in the database according to the currently used service processing thread identification feature.
In a specific embodiment of the present application, different types of services share the same physical database; accordingly, the storage location determining module 120 may be specifically configured to determine the logical storage location of the business data in the common physical database.
The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the solution of the present application. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is directed to embodiments of the present application and it is noted that numerous modifications and adaptations may be made by those skilled in the art without departing from the principles of the present application and are intended to be within the scope of the present application.

Claims (6)

1. A multi-service multiplexing processing method is used for processing more than two types of services containing the same operation logic, and is characterized by comprising the following steps:
receiving a service operation request, and determining a service type to be processed and a corresponding operation type;
determining a logic storage position of service data in a general physical database according to the type of the service to be processed, wherein different types of services share the same physical database;
according to the operation type of the service to be processed, obtaining a preset general service operation instruction for processing the operation type, wherein the actual storage position of the operation object data is not specified in the general service operation instruction; wherein, the different operation types correspond to different general service operation instructions;
constructing an actual service operation instruction by using the determined service data storage position and the obtained general service operation instruction;
and executing the actual business operation instruction to respond to the business operation request.
2. The method of claim 1, wherein each type of service corresponds to a processing thread having a fixed identification characteristic;
the determining the storage position of the service data in the database according to the type of the service to be processed includes: and determining the storage position of the service data in the database according to the identification characteristics of the currently used service processing thread.
3. A multi-service multiplexing processing apparatus for processing two or more types of services including the same operation logic, the apparatus comprising:
the request receiving module is used for receiving the service operation request and determining the type of the service to be processed and the corresponding operation type;
the storage position determining module is used for determining the logic storage position of the service data in the general physical database according to the type of the service to be processed, wherein different types of services share the same physical database;
the device comprises a general operation instruction obtaining module, a data processing module and a data processing module, wherein the general operation instruction obtaining module is used for obtaining a preset general service operation instruction for processing an operation type according to the operation type of a service to be processed, and the actual storage position of operation object data is not specified in the general service operation instruction; wherein, the different operation types correspond to different general service operation instructions;
the actual operation instruction construction module is used for constructing an actual service operation instruction by utilizing the determined service data storage position and the obtained general service operation instruction;
and the execution module is used for executing the actual business operation instruction so as to respond to the business operation request.
4. The apparatus of claim 3, wherein each type of service corresponds to a processing thread having a fixed identification characteristic;
the storage location determining module is specifically configured to determine a storage location of the service data in the database according to the currently used service processing thread identification feature.
5. A multi-service multiplexing processing system for processing two or more types of services containing the same operation logic, the system comprising: the system comprises a service interface layer, a service data routing layer, a general instruction base and a database;
the service interface layer is used for receiving a service operation request sent to the system from the outside of the system;
a general instruction library: storing a general service operation instruction, wherein the actual storage position of the operation object data is not specified in the general service operation instruction;
the database is used for storing the service data;
the service data routing layer comprises:
the request receiving module is used for receiving the forwarded service operation request and determining the type of the service to be processed and the corresponding operation type;
the storage position determining module is used for determining the logic storage position of the service data in the general physical database according to the type of the service to be processed, wherein different types of services share the same physical database;
the general operation instruction obtaining module is used for obtaining a preset general service operation instruction for processing the operation type from a general instruction library according to the operation type of the service to be processed; wherein, the different operation types correspond to different general service operation instructions;
the actual operation instruction construction module is used for constructing an actual service operation instruction by utilizing the determined service data storage position and the obtained general service operation instruction;
and the execution module is used for executing the actual business operation instruction so as to respond to the business operation request.
6. The system of claim 5, wherein each type of service corresponds to a processing thread having a fixed identification characteristic;
the storage location determining module is specifically configured to determine a storage location of the service data in the database according to the currently used service processing thread identification feature.
CN201510993250.4A 2015-12-24 2015-12-24 Multi-service multiplexing processing method, device and system Active CN106919590B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510993250.4A CN106919590B (en) 2015-12-24 2015-12-24 Multi-service multiplexing processing method, device and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510993250.4A CN106919590B (en) 2015-12-24 2015-12-24 Multi-service multiplexing processing method, device and system

Publications (2)

Publication Number Publication Date
CN106919590A CN106919590A (en) 2017-07-04
CN106919590B true CN106919590B (en) 2020-05-29

Family

ID=59459784

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510993250.4A Active CN106919590B (en) 2015-12-24 2015-12-24 Multi-service multiplexing processing method, device and system

Country Status (1)

Country Link
CN (1) CN106919590B (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107392766A (en) * 2017-07-25 2017-11-24 上海壹账通金融科技有限公司 Method for processing business, adapter and computer-readable recording medium
CN107819861A (en) * 2017-11-16 2018-03-20 中国银行股份有限公司 Business data processing method, apparatus and system
CN108920563B (en) * 2018-06-21 2021-07-30 创新先进技术有限公司 Database switching method and device
CN111061759A (en) * 2018-10-17 2020-04-24 联易软件有限公司 Data query method and device
CN110348859A (en) * 2019-06-17 2019-10-18 阿里巴巴集团控股有限公司 A kind of complaint processing method and system
CN110781165B (en) * 2019-10-10 2022-02-25 支付宝(杭州)信息技术有限公司 Method, device and equipment for processing service data
CN111797074A (en) * 2020-07-03 2020-10-20 中国建设银行股份有限公司 Database connection method and device, electronic equipment and readable storage medium
CN114006927B (en) * 2021-11-01 2024-02-02 中国工商银行股份有限公司 Service message processing method and processing device thereof, electronic equipment and storage medium

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1921572A1 (en) * 2006-11-09 2008-05-14 Max J. Pucher Method for training a system to specifically react on a specific input

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100671506B1 (en) * 2005-09-13 2007-01-19 한미아이티 주식회사 A mobile middleware and a method for processing business logic using it
US8799319B2 (en) * 2008-09-19 2014-08-05 Oracle International Corporation System and method for meta-data driven, semi-automated generation of web services based on existing applications
CN102520963B (en) * 2011-12-26 2014-10-01 重庆新媒农信科技有限公司 Method and system for realizing service logic processing based on strongly-typed relation mapping
CN103873433A (en) * 2012-12-07 2014-06-18 中国移动通信集团福建有限公司 Service activation-based data processing method, device, server and system
US9063710B2 (en) * 2013-06-21 2015-06-23 Sap Se Parallel programming of in memory database utilizing extensible skeletons
CN103677810B (en) * 2013-11-21 2018-06-01 金蝶软件(中国)有限公司 Business mobile application system and its application process
CN104066079A (en) * 2014-06-27 2014-09-24 北京思特奇信息技术股份有限公司 Method and device for number-carrying cross-region service processing

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1921572A1 (en) * 2006-11-09 2008-05-14 Max J. Pucher Method for training a system to specifically react on a specific input

Also Published As

Publication number Publication date
CN106919590A (en) 2017-07-04

Similar Documents

Publication Publication Date Title
CN106919590B (en) Multi-service multiplexing processing method, device and system
CN108494891A (en) A kind of domain name analytic method, server and system
JP4571609B2 (en) Resource allocation method, resource allocation program, and management computer
CN103324487B (en) Method for achieving SaaS for workflow engine
CN110019292A (en) A kind of querying method and device of data
KR20160147909A (en) System and method for supporting common transaction identifier (xid) optimization and transaction affinity based on resource manager (rm) instance awareness in a transactional environment
CN110661842B (en) Resource scheduling management method, electronic equipment and storage medium
CN111581234B (en) RAC multi-node database query method, device and system
CN112866421B (en) Intelligent contract operation method and device based on distributed cache and NSQ
WO2016191995A1 (en) Method and device for partitioning association table in distributed database
CN104866976A (en) Multi-tenant-oriented information managing system
CN101340368B (en) Web service distributed management system and method based on WSDM
CN109104368A (en) A kind of request connection method, device, server and computer readable storage medium
CN109245915B (en) Method and system for realizing server set balanced allocation
CN112699134A (en) Distributed graph database storage and query method based on graph subdivision
CN102932389A (en) Request processing method and device, and server system
CN105978744A (en) Resource allocation method, device and system
CN110502339A (en) Data service resource allocation methods, device, system and storage medium
CN106951225B (en) Data processing method and device based on service configuration template
CN106940725B (en) Credit investigation data storage scheduling method and system
CN112001800B (en) Method and device for processing business in block chain system
CN110879748A (en) Shared resource allocation method, device and equipment
CN104869172B (en) The data interactive method and data interaction system more applied under heterogeneous system
CN110851483B (en) Method, apparatus, electronic device, and medium for screening objects
Wang et al. Node‐Fusion: Topology‐aware virtual network embedding algorithm for repeatable virtual network mapping over substrate nodes

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20200921

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee after: Innovative advanced technology Co.,Ltd.

Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee before: Advanced innovation technology Co.,Ltd.

Effective date of registration: 20200921

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee after: Advanced innovation technology Co.,Ltd.

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Patentee before: Alibaba Group Holding Ltd.

TR01 Transfer of patent right