CN113630310A - Distributed high-availability gateway system - Google Patents
Distributed high-availability gateway system Download PDFInfo
- Publication number
- CN113630310A CN113630310A CN202010371589.1A CN202010371589A CN113630310A CN 113630310 A CN113630310 A CN 113630310A CN 202010371589 A CN202010371589 A CN 202010371589A CN 113630310 A CN113630310 A CN 113630310A
- Authority
- CN
- China
- Prior art keywords
- service
- request
- interface
- service request
- unit
- 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
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
-
- 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/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
-
- 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/08—Protocols for interworking; Protocol conversion
Abstract
The invention discloses a distributed high-availability gateway system, which comprises a background management subsystem and a core subsystem; the core subsystem receives a service request from a service request end and routes the service request to a back-end service interface; the core subsystem comprises a safety control component, a request checking component, a data acquisition component and a result aggregation component; the safety control component is used for carrying out safety verification, current limitation and anti-brushing on the service request; the request checking component is used for acquiring service request parameters; the data acquisition component is used for routing the service request to a back-end service interface; the structure aggregation component is used for aggregating results from the service end and returning the results to the service request end; the background management subsystem and the core subsystem are both realized by adopting a distributed system.
Description
Technical Field
The invention belongs to a distributed micro-service gateway system, and particularly relates to a distributed high-availability gateway system.
Background
In the micro-service architecture style, a large application is split into a plurality of small service systems, which can be self-organized, that is, the small systems can own their own database, framework, even language, etc., and the small systems are usually called by H5, Android, IOS and third-party applications with interfaces providing the Rest Api style.
However, when the data is presented on the UI, it is usually necessary to present many data on one interface, and these data may come from different microservices, for example: in an e-commerce system, look at a product detail page containing product title, price, inventory, comments, etc., which may be located in different microservices systems for the backend, it may be that my backend system splits my services by:
product service-is responsible for providing the title, description, specifications, etc. of the goods.
Price service-responsible for pricing products, price strategy calculation, promotional prices, etc.
Inventory service-is responsible for product inventory.
Rating service-is responsible for user reviews, replies, etc. on the goods.
Now, the commodity detail page needs to pull corresponding information from these micro-services, but because of the service system architecture we use, there is no way to rely on join query of database to get the final result like traditional monolithic application, how can each service be accessed? According to the guiding principle of micro-service design, the micro-service may have the following problems:
the service uses multiple protocols because different protocols have different application scenarios, such as HTTP, AMQP, gRPC, etc. may be used simultaneously. Additionally the division of services may change over time and the instances of services or Host + ports may change dynamically. Then, the UI requirements for the front end may also be several: coarse-grained APIs, while fine-grained APIs typically provided by micro-services, may require many calls for the UI if a fine-grained API is to be called, which is a matter of course. Different client devices may need different data, such as Web, H5, APP, etc., and also the network capabilities of different devices, for multiple apis, the server to which this access needs to be transferred will be much faster, and discrete microservices are difficult to meet these requirements.
To solve these problems, API gateway technology is being developed and applied, and the API gateway provides these general functions for the microservice, which makes the microservice focus on its own domain and well isolates the service caller and the service provider. For example, kong API Gateway (which may be considered an OpenResty application) developed based on nginx, implemented with the lua-nginx module, the bottom layer uses Apache Cassandra or PostgreSQL databases. Developers can conveniently add defined plug-ins, and even can develop and use plug-ins by themselves to achieve the functions of agent, load balancing, health check, logging and the like.
However, the existing API gateway functions are not perfect, and particularly, in the prior art, the external API gateway product is used to store the call relationship chain data in the database of the corresponding product; in addition, the user-defined aggregation of a plurality of interface results is not met; access of an intranet interface is not supported; does not support protocol conversion, etc., and is very inconvenient to use.
Disclosure of Invention
In order to solve the problem that the existing API gateway is not perfect in function, particularly in the prior art, calling relation chain data needs to be stored in a database of a corresponding product when an external API gateway product is used; in addition, the user-defined aggregation of a plurality of interface results is not met; access of an intranet interface is not supported; the conversion of protocols is not supported, and the use is very inconvenient. The distributed high-availability gateway system is provided, protocol conversion is supported, deployment is convenient and flexible, and access is efficient and flexible.
In order to achieve the technical effect, the invention adopts the following technical scheme.
A distributed high-availability gateway system comprises a background management subsystem and a core subsystem; the core subsystem receives a service request from a service request end and routes the service request to a back-end service interface; the core subsystem comprises a safety control component, a request checking component, a data acquisition component and a result aggregation component;
the safety control component is used for carrying out safety verification, current limitation and anti-brushing on the service request;
the request checking component is used for acquiring service request parameters;
the data acquisition component is used for routing the service request to a back-end service interface;
the structure aggregation component is used for aggregating results from the service end and returning the results to the service request end;
the background management subsystem and the core subsystem are both realized by adopting a distributed system.
In addition, the request checking component processes and checks the service request in a pipeline chain mode, each of a plurality of processing logics of the service request is regarded as a pipeline, each pipeline is executed in sequence according to a preset sequence, a processed or checked result is delivered to the next pipeline, and the sequence of the pipeline chain is adjusted along with the flow sequence of the service request.
In addition, the request verification component obtains the user information carried by the service request by one or more of the following three ways: a, acquiring a cookie value of an application, B, acquiring a cookie value designated by single sign-on, and C, acquiring a value of a preset position in request header information; and after the request checking component acquires the user information, the authentication and the certification related to the service request are carried out.
In addition, the safety control assembly includes a primary current limiting unit and a secondary current limiting unit, wherein,
the primary current limiting unit is arranged in a Nginx server, the Nginx server receives and forwards a service request, the primary current limiting unit limits the access amount of a single service request address in unit time, and when the access amount of the single service request address in unit time is larger than a preset threshold value, the primary current limiting unit does not forward the service request;
the secondary current limiting unit records the detail data of each forwarded service request by using an interceptor, caches the detail data by using a redis, and then acquires the allowed access amount of the same address in unit time and the allowed access total amount in unit time, which are set in a configuration system; calculating the single address access amount in unit time and the total request access amount in unit time; when the single address access amount in unit time exceeds the access amount allowed by the same address in unit time or the total requested access amount in unit time exceeds the total requested access amount allowed in unit time, the secondary current limiting unit blocks the service request from the address or blocks all the service requests until the single address access amount in unit time after recalculation is less than the access amount allowed by the same address in unit time or the total requested access amount in unit time is less than the total requested access amount allowed in unit time.
In addition, the core subsystem processes the plurality of service requests in an asynchronous mode, when each service request in the plurality of service requests reaches the core subsystem, the thread corresponding to the Nginx server of the core subsystem directly returns, then the thread corresponding to other components in the core subsystem is used for executing the relevant operation of the service request, and when the service request has a result returned, the request result is returned to the service request end.
In addition, the background management subsystem comprises an interface management unit and an interface release unit, wherein the interface management unit is used for inquiring, newly adding, modifying and offline relevant configuration of a rear-end service interface; the interface issuing unit is used for receiving an audit instruction of an administrator for newly adding or modifying the back-end service interface and transmitting the audit instruction to the interface management unit; the interface management unit stores the back-end service interface information in a local database, and issues a back-end service interface updating mark to a core subsystem through a distributed service system, and after the core subsystem subscribes the mark issued by the system for issuing the back-end service interface updating, the updated back-end service interface information is pulled from a background management subsystem.
In addition, the data acquisition component of the core subsystem comprises a protocol conversion unit, and the protocol conversion unit is used for realizing coordination between a protocol followed by the service request and a protocol followed by the service of the service system; the protocol conversion unit realizes the conversion from the Dubbo protocol to the hypertext transmission protocol in a generalization calling mode, and converts the Dubbo protocol to the hypertext transmission protocol into a common language so as to realize mutual conversion; and the conversion from the hypertext transfer protocol to the Dubbo protocol is realized by utilizing an Apache extensible interactive system.
In addition, the core subsystem executes a plurality of back-end service interface requests in parallel in a thread pool mode, the back-end service interface requests are organized in the thread pool mode, when the service requests are routed to one or a plurality of back-end service interfaces, the core subsystem executes the one or the plurality of back-end service interface requests in parallel through the thread pool so as to reduce the routing time from the service requests to the back-end service interfaces when the back-end service interface requests exist, when the back-end service interface requests are completed, the threads are released to the thread pool to be conveniently recycled in the next request, and the routing is performed by using an Okhttp3 client lightweight framework;
in addition, the core subsystem also monitors the request state and the request duration of each back-end service interface simultaneously, generates early warning information about the back-end service interface request according to the monitoring result, and sends the early warning information about the back-end service interface request to the back-end management system through rabbitmq.
In addition, when a service request end needs to call data from a plurality of service ends together, the service request end sends a single service request to a core subsystem, the core subsystem disassembles and routes the service request to a plurality of different back-end service interfaces, and aggregates results from the plurality of different back-end service interfaces and returns the aggregated results to the service request end, and the result aggregation is performed in a JavaScript and groovy engine mode.
In particular, the background management subsystem further comprises,
a group management unit: the system comprises a back-end service interface, a group management module and a service management module, wherein the back-end service interface is used for managing a back-end service interface in a group mode, and the management comprises group inquiry, addition and modification;
a recycle bin unit: the back-end service interface is used for storing the offline back-end service interface of the interface management unit and restoring and deleting the offline back-end service interface according to the interface management unit;
an application authorization unit: for configuring backend service interfaces to be accessible by those applications;
a document management unit: the method is used for generating and displaying the relevant documents of the back-end service interface;
software development kit unit: the system is used for generating a uniform tool kit for other systems to introduce;
an interface test unit: the system is used for supporting the configured back-end service interface on-line test;
a log statistic unit: the system is used for counting the calling frequency, calling source and calling time of the back-end service interface and outputting a report of the back-end service interface;
a monitoring and early warning unit: the method is used for providing early warning notification of multiple ways for the backend service interface with failed calling or poor performance.
Drawings
Fig. 1 is a schematic structural diagram of a distributed high availability gateway system according to an embodiment of the present invention.
Fig. 2 is a schematic structural diagram of a core subsystem of a distributed high availability gateway system according to an embodiment of the present invention.
Fig. 3 is a schematic partial structural diagram of a core subsystem of a distributed high availability gateway system according to an embodiment of the present invention.
Detailed Description
The present invention will be described in detail below with reference to the accompanying drawings.
Detailed exemplary embodiments are disclosed below. However, specific structural and functional details disclosed herein are merely for purposes of describing example embodiments.
It should be understood, however, that the intention is not to limit the invention to the particular exemplary embodiments disclosed, but to cover all modifications, equivalents, and alternatives falling within the scope of the disclosure. Like reference numerals refer to like elements throughout the description of the figures.
Referring to the drawings, the structures, ratios, sizes, and the like shown in the drawings are only used for matching the disclosure of the present disclosure, so as to be understood and read by those skilled in the art, and are not used to limit the conditions that the present disclosure can be implemented, so that the present disclosure has no technical significance, and any structural modification, ratio relationship change, or size adjustment should still fall within the scope of the disclosure of the present disclosure without affecting the efficacy and the achievable purpose of the present disclosure. Meanwhile, the positional limitation terms used in the present specification are for clarity of description only, and are not intended to limit the scope of the present invention, and changes or modifications of the relative relationship therebetween may be regarded as the scope of the present invention without substantial changes in the technical content.
It will also be understood that the term "and/or" as used herein includes any and all combinations of one or more of the associated listed items. It will be further understood that when an element or unit is referred to as being "connected" or "coupled" to another element or unit, it can be directly connected or coupled to the other element or unit or intervening elements or units may also be present. Moreover, other words used to describe the relationship between components or elements should be understood in the same manner (e.g., "between" versus "directly between," "adjacent" versus "directly adjacent," etc.).
Fig. 1 is a schematic structural diagram of a distributed high availability gateway system according to an embodiment of the present invention. As shown in the figure, the invention discloses a distributed high-availability gateway system, which comprises a background management subsystem and a core subsystem; the core subsystem receives a service request from a service request end and routes the service request to a back-end service interface; the core subsystem comprises a safety control component, a request checking component, a data acquisition component and a result aggregation component;
the safety control component is used for limiting the current and preventing the brushing of the service request;
the request checking component is used for acquiring service request parameters;
the data acquisition component is used for routing the service request to a back-end service interface;
the structure aggregation component is used for aggregating results from the service end and returning the results to the service request end;
the background management subsystem and the core subsystem are both realized by adopting a distributed system.
In the invention, the gateway is designed into a background management subsystem and a core subsystem which are separated in function, and the background management subsystem and the core subsystem are both realized by adopting a distributed system, so that the technical effects that: firstly, the core subsystem does not directly access the server, so that the requests of the internal network and the external network and other external platform can be distinguished, the request addresses of the internal network and the external network are distinguished, the later expansion is convenient, for example, the interface address for prohibiting the external network from accessing the internal network is set through nginx, and meanwhile, the back-end verification is carried out on the server, so that the data security of the server can be ensured. Secondly, the distributed high-availability gateway system is beneficial to realizing functional upgrading, adopts a modular structure, adopts standard software interfaces for connection among modules, and can conveniently upgrade the functional components of the gateway system without the transformation of a whole gateway.
Especially for a background management subsystem, the system is overlapped with a functional module in the prior art, and the system also improves the functions of flow control, asynchronous processing request of pipeline chains, result aggregation and the like in the aspect of a core subsystem, so that the system can realize exchange with some existing gateway products or even replace the existing gateway products by adopting a modular design.
In the invention, the background management subsystem and the core subsystem are realized by using a distributed architecture, the processing capability and the cache function of the distributed system can be effectively utilized, and the response speed and the processing capability of the distributed high-availability gateway system are further improved.
Particularly, in the specific embodiment of the invention, the front end of the background management subsystem uses act to show a view, the back end uses spring mvc to provide a rest data interface for the front end, uses Rabbitmq to receive the early warning information of the back-end service interface, uses a service discovery tool zookeeper to send a cache update event, and uses a database Mysql to store the data of the back-end service interface. The back end of the core subsystem uses spring mvc to provide a rest data interface for the front end, uses a cafneine high-performance cache and a Redis distributed cache as caches and interface data acquisition sources, uses a service discovery tool zookeeper to update back-end service interface data in a local cache in real time, uses Rabbitmq to receive interface early warning information, and uses Okhttp3 to perform route forwarding, and the specific implementation modes are respectively described below.
Fig. 2 is a schematic structural diagram of a core subsystem of a distributed high availability gateway system according to an embodiment of the present invention. As shown in fig. 2, in a specific embodiment of the present invention, the request checking component processes and checks the service request in a pipeline chain manner, each of a plurality of processing logics of the service request is regarded as a pipeline, each pipeline is executed in sequence according to a preset sequence, a result after processing or checking is delivered to a next pipeline, and the sequence of the pipeline chain is adjusted according to a flow sequence of the service request.
In a specific embodiment of the invention, the request checking component processes and checks the service request in a pipeline chain manner, the processing and checking (parameter checking, authentication and authentication) of the request parameters are composed of Pipe chains, each Pipe is responsible for one function, the technical scheme is that the Pipe chains are sequentially executed by using a responsibility chain mode, and the realization corresponding to each Pipe chain is executed by using a strategy mode. A Chain of responsibilities mode, Chain of responsibilities (CoR) mode, also called Chain of responsibilities mode or Chain of responsibilities mode, is one of the behavior modes, which constructs a series of objects of classes respectively serving as different responsibilities to jointly complete a task, and the objects of the classes are closely connected like a Chain, and thus called Chain of responsibilities mode.
The advantage of the chain of responsibility mode is the sharing of responsibility. Each class only needs to process the work of the process (the process is not transmitted to the next object to be completed), the responsibility range of each object is defined, the minimum packaging principle of the object is met, and each object can perform its own job; and the workflows can be freely combined as required. If the workflow changes, the new workflow can be adapted by reallocating the object chain. The flows can be freely combined. Under the responsibility chain mode, each Pipe is executed in sequence according to a preset sequence, and the subsequent addition of new processing logic becomes simple, such as: and the parameter verification- > identity authentication- > … … is sequentially carried out.
In particular, in the embodiments of the present invention, the sequence of the pipe chain is adjusted according to the flow sequence of the service request, which is beneficial to the adjustment and improvement of the gateway system and the implementation of the customized service request and the customized service.
Further, for each Pipe, a policy mode is used for specific processing and checking, the Strategy mode is also called a policy mode, is one of behavior modes, encapsulates a series of algorithms, defines an abstract algorithm interface for all algorithms, encapsulates and implements all algorithms by inheriting the abstract algorithm interface, selects and hands over specific algorithms to a client (policy), and provides a method for managing related algorithm families. The hierarchy of policy classes defines a family of algorithms or actions. Proper use of inheritance allows common code to be moved into parent classes, thereby avoiding duplicate code.
In addition, in a specific embodiment of the present invention, the request checking component obtains the user information carried by the service request by using one or more of the following three ways: a, acquiring a cookie value of an application, B, acquiring a cookie value designated by single sign-on, and C, acquiring a value of a preset position in service request header information; and after the request checking component acquires the user information, the authentication and the certification related to the service request are carried out.
In addition, the safety control assembly includes a primary current limiting unit and a secondary current limiting unit, wherein the primary current limiting unit is disposed in a Nginx server, the Nginx server receives and forwards a service request, the primary current limiting unit limits an access amount per unit time from a single service request address, and the primary current limiting unit does not forward the service request when the access amount per unit time of the single service request address is greater than a predetermined threshold;
the secondary current limiting unit records the detail data of each forwarded service request by using an interceptor, caches the detail data by using a redis, and then acquires the allowed access amount of the same address in unit time and the allowed access total amount in unit time, which are set in a configuration system; calculating the single address access amount in unit time and the total request access amount in unit time; when the single address access amount in unit time exceeds the access amount allowed by the same address in unit time or the total requested access amount in unit time exceeds the total requested access amount allowed in unit time, the secondary current limiting unit blocks the service request from the address or blocks all the service requests until the single address access amount in unit time after recalculation is less than the access amount allowed by the same address in unit time or the total requested access amount in unit time is less than the total requested access amount allowed in unit time.
The invention adopts a two-stage current limiting mode, a primary current limiting unit limits the access amount of a single service request address in unit time according to hardware load or the configuration of a Nginx server, when the access amount of the single service request address in unit time is greater than a preset threshold value, the primary current limiting unit does not forward the service request, and the current limiting/anti-brushing directly faces the service request of a service request end (also called a client), so the response is rapid, and the current limiting/anti-brushing can be directly configured in a Nginx system, thereby the realization is simpler.
However, for primary current limiting, it cannot achieve current limiting at a global level (because service request information from all clients is not counted and cached), for example, in some cases, although the service request amount of a single IP address is not excessive, due to the number of other clients or too large service request amount, the clients from each IP address need to be "sacrificed" for the gateway device to work normally. Therefore, the invention further utilizes a secondary current limiting unit, the secondary current limiting unit uses an interceptor to record the detail data of each forwarded service request, uses a redis cache to cache the detail data, and then obtains the allowed access amount of the same address in unit time and the allowed access total amount in unit time which are set in a configuration system; and when the single address access amount in the unit time exceeds the access amount allowed by the same address in the unit time or the total requested access amount in the unit time exceeds the total requested access amount allowed in the unit time, the secondary current limiting unit intercepts the service request from the address or intercepts all the service requests until the recalculated single address access amount in the unit time is smaller than the access amount allowed by the same address in the unit time or the total requested access amount in the unit time is smaller than the total requested access amount allowed in the unit time. In this way, the secondary current limiting unit can comprehensively judge whether the gateway system needs to perform current limiting on a single IP or perform current limiting and anti-brushing on service requests from clients of all IPs.
As a further improvement of the present invention, the four parameters of the access amount of a single address in a unit time, the total access request amount in a unit time, the access amount allowed by the same address in a unit time, and the total access allowed amount in a unit time can be comprehensively considered, and a current limiting scheme can be selected according to the configuration of the core subsystem, for example, service requests of a current limiting single IP are set but not limited to the total service request, or the total service request is limited but not limited to the service requests of a single IP (for example, the request priority of a target IP is increased according to needs), so that the application of the present invention can be more flexible.
The condition that the current service request flow is stored by utilizing the distributed storage can be generally realized by adopting Redis, and the condition generally has some performance loss, but the reliability and the cache capacity of the storage can be greatly improved.
Specifically, the Redis is a key-value distributed storage system. Similar to Memcached, it supports relatively more stored value types, including string, list, set, zset, and hash. These data types all support push/pop, add/remove, and intersect union and difference, and richer operations, and these operations are all atomic. On this basis, Redis supports various different ways of ordering. Like memcached, data is cached in memory to ensure efficiency. The difference is that Redis periodically writes updated data to disk or writes modify operations to an additional recording file, and realizes master-slave synchronization based on the updated data or the modify operations.
In addition, as shown in fig. 2, in the embodiment of the present invention, the core subsystem processes the plurality of service requests in an asynchronous manner, when each of the plurality of service requests reaches the core subsystem, a thread corresponding to an Nginx server of the core subsystem directly returns, then a thread corresponding to another component inside the core subsystem is used to perform a service request related operation, and when a result of the service request is returned, a request result is returned to the service request end.
The core subsystem of the invention uses WebAsyncTask to process the request asynchronously at the Controller layer, because the number of the server threads is certain, when the number of the service requests reaches the total number of the server threads, the connection is refused, after the WebAsyncTask is used, when the request reaches the Controller, the server threads directly return, then the thread in the system is used to execute the service, when the service returns, the request returns to the client, and the throughput of the server can be greatly improved by an asynchronous mode.
For example, in a default flow, when a user opens a url address, the web server starts a thread to receive the request, and the thread is not released until page data is received. Corresponding callback processing can be set for the asynchronous task, such as when the task is overtime, abnormally thrown, and the like. Asynchronous tasks are often very practical, such as: after one order is paid, the asynchronous task is started to inquire the payment result of the order, and the like, so that the efficiency of the gateway system for processing the service request is greatly improved.
In addition, in a specific embodiment of the present invention, the background management subsystem includes an interface management unit and an interface publishing unit, and the interface management unit is configured to query, add, modify, and download a relevant configuration of a backend service interface; the interface issuing unit is used for receiving an audit instruction of an administrator for newly adding or modifying the back-end service interface and transmitting the audit instruction to the interface management unit; the interface management unit stores the back-end service interface information in a local database, and issues a back-end service interface updating mark to a core subsystem through a distributed service system, and after the core subsystem subscribes the mark issued by the system for issuing the back-end service interface updating, the updated back-end service interface information is pulled from a background management subsystem.
As shown in fig. 3, the back-end service interface information of the core subsystem is obtained through local storage and Redis caching, so that the problem of poor database performance under high concurrency is solved, the cache data is updated through a watch mechanism of the zookeeper, and after the back-end management system issues or logs off the line of the back-end service interface information, the cache value is updated in real time through the watch mechanism of the zookeeper, so that the real-time performance of updating the back-end service interface information is ensured.
zookeeper as a mature distributed coordination framework, the subscription-publication function is an important core function. The subscription and publication function is simply called a watcher model. The viewers subscribe to some topics of interest and are then automatically notified once they change. The zookeeper subscription publishing, i.e., watch, mechanism is a lightweight design. Because it employs a push-pull combination mode. Once the server side perceives that the theme is changed, only one event type and node information is sent to the concerned client side, and specific change content is not included, so that the event is light-weight, and the so-called 'push' part is formed. The client receiving the change notification then needs to pull the changed data itself, which is the "pull" part.
In the invention, the interface management unit stores service interface information in a local database, and issues a service interface update mark (push) to a core subsystem through a distributed service system, and after the core subsystem subscribes the service interface update mark issued by the system, the updated service interface information is pulled from a background management subsystem.
Compared with the cache data updating through a watch mechanism of zookeeper, the method and the system can also adopt the message middleware to realize the transmission of the service interface information between the core subsystem and the background management subsystem, and the message middleware is suitable for the distributed environment needing reliable data transmission. In the system adopting the message middleware mechanism, different objects activate the event of the other side by transmitting messages, and the corresponding operation is completed. The sender sends the message to the message server, and the message server stores the message in a plurality of queues and forwards the message to the receiver when appropriate. Message middleware can communicate between different platforms, is often used for shielding characteristics among various platforms and protocols and realizes cooperation among application programs, has the advantages of providing synchronous and asynchronous connection between a client and a server and transmitting or storing and forwarding messages at any time, but has the disadvantages of increasing the overhead, influencing the performance of a database when high concurrency occurs, and is relatively better than the message middleware in terms of ensuring data consistency by using the Watch mechanism of Zookeeper; the message middleware scheme may have problems of message loss or message repetition.
As shown in fig. 3, the present invention also adopts Caffeine to implement high performance cache, where Caffeine is a high performance cache framework built on java8, and it is a local high performance cache framework, but the present invention is used for the management of Redis cache. The Caffeine function is similar to the Guava cache, and three cache elimination strategies are provided and are respectively based on size, time and reference modes. In the specific embodiment of the invention, Caffeine is adopted to improve the response capability of the gateway system, and particularly, in the specific embodiment of the invention, Caffeine is utilized to realize the scheduling and management of Redis cache, which integrates the advantages of two schemes.
The gateway system in the embodiment of the invention caches the back-end service interface information through local storage and Redis, so that the data of the calling relationship chain of other platform databases is not needed.
In addition, as shown in fig. 2, in the embodiment of the present invention, the data acquisition component of the core subsystem includes a protocol conversion unit, where the protocol conversion unit is configured to implement coordination between a protocol followed by the service request and a protocol followed by the service of the service system; the protocol conversion unit realizes the conversion from the Dubbo protocol to the hypertext transmission protocol in a generalization calling mode, and converts the Dubbo protocol to the hypertext transmission protocol into a common language so as to realize mutual conversion; and the conversion from the hypertext transfer protocol to the Dubbo protocol is realized by utilizing an Apache extensible interactive system.
Most interfaces of the existing gateway system use a Dubbo protocol interactively, but some systems use a Webservice technology, the gateway needs to uniformly convert the interfaces into an http mode, and the coordination between the protocol followed by the service request and the protocol followed by the service of the service system is realized through protocol conversion (Dubbo and Webservice to http, or vice versa) so as to realize the technical effects that: A. the method only needs to call a back-end service interface of the gateway system in an http mode without concerning what protocol is used by the back-end service; B. other systems are compatible, and the system interface of the system is not required to be modified for being compatible with the gateway equipment of the invention; C. developers do not need to learn and know Dubbo and webservice protocols, the learning cost of the developers is reduced, and the research and development cost of the gateway system is correspondingly reduced. Other protocols, such as ftp, rmi, and thrift, etc., may also adopt a protocol conversion manner to realize compatibility between protocols.
In addition, as shown in fig. 2, in the specific embodiment of the present invention, the core subsystem executes a plurality of backend service interface requests in parallel by using a thread pool, organizes the backend service interface requests by using a thread pool, when a service request is routed to one or more backend service interfaces, the core subsystem executes one or more backend service interface requests in parallel by using the thread pool, so as to reduce the routing time from the backend service interface request to the backend service interface when there are a plurality of backend service interfaces, when the backend service interface request is completed, the thread is released back to the thread pool, so that the thread can be reused when a next request is made, and the routing is performed by using an Okhttp3 client lightweight framework;
in addition, the core subsystem also monitors the request state and the request duration of each back-end service interface simultaneously, generates early warning information about the back-end service interface request according to the monitoring result, and sends the early warning information about the back-end service interface request to the back-end management system through rabbitmq.
In the invention, a route from a service request to a back-end service interface is completed by using Okhttp3, namely the route uses an Okhttp3 client lightweight frame, Okhttp3 is an excellent http frame, supports get request and post request, supports file uploading and downloading based on http, supports loading pictures, supports transparent GZIP compression of downloaded files, supports response cache to avoid repeated network requests, and supports using a connection pool to reduce the problem of response delay.
Thread pools are a technique for creating and managing a buffer pool of threads that are ready for use by any request that requires them.
The thread pool can greatly improve the performance of the Java application program of the user and simultaneously reduce the use of all resources.
Reducing thread creation time: in contrast to other gateway systems, if such threads are used "round-robin", the overhead of recalling the backend service interface thread is avoided. Simplified implementation mode: when using thread pools, each individual thread can operate as if it had created an own JDBC connection, allowing the user to directly use JDBC programming techniques. Controlled resource usage: if the user does not use the thread pool, but whenever a request needs to be routed to a new backend service interface, then the resource usage of the user's application is very wasteful and can lead to exceptions under high load.
In addition, as shown in fig. 2, in the embodiment of the present invention, when a service request end needs to call data from multiple service ends together, the service request end sends a single service request to a core subsystem, the core subsystem disassembles and routes the service request to multiple different backend service interfaces, and aggregates results from the multiple different backend service interfaces back to the service request end, where the result aggregation is performed in a manner of JavaScript and groovy engine.
In the gateway system, the JavaScript and the groovy engine are used for result aggregation, and the self-defined result field can be supported, so that the flexibility is improved. As part of the gateway system, multiple client service requests (typically http requests) for multiple internal microservices may be aggregated into a single client service request. This mode is particularly convenient when the client page needs to invoke data from multiple microservices. Using this method, the client will send a service request to the gateway system, and then the gateway system will be responsible for sending multiple service requests to obtain internal microservices and then aggregate the results and send back to the client. The main advantage and goal of this design paradigm is to reduce the gap between client applications and backend APIs, which is especially important for remote applications outside of the data center where the microservice is located.
In addition, the gateway system of the invention also supports the user-defined result field, thus greatly expanding the application range of the patent scheme, aggregating the user-defined result field in the data provided for the client (service request end), and facilitating the improvement and customization of the client.
In particular, as shown in fig. 1, in the embodiment of the present invention, the back-end management subsystem further includes a unit,
a group management unit: the system comprises a back-end service interface, a group management module and a service management module, wherein the back-end service interface is used for managing a back-end service interface in a group mode, and the management comprises group inquiry, addition and modification;
a recycle bin unit: the back-end service interface is used for storing the offline back-end service interface of the interface management unit and restoring and deleting the offline back-end service interface according to the interface management unit;
an application authorization unit: for configuring backend service interfaces to be accessible by those applications;
a document management unit: the method is used for generating and displaying the relevant documents of the back-end service interface;
software development kit unit: the system is used for generating a uniform tool kit for other systems to introduce;
an interface test unit: the system is used for supporting the configured back-end service interface on-line test;
a log statistic unit: the system is used for counting the calling frequency, calling source and calling time of the back-end service interface and outputting a report of the back-end service interface;
a monitoring and early warning unit: the method is used for providing early warning notification of multiple ways for the backend service interface with failed calling or poor performance.
In addition, in the embodiment of the present invention, the data obtaining unit of the core subsystem further includes a parameter mapping unit, and the parameter mapping unit obtains a back-end service request parameter value and a conversion request mode through a parameter mapping relationship, where the supported request modes include get, post, body, header, cookie, and rest mode. The parameter mapping unit corresponds the service request parameters transmitted to the gateway by the user to the request parameters required by the back-end service interface, for example: the service request parameter transmitted to the gateway by the user is userId, and the request parameter required by the back-end service interface is boId, then the gateway system in the embodiment of the invention is responsible for acquiring the value of userId, then assigning the value to the boId, mapping the parameter, and realizing the effective transmission from the service request to the service interface.
Compared with the API gateway in the prior art, the gateway system in the embodiment of the present invention has the following advantages:
a is developed based on JAVA and a mainstream system, so that the deployment and installation are more convenient;
b, self-defining result aggregation by using a JavaScript and a groovy engine;
c, updating a local cache in real time by using a watch mechanism of the zookeeper;
d, checking and processing the service request parameters by using a responsibility chain mode and a strategy mode;
e supports conversion between protocols such as Dubbo, Webservice, http and the like.
While the foregoing description shows and describes several preferred embodiments of the invention, it is to be understood that the invention is not limited to the forms disclosed herein, but is not to be construed as excluding other embodiments and is capable of use in various other combinations, modifications, and environments and is capable of changes within the scope of the inventive concept as expressed herein, commensurate with the above teachings, or the skill or knowledge of the relevant art. And that modifications and variations may be effected by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (10)
1. A distributed high-availability gateway system comprises a background management subsystem and a core subsystem; the core subsystem receives a service request from a service request end and routes the service request to a back-end service interface; the core subsystem comprises a safety control component, a request checking component, a data acquisition component and a result aggregation component;
the safety control component is used for carrying out safety inspection, current limiting and brushing prevention on the service request;
the request checking component is used for acquiring service request parameters;
the data acquisition component is used for routing the service request to a back-end service interface;
the structure aggregation component is used for aggregating results from the service end and returning the results to the service request end;
the background management subsystem and the core subsystem are both realized by adopting a distributed system.
2. The distributed high availability gateway system of claim 1, wherein the request validation component processes and validates the service request in a pipeline chain manner, treats each of a plurality of processing logics of the service request as a pipeline, each pipeline executes in sequence according to a preset order, passes the processed or validated result to the next pipeline, and wherein the sequence of the pipeline chain is adjusted according to the flow sequence of the service request.
3. The distributed high availability gateway system of claim 2, wherein the request verification component obtains the user information carried by the service request using one or more of the following three approaches: a, acquiring a cookie value of an application, B, acquiring a cookie value designated by single sign-on, and C, acquiring a value of a preset position in service request header information; and after the request checking component acquires the user information, the authentication and the certification related to the service request are carried out.
4. The distributed high availability gateway system of claim 1, wherein the safety control component comprises a primary current limiting unit and a secondary current limiting unit, wherein,
the primary current limiting unit is arranged in a Nginx server, the Nginx server receives and forwards a service request, the primary current limiting unit limits the access amount of a single service request address in unit time, and when the access amount of the single service request address in unit time is larger than a preset threshold value, the primary current limiting unit does not forward the service request;
the secondary current limiting unit records the detail data of each forwarded service request by using an interceptor, caches the detail data by using a redis, and then acquires the allowed access amount of the same address in unit time and the allowed access total amount in unit time, which are set in a configuration system; calculating the single address access amount in unit time and the total request access amount in unit time; when the single address access amount in unit time exceeds the access amount allowed by the same address in unit time or the total requested access amount in unit time exceeds the total requested access amount allowed in unit time, the secondary current limiting unit blocks the service request from the address or blocks all the service requests until the single address access amount in unit time after recalculation is less than the access amount allowed by the same address in unit time or the total requested access amount in unit time is less than the total requested access amount allowed in unit time.
5. The distributed high availability gateway system according to claim 4, wherein the core subsystem handles the plurality of service requests in an asynchronous manner, and when each of the plurality of service requests reaches the core subsystem, a thread corresponding to a Nginx server of the core subsystem directly returns, and then a thread corresponding to other components inside the core subsystem is used to perform operations related to the service request, and when a result of the service request is returned, the request result is returned to the service request terminal.
6. The distributed high availability gateway system of claim 1, wherein the back-end management subsystem comprises an interface management unit and an interface publishing unit, the interface management unit is configured to query, add, modify, and download relevant configurations of back-end service interfaces; the interface issuing unit is used for receiving an audit instruction of an administrator for newly adding or modifying the back-end service interface and transmitting the audit instruction to the interface management unit; the interface management unit stores the back-end service interface information in a local database, and issues a back-end service interface updating mark to a core subsystem through a distributed service system, and after the core subsystem subscribes the mark issued by the system for issuing the back-end service interface updating, the updated back-end service interface information is pulled from a background management subsystem.
7. The distributed high availability gateway system of claim 1, wherein the data acquisition component of the core subsystem comprises a protocol conversion unit, and the protocol conversion unit is configured to implement coordination between a protocol followed by the service request and a protocol followed by the service of the business system; the protocol conversion unit realizes the conversion from the Dubbo protocol to the hypertext transmission protocol in a generalization calling mode, and converts the Dubbo protocol to the hypertext transmission protocol into a common language so as to realize mutual conversion; and the conversion from the hypertext transfer protocol to the Dubbo protocol is realized by utilizing an Apache extensible interactive system.
8. The distributed high availability gateway system of claim 1, wherein the core subsystem performs multiple back-end service interface requests in parallel in a thread pool manner, the multiple back-end service interface requests are organized in the thread pool manner, when a service request is routed to one or more back-end service interfaces, the core subsystem performs one or more back-end service interface requests in parallel through the thread pool, so as to reduce the routing time from the service request to the back-end service interface when multiple back-end service interface requests exist, when a back-end service interface request is completed, the thread is released back to the thread pool, and is reused when a next request is made; the routing is performed using an Okhttp3 client lightweight framework;
in addition, the core subsystem also monitors the request state and the request duration of each back-end service interface simultaneously, generates early warning information about the back-end service interface request according to the monitoring result, and sends the early warning information about the back-end service interface request to the back-end management system through rabbitmq.
9. The distributed high-availability gateway system according to claim 1, wherein when a service request end needs to call data from multiple service ends together, the service request end sends a single service request to a core subsystem, the core subsystem disassembles the service request and routes the service request to multiple different backend service interfaces, and aggregates results from the multiple different backend service interfaces back to the service request end, and the result aggregation is performed in a JavaScript and groovy engine manner.
10. The distributed high availability gateway system of claim 1, wherein the back office management subsystem further comprises,
a group management unit: the system comprises a back-end service interface, a group management module and a service management module, wherein the back-end service interface is used for managing a back-end service interface in a group mode, and the management comprises group inquiry, addition and modification;
a recycle bin unit: the back-end service interface is used for storing the offline back-end service interface of the interface management unit and restoring and deleting the offline back-end service interface according to the interface management unit;
an application authorization unit: for configuring backend service interfaces to be accessible by those applications;
a document management unit: the method is used for generating and displaying the relevant documents of the back-end service interface;
software development kit unit: the system is used for generating a uniform tool kit for other systems to introduce;
an interface test unit: the system is used for supporting the configured back-end service interface on-line test;
a log statistic unit: the system is used for counting the calling frequency, calling source and calling time of the back-end service interface and outputting a report of the back-end service interface;
a monitoring and early warning unit: the method is used for providing early warning notification of multiple ways for the backend service interface with failed calling or poor performance.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010371589.1A CN113630310A (en) | 2020-05-06 | 2020-05-06 | Distributed high-availability gateway system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010371589.1A CN113630310A (en) | 2020-05-06 | 2020-05-06 | Distributed high-availability gateway system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113630310A true CN113630310A (en) | 2021-11-09 |
Family
ID=78376333
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010371589.1A Pending CN113630310A (en) | 2020-05-06 | 2020-05-06 | Distributed high-availability gateway system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113630310A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114389900A (en) * | 2022-03-23 | 2022-04-22 | 广东睿江云计算股份有限公司 | OpenResty-based abnormal traffic capturing and intercepting method and system |
| CN115801809A (en) * | 2022-11-03 | 2023-03-14 | 广州辰创科技发展有限公司 | Cross-network data synchronization control system, method and medium |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN206506551U (en) * | 2017-03-01 | 2017-09-19 | 武汉智菱物联科技有限公司 | A kind of gateway |
| CN107241315A (en) * | 2017-05-23 | 2017-10-10 | 广州唯品会网络技术有限公司 | Cut-in method, device and the computer-readable recording medium of bank's gateway interface |
| CN107395464A (en) * | 2017-09-11 | 2017-11-24 | 北京奇艺世纪科技有限公司 | A kind of server test method, apparatus and API gateway |
| CN108293021A (en) * | 2015-01-30 | 2018-07-17 | Nicira股份有限公司 | Dynamic data access at Border Gateway |
| CN109101334A (en) * | 2018-06-29 | 2018-12-28 | 中译语通科技股份有限公司 | A kind of micro services concurrency control method towards Zuul gateway |
| CN109309666A (en) * | 2018-08-22 | 2019-02-05 | 中国平安财产保险股份有限公司 | Interface security control method and terminal device in a kind of network security |
| CN109544892A (en) * | 2018-12-04 | 2019-03-29 | 四川奥地建筑设计有限公司 | A kind of wisdom agricultural things-internet gateway system |
| CN109618347A (en) * | 2019-02-17 | 2019-04-12 | 中国—东盟信息港股份有限公司 | A kind of Intelligent gateway system of automation distribution service request |
| CN109672612A (en) * | 2018-12-13 | 2019-04-23 | 中国电子科技集团公司电子科学研究院 | API gateway system |
| US20190236683A1 (en) * | 2018-01-30 | 2019-08-01 | Walmart Apollo, Llc | Transformation and aggregation engine |
| CN110191063A (en) * | 2019-06-13 | 2019-08-30 | 北京百度网讯科技有限公司 | Processing method, device, equipment and the storage medium of service request |
| CN110493352A (en) * | 2019-08-30 | 2019-11-22 | 南京联创互联网技术有限公司 | A kind of unified gateway service system and its method of servicing based on WEB middleware |
-
2020
- 2020-05-06 CN CN202010371589.1A patent/CN113630310A/en active Pending
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108293021A (en) * | 2015-01-30 | 2018-07-17 | Nicira股份有限公司 | Dynamic data access at Border Gateway |
| CN206506551U (en) * | 2017-03-01 | 2017-09-19 | 武汉智菱物联科技有限公司 | A kind of gateway |
| CN107241315A (en) * | 2017-05-23 | 2017-10-10 | 广州唯品会网络技术有限公司 | Cut-in method, device and the computer-readable recording medium of bank's gateway interface |
| CN107395464A (en) * | 2017-09-11 | 2017-11-24 | 北京奇艺世纪科技有限公司 | A kind of server test method, apparatus and API gateway |
| US20190236683A1 (en) * | 2018-01-30 | 2019-08-01 | Walmart Apollo, Llc | Transformation and aggregation engine |
| CN109101334A (en) * | 2018-06-29 | 2018-12-28 | 中译语通科技股份有限公司 | A kind of micro services concurrency control method towards Zuul gateway |
| CN109309666A (en) * | 2018-08-22 | 2019-02-05 | 中国平安财产保险股份有限公司 | Interface security control method and terminal device in a kind of network security |
| CN109544892A (en) * | 2018-12-04 | 2019-03-29 | 四川奥地建筑设计有限公司 | A kind of wisdom agricultural things-internet gateway system |
| CN109672612A (en) * | 2018-12-13 | 2019-04-23 | 中国电子科技集团公司电子科学研究院 | API gateway system |
| CN109618347A (en) * | 2019-02-17 | 2019-04-12 | 中国—东盟信息港股份有限公司 | A kind of Intelligent gateway system of automation distribution service request |
| CN110191063A (en) * | 2019-06-13 | 2019-08-30 | 北京百度网讯科技有限公司 | Processing method, device, equipment and the storage medium of service request |
| CN110493352A (en) * | 2019-08-30 | 2019-11-22 | 南京联创互联网技术有限公司 | A kind of unified gateway service system and its method of servicing based on WEB middleware |
Non-Patent Citations (1)
| Title |
|---|
| 汪日康 马启文: "计算机局域网络技术与应用", 上海科学普及出版社, pages: 155 - 156 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114389900A (en) * | 2022-03-23 | 2022-04-22 | 广东睿江云计算股份有限公司 | OpenResty-based abnormal traffic capturing and intercepting method and system |
| CN115801809A (en) * | 2022-11-03 | 2023-03-14 | 广州辰创科技发展有限公司 | Cross-network data synchronization control system, method and medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8306979B2 (en) | Service query, selection, routing and propagation | |
| US9686371B2 (en) | Proxy application with dynamic filter updating | |
| US10462262B2 (en) | Middleware abstraction layer (MAL) | |
| JP4934670B2 (en) | Gateway adapted to switch transactions and data using context-based rules over unreliable networks | |
| US7949999B1 (en) | Providing support for multiple interface access to software services | |
| US20200267202A1 (en) | Apparatus and method for low-latency message request/response processing | |
| US11163791B2 (en) | Transformation configuration in instance data replication with bi-directional replication support | |
| US20120324069A1 (en) | Middleware Services Framework for On-Premises and Cloud Deployment | |
| CN106663033B (en) | System and method for supporting a wraparound domain and proxy model and updating service information for cross-domain messaging in a transactional middleware machine environment | |
| US20020178254A1 (en) | Dynamic deployment of services in a computing network | |
| US8799399B2 (en) | Near-real time distributed usage aggregation system | |
| US20180205759A1 (en) | Reconfiguration of security requirements for deployed components of applications | |
| US20140181252A1 (en) | Request and response decoupling via pluggable transports in a service oriented pipeline architecture for a request response message exchange | |
| US20190132276A1 (en) | Unified event processing for data/event exchanges with existing systems | |
| US8135785B2 (en) | System and method for processing messages using pluggable protocol processors in a service-oriented pipeline architecture | |
| Inzinger et al. | Generic event‐based monitoring and adaptation methodology for heterogeneous distributed systems | |
| US10075549B2 (en) | Optimizer module in high load client/server systems | |
| CN113630310A (en) | Distributed high-availability gateway system | |
| US20200220910A1 (en) | Idempotent processing of data streams | |
| CN109451014A (en) | A kind of WebService agency plant and its transparent proxy method | |
| US20230283695A1 (en) | Communication Protocol for Knative Eventing's Kafka components | |
| EP1872256B1 (en) | System and method of waste management | |
| KR102260781B1 (en) | Integration System of Named Data Networking-based Edge Cloud Computing for Internet of Things | |
| US11323534B2 (en) | Concurrency reduction through publish-subscribe patterns | |
| TW201403477A (en) | Methods and systems for executing applications on mobile devices using cloud services |
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 | ||
| CB02 | Change of applicant information |
Address after: No. 1703, 17th floor, No. 27, Zhongguancun Street, Haidian District, Beijing 100080 Applicant after: BEIJING NONGXIN INTERNET TECHNOLOGY GROUP Co.,Ltd. Applicant after: Beijing Nongxin Shuzhi Technology Co.,Ltd. Applicant after: Xiamen Nongxin Digital Technology Co.,Ltd. Address before: 100080 1601 16 street, 27 Zhongguancun street, Haidian District, Beijing. Applicant before: BEIJING NONGXIN INTERNET TECHNOLOGY GROUP Co.,Ltd. Applicant before: BEIJING NONGXIN INTERNET DATA TECHNOLOGY Co.,Ltd. Applicant before: Xiamen Nongxin Digital Technology Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20220426 Address after: 100080 Beijing Haidian District Zhongguancun Street 27, 16 floor 1601 room. Applicant after: Beijing Nongxin Shuzhi Technology Co.,Ltd. Address before: No. 1703, 17th floor, No. 27, Zhongguancun Street, Haidian District, Beijing 100080 Applicant before: BEIJING NONGXIN INTERNET TECHNOLOGY GROUP Co.,Ltd. Applicant before: Beijing Nongxin Shuzhi Technology Co.,Ltd. Applicant before: Xiamen Nongxin Digital Technology Co.,Ltd. |
|
| TA01 | Transfer of patent application right |