【问题标题】:What technology to use to avoid too many VMs使用什么技术来避免过多的虚拟机
【发布时间】:2017-05-06 17:41:13
【问题描述】:

我有一个小型网络和移动应用程序,部分运行在用 PHP (Symfony) 编写的网络服务器上。我有几个客户在使用该应用程序,并逐渐扩展到更多客户。

目前我的后端架构是这样的:

  • 数据库是在 GCP 上运行的 Cloud SQL(每个客户端都有自己的 数据库实例)
  • 文件存储在云存储 (GCP) 或 S3 (AWS) 上,具体取决于客户端。 (每个客户都有自己的桶)
  • PHP 应用程序在 Compute Engine VM (GCP) 中运行,(每个客户端都有自己的 VM)

现在的问题是,在 PHP 代码中,唯一特定于客户端的是一个设置文件,其中包含数据库凭据和 Storage/S3 密钥。对于每个客户端,所有其他代码都完全相同。而且大多数不同的虚拟机整天都处于闲置状态,每个客户端等待几个小时的使用时间。

我试图找到一种方法来避免必须为每个客户创建和维护虚拟机。我如何重新架构我的后端,以便我可以为每个客户端保留单独的数据库和存储桶,但只在需要容量时扩展我的虚拟机?

我听到了很多关于 Docker 的消息,正在考虑将数据库凭据和密钥保存在 Redis 数据库或云数据存储中,正在研究 Heroku、AppEngine、Elastic Beanstalk,...

这是我现在看到的理想场景

  1. 传入请求已完成,到达负载平衡器
  2. 根据请求,确定请求是针对哪个客户端
  3. 从数据库中查找正确的设置文件或凭据
  4. 在未使用的“容器”中注入设置文件
  5. 处理请求
  6. 让容器再次空闲

在那里的某个地方,根据传入请求或流量的数量确定我是否需要启动或关闭容器以处理额外或减少的(临时)负载。

所有这些信息过载让我陷入困境,我不知道该选择哪个方向,而且我看不到实施上述任何技术将如何真正解决我的问题。

【问题讨论】:

  • 你不能简单地给每个客户自己的子域吗?当应用程序被请求时,您根据子域选择要使用的设置文件。
  • 一台虚拟机也支持不同的域
  • 我在我的问题中添加了我的“理想场景”,以提供更多信息。
  • 如果代码相同,是否每个客户都需要自己的虚拟机?如果您的负载均衡器可以识别客户端,它应该能够将该信息传递给负责处理请求的任何实例。包含客户端详细信息的文件是否可以位于每台服务器上(假设它是安全的),并根据每个请求检索适当的客户端详细信息?换句话说,你能允许任何服务器处理任何请求吗?至于扩展,也许 Kubernetes 可以提供帮助(如果你走 Docker 路线)-kubernetes.io.
  • 每个客户都不需要自己的虚拟机,目前这部分是一个巨大的矫枉过正。理论上我可以将设置文件放在每台服务器上,客户端无权访问服务器。

标签: performance web-applications architecture google-cloud-platform


【解决方案1】:

有几种方法可以用最少的努力做到这一点:

  • 根据客户重写配置文件的加载
  • 在一台虚拟机上创建多个后端网站(我认为最好的选择)

【讨论】:

  • 我在我的问题中添加了一些额外的信息。问题是,只要我的虚拟机可以承担负载,您的解决方案就可以工作。当我有太多客户端,VM 变得拥挤时会发生什么?创建一个新的 VM,并将我的客户端拆分为 2 个 VM?如果其中 1 个 VM 的流量非常高,而另一个没有,该怎么办?
  • 如果您意识到您的场景,您将需要创建跨 VM 会话存储。如果你有这个处理模型——那么一切都好,否则你将重写所有依赖于会话的代码。
  • 关于你的问题。当然,从资源使用的角度来看,这种情况并不是最优的,但是高水平的优化需要更复杂的系统并且会产生更复杂的问题。所以吻。
  • 为了解决负载问题,您可以在架构中包含 GCE 功能,例如 autoscalerURL maps。要自动缩放,您需要使 VM 无状态(如视频数据库中所述,在这种情况下,不能存在于 VM 中)。
猜你喜欢
  • 2011-02-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-12-31
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多