CN114884964A - Service wind control method and system based on Tuxedo architecture - Google Patents
Service wind control method and system based on Tuxedo architecture Download PDFInfo
- Publication number
- CN114884964A CN114884964A CN202210807577.8A CN202210807577A CN114884964A CN 114884964 A CN114884964 A CN 114884964A CN 202210807577 A CN202210807577 A CN 202210807577A CN 114884964 A CN114884964 A CN 114884964A
- Authority
- CN
- China
- Prior art keywords
- wind control
- service
- business
- wind
- request
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
The application relates to a business wind control system, wherein, the business wind control system constructs on Tuxedo framework, the business wind control system includes: a service system configured to receive a service request from a user and forward it to a HAproxy server; the HAproxy server is configured to distribute the service request to a corresponding wind control system according to a preset distribution rule; the wind control system in the Tuxedo domain is configured for carrying out wind control service processing according to the received service request; and the database is configured to store the business wind control rules and the wind control parameters related in the wind control service.
Description
Technical Field
The present application relates to the field of wind control of a service system, and more particularly, to a service wind control method and system capable of implementing a dynamic customized wind control service and multi-granularity load balancing based on a Tuxedo architecture.
Background
With the progress of information technology, the innovation of payment settlement tools and the increasing expansion of settlement channels, the payment settlement operation tends to develop in the direction of automation, informatization and electronization. Meanwhile, the payment settlement risk is increased, and a new form and new characteristics appear, so that the account and fund security of the user, the merchant, the bank, a third-party financial institution and the like is directly threatened. For example, the payment risk may include, but is not limited to: telecom fraud risk, credit card crime risk, electronic payment risk, system vulnerability risk, etc.
To avoid the various payment risks described above, technicians have developed various wind-controlled systems that protect against transaction data risks.
Currently mainstream wind control systems generally include the following features:
the database read-write separation mechanism is that rule parameters, transaction data and the like are put into a database, the database adopts a fragmentation mechanism and a master-slave copy mode, and the system writes data and reads data to access different databases.
In a distributed cache mode, namely, high-frequency data is put into some cache middleware (such as Redis, memcache), the performance of the system can be improved by the high-efficiency cache system, and the wind control system acquires wind control parameters and wind control rules from the cache.
In addition, a load balancing mode for the currently mainstream wind control system mainly utilizes a common software load balancing technology (such as Linux VirtualServer), that is, network-level distribution is performed through a corresponding load balancing algorithm provided by the common software load balancing technology.
However, the existing main flow control technologies also have some defects and problems, including:
for the database read-write separation mechanism: the system and the database have high coupling, and under the high-frequency request and high-concurrency scene, the transaction response time and the database performance are obviously reduced, and the I/O pressure of the database is high.
For the distributed caching approach: the cache middleware (e.g., Redis, memcache) may generate avalanche under the conditions of high concurrency, data misoperation, etc., and has high requirement on bandwidth under the conditions of large transaction amount and high concurrency, and a calling party needs additional network overhead when accessing the cache data.
For the existing load balancing technology (such as Linux VirtualServer): the method is mainly responsible for data distribution of a network layer and a host level, and load balance among smaller-granularity service processes cannot be achieved.
Therefore, there is a need to provide a dynamically flexible wind management and load balancing scheme that overcomes the above-mentioned drawbacks.
Disclosure of Invention
The application relates to a local cache processing mode, which is used for providing flexibility of parameter configuration of a wind control rule and expandability of the rule service and realizing plug and play of the rule service; and multi-granularity load balancing according to a service domain, a service host and a service process is realized by using Tuexdo.
According to a first aspect of the present application, there is provided a service wind control system, wherein the service wind control system is built on a Tuxedo architecture, and the service wind control system includes:
a service system configured to receive a service request from a user and forward it to a HAproxy server;
the HAproxy server is configured to distribute the service request to a corresponding wind control system according to a preset distribution rule;
the wind control system in the Tuxedo domain is configured for carrying out wind control service processing according to the received service request; and
a database configured to store business wind control rules and wind control parameters involved in the wind control service;
wherein the wind control system comprises:
the wind control access preposition is configured for analyzing the service request from the service system, converting the service request into an internal message format of the wind control system, and returning a result processed by the wind control processing module to the corresponding service system;
a wind control processing module configured to invoke various wind control services associated with the business wind control type according to the business wind control type determined from the converted business request;
a local cache configured to cache the business wind control rules and wind control parameters of the wind control service.
According to a second aspect of the present application, there is provided a service scheduling method based on Tuxedo architecture, including:
receiving a service request from a user and forwarding the service request to an HAproxy server;
distributing the service request to a corresponding wind control system according to a preset distribution rule;
carrying out wind control service processing according to the received service request; and
returning the result of the processing of the wind control service to the user who makes the service request;
wherein the wind control service processing comprises:
analyzing the service request, and converting the service request into an internal message format of the wind control system;
invoking various wind control services associated with the business wind control type according to the business wind control type determined from the converted business request;
and the business wind control rules and the wind control parameters of the wind control service are cached in a local cache of the wind control system.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Drawings
In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
fig. 1 shows a schematic diagram of the basic architecture of a Tuxedo system.
FIG. 2 illustrates an example environmental block diagram of a Tuxedo architecture based traffic scheduling system according to one embodiment of this application.
FIG. 3 illustrates an example functional block diagram of a wind control system according to one embodiment of this application.
Fig. 4 illustrates an example flow diagram of a Tuxedo architecture based traffic scheduling method according to one embodiment of the present application.
FIG. 5 shows an example flow of a method of refreshing a local cache of a wind control system according to an embodiment of the present application.
Detailed Description
Before formally describing the aspects of the present application, some basic terms referred to in the present application will be explained to facilitate understanding by a skilled person.
HAproxy：
HAProxy is a free and open source software written in C language that provides high availability, load balancing, and TCP and HTTP based application proxies.
HAProxy is particularly well suited for those web sites that are very heavily loaded, which in turn typically require session maintenance or seven-layer processing. HAProxy runs on current hardware and can fully support tens of thousands of concurrent connections. And its mode of operation makes it easy and secure to integrate into your current architecture, while protecting your web server from being exposed to the network.
Tuxedo （Transaction for Unix has been Extended for Distributed Operation）：
I.e., the Unix transactional system after the distributed operation extension. Tuxedo is a client/server "middleware" product that leverages between clients and servers to ensure that transactions are processed correctly.
Tuxedo is a powerful tool for developing and managing three-tier structured client/server type mission critical application systems in a distributed computing environment such as the Internet. It has distributed transaction processing and application communication functions and provides various perfect services to establish, run and manage the mission-critical application system. With which developers can build interoperable application systems across multiple hardware platforms, databases, and operating systems.
The main roles of Tuxedo are: the differences in various communication protocols, hardware architectures, operating systems, databases, other application services and the like in the distributed environment are shielded, so that the unit components of the application program distributed on the network nodes can be interoperated, the consistency and integrity of operation are coordinated, system resources are saved to the maximum extent, and the system performance is improved. Based on these characteristics, Tuxedo has been widely applied to core business systems of various industries such as finance, telecommunications, manufacturing, and the like.
A schematic diagram of the basic architecture of a Tuxedo system is shown in fig. 1. As shown, the basic architecture of Tuxedo can be divided into a typical three-tier architecture of a client tier (presentation tier), a middleware application service tier (business logic tier), and a database server tier (data tier). For Tuxedo middleware that uses Tuxedo protocol, the front-end development tools may be various, such as VC + +, java, Delphi, VB, etc.
Tuxedo DOMAIN (DOMAIN)
A domain is a collection of application systems having the same function or structure. The application system can be composed of a plurality of servers. The domain nature of Tuxedo extends the client/server model to multiple independent autonomous application systems. A domain can be a group of Tuxedo applications or a group of applications running in another non-Tuxedo environment.
Server
A Server is a process that provides one or more services. They constantly check the message queue of service requests and assign them the appropriate service subroutines.
In summary, in the scheme of the application, the three-layer architecture system of Tuxedo is used for configurating the parameter cache of the wind control rule, micro-servitization processing is realized for the rule, multi-domain multi-machine deployment is performed by using Tuxedo, and multi-granularity load balancing according to a service domain, a service host and a service process can be realized. The scheme can be applied to core systems of financial payment transaction, accounting, wind control and the like, so that the flexibility, the concurrency and the stability of the system are improved, and the customer experience is improved.
First, in fig. 2, an example environment block diagram of a Tuxedo architecture based traffic scheduling system according to an embodiment of the present application is shown.
As shown, the business wind system may include a plurality of business systems (210A, 210B, … …, 210N), a HAproxy server 220, wind control systems (230A, 230B, 230C) deployed in one or more Tuxedo domains (three domains are illustrated), and a database 240.
The wind control system can be divided into a wind control access front (232A, 232B, 232C), a wind control processing module (234A, 234B, 234C) and a local cache (236A, 236B, 236C).
The various components/modules may communicate with one another via, for example, wired or wireless communication techniques (e.g., cable, USB, data line, bluetooth, NFC, cellular, local area network, wide area network, and the internet, among others).
Referring to Tuxedo architecture of fig. 1, the multiple business systems (210A, 210B, … …, 210N) therein are deployed at the client layer in fig. 1, the wind control systems (230A, 230B, 230C) are deployed at the middleware application service layer, and the database 240 is deployed at the server layer. The difference from Tuxedo architecture is that the business wind control system additionally provides a HAproxy server 220 between the business system and the wind control system. Therefore, the service wind control system can realize the functional modules by correspondingly configuring and programming each layer of the Tuxedo architecture and the HAproxy server.
In particular, the present solution includes a plurality of external business systems (210A, 210B, … …, 210N) configured to provide different types of business to users (e.g., transactions, balance inquiries, transfers, account information modifications, etc.), receive business requests from users and forward them to the HAproxy server 220.
The HAproxy server 220 is configured to distribute the message to the wind control access preambles of the corresponding wind control systems according to a preset distribution rule, and monitor the system state of each wind control access preamble of each wind control system. The request message distribution to the wind control system is controlled by using the load balancing technology such as HAproxy and the like, so that the load balancing on the network layer is realized.
The preset distribution rules will be detailed in the method part of the scheme.
And the plurality of wind control systems (230A, 230B and 230C) positioned in the plurality of domains are mainly responsible for carrying out wind control service processing according to the message of the service request. Specifically, the wind control system relates to the field of processing various business risk rule checking works and performing in-process and after-process risk control and early warning works of business.
Specifically, in fig. 3, an example functional block diagram of a wind control system according to an embodiment of the present application is shown. As shown, the wind control system may include the following functions: the system comprises a wind control access service, a message analysis processing service, a wind control rule scheduling service and a cache management service.
The wind control access service and the message analysis processing service are realized by the wind control access preposition of the wind control system. Specifically, the wind-controlled access preamble receives various types of service requests (e.g., request messages in the form of TCP/IP) from the service system from the HAproxy server 220. The received service request is then parsed, which may include decrypting the encrypted content in the request and converting it into a message format internal to the wind control system. The converted request message is then forwarded to a wind control processing module for subsequent processing. And the wind control access front-end is further configured to return the wind control result (for example, in the form of a response message) processed by the wind control processing module to the corresponding service system.
Subsequently, the wind control processing module executes the wind control rule scheduling service, namely, according to the corresponding service wind control type (such as a service type code) in the converted request message received from the wind control access preamble, the wind control type of the service to be requested is determined, and various wind control services related to the service wind control type are called based on the determined service wind control type.
As shown in fig. 3, the wind control rule scheduling service may provide one or more of the following wind control services according to the requested traffic type: black and white list checking service, authority checking service, quota checking service and other services. The wind control rule scheduling service component may schedule one or more of the wind control services according to different traffic wind control types. These wind control services are only example services given for illustration purposes, and it will be understood by those skilled in the art that the wind control services may also include more or less services, such as encompassing all the wind control services involved in various wind control traffic types.
Each of the wind control services has its corresponding wind control rule and rule parameter to implement a wind control operation, for example, the black and white list check service may confirm the identity of the user according to the black list and/or white list data and the corresponding list matching rule and matching parameter (e.g., user name, mobile phone, identification number, etc.). Therefore, once the blacklist and whitelist checking service is called by the wind control rule scheduling service, the operation of confirming whether the user requesting the service belongs to the blacklist/whitelist of the wind control can be realized.
In addition, in order to improve the response time and the concurrency performance of the system service, a memory cache (stored in the memory of the server, namely, a local cache) can be locally applied to the wind control system for all service groups to access, and the business rule parameters and the business risk rule control flow are loaded into the local cache. Because the wind control configuration data is stable, the data volume is small, and the operations such as updating and the like cannot be frequently performed, the pressure of the database can be greatly reduced by using the local cache, the response speed of query configuration is improved, the high-frequency access pressure of the database can be released, and the network overhead of accessing the cache middleware is removed.
And the cache management service is mainly configured to refresh some related latest data stored in the database 240 into a local cache of each wind control system for the wind control service to call.
A database 240 configured to (remotely) store the traffic wind control rules and wind control parameters involved in the wind control service. The traffic wind control rules and wind control parameters are stored, for example, in the form of a table. And the business wind control rules and the wind control parameters can be stored in a classified mode according to different business wind control types. That is, the wind control service rules and the service rule parameter groups related to the same wind control service type are stored together. In this way, the wind-controlled business rules and business rule parameters associated with the user-requested business wind control type can be called in an organized manner according to the business wind control type, and the rules and parameters related to the wind control type do not need to be retrieved each time.
Once the wind control personnel dynamically modify the business wind control rules and/or business rule parameters in the database (module or server) 240, the modifications can be refreshed into the local cache through the cache management service, so that the wind control rule scheduling service can adjust the risk rule service of the corresponding business in real time.
In addition, as shown in fig. 2 and 3, the wind control system may adopt multi-domain distributed deployment, that is, each domain is configured with multiple host nodes, and each service may be provided by multiple Server processes, so as to perform multi-dimensional load balancing according to the host and the service processes in real time. It should be understood that although only three domains and the wind control systems deployed thereon are shown in fig. 2, in practical applications, the number of domains and wind control systems may be adjusted according to the needs of the service, for example, far more than 3.
An example flow chart of a service scheduling method based on Tuxedo architecture according to an embodiment of the present application is described below with reference to fig. 4 in combination with the above example architecture of the service scheduling system.
As shown in the figure, in step 402, the user inputs a corresponding service request in the service system according to his service requirement.
As previously mentioned, the business system provides various business applications for use by users. The service request may include various data related to the service, such as institution number, merchant number, order amount, target routing, transaction code, and other necessary parameters. The service request may come from various applications running on the user-side system, such as e-commerce software, banking websites, gaming applications, payment terminal applications, and so forth. Alternatively, the service request may come from various APPs installed on the mobile terminal, such as a mobile phone or a tablet. The service request may be sent to the HAproxy server in the form of a data message via, for example, an http communication protocol, such as a TCP/IP request.
At step 404, the service request is distributed to the wind control access preambles of the corresponding wind control systems according to preset distribution rules.
As described above, the service wind control system of the present solution adopts the HAproxy technology to implement load balancing at a network level. Specifically, a service wind control system generally includes a plurality of Tuxedo domains, and each domain includes its own wind control system. And each wind control system has a respective wind control access preposition. Therefore, the HAproxy server can continuously monitor the system state of each wind control access preposition of each wind control system so as to adjust the distribution rule. And after receiving a service request from a service system, sending the service request to a wind control access front end in a corresponding domain according to a preset distribution rule.
For example, a predetermined distribution rule ratio may be set for each of the wind control systems. For example, as shown in fig. 2, assume that there are three wind-controlled access preambles 232A, 232B, 232C distributed over three different domains. If all the wind control access prepositive states are normal, the service process of distributing the service request message in the HAproxy server distributes the service request message to each prepositive host according to the proportion of a preset rule M: N: K, wherein the wind control access prepositive 232A accounts for M proportion, the wind control access prepositive 232B accounts for N proportion, the wind control access prepositive 232C accounts for K proportion, and M + N + K =100, as shown in Table 1.
That is, if the HAproxy server receives 10 service requests, assuming that M: N: K is 30:20:50, the HAproxy server forwards 3 of the service requests to the wind-controlled access preamble 232A, 2 of the service requests to the wind-controlled access preamble 232B, and the remaining 5 service requests to the wind-controlled access preamble 232C. The ratio of M to N to K may be predetermined based on the processing power of the wind control systems in the three domains. Under the condition that the network conditions are approximately the same, the wind control system with stronger processing capacity occupies larger proportion weight.
And if the state of a certain wind control access preposition is abnormal, the HAproxy server disconnects the connection with the wind control access preposition, so that the follow-up request is not distributed to the wind control access preposition any more. For example, if the monitor of the HAproxy server detects that the system failure status of a certain wind control access preamble (e.g. 232A) is abnormal, the distribution rule may be adjusted in real time, for example, according to [ N + M × N/(N + K) ]: and the [ K + M K/(N + K) ] is distributed to other wind control access prepositions 232B and 232C hosts which work normally, and the failed wind control access preposition 232A is not forwarded with messages any more, so that the dynamic load balance of the network layer is realized.
In addition to the proportionally weighted distribution rules, the distribution rules also support specified IP forwarding. For example, a request message from IP1 (which may be an IP address range) should be forwarded to the gated access preamble 232A, a request message from IP2 should be forwarded to the gated access preamble 232B, and a request message from IP3 should be forwarded to the gated access preamble 232C. The address ranges of IP1, IP2, and IP3 collectively should cover the IP addresses of all the service systems.
In other embodiments, the distribution rules may also be adjusted in consideration of the network quality of the wind control systems of the respective domains, and if the network environment of the respective hosts is normal, the distribution rules are distributed according to a predefined proportional weight; when the host network of a certain domain is detected to be abnormal, the proportion weight can be adjusted in real time.
These distribution rules are only examples, and the skilled person can set other distribution rules according to actual needs.
At step 406, after the wind control access preamble receives the service request message, the service request message is parsed, where the parsing includes decrypting the message (for personal privacy and security, the service request is typically encrypted) and converting it into an internal message format that can be processed by the wind control system.
At step 408, the wind control processing module determines a corresponding service wind control type from the converted service request message (e.g., by parsing and identifying a service type code in the request), and invokes various wind control services associated with the service wind control type based on the determined service wind control type. For example, the corresponding wind control services may be sequentially invoked according to the wind control rules corresponding to different service codes in the service request message.
As shown in fig. 3, example wind services may include a black and white list check service, a rights check service, a quota check service … …. Each of the wind control services has its corresponding wind control rules and rule parameters to implement a wind control operation. These wind control services are common services in wind control systems and therefore they will not be described in detail here.
How to implement the above-described steps of the wind control processing module is explained below by referring to example program code, wherein rsk1.ubb of the wind control system rsk1 is configured as follows:
from the above configuration, it can be appreciated that there are 2 hosts, each of which is configured with 5 processes to provide services. Thus, when each host receives a black and white list check request, for example, it will load balance to 5 processes to execute.
The rsk1.dom domain configuration of the wind control system rsk1 is as follows:
configuring in the domain configuration file of the calling party by:
the request load can be balanced to site1 and site2 hosts of the rsk1 domain, and the load balance among 5 processes of each host served by the BLACK _ CHK _ SVC is realized through the above rsk1.ubb configuration at the service process level.
Specifically, when each host receives a request for invoking a wind-controlled service (e.g., a black-and-white list check request), the request may be placed in a message queue, and then, the process Server corresponding to the service starts multiple instances to read request messages from the same queue to complete service processing. By using the message queue mechanism to complete the concurrent processing of the service request, each audit service load can be balanced to 5 processes to execute.
And in the service calling process, if the network interruption of the first domain is found, the wind control processing module automatically sends the request to the second backup domain, so that the high-efficiency fault tolerance is realized.
After the processing of the invoked wind-controlled service associated with the requested service type is completed, at step 410, the wind-controlled processing module returns the processing result (i.e., the reply message) to the service system that made the service request through the wind-controlled access preamble.
As previously described, to improve system service response time and concurrency performance, a local cache (236A, 236B, 236C) is also provided in the wind control system for locally storing wind control rules and wind control parameters for the wind control service. In a conventional business wind control system, wind control rules and wind control parameters are generally stored in a separate database to facilitate updating and maintenance. However, if there are a large number of concurrent wind control requests (e.g., the zero promotion period of the double eleven shopping festival), temporarily retrieving and invoking the corresponding wind control rules and wind control parameters from the database will obviously significantly reduce the processing capacity of the business wind control system, resulting in the request processing having to be delayed or even erroneous. Therefore, the key high-frequency core data is subjected to local caching, so that the access pressure of the database can be released, and the network overhead of accessing the cache middleware can be removed. However, the local cache mechanism also has its own drawbacks, that is, after the wind control rule or the wind control parameter at the database is adjusted, how to simultaneously refresh the corresponding data in the local cache of the wind control system is a big problem.
To this end, an example flow of a method of refreshing a local cache of a wind control system according to one embodiment of the present application is shown in fig. 5.
As shown, first, at step 502, the wind controlled platform may receive a modification request from, for example, a wind controller personnel to modify a wind control rule and/or a wind control parameter.
Subsequently, at step 504, the wind control platform modifies the corresponding wind control rules and/or wind control parameters stored at the database 240 accordingly according to the modification request.
Next, at step 506, the wind control platform sends a cache data update notification to the cache management services of all the wind control systems. The notification comprises modification data of the involved wind control rules and/or wind control parameters.
At step 508, the cache management service at each of the wind control systems updates the corresponding data in its local cache according to the received cache data update notification.
For example, the wind control rule structure may be defined as follows:
as shown above, each wind control rule has a rule ID number and corresponds to a wind control service; each service type corresponds to a wind control rule list, and the list comprises a plurality of service checking rules. When a certain wind control rule of a service is added or deleted on the wind control platform, each wind control system can immediately update the service wind control rule list in the local cache of the wind control system, and the subsequent request wind control rule scheduling service of the service can call the corresponding wind control service according to the latest service wind control rule list in the cache.
In addition, the scheme of the application can also realize load balancing of the service level. Specifically, a plurality of corresponding servers can be deployed at the same time when the wind control service with balanced load needs to be performed, each Server has an independent response queue, but the plurality of servers access the same request queue. Thus, after a certain Server takes the request message from the request queue, the corresponding logic processing is completed, and the processing result is returned to the service calling party through the self independent response queue of the Server. The message queue can be used for realizing concurrent execution of the wind control service on a plurality of servers and a plurality of processes of the servers, thereby realizing the load balance of the service level.
In some embodiments, if the external business system is a Tuxedo application, the front of the wind control access can be directly skipped, and the wind control service issued by the wind control system can be directly called through the service.
To sum up, the scheme of the present application provides a service wind control method and system based on Tuxedo architecture and capable of implementing dynamic customized wind control service and multi-granularity load balancing, and can provide the following advantages:
1) the key high-frequency core data is cached and processed locally, and each business risk rule micro-service supports dynamic adjustment and configuration, so that plug and play are really realized, the business risk monitoring is flexible and convenient, the network overhead of calling other cache middleware by application is reduced, and meanwhile, the system performance and the concurrency are greatly improved.
2) By utilizing the distributed deployment capability of the Tuxedo, the multi-granularity load balance and fault tolerance of the service system in networks, hosts, service processes and the like are realized, the stability of the system is greatly improved, and the real service capability of 7 × 24 hours is realized.
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Persons skilled in the relevant art(s) will recognize that various changes may be made in form and detail without departing from the spirit and scope of the invention, as defined by the appended claims. Thus, the breadth and scope of the present invention disclosed herein should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
Claims (10)
1. A service gating system, wherein the service gating system is built on a Tuxedo architecture, the service gating system comprising:
a service system configured to receive a service request from a user and forward it to a HAproxy server;
the HAproxy server is configured to distribute the service request to a corresponding wind control system according to a preset distribution rule;
the wind control system in the Tuxedo domain is configured for carrying out wind control service processing according to the received service request; and
a database configured to store business wind control rules and wind control parameters involved in the wind control service;
wherein the wind control system comprises:
the wind control access preposition is configured for analyzing the service request from the service system, converting the service request into an internal message format of the wind control system, and returning a result processed by the wind control processing module to the corresponding service system;
a wind control processing module configured to invoke various wind control services associated with the business wind control type according to the business wind control type determined from the converted business request;
a local cache configured to cache the business wind control rules and wind control parameters of the wind control service.
2. The business wind system of claim 1, wherein the business wind system comprises a plurality of Tuxedo domains and their associated wind systems, and the HAproxy server distributes the business requests to the respective wind systems based on the following distribution rules:
according to a preset rule proportion set for each wind control system;
appointing IP to forward;
according to the network quality of each wind control system; and
other distribution rules.
3. The business wind control system of claim 2, wherein the HAproxy server is further configured to monitor a system state of each wind control access preamble of each wind control system and adjust the predetermined rule proportion in real time according to the system state of each wind control access preamble.
4. The business wind system of claim 1, wherein the wind system is further configured to provide cache management services to flush the latest data held in the database into the local cache.
5. The traffic wind system according to claim 1, wherein said wind processing module can provide one or more of the following wind services depending on the type of traffic requested: black and white list checking service, authority checking service, quota checking service and other services.
6. The business system of claim 1, wherein the business system is deployed at a client tier of the Tuxedo architecture, the wind control system is deployed at a middleware application service tier of the Tuxedo architecture, and the database is deployed at a server tier of the Tuxedo architecture.
7. The business wind system of claim 1, wherein multiple corresponding servers are deployed simultaneously for the wind service, each Server having its own independent response queue, but the multiple servers accessing the same request queue.
8. The service hosting system of claim 1, wherein if the service system is a Tuxedo application, the service hosting service published by the service hosting system is invoked directly by a service, skipping the service access preamble.
9. A business wind control method based on a Tuxedo architecture comprises the following steps:
receiving a service request from a user and forwarding the service request to an HAproxy server;
distributing the service request to a corresponding wind control system according to a preset distribution rule;
carrying out wind control service processing according to the received service request; and
returning the result of the processing of the wind control service to the user who makes the service request;
wherein the wind control service processing comprises:
analyzing the service request, and converting the service request into an internal message format of the wind control system;
invoking various wind control services associated with the business wind control type according to the business wind control type determined from the converted business request;
and the business wind control rules and the wind control parameters of the wind control service are cached in a local cache of the wind control system.
10. The traffic-scheduling method of claim 9, further comprising:
receiving a modification request from a wind control worker for modifying the business wind control rule and/or the wind control parameter;
correspondingly modifying the corresponding business wind control rules and/or wind control parameters stored in the database according to the modification request;
sending a cache data updating notification to cache management services of all the wind control systems, wherein the cache data updating notification comprises modification data of related business wind control rules and/or wind control parameters; and
the cache management service at each wind control system updates the corresponding data in its local cache according to the received cache data update notification.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210807577.8A CN114884964A (en) | 2022-07-11 | 2022-07-11 | Service wind control method and system based on Tuxedo architecture |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210807577.8A CN114884964A (en) | 2022-07-11 | 2022-07-11 | Service wind control method and system based on Tuxedo architecture |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114884964A true CN114884964A (en) | 2022-08-09 |
Family
ID=82683175
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210807577.8A Pending CN114884964A (en) | 2022-07-11 | 2022-07-11 | Service wind control method and system based on Tuxedo architecture |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114884964A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116664138A (en) * | 2023-07-21 | 2023-08-29 | 上海富友支付服务股份有限公司 | Wind control method and system based on dynamic control in third party payment |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001285266A (en) * | 2000-03-30 | 2001-10-12 | Nec Corp | Digital phase control circuit |
| US20030025539A1 (en) * | 2001-07-31 | 2003-02-06 | Cypress Semiconductor Corp. | Digitally controlled analog delay locked loop (DLL) |
| EP1708425A1 (en) * | 2005-03-31 | 2006-10-04 | Matsushita Electric Industrial Co., Ltd. | Tunnelling of multicast data |
| DE502004011378D1 (en) * | 2003-03-20 | 2010-08-26 | Siemens Ag | Method and jitter buffer control circuit for controlling a jitter buffer |
| CN103825830A (en) * | 2014-02-24 | 2014-05-28 | 北京南天软件有限公司 | Method and device for system to achieve flow control based on TUXEDO middleware |
| CN111311136A (en) * | 2020-05-14 | 2020-06-19 | 深圳索信达数据技术有限公司 | Wind control decision method, computer equipment and storage medium |
| CN112581045A (en) * | 2021-02-25 | 2021-03-30 | 上海富友支付服务股份有限公司 | Data wind control system and method based on micro-service |
| CN113568604A (en) * | 2021-09-26 | 2021-10-29 | 深圳万顺叫车云信息技术有限公司 | Method and device for updating wind control strategy and computer readable storage medium |
| CN114186874A (en) * | 2021-12-14 | 2022-03-15 | 平安付科技服务有限公司 | Flow playback-based wind control strategy configuration method, device, equipment and medium |
-
2022
- 2022-07-11 CN CN202210807577.8A patent/CN114884964A/en active Pending
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001285266A (en) * | 2000-03-30 | 2001-10-12 | Nec Corp | Digital phase control circuit |
| US20030025539A1 (en) * | 2001-07-31 | 2003-02-06 | Cypress Semiconductor Corp. | Digitally controlled analog delay locked loop (DLL) |
| DE502004011378D1 (en) * | 2003-03-20 | 2010-08-26 | Siemens Ag | Method and jitter buffer control circuit for controlling a jitter buffer |
| EP1708425A1 (en) * | 2005-03-31 | 2006-10-04 | Matsushita Electric Industrial Co., Ltd. | Tunnelling of multicast data |
| CN103825830A (en) * | 2014-02-24 | 2014-05-28 | 北京南天软件有限公司 | Method and device for system to achieve flow control based on TUXEDO middleware |
| CN111311136A (en) * | 2020-05-14 | 2020-06-19 | 深圳索信达数据技术有限公司 | Wind control decision method, computer equipment and storage medium |
| CN112581045A (en) * | 2021-02-25 | 2021-03-30 | 上海富友支付服务股份有限公司 | Data wind control system and method based on micro-service |
| CN113568604A (en) * | 2021-09-26 | 2021-10-29 | 深圳万顺叫车云信息技术有限公司 | Method and device for updating wind control strategy and computer readable storage medium |
| CN114186874A (en) * | 2021-12-14 | 2022-03-15 | 平安付科技服务有限公司 | Flow playback-based wind control strategy configuration method, device, equipment and medium |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116664138A (en) * | 2023-07-21 | 2023-08-29 | 上海富友支付服务股份有限公司 | Wind control method and system based on dynamic control in third party payment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7426737B2 (en) | Method and apparatus for operating an open API network having a proxy | |
| RU2436148C2 (en) | Adaptive gateway for switching transactions and data on untrusted networks using context-based rules | |
| KR101311978B1 (en) | Schema-based dynamic parse/build engine for parsing multi-format messages | |
| CN111290865A (en) | Service calling method and device, electronic equipment and storage medium | |
| CN112804722A (en) | Method for realizing micro-service gateway dynamic routing | |
| US20040249926A1 (en) | System and methd for common information model object manager proxy interface and management | |
| CN112612629A (en) | Method and system for realizing component type data interface | |
| US20070038762A1 (en) | Secure gateway with proxy service capability servers for service level agreement checking | |
| CN113595925A (en) | Intelligent gateway dynamic current limiting implementation method | |
| CN115695139A (en) | Method for enhancing micro-service system architecture based on distributed robust | |
| CN109117609A (en) | A kind of request hold-up interception method and device | |
| CN113110975A (en) | Data access method, device, equipment and medium | |
| CN114884964A (en) | Service wind control method and system based on Tuxedo architecture | |
| CN112565340B (en) | Service scheduling method, device, computer system and medium for distributed application | |
| CN115516842A (en) | Orchestration broker service | |
| KR20200094404A (en) | System for retirement pension and method for financial services providing using the same | |
| CN112994894B (en) | Gateway-based single-thread request processing method and information verification AGENT | |
| CN117390068A (en) | Data query method, device, equipment and storage medium |
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 | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20220809 |