FATE serving2.0简介

fate-serving是FATE的在线部分，在使用FATE进行联邦建模完成之后，可以使用fate-serving进行在线联合预测。 **目前的文档只适用于2.0以上版本 ** FATE-SERVING 2.0 支持的特性：

1.单笔预测，2.0.*版本guest方与host方将并行计算，从而降低了耗时。
2.批量预测，2.0.*版本开始引入的新的特性，一次请求可以批量提交一批需要预测的数据，极大地提高了吞吐量。
3.并行计算，在1.3.*版本中guest方的预测与host方的预测是串行，从2.0版本开始guest方与host方将采用并行预测的方式，各方预测时可以根据特征数量拆分成子任务再并行计算。
4.可视化的集群操作界面，引入新的组件serving-admin，它将提供集群的可视化操作界面，包括模型的管理、流量的监控、配置的查看、服务的管理等操作。
5.新的模型持久化/恢复方式，在serving-server重启时1.3.*版本采用了回放推送模型的请求的方式来实例重启时恢复模型 ，2.0.* 版本使用了直接恢复内存数据的方式恢复模型。
6.java版的SDK，使用该SDK可以使用FATE-SERVING带有的服务治理相关的功能，如服务自动发现、路由等功能。
7.新的扩展模块，将需要用户自定义开发的部分（如：host方的特征获取adaptor接口开发）放到该模块，从而与核心源码分离。
8.支持多种缓存方式，FATE-SERVING在1.3.*版本强依赖redis，从2.0.*版本开始，不再强依赖redis。可以选择不使用缓存、使用本地内存缓存、使用redis。
9.更改内部预测流程，重构了核心代码，去除调了前后处理等组件，使用了统一的异常处理。算法组件不再跟rpc接口紧耦合。

架构图

部署架构

fate-serving 的部署架构图如下

如上图所示，整个集群需要有几个组件

• serving-server

  serving-server用于实时处理在线预测请求,理论上serving-server需要从fate-flow加载模型成功之后才能对外提供服务。在FATE中建好模型之后，通过fate-flow的推送模型脚本可以将模型推送至serving-server。 推送成功之后，serving-server会将该模型相关的预测接口注册进zookeeper ，外部系统可以通过服务发现获取接口地址并调用。同时本地文件持久化该模型,以便在serving-server实例在集群中某些组件不可用的情况下，仍然能够从本地文件中恢复模型。

• serving-proxy

  serving-proxy 是serving-server的代理，对外提供了grpc接口以及http的接口，主要用于联邦预测请求的路由转发以及鉴权。在离线的联邦建模时，每一个参与方都会分配一个唯一的partId。serving-proxy维护了一个各参与方partId的路由表，并通过路由表中的信息来转发请求。

• serving-admin

  serving-admin 提供在线集群的可视化操作界面，可以查看管理集群中各节点的配置以及状态、查看模型列表、流量的调控、并能提供一定的监控的功能。

• zookeeper

  zookeeper 用户各组件的信息同步协调以及服务注册于发现

工作时序图