-
Notifications
You must be signed in to change notification settings - Fork 77
新手指南
utu edited this page Mar 10, 2020
·
19 revisions
fate-serving是FATE的在线部分,在使用FATE进行联邦建模完成之后,可以使用fate-serving进行在线联合预测。 **目前的文档只适用于1.2以上版本 **
fate-serving 的部署架构图如下
如上图所示,整个集群需要有几个组件
- serving-server
- serving-proxy(1.2版本之前为serving-router)
- zookeeper 3.4+
- redis 4.0+
接下来将逐一介绍各个组件的作用
serving-server用于处理所有的在线预测请求、以及模型加载请求。serving-server需要从fate-flow加载模型成功之后才能对外提供服务。在FATE中建好模型之后,通过fate-flow的推送模型脚本可以将模型推送至serving-server。
推送成功之后,serving-server会将该模型相关的预测接口注册进zookeeper ,外部系统可以通过服务发现获取接口地址并调用。同时本地文件持久化该模型,以便在serving-server实例在集群中某些组件不可用的情况下,仍然能够从本地文件中恢复模型。
部署serving-server时,可以根据实际业务请求量来动态扩缩容。
serving-proxy 是serving-server的代理,对外提供了grpc接口以及http的接口,主要用于联邦预测请求的路由转发以及鉴权。在离线的联邦建模时,每一个参与方都会分配一个唯一的partId。serving-proxy维护了一个各参与方partId的路由表,并通过路由表中的信息来转发请求。路由表的配置参考路由表。
部署serving-proxy时,可以根据实际业务请求量来动态扩缩容,可以根据业务系统的特点,来选择负载均衡的方式 ,比如在serving-proxy前面部署nginx作为http/grpc的反向代理
zookeeper用作注册中心,各组件启动后将自身提供的接口注册至注册中心
redis 目前主要用在guest端,用于缓存预测结果。
fate-serving 使用mvn作为jar包管理以及打包的工具,在打包前必须满足几个先决条件:
- 安装jdk
- 有良好的网络
- 已安装maven
具体可以参考打包部署