分布式有状态服务的调度技术预研报告

1. 研究项目背景

平台版本建设中，为了充分发挥视频分析引擎性能，需要针对业务特点，现有的分布式调用方式无法满足需求，需要研究分布式服务的有状态调用实现。

2. 技术现状分析

2.1 分布式有状态服务调度技术的发展历程

1. 固定分配
   最初的分布式有状态服务调度技术采用固定分配的方式，即将每个服务实例分配到特定的机器上，一旦该机器出现故障，就需要手动重新分配。这种方式的优点是简单可靠，缺点是无法动态应对机器故障和负载波动。
2. 故障感知的调度
   为了解决机器故障问题，分布式有状态服务调度技术引入了故障感知机制。一旦发现某个机器无法响应，就将其上的服务实例重新调度到其他机器上。这种方法需要一定的检测和恢复时间，但可以确保服务的高可用性。
3. 优先级调度
   随着服务规模的扩大，服务之间的关系变得越来越复杂。在这种情况下，需要引入优先级调度机制，将关键的服务或高负载的服务分配到资源更为丰富的机器上，以确保整个系统的稳定性和可用性。

2.2 目前常用的分布式服务调度技术

1. Apache ZooKeeper： ZooKeeper 是一个分布式的，开源的分布式协调服务，可以提供分布式系统中的管理和协调，通常用来进行服务的注册、发现和配置管理，还可以实现分布式锁和协调等功能。
2. Consul：Consul 是一个服务发现和配置工具，可以管理微服务架构中的服务注册和发现，提供了基于 HTTP API 和 DNS 的服务发现功能，支持健康检查，还可以实现一致性协议和故障检测等功能。
3. ETCD ：ETCD 是一个分布式键值存储系统，提供了高可用性的集群支持以及强一致性、分布式锁等特性，通常用于服务注册发现、分布式锁等场景。
4. Nacos：集配置中心和注册中心与一体的， AP 支欢迎持性能良好， 天然支持Dubbo，用于服务配置、注册发现，使用简单方便。目前只支持无状态服务调用，有状态服务调用需要自研。

3. 技术实现原理分析

分布式有状态服务是指一个服务在多台服务器上运行，且不同的服务器保存着该服务的有状态信息。实现分布式有状态服务需要满足以下几点原则：

1. 状态信息的共享：多台服务器要共享服务的状态信息，一般采用分布式缓存技术。
2. 负载均衡：多台服务器要均衡处理请求，常见的负载均衡算法有轮询、随机、最小连接数等。
3. 服务发现：多台服务器需要知道彼此的存在及状态信息。
4. 一致性协议：多台服务器之间需要保持一致性，可采用Paxos、Raft等一致性协议。

在实现分布式有状态服务时，需要注意以下几点：

1. 避免单点故障：采用集群部署方式，避免单点故障。
2. 数据一致性：确保多台服务器之间的数据一致性，避免冲突。
3. 高可用性：服务要保持高可用性，避免因单点故障导致服务不可用。

4. 技术挑战和解决方案

4.1 分布式有状态服务调度技术面临的挑战

1. 数据一致性问题。由于分布式系统中各个节点之间的通信可能会出现延迟、丢包等问题，因此对于有状态服务的状态同步需求，需要保证数据的一致性。
2. 负载均衡问题。分布式有状态服务通常需要为多个客户端提供服务，这就要求调度系统能够动态地将负载均衡地分配到各个节点上。不同服务的负载可能不一致，因此需要采用适当的负载均衡算法。
3. 高可用问题。当某个节点出现故障时，需要能够快速地将服务迁移至其他节点上，以保持服务的可用性。这就需要调度系统能够监控各个节点的状态，及时发现和处理故障。

4.2 可以采取的解决方案

1. Apache ZooKeeper

   利用 ZooKeeper 实现分布式锁：ZooKeeper 是一个分布式的协调服务框架，其提供的分布式锁机制可以用来实现分布式有状态服务。通过在 ZooKeeper 上创建一个节点来代表服务状态，各个服务实例通过申请分布式锁来对该节点进行读写，完成状态共享。

2. ETCD

   ETCD 实现方式和ZooKeeper 类似，ETCD提供了分布式锁的原生实现，而ZooKeeper则需要开发人员自己来实现分布式锁。ETCD的社区活跃度相对较高，有较多的开发者集中在ETCD的开发和维护上。

3. 共享数据库

   将服务的状态信息存储在一个共享的数据库中，各个服务实例通过对该数据库的读写完成状态共享。这种方式的优点是简单易实现，缺点是数据库成为了单点故障，读写频繁的情况下容易出现性能问题。

4. 自研服务注册中心 + 客户端负载

   复用AI能力托管平台实现，使用进程探针，实现服务发现。调用方调用引擎服务时，通过引擎服务名称调用。负载客户端sdk中，访问缓存系统，从缓存中获取当前集群中需要使用的引擎服务具体状态信息，根据策略访问对应的引擎服务。

5. 调研结论

从高可用 、服务注册发现、是否支持集群方、有状态服务调用策略、引擎服务改造等方面考虑，特别是引擎服务改造需要花费高成本改造，且对于C++/Go服务,集成其他组件成本过高。综合考虑决定使用自研服务注册中心 + 客户端负载方式实现分布式有状态服务调度。