服务治理

fate-serving 的服务治理

在线预测部分主要有一下几个模块会进行rpc调用：

• serving-server
• serving-proxy
• fateflow

其中serving-server 和serving-proxy对外提供了预测接口， 承载业务流量，所以有弹性扩缩容的需求，同时要求高可用。 针对以上的几点 ，fate-serving使用了zookeeper作为注册中心，管理各模块的服务注册以及发现。可参考代码中register模块。目前源码默认使用zookeeper。可参考 serving-server配置详解 ，以及 serving-proxy配置详解。

zookeeper中的数据结构

zookeeper中使用的数据结构如下

/FATE-SERVICES/{模块名}/{ID}/{接口名}/provider/{服务提供者信息}

接下来说明zookeeper各级路径的含义

• 第一级路径：永久节点，固定为FATE-SERVICES
• 第二级路径：永久节点，各自模块的名字，比如serving-proxy的模块名为proxy ，serving-server的模块名为serving
• 第三级路径：永久节点，ID ，根据接口的不同ID的值不一样。与模型版本强相关的接口，如inference接口，ID为fate-flow推送模型时产生的serviceId ，这样可以使得不同版本模型注册路径不一样。其他接口为字符串online
• 第四级路径：永久节点，固定字符串provider
• 第五级路径：临时节点，详细描述注册信息 eg: grpc://172.168.1.1:8000

订阅与注册的可靠性保证

目前订阅/取消订阅 、 注册/取消注册操作都使用了定时重试的机制来保证操作的最终成功。

客户端服订阅务信息的缓存与持久化

默认在当前用户目录下生成.fate 的文件夹，所有的持久化信息都会放入该文件夹。 使用服务治理管理的模块启动之后，首先会从本地缓存文件加载之前订阅的接口，然后再从注册中心拉取并更新本地文件。在极端情况下，如注册中心宕机，本地的持久化文件将继续服务，不会影响业务流量。

客户端的负载均衡

目前支持

• 随机(默认)
• 加权随机

服务端的优雅停机

服务端会在jvm 退出时，主动取消注册在注册中心的接口，拒绝新的请求，并等待当前正在处理的请求退出。 需要注意的是，不能使用kill -9 命令退出，这样不会触发jvm退出前的动作，如果进程意外退出，zookeeper会判断心跳超时，所创建的临时节点会消失，但是在心跳还未超时的这段时间里，业务流量会被路由到当前已被kill的实例上来，造成风险。建议使用kill