有很多朋友的項目需要用到即時通訊，幾年前鄙人的項目也是如此，當年沒有選擇，只能自建了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之路坎坷，君請三思而行。