This issue recommends an instant messaging (IM) project based on Go built by a former wechat technical expert——OpenIM。

Open-im is an Open source instant messaging component created by former wechat technical experts. Open-IM includes the IM server and client SDKS, which achieve important features such as high performance, lightweight, and easy to expand. By integrating Open-IM components and privatizing deployment servers, developers can quickly integrate instant messaging and real-time networking capabilities into their applications and ensure the security and privacy of business data.

Advantages of Open-IM

• Open source permanently free: The code is all open source and permanently free, including the client and the server, built by former wechat technical experts, and invites global technology geeks to participate in the construction.
• Easy to expand: the server is implemented by golang, the first “everything is a message” communication model, and it is easy to achieve custom messages and extension functions.
• Professional technical service: Each technical staff assumes the role of technical customer service, strengthens the community, does not mention work orders, and answers in time.
• High performance: Learn from and optimize the communication architecture, abstract online message, offline message, historical message storage model, hierarchical governance architecture, support cluster deployment.
• Security: All the code is open source, the server is privatized, and the data is self-controlled. Join the world’s most secure signal end-to-end encryption protocol.
• Full platform support: Support Andorid, iOS native development, support Flutter, uni-app cross-end development, support small programs, React and other mainstream web front-end technology framework, PC support Electron, Flutter, iOS, uni-app has mature demo can experience. Developers can use Open-IM to replace various IM cloud services on the market, in addition to reducing costs, but also give developers more flexibility and autonomy. Through Open source, we invite global technology geeks to participate in the construction of Open-IM, so that every developer can use the best IM components for free, so that every app has instant messaging capabilities.

Which modules are included in Open-IM

• client

1. golang implements cross-platform SDK

2. The iOS version SDK generated on the basis of Open-IM-SDK-Core

3. The Android version SDK generated on the basis of Open-IM-SDK-Core

4. Flutter version SDK generated in Open-IM-SDK-iOS, Open-IM-SDK-Android

5. uni-app version SDK generated in Open-IM-SDK-iOS and Open-IM-SDK-Android

6. Based on Open-IM-SDK-iOS development, for developers reference iOS Demo

7. Android Demo based on Open-IM-SDK-Android development

8. A Flutter Demo based on Open-IM-SDK-Flutter

9. uni-app Demo based on Open-IM-SDK-Uniapp

• server

1. Server side of pure golang implementation

2. docker mirror image：open-im-server

• back-end management

Including statistical reports, user management and other operation management system：Open-IM-Admin

Client interface

Open-IM main function

• Multiterminal entry

• message type

• Message function

• User data hosting

• User relationship hosting

• group

• data statistics

Server architecture

overall structure

The service end consists of the access layer, logical layer, and storage layer. The benefit is that each layer can focus on its own things based on service characteristics, improve system reusability, and reduce the coupling between services.

• Access layer: Messages are accessed through websocket protocol, and others are accessed through http/https protocol. Messages are high-frequency and core functions, and dual-protocol routing reflects the design idea of separating light from heavy.
• Logic layer: Implementation of stateless logic services through rpc, easy parallel extension, messages decoupled via MQ.
• Storage layer: redis storage token and seq; mongodb stores offline messages and periodically deletes data before 14 days (configurable by itself). mysql stores all historical messages and user information. Hierarchical data storage, taking advantage of the features of different storage components.
• Etcd：Service registration and discovery, and distributed configuration centers.

Message architecture

Open-IM message model adopts the classic inbox model, and does message alignment through global seq, which brings the simplification of the architecture and reflects the simple and beautiful architecture design concept.

• The green arrow indicates the process for user A to send A message to user B. When user A sends a message, msg_gateway splits the message and lands the message to MQ. MQ writes the message to different partitions according to userids and returns the message to User A successfully.
• The blue arrow indicates the process of the server pushing A message to B after A sends a message to B: msg_transfer is achieved through MQ consumer monitoring messages, adding seq corresponding to userId through redis, associating seq with messages and writing to mongodb, and asynchronously writing to mysql. The former is used for offline message storage. For example, when the user is not online or the push fails, the synchronization message is used to back up historical messages for background management or other purposes. After the write succeeds, pusher is called to push the message according to the msg_gateway connected to B (the push may fail due to network fluctuations or because B is not online).
• The pink arrow indicates B active synchronization and server differential message flow: When the client has any reconnection action (including re-login, network fluctuation, etc.), it will first obtain its own maximum seq on the server, compare the difference with the local seq, and actively pull the difference message to the local through the interface, thus completing the alignment of the local and server messages.

Message sending, message alignment and other logic of interaction with the server are provided for everyone to use through Open-IM-SDK, simplifying the development process.

Client architecture

Client architecture

The client SDK is responsible for the interaction with the IM server, local data storage and synchronization, and message and event callback. By integrating SDK, developers can develop chat interface UI by themselves, and set event monitoring callback to realize data docking with UI.

The Open – IMSDK is divided into three layers: network layer, logic layer and storage layer. Hierarchical governance, each performing their own duties, to achieve an efficient, stable, and unified client architecture.

• Network layer: responsible for maintaining websocket connection with the server, disconnecting the network, and receiving message push to ensure that messages and various events can be reached in real time when online. It is responsible for data completion during initial login and reconnection. By comparing the maximum seq between the local seq and the server, it synchronously pulls difference messages or events to ensure that the client and the server reach the final consistent state.
• Logical layer: For the active invocation interface and the passive triggering of events, interconnect with the network layer and storage layer to achieve business details, and complete the callback between the UI according to logic. For example, to send a message, the SDK provides a message sending and callback interface for the UI, the logical layer calls the storage layer to store local messages, the network layer calls the message, calls the UI successfully or fails, and triggers the session change callback. After receiving messages or events, the network layer sends the messages or events to the logical layer. The logical layer handles the messages or events according to the types of messages or events, such as storing local messages and triggering callbacks for session changes.
• Storage layer: sqlite lightweight database is used to complete data synchronization between the local and the server, including sessions, messages, events, contacts, groups, etc. The data get interface provided externally is obtained through the local database, so that the local data such as messages can be viewed without network, and the pressure on the server can be effectively relieved. The dual purpose of data synchronization and cache is achieved.

SDK integration process

Open-IM SDK integration is very simple, due to the developer’s private deployment, code, configuration, data are on their own server, there is no need to apply for AppKey and Secret from the cloud platform, compared with third-party IM cloud services, Open-IM is more secure, controllable, and more free.

You can read more on your own.