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.当然也有一套强大监控系统,服务端监控和服务器监控平台,服务器监控平台用的是监控宝,服务端用的自己开发的.
服务器架构图:
