在上文中大概提了下为什么要做这个事情的初衷,以及后续的一些步骤规划。那么今天就会从IM的业务规划、模块划分,以及技术选型三个方向来聊一聊接下来该怎么使用Erlang去搭建一套完备的IM服务。
业务规划
IM的功能点其实可以加很多,比如聊天,可以从形式上扩展为群聊,单聊。还可以从内容上分为语音消息,文本消息,图片消息。从用户体验上来说,还可以区分,推送消息等等。
简单来说,我们此处将IM的业务简化为三大类:
- 好友关系
- 聊天
-
推送 & tunnel
IM业务划分
接下来说下对这三类业务的具体规划:
-
好友关系
目前市场上存在的IM,对于好友关系的区分来看,大致分为两类:- 强关系。 如:QQ,微信,What's App。也就是,首先需要加为好友,才能进行聊天。
- 弱关系。如:蘑菇街的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支持订阅、发布的方式,足够支撑消息队列。
网友评论