在可扩展的网站上显示实时数据？答案

【问题标题】：Display real time data on website that scales?在可扩展的网站上显示实时数据？
【发布时间】：2018-08-04 07:12:27
【问题描述】：

我正在开始一个项目，我想在其中创建一个显示实时航班信息和状态的网站。我们都在机场看到了这一点。这里给出了一个例子 - http://www.computronics.biz/productimages/prodairport4.jpg。如您所见，此信息不断变化。该网站将与后端 api 对话，而此后端 api 将与 数据库 对话。现在重要的部分是数据库中的航班信息将由航空公司自己更新。可能有几家航空公司，他们将分别更新他们的数据。我画了一张图上传到这里-https://imgur.com/a/ssw1S。

现在这些航空公司显然会有一个接口（网站与一些后端 API 对话），他们将通过该接口更新数据库。

现在这是我尝试解决的问题。我们需要某种触发器，这样如果任何航空公司在当前时间 - 1 小时到当前 + 4 小时之间更新数据库中的航班详细信息（网站只会显示几个小时的航班），我们需要调用 web api 和然后将更新实时发送到网站。 用户根本不能刷新页面。同时网站需要很好地扩展，即如果网站上有100万用户，并且数据库在正确的时间范围内有更新，所有 100 万用户的网站都应该在相当长的时间内得到更新。

我做了一些研究，看起来我们需要一种基于事件的方法。例如 - 我们需要创建一个函数（AWS lambda 或 Azure 函数），只要在正确的时间范围内数据库（例如 Dynamo DB）有更新，就应该调用该函数。这个函数然后应该调用一个 API，然后应该通过 web socket 技术更新网站。

我不是在寻找任何代码，而只是寻找一些关于如何以可扩展的方式解决此问题的替代建议。还有我们如何测试可扩展性？

【问题讨论】：

准备好了。火。瞄准。
航空公司需要直接更新数据库还是可以通过航空公司调用的API抽象出来？
@dashmug - 哈哈是真的:)
@UsmanMutawakil - 他们将拥有一个与 API 对话的用户界面，该 API 将更新一些数据库（sql server、dynamo db）等。
@VVV 我明白了。我刚刚发布了一个高级解决方案，其中包含关于可扩展性测试的部分，我的中心主题是您不需要 lambda 或 azure 函数。

标签： amazon-web-services websocket aws-lambda scalability azure-functions

【解决方案1】：

不要使用无服务器函数（Lambda/Azure 函数）

虽然我是无服务器函数的忠实拥护者，并且目前在 Lambda 中运行一个完整的 Web 应用程序，但我认为您的用例不需要它并且在经济上没有意义。正如您在 cmets 中回答的那样，每家航空公司都不会直接写入数据库，它们会推送到 API，这意味着您会在航班发生变化时被明确告知。当航空公司向您发送新数据时，您只需通过 websocket 将其传播到所有浏览器端点。这使设计非常简单。无需人为地创建一个数据库事件，然后触发一个函数，然后告诉您航班已更新。这就像移除你的门铃并用触发门铃的运动检测器替换它:)

费用

金钱总是值得拥有自己的部分。 Lambda 与其说是技术上的突破，不如说是一种经济上的突破。你必须知道它何时具有成本效益。您按请求付费，因此如果您处理的流程每月处理 10,000 次操作，或者每天只触发 1,000 次，那么 lambda 非常便宜且几乎免费。您还需要为函数执行的时间长度和执行时消耗的内存付费。通常，在专用服务器大部分时间处于空闲状态的情况下，使用 lambda 函数是有意义的。因此，AWS 不是为您提供整个 EC2 实例，而是按需为您提供容器。在某些情况下，高请求率和不断运行的进程使 lambda 比 EC2 更昂贵。本文讨论了在一定程度上使用 lambda 通常会更便宜 -> https://www.trek10.com/blog/lambda-cost/ 这同样适用于 Azure 函数和 google 等价物。它们都是按需提供的容器。

如果您正在处理航班信息，我想您将每分钟更新数千个航班，因此您的 lambda 函数将不断触发，就像您在运行 EC2 实例一样。您最终将支付比 EC2 更多的费用。当您有一项服务需要 24/7 全天候运行并以高活动运行 24/7 时，这肯定是专用服务器或服务器的有效用例。

建议的解决方案

这些是我将在下面使用的组件：

某种消息队列（RabbitMQ 或带有 SNS 的 AWS SQS）
Web Socket 后端（选择取决于编程语言）
航空公司输入 API（REST、GraphQL 或 AWS Kinesis Data Firehose）

航空公司将他们的数据发布到后端 API。更新存储在消息队列中，而实际通过 websockets 向用户显示结果的 Web 应用程序从队列中读取。

可扩展性

为了可扩展性，您可以在一个自动扩展组中的多个 EC2 实例（全部从同一个队列服务中读取）上运行 websocket 应用程序，因此额外负载会自动创建更多实例，因此名称为“自动扩展”。这些实例可以位于弹性负载均衡器后面。许多关于如何做到这一点及其旗舰设计模式的 AWS 文档。如果您使用 AWS SQS，则不必自己管理可扩展性详细信息，aws 会处理。唯一真正要扩展的组件是您的 websocket 应用程序和航班数据输入端点。您也可以在自动缩放组中运行 flight api，但 AWS 确实提供了一个额外的工具来处理高流量数据。我在下面详细说明。

测试可扩展性

让模拟航空公司用成千上万的虚假更新来炸毁你的服务是相当容易的，另一方面，你可以轻松地运行多个硒测试线程来模拟浏览器点击并验证 UI 是否仍在运行。

其他工具

如果它最终是大量数据，而不是使用传统的 REST api 来提供航班更新服务，您可以考虑 AWS 提供的专门用于处理大量实时更新的服务 (Kinessis Data Firehose)https://aws.amazon.com/kinesis/data-firehose/但是我没用过。

【讨论】：

感谢哥们的详细文章。是的，成本是一个很大的因素，而我目前的做法是矫枉过正。你的解决方案非常好。您已经删除了函数和数据库，并且已经有一个使用 AWS Lambda 函数的 Web 应用程序，因此您显然知道得更好。我唯一担心的是，因为没有数据库，所以没有状态。现在，它看起来不错，但不确定当我开始实施它时是否会遇到任何问题。非常感谢您的时间。你可能花了一个多小时来写和画这个:)
没问题。分享很有趣，这个网站在过去也帮助了我很多。如果您想要保存历史记录，您当然可以添加一个数据库。消息队列本身就是一种存储机制，但我肯定会看到未来需要回滚不同的帖子，这样数据库才会有用。为了简单起见，我只是省略了它。很高兴这有帮助。祝项目好运。
@VVV 这是一个很好的答案，但不适合您的情况。就在这种确切情况下的经验而言，除了简单的数据库和后台客户端刷新之外的任何事情都远远超过了复杂化。请注意，queue-> socket 方法将不起作用，因为数据并不总是连续的。
@Johns-305 AWS SQS 提供订单控制 (FIFO)。但是队列不是必须的......关于websockets，它们旨在用于实时显示。在任何地方都使用 websocket，您当然可以用简单的轮询来替换它们，但要付出一定的代价。我不认为将桌面显示器链接到前端的插座是一个巨大的复杂性牺牲。
@UsmanMutawakil 我的主要观点是，在这种情况下，由于实际情况，解决方案是这个答案不适合。实际上，客户端如何更新可能是整体考虑的 5%。需要明确的是，这个堆栈可以很好地工作......对于其他东西。 :) 我只是不想让 OP 把时间花在他们最终会意识到并不重要的事情上。

【解决方案2】：

首先，请不要想太多。这是一个很容易解决的问题，不需要任何特殊的技巧、技术或流行的模式和框架。

实际上，您可以几乎分别处理三个功能领域。

摄取 - 从各种来源收集和规范化数据。为此，您需要一个流程和转换引擎、LogicApp 等。
您的数据库。您会很快了解到并非所有航班都相同；）。虽然看起来如此，但数据量并没有那么多。为特定功能调整的 MySQL/SQL Server 实例可以正常工作。提示，您无需随时准备好每个动作的数据。
演示文稿。数据 API 和 UI。这确实是最容易的部分。我建议您首先使用基本轮询。由于您永远无法控制的原因，航班数据的 SLA 大约为 5 分钟，因此您应该首先将时间花在实时客户通知系统上。

【讨论】：

我得到了第 1 点，对于第 2 点，您的意思是我们可以在 SQL Server 中设置一个触发器，这样每当有更新时，就会调用一个 Azure 函数。那么这个 Azure 功能将如何更新用户网站呢？
@VVV 那里有无数的回调模式，但我是说一开始你不需要这样做。客户端可以轮询（在后台）以更新自身。您不需要实时，因为数据不是。
谢谢，实际上这是过度杀戮。客户端轮询的问题是该网站打开了 100 万个，他们将发送 100 万个并发请求。所以我想我会为此使用 web socket。
@VVV 相信我，你在浪费时间。全球每天有 12% 的乘客使用您的网站是不合理的。维护套接字既昂贵又不可靠。当您达到 10,000 个用户时，请担心轮询性能。相信我，您高估了实时更新的需求。