開發者自建IM服務器必需要解決的幾個問題！

有不少朋友的項目須要用到即時通信，幾年前鄙人的項目也是如此，當年沒有選擇，只能自建了IM服務器，幾年下來跨了很多的坑，想一想都甚是後怕。總結此文爲後來還想自建IM的朋友提個醒，或許能找到更好的解決之路。

 

1, 如何應對大併發量鏈接

本身組建IM服務器，老是要面對大併發量鏈接的，有些朋友可能會說，咱們用戶很少，不須要考慮這個問題，但至少應該將用戶控制在一個數量之內，不要讓意外增長的用戶影響到現有的用戶吧。那麼一臺服務器能夠支撐多少鏈接？又能夠支撐多少用戶同時發消息？

若是須要多臺服務器作集羣？須要怎麼作？架構又是如何的？

這些課題絕對不是幾我的短期就能解決的。開發者須要根據項目的具體狀況嚴謹地評估是否能夠處理這些問題。

 

  

2, 爲何老是莫名地斷線呢？

通常自建IM服務器都會使用現成的openfire等現成的開源部署，通過很多時間部署測試後正常運做。但一到了移動端這種網絡至關不穩定的環境後老是會出現各類各樣的奇怪問題，費盡力氣才發現原來是鏈接不穩定，常常斷線致使的。

那麼又如何來解決這個問題呢？

辦法不是沒有，只是至關繁瑣。須要很長一段時間的評估測試才能解決，甚至會更改原來的一些功能設計。

若是你沒有精通開源庫的專家，要想短期解決這些問題除了花大量時間以外就是使用其它方式巧妙避開它。

 

 

3, 爲何老是會丟消息？

  丟消息是自建IM服務器常遇到的問題,要解決這個問題也不容易。

移動端的丟消息大概是這個樣子。A和B通信，A發了一條消息給服務器，服務器發給B，可是B網絡很差掉線了，而服務器殊不知道B退出了（B正常退出會給服務器發下線通知），因此消息丟失了。XMPP中有xep-0184協議（消息回執），A給B發消息，消息體中帶一行代碼（要求消息回執），當B收到消息後發送一條回執，證實我收到了。後來XMPP又有了xep-0198協議（流管理），斷線後快速重鏈，同時判斷必定時間收不到消息，就把消息寫離線消息，減小丟消息狀況。可是可能網絡狀況複雜，加上各類不肯定因素，還會出現丟消息的問題。 

  目前比較靠譜的方法就是存全部的聊天記錄，由手機端根據時間點去數據庫拉消息，只要別人發出的消息就不會丟。這要對即時通信模塊進行了相關改動，同時須要注意消息的順序，拉消息時也儘量只拉取須要的消息，這時須要一個較好的完整同步機制，這個機制推薦參考yun2win的同步機制http://console.yun2win.com/docs/server.html。

這裏須要花費多少時間成本，能夠感覺一下。 

 

 

這裏只是列出了比較常出現的幾個問題，自建IM服務器成本不小，不論是硬件成本仍是開發成本以及運營風險上。評估本身項目是否須要自建IM服務器通常是如下幾種狀況：

1，擁有自主的即時通信技術的狀況下

2，項目保密性很高，須要絕對保證數據安全

很差意思，在如今PAAS盛行的時代我還真沒法想出更多須要自建IM的理由了，以上兩點貌似看上對比較立得住腳。

其它第2點提到的數據安全如今好像也不能算是自建IM的理由了，由於市面上已經出現數據和通信分開物理隔離的即時通信雲，能夠百度下yun2win。

總之，自建IM之路坎坷，君請三思而行。