可处理数千个请求的体系结构

时间:2019-12-02 15:30:55

标签: amazon-web-services

我目前正在质疑我们4年前(以前的开发人员完成)的体系结构。 我们约有10个大客户(在不同时期完成了大量请求),其中有2个每分钟可能有100.000个从移动应用程序到后端的连接(对我来说这没什么大不了的)。

这是我们当前的体系结构:

  • 1个负载均衡器
  • 4到8个前端(取决于我们必须处理的事件)-8vCPU / 30Go RAM
  • 3个后端-2vCPU / 11Go RAM
  • 2个摄取器(用于从提供程序收集数据并将其放在后端DB上)-2vCPU / 5Go RAM

以下是在此体系结构上全局运行的服务:

  • 摄取器/后端的RabbitMQ
  • 在后端进行弹性搜索
  • 前端的NSAPI

这是平台的工作方式:

Ingesters以定义的频率(例如每3分钟一次)从提供者收集数据,将其推送到RabbitMQ队列中。后端上的RabbitMQ使用者将使用RabbitMQ队列并将数据集成到Elastic Search中。前端包含要调用的端点,并且将在后端ES上获取数据(它也具有nginx缓存)。

这里是问题:

  • 从未维护版本,因此例如ES似乎真的很慢
  • 当来自前端的呼叫数量很高时,Elastic Search会完全满足要求,无法再从RabbitMQ提取数据。

我对此有何看法:

我想使用它们的服务完全切换到功能性AWS架构,因为实际上我觉得我们像专用服务器一样使用EC2,而没有利用服务。 对我来说,一个简单的架构就可以完成工作,例如:

  • EC2上的Ingester(用于在NodeJS上运行我们想要的数据进行自定义)
  • PostgreSQL上的RDS(8vCPU / 32GB RAM)
  • Lambda,用于从后端到数据库的计算
  • API网关具有高度可扩展的前端
  • 用于监视的Cloudwatch

我不是AWS方面的专家,这似乎是一个不错的选择,或者您有任何想法来改进此架构?

0 个答案:

没有答案