理解Google平台MicroServices体系结构设计的成本估算

Question

我正在将一个单点应用程序重新设计成一个MicroServices体系结构，并希望使用来承载整个解决方案。我很难理解他们的成本分类，我担心我的成本会在我建造之后无法控制。这是一个个人项目，但我希望会有许多用户后，我启动，所以我想得到正确的基础架构，同时有合理的成本，开始时，我推出。

这是我的建筑：

MicroServices 1-4(总计4个API服务)：

• 在上运行
• 公开REST并将数据保存到DataStore
• 最初，每个 API应该每天被点击大约200次。

MicroService 5(事件触发API服务)：

• 在上运行
• 侦听PubSub事件并保存到DataStore (基本上，我有一个传感器将数据推送到此服务中存储)
• 最初，PubSub应该每天接收大约200次事件。

MicroService 6-7 (总共2个UI服务)：

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

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

由于我有7个App实例运行，而且它们每天只需要运行一段很短的时间，那么定价是如何工作的？

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

任何帮助理解我的每月费用将不胜感激。

非常感谢。

更新日期:2017年2月8日

我决定暂时不加入GCP。由于我希望在Flex中运行7个(因为它们是node.js)，所以我似乎无法访问一个免费的层，也无法将空闲服务扩展到0实例。

这意味着我将为这些服务付出全部的代价。(即每月7X个App成本:O )

这是一项开支，我不能只为一个适当的MicroService设计的POC。相反，我将继续我的MicroService设计，但是使用一个10美元的DigitalOcean盒和Dokku来封装我的服务。如果这很好，而且我有需要的话，我将把这个设计迁移到GCP (或AWS)

Answer 1

App实例处理的全部大纲可在https://cloud.google.com/appengine/docs/python/how-instances-are-managed上获得。简而言之，你最好的选择是启用自动缩放和设置

max_idle_instances = 0

在你的app.yaml里。

这意味着您的应用程序将根据需要自动处理流量，然后关闭实例。也是

当负载高峰后恢复到正常水平时，空闲实例的数量可能暂时超过指定的最大值。但是，对于比指定的最大数目更多的实例，您将不会被收取费用。

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

Answer 2

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

您应该知道，自动可伸缩的GAE应用程序总是有成本组件依赖于外部用户请求模式，这是不可控制的。

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

• 如果它们分布均匀，它们将在15分钟内到达--每个实例生存期的最短计费时间，因此相应的服务将被计费为每天至少24个实例小时(非常接近每日28免费实例-收费应用每天工作时间，只有使用最小实例类的单一服务应用程序才能适应)。
• 如果在15分钟内收到所有这些服务，服务将每天收费0.5个实例小时(即使有多个服务和/或更强大的实例类，也可以轻松地满足免费的每日配额)。

每个服务的实际可伸缩性配置也很重要。例如，看，

严格控制成本的唯一方法是通过每日预算配置(但如果达到这个限制，则意味着应用程序的功能将被暂时削弱)。

由于正在执行的功能，所有其他基于使用的成本是相等的，您可以通过以下方式对成本进行一些(潜在的重大)控制：

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

- [the standard env](https://cloud.google.com/appengine/pricing#standard_instance_pricing) is billed by instance hours and includes a free daily quota
- [the flex env](https://cloud.google.com/appengine/pricing#flexible-environment-instances) has no free daily quota.

​

• 服务的数量:您可以通过组合它们的功能来开始使用更少的服务(您仍然可以将它们模块化以供以后的拆分)。您所描述的预期初始负载可以很容易地满足每天的免费预算，只需一个标准的env服务。

一旦应用程序的使用率上升，以及免费的每日配额在总成本中所占的百分比变得微不足道，您就可以根据需要逐步将该应用分成多个服务。一般来说，如果应用程序被适当模块化，这可能是一个相对简单的任务。