作者：京东科技葛星宇

1.前言

本文除特殊说明外，所指的都是 fate 1.9 版本。

fate 资料存在着多处版本功能与发布的文档不匹配的情况，各个模块都有独立的文档，功能又有关联，坑比较多，首先要理清楚各概念、模块之间的关系。

2.网络互联架构

1. 概念解释：

RollSite 是一个 grpc 通信组件，是 eggroll 引擎中的一个模块，相当于我们的 grpc 通信网关。

Exchange 是 RollSite 中的一个功能，用于维护各方网关地址，并转发消息。参考《FATE exchange 部署指南》

2. 对比解读：

l 网状架构相当于我们的一体化版本模式，但没有 dop 平台来维护网关，每方需要在配置文件里维护其他参与方的网关地址。

l 星型架构的好处是只在 Exchange 方维护所有参与方的网关地址，前提是需要信任 Exchange，并且流量全部都需要从 Exchange 方中转，相当于我们的中心化版本。但不支持证书。

3. Exchange 配置

在 Exchange 上配置路由表：

在各 party 方配置默认路由指向 exchange，不需要再配置每个 party 的地址。

3.总体架构

FATE 支持 eggroll 和 spark 两种计算引擎,搭配不同的通信组件，共五种组合，不同的通信模块不能兼容。

方案名	计算引擎	存储	通信	是否支持 exchange	task 调度	特点
EggRoll	nodemanager	nodemanager	rollsite	是	clustermanager	原生、最成熟
Spark_RabbitMQ	spark	hdfs	nginx+ rabbit	否	yarn？	简单易上手的 MQ
Spark_Pulsar	spark	hdfs	nginx+ pulsar	是	yarn？	比 RabbitMQ，可以支持更大规模的集群化部署
Slim FATE	spark_local	localFS	nginx+ pulsar	是	spark？	最小资源。可用 rabbit 替代 pulsar

参考：：《不同类型 FATE 的架构介绍》

区别：

l RabbitMQ 是一个简单易上手的 MQ

l Pulsar 相比 RabbitMQ，可以支持更大规模的集群化部署，也支持 exchange 模式的网络结构。

l Slim FATE 相比其他模式，最大化减少集群所需的组件，可以使用在小规模联邦学习计算，IOT 设备等情况。

3.1.基于 EggRoll 引擎的架构

Eggroll 是 FATE 原生支持的计算存储引擎，包括以下三个组件：

l rollsite 负责数据传输，以前的版本里叫 Proxy+Federation

l nodemanager 负责存储和计算

l clustermanager 负责管理 nodemanager

3.2.基于 spark+hdfs+rabbitMQ 的架构

3.3. 基于 spark+hdfs+Pulsar 的架构

3.4. spark_local (Slim FATE)

支持 rabbitMQ 替换 pulsar

4. 组件源码

所有的 fate 项目都在这个叫 FederateAI 社区的 URL 下：https://github.com/FederatedAI

主项目：FATE是一个汇总的文档和超链集合，学习入口，在线文档

关联项目：

•KubeFATE docker 和 k8s 的部署

•AnsibleFATE 相当于我们的图形化部署版的底层脚本学习入口

•FATE-Flow 联合学习任务流水线管理模块，注册、管理和调度中心。

•EggRoll 第一代 fate 的计算引擎

•FATE-Board 联合学习过程可视化模块，目前只能查看一些记录

•FATE-Serving 在线联合预测，学习入口

•FATE-Cloud 联邦学习云服务,类似于我们的 dop 平台，管理功能。

•FedVision 联邦学习支持的可视化对象检测平台

•FATE-Builder fate 编译工具

•FedLCM 新增的项目：创建 FATE 联邦并部署 FATE 实例。目前仅支持部署以 Spark 和 Pulsar 作为基础引擎，并使用 Exchange 实现互相连接的

5. FATE-Flow

FATE Flow 是调度系统，根据用户提交的作业 DSL，调度算法组件执行。

官网文档

服务能力:

· 数据接入

· 任务组件注册中心

· 联合作业&任务调度

· 多方资源协调

· 数据流动追踪

· 作业实时监测

· 联合模型注册中心

· 多方合作权限管理

· 系统高可用

· CLI、REST API、Python API

5.1. 流程架构

旧版，图比较立体

· DSL Parser：是调度的核心，通过 DSL parser 可以拿到上下游关系、依赖等。

· Job Scheduler：是 DAG 层面的调度，把 DAG 作为一个 Job，把 DAG 里面的节点 run 起来，就称为一个 task。

· Federated Task Scheduler：最小调度粒度就是 task，需要调度多方运行同一个组件但参数算法不同的 task，结束后，继续调度下一个组件，这里就会涉及到协同调度的问题。

· Job Controller：联邦任务控制器

· Executor：联邦任务执行节点，支持不同的 Operator 容器，现在支持 Python 和 Script 的 Operator。Executor，在我们目前的应用中拉起 FederatedML 定义的一些组件，如 data io 数据输入输出，特征选择等模块，每次调起一个组件去 run，然后，这些组件会调用基础架构的 API，如 Storage 和 Federation Service ( API 的抽象 ) ，再经过 Proxy 就可以和对端的 FATE-Flow 进行协同调度。

· Tracking Manager：任务输入输出的实时追踪，包括每个 task 输出的 data 和 model。

· Model Manager：联邦模型管理器

5.2. api service

DataAccess 数据上传，下载，历史记录,参考示例

Job 提交（并运行），停止，查询，更新，配置，列表，task 查询

Tracking

Pipeline

Model

Table

客户端命令行实际上是对 api 的包装调用，可以参考其示例

Python 调用 api示例

5.3. 算法模块

Federatedml模块包括许多常见机器学习算法联邦化实现。所有模块均采用去耦的模块化方法开发，以增强模块的可扩展性。具体来说，我们提供：

1.联邦统计: 包括隐私交集计算，并集计算，皮尔逊系数, PSI 等

2.联邦特征工程：包括联邦采样，联邦特征分箱，联邦特征选择等。

3.联邦机器学习算法：包括横向和纵向的联邦 LR, GBDT， DNN，迁移学习等

4.模型评估：提供对二分类，多分类，回归评估，聚类评估，联邦和单边对比评估

5.安全协议：提供了多种安全协议，以进行更安全的多方交互计算。

Figure 1： Federated Machine Learning Framework

可开发在 fate 框架下运行的算法：指南

6. FATE-Serving

6.1. 功能架构

6.2. 部署逻辑架构

Adatptor：默认的情况使用系统自带的 MockAdatptor，仅返回固定数据用于简单测试，实际生产环境中需要使用者需要自行开发并对接自己的业务系统。（这部分可以看看能不能对接咱们自己的在线预测系统。）

l 支持使用 rollsite/nginx/fateflow 作为多方任务协调通信代理

l rollsite 支持 fate on eggroll 的场景，仅支持 grpc 协议，支持 P2P 组网及星型组网模式

l nginx 支持所有引擎场景，支持 http 与 grpc 协议，默认为 http，支持 P2P 组网及星型组网模式

l fateflow 支持所有引擎场景，支持 http 与 grpc 协议，默认为 http，仅支持 P2P 组网模式，也即只支持互相配置对端 fateflow 地址

6.3. 部署实例图

6.4. 工作时序图

6.5. 模型推送流程

蓝色为 guest 集群，灰色代表 host 集群

1. 通过 fate flow 建模 2. 分别部署 guest 方 Fate-serving 与 host 方 Fate-serving

3. 分别配置好 guest 方 Fate-flow 与 guest 方 Fate-serving、host 方 Fate-flow 与 host 方 Fate-serving。

4. Fate-flow 推送模型

5. Fate-flow 将模型绑定 serviceId

6. 以上操作完成后，可以在 serving-admin 页面上查看模型相关信息（此步操作非必需）。

7. 可以在 serving-admin 页面上测试调用（此步操作非必需）。

6.6. 搭配 nginx 代理

https://fate-serving.readthedocs.io/en/develop/example/nginx/

FATE-Serving 之间的交互可以通过 nginx 反向代理转发 grpc 请求，以下几种场景配置如下：

· 场景一：双方不配置 TLS，通过 nginx 四层代理转发

· 场景二：双方配置 TLS，通过 nginx 四层代理转发，双方分别进行证书校验

· 场景三：数据使用方配置 Client 端证书，Nginx 配置 Server 端证书，Host 不配置证书，通过 nginx 七层代理转发，由 Client 端和 nginx 进行证书校验

7. FATE Cloud

FATE Cloud 由负责联邦站点管理的云管理端 Cloud Manager 和站点客户端管理端 FATE Manager 组成，提供了联邦站点的注册与管理、集群自动化部署与升级、集群监控、集群权限控制等核心功能。

联邦云管理端（Cloud Manager）

联邦云管理端即联邦数据网络的管理中心，负责统一运营和管理 FATE Manager 及各站点，监控站点的服务与联邦合作建模，执行联邦各权限控制，保证联邦数据合作网络的正常运作；

联邦站点管理端（FATE Manager）

联邦站点管理端，负责管理和维护各自的联邦站点，为站点提供加入联邦组织、执行站点服务的自动化部署与升级，监控站点的联邦合作与集群服务，并管理站点用户角色与应用权限；

产品手册

8. 部署测试

共有 4 类部署方式，单机的安装模式是只提供了单机的安装文档，也可以研究怎么扩展成集群模式。

部署时会要求配置机器对应的角色，只能选 host，guest 和 Exchange，其中 host 和 guest 并没有区别，实际运行联邦时还是在 job 的配置中去配置哪一方是 guest，哪一方是 host，任务只能在 guest 方提交。

8.1. AllinOne

所有的组件都部署在一台机器上，比较适合开发调试，参考链接。

8.2. ansible

尝试用 ansible 部署时遇到了 python 相关的错误，指导文档也缺少详细的步骤，没有相关错误的说明。

8.3. k8s

手上没有 k8s 环境，暂未测试。

参考文档：《KubeFATE 部署 FATE 支持引擎介绍》

8.4. docker compose

容器部署尝试用 docker compose 方式部署了一对，比较顺利，参考了 2 篇官方文章，前边的准备步骤和安装过程参考此文，“验证部署” 及之后的步骤参考《Docker Compose 部署 FATE》

不同点如下：

8.4.1. 准备阶段

下载镜像较慢，如果大批量部署，可以搭建内网镜像服务。

| Role | party-id | OS | IP | |
| host | 20001 | Centos7.6 | 11.50.52.81 | 8C64G |
| guest | 20002 | Centos7.6 | 11.50.52.62 | 8C64G |
| 部署机 | | Centos7.6 | 11.50.52.40 | |

以上内容替代文档中对应的部分内容。

一开始我只部署了一台 host，本来打算这 2 台做一个集群，后来发现文档里没提这种方式，只好先按文档实验一次，于是又部署了 guest，这样在 guest 的配置里已经写好了 host 的地址，于是手动将配置更新到了 host 的/data/projects/fate/confs-20001/confs/eggroll/conf/route_table.json

发现不需要重启容器后续步骤也没报错，说明可以动态修改路由信息。

8.4.2. hetero_lr 测试

进入容器的时候，容器名包含的平台 id 需要修改成实际的。

json 格式定义说明文档

fateflow/examples/lr/test_hetero_lr_job_conf.json 中不同点，

修改对应的平台 id

"initiator": {
"role": "guest",
"party_id": 20002
},
"role": {
"guest": [
20002
],
"host": [
20001
],
"arbiter": [
20001
]
},

按文档写资源不够运行不了,需要修改如下

"job_parameters": {

    "common": {

      "task_parallelism": 1,

      "computing_partitions": 1,

      "task_cores": 1

},

不要修改 fateflow/examples/lr/test_hetero_lr_job_dsl.json 文件，文档中的配置是旧版本的，修改了就不能执行了，里面的 DataIO 组件已废弃。

运行测试后可以通过 board 查看，成功的 id：202211031508511267810

http://11.50.52.62:8080/#/history

http://11.50.52.81:8080/#/history

8.4.3. 模型部署

# flow model deploy --model-id arbiter-20001#guest-20002#host-20001#model --model-version 202211031508511267810

输出了产生的 model_version 是 202211031811059832400

1. 修改加载模型的配置

# cat > fateflow/examples/model/publish_load_model.json <<EOF
{
  "initiator": {
    "party_id": "20002",
    "role": "guest"
  },
  "role": {
    "guest": [
      "20002"
    ],
    "host": [
      "20001"
    ],
    "arbiter": [
      "20001"
    ]
  },
  "job_parameters": {
    "model_id": "arbiter-20001#guest-20002#host-20001#model",
    "model_version": "202211031811059832400"
  }
}
EOF

2. 修改绑定模型的配置

# cat > fateflow/examples/model/bind_model_service.json <<EOF
{
    "service_id": "test",
    "initiator": {
        "party_id": "20002",
        "role": "guest"
    },
    "role": {
        "guest": ["20002"],
        "host": ["20001"],
        "arbiter": ["20001"]
    },
    "job_parameters": {
        "work_mode": 1,
        "model_id": "arbiter-20001#guest-20002#host-20001#model",
        "model_version": "202211031811059832400"
    }
}
EOF

3. 在线测试

发送以下信息到"GUEST"方的推理服务"{SERVING_SERVICE_IP}:8059/federation/v1/inference"

# curl -X POST -H 'Content-Type: application/json' -i 'http://11.50.52.62:8059/federation/v1/inference' --data '{
  "head": {
    "serviceId": "test"
  },
  "body": {
    "featureData": {
        "x0": 1.88669,
        "x1": -1.359293,
        "x2": 2.303601,
        "x3": 2.00137,
        "x4": 1.307686
    },
    "sendToRemoteFeatureData": {
        "phone_num": "122222222"
    }
  }
}'

9.在 Jupyther 中构建任务

Jupyter Notebook 是 web 界面 IDE。已集成在 fate-client 容器中。

10. 总结

本文旨在从宏观的角度分析 FATE 的源码分布、总体架构、主要功能及核心流程，尚有许多细节和功能未深入研究，欢迎大家留言，互相学习。

↙↙↙阅读原文可查看相关链接，并与作者交流

作者：京东科技 葛星宇