在上文中大概提了下为什么要做这个事情的初衷，以及后续的一些步骤规划。那么今天就会从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支持订阅、发布的方式，足够支撑消息队列。