扩展与动态路由

如上面的微服务列表所示，每个微服务根据其特性分为有状态和无状态。有状态微服务是对视频或音频流执行连续实时处理的微服务，因此必须在内存中维护其内在状态，以避免长延迟和不一致性。有状态微服务在 Kubernetes 中被建模为 StatefulSet 资源。无状态微服务通常是对延迟更宽松，主要服务于无状态 REST 请求的微服务，因此它将其状态持久化在外部，可以是缓存或数据库中。无状态微服务在 Kubernetes 中被建模为 Deployment 资源

扩展无状态微服务就像增加其 Deployment 资源的副本一样简单，同时将同一微服务的所有副本保留在同一消息总线消费者组中，以便将一部分消息分发给所有客户端。

然而，当我们开始扩展有状态微服务时，事情可能会变得有点棘手。由于有状态微服务在其会话期间在内部维护其状态。特定用户会话生成的状态与有状态微服务共享相同的生命周期。在运行同一微服务的多个副本的情况下，源事件将被其中一个副本拾取，并且在用户会话的生命周期内，流量需要正确路由到同一副本。

因此，我们需要有关工作负载对象与其处理 worker 之间关系的信息，换句话说：特定流 ID 到 statefulset 副本索引的映射，例如，Chat controller pod 0 当前正在处理流 ID xxx。我们需要此信息，因为我们需要对传入请求做出动态路由决策，以便它们落在当前正在处理工作负载的正确副本上。

工作负载分配和流量路由都由 NVIDIA SDR 处理，这向开发人员隐藏了扩展的复杂性。要扩展有状态微服务，开发人员只需与 SDR 集成。详细信息请参考 SDR 文档 (流分发与路由)。