在上一篇文章,我们讲到了长连接常见的实现方案,相信大家对长连接已经有一定的了解了,这篇文章我们会讲 FeatureProbe 的长连接实现方案。
一、为什么FeatureProbe需要长连接
Feature Toggle 在部分场景下,客户端对实时性有较高的要求,如紧急情况,希望配置立刻下发生效。有的 Feature 在 Web 端加载或 App 启动的时候就要读取到开关的值,虽然缓存能解决一部分问题,但是最快拿到最新的值,会更符合用户的预期。我们在上篇有提到过,长连接可以解决数据推送和请求优化这两个场景。
1、可选协议
- SSE :Server Send Event 能满足服务端向客户端发送数据的需求,协议简单,但因为不是双工的数据通路后期无法实现 HTTP 的请求优化。
- TCP :目前最主流的长连接协议,配合 TLS 1.3 可以做到很好的使用效果。
- QUIC :本身握手和 TLS1.3 融合,还支持连接恢复,多Stream避免包头阻塞问题,有很多优势,因为基于UDP,可能会有部分特殊网络环境被禁止。
- UDP :需要自己实现丢包重传,部分网络环境有可能被限制。
- WebSocket :对浏览器友好,小程序唯一支持的双向收发 (全双工) 协议,很难做连接优化。
2、设计目标
- 尽可能支持更多的端,小程序,移动端,多种语言服务端;
- 尽量降低 SDK 的实现复杂度,方便后期社区贡献;
- 尽可能使开关快速生效;
- 尽可能低的数据传输量。
二、FeatureProbe长连接方案
1、协议选择 WebSocket
小程序是我们一期要优先支持的平台,所以所有不支持