im大型分佈式實時計費服務器系統架構2.0

整個創業團隊後臺就我一個設計,架構,和開發.一路上很辛苦,因爲遇到的問題很多很多,並不是想象的那麼簡單.本來2.0想用go語言開發的,簡單,又快,又支持熱更新.處理速度和c++差不多,但靈活度沒有c++高,沒有那麼多特性.設計一個複雜的Im系統,有點不合適.然後我又用回了c++,本人還是熱衷於c++,我使用很多語言,都沒有c++的靈活,好用.

感覺qt的類庫非常強大,還有它的機制,非常容易擴展,所以還是繼續qt+epoll模型.


我重新設計了以前1.0服務器不足之處,整個服務器性能提升到將近20倍左右,並支持動態擴容,容易維護和升級.能夠分佈到全球不同地方,包扣一套運維繫統的架構,能夠實現方便的管理.

我們服務器系統業務邏輯非常複雜,超過了騰訊的業務邏輯,對於一般的IM軟件只需要發送消息到目標客戶端就可以了,而我們這套系統需要對視頻時間和每條消息進行實時計費,如果接受者無法在這段時間內回覆消息就得重新轉發到其他客戶端,一直到此條消息有人回覆或者生命週期結束.並且支持消息類型的過濾,消息發送的算法優化.保證數據的安全性和計費的準確性,所有計算全部都是由服務器來承擔的

客戶端能夠支持消息預約,消息條件的過濾,消息的生命週期,當前用戶的狀態.離線消息,推送消息,電子郵件的通知,數據的校驗,充值的反饋

,快速拉取個人信息和記錄.


1.增加了數據同步服務器,在整個集羣裏面只存在一個用戶實例,個人數據信息的實時同步.

2.數據庫採用redits+msyql集羣組合,從以前單臺數據庫處理速度升級到 4000+/s升級到70000+/s

3.離線消息系統獨立,離線消息系統從以前和業務服務器分離開來了,成爲一條獨立的系統和apns推送集羣銜接在一起了,這樣能夠更加快速進行離線推送到用戶移動端上.

4.獨立的apns輪詢推送集羣,對於移動端用戶來說,大多數用戶都是待機狀態,當每秒要推送上千或者上萬,單臺apns推送服務器根本就沒法支撐,所以設計了apns輪詢推送機制,能夠減輕服務器的負載,並且快速進行推送

5.充值服務器實時響應,服務器不停的會對大量用戶進行實時計費,考慮到大量充值事件響應,獨立到一臺服務器上,paypal的ipns通知事件,能夠立刻更新當前用戶的賬戶金額.

6.狀態監測服務器,能夠監測當前業務服務器的負載狀態,並實時更新和發送到負載最小的業務服務器給客戶端登陸

7.數據驗證服務器,對用戶登入信息進行驗證,並通知到需要的登入的業務服務器,防止用戶非法登入.

8.消息管理服務器,對消息轉發到幾十個相應的接收者上,生命週期的計算,消息的計費,視頻消息的實時計費,無人響應的轉發規則,預約消息的轉發規則

9.後臺服務器管理端,能否對不同類型的服務端進行配置和設定,每條服務端日誌的記錄.

10.web後臺管理系統的設計,對用戶的信息進行管理和操作.金額的統計,資金流的發放.

11.當然也有一套強大監控系統,服務端監控和服務器監控平臺,服務器監控平臺用的是監控寶,服務端用的自己開發的.


服務器架構圖:


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章