1

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

如前所述，这里有两种方法。

  1. 流媒体
  2. 轮询

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

  • 比轮询更快
  • 仅接收最新数据，而不是与以前相同的所有数据
  • 避免定期请求

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

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

2 回答 2

6

流媒体

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

轮询

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

网络挂钩

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

如何决定

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

于 2019-12-27T10:55:48.457 回答
1

除了@Zoltan 的回答，我还从 LaunchDarkly 的Effective Feature management E book (Page 36)中找到了以下内容

在任何网络系统中，都有两种分发信息的方法。

轮询是端点（客户端或服务器）定期请求更新的方法。第二种方法是流式传输，当新值发生变化时，中央机构将新值推送到所有端点。这两种选择都有利有弊。

但是，在基于轮询的系统中，您面临着一个没有吸引力的权衡：要么不频繁地进行轮询，并且冒着应用程序的不同部分具有不同标志状态的风险，要么您非常频繁地进行轮询并承担了系统负载的高成本、网络带宽和支持高需求的必要基础设施。

另一方面，流式架构提供速度优势和一致性保证。流更适合大规模和分布式系统。在这个设计中，每个客户端都保持与功能管理系统的连续运行连接，该系统会在所有客户端发生任何更改时立即将它们发送下来。

投票优点：

  • 简单的
  • 轻松缓存

投票缺点：

  • 效率低下。无论是否有变化，所有客户端都需要立即连接。

  • 更改需要大约两倍的轮询间隔才能传播到所有客户端。

  • 由于轮询间隔较长，系统可能会造成“<strong>脑裂”的情况，其中新标志和旧标志状态同时存在。

流媒体优点：

  • 大规模高效。每个客户端仅在必要时接收消息。

  • 快速传播。更改可以实时推送给客户。

流媒体缺点：

  • 需要中央服务来维护每个客户端的连接

  • 假设网络可靠

对于我的用例，我决定在不需要经常更新标志（长轮询间隔）并且不关心不一致（脑裂）的地方使用轮询。

对于需要立即更新标志和保持一致性的应用程序，流式传输非常重要。

于 2019-12-30T15:19:09.657 回答