一、融云接入架构
融云在进行接入时，具有不影响原APP架构的特性，提供有专门的sdk用于进行APP端的开发。在不需要自身服务器的前提下，可以使APP与融云服务器进行自行交互。同时服务端可以与融云服务端以API调用的形式进行互相交互，提供的功能有消息推送，消息路由，群组管理，聊天室管理，聊天记录下载等。
二、融云的聊天类型
1. 1V1单聊
1v1单聊是指A直接向B发送消息，然后A与B产生的消息对接，消息的对接列表由客户端自己进行维护，融云不会进行维护用户的聊天列表，只会进行维护用户的聊天记录，并且，该聊天记录仅保存6个月。（如果用户A分别和B、C、D三个人进行了聊天，然后清空APP数据，则再打开时就无法获取之前的聊天列表了，但是重新发起聊天以后，可以获取到历史的聊天消息记录）
2. 群组聊天
群组聊天与微信群一样，在加入一个群后，该群中只要产生新的消息，就会发送给群内的每一个用户。但是在融云的服务器，不会维护群的列表信息，用户所加入的群的列表，需要由我们自己的服务端进行控制维护，并且融云不提供拉取某用户加入的群的功能。
3. 聊天室聊天
聊天室与群组聊天具有不同，群组聊天是在退出群组界面后，依然会给群成员发送推送，而聊天室则不会继续发送推送。（本质上可以理解为一个在退出聊天界面以后，就退出的一个群聊。）
三、服务端开发方案
1. 最简单的聊天-Server零改动
如果希望实现一个最简单的聊天系统，直接可以使用融云的聊天系统进行接入APP，后端无需任何接口进行来与APP进行对接即可实现最简单的聊天功能。但是在进行开发时，如果采用最简方案，将会出现无法获取到用户之间的聊天记录的问题，因此需要使用融云的消息路由服务进行消息的同步，或者通过下载聊天记录文件的形式进行聊天记录的获取。
2. 消息路由-实时消息保存
在融云上，提供了消息路由服务，该服务的用途为将用户所发送的消息内容转发到一个指定的接口。如果该接口没有正常的响应，则会再重新推送两次，如果依然失败则会将不会再进行消息的推送。利用这个功能，我们可以对用户的消息进行实时保存，也可以用于与正在使用的第三方IM进行兼容使用，便于用户从其他第三方平台迁移到融云。
3. 第三方平台迁移 
上图为融云官方所给出的迁移后的消息收发流程，在进行消息收发时，需要由我们自己的服务器，将每一条收到的融云消息转发到旧的第三方IM平台，同时将每一条旧的IM平台收到的消息转发到融云平台，这样就可以实现融云与旧的IM平台进行互通聊天。
4.融云带来的问题
如果完全依托于融云进行对接，则会面临以下的问题：
- 对接IM会话的列表页无法进行UI层面以及数据的完全自定义：再融云的SDK中，对接的列表页将会由融云来提供，我们仅能做一些极少的UI改动。因此我们无法过多的自定义融云会话列表的UI以及内容。例如我们希望做一个招聘软件，此时，我们的会话对接页面，将无法在列表上直接提供所沟通的岗位。
- 离线消息仅保存七天：如果A用户向B用户发送消息，但是B用户7天中都处于离线状态，而B用户在七天后登录了APP，重新处于上线状态，此时A向B发送的消息仅会保存七天就不再进行推送了，会造成A和B的消息不同步的问题。即，如果一个用户出现了七天以上的离线，那么会丢失 上一次下线时间 ~ （当前时间-7天）的所有聊天信息。
- 历史聊天记录问题：历史聊天记录仅会保存6个月，如果想要查看更早的聊天记录，则会无法查看。
- 如果清空本地数据，则无法获取之前的聊天列表：对于某些特定的APP，可能会出现数据清空后，无法重新发起会话的，或者查看历史消息记录的情况。
- 在对接列表中，不能穿插其他元素：在对接页面中，无法穿插推荐等信息，只能将这些信息放在某个特定的位置进行显示。
5.自定义的对接
在遇到需求不能接受融云所带来的问题时，可以只使用融云的自定义消息通知来进行设计对接。使用这种做法时，我们相当于使用在制作留言板的情况下，新增了实时对接的效果。可以可以自己来去实现APP的UI以及页面逻辑，同时，管理APP的未读已读数量等。可以使用下方的流程图进行处理（该流程图较为简单，实际使用需要添加很多逻辑）：
