为什么您的电子商务网站需要一个活跃的多云架构这个假日季节

对于电子商务领导者，假日季节带来两个确定性：大量涌入的购物者和云服务提供商中断的风险加大。主要的云中断似乎变得更加频繁和更具破坏性。例如，AWS US-East-1 区域有着在假日季节发生重大中断的历史。同样，每年一月，Microsoft Azure 都会在某些区域由于发布或测试计划而出现网络延迟问题或网络中断。而我们只需要回顾一下今年六月份，当时一个主要的 Google Cloud 中断影响了广泛的应用程序，就会被提醒，没有一个单一的提供商是免疫的。

如果您负责电子商务运营，您不希望发现，即使您已经设置了所有内容，但在一年中最关键的时刻，某些东西已经停止工作。这些云服务提供商中断和问题的趋势可能不在您的雷达上，坦率地说，它们不应该在您的雷达上。如果您是一名站点可靠性工程师，您不应该担心云平台中断是否会影响您的应用程序，也不应该在问题发生期间尝试调整您的基础设施。相反，您应该重新审视您对多云的了解。

多云应用程序

如果您的组织正在支付 AWS、Azure 和 GCP 的费用，您确实拥有所有三个云。但是，当您深入到更深层次时，很重要的是要检查一下会发生什么。如果您的某些应用程序是特定于 AWS、Azure 或 GCP 的，它们是否会在一个云提供商中断时继续工作，您需要快速切换到另一个云提供商时会发生什么?

您的应用程序必须在任何云上完美运行。这就是真正的多云设置。如果您想成为云无关，您不能只是支付多云费用；您还必须确保您的应用程序也是多云的。

此外，依赖单一提供商会引入计算能力、API 限速和区域可用性的固有约束。真正的多云架构增加了您的综合计算能力，并提供了对这些约束的弹性。它解锁了您在单一提供商限制之外按需扩展的能力，快速跨地域扩展容量，并在高峰购物日期间确保一致的性能。但是，拥有一个可移植的、云无关的应用程序只是第一步；下一步是以真正的弹性架构部署它。

扩展到活跃-活跃方法

这需要 DevOps 进行一些严肃的准备。创建一个 100% 准确的业务连续性灾难恢复 (BCDR) 策略是非常困难的，因为当您运行实时操作时，有多个故障点。您不希望在中断期间测试您的 BCDR 策略，因此您可能会觉得您只能预测可能的场景并相应地进行准备。

我的建议是为站点可靠性工程师设计默认的故障。这意味着拥有一个或多个云在活跃状态下运行。一个仅限于单一提供商的 BCDR 策略是一个单点故障；如果提供商的控制平面或网络骨干发生故障，您的整个恢复计划将变得无用。

在假日季节，访客数量会突然增加，迫使您的平台或应用程序以降低的能力运行。如果您已经创建了工作应用程序的副本，即次要应用程序，您可以切换到负载均衡，以便将一些请求分配到应用程序的另一个实例。

这种活跃-活跃方法意味着您拥有一个完全成熟的产品副本，在其他地方运行。如果您的主要云提供商出现严重的性能下降或中断，您可以通过 DNS 或全局负载均衡器无缝地将 100% 的流量转移到次要提供商，这不会对您的客户造成任何干扰。

不采用多云的真正成本

虽然运行次要云的成本并非微不足道，但与主要中断的业务影响相比，它是微不足道的：在可靠性故障后向客户道歉，试图向他们保证这不会再次发生，并说服他们不要离开您去选择您的竞争对手。让我们也不要忘记所有因销售机会丧失而错失的收入。FluidCloud，我见过这种情景一次又一次地发生：公司在单一提供商上投入大量资金，却发现自己在中断期间没有立即的补救措施。

话虽如此，仅使用一个云提供商就已经很难控制成本；您的云成本可能看起来像一个指数图。如果您采用多个云，那个指数图只会变得更加陡峭。

当您从主要云复制基础设施时，您自然不希望成本加倍。因此，我建议关注更便宜的云，它们提供具有竞争力的性能和更低的价格点。如果您在更便宜的云中运行次要云，您仍然会拥有完全的活跃-活跃冗余，但成本更低。这是一个双赢的局面。

最后的思考

在多个云提供商上运行应用程序的活跃-活跃方法并不仅仅意味着创建一个备份。这意味着为实时弹性而构建，确保您的业务没有单点故障，并能够在流量激增期间提供一致的速度。

这个假日季节，不要只是希望可靠性。为它而构建。设计您的系统以便在任何云提供商或区域发生故障时保持一致的运行。通过采用真正的活跃-活跃、多云架构，提供无缝的客户体验。能够提供一致的速度，即使在流量激增期间。这个假日季节，不要只是希望可靠性。为它而构建。设计您的系统以便在任何云提供商或区域发生故障时保持一致的运行。提供无缝的客户体验，通过采用真正的活跃-活跃、多云架构，能够提供一致的速度，即使在流量激增期间。