1. IM的业务规划、模块划分、技术选型

在上文中大概提了下为什么要做这个事情的初衷,以及后续的一些步骤规划。那么今天就会从IM的业务规划、模块划分,以及技术选型三个方向来聊一聊接下来该怎么使用Erlang去搭建一套完备的IM服务。

业务规划

IM的功能点其实可以加很多,比如聊天,可以从形式上扩展为群聊,单聊。还可以从内容上分为语音消息,文本消息,图片消息。从用户体验上来说,还可以区分,推送消息等等。

简单来说,我们此处将IM的业务简化为三大类:

  1. 好友关系
  2. 聊天
  3. 推送 & tunnel


    IM业务划分

接下来说下对这三类业务的具体规划:

  • 好友关系
    目前市场上存在的IM,对于好友关系的区分来看,大致分为两类:

    1. 强关系。 如:QQ,微信,What's App。也就是,首先需要加为好友,才能进行聊天。
    2. 弱关系。如:蘑菇街的IM,阿里旺旺,58 IM,京东IM。

    从应用场景上来说,强关系类型的IM注重的聊天的过程,而一些功能点都是基于聊天来做扩展。而弱关系类型的,更多是注重非IM的业务,IM更像是作为类似客服投诉通道的角色存在。

    而在此处,我们选择使用强关系的方式来构建我们的IM。毕竟,我们只做IM,只关心IM。而且,弱关系类型其实本质上也是存在好友关系,只是对用户不可见,默认聊天就建立关系。

  • 聊天

    对于聊天的内容,我们支持主流的文本消息、语音消息、图片消息、表情消息。也要考虑下扩展类型消息。诸如:红包消息,分享消息,地理位置消息等等。
    对于聊天的形式,支持单聊、固定群组、讨论组的方式。

    对于实时对讲、视频聊天暂时不做开发。

  • 推送 & tunnel

    严格意义上来说,推送应当作为聊天存在。不过从应用场景上来说,推送一方面是作为运营内容信息的推广使用,另外一方面是考虑到移动App特有的存在形式(尤其是iOS,进程在后台hung住),推送消息的作用就是更友好的告知用户有新消息达到。

    而tunnel作为IM的链路通道存在,作为文件传输等需要长时间占用链接,发送大文本内容的链路。也作为可扩展、可共用的链路形式存在。

模块划分

IM功能点模块划分

技术选型

  • 开发语言
    关于开发语言,其实并不存在选择余地(在这个系列中)。因为作为Erlang的支持者,不用Erlang,那还像话嘛。

  • 存储
    存储分为两块:持久化和缓存。分别使用mysql和redis来支撑。

  • 网络
    网络通信主要依赖于TCP方式进行通信。当然关于最近比较火的一则新闻:苹果要求2016年初商家的App必须提供IPV6的支持。那么,在我们的网络通信实现上,也会对IPV6做支持。要紧随时代的步伐嘛。

  • 通信协议
    通信协议的话,其实使用protocol buffer更为合适。

  • 进程间数据同步
    关于进程间的接口调用,暂时不打算使用RPC的方式去做支撑。而进程间的数据同步,使用redis进行支持。当然也可以选择诸如rabbitMQ来支撑。不过,目前这个阶段,暂时不打算把技术分散。并且,redis支持订阅、发布的方式,足够支撑消息队列。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容