CN115174666A - Cross-frame cross-end message pushing method and device - Google Patents

Abstract

The invention belongs to the technical field of message pushing and developing, and discloses a cross-frame cross-end message pushing method and a cross-frame cross-end message pushing device, which are characterized by comprising a protocol layer message pushing device and a service layer message pushing device; the protocol layer message pushing device has no service related attribute or platform related attribute, the service layer message pushing device can be regarded as the best practice of the protocol layer message pushing device, and any mobile terminal can complete message pushing access only by initializing the service device; the protocol layer message pushing device provides a set of api with no difference at each end, and a set of high-availability middleware is built in the protocol layer message pushing device, wherein the middleware comprises weak network communication, log monitoring and heartbeat keep-alive. Because only one code is maintained, the invention facilitates the monitoring, is more convenient for closing all communication ports and simplifies the collection and maintenance of indexes; moreover, the api between the ends is consistent, so that the maintenance of multiple ends is simple, and all the ends can be used after one end is debugged.

Description

A cross-frame cross-end message push method and device

technical field

The invention belongs to the technical field of message push development, and in particular relates to a cross-frame cross-end message push method and device.

Background technique

With the rapid development of the mobile Internet in China, high concurrency and real-time user response are often faced by mobile applications, such as real-time information on patient numbers and real-time message push in social networks. Message push has become a standard for mobile development. However, to achieve real-time message push on mobile, a high-efficiency and energy-saving two-way communication mechanism must be used to ensure real-time data transmission, such as using the websocket protocol as the communication protocol.

However, there are many mobile terminals on the market at present, such as android, ios, WeChat applet, Alipay applet, H5, etc. The implementation methods of websocket are different between each terminal, and the access methods are also different. In cross-terminal technology, multi-terminal communication cannot be accessed indiscriminately, and only specific terminals can be accessed. For example, socket.io is often used as a web terminal, and socketTask is often used as a small program. The access methods between them are different, and the APIs are also different. It cannot achieve indiscriminate access to any terminal, which makes it impossible to guarantee consistency between multiple terminals, and there will be differences in API calling methods and interactions. At present, the traditional access method has four shortcomings: (1) The message device in the applet environment cannot be reused to the web side. If the same function web side needs to be re-connected and developed; (2) The api (Application ProgrammingInterface, application programming interface) is inconsistent, making it difficult to maintain multiple terminals, and the code cannot be reused between terminals ③ If a communication function has been developed on a terminal (not the current terminal), it cannot be directly It is necessary to re-develop a device with exactly the same function; ④ Each terminal writes a separate set of code to implement the message push function, which cannot guarantee the consistency of implementation between terminals, which may lead to some unexpected external error. The root cause of these shortcomings is that there is no message push device that can run on any terminal at the same time and provide multi-terminal indifference APIs.

In view of the above shortcomings, the problem to be solved or the purpose of the present invention is to provide a cross-frame cross-terminal message push method and device, which can support the message push access of any terminal, and provide a set of indifference between each terminal. api, due to the complex network environment in the websocket scenario, a set of high-availability middleware is built-in, such as weak network communication, log monitoring, and heartbeat keep-alive. Developers only need to pay attention to the current business, without paying too much attention to compatibility and special scene processing, and develop a set of code that can run on any terminal, thus greatly reducing development costs.

SUMMARY OF THE INVENTION

Aiming at the deficiencies of the prior art, the purpose of the present invention is to provide a cross-frame cross-end message push method and device, which can run on any terminal at the same time and provide a multi-end indifference api message push device including: protocol layer message push device, service layer message push device. The service layer message pushing device depends on the protocol layer message pushing device. The message push device at the protocol layer does not have any business-related attributes, nor does it have any platform-related attributes. The service layer push device can be regarded as the best practice of the protocol layer push device, any mobile terminal only needs to initialize the service device to complete the access of message push.

In order to realize a message push system that can run on any terminal at the same time and provides multi-terminal indifference APIs, the present invention adopts the following technical solutions.

A cross-frame cross-end message push device, characterized in that it includes a protocol layer message push device and a business layer message push device;

The protocol layer message push device does not have any business-related attributes, nor any platform-related attributes. The business layer message push device can be regarded as the best practice of the protocol layer push device. Any mobile terminal only needs to initialize the service device to complete the message push. access;

The protocol layer message push device provides a set of APIs that are indistinguishable from each end, and has a built-in set of high-availability middleware including weak network communication, log monitoring, and heartbeat keep-alive.

Further, the protocol layer message push device is a basic message push device that encapsulates the agreed protocol and encapsulates it into a protocol layer;

Specifically, it is divided into the following steps: 1) implement a general socket instance container; 2) run-time instance injection; 3) register a high-availability processor; 4) implement a message manager.

Further, the socket instance container includes, but is not limited to, an instance that is compatible with android, ios, WeChat applet, Alipay applet, and socket in H5 state, and implements a unified api;

The injection of the runtime instance, including but not limited to using the over of stomp to achieve injection;

The high-availability processors include but are not limited to heartbeat keep-alive processors, message merging processors, weak network communication processors, and indicator observation processors;

The message manager includes but is not limited to providing a complete set of config (initialization configuration item) and api.

Further, the specific message processing process of the service layer message push device is divided into the following steps: 1. initialize the basic device, 2. register the processor of the service layer, and 3. provide a set of initialization configuration and api.

Further, the processor of the registration service layer includes but is not limited to: identity authentication, tracking, publish-subscribe device, and debug.

A cross-frame cross-end message push method, characterized in that it comprises the following steps:

Step 1: the server and the client agree on a sub-protocol, and the server pushes a message to the client according to the agreed sub-protocol;

Step 2: the client completes the base layer message processing across multiple terminals through the protocol layer message push device according to the sub-protocol agreed in the step 1 and generates a base device;

Step 3: complete business layer message processing by business layer message push device according to the basic device provided in step 2;

Step 4: the client distributes the message pushed by the server, and distributes it to the designated terminal;

Step 5: The device side receives the message, updates the data, and renders the view.

Further, the sub-protocols agreed in step 1 include but are not limited to stomp and socket.io.

Further, the processor for processing basic messages across multiple terminals described in step 2 includes a message merging processor, a weak network communication processor, an indicator observation processor, a heartbeat keep-alive processor, and a disconnection and reconnection processor;

Inject Socket instances of specific terminals such as android, ios, WeChat applet, Alipay applet, H5 and other specific terminals through runtime capabilities; and provide indifference api, customizable config; and then purify it so that it does not contain any environment-related content , to form a protocol layer device. Through the processing of runtime injection here, the compilation will not contain any platform-related information, and the basic protocol layer device will be able to be mounted on any terminal.

Further, the basic device described in step 2 is written according to a specific domain language, and its presentation form is similar to an intermediate language, and the focus of the present invention is not to compile the DSL, so it is necessary to use some cross-end framework capabilities on the market to complete the DSL compilation work, Make it compile to code for a specific terminal.

Further, the business layer message processing described in step 3 includes, but is not limited to, further processing such as authentication and authentication processing, buried point processing, triggers, mock capabilities, etc., adding these processing to the protocol layer device generated in step 2, And according to the indifference api provided by the protocol layer device, it is formed into a business layer device, including initialization methods, business middleware, etc.

Further, before step 4 is performed, the business layer device in step 3 needs to be initialized, and the initialization items include the service port agreed with the server and the subscribed channel.

Further, after receiving the processed message in step 5, the terminal side can directly render the message without paying attention to the processing of the protocol layer and the business layer.

Compared with the prior art, the beneficial effects of the present invention are:

1. Since only one code is required to be maintained, monitoring becomes easier, it is more convenient to close all communications, and the collection and maintenance of indicators becomes simple.

2. Since only one code is needed to be maintained, and the APIs between each end are consistent, it is easy to maintain multiple ends, and all ends are available after debugging at one end.

3. Since only one code needs to be maintained, if a certain communication function has been developed on a certain terminal (not the current terminal), it can be reused directly at this time, without re-development, saving manpower.

4. Due to the maintenance of only one code, the multi-terminal interaction consistency becomes easy, and the traditional method requires a lot of time to compare the interaction consistency between the multi-terminals.

5. Since only one code is needed to maintain, the stability of messages, timing, weak network processing, etc., a series of time-consuming and labor-intensive high-availability processing is unified, and it does not need to spend too much manpower, which can greatly save manpower.

Description of drawings

1 is a flowchart of a cross-frame cross-terminal message push method according to the present invention;

2 is an architectural diagram of a cross-frame cross-end message push method according to the present invention;

Detailed ways

Please refer to a cross-frame cross-end message push method and device shown in Figure 1-2. It can support message push access of any terminal, and provides a set of APIs that are indistinguishable from each end. The network environment is complex, so a set of high-availability middleware is built-in, such as weak network communication, log monitoring, and heartbeat keep-alive. Developers only need to pay attention to the current business, without paying too much attention to compatibility and special scene processing, and develop a set of code that can run on any terminal, thereby greatly reducing development costs. A cross-frame cross-end message push method and device.

Specifically, 1. a cross-frame cross-end message push device, comprising a protocol layer message push device and a business layer message push device, the protocol layer message push device does not have any business-related attributes, nor does it have any platform-related attributes, business layer messages The push device can be regarded as the best practice of the protocol layer push device. Any mobile terminal only needs to initialize the service device to complete the access of the message push. The protocol layer message push device provides a set of APIs that are indistinguishable from each end, and has built-in A set of high-availability middleware includes weak network communication, log monitoring, and heartbeat keep-alive.

The protocol layer message push device is a basic message push device that encapsulates the agreed protocol and encapsulates it into a protocol layer. Specifically, it is divided into the following steps: 1) Realize a general socket instance container; 2) Runtime instance injection; 3) Registration High availability processor; ④ implement message manager.

Among them, the socket instance container includes but is not limited to compatible with android, ios, WeChat applet, Alipay applet, socket instance in H5 state, and realizes a unified api; the injection of the runtime instance, including but not limited to the use of stomp over to achieve Injection; high-availability processors include but are not limited to heartbeat keep-alive processors, message merging processors, weak network communication processors, and indicator observation processors; message managers include but are not limited to providing a complete set of config (initialization configuration items) and api.

The specific processing message process of the business layer message push device is divided into the following steps: 1. initialize the basic device 2. the processor of the registered business layer 3. provide a set of initialization configuration and api, wherein the processor of the registered business layer includes but is not limited to: identity authentication, burial point, publish-subscribe device, debug.

A cross-frame cross-end message push method, comprising the following steps:

Step 1: the server and the client agree on a sub-protocol, and the server pushes a message to the client according to the agreed sub-protocol;

Step 2: the client completes the base layer message processing across multiple terminals through the protocol layer message push device according to the sub-protocol agreed in the step 1 and generates a base device;

Step 3: complete business layer message processing by business layer message push device according to the basic device provided in step 2;

Step 4: the client distributes the message pushed by the server, and distributes it to the designated terminal;

Step 5: The device side receives the message, updates the data, and renders the view.

In step 1, the server client agrees on a sub-protocol, for example, stomp (Simple Text Orientated Messaging Protocol, Simple Text Oriented Messaging Protocol) is used as the sub-protocol, and then the server will push messages to the client in the form of the stomp protocol.

In step 2, according to the protocol stomp agreed in step 1, the stomp-based protocol is encapsulated, and a basic message push device of a protocol layer is encapsulated. Specifically, it is divided into the following steps: 1. Carry out the content processing of the platform, remove all platform-related content, and then implement a general socket instance container, smooth the api of all platforms in the container, and then reveal a unified api socket Instance; 2. The specific socket instance is determined at runtime. Specifically, the instance is injected through the over attribute of stomp at runtime to realize the indifference of multiple terminals; 3. With the front base, on the base It is necessary to implement a highly available processor to make up for the shortcomings of the protocol. There are the following core processors: a. Heartbeat keep-alive processing, in order to avoid a lot of heartbeat waste and the appearance of heartbeat tides, the smart heartbeat method is used, which is better To balance the timeliness and performance of the message, and debounce (anti-shake) to achieve not occupying the message channel, the heartbeat value is 2000ms. b. The message merging processor, which merges the messages in the same time period, specifically sets the concurrency threshold, and merges when the threshold is exceeded. c. The weak network communication processor performs downgrade processing according to the mobile network environment and the consecutive times of disconnection and reconnection. d. The indicator observation processor is used to detect the health state of the device and report abnormality, such as abnormal recording and abnormal backtracking. In addition to the above core processors, the expansion entry for non-core processors is also provided. The non-core processors are implemented in the form of plugins, so as to cut interviews and expand without affecting the core; The provided processor is registered with the manager and provides a complete set of config (initialization configuration items) and api. So far, a basic protocol layer message device can be completed.

In step 3, it is necessary to rely on the basic layer device provided in step 2, which is divided into the following steps: 1. Initialize the basic device, and make a layer of bridging options in the config before revealing it. ②Register the processor of the business layer, the core processor (here, it has little to do with the topic, only enumerates and does not elaborate): identity authentication ability, buried point ability, publish and subscribe ability, debugging ability, etc. ③ Provide a set of initialization configuration, including but not limited to: run (run), destroy (destroy), config (configuration), bizMiddleware (business middleware), triggerMiddleware (message-triggered middleware).

In step 4, it is necessary to initialize the message device provided in step 3, configure config and run it. At this stage, the message push from the server can be received, and after receiving the message, the message will be distributed to each subscription service according to the message type. on the page. At this time, the message device can already be initialized to many terminals, such as Android, ios, WeChat applet, Alipay applet, H5, etc., all of which can be used without distinction. And all terminals only need to maintain one message push device described in step 3, and provide an expandable way. If you want to expand more terminals, you only need to add the socket container of the protocol layer message device described in step 2 and be compatible with the instance on the terminal side. The upper layer does not need to be changed or sensed. If you need customized message push requirements , just inject the plugin described in step 2 in the specific business layer.

In step 5, each end-side business page receives the message, renders the view, and completes the consumption of the message.

Claims (10)

1. A cross-frame cross-end message push device, characterized in that, comprising a protocol layer message push device, a business layer message push device; The protocol layer message push device does not have any business-related attributes, nor does it have any platform-related attributes. The business layer message push device can be regarded as the best practice of the protocol layer push device. Any mobile terminal only needs to initialize the service device to complete the message push. access; The protocol layer message push device provides a set of APIs that are indistinguishable from each end, and has a built-in set of high-availability middleware including weak network communication, log monitoring, and heartbeat keep-alive. 2. a kind of cross-frame cross-end message push device according to claim 1, is characterized in that, described protocol layer message push device is to encapsulate the agreed protocol, and encapsulate into a protocol layer basic message push device; Specifically, it is divided into the following steps: 1) implement a general socket instance container; 2) run-time instance injection; 3) register a high-availability processor; 4) implement a message manager. 3. A cross-frame cross-end message push device according to claim 2, wherein the socket instance container includes but is not limited to compatible android, ios, WeChat applet, Alipay applet, socket in H5 state , and implement unified api; The injection of the runtime instance, including but not limited to using the over of stomp to achieve injection; The high-availability processors include but are not limited to heartbeat keep-alive processors, message merging processors, weak network communication processors, and indicator observation processors; The message manager includes but is not limited to providing a complete set of config (initialization configuration item) and api. 4. a kind of cross-frame cross-end message push device according to claim 1, is characterized in that, described business layer message push device concrete processing message process is divided into the following steps: 1. initialize basic device 2. process of registering business layer ③ provides a set of initialization configuration and api. 5. A cross-frame cross-end message push device according to claim 4, wherein the processor of the registration service layer includes but is not limited to: identity authentication, buried point, publish and subscribe device, and debug. 6. A cross-frame cross-end message push method, characterized in that, comprising the following steps: Step 1: the server and the client agree on a sub-protocol, and the server pushes a message to the client according to the agreed sub-protocol; Step 2: the client completes the base layer message processing across multiple terminals through the protocol layer message push device according to the sub-protocol agreed in the step 1 and generates a base device; Step 3: complete business layer message processing by business layer message push device according to the basic device provided in step 2; Step 4: the client distributes the message pushed by the server, and distributes it to the designated terminal; Step 5: The device side receives the message, updates the data, and renders the view. 7. The cross-frame cross-terminal message push method according to claim 6, wherein the sub-protocols agreed in step 1 include but are not limited to stomp and socket.io. 8. a kind of cross-frame cross-terminal message push method according to claim 6, is characterized in that, the processor of cross-multi-terminal basic message processing described in step 2 comprises message merge processor, weak network communication processor , indicator observation processor, heartbeat keep-alive processor, disconnection and reconnection processor. 9. a kind of cross-frame cross-terminal message push method according to claim 6, is characterized in that, before executing step 4, need to initialize the business layer device of step 3, and the initialization item comprises the service agreed with the server Ports, subscribed channels. 10. A cross-frame cross-end message push method according to claim 6, characterized in that, after the end-side described in step 5 receives the processed message, it can be rendered directly without paying attention to the protocol layer and the message. Business layer processing.

Images