我最近开始使用暗启动(LD)。我还在探索LD是如何更新其特性标志的。
如前所述，有两种方式。
- 流媒体
- 轮询
我只是在想在什么情况下哪个实现会更好。经过对streaming vs polling的研究，发现Streaming比polling具有以下优点。
- 比轮询更快
- 只接收最新的数据，而不是与以前相同的所有数据
- 避免定期请求
我确信以上所有的优势都是有代价的。所以，
- 使用流式轮询有什么缺点吗
- 在什么情况下应该首选轮询？还是反过来
- 我应该根据哪些因素来决定是流媒体还是投票
流式处理
流式处理要求应用程序始终处于活动状态。在无服务器环境中可能不是这样。此外，流式传输解决方案通常依赖于始终在后台打开的连接。这可能代价高昂，因此功能标志提供程序往往会限制您可以保持对其基础设施开放的并发连接的数量。如果只在少数应用程序实例中使用功能标志，这可能不是问题。但是，如果你想将功能标志更新流式传输到移动应用程序或大量微服务，你将很容易达到极限。
轮询
投票听起来不那么花哨，但它是一个可靠的&稳健的老派模式，几乎适用于所有环境。
Webhooks
还有第三种选择：webhooks。其基本思想是，在您的端上创建一个HTTP端点，每当发生特性标志值更新时，特性标志服务就会调用该端点。通过这种方式，您可以获得有关功能标志值更改的"通知"。例如，ConfigCat支持此模型。ConfigCat可以通过调用webhook并(可选)向您的端推送新值来通知您的基础设施。与流媒体相比，Webhook的优势在于维护成本低廉，因此功能标志服务提供商不会对其进行太多限制(例如ConfigCat可以为您提供无限的Webhook)。
如何决定
我将如何使用上述3个选项实际上取决于您的用例。一般经验法则是：默认情况下使用轮询，并向了解功能标志值更新至关重要的组件添加准实时通知(通过流媒体或Webhook)。
除了@Zoltan的回答，我还从LaunchDarkly的有效功能管理E书(第36页)中找到了以下内容
在任何联网系统中，都有两种分发信息的方法。
轮询是端点(客户端或服务器)定期请求更新的方法。第二种方法是流式处理，即中央机构在新值发生变化时将其推送到所有端点。这两种选择都有利弊。
然而，在基于轮询的系统中，您面临着一个没有吸引力的权衡：要么您很少轮询，并冒着应用程序不同部分具有不同标志状态的风险，要么您非常频繁地轮询，并在系统负载、网络带宽和支持高需求的必要基础设施方面承担高昂的成本。
另一方面，流架构提供了速度优势和一致性保证。流媒体更适合大规模和分布式系统。在这种设计中，每个客户端都保持与功能管理系统的连接，当所有客户端发生任何更改时，功能管理系统会立即将其发送给所有客户端。
轮询优点：
- 简单
- 轻松缓存
轮询缺点：
-
效率低下。无论是否发生更改，所有客户端都需要立即连接。
-
更改需要大约两倍的轮询间隔才能传播到所有客户端。
-
由于轮询间隔较长，系统可能会造成">大脑分裂"的情况，即新的标志状态和旧的标志状态同时存在。
流媒体优点：
-
在规模上高效。每个客户端仅在必要时接收消息。
-
快速传播。更改可以实时推送给客户端。
流媒体缺点：
-
需要中央服务来维护每个客户端的连接
-
假设一个可靠的网络
对于我的用例，我决定在不需要经常更新标志的地方使用轮询(轮询间隔长)，也不关心不一致(分裂大脑)。
对于需要立即更新标志和保持一致性的应用程序，流式处理非常重要。