本文介绍了在数据中心发生故障时确保在云中部署的Web服务的可用性的选项。 提出的解决方案基于包括
部分重复的折衷方案：在另一个数据中心中部署了一个备份系统，当主数据中心不可用时，该备份系统可以以功能受限的模式运行。 该方案主要针对短期故障的应用程序，但在发生大规模问题时，还提供了将备份系统快速变成主要系统的能力。
问题描述
去年，我们被一家著名的云提供商的数据中心的事件所感动-我们的一项服务对用户来说半小时无法使用。 然后，我们亲眼看到了在云数据中心出现问题的情况下，实际上没有恢复应用程序运行状况的方法，除了负责安装和等待的工作之外，负责应用程序的团队没有其他任何东西。 这种经验使我们认真考虑将云用于我们的产品。
那天确切发生的事情从未被发现。 我们习惯于将云看作是坚不可摧的前哨基地，但事实并非如此。 事实是，与其他任何地方一样，云中没有百分之一百的服务可用性保证。 云是一种抽象概念，其背后隐藏着数据中心中所有相同的铁架和人为因素。 任何硬件迟早都会发生故障（尽管数据中心的硬件故障很可能是正常情况）。 此外，还有
一些更严重的问题导致数据中心无法访问：火灾，DDoS攻击，自然灾害，电力和互联网中断等。
如果我们谈论人为因素，那么这并不是造成事故的最新原因：
“根据统计，在80％的网络基础设施故障中，人们应该对此负责 。
” 人们，无论他们受到多么善意的指导，都是不可靠的。 甚至您和您的同事（对支持产品的稳定性直接感兴趣的人们）也可能犯了错误，更不用说别人公司的人员了，您的实例与成千上万的实例没有什么不同。 无论基础架构背后的专业团队是什么，新的故障都是时间问题。
一切都有代价。 当您迁移到云中时，您会得到一个简单的抽象，使用起来很方便，对运营部门的依赖性很弱，以换取对情况的完全控制。 在这种情况下，如果您没有事先照顾好自己，并且预见到了其他人犯错误的可能性，那么没有人会这样做。
解决方案选项
对于我们来说，服务的可用性，即使是几分钟，已经很重要。 因此，我们决定寻找一种方法，以确保将来自己免受类似问题的困扰，而又不会丢下乌云。
当开始解决云中服务可用性的问题时，应牢记可访问性是一个相当广泛的概念，并且根据它的含义，考虑了提供它的各种方案。 尽管本文仅讨论了由于数据中心故障而导致的可访问性问题，但还是要对其他可访问性问题的解决方案说几句话。
可用性是一种技术机会，可以在一定时间内以一定的负载提供对资源的访问。 服务运行时会发生问题，但是由于资源有限和系统的体系结构框架，并非所有用户都可以在一定的响应时间内访问它。 最常见的任务是通过在应用程序中部署其他实例来解决。 通过这种缩放，云将发挥出色的作用。
可访问性是特定地区用户对Web服务的可用性。 显而易见的解决方案是分片。 换句话说，例如，根据其地理位置，将系统分为具有各自数据的不同数据中心中的几个独立应用程序，并将每个用户分配给其系统实例。 分片时，在最坏的情况下一个数据中心的故障将导致仅与该数据中心相关联的一部分用户无法使用该服务。 不是支持分片的最后一个论据-这是对不同区域的数据中心执行ping操作的不同时间。
但是，通常在使用云的限制和去中心化的需求是立法要求，即使在系统设计阶段，通常也要考虑这些立法要求。 这些要求包括：Yarovaya法律-俄罗斯用户的个人数据（PD）的存储； 通用数据保护法规（GDPR）-限制欧盟用户PD向某些国家/地区的跨境转移； 以及中国互联网审查制度，所有通信和应用程序的所有部分都应位于中国，最好位于其服务器上。
通过在另一个数据中心中复制服务来解决数据中心的技术不可访问性的问题。 这不是一项容易的技术任务。 在不同数据中心中并行部署服务的主要障碍是数据库。 通常，小型系统使用单向导架构。 在这种情况下，主数据中心的故障会使整个系统无法运行。 主复制复制方案是可行的，但是它施加了并非所有人都了解的强大限制。 实际上，它没有将记录扩展到数据库，但是甚至付出了很小的时间损失，因为有必要确认所有节点事务已被接受。 当节点必须位于不同的数据中心时，写入操作时间将增加更多。
决定的理由
对我们的服务负载的分析表明，平均大约有70％的API调用是通过GET方法进行的。 这些方法使用只读数据库。
Web服务HTTP方法调用分配我认为这些结果反映了普遍可用的Web服务的整体情况。 因此，可以说
在一般的Web服务API中，读取方法的调用比写入方法的调用要频繁得多 。
我想提出的第二个陈述是，
如果我们谈论绝对可访问性，那么服务的客户确实不仅需要大量可用的API方法，而且还需要继续使用系统的“常规”工作所必需的那些可访问性。并执行“正常”查询 。 如果一个月两次被访问几次的方法在几分钟内不可用，则不会让任何人感到沮丧。 通常，阅读方法可以涵盖“正常”流程。
因此，对于数据中心发生故障时系统可用性问题的短期解决方案，已经可以考虑确保仅读取方法的绝对可用性。我们要实现什么
万一数据中心出现故障，我们想将流量切换到另一个数据中心的备份系统。 在备份系统中，所有读取方法均应可用，并且在调用其余方法时，如果无法不写入数据库而无法执行操作，则应显示正确的错误。
在正常操作中，用户请求被发送到平衡器，平衡器又将其重定向到主API。 如果主服务不可用，则平衡器确定这一事实并将请求重定向到以受限功能模式运行的备份系统。 此时，团队将分析问题并决定等待数据中心恢复或将备份系统切换到主模式。
实现算法
必要的基础架构变更
- 在另一个数据中心中创建数据库从属复制。
- 设置Web服务部署，在第二个数据中心中收集日志和指标。
- 平衡器配置，用于在第一个数据中心不可用时将流量切换到备用数据中心。
代码更改：
- 将单独的连接添加到Web服务中的副本。
- 将所有只读API路由迁移到副本。
- 对于其余方法，通过环境变量或其他触发器引入只读模式将部分解决问题，而不是写入数据库，或者如果其功能中断而没有写入数据库，则会给出正确的错误。
- 改进了前端，以在调用记录方法时显示正确的错误。
所描述解决方案的优缺点
好处
- 所提出的方案的主要优点是总是有重复的服务，随时准备为用户服务。 万一主数据中心出现问题，您不必在其他基础架构上编写部署脚本，也不必着急运行所有内容。
- 该解决方案的实施和维护成本低廉。 如果您具有微服务架构，并且该产品不需要一项服务而是需要许多服务，那么在这种情况下，将所有微服务转移到该方案中就不会有任何特殊问题。
- 没有数据丢失的威胁，因为在另一个数据中心的副本上始终存在数据库的完整副本。
- 该解决方案主要用于临时流量交换，最长可达半小时。 如果基础架构出现问题，这半小时不足以进行导航。 如果在此期间未还原第一个数据中心，则数据库的从属副本将成为主副本，而副本服务将成为主要副本。
- 在提出的方案中，应用程序和数据库位于同一数据中心。 如果您在不同的数据中心中有一个API和一个数据库，那么最好将它们转移到一个：这将大大减少查询的执行时间。 例如，我们的测量结果表明，对于Google Cloud，从API到一个数据中心内的数据库的请求平均需要6毫秒，而当将数据发送到另一个数据中心时，该时间增加了数十毫秒。
缺点
- 整个方案的主要缺点是，对于即时流量交换，需要一个与主服务不在同一数据中心中的平衡器。 平衡器是故障点：如果带有平衡器的数据中心发生故障，那么无论如何您的服务将变得不可用。
- 需要将代码部署到另一台服务器，监视其他资源-例如，监视副本，以便没有延迟。
结论
您不能创建能够抵抗所有类型故障的系统。 但是，保护自己免受某些类型的侵害是可行的。 本文中描述的解决方案在数据中心发生故障的情况下可以确保应用程序的可用性，在许多情况下，在实际应用中可能是有趣且有用的。
为了防止数据中心发生假设性故障，将常规Web服务转换为完全分布式的系统很可能是不切实际的。 乍看之下，即使是所提出的方案也似乎是多余且“繁重的”，但这些缺点的优点和易于实施的作用远远超过了它们。 您可以将事故保险比喻为一个例子：很有可能永远不需要这种保险，但是如果发生事故，将是非常受欢迎的。 使用提议的方案，您将确保始终准备好备份系统，该备份系统对于短期问题将确保大多数服务方法的可用性，并且在长期失败的情况下，它可以在几分钟之内完全转变为主要系统。 许多人会同意为这种信心付出这个代价。
每个系统都有自己独特的负载参数和可访问性要求。 这就是为什么对以下问题没有正确或错误答案的原因：“您可以完全信任Google Cloud还是AWS？” -在每种特定情况下，他都将是自己的。