CN117155904A - Service registration method - Google Patents

Service registration method Download PDF

Info

Publication number
CN117155904A
CN117155904A CN202310739248.9A CN202310739248A CN117155904A CN 117155904 A CN117155904 A CN 117155904A CN 202310739248 A CN202310739248 A CN 202310739248A CN 117155904 A CN117155904 A CN 117155904A
Authority
CN
China
Prior art keywords
netty
server
service
token
registration
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
Application number
CN202310739248.9A
Other languages
Chinese (zh)
Inventor
梁文楷
李正华
刘忠沁
凃红玲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vocational And Technical College Of Anshun
Original Assignee
Vocational And Technical College Of Anshun
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vocational And Technical College Of Anshun filed Critical Vocational And Technical College Of Anshun
Priority to CN202310739248.9A priority Critical patent/CN117155904A/en
Publication of CN117155904A publication Critical patent/CN117155904A/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
    • 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/568—Storing data temporarily at an intermediate stage, e.g. caching

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer And Data Communications (AREA)

Abstract

The embodiment of the application provides a service registration method, which relates to the technical field of communication and is applied to a Netty server and comprises the following steps: acquiring a target token from the Redis cache according to the registration sequence of the Netty server; the target token is generated by a registry and stored in a Redis cache; registering the target token as a request parameter with a registration center for service; after the registration service is successful, acquiring the state of the Netty server authorized by the registration center; the state of the Netty server is an effective state or a standby state; and starting the Netty service and performing service monitoring on the appointed port. The problem of how to realize high availability of message communication between software systems by adopting Netty technology is solved.

Description

Service registration method
Technical Field
The embodiment of the application relates to the technical field of communication, in particular to a service registration method.
Background
The efficient network communication method between the existing software systems is usually a transmission layer interface communication technology based on a TCP/IP protocol, and is usually used as the first choice of the efficient network communication technology by a plurality of software items due to the characteristics of stateful connection, TCP reliable transmission, TCP full duplex communication, TCP long connection and the like. Regarding the transmission layer interface communication technology based on the TCP/IP protocol, the existing technical solutions include socket implementation communication based on Netty encapsulation or socket (socket) communication based on various programming languages, and generally, a communication architecture mode of one Netty server of multiple Netty clients is designed and message communication is performed by adopting JSON or XML format. If the Netty server is abnormal or down, the whole communication system is interrupted and communication cannot be continued.
Therefore, how to ensure that the Netty technology is adopted between software systems to realize high availability of message communication becomes a technical problem to be solved urgently at present.
Disclosure of Invention
The embodiment of the application provides a service registration method, electronic equipment and a computer readable storage medium, which are used for solving the problem of low efficiency when different formats are adopted for message communication between software systems in the prior art. In order to solve the technical problems, the application is realized as follows:
in a first aspect, an embodiment of the present application provides a service registration method, applied to a Netty server, including:
acquiring a target token from a Redis cache according to the registration sequence of the Netty server; the target token is generated by a registry and stored in a Redis cache;
registering a service with the registry by taking the target token as a request parameter;
after the registration service is successful, acquiring the state of the Netty server authorized by the registration center; the state of the Netty server is an effective state or a standby state;
and starting the Netty service and performing service monitoring on the appointed port.
Optionally, if the Netty server is the first registered server, the target token is the first token, and after the registration service is successful, the state of the Netty server authorized by the registration center is obtained to be an effective state;
If the Netty server is not the first registered server, the target token is a second token, and after the registration service is successful, the state of the Netty server authorized by the registration center is acquired to be a standby state.
Optionally, the registering the target token as a request parameter with the registry includes:
and performing AES asymmetric encryption on the target token, and storing an encrypted ciphertext of the target token in a request header for request registration.
In a second aspect, an embodiment of the present application further provides a service registration method, which is applied to a registration center, including:
caching the token and the corresponding key to the redis;
acquiring a target secret key of a target token according to the registration sequence of the Netty server;
receiving a service registration request carrying request parameters from a Netty server, and performing target token verification, wherein the request parameters carry token information;
and if the verification is successful, authorizing the corresponding service end state to the Netty service end according to the registration sequence of the Netty service end and prompting that the service registration is successful.
Optionally, if the Netty server is the first registered server, the target token is the first token, and if the verification is successful, the corresponding server state is authorized to be the valid state according to the registration sequence of the Netty server;
If the Netty server is not the first registered server, the target token is the second token, and if the verification is successful, the corresponding server state is authorized to be the standby state according to the registration sequence of the Netty server.
Optionally, the receiving a service registration request carrying a request parameter from the Netty server and performing target token verification, where the request parameter carries token information includes:
decrypting the token information in the request parameters, judging whether the decrypted token is consistent with a target token corresponding to the target secret key, and if so, checking successfully.
In a third aspect, an embodiment of the present application further provides a service registration method, applied to a Netty client, including:
obtaining a target token from a Redis cache; the target token is generated by a registry and stored in a Redis cache;
registering a service with the registry by taking the target token as a request parameter;
after the registration service is successful, the Netty client service is started, and a TCP channel is created by the Netty server in an effective state for communication.
Optionally, if the Netty client senses that the TCP channel of the Netty server in the valid state is unavailable, sending a server reassignment request to the registry and attempting to create the TCP channel with the Netty server in the latest valid state for communication.
In a fourth aspect, an embodiment of the present application further provides a service registration method, which is applied to a registration center, including:
caching the token and the corresponding key to the redis;
acquiring a target secret key of a target token;
receiving a service registration request carrying request parameters from a Netty client, and performing target token verification, wherein the request parameters carry token information;
if the verification is successful, the service registration is prompted to be successful.
Optionally, if a Netty client redistribution request is received, the registry selects a Netty server in a standby state, switches the state of the current Netty server from the standby state to an active state, and returns the IP address of the Netty server in the latest active state to the Netty client, so that the Netty client and the Netty server in the latest active state establish communication.
In a fifth aspect, the present application further provides a service registration device for the service registration method according to any one of the first to fourth aspects, where the service registration device has a corresponding functional module and has a corresponding effect.
In a sixth aspect, an embodiment of the present application further provides an electronic device, including:
A memory for storing a computer program;
a processor for implementing the steps of the service registration method as described in any one of the first to fourth aspects above when executing the computer program.
In a seventh aspect, an embodiment of the present application further provides a computer readable storage medium, on which a computer program is stored, which when executed by a processor implements the steps of the service registration method according to any one of the first to fourth aspects above.
In the embodiment of the application, when the service registration method is applied to the Netty client, a target token is acquired from a Redis cache according to the registration sequence of the Netty client; the target token is generated by a registry and stored in a Redis cache; registering the target token as a request parameter with a registration center for service; after the registration service is successful, acquiring the state of the Netty server authorized by the registration center; the state of the Netty server is an effective state or a standby state; and starting the Netty service and performing service monitoring on the appointed port. The registry can determine the effective states and standby states of the plurality of servers according to the registration order of the Netty servers, so that the subsequent Netty clients can establish the Netty servers with the effective states for communication. The Netty server end configuration structure with one master and multiple slaves is provided so as to communicate with a plurality of clients, so that the problem that communication is unavailable due to sudden downtime of the Netty server end is effectively solved, and the stability and safety of communication are ensured.
In addition, the application also provides a service registration device corresponding to the service registration method embodiment, and the service registration device is provided with corresponding functional modules and has corresponding effects.
In addition, the application also provides electronic equipment and a computer readable storage medium, which also have the beneficial effects.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the application. Also, like reference numerals are used to designate like parts throughout the figures. In the drawings:
fig. 1 is a schematic flow chart of a service registration method according to an embodiment of the present application.
Fig. 2 is a second flowchart of a service registration method according to an embodiment of the present application.
Fig. 3 is a third flowchart of a service registration method according to an embodiment of the present application.
Fig. 4 is a flowchart of a service registration method according to an embodiment of the present application.
Fig. 5 is a schematic diagram of a service registration method according to an embodiment of the present application.
Fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
The efficient network communication method between the existing software systems is usually a transmission layer interface communication technology based on a TCP/IP protocol, and is usually used as the first choice of the efficient network communication technology by a plurality of software items due to the characteristics of stateful connection, TCP reliable transmission, TCP full duplex communication, TCP long connection and the like. Regarding the transmission layer interface communication technology based on the TCP/IP protocol, the existing technical solutions include socket implementation communication based on Netty encapsulation or socket (socket) communication based on various programming languages, and generally, a communication architecture mode of one Netty server of multiple Netty clients is designed and message communication is performed by adopting JSON or XML format. If the Netty server is abnormal or down, the whole communication system is interrupted and communication cannot be continued.
The application provides a service registration method for realizing high-availability communication service, which mainly comprises a Register registration center, netty service ends (one is Active, one is Standby), netty clients and a protobuf protocol module by designing communication architecture modes of the Netty clients and the Netty service ends. The method aims to solve the problem of high availability of message communication between software systems by adopting Netty technology.
In the embodiment of the application, a Register registry mainly generates 3 token tokens which are stored in a Redis cache in the form of character strings, the first two token tokens are used for service registration by a Netty server, and the third token is used for service registration by a Netty client, and the method comprises the following steps:
(1) The 1 st type is used for calling authentication by a Register registry and a Netty server (Active effective state) RESTFul interface, the token consists of an active+netty server IP+32-bit UUID (universal unique identifier) +timestamp, and a corresponding storage key (key) is BizServer_active;
(2) The 2 nd interface used for the Register registry and the Netty server (Standby state) is used for calling authentication, the token consists of a standby+netty server IP+32 bits UUID+time stamp, and the corresponding storage key (key) is BizServer_standby;
(3) The 3 rd type is used for calling authentication between a Register registry and a Netty client RESTFul interface, the token consists of a Netty client identifier BizClient+32-bit UUID+timestamp, and the corresponding storage key (key) is BizClient_TokenKey.
Referring to fig. 1, fig. 1 is a schematic flow chart of a service registration method according to an embodiment of the application. The embodiment of the application provides a service registration method, which is applied to a Netty server and comprises the following steps:
step S11: acquiring a target token from a Redis cache according to the registration sequence of the Netty server; the target token is generated by the registry and stored in the Redis cache.
In this embodiment, the target token is determined according to the registration order of the Netty server, and is used for invoking authentication by the RESTFul interface when the Register registry and the Netty server are in different states.
Step S12: registering a service with the registry using the target token as a request parameter.
In some embodiments of the present application, optionally, if the Netty server is the first registered server, the target token is the first token, and after the registration service is successful, the state of the Netty server authorized by the registration center is obtained as an effective state;
If the Netty server is not the first registered server, the target token is a second token, and after the registration service is successful, the state of the Netty server authorized by the registration center is acquired to be a standby state.
In some embodiments of the present application, optionally, the registering the target token as a request parameter with the registry includes:
and performing AES asymmetric encryption on the target token, and storing an encrypted ciphertext of the target token in a request header for request registration.
Specifically, the Netty server (Active state) is generally the first registered service, the token used is composed of an active+netty server ip+32 bits uuid+timestamp, the corresponding storage key is a bizserver_active, when the Netty server (Active state) requests registration from the Register registry, the token (key is a bizserver_active) generated by the Register registry is acquired from the Redis cache, AES asymmetric encryption is performed on the token, and the token encrypted ciphertext is stored in the Header request Header to perform request registration. The Netty server (in the Standby state) is generally a second registered service, the used token consists of a standby+netty server ip+32-bit uuid+timestamp, the corresponding storage key is a bizserver_standby, when the Netty server (in the Standby state) requests registration from the Register registry, the token (the key is a bizserver_standby) generated by the Register registry is acquired from the Redis cache, AES asymmetric encryption is performed on the token, and the encrypted ciphertext of the token is stored in the Header request Header to perform request registration.
Step S13: after the registration service is successful, acquiring the state of the Netty server authorized by the registration center; the state of the Netty server is an effective state or a standby state.
In a specific embodiment, during the starting process, the Netty server firstly acquires the token value in the Redis cache and sets the token value in the request Header, and the token parameter is set in the Header request Header:
authKey = token;
the authKey is used for authentication of interface calls of the Netty server and the Register registry.
Note that: the key of the token value acquired by the first Netty server is BizServer_Active, and the key of the token value acquired by the subsequent Netty server is BizServer_Standby. The Netty server RESTFul interface requests the Register registry to Register the service, and after the interface response returns, whether the service registration is successful or not can be judged according to the response code (0: success, -1: failure) and the current state (Active state or Standby state) of the Netty server.
In this embodiment, before starting, the Netty server acquires the token in the Redis cache, registers the token with the Register registry as a request parameter, and acquires an Active effective state or a Standby state authorized by the Register registry after successful registration (the first registered Netty server is Active, the second registered Netty server is Standby), that is, the Netty server in the Active state can receive a TCP request from the Netty client, and the Netty server in the Standby state stands by at any time.
Further, when the Register registry receives the Netty server for which the Netty client interface is available, and the Register registry knows that the Netty server in the original Active state is abnormal or down, the Netty server in the original Standby state is authorized and changed into the Active state, and communication service is continuously provided for the Netty client. And after the Netty server is successfully registered, continuing to start the Netty service and monitoring the service at the designated port.
It can be understood that the method does not limit the number of Netty servers, and when at least 2 Netty servers exist, the deployment of the effective server and the standby server can be completed, and the method is also suitable for other one-master multi-slave deployment schemes. After the Netty server in the current Active state is abnormal or down, the Register registry randomly selects the Netty server (Standby state), and switches the state of the Netty server from Standby to Active, and communication service is continuously provided for the Netty client, so that the high availability function of the whole communication system is ensured.
Step S14: and starting the Netty service and performing service monitoring on the appointed port.
It can be appreciated that the Netty server in an active state that completes service registration can also maintain communication with the Netty client.
In a specific embodiment, after the Netty server is successfully registered, the Netty service is continuously started and service monitoring is performed on the designated port. The Netty server configures a listening port and a thread generation coefficient, configures a bosgroup and a workercroup thread group, wherein the thread number of the bosgroup is the number of CPU cores of the current computer, the thread number of the workercroup is (numOfCores/(1-coefficient))+1, a channel is set to be non-blocking, the maximum length waiting for connection in a thread queue is set to be 128, meanwhile, a Nagle algorithm is closed to ensure timely sending when a message is generated, a TCP bottom heartbeat keep-alive mechanism is started, an address port of the Netty server is set to be shared, a message transmission protocol of the Netty server is set to be a protobuf protocol, and a heartbeat detection processing class (HearbeatHandler inherited by IdlestateHandler class) and a message processing class (handler inherited by a serviceHandler class) of the server are added. Meanwhile, the Netty server integrates a SpringBoot environment, so that connection and management of MySQL database and Redis cache service are realized, service interface call is realized, the Netty server realizes an API interface in a service processing class custom protocol of a service processing package, the Netty client requests call conveniently, class names in the service processing package configure custom annotation @ BizServer, and a class method configures custom annotation @ BizService (parameters have interface names, protocols, request types and version numbers) for receiving and processing requests of the Netty client. When the Netty server starts, automatically scanning whether the interface processing class under the service processing package of the Netty server has a custom annotation @ BizServer, and if the interface processing class has the annotation @ BizServer, registering the interface processing class into the custom BizServerServiceFaction class (using ConcurrentHashMap technology for storage, and guaranteeing thread concurrency and security when accessing beans). When the Netty server receives the request of the Netty client, according to the service name and method in the request parameters of the Netty client, invoking the BizServiceFaction class to acquire the object and method of the service processing class of the Netty server, acquiring the object method of the service processing class of the Netty server by using the Java reflection technology, judging whether the method has annotation@remoteService (the parameters have service name, version number and service type), if so, further judging whether the parameter value of the annotation@remoteService (the parameters have service name, version number and service type) of the Netty client request method is consistent with the interface invoking parameter value agreed by the Netty server, if so, acquiring the service name and service type parameter value annotated by the Netty server, acquiring the service processing class object and method of the Netty server by the service name value (comprising the service processing class name and the method name of the Netty server), and then executing the method invoking by the Netty server and returning the processing result. The spring space component self-defines a heartbeat detection processing class HeartBeatHandler (inheriting IdleStateHandler class) of the Netty server and a message processing class ServerHandler (inheriting SimpleChannelInboundHandler class) of the server, and is used for sending back a heartbeat packet to the Netty client when the Netty server receives the heartbeat packet sent by the Netty client, so as to maintain TCP connection to realize TCP long connection, and avoid resource waste caused by the reestablishment of the connection of the TCP connection.
In the embodiment of the application, when the service registration method is applied to the Netty client, a target token is acquired from a Redis cache according to the registration sequence of the Netty client; the target token is generated by a registry and stored in a Redis cache; registering the target token as a request parameter with a registration center for service; after the registration service is successful, acquiring the state of the Netty server authorized by the registration center; the state of the Netty server is an effective state or a standby state; and starting the Netty service and performing service monitoring on the appointed port. The registry can determine the effective states and standby states of the plurality of servers according to the registration order of the Netty servers, so that the subsequent Netty clients can establish the Netty servers with the effective states for communication. The Netty server end configuration structure with one master and multiple slaves is provided so as to communicate with a plurality of clients, so that the problem that communication is unavailable due to sudden downtime of the Netty server end is effectively solved, and the stability and safety of communication are ensured.
Referring to fig. 2, fig. 2 is a second flowchart of a service registration method according to an embodiment of the application. The embodiment of the application also provides a service registration method which is applied to the registration center and comprises the following steps:
Step S21: the token and corresponding key are cached to the redis.
In this embodiment, when the Register registry receives a service registration request from the Netty server, the first two token tokens and keys are mainly used.
Step S22: and acquiring a target secret key of the target token according to the registration sequence of the Netty server.
In some embodiments of the present application, optionally, if the Netty server is the first registered server, the target token is the first token, and if the verification is successful, the corresponding server state is authorized to be the valid state according to the registration order of the Netty server;
if the Netty server is not the first registered server, the target token is the second token, and if the verification is successful, the corresponding server state is authorized to be the standby state according to the registration sequence of the Netty server.
Step S23: and receiving a service registration request carrying request parameters from the Netty server, and performing target token verification, wherein the request parameters carry token information.
In some embodiments of the present application, optionally, the receiving a service registration request from the Netty server, where the service registration request carries a request parameter, and performing target token verification, where the request parameter carries token information, includes:
Decrypting the token information in the request parameters, judging whether the decrypted token is consistent with a target token corresponding to the target secret key, and if so, checking successfully.
In a specific implementation mode, a SpringAOP interceptor is arranged in a Register registry, when judging that a Netty server port is in request of registering service, if the Netty server port is registered by a first Netty server port, the Register registry acquires a token with a key of BizServer_Active from a Redis cache, decrypts the token in a request parameter, checks whether the decrypted token is consistent with the token acquired by the Redis cache, and performs service registration if the check passes; when judging that the Netty server interfaces require registration service, if the Netty server interfaces are registered by the second or N Netty server, the Register registry acquires a token with a token of BizServer_Standby from the Redis cache, decrypts the token in the request parameters, checks whether the decrypted token is consistent with the token acquired by the Redis cache, and if the check passes, service registration is performed.
Step S24: and if the verification is successful, authorizing the corresponding service end state to the Netty service end according to the registration sequence of the Netty service end and prompting that the service registration is successful.
In the embodiment of the application, when the service registration method is applied to a registration center, a target key of a target token is acquired according to the registration sequence of a Netty server by caching the token and the corresponding key to a redis; receiving a service registration request carrying request parameters from a Netty server, and performing target token verification, wherein the request parameters carry token information; if the verification is successful, authorizing the corresponding service end state to the Netty service end according to the registration sequence of the Netty service end and prompting that the service registration is successful. The registry can determine the effective states and standby states of the plurality of servers according to the registration order of the Netty servers, so that the subsequent Netty clients can establish the Netty servers with the effective states for communication. The Netty server end configuration structure with one master and multiple slaves is provided so as to communicate with a plurality of clients, so that the problem that communication is unavailable due to sudden downtime of the Netty server end is effectively solved, and the stability and safety of communication are ensured.
Referring to fig. 3, fig. 3 is a third flowchart of a service registration method according to an embodiment of the present application. The embodiment of the application also provides a service registration method which is applied to the Netty client and comprises the following steps:
Step S31: obtaining a target token from a Redis cache; the target token is generated by the registry and stored in the Redis cache.
In this embodiment, when the Register registry receives a service registration request of the Netty client, a third token is mainly used for invoking authentication by using the RESTFul interface of the Register registry and the Netty client.
Step S32: registering a service with the registry using the target token as a request parameter.
In a specific embodiment, when the Netty client requests registration from the Register registry, the token is composed of a Netty client identifier, a bizclient+32-bit uuid+timestamp, the corresponding storage key is a bizclient_token, all Netty clients use a unified token, when the Netty client requests registration from the Register registry, the token (the key is the bizclient_token) generated by the Register registry is acquired from the Redis cache, AES asymmetric encryption is performed on the token, and the encrypted ciphertext of the token is stored in the Header request Header for registration.
Step S33: after the registration service is successful, the Netty client service is started, and a TCP channel is created by the Netty server in an effective state for communication.
It will be appreciated that the Netty client that completes the service registration can also maintain communication with the Netty server in an active state.
In a specific embodiment, the Netty client configures an IP address and a port of the Netty server (Active state), configures a group thread group of the Netty client, and has a thread number of (numofCores/(1-coeffcient)) +1, wherein numofCores is the CPU core number of the current computer, sets a channel to be non-blocking, closes a Nagle algorithm to ensure that a message is timely sent when the message is generated, opens a heartbeat keep-alive mechanism of a TCP bottom layer, sets an address port of the Netty server to be shared, sets a message transmission protocol of the Netty client to be a protobuf protocol, and adds a heartbeat detection processing class cltidlehander (inherited by the idestatehander class) of the protobuf Varint32FrameDecoder, protobufDecoder, protobufVarint LengthFieldPrepender, protobufEncoder, netty client and a message processing class clliehander (inherited by the channllnenderader class) of the client. The Netty client self-defines an interface class of remote request, a method in the interface is @ RemoteService annotation class (parameters are service name, version number and service type), the method is used for carrying authentication parameters when sending data request processing to the method in the service processing class of the Netty server, the RemoteClient class is defined, a Map < String of the RemoteClient class, a TCP channel connection pool of IConnectPools > connection Pools stores TCP channel connections of the Netty client and the Netty server, and when the Netty client sends data to the Netty server, an asyncClient () asynchronous request method of the RemoteClient class is called to acquire the current TCP channel connection, send a request to the Netty server and wait for a response to return. Meanwhile, the Netty client integrates a SpringBoot environment, and connection and call of Redis cache service are realized. When the Netty client starts, a TCP connection channel connected with the Netty server is established and stored in a connection pool connected with the TCP, a remote method of the custom Netty client scans a class remoteconnerConfig and configures an interface packet name of a remote request of the Netty client, the remoteconnerConfig scans an interface packet lower interface class of the remote request of the Netty client, analyzes a method with annotation@remoteservice (parameters include service name, version number and service type), adopts JDK dynamic proxy technology to proxy the interface packet lower interface class of the remote request of the Netty client, acquires the TCP connection channel of the Netty client and the Netty server, and sends request data to the Netty server and waits for response. The soacf component creates a TCP request follower of the TCP channel, and is used for acquiring the response of the Netty server and forwarding the response to the Netty client. Meanwhile, the space component defines a heartbeat detection processing class ClientIdleHandler (inheriting IdleStateHandler class) of the Netty client and a message processing class ClientHandler (inheriting ChannelInboundHandlerA class) of the client, and is used for sending a heartbeat packet to the Netty server when a TCP connection channel of the Netty client is idle, so that TCP connection is maintained to realize TCP long connection, and resource waste caused by reestablishing connection of the TCP connection is avoided.
In some embodiments of the present application, optionally, if the Netty client senses that the TCP channel with the Netty server in the valid state is unavailable, the server reassignment request is sent to the registry and an attempt is made to communicate with the new Netty server in the valid state by creating the TCP channel.
Specifically, when the Netty server in the Active state is abnormal or down, the Netty client immediately senses that a TCP connection channel with the Netty server in the Active state is unavailable through a channel inactive () method, then reconnection is performed for a plurality of times when an interval is set, and if reconnection fails for a plurality of times, the Netty client requests (acquires a currently effective token through a Redis) a Register registry to acquire a Netty server connection address in the Standby state.
In the embodiment of the application, when the service registration method is applied to the Netty client, the Netty client acquires the token in the Redis cache before starting, registers the token as a request parameter to a Register registration center, continues to start the Netty client service after successful registration, and establishes a TCP channel with the Netty server (Active state) for communication. The Netty server end configuration structure with one master and multiple slaves is provided so as to communicate with a plurality of clients, so that the problem that communication is unavailable due to sudden downtime of the Netty server end is effectively solved, and the stability and safety of communication are ensured.
Referring to fig. 4, fig. 4 is a flowchart illustrating a service registration method according to an embodiment of the application. The embodiment of the application also provides a service registration method which is applied to the registration center and comprises the following steps:
step S41: the token and corresponding key are cached to the redis.
In this embodiment, when the Register registry receives a service registration request from the Netty client, the third token and the key are mainly used.
Step S42: a target key of the target token is obtained.
Step S43: and receiving a service registration request carrying request parameters from the Netty client, and performing target token verification, wherein the request parameters carry token information.
Step S44: if the verification is successful, the service registration is prompted to be successful.
In a specific embodiment, a SpringAOP interceptor is set in a Register registry, when judging that a Netty client interface requests to Register a service, the Register registry acquires a token whose key is a bizclient_token from a Redis cache, decrypts the token in the request parameter, checks whether the decrypted token is consistent with the token acquired by the Redis cache, and performs service registration if the check passes.
In some embodiments of the present application, optionally, if a server redistribution request sent by a Netty client is received, the registry selects a Netty server in a standby state, switches the state of the current Netty server from the standby state to an active state, and returns the IP address of the Netty server in the latest active state to the Netty client, so that the Netty client establishes communication with the Netty server in the latest active state.
In a specific embodiment, the Register registry randomly selects one from the current Netty server (Standby state), acquires the IP address of the current Netty server (Standby state), acquires the corresponding token stored in the Redis cache (the key in the Redis cache is the bizserver_standby), invokes the RESTFul request interface, requests to switch the state of the current Netty server from Standby to Active through the RESTFul interface, and returns the IP address of the new Netty server (Active state) to the Netty client, so that the Netty client establishes communication with the current new Netty server (Active state).
In the embodiment of the application, when the service registration method is applied to a registration center, a target token is acquired from a Redis cache; the target token is generated by a registry and stored in a Redis cache; registering the target token as a request parameter with a registration center for service; after the registration service is successful, the Netty client service is started, and a TCP channel is created by the Netty server in an effective state for communication. The method for communicating the Netty servers in the effective state by the multiple clients is provided, the problem that communication is unavailable due to sudden downtime of the Netty servers is effectively solved, and the stability and safety of communication are ensured.
Referring to fig. 5, fig. 5 is a schematic diagram of a service registration method according to an embodiment of the present application. The architecture includes a registry, one or more Netty clients, at least 2 Netty servers. The method specifically comprises the following steps:
step 1: starting a Register registry to generate a token (updated every 30 minutes), storing the token in a Redis cache, and starting to receive service registration from a Netty server and a Netty client;
step 2: starting two Netty servers, wherein the Netty servers firstly acquire token in a Redis cache;
step 3: the Netty server registers the token as a request parameter to a Register registry for service;
step 4: after two Netty service ends Register service with the Register registry successfully, updating the state of the service ends to be Active or Standby, continuously starting the Netty service end service and monitoring a designated port (the Netty service end with the Active state and the Standby state already started at the moment)
Step 5: starting a Netty client, wherein the Netty client firstly acquires a token in a Redis cache;
step 6: the Netty client registers the token as a request parameter to a Register registry for service;
step 7: after the Netty client successfully registers the service to the Register registry, continuing to start the Netty client service and creating a TCP connection channel with the Netty server (Active state);
Step 8: the Netty client acquires a TCP connection channel with a Netty server (Active state), uses a JDK dynamic proxy technology to proxy a remote request interface of the Netty client, and sends a request message to the Netty server (Active state), wherein the message format is protobuf format; the Netty server (Active state) receives the request of the Netty client, verifies the request parameters and calls the method of the business processing class object of the Netty server (Active state) by using Java reflection technology;
step 9: after receiving a request from a Netty client, the Netty server (Active state) executes a method of a business processing class object, calls MySQL data, redis cache service and the like, and returns an operation result;
step 10: when the channel of the Netty client side is free to read (the reading free time is 15 s), sending a heartbeat message to the Netty server side (Active state);
step 11: when the Netty server (Active state) receives the heartbeat message of the Netty client, the Netty server sends back the heartbeat message to the Netty client;
step 12: when the Netty client senses that a TCP connection channel with a Netty server (Active state) is unavailable immediately through a channel Inactive () method, reconnecting for 5 times at intervals of 30 seconds, and if the reconnecting fails for 5 times, the Netty client requests (a currently effective token is acquired through Redis) a Register registry to acquire a Netty server connection address in a Standby state;
Step 13: after receiving the request of the Netty client to reacquire the available Netty server, the Register registry immediately sets the Netty server in the original Standby state as an Active state, and sets the Netty server in the original Active state as the Standby state;
step 14: the Register registry returns the Netty server connection address in the current Active state to the client;
step 15: after the Netty client receives the return of the Register registry, reestablishing a TCP connection channel with the Netty server in the current Active state, and executing the step 8;
step 16: after receiving a request from a Netty client, the Netty server in the current Active state executes a method of a business processing class object, calls MySQL data, redis cache service and the like, and returns an operation result;
step 17: when the channel of the Netty client side is free to read (the reading free time is 15 s), sending a heartbeat message to the Netty server side in the current Active state;
step 18: when the Netty server in the current Active state receives the heartbeat message of the Netty client, the heartbeat message is sent back to the Netty client.
In this embodiment, a Register registry implemented based on a SpringBoot technology is defined, so as to implement connection and management of a Redis cache service and a MySQL database, and a service processing class thereof implements a RESTful interface, so as to be convenient for receiving a service registration request (Http protocol) of a Netty server or a Netty client. The Register registry automatically generates a token and stores the token in a Redis cache when being started, and is updated every 30 minutes to ensure timeliness of the token, the Register registry is responsible for managing request parameters token in a RESTful interface calling process of a Netty server or a Netty client, when the Netty server or the Netty client requests Register registry registration service, the Register registry performs IP white list and token verification on the request of the Netty server or the Netty client, and the verification can Register service. In order to ensure high availability of the Netty server, when the Register registry receives the Netty server for service registration, two Netty server ends in Active and Standby states are respectively registered according to time sequence, namely, the Netty server end in Active state receives TCP requests from the Netty client, when the Netty server end in Active state is abnormal or down, the Netty client immediately senses that a TCP connection channel with the Netty server end in Active state is unavailable through a channel Active () method, and then reconnection is carried out for 5 times at intervals, if the reconnection fails for 5 times, the Netty client acquires a Netty server connection address in Standby state through the Register registry, the Netty server end in Active state is immediately set as Active state after the Register receives the request, the Netty server end in Active state is connected to the client, and the Netty client is reconnected with the Netty server end in Active state and continues to communicate with the Netty server end in Active state. And customizing a proto file of message transmission by utilizing a protobuf protocol technology, and generating a corresponding request and response Java file with a protobuf format, wherein the Java file is used for message communication between the Netty client and the Netty server. Because protobuf is a Google open-source supporting cross-platform, multi-language structured data description and high-performance serialization protocol, the protocol is completely based on binary system, so that the performance is far higher than that of message transmission in JSON or XML formats.
In this embodiment, the functions implemented by the Netty server include:
(1) Starting Netty server service and monitoring a designated port;
(2) Scanning interface processing class under a service processing packet of the Netty server, and registering class objects with @ BizServer annotation into BizServerServiceFaction class;
(3) Checking whether the parameter value of Netty client request method annotation @ RemoteService is consistent with the interface call parameter value agreed by the Netty server;
(4) Acquiring a business processing class object corresponding to the Netty server according to the parameter value of the Netty client request annotation@remoteservice, acquiring a method of the business processing class object of the Netty server by using a Java reflection technology, and executing method call;
(5) The Netty server side carries out heartbeat processing to realize TCP long connection;
(6) The protobuf protocol communication response class is realized, and the Netty server side can conveniently communicate with the Netty client side by using the protobuf protocol.
In this embodiment, the functions implemented by the Netty client include:
(1) Starting Netty client service, and creating a TCP channel connection pool for connecting Netty servers;
(2) Scanning interface package interface classes of remote requests of Netty clients, and adopting a JDK dynamic proxy technology to make proxy requests on annotated @ remoteService interface methods;
(3) Acquiring TCP connection channels of a Netty client and a Netty server, creating a TCP request follower of the TCP connection channel, sending a request and waiting for a response;
(4) The TCP request follower of the TCP connection channel obtains the response of the Netty server and forwards the response to the Netty client.
(5) The Netty client side carries out heartbeat processing to realize TCP long connection;
(6) The protobuf protocol communication request class is realized, and the Netty client side can conveniently communicate with the Netty server side by using the protobuf protocol.
In this embodiment, a software developer needs to start a Register registry first, monitor and receive service registration requests from a Netty server and a Netty client; the Netty server needs to be deployed on two computer servers (high availability is guaranteed), and is configured with a service monitoring port, a thread generation coefficient coeffient, a configuration scanning type BizScannerConfig and a processing interface scanning packet name; the configuration of the IP address and the port connected with the Netty server (Active) at the Netty client, the remote call scanning class remoteckannerconfig and the request interface scanning packet name can be completed through the configuration, and the operation is simple, flexible and easy to use.
In addition, the application also provides a service registration device corresponding to the embodiment of the service registration method, and the service registration device is provided with corresponding functional modules, and it should be noted that specific workflows of the corresponding functional modules can refer to corresponding contents disclosed in the foregoing embodiment and have corresponding effects, and no detailed description is given here.
Referring to fig. 6, fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the application. The embodiment of the application also discloses an electronic device 30, which comprises a processor 31 and a memory 32; wherein the memory 32 is used for storing a computer program; the processor 31 is configured to execute the computer program, and the service registration method disclosed in the foregoing embodiment.
For the specific procedure of the service registration method, reference may be made to the corresponding content disclosed in the foregoing embodiment, and no further description is given here.
The memory 32 may be a carrier for storing resources, such as a read-only memory, a random access memory, a magnetic disk, or an optical disk, and the storage mode may be transient storage or permanent storage.
In addition, the electronic device 30 further includes a power supply 33, a communication interface 34, an input-output interface 35, and a communication bus 36; wherein the power supply 33 is configured to provide an operating voltage for each hardware device on the electronic device 30; the communication interface 34 can create a data transmission channel between the electronic device 30 and an external device, and the communication protocol to be followed is any communication protocol applicable to the technical solution of the present application, which is not specifically limited herein; the input/output interface 35 is used for obtaining external input data or outputting external output data, and the specific interface type thereof may be selected according to the specific application requirement, which is not limited herein.
Further, the embodiment of the application also discloses a computer readable storage medium for storing a computer program, wherein the computer program realizes the service registration method disclosed in the previous embodiment when being executed by a processor.
For the specific procedure of the service registration method, reference may be made to the corresponding content disclosed in the foregoing embodiment, and no further description is given here.
In this specification, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different point from other embodiments, so that the same or similar parts between the embodiments are referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant points refer to the description of the method section.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The foregoing has outlined a detailed description of a service registration method, apparatus, electronic device and computer readable storage medium, wherein specific embodiments are provided to facilitate the understanding of the method and core idea of the application; meanwhile, as those skilled in the art will have variations in the specific embodiments and application scope in accordance with the ideas of the present application, the present description should not be construed as limiting the present application in view of the above.

Claims (10)

1. The service registration method is characterized by being applied to a Netty server and comprising the following steps of:
acquiring a target token from a Redis cache according to the registration sequence of the Netty server; the target token is generated by a registry and stored in a Redis cache;
registering a service with the registry by taking the target token as a request parameter;
after the registration service is successful, acquiring the state of the Netty server authorized by the registration center; the state of the Netty server is an effective state or a standby state;
and starting the Netty service and performing service monitoring on the appointed port.
2. The service registration method according to claim 1, wherein if the Netty server is a first registered server, the target token is a first token, and after the registration service is successful, the state of the Netty server authorized by the registration center is obtained as an effective state;
if the Netty server is not the first registered server, the target token is a second token, and after the registration service is successful, the state of the Netty server authorized by the registration center is acquired to be a standby state.
3. The service registration method according to claim 1, wherein registering the target token as a request parameter with the registry for a service comprises:
and performing AES asymmetric encryption on the target token, and storing an encrypted ciphertext of the target token in a request header for request registration.
4. A service registration method, applied to a registration center, comprising:
caching the token and the corresponding key to the redis;
acquiring a target secret key of a target token according to the registration sequence of the Netty server;
receiving a service registration request carrying request parameters from a Netty server, and performing target token verification, wherein the request parameters carry token information;
And if the verification is successful, authorizing the corresponding service end state to the Netty service end according to the registration sequence of the Netty service end and prompting that the service registration is successful.
5. The service registration method according to claim 4, wherein if the Netty server is a first registered server, the target token is the first token, and if verification is successful, the corresponding server state is authorized to be the valid state according to the registration order of the Netty server;
if the Netty server is not the first registered server, the target token is the second token, and if the verification is successful, the corresponding server state is authorized to be the standby state according to the registration sequence of the Netty server.
6. The service registration method according to claim 4, wherein the receiving a service registration request carrying a request parameter from a Netty server and performing target token verification, wherein the request parameter carries token information, includes:
decrypting the token information in the request parameters, judging whether the decrypted token is consistent with a target token corresponding to the target secret key, and if so, checking successfully.
7. A service registration method, applied to a Netty client, comprising:
Obtaining a target token from a Redis cache; the target token is generated by a registry and stored in a Redis cache;
registering a service with the registry by taking the target token as a request parameter;
after the registration service is successful, the Netty client service is started, and a TCP channel is created by the Netty server in an effective state for communication.
8. The service registration method according to claim 7, wherein if the Netty client senses that a TCP channel with a Netty server in an active state is not available, sending a server reassignment request to a registry and attempting to communicate with a Netty server in a latest active state by creating a TCP channel.
9. A service registration method, applied to a registration center, comprising:
caching the token and the corresponding key to the redis;
acquiring a target secret key of a target token;
receiving a service registration request carrying request parameters from a Netty client, and performing target token verification, wherein the request parameters carry token information;
if the verification is successful, the service registration is prompted to be successful.
10. The service registration method according to claim 9, wherein if a Netty client redistribution request is received, the registration center selects a Netty server in a standby state, switches the state of the current Netty server from the standby state to an active state, and returns the IP address of the Netty server in the latest active state to the Netty client, so that the Netty client establishes communication with the Netty server in the latest active state.
CN202310739248.9A 2023-06-21 2023-06-21 Service registration method Pending CN117155904A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310739248.9A CN117155904A (en) 2023-06-21 2023-06-21 Service registration method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310739248.9A CN117155904A (en) 2023-06-21 2023-06-21 Service registration method

Publications (1)

Publication Number Publication Date
CN117155904A true CN117155904A (en) 2023-12-01

Family

ID=88885592

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310739248.9A Pending CN117155904A (en) 2023-06-21 2023-06-21 Service registration method

Country Status (1)

Country Link
CN (1) CN117155904A (en)

Similar Documents

Publication Publication Date Title
JP4965574B2 (en) Port sharing among multiple processes
EP2817733B1 (en) Identity provider discovery service using a publish-subscribe model
US9817657B2 (en) Integrated software development and deployment architecture and high availability client-server systems generated using the architecture
CN112114979B (en) Remote procedure call method and device
US8832271B2 (en) Identity provider instance discovery
US7801998B2 (en) Establishing and maintaining a connection by a client to a server within a network
EP2620872B1 (en) Method and device for callback processing in telecommunication capacity opening
CN109951546B (en) Transaction request processing method, device, equipment and medium based on intelligent contract
US20160219083A1 (en) Resource management for webrtc
US8566847B2 (en) Out-of-band host management via a management controller
US10367894B2 (en) Information processing apparatus, method for controlling the same, non-transitory computer-readable storage medium, and information processing system
CN111478955A (en) Microservice registration method, system, apparatus and computer readable storage medium
US8925066B2 (en) Provisioning proxy for provisioning data on hardware resources
US20070226745A1 (en) Method and system for processing a service request
CN111970240A (en) Cluster receiving and managing method and device and electronic equipment
EP1331571B1 (en) System and method for enabling arbitrary components to transfer data between each other
US11411812B2 (en) Dynamic service creation for microservice-based integration service
CN111212117A (en) Remote interaction method and device
JP2008172489A (en) Device for authenticating terminal device, authentication method, authentication program, terminal device, and device for relaying communication of terminal device
CN110545320A (en) Intranet data interaction method and equipment
CN103607324B (en) Data processing method for Java message service, Java message client and server
US20090138702A1 (en) Method and apparatus for supporting cryptographic-related activities in a public key infrastructure
CN117155904A (en) Service registration method
CN114025005B (en) Data communication method, system, electronic equipment and storage medium
CN112929453B (en) Method and device for sharing session data

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