java - CloudBees 服务级别协议(protocol)和功能服务

Question

我一直在仔细比较 Java PaaSes，并且真的开始喜欢 CloudBees。我对他们只有一个大问题，那就是他们的 SLA/正常运行时间。

翻遍他们所有的文档后，我只能找到 one paper they offer on SLAs其中指出:

If you are using the CloudBees PaaS without taking advantage of high availability options, then CloudBees can only offer uptime that approaches the base uptime SLA of the infrastructure cloud provider.

正如同一篇论文还提到的，Amazon 似乎提供了 99.95% 的正常运行时间，而且我知道 CloudBees 大部分运行在 AWS/EC2 实例本身上。

因此，这产生了许多密切相关的 SLA 问题:

1. 如果我不利用“高可用性”选项，那么我是否可以假设 CloudBees 甚至不能保证 99.95%？或者其他地方是否有文档说明其正常运行时间以及无法满足正常运行时间的补救措施？
2. 他们在这里谈论什么高可用性选项？我刚刚阅读了他们的整个开发人员文档，但从未看到过任何有关 HA 的内容。
3. 如果合作伙伴服务(例如用于邮件的 SendGrid 或用于缓存的 MemCachier)出现故障，我可以采取哪些补救措施？我喜欢 GAE 的一件事是它的 CapabilityService，在您使用他们的电子邮件 API 或缓存 API 之前，您首先要与主服务器 CapabilityService 进行检查以确保这些服务正在运行。我想对 CloudBees 做同样的事情，但似乎我需要自己构建它。这很好，但不确定 CloudBees 是否提供了一种机制(API 调用等)来确定特定服务合作伙伴是在线还是离线。

提前致谢!

Answer 1

1. CloudBees 不提供可用性 SLA，也不提供积分形式的补救措施(如果一个月内未达到特定的正常运行时间水平)。据我所知，这对于 AWS 上的其他产品(例如 Heroku)来说很常见。 CloudBees 确实通过支持协议(protocol)提供基于标准响应时间的 SLA。正如您引用的白皮书中所讨论的，我们还采用了自己使用 AWS 和外部提供商的实践，这有助于将我们的用户与某些特定的 Amazon 问题隔离开来。

2. 您可以使用的可用性功能包括:

   • 使用多个实例(并且可能会自动扩展)。应用实例由 CloudBees 分布在不同的 EC2 实例上，因此您可以避免 EC2 实例发生故障时出现停机。
   • 使用session store 。您可以使用我们的产品或 Memcachier 等合作伙伴产品在与应用实例不同的单独层中共享 session 状态。
   • 使用 dedicated servers CloudBees 在多个 AWS 可用区中设置。
   • 确保您的应用所使用的数据库是在高可用性配置中设置的。例如，RDS 与 CloudBees 结合使用非常简单，并且支持多个可用区中的备用数据库和只读副本。
   • 使用 New Relic 和 AppDynamics 等合作伙伴提供的应用监控解决方案来提醒您任何问题。

   有关使用“高可用性选项”的评论的主要观点是警告人们，仅在 CloudBees 上部署应用程序并不能使其具有高可用性。如果 EC2 实例在单实例部署下发生故障，当我们的内部机器重新部署到工作实例时，您的用户将经历停机，而多实例部署可能只会遇到较慢的响应，直到部署新实例。与没有跨可用区的备用数据库或副本的单实例数据库类似。虽然这只是对很多人来说显而易见的事实，但您可能会惊讶地发现有多少人只是假设正在发生一些魔法。

3. 关于功能服务的观点很好!我们在这方面有一些想法，但您现在必须自己做这样的事情。