何时在黑暗启动时使用轮询和流媒体

Question

我最近开始使用黑暗启动（LD）。我正在探索 LD 如何更新其功能标志。

正如这里提到的，有两种方法。

1. 流媒体
2. 轮询

我只是在想在什么情况下哪种实现会更好。经过一番研究streaming vs polling，发现Streaming有以下优点polling。

• 比轮询快
• 只接收最新的数据，而不是和以前一样的所有数据
• 避免定期请求

我很确定上述所有优势都是有代价的。所以，

1. 在轮询上使用流式传输有什么缺点吗？
2. 在什么情况下应该首选轮询？或者反过来？
3. 我应该根据哪些因素来决定是流式传输还是轮询？

Answer 1

流媒体

流式传输要求您的应用程序始终处于活动状态。在无服务器环境中可能不是这种情况。此外，流媒体解决方案通常依赖于始终在后台打开的连接。这可能很昂贵，因此功能标志提供者倾向于限制您可以对其基础设施保持开放的并发连接数。如果您仅在少数应用程序实例中使用功能标志，这可能不是问题。但是，如果您想将功能标志更新流式传输到移动应用程序或大量微服务，则很容易达到限制。

轮询

轮询听起来不那么花哨，但它是一种可靠且强大的老式模式，几乎适用于所有环境。

网络钩子

还有第三种选择：webhooks。基本思想是您在您的一端创建一个 HTTP 端点，并且每当发生功能标志值更新时，功能标志服务将调用该端点。通过这种方式，您会收到有关功能标志值更改的“通知”。例如 ConfigCat 支持这个模型。ConfigCat可以通过调用您的 webhooks 和（可选）将新值推送到您的终端来通知您的基础设施。Webhooks 比流式传输的优势在于维护成本低，因此功能标志服务提供商不会对它们进行太多限制（例如 ConfigCat 可以为您提供无限的 Webhooks）。

如何决定

我将如何使用上述 3 个选项实际上取决于您的用例。一般的经验法则是：默认情况下使用轮询并将准实时通知（通过流式传输或通过 webhooks）添加到组件中，在这些组件中，了解功能标志值更新至关重要。