Shulou(Shulou.com)06/02 Report--

This article mainly explains "what problems should be considered in building websocket message push service". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what problems should be considered in building websocket message push service".

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

In the face of the increasing demand for websocket function 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, and some choose self-built websocket services.

As a veteran programmer with many years of experience in websocket development, he has experienced the process of GoEasy enterprise websocket services from scratch to large. This article is based on the holes that have been stepped on in the process of GoEasy development in the past few years, as well as some experiences and experiences in providing websocket services for many development teams and communicating with many developers.

This time, we mainly share the basic functions and features of websocket services. Next time, we have the opportunity to share more about the high concurrency, massive messages, cluster disaster recovery, scale-out, and automated operation and maintenance that we have to face when building a highly available websocket.

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

1. The establishment of heartbeat mechanism is the first step in almost all network programming, which is often easily ignored by beginners. Because in the websocket persistent connection, the client and the server will not communicate all the time, if the two sides do not communicate for a long time, they do not know the current status of each other, so it is necessary to send a small message to tell the other side that "I am still alive". There are also two purposes: the server detects that a client has no heartbeat and can actively close the channel and let it go offline; if the client detects that a server has not responded to the heartbeat, it can reconnect to obtain a new connection.

two。 Establishing client SDK with good compatibility although mainstream browsers now support websocket, there are still browser compatibility problems in coding, and the client that communicates through websocket has long been not limited to a variety of web browsers, but also includes more and more APP, Mini Program. Therefore, it requires that the built websocket service must be able to support a variety of clients amicably. The best way is to build a client SDK that is compatible with all mainstream browsers, Mini Program and APP, as well as various front-end frameworks such as uni-app, vue, react-native and so on, so that no matter what front-end technology the company's projects use, it can quickly integrate websocket services.

3. Automatic network reconnection and message retransmission mechanism in the era of mobile Internet, the network environment of end users is diverse and complex, such as users entering and leaving elevators, basement or subway, or network instability caused by other reasons are very common scenarios. Therefore, a reliable websocket service must have a perfect automatic reconnection mechanism. After the network is cut off, once the network is restored, the long-standing connection can be automatically re-established as soon as possible, and the messages sent during the period of network instability can be reissued immediately.

4. Websocket communication based on offline messages, technically speaking, the prerequisite for message delivery is to establish a long connection. It is rogue to discuss communication without establishing a network connection. But from the user's point of view, the situation that shuts down the browser, or directly kills the Mini Program or APP process, which leads to the disconnection of the network, occurs at any time. Then we subconsciously expect that the next time I open a browser to visit the web page, or open APP, I will receive all the information about the time the user is away from 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 services and a feature that can greatly improve the user experience.

5. Online reminder, the client online list to know which users are online in the current system, to capture user online events, is to build an enterprise-level websocket service, essential features, especially the development of IM and game products.

6. Support for historical message query websocket service, a sense also belongs to a message system, the query requirements for historical messages, is an unavoidable topic. For example, historical messages are common in IM systems, so it is a necessary work to implement a high-speed and reliable message queuing mechanism in websocket services to support the query of historical messages in websocket services.

7. Whether the message compression mechanism is to ensure the speed and real-time performance of message communication, 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 in the process of communication.

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

1. Choosing the appropriate message caching mechanism for caching and persistence is a problem that must be considered to guarantee the performance of enterprise-level websocket services.

two。 Asynchronous invocation must be recommended for a high-performance system that supports a large number of message communication. If designed for synchronous invocation, the caller needs to wait for the callee to complete. If a layer-by-layer synchronous call continues, all callers need the same waiting time, and the caller's resources will be wasted. To make matters worse, once something goes wrong with the callee, other calls will have a domino effect that will follow the problem, causing the fault to spread. Return the result immediately after receiving the request, and then execute it asynchronously, which can not only increase the throughput of the system, but also make the decoupling between services more thorough.

3. Independent of business and standardization, although there can be both regular http services and websocket services in a web project, especially for single-application web systems with low performance requirements, this approach is simpler and easier to maintain. However, for enterprise systems or Internet platforms with high performance and availability, a better way is to design websocket services as a separate micro-service to avoid preempting resources with conventional http services, resulting in uncontrollable system performance and more convenient for scale-out.

A well-designed enterprise websocket service should be a standardized technical micro-service independent of the business system, which can provide communication services for all the company's projects as part of the company's infrastructure.

4. Idempotency and repetitive message filtering the so-called idempotency is that requesting an interface once and multiple times should have the same consequences. Why do you need it? Calls to each interface have three possible outcomes: success, failure, and timeout. Many of the last reasons may be packet loss on the network, the request may not arrive, or the return may not be received. Therefore, there is often a retry mechanism when calling an interface, but the retry mechanism can easily lead to repeated transmission of messages, which is often unacceptable from the user level, so when designing the interface, we need to consider the idempotence of the interface. make sure that the same message is sent once and ten times will not lead to repeated arrival of the message.

5. Support QoS quality of service grading. In fact, the industry already has solutions and standards for message repetition. For message arrival rate and repetition, the common means is to ensure message arrival through message confirmation. The higher the requirement, the more complex the confirmation mechanism, the higher the cost. In order to strike a good balance between cost and arrival rate, the quality of service (QoS) of the messaging system is usually divided into the following three levels:

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

QoS 1 (At least once): "send at least once" means that the sender must clearly receive the acknowledgement signal from the receiver, otherwise it will be sent repeatedly. Each message needs at least two communications to confirm its arrival. It is acceptable for some messages to be retransmitted, but the cost is not high.

QoS 2 (Exactly once): "make sure to send only once" means that each message can only arrive once, and repeated arrival is not allowed. In order to achieve this goal, both parties need to communicate at least three times, and the cost is the highest.

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

Finally, although websocket has been widely used in a variety of systems and platforms, but if you want to build a reliable, secure and stable websocket service that meets enterprise or large-scale Internet platforms, for inexperienced students, there are still many holes to step on in the specific technical practice process.

There are higher requirements for websocket services, so choosing a mature and reliable third-party web socket service is actually a lower-cost and efficient choice. As the leading third-party websocket messaging platform in China, GoEasy has been running steadily for 5 years, supporting 10 million levels of message concurrency. It is not only compatible with all common browsers, but also compatible with uni-app, various Mini Program, vue, react-native and other common front-end frameworks.

Thank you for your reading. The above is the content of "what problems should be considered in building websocket message push service". After the study of this article, I believe you have a deeper understanding of what problems to consider in building websocket message push service, and the specific usage needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.