在上文中大概提了下为什么要做这个事情的初衷，以及后续的一些步骤规划。那么今天就会从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的链路通道存在，作为文件传输等需要长时间占用链接，发送大文本内容的链路。也作为可扩展、可共用的链路形式存在。
模块划分
技术选型
开发语言
关于开发语言，其实并不存在选择余地（在这个系列中）。因为作为Erlang的支持者，不用Erlang，那还像话嘛。存储
存储分为两块：持久化和缓存。分别使用mysql和redis来支撑。网络
网络通信主要依赖于TCP方式进行通信。当然关于最近比较火的一则新闻：苹果要求2016年初商家的App必须提供IPV6的支持。那么，在我们的网络通信实现上，也会对IPV6做支持。要紧随时代的步伐嘛。通信协议
通信协议的话，其实使用protocol buffer更为合适。进程间数据同步
关于进程间的接口调用，暂时不打算使用RPC的方式去做支撑。而进程间的数据同步，使用redis进行支持。当然也可以选择诸如rabbitMQ来支撑。不过，目前这个阶段，暂时不打算把技术分散。并且，redis支持订阅、发布的方式，足够支撑消息队列。
