一、融雲接入架構
融雲在進行接入時，具有不影響原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的未讀已讀數量等。可以使用下方的流程圖進行處理（該流程圖較爲簡單，實際使用需要添加很多邏輯）：
