在我之前的一个回答中，我提到在设计连接到物联网设备的云服务时，最好以某种方式使服务器变得冗余，这样如果一个数据中心或服务器出现故障，整个系统仍然可以正常工作。
Sean Houlihane 指出，真正的冗余可能会使供应商的成本增加一倍，使其在技术上不可行。
因此，我很想知道如何在不复制每个组件的情况下使云服务（可能类似于用于 Nest 恒温器的服务，在 S3 中断时出现故障）变得更加可靠，从而减少对一个公司的商业模式。
我正在考虑的那种设备类似于智能恒温器，它需要将来自手机应用程序（家庭本地网络外部）的数据同步到恒温器本身，并将状态存储在云存储中，如 S3。
如何确保云服务器具有高可用性，而无需在不同位置运行每个服务器的两个副本？
...使提供商的成本增加一倍，使其在技术上不可行。
成本翻倍并不是真正“技术上不可行”，它只会使情况变得更加昂贵。然而，它并没有那么糟糕。
我为一家服务公司工作，该服务从三个不同的供应商那里租用三个不同数据中心的专用硬件，一个在西部，一个在东部，一个在中西部。我们的客户端应用程序会自动、持续、无缝地切换到任何响应最快的中心。（服务器端甚至不必做“负载平衡”；客户端做“负载分配”。）自从多年前启动以来，从未有过三个中心中至少有两个没有的时刻回应。
租用和运营这些服务器的成本微乎其微。我们可以使用小额现金轻松扩展到更多数据中心，但这不是必需的，因为三个现有系统提供了大量冗余和大量吞吐量。
电脑很便宜。停电代价高昂，而且会给您带来负面新闻。冗余服务器是最便宜的解决方案。
最重要的是，您需要一个可靠的负载平衡基础设施。这就是真正的问题所在。在其他东西所在的位置提供负载平衡和索引的服务。拥有冗余计算或存储很容易。它也不是那么贵。正如您所指出的，有足够多的模型，其中大部分成本仅适用于实际使用时。
就像在这个Wikipedia 负载平衡页面上一样，负载平衡器通常被描绘成单个实例。尽管这是一个巨大的简化，但很少有跨供应商的负载平衡。因此，如果您的 AWS 负载均衡器关闭，那么拥有大量可用的 Google Cloud Functions 和 OneDrive 存储将毫无用处。您的 IoT 设备将无法找到这些服务。他们将查看您的云服务的虚假域/IP。
其余的无论如何都是冗余设置的。亚马逊发生的事情是他们无意中关闭了单点故障。那个带有大红色的服务器从不关闭它的标志。他们错误地关闭了东海岸 S3的索引服务器。
这些子系统之一，即索引子系统，管理区域内所有 S3 对象的元数据和位置信息。该子系统是服务所有 GET、LIST、PUT 和 DELETE 请求所必需的。
本质上是知道什么在哪的服务。无论您如何设计基础设施，总会有相似之处。只需从亚马逊那里拿走它，即使是排名第一的云提供商也不敢接触该系统。
虽然这是自 S3 推出以来我们一直依赖的一项操作来维护我们的系统，但我们多年来并没有完全重新启动我们较大区域的索引子系统或放置子系统。
如果你把他们的博客读到最后，他们没有实际的解决方案。他们只是想减少它再次发生的机会。总会有一些关键点，您不能进行冗余——或者在该区域进行冗余成本非常高。
最后，让服务停止运行并等待三大云提供商将其恢复可能会更便宜。
一种想法可能是使用多个功能即服务提供商（例如AWS Lambda、Azure Functions或Google Cloud Functions），以便如果一个服务失败，则可以改用其他服务。
由于无服务器（功能即服务）提供商通常按调用次数而不是使用时间收费，因此成本影响可能并不那么重要——如果您 99% 的时间使用 AWS Lambda 并且仅在 AWS 停机时使用 Azure ，您仍然只需为每个函数调用付费一次，而不是为使用多个物理服务付费。
当然，大多数云服务不仅仅依赖于计算——存储方面仍然很重要，并且可能是不同的单点故障。你可能复制，太多在不同的供应商，但在这一点上它开始变得昂贵，因为你的付出多次为你的数据的存储，它可以很容易地获得同步进行，增加了复杂性的服务。
想象一下，在手机上将智能恒温器设置为 20°C——它可能会将该数据与云服务器 #1 同步，然后在数据被推送到另一个存储之前崩溃，因此云服务器 #2 认为你仍然希望你的恒温器处于10°C，你就会回到冰冷的房子里。
从本质上讲，制作可靠的物联网服务很难，但批评糟糕的设计似乎很容易。