Several issues that must be considered when building a websocket message push service

In recent years, whether it is the fast-growing live broadcast, distance education and IM chat scenarios, or the system reminders used in conventional enterprise-level systems, the demand for websockets is increasing, and the requirements for websockets are getting higher and higher. From the early days, the application of websocket was limited to a small number of functions and special scenarios such as IM, and gradually developed into a highly available websocket service that supports high concurrency, millions and tens of millions of communications per second.

Faced with the increasing demand for websocket functions and performance in various new scenarios, different teams have different choices. Some directly use mature and stable third-party websocket services developed by professional teams, while others choose to build their own websocket services. .

As an old programmer with many years of websocket development experience, I have experienced the process of GoEasy enterprise-level websocket service from scratch, from small to large. The development team provides websocket services, and some experiences and experiences summarized in exchanges with many developers.

This time, I mainly share some basic functions and features of building websocket services. Next time I have the opportunity, I will focus on high concurrency, massive messages, cluster disaster tolerance, horizontal expansion, and automated operation and maintenance when building a highly available websocket. Looking forward to sharing more.

The following points are some technical features that I think must be considered when building a websocket service and functions that can significantly improve the user experience, for your reference:

1. Establish a heartbeat mechanism

The heartbeat mechanism is the first step in almost all network programming and is often overlooked by newbies. Because in the websocket long connection, the client and the server do not communicate all the time. If the two parties do not communicate for a long time, they will not know each other's current status, so they need to send a small message to tell the other party "I am still alive". There are also two other purposes: the server detects that a client has no heartbeat for a long time and can actively close the channel and make it offline; the client detects that a server has no response to the heartbeat and can reconnect to obtain a new one. Connection.

2. Establish a client SDK with good compatibility

Although all mainstream browsers now support websockets, browser compatibility issues are still encountered in coding, and clients communicating through websockets have long been not limited to various web browsers, but also include more and more APPs and small programs. . Therefore, it is required that the built websocket service must be able to support various clients very friendly. The best way is to build a client SDK that is compatible with all mainstream browsers, applets and APPs, as well as uni-app, vue, react-native and other common front-end frameworks, so that no matter what the company's projects use Such front-end technologies can quickly integrate websocket services.

3. Automatic reconnection and message re-send mechanism after disconnection

In the era of mobile Internet, the network environment of end users is diverse and complex. For example, users entering and exiting elevators, entering and exiting basements or subways and other places with unstable networks, or network instability caused by other reasons are very common scenarios. Therefore, a reliable websocket service must have a complete automatic reconnection mechanism when the network is disconnected. Ensure that after the network is disconnected, once the network is restored, it can automatically re-establish a long connection at the first time, and can immediately re-send messages sent during network instability.

4. Offline messages

Basic Websocket communication From a technical point of view, the prerequisite for message delivery is to establish a long connection. It is hooligan to discuss communication without establishing a network connection. However, from the user's point of view, it happens at any time that the network connection is disconnected by closing the browser at will, or directly killing the applet or APP process. Then our subconscious expectation is that the next time I open a browser to visit a web page or open an APP, I can receive all the information when the user leaves the system. Technically, this is a requirement that has little to do with websocket, but in fact it is an indispensable basic feature of websocket service, and it is also a function that can greatly improve the user experience.

5. Online and offline reminder, client online list

Knowing which users are online in the current system and capturing users' online and offline events are essential features for building an enterprise-level websocket service, especially for developing IM and game products.

6. Support historical message query

The websocket service, in a sense, also belongs to a message system, and the query requirement for historical messages is an inescapable topic. For example, the common historical messages in the IM system, so it is a must to implement a high-speed and reliable message queue mechanism within the websocket service to support the websocket service to query historical messages.

7. Message compression mechanism

Whether it is to ensure the speed and real-time nature of message communication, or to save traffic and bandwidth costs, or to improve the efficiency of the network card and increase the throughput of the system, it is necessary to compress messages during the communication process. Less.

In addition to the above seven points to consider, the author believes that there are several issues that are worthy of active attention by beginners:

1. Caching and Persistence

Choosing an appropriate message caching mechanism is an issue that must be considered to ensure the performance of enterprise-level websocket services.

2. Asynchronous call

To support high-performance systems with a large number of message communications, asynchronous calls are definitely recommended. If it is designed as a synchronous call, the caller needs to wait for the callee to complete. If the synchronous calls are made layer by layer, all callers need the same waiting time, and the caller's resources will be wasted a lot. To make matters worse, once the callee fails, other calls will have a domino effect followed by failure, causing the failure to spread. Returning the result immediately after receiving the request, and then executing it asynchronously, not only increases the throughput of the system, but also makes the decoupling between services more thorough.

3. Business independence and standardization

Although regular http services and websocket services can coexist in a web project, especially for single-application web systems with low performance requirements, this method is simpler and easier to maintain. However, for enterprise-level systems or Internet platforms with high performance and availability, a better way is to design the websocket service as a separate microservice to avoid preempting resources with conventional http services, resulting in uncontrollable system performance, and also Easier to scale horizontally.

A well-designed enterprise-level websocket service should be a standardized, independent, technical microservice independent of the business system, capable of providing communication services for all the company's projects as part of the company's infrastructure.

4. Idempotency and filtering of duplicate messages

The so-called idempotency means that requesting an interface once and multiple times should have the same consequences. Why do you need it? A call to each interface will have three possible outcomes: success, failure, and timeout. Many reasons for the last one may be network packet loss, the request may not arrive, or the return may not be received. Therefore, there is often a retry mechanism when calling the interface, but the retry mechanism can easily lead to repeated sending of messages, which is often unacceptable from the user level. Therefore, when designing the interface, we need to consider the power of the interface. Equivalence, to ensure that the same message sent once and ten times will not result in repeated arrival of the message.

5. Support QoS service quality classification

In fact, for the problem of message duplication, the industry already has solutions and standard specifications. For the message arrival rate and duplication, the commonly used method is to ensure the arrival of messages by means of message confirmation. The higher the requirements, the more complex the confirmation mechanism. , the higher the cost. In order to have a good balance between cost and arrival rate, the quality of service (QoS) for message systems is usually divided into the following three levels:

QoS 0 (At most once): "Send at most once", which means that it can be sent without an acknowledgement mechanism, just send it. It is suitable for scenarios with low requirements, and a certain non-arrival rate can be accepted, and the cost is the lowest.

QoS 1 (At least once): "Send at least once", which means that the sender must clearly receive the confirmation signal from the receiver, otherwise it will be sent repeatedly. Each message needs at least two communications to confirm the arrival, and some messages can be accepted. Reissued, but at a low cost.

QoS 2 (Exactly once): "Ensure that it is only sent once", which means that each message can only arrive once, and repeated arrivals are not allowed. In order to achieve this goal, both parties need to communicate at least three times, and the cost is the highest.

A complete websocket service faces different application scenarios, and should be able to support the selection of different levels of QoS to strike a balance between cost and service quality.

finally

Although websocket has been widely used in various systems and platforms, if you want to build a reliable, safe and stable websocket service that meets enterprise-level or large-scale Internet platforms, for inexperienced students, there are still some problems in the specific technical practice process. There are few pits to step on.

There are higher requirements for websocket services, and choosing a mature and reliable third-party websocket service is actually a lower cost and efficient choice. As a leading third-party websocket messaging platform in China, GoEasy has been running stably for 5 years and supports tens of millions of messages concurrently. In addition to being compatible with all common browsers, it is also compatible with uni-app, various small programs, and vue, Common front-end frameworks such as react-native.

I hope that this article can help and refer to the ideas for students who are building websocket services for the first time. I also welcome your predecessors to criticize and correct me. I also hope that I will have the opportunity to communicate with you about more technologies in the future.

GoEasy official website: https://www.goeasy.io

GoEasy series of tutorials:

Several issues that must be considered when building a websocket message push service

Guess you like