本文译自tech takshila经OpenIM技术人员整顿订正后公布。
写在后面

Open-IM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包含IM服务端和客户端SDK，实现了高性能、轻量级、易扩大等重要个性。开发者通过集成Open-IM组件，并私有化部署服务端，能够将即时通讯、实时网络能力疾速集成到本身利用中，并确保业务数据的安全性和私密性。

理解更多原创文章：

【OpenIM原创】开源OpenIM：轻量、高效、实时、牢靠、低成本的音讯模型

【OpenIM原创】C/C++调用golang函数，golang回调C/C++函数

【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理

【OpenIM扩大】OpenIM服务发现和负载平衡golang插件：gRPC接入etcdv3

【开源OpenIM】高性能、可伸缩、易扩大的即时通讯架构

如果您有趣味能够在文章结尾理解到更多对于咱们的信息，期待着与您的交换单干。

免责申明：这是设计WhatsApp等即时通讯零碎的一种办法。然而，咱们不能保障WhatsApp是以这种形式设计的。这是咱们设计相似零碎的想法。

问题陈说

设计一个即时通讯平台，如WhatsApp或Signal，用户能够利用该平台互相发送音讯。应用程序的一个重要方面是聊天信息不会永恒存储在应用程序中。

乏味的事实：一些聊天信使（如FB Messenger）存储聊天信息，除非用户明确删除它。然而，像WhatsApp这样的即时通讯工具不会将音讯永恒保留在服务器上。

零碎需要

instant messenger应用程序应满足以下要求。

  • 它应该可能反对用户之间的一对一对话。
  • 它应该可能向其余用户显示发送/交付/读取确认。
  • 它应该可能提供对于用户上次流动工夫的信息。
  • 它应该容许用户共享图像。
  • 它应该可能向其余用户发送推送告诉。

容量布局

咱们须要建设一个高度可扩大的平台，可能反对WhatsApp规模的流量。此外，在进行容量布局时，咱们须要确保思考顶峰流量的最坏状况。上面列出了咱们能够用来估算应用程序容量的一些数字（如WhatsApp）。

-每月应用程序上的用户数：10亿

-顶峰流量时每秒的流动用户数：650000

-顶峰流量时每秒的邮件数：4000万

整个应用程序将由几个微服务组成，每个微服务执行特定的工作。解决聊天信息流量的数据立体（网站管理员包含到分布式系统章节的链接）（咱们称之为chat microservice）中所需的服务器数量能够应用以下等式进行预计。

# ℎ = （#聊天信息/秒）__∗ 提早）/#每台服务器的并发连贯

假如每台服务器的并发连接数为100K，发送音讯的提早为20毫秒。在这种状况下，聊天服务器机队中所需的服务器的预计数量（应用上述等式）将为8（即4000万*20毫秒/100K）。在规范实际中，倡议再增加几个服务器，以解决这些服务器可能的故障。在接下来的一节中，咱们将看到这些聊天服务器对总体基础设施老本的影响。

乏味的事实：在本次演讲中，Rick Reed（软件工程师@WhatsApp）谈到了优化基于Erlang的服务器应用程序，以及调整FreeBSD内核以反对每台服务器数百万个并发连贯。这在很大水平上帮忙了他们放弃尽可能小的服务器占用空间。

高级设计

此即时通讯应用程序所需的性能能够应用两种微服务建模：聊天服务和长期服务。聊天服务将为沉闷用户发送的在线聊天信息流量提供服务。该服务将查看接管音讯的用户是否在线。如果用户在线，则音讯将立刻转发给该用户。否则，音讯将由长期服务解决。此服务将负责保护发送给脱机用户的所有音讯（文本或图像）。数据将临时存储在长期存储器中，直到脱机用户复原联机。咱们将在前面的一节中提供无关各个组件的更多详细信息。

乏味的事实：WhatsApp实际上应用了一种十分相似的办法，正如同一位WhatsApp工程师（Rick Reed）在另一次演讲中所探讨的。

API设计

咱们能够公开一个REST端点来与聊天服务交互。上面介绍了用于发送音讯的API端点的定义。

sendMessage（String fromUser、String toUser、ClientMetaData ClientMetaData、String message）

申请：

_fromUser:\u发送申请的用户ID

_toUser:\u向其发送申请的用户ID

clientMetaData：用于存储客户端信息（如设施详细信息、地位等）的元数据。

音讯：作为通信的一部分发送的音讯。

数据模型

咱们将存储详细信息，例如用户连贯到的服务器以及用户上次流动的工夫。咱们能够应用基于文档的数据库（如MongoDB）来存储用户信息，如用户的最初流动工夫（也称为心跳工夫）。数据模型将相似于下表。

用户ID（香港）心跳工夫已连贯服务器

表1：数据模型-用户信息

组件图

在本节中，咱们将探讨在一对一通信中发送音讯的两种不同场景。之后，咱们将探讨须要反对的其余性能，例如推送告诉和用户活动状态。最初，咱们将钻研进行优化和解决故障场景的不同机制。

一对一通信

这里，咱们将探讨与向另一个用户发送音讯相干的两种不同场景。第一种状况波及向在线用户发送文本音讯。在第二个场景中，咱们形容了向脱机用户发送图像所波及的操作序列。

场景1：向在线用户发送文本

上面介绍了向在线用户发送文本音讯的序列图中每个步骤的详细信息。

  • 步骤1：Alice向Bob发送一条音讯，该音讯被定向到Alice连贯的聊天服务器。
  • 步骤2：Alice从其连贯的聊天服务器（即聊天服务器A）取得确认，音讯标记为Alice端发送。
  • 步骤3：聊天服务器向数据存储器发出请求，以获取无关Bob连贯的聊天服务器的信息。
  • 步骤4：聊天室存储返回Bob连贯到聊天室服务器的信息。
  • 步骤5：聊天室服务器A将音讯转发给聊天室服务器B。
  • 步骤6：应用推送机制将消息传递给Bob。
  • 步骤7：Bob将ACK发送回聊天服务器。
  • 步骤8：ACK被转发到Alice连贯的聊天服务器A。
  • 步骤9：ACK被传递给Alice，并被标记为已传递。
  • 步骤10：当Bob浏览音讯时（假如15分钟后），另一个ACK被发送到Chat_Server_B。
  • 步骤11：聊天室服务器申请获取Alice连贯的服务器。
  • 步骤12：聊天室存储返回Alice连贯到聊天室服务器的信息。
  • 步骤13：聊天室服务器B将读取确认转发给聊天室服务器A。
  • 步骤14：将ACK转发给Alice，将申请标记为已读。

场景2：向脱机用户发送媒体文件

上面介绍了序列图中向脱机用户发送图像的每个步骤的详细信息。

  • 步骤1：Alice向Bob发送一个图像，该图像被转发到聊天服务器A，Alice与之连贯的服务器。
  • 步骤2：聊天服务器将图像上传到文件服务器，文件存储在目录构造中
  • 步骤3：文件服务器将上传文件的图像url返回给聊天室服务器。
  • 步骤4：图像url返回给Alice，用于在Alice的设施上出现图像。图像被标记为在Alice端发送。
  • 步骤5：聊天服务器向Bob连贯的服务器发出请求。
  • 步骤6：聊天室存储返回Bob离线的信息。
  • 步骤7：聊天服务器将蕴含图像url的音讯转发给长期服务器
  • 步骤8：长期服务器将蕴含图像url的音讯存储在长期存储器中。
  • 第九步：Bob上线并与Chat_Server_B进行心跳（网站管理员包含链接）。
  • 步骤10：聊天服务器从长期服务器获取Bob的长期音讯。
  • 步骤11：聊天服务器将长期音讯转发给Bob。
  • 步骤12：Bob从文件服务器获取图像。此时，映像将被传送到Bob的设施，所有对瞬态音讯的援用都将从零碎中删除。
  • 步骤13：Bob的设施向聊天服务器发送Alice图像的确认
  • 步骤14：获取Alice连贯到的服务器的信息；i、 e.聊天室服务器
  • 步骤15：将确认转发至聊天室服务器
  • 步骤16：将ACK传递给Alice，将音讯标记为已传递。

瞬态数据存储

咱们能够应用基于FIFO的策略实现基于队列的机制来存储和检索瞬态音讯。为此，咱们能够应用现有的基于云的技术，如AmazonSQS或WindowsAzure队列服务。咱们能够应用这些队列来存储发送给脱机用户的长期音讯。一旦消息传递给脱机用户，所有对这些长期音讯的援用都将从零碎中删除。

推送告诉

应用推送技术向用户传递音讯有两种办法：客户端推送或服务器推送。如果咱们沿着客户机申请的路线走上来，咱们能够在长轮询和短轮询之间做出决定。另一方面，有两种办法能够实现服务器推送办法：WebSocket和服务器发送事件（SSE）。Websockets曾经成为聊天应用程序事实上的通信协议。咱们在上面的局部中提供了无关它的更多详细信息。

应用轮询技术，客户机定期向服务器申请新数据。抉择轮询技术的衡量决定能够应用上面提到的数据点。

  • 短轮询:（例如，基于AJAX的计时器）
  • 长处：如果申请之间的工夫距离较长，则更简略且不太耗费服务器
  • 毛病：不适用于须要以最小提早告诉服务器事件的状况
  • 长轮询：（例如，基于XHR的Comet）
  • 长处：服务器事件的告诉不会提早
  • 毛病：更简单，耗费更多服务器资源

将服务器音讯推送到客户端的办法次要有两种类型。第一种是WebSocket，它是一种通信协议。它通过单个TCP连贯提供双工通信信道。因为双向通信，它非常适合聊天应用程序等场景。另一种称为服务器发送事件（SSE），它容许服务器在建设初始客户机-服务器连贯后异步向客户机发送“新数据”。SSE更适宜发布者-订阅者模型，如实时流式股票价格；twitter提供更新和浏览器告诉。

用户活动状态

用户最初一次处于活动状态是能够在即时消息中找到的规范性能。咱们在下面的表1中展现了存储相干信息的数据模型

在图4中，咱们展现了应用WebSocket在客户端和服务器之间保护连贯的机制。一旦在客户端和服务器之间建设了初始连贯，通信就会切换到双向二进制协定。客户端和服务器之间的连贯应用心跳放弃活动状态。咱们将上次从用户接管心跳的工夫存储在数据库中。而后能够查问数据存储以获取用户上次流动的工夫。

优化

咱们能够应用上面列出的参数来倡议零碎中的优化。在本文中，咱们提供了倡议系统优化所应遵循的办法的详细信息。

  • 提早：咱们能够应用分布式缓存（包含指向分布式缓存的链接），例如Redis，在内存中缓存用户活动状态及其最近聊天的信息。这可能有助于缩小应用程序的总体提早，并提供更好的客户体验。甚至一些数据库解决方案也提供了内存缓存解决方案，如Amazon DynamoDB Accelerator。
  • 基础设施老本：从零碎中能够显著看出，聊天服务器对基础设施老本的重要奉献。如果不管制聊天服务器的脚印，那么聊天服务器产生的老本可能会迅速减少。一种办法是减少每个主机的连接数。这将大大减少保护服务所需的服务器数量。咱们能够通过调整服务器配置和抉择适合的技术来实现这项工作。例如，WhatsApp的工程师通过优化基于Erlang的服务器应用程序和调优FreeBSD内核，可能在每台主机上实现数百万个连贯
  • 可用性：咱们能够保护长期音讯的多个正本，这样即便其中一个正本中的音讯失落，也能够从另一个正本中检索。这意味着要保护这些长期音讯的正本。客户端将负责从两个队列获取音讯，并将它们合并。咱们将在下一节中探讨更多内容。

解决瓶颈

零碎中更容易产生故障的次要瓶颈是聊天服务器和长期存储解决方案。在上面的局部中，咱们举荐了一些解决此类故障的办法。

  • 聊天服务器故障：零碎中的聊天服务器将放弃与用户的连贯。有两种解决聊天服务器故障的办法。一种办法是将这些TCP连贯传输到另一台服务器；然而，这种故障转移的实现并非微不足道。第二个绝对简略的办法是让用户客户端在连贯失落的状况下主动启动连贯。用户连贯到的服务器的信息须要在数据库中更新，这与咱们采取的办法无关。例如，在图5中，咱们展现了解决此故障场景的示例。咱们能够看到User1连贯到Server1，当该服务器敞开时，将从新建设与另一台服务器（即Server2）的连贯，并在数据库中更新此信息。

  • 瞬态存储故障：瞬态存储是另一个容易产生故障的组件，可能会导致脱机用户在传输过程中失落音讯。咱们能够复制每个用户的长期存储，以避免在他们脱机时发送给他们的音讯失落。当用户从新联机时，将查问并合并用户长期存储的原始实例和正本实例。在图6中，咱们展现了一种解决刹时存储故障的机制，该故障在用户从新联机时启动。

监测

咱们心愿确保咱们的服务可能以高可用性和低提早满足用户需要。咱们能够为这些指标定义服务级别协定（SLA），并创立中度和重度监控器，当违反这些SLA时，这些监控器会触发警报。对于此应用程序，咱们能够为sendMessage API定义以下SLA。

  • 可用性SLA:p99.999
  • 提早SLA:p99.99，共5毫秒

可用性SLA意味着，如果1000个申请中有1个以上失败，监控器将触发警报。同样，提早SLA意味着，如果服务器对其接管的100个申请中超过1个申请的响应工夫超过5毫秒，则会触发警报。

此外，咱们能够在不同的谬误场景中设置故障警报。当聊天服务器无奈从长期存储的所有正本中为用户获取长期音讯时，可能会呈现这种状况。这映射到下面图3所示的步骤#10，其中聊天服务器#B申请长期服务器在Bob脱机时获取发送给Bob的音讯。让咱们假如咱们在长期存储器中保护Bob音讯的两个正本，以使零碎更加强壮。然而，因为长期存储的长期问题，长期服务器无奈从两个正本检索音讯。这是一个须要调试的谬误场景，因而须要足够的监控警报。

扩大要求

咱们能够扩大零碎以反对群组聊天，通过群组聊天咱们能够将消息传递给多个用户。咱们能够创立一个数据模型来存储组数据实体，该实体将由GroupChatID标识，并将用于保护属于该组的人员列表。上述零碎可扩大以反对向在线和离线用户发送音讯的场景。咱们能够构建一个组件，该组件将负责确保依据组中所有用户的活动状态将消息传递给他们。

作为此问题的扩大，能够涵盖的另一个方面是安全性，特地是端到端加密，其中只有通信用户能够读取音讯。每个用户都有一个公钥，该公钥与该用户正在通信的所有其余用户共享。例如，两个用户Alice和Bob正在互相通信。Alice领有Bob的公钥，反之亦然；然而，它们的私钥不共享。当Alice向Bob发送音讯时，该音讯应用Bob的公钥加密并通过网络发送。服务器将加密的音讯定向给Bob，Bob应用私钥解密音讯。这样，服务器只能拜访加密的音讯，只有Alice和Bob能力读取他们替换的理论音讯。

OpenIM github开源地址：

https://github.com/OpenIMSDK/...

OpenIM官网 ：https://www.rentsoft.cn

OpenIM官方论坛：https://forum.rentsoft.cn/

咱们致力于通过开源模式，为寰球企业/开发者提供简略、易用、高效的IM服务和实时音视频通信能力，帮忙开发者升高我的项目的开发成本，并让开发者掌控业务的外围数据。

IM作为外围业务数据，平安的重要性毋庸置疑，OpenIM开源以及私有化部署让企业能更放心使用。

现在IM云服务商免费高企，如何让企业低成本、平安、牢靠接入IM服务，是OpenIM的历史使命，也是咱们后退的方向。

如您有技术下面的浅见请到咱们的论坛分割沟通，用户也可与咱们的技术人员谈讨应用方面的难题以及见解