企业级后台管理与移动端数据采集系统Nginx+MQ+Redis架构演进

对于一个应用系统的演化进程跟用户量有直接关系,只有不断地调整自己的架构满足用户的需求才是第一位的,受益者不光是用户还有企业甚至是开发人员。一个阶段性的东西,只是针对具体情况的分析和实践,所谓架构就是高层建筑,需要考虑高可用性、可扩展性、可维护性、简单易部署。本次博客主要讲解移动端并发和附件上传对后台服务造成影响之后我们做的调整方案及后期规划,对于数据库层面数据量暴增对后端的影响本篇暂不做论述。

目录

第一版

原始阶段:Tomcat+Mysql

实验阶段:Nginx转发拆分移动端附件上传接口-仅分离附件接口

第一阶段:Nginx(附件静态代理+服务转发)

第二阶段:Nginx(css/js附件等静态资源代理+服务转发)+Redis

第三阶段:Nginx前后端分离+服务或微服务集群+Redis集群+MYSQL主备

第二版

原始阶段:Tomcat+Mysql

实验阶段:Nginx转发拆分移动端附件上传接口-仅分离附件接口

第一阶段:Nginx(附件静态代理+服务转发)

第二阶段:Nginx(css/js附件等静态资源代理+服务转发)+Redis

第三阶段:Nginx前后端分离+服务或微服务集群+Redis集群+MYSQL主备

MQ数据分析能力

Redis发布订阅

MQ消息队列


第一版

原始阶段:Tomcat+Mysql

缺点:前后端融合在一起,高并发应用场景下,后端受到服务器性能和tomcat处理性能的限制。

结论:实施新的架构方案,解决一部分并发问题。

实验阶段:Nginx转发拆分移动端附件上传接口-仅分离附件接口

缺点:需要移动端从后台服务端获取移动端Token接口。

结论:真实的情况是移动端并发导致后台服务无响应,而非附件上传接口,这个跟tomcat的优化和配置有一定关系。

第一阶段:Nginx(附件静态代理+服务转发)

缺点:最早的内存缓存数据大多是移动端数据,获取用户位置信息需要移动端提供接口给后台访问。

结论:很好地避免了移动端并发对后台服务的影响,但后端服务还有优化空间。

第二阶段:Nginx(css/js附件等静态资源代理+服务转发)+Redis

缺点:没有实现负载均衡,MYSQL数据量快速增长问题或不能短期得到解决,并发量再上一个台阶架构难以支撑。

结论:能够提升后端管理系统页面DOM加载速率及相关组织机构的查询速度,用户体验得到提升。

第三阶段:Nginx前后端分离+服务或微服务集群+Redis集群+MYSQL主备

缺点:MYSQL数据库主备能一定程度解决数据灾难问题,整体架构实施复杂度增加;如果采用微服务,需要前后端进行重构,工作量比较大周期长。

结论:能够很好地解决并发上来之后保证用户高可用性,依然没有解决数据量大的时候数据查询性能问题。
 

第二版

原始阶段:Tomcat+Mysql

缺点:前后端融合在一起,高并发应用场景下,后端受到服务器性能和tomcat处理性能的限制。

结论:实施新的架构方案,解决一部分并发问题。

实验阶段:Nginx转发拆分移动端附件上传接口-仅分离附件接口

缺点:需要移动端从后台服务端获取移动端Token接口。

结论:真实的情况是移动端并发导致后台服务无响应,而非附件上传接口,这个跟tomcat的优化和配置有一定关系。

第一阶段:Nginx(附件静态代理+服务转发)

缺点:最早的内存缓存数据大多是移动端数据,获取用户位置信息需要移动端提供接口给后台访问。

结论:很好地避免了移动端并发对后台服务的影响,但后端服务还有优化空间。

第二阶段:Nginx(css/js附件等静态资源代理+服务转发)+Redis

缺点:没有实现负载均衡,MYSQL数据量快速增长问题或不能短期得到解决,并发量再上一个台阶架构难以支撑。

结论:能够提升后端管理系统页面DOM加载速率及相关组织机构的查询速度,用户体验得到提升。

第三阶段:Nginx前后端分离+服务或微服务集群+Redis集群+MYSQL主备

缺点:MYSQL数据库主备能一定程度解决数据灾难问题,整体架构实施复杂度增加;如果采用微服务,需要前后端进行重构,工作量比较大周期长。

结论:能够很好地解决并发上来之后保证用户高可用性,依然没有解决数据量大的时候数据查询性能问题。

MQ数据分析能力

Redis发布订阅

利用Redis的pub/Sub特性,实现消息的发布订阅。通过订阅类型进行消费处理。鉴于消息可靠性等考虑采用MQ,这种方案仅做参考。

说明:

  1. 后端和移动端发布Redis主题消息
  2. 数据统计分析服务订阅Redis主题内容
  3. 数据统计分析服务接收到Redis订阅主题内容后进行计算
  4. 数据统计分析服务将计算结果放入Redis缓存起来|将结果保存到MySQL

MQ消息队列

MQ主要的作用就是实现应用解耦、流量削峰、保证顺序执行、发布订阅、点对点通信以及异步操作问题。引入MQ主要是基于统计数据计算服务而存在,目的是为了将运算类业务需求单独提成服务独立运行,通过异步计算统计分析结果并缓存在Redis中或将周期性的统计结果保存到MySQL数据库中。

说明:

  1. 后端和移动端发布MQ主题内容
  2. 数据统计分析服务订阅MQ主题内容
  3. 数据统计分析服务接收到MQ订阅主题内容后进行计算
  4. 数据统计分析服务将计算结果放入Redis缓存起来|将结果保存到MySQL
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值