单体架构IM系统1:业务背景+研发策略+技术选型

先直接抛出业务背景!

有一款游戏,日活跃量(DAU)在两千左右,虽然 DAU 不高,但这两千用户的忠诚度非常高,而且会持续为游戏充值;为了进一步提高用户体验,继续增强用户的忠诚度,老板想要在该款游戏中引入聊天功能,同时探索和验证游戏用户对 IM 的需求和依赖度。IM 需要在两周后上线,如果你是这个 IM 项目的架构师,带着两名经验尚欠的程序员,你如何设计并落地该 IM 系统?

业务背景并不复杂,简单总结一下:

  1. 用户规模小:DAU 在两千左右,同时在线人数高峰期不到200;
  2. 开发人员少:一名架构师加两名程序员;
  3. 开发时间短:一周开发加一周测试,只有两周时间。

这种情况下,研发策略通常是:怎么简单就怎么做,怎么快就怎么来!

所以对该 IM 系统采用【单体架构】的方式进行设计,见下图。

图片

前端是运行安卓系统和 IOS 系统的移动设备,游戏 APP 内嵌 IM 的客户端,由前端同学负责开发。

后端是 Server 节点,通过多进程多机器部署的方式,避免 “单点”;这个地方需要注意:【单体架构】并非 “单点架构” ,单体架构仍然是分布式架构的一种,通过集群的方式提供高可用和高吞吐的服务;对多个 Server 节点的访问通过 Nginx 来做反向代理;Server节点由后端同学负责开发。

存储部分包括数据库和缓存,数据库中分别创建 “消息表”、“离线消息表”、“联系人表” 和 “用户表”;缓存用来记录用户的在线信息;数据库和缓存由 DBA 同学负责维护。单体架构的系统,最大的优势就是在项目前期开发简单、部署简单、测试简单、运维简单,开发同学几乎可以将所有的注意力全部放在业务逻辑上,实现真正的【快速落地】。

下面分别讨论一下关键的技术选型:前端与后端的通讯协议、后端的编程语言、数据库选型。

一、通讯协议

前端与后端之间的通讯协议,有四种选择,见下表。

单体架构IM系统1:业务背景+研发策略+技术选型

IM 系统通常会选择 “长连接” 类型的协议;但是 WebSocket 协议因为刚推出不久,成熟度不高;TCP 协议属于传输层协议,较为复杂,如果没有丰富的 TCP 网络编程经验的话,在研发时间非常紧张的情况下,建议不要选择 TCP。

所以,这里我们选择最简单和最容易落地的协议—Http;对于编程经验尚欠的应届生来讲,Http编程也不会有太大难度。

分析到这里,相信大家肯定有这样的疑惑:Http 是短连接的无状态协议,如何进行消息的即时通讯呢?难道是通过客户端周期性的轮询访问吗?是的,同时在线人数只有几百的情况下,客户端周期性轮询是完全没有问题的,况且Server是多节点部署,完全可以 Cover 客户端周期轮询的压力。

二、编程语言

Server 端编程语言,也有四种选择(公司内部正在使用的技术栈),见下表。

图片

C++、Java、PHP、Go 四门编程语言都有非常成熟的并发编程模型,这里我们选择公司和团队最熟悉的语言—Go,使用最熟悉的语言才会带来更高的编程效率和更快的问题解决速度。

三、数据库选型

数据库选型有三种选择,分别是关系型 SQL 数据库—MySQL、非关系型 NoSQL 数据库—MongoDB、已经新兴的NewSQL 数据库—TiDB,见下表。

图片

在该单体架构的 IM 系统中,数据库需要提供强事务能力,来保证业务的完整逻辑;同时,数据库需要做到更低成本的运维;这里我们选择满足需求和容易运维的数据库—MySQL。

总结文中关键:

1、业务背景:用户规模小、开发人员少、开发时间短;

2、研发策略:怎么简单怎么做,怎么快怎么来;

3、IM单体架构:前端(APP)+ Server + 数据库

     单体架构最大的优势就是在项目前期开发简单、部署简单、测试简单、运维简单。

4、技术选型:

     选择最简单和最容易落地的协议—Http,

     选择公司和团队最熟悉的语言—Go,

     选择满足需求和容易运维的数据库—MySQL。

最后,提出一个思考问题,我们会在下篇技术短文中进行分析:

基于该 IM 单体架构,如何实现用户的登录和收发消息呢?Server 节点是无状态化的吗?

作者:棕生,来源:架构之魂(喜欢他的文章可以到公众号进行关注)

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

发表回复

登录后才能评论