openfire服务器搭建(openfire的售后)

zzxiexin 1 0
初期架构

从2015年刚开始,我加入了一家做社交软件的创业公司。那时候公司才刚起步,一切都是从零做起。我们的社交产品,主要针对年轻人做陌生人社交,提供匹配,社区,小游戏等新奇的玩法。由于后台只有1到2人,再加上版本迭代快,而且业务还比较简单。就选用了下面这样一个简单架构,能够满足初期的业务发展。

初期架构

对这个架构说明一下

首先,是确定一个简单的框架用来快速开发,rop+spring+mybatis所有业务都在一个工程,开发会方便很多所有存储都是用mysql,不用考虑太多数据一致性,数据分片等问题IM用开源的openfire框架来搭建图片等静态资源也是简单存储在自己服务器上

这个架构具有以下特点:

单体架构,架构简单,清晰的分层结构;可以快速研发,满足产品快速迭代要求;没有太复杂的技术,可以专注于做业务,实现快速开发;

这个架构大概支撑了1年,这个时候业务接口请求最多并发量是50次/秒,日活几万,总用户刚过百万,还算是可以撑得住。

中期架构变迁

到了16年,随着用户量增加,每天日活也是大涨。另外,业务本身也变得丰富和复杂,增加了支付,送礼,多人游戏,多元化的匹配方式。一到晚上高峰期就很容易挂,主要集中在2类问题上。一类是大面积用户收发消息有问题,另外一类是db大量慢查询。所以,到了必须升级架构的阶段。具体做了如下架构升级和优化

openfire加入链接管理器,改造快速登录,应用层加消息确认机制,能最多支持8w人同时在线存储多加一层缓存,加入redis数据库读写分离数据库迁移到rds图片转用cdn对于接入层做了一些优化,nginx部署多台,前面还加一层slb

架构图如下:

中期架构

这个架构大概支撑了大半年,可是到了16年下半年,用户量突增,日活也到达了好几十万。这个中期架构暴露了如下问题:

所有表都在同一个库里,而且一些统计类,离线类,日志类的数据也都是用同一个db存储所有业务接口都在一个应用里,任何一个修改都必须要全部发版本,而且整个工程也变得越来越臃肿,难以维护业务和IM以及cms相互通信暴露出了巨大问题,要不是通过rmi,要不就是直接用db或者是缓存来共享数据,以此来达到通信的目的

16年这个阶段是最痛苦的一年,总结如下:

现网层出不穷的问题,比如用户发不了消息,图片看不了,请求访问被拒绝后台一发版本经常出问题db经常出现慢查询每天现网问题需要解决的同时,版本开发也得跟上,还得做上面的架构升级后台人员还是非常少目前架构

既然有这么多问题,就要想办法解决,于是又做了一次大的架构升级,具体如下:

引入dubbo,拆分服务tomcat层开始做一些业务隔离,比如圈子整个就是单独的tomcatopenfire整体迁移到TIM

引入dubbo后,最主要的就是梳理现有业务,确定业务拆分的粒度,服务的职责,而且还需要考虑之后存储的拆分。服务拆分好了之后,还得配套设施也得跟上,在实施业务拆分的工程中,面临了如下难题。

开发调试的工作量大大增加,特别是在初期,同样一个接口,之前可能1小时内能搞定,现在得花半天时间拆分服务的时候,各种兼容性问题,各种服务依赖问题线上服务变多了之后,给发布运维带来了极大的挑战,需要一个快速,高效的发布系统定位问题变得复杂很多,需要一个个服务去查问题刚上线初期,几个量大的核心服务,经常rpc timeout

增对这些问题,具体做了如下大的改进

引进分布式调用链监控,从sql,url到服务,整个监控立体化。及时发现线上问题,和系统的性能频颈。引进日志中心,对于排查问题有了根据微服务也在不断完善,整个团队对dubbo的掌控也在加强运维自动化的建设,比如发布自动化,数据清理自动化图片上传架构调整,改成前端直接上传到cdn的方式,减少服务器压力专门搭了一个搜索的es集群,并且把一些离线类,日志类的数据都改用其它存储,减少db压力团队会定期技术分享,相互提升

最新架构图如下:

最新架构

终结

架构是伴随业务慢慢迭代,没有最好的架构,只有最合适的架构。在做架构选型的时候,需要考虑到业务规模,版本迭代速度,团队实力等综合因素。特别是在创业公司里,做架构选型的时候,不要走的太前,也不要只满足当前,最好满足当前业务的前提下,稍微往前迈一步。

标签: #openfire服务器搭建

  • 评论列表

留言评论

 
QQ在线咨询
售前咨询电话
173-175-32776
技术支持电话
173-175-32776
嘿,欢迎咨询