具体解释就是:
1)高可靠:确保不丢消息;
2)高可用:任意机房或者服务器挂掉,不影响服务;
3)实时性:不管用户在哪里,在线用户消息在1秒内达到(我们实际是75%消息可以做到120ms);
4)有序性:确保用户消息的有序性,不会出现发送和接受的乱序。
5、架构拆分
从整体架构上来说,亿级用户量的IM架构整体上偏复杂。
传统开源的IM服务喜欢把所有服务做到1-2个服务里(Connector+Service模型),这样带来的问题比较严重。
传统开源的IM的问题主要体现在:
1)服务代码复杂,难以持续开发和运维;
2)单一业务逻辑出问题,可能会影响到其它逻辑,导致服务的全面不可用。
因此,我在做架构设计的时候尽量追求微服务化。即把整体架构进行分拆为子系统,然后子系统内按照业务逻辑分拆为微服务。
系统拆分如下图:
4个子系统的职责是:
1)IM业务系统:服务IM相关的业务逻辑(比如好友关系、群关系、用户信息等);
2)信令系统:负责用户登录,用户在线状态的维护,以及在线用户的下行推送;
3)推送系统:负责消息的在线推送和离线推送;
4)存储系统:负责消息和文件的存储和查询;
其中:信令系统和推送系统是基础设施,不只是可以为IM业务服务,也可以承载其它类似的业务逻辑(比如客服系统)。
在部署层面:采用存储3核心机房,信令和推送节点按需部署的方式(国内业务推荐8-10个点)。实际上我们只做了了北京3个机房,上海1个机房和香港一个机房的部署,就基本上满足了大陆+香港的业务需求。
下面将逐个介绍这4个子系统的细节方面。
6、IM业务系统
一说到IM,很多人脑海里跳出的第一个关键就是“即时通信”,技术上理所当然的联想到了socket,也就是大家成天嘴上说的:“长连接”。换句话说,很多对IM不了解或了解的不多的人,认为IM里的所有数据交互、业务往来都是通过“长连接”来实现的,这样话,对于本文章中拆分出的“IM业务系统”就有点不理解了。
实际上,早期的IM(比如20年前的QQ、MSN、ICQ),确实所有数据基本都是通过“长连接”(也就是程序员所说的“socket”)实现。
但如今,移动端为主端的IM时代,IM系统再也不是一个条“长连接”走天下。
现在,一个典型的IM系统数据往来通常拆分成两种服务:
1)socket长连接服务(也就是本文中的“推送服务”);
2)http短连接服务(就是最常用的http rest接口那些,也就是本文中的“IM业务系统”)。
通俗一点,也也就现在的IM系统,通常都是长、短连接配合一起实现的。
比如论坛里很多热门技术方案都是这样来做的,比如最典型的这两篇:《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?》、《IM消息送达保证机制实现(二):保证离线消息的可靠投递》,文记里提到的“推”其实就是走的“长连接”、“拉”就上指的http短连接。
对于socket长连接服务就没什么好说,就是大家最常理解的那样。
IM业务系统详细来说,就是专注处理IM相关的业务逻辑,比如:
1)维护用户数据:用户基本信息等;
2)维护好友关系:好友请求、好友列表、好友信息等;
3)维护群组信息:群创建、解散、成员管理等;
4)提供数据:离线拉取、历史记录同步;
5)其它逻辑:比如通过存储和推送系统,存储消息和发送通知;
按照微服务的原则,IM业务系统也被分拆为多个服务,比如:
1)GInfo服务:群组信息维护;
2)IM服务:处理1V1消息;
3)GIM服务:处理群组消息。
7、信令系统
7.1 基本情况
信令系统主要职责是3部分:
1)维护用户在线状态:
因为用户规模庞大,必然是多个集群,每个集群多台服务器为用户提供服务。
考虑到服务器运维的复杂性,我们要假定任何一个集群,任何一个服务器都可能会挂掉,而且在这种情况下要能够继续为用户提供服务。
在这种情况下,如果用户A给用户B发消息,我们需要知道用户B在哪个服务器上,才能把消息正确推送给用户B。用户在哪个信令服务,这个信息就是在线状态数据。
2)下行消息推送:
跟上一个职责有关,用户在线的时候,如果有其它用户给他发消息,那就最好不要走离线推送,而是走在线推送。
在线推送的最后一个环节,是把用户消息推送给用户设备,因为就需要知道用户登录到哪个服务器上。
3)业务分发:
信令服务不只可以处理IM请求,也可以处理其它类型的业务请求。为了处理不同的业务,就需要有分发能力。
具体做法是通过一个SVID(service id)来实现,不同的业务携带不同的SVID,信令服务就知道如何分发了。
用户通过登录服务把数据(比如IM消息)发送到信令系统,信令系统根据SVID转发给IM系统。不管后台有多少个业务,用户只需要一条链接到信令。
7.2 服务拆分
信令系统为了实现以上这3个职责,同时要确保我们服务可平行扩展的能力和稳定性,在实际的技术实现上,我们实际上把信令服务分拆为3个服务模块。
如下图所示:
下面将逐个介绍这3个子服务。
7.3 Login服务
Login服务主要负责维护用户长链接:
1)每个用户一条链接到Login服务,并按时间发心跳包给Login服务;
2)服务定时检查用户链接状态和心跳包,比如发现2个心跳周期都没收到心跳,就认为用户掉线了(有假在线问题,有兴趣同学可回贴讨论)。
Login服务收到用户登录请求以后,验证uid/cookie,如果成功就把这个用户的登录信息发送给online。
此过程主要记录的信息包含:
1)uid(用户id);
2)Login服务器IP/Port;
3)Route服务器的IP/Port。
如果用户发送IM消息,先发送到Login,Login转发给Route,Route根据服务的类型(SVID),发现是IM协议就发送给后端的IM服务。
Login对并发要求比较高,一般要支持TCP+UDP+Websocket几种方式,单服务可以做到10-250万之间。从服务稳定性角度触发,建议是控制VM的CPU/内存,单服务器以20-50万为合适。
Login服务器本身没有状态,任何一个Login服务断掉,用户端检测到以后重连另一个Login服务器就可以了,对整体服务可靠性基本没有影响。
7.4 Online服务
Online服务主要负责维护用户的在线信息:
1)如果用户掉线,Online服务里信息就是空;
2)如果用户在线,Online就能找到用户登录在哪个集群,哪个Login服务器上。
Online业务相对简单:多个Login服务器会连接到Online,定期同步用户登录和离线信息。
Online主要职责是:把用户状态信息存储在Redis集群里。因此也是无状态的,任何一个Online服务挂掉,不影响整体服务能力。
如果集群规模不大,用户规模也不大,Online服务也可以收到Login服务里去。
如果规模比较大,建议分拆出来,一方面简化Login的逻辑复杂度,同时避免写Redis的慢操作放在Login服务里。因为Login要同时处理50万以上的并发链接,不适合在循环里嵌入慢操作。
7.5 Route服务
Route服务的设计核心,是作为信令系统跟其它子系统的交互层。Route下接Login服务,可以接受用户业务信息(IM),也可以往用户推送下行消息。
多个后端业务系统可以接入到Route,按照服务类型(SVID, service id)注册。比如IM服务可以接入到Route, 注册SVID_IM。这样Login接收到SVID=SVID_IM的消息,转发给Route,Route就可以根据SVID转发给IM相关的服务。
Route简单的根据SVID做转发,不处理具体的业务逻辑,因此也是无状态的。一个信令集群可以有多个Route服务,任何服务挂了不影响整体服务能力。
8、推送系统
推送系统的核心任务:是接收到给用户发送下行消息的请求以后,去信令服务查询用户是否在线,如果在线走信令推送,如果不在线走离线推送(如iOS的APNS、华为推送、小米推送等)。
因为推送服务可能出现大规模并发蜂拥,比如大群激烈讨论的时候,会触发亿级的TPS。因此推送服务用Kafka做了削峰。
我在实际的技术实现上,将推送系统进行了如下细分:
具体就是:
1)PushProxy:接受用户的推送请求,写入Kafka;
2)Kafka:缓存推送服务;
3)PushServer:从Kafka获取推送请求,判断用户是否在线;
4)PushWorker:真正推送给信令或者APNS,华为推送等。
这里同样,除了Kafka以外每个服务都是无状态的,因为也可以实现平行扩展和容错,任何服务挂掉不影响整体服务可用性。
9、存储系统
存储服务主要是负责消息的存储和查询,因为消息量巨大,对存储服务的并发能力和存储量要求巨大。
为了平衡性能、空间和成本,存储服务按数据的热度进行了分级和区别对待。
具体是:
1)短期消息(7天):存储在Redis里;
2)近期消息(1-3个月):存储在Mysql里,以备用户实时查询;
3)历史信息:存储在HBase里,作为历史数据慢查询。
同时,为了应对超大群的大量消息处理,存储服务在实际的技术实现上,也做了比较细的分拆。
存储服务具体拆分如下图:
具体的业务划分就是:
1)MsgProxy:负责接受IM子系统的存储请求,写入Kafka;
2)MsgWriter:从Kafka获取写请求,按需写入Redis和Mysql;
3)MsgReader:接受用户的消息查询请求,从Redis,Mysql或者HBase读数据;
4)运维工具:主要是数据库的运维需求。
消息队列(Kafka)在这里角色比较重要,因为对于高并发请求(100万人公众号),需要通过消息队列来做削峰和并行。
在具体部署上:可能是3-4个MsgProxy,后端可以对应15个左右的MsgWriter。MsgWriter是比较慢的,需要同时操作多个数据库,还要保证操作的原子性。
10、本篇小结
本篇主要总结了这套亿级用户量IM系统的总体架构设计,为了高性能和横向扩展性,基于微信的理念将整个架构在实现上分成了4个子系统,分别是:IM业务系统、信令系统、推送系统、存储系统。
针对这4个子系统,在实际的技术应用层上,又进行了进一步的服务拆分和细化,使得整个架构伸缩性大大增强。
—— 下篇《一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等》稍后发布,敬请期待 ——
附录:相关文章