了解 Google Cloud Platform 微服务架构设计的成本估算

Question

我正在将单体应用程序重新设计为微服务架构，并希望使用 Google Cloud Platform (GCP) 来托管整个解决方案。我很难理解他们的成本明细，并且担心我的成本在建造后将无法控制。这是针对个人项目的，但我希望在启动后会有很多用户，因此我希望获得正确的底层架构，同时在启动时初始成本合理。

这是我的架构：

微服务 1 - 4（总共 4 个 API 服务）：

• 在 App Engine 上运行
• 公开 REST API 并将数据保存到 DataStore
• 最初每个 API 应该每天被访问大约 200 次

MicroService 5（事件触发 API 服务）：

• 在 App Engine 上运行
• 监听 PubSub 事件并保存到 DataStore（基本上我有一个传感器可以将数据推送到该服务进行存储）
• 最初，PubSub 应该每天接收大约 200 次事件

微服务 6-7（总共 2 个 UI 服务）：

• 在 App Engine 上运行
• 这些是用户界面，因此人们可以登录和使用系统。 UI 是轻量级前端应用程序，它们使用上面的 REST 服务以一种很好的方式填充用户数据。
• 每个用户界面服务应该每天使用大约 3 小时

因此，我总共有 7 个微服务，每个微服务在单个 GCP“项目”中作为 AppEngine“服务”运行。在这个项目中的这些 API 之间共享一个 DataStore。

由于我有 7 个 App Engine 实例正在运行，并且它们每天只需要运行很短的时间，定价如何运作？

我想使用 App Engine，因为它是完全托管的，这是我的设计要求之一。但我希望 AppEngine 有某种睡眠模式，这样当没有使用时它不会计费？

如果能帮助我了解我的每月费用，我们将不胜感激。

非常感谢。

---

2017 年 8 月 2 日更新

我决定暂时不使用 GCP。由于我希望在 Flex 中运行 7 个 App Engines 服务（因为它们是 node.js），我似乎无法访问免费层或将空闲服务扩展到 0 个实例的能力。

这意味着我将为这些服务支付全价。 （即每月 7 X 完整的 App Engine VM 成本：O）

这是我不能仅仅为了一个适当的微服务设计的 POC 的费用。相反，我将继续我的微服务设计，但使用 10 美元的 DigitalOcean 盒子和 Dokku 来容器化我的服务。如果这很好用并且我有需要，我会将此设计迁移到 GCP（或 AWS）

---

Answer 1

在https://cloud.google.com/appengine/docs/python/how-instances-are-managed 上提供了 App Engine 实例处理的完整概要。 总之，你最好的选择是enable automatic scaling and set

max_idle_instances = 0

在您的 app.yaml 中。

这意味着您的应用将自动缩放以根据需要处理流量并在之后关闭实例。还有

在负载高峰后恢复到正常水平时，空闲实例的数量可能会暂时超过您指定的最大值。但是，您不会为超过您指定的最大数量的实例付费。

稍后 - 当加载时间变得更重要时，您可以将 min_idle_instances 设置为更合适的数字 - 这允许响应式应用程序。

Answer 2

担心我的成本在我建造后会无法控制

您应该知道，自动可扩展的 GAE 应用总是具有依赖于不可控的外部用户请求模式的成本组件。

例如，在标准 GAE 环境中，这 200 个请求/天的分布方式非常重要：

• 如果它们均匀分布，它们将在不到 15 分钟的间隔内出现 - 每个实例生命周期的最短计费时间，因此相应服务将按每天至少 24 个实例小时计费（非常接近每日28 free instance-hours/day for billed apps，只有使用最小的instance class 的单服务应用程序才能放入其中）。
• 如果它们都在 15 分钟间隔内收到，则服务将按每天 0.5 个实例小时计费（即使有多个服务和/或更强大的实例类，也可以轻松满足每日免费配额）。

每个服务的实际可扩展性配置也很重要。例如，参见

严格控制成本的唯一方法是通过每日预算配置（但达到该限制意味着您的应用的功能将暂时受损）。

由于正在执行的功能，所有其他基于使用的成本都相同，您可以通过以下方式对成本进行一些（可能很重要）控制：

• 为每个服务选择的 GAE 环境类型：

  • the standard env 按实例小时计费，包括每日免费配额
  • the flex env 没有免费的每日配额。

• 服务的数量：您可以通过组合它们的功能从较少的服务开始（您仍然可以将它们模块化以便以后拆分）。您描述的预期初始负载可以很容易地适应免费的每日预算，只需一个标准的 env 服务。

一旦应用使用量回升并且总成本中的每日免费配额百分比变得可以忽略不计，您可以根据需要逐步将应用拆分为多个服务。一般来说，如果应用程序被适当地模块化，这可能是一项相对简单的任务。