Flower 部署架构深度解析SuperLink、SuperExec、SuperNode 与多租户 Multi-Run 协同机制【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本文围绕 Flower 官方架构说明文档展开讲清楚一个部署形态的 Flower 联邦学习系统中各核心进程SuperLink、SuperExec、SuperNode的职责边界与协作关系并解释 SuperExec 如何按需管理多个短生命周期的训练应用进程、Multi-Run 如何实现多租户multi-tenancy / multi-job。读完本文你可以基于仓库源码验证这套架构的真实实现细节并理解为什么 AI 工程师只需编写ServerApp与ClientApp即可构建完整的联邦学习应用。从 Hub-and-Spoke 拓扑到进程化架构在联邦学习Federated Learning, FL中典型形态是一个服务器server与大量客户端clients相连接这组服务器 多个客户端的集合通常被称为一个联邦federation。其中服务器的角色是协调训练过程选择客户端、分发任务、聚合结果每个客户端的角色是接收来自服务器的任务、在本地执行这些任务并把结果返回给服务器。这种结构常被称为Hub-and-Spoke中心辐射拓扑中心 Hub 是服务器周围的 Spoke 是各客户端。但在真实生产部署中同一个联邦上往往需要运行多个不同的项目而每个项目可能使用不同的超参数如轮数、batch size不同的模型架构如 ResNet 与 MLP不同的聚合策略如 FedAvg 与 FedAvgM甚至不同的机器学习框架如 PyTorch 与 TensorFlow。为了让同一套基础设施承载这些互不相同的项目Flower 把服务端和客户端都拆分为两部分长生命周期部分long-lived负责跨网络的通信常驻运行与具体项目无关短生命周期部分short-lived执行任务特定的项目代码随用随启、用完即弃。这一拆分是整个 Flower 部署架构的核心设计思想下文各组件正是围绕长生命周期 通信骨架 / 短生命周期 项目代码来组织的。服务端三组件SuperLink、SuperExec 与 ServerApp一个 Flower服务器由以下三个部分组成组件生命周期职责SuperLink长生命周期向客户端SuperNode转发任务指令并接收任务结果返回是联邦中所有节点间通信的枢纽SuperExec长生命周期通过 SuperLink 按需调度、启动和管理多个应用进程如ServerApp默认由 SuperLink 自动拉起ServerApp短生命周期包含项目特定的服务端代码定制联邦学习的全部服务端逻辑客户端选择、客户端配置、结果聚合这是 AI 研究员与工程师构建 Flower 应用时实际实现的组件SuperLink 的源码实现从源码结构看SuperLink 在当前仓库中位于 flwr/superlink。main.py 中的create_app()构建了 SuperLink 的 FastAPI 服务其关键事实包括中间件链中包含ControlAuthenticationMiddleware、ControlLicenseMiddleware、ProtobufTranslationMiddleware等见 _get_middleware说明 Control API 具备认证、License 与 Protobuf 报文翻译能力路由注册了三类 API健康检查health.router、Control APIcontrol_router、Runtime APIruntime_router并附加了RuntimeVersionDependency版本校验见 main.py#L209-L217。Runtime API 正是 SuperExec 拉取任务所使用的接口Fleet 通信默认使用 gRPCfleet_api_type TRANSPORT_TYPE_GRPC_RERE见 main.py#L124-L143LinkState联邦运行时状态通过对象存储工厂初始化默认使用内存数据库FLWR_IN_MEMORY_DB_NAME也可通过FLWR_DATABASE配置外部数据库。SuperExec 由 SuperLink 自动拉起的证据文档声明 SuperExec 默认由 SuperLink 自动启动。这一事实在源码中得到直接印证flower_superlink.py 中的SuperLinkLifespan持有superexec_process: subprocess.Popen并在 startup 阶段调用_start_superexec_if_needed()以flower-superexec子进程方式启动 SuperExecshutdown 时则会 terminate 该子进程。这与由 SuperLink 自动管理 SuperExec 生命周期的描述完全一致。ServerApp工程师实际编写的项目代码ServerApp的实现在 flwr/serverapp/server_app.py支持两种典型编写方式# 方式一配合已有 Strategy 使用 def server_fn(context: Context): server_config ServerConfig(num_rounds3) strategy FedAvg() return ServerAppComponents( strategystrategy, server_configserver_config, ) app ServerApp(server_fnserver_fn) # 方式二自定义 main 函数 app ServerApp() app.main() def main(grid: Grid, context: Context) - None: print(ServerApp running)源码中还明确约束了两者不可同时提供BOTH_MAIN_FN_SERVER_FN_PROVIDED_ERROR_MSG见 server_app.py#L55-L77这正对应文档中ServerApp 定制客户端选择、配置与结果聚合的定位无论使用内置 Strategy 还是完全自定义的 Grid 主函数项目相关逻辑都被封装在这个短生命周期进程中。客户端三组件SuperNode、SuperExec 与 ClientApp一个 Flower客户端同样由三部分组成组件生命周期职责SuperNode长生命周期连接 SuperLink、请求任务、执行任务例如用你的本地数据训练这个模型并把结果返回给 SuperLinkSuperExec长生命周期通过 SuperNode 按需调度、启动和管理多个应用进程如ClientApp默认由 SuperNode 自动拉起ClientApp短生命周期包含项目特定的客户端代码定制联邦学习的全部客户端逻辑本地模型训练、评估、前后处理这是 AI 研究员与工程师构建 Flower 应用时在客户端侧实现的组件为什么叫 SuperNode官方文档给出的命名解释很直白在联邦学习中客户端才是真正的主角the actual stars of the show——它们持有训练数据、执行真正的训练。因此 Flower 决定将它们命名为SuperNode超级节点而SuperLink的职责则是充当连接所有 SuperNode 的缺失的环节missing link。ClientApp 的源码形态ClientApp实现在 flwr/clientapp/client_app.py。以最典型的用法为例将自定义的Client实现包装进ClientAppfrom flwr.app import Context class FlowerClient(NumPyClient): # ... 训练/评估/查询逻辑 def client_fn(context: Context): return FlowerClient().to_client() app ClientApp(client_fn)源码层面有两点值得注意签名检查与兼容适配_inspect_maybe_adapt_client_fn_signature 会检查client_fn是否为def client_fn(context: Context)形式若用户仍使用旧版client_fn(cid)签名会触发弃用警告并自动包装一个适配器从context.node_config或context.node_id中提取客户端标识——这体现了 Flower 对旧 API 的平滑兼容。消息类型约束当没有提供client_fn而使用app.handle()方式时消息类型必须是category或category.action形式且category必须是train/evaluate/query之一见 client_app.py#L146-L150。SuperNode 侧的 FastAPI 服务位于 flwr/supernode/main.py其应用状态中同样携带superexec_auth_secret用于 SuperNode 与其自动拉起的 SuperExec 之间的认证详见下文。SuperExec 深度解析短生命周期应用进程的管理器SuperExec 是文档中两个部署侧组件服务端与客户端共用的机制也是理解长/短生命周期拆分如何落地的关键。其主实现位于 flwr/supercore/superexec/run_superexec.py。主循环拉取 → 选择 → 认领 → 启动run_superexec()的核心是一个while True轮询循环run_superexec.py#L266-L312每一轮执行executor.reconcile()对现有任务进程做一致性检查client.PullPendingTasks()向 Runtime API 拉取待处理任务列表plugin.select_task(tasks)由插件的选择逻辑挑出一个任务executor.wait_for_capacity(...)按任务类型等待执行容量client.ClaimTask(ClaimTaskRequest(task_id))认领任务服务端返回 token 后才会真正启动应用claim_res.token为空则本轮什么都不做plugin.launch_task(token, task)启动对应的应用进程ServerApp 或 ClientApp并对启动结果ACCEPTED/CAPACITY_REJECTED/FAILED/UNKNOWN做日志与容错处理见 _handle_launch_result。从源码结构看PullPendingTasks与ClaimTask两个方法与 run_superexec.py#L54-L59 中定义的_SUPEREXEC_AUTH_METHODS完全对应——这两个接口受 HMAC 认证拦截器SuperExecAuthHttpInterceptor保护即 SuperLink/SuperNode 与 SuperExec 之间通过superexec_auth_secret共享密钥进行鉴权。轮询间隔配置SuperExec 的任务轮询间隔由环境变量FLWR_SUPEREXEC_TASK_POLL_INTERVAL控制_get_task_poll_interval配置项说明环境变量FLWR_SUPEREXEC_TASK_POLL_INTERVAL单位秒默认值1.0秒允许范围0.0160.0秒且必须为有限数值否则抛出ValueError作用控制 SuperExec 向 SuperLink/SuperNode 轮询新任务的频率与父进程的共生关系run_superexec()接受一个parent_pid参数一旦提供就会调用start_parent_process_monitor(parent_pid)run_superexec.py#L208-L210在父进程退出时让 SuperExec 自动终止。这正是文档所述SuperExec 默认由 SuperLink/SuperNode 自动启动的配套机制——子进程随宿主生命周期共生死。Multi-Run 与多租户一个联邦承载多个项目Flower 的multi-run能力允许在同一个联邦由单个常驻 SuperLink 与多个常驻 SuperNode 组成中同时运行多个ServerApp与ClientApp。这种能力也被称为multi-tenancy多租户或multi-job多作业。理解 multi-run 的关键细节是SuperNode 只有在被选中参与某次训练时才会启动对应的ClientApp。官方文档用两个 run 举例说明[run 1]ServerApp与ClientApp参与第一轮训练本轮中所有 SuperNode 都被选中因此每个 SuperNode 都运行各自的ClientApp[run 2]只有第 1、第 2 个 SuperNode 被选中参与训练其余 SuperNode 保持空闲不启动 ClientApp 进程。因此借助 Flower multi-run不同的 Flower App 项目可以运行在不同的客户端集合上——项目 A 训练时选中全部节点项目 B 训练时只选中部分节点两者共享同一套通信骨架SuperLink SuperNodes而项目特定的计算进程App由各自的 SuperExec 按需拉起。这与上文 SuperExec Pull → Select → Claim → Launch 的任务模型形成了闭环任务携带项目归属信息SuperNode 侧的 SuperExec 只认领属于自己 run 的任务。适用前提与延伸阅读需要明确两个边界本文档覆盖范围官方说明明确注明本文覆盖的是Flower Deployment Runtime部署运行时针对 Flower Simulation Runtime单机仿真运行时的说明文档将另行提供原文档 note 部分。因此上述 SuperLink/SuperNode 部署形态不适用于纯本地仿真场景版本演进Flower 团队在快速迭代中该说明文档会持续更新SuperExec 相关 API 与配置如执行器类型、认证方式以当前仓库源码为准。建议结合以下仓库路径继续深入SuperLink 服务入口与 API 组织framework/py/flwr/superlink/main.pySuperLink CLI 与 SuperExec 自动启动逻辑framework/py/flwr/superlink/cli/flower_superlink.pySuperExec 主循环与任务认领framework/py/flwr/supercore/superexec/run_superexec.pySuperNode 服务端入口framework/py/flwr/supernode/main.py开发者实际编写的两个应用组件framework/py/flwr/serverapp/server_app.py 与 framework/py/flwr/clientapp/client_app.py。小结Flower 部署架构的本质是把通信与计算解耦为两种生命周期的进程SuperLink 与 SuperNode 构成联邦的常驻通信骨架SuperExec 在两端按需拉起承载项目代码的 ServerApp / ClientApp从而让单个联邦能够同时承载多个使用不同超参数、模型、聚合策略乃至不同 ML 框架的训练项目。理解这条长生命周期管通信、短生命周期管业务的主线就能准确把握 Flower 中各个组件的职责边界并在源码中快速定位任意部署问题的责任方。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Flower 部署架构深度解析：SuperLink、SuperExec、SuperNode 与多租户 Multi-Run 协同机制
Flower 部署架构深度解析SuperLink、SuperExec、SuperNode 与多租户 Multi-Run 协同机制【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本文围绕 Flower 官方架构说明文档展开讲清楚一个部署形态的 Flower 联邦学习系统中各核心进程SuperLink、SuperExec、SuperNode的职责边界与协作关系并解释 SuperExec 如何按需管理多个短生命周期的训练应用进程、Multi-Run 如何实现多租户multi-tenancy / multi-job。读完本文你可以基于仓库源码验证这套架构的真实实现细节并理解为什么 AI 工程师只需编写ServerApp与ClientApp即可构建完整的联邦学习应用。从 Hub-and-Spoke 拓扑到进程化架构在联邦学习Federated Learning, FL中典型形态是一个服务器server与大量客户端clients相连接这组服务器 多个客户端的集合通常被称为一个联邦federation。其中服务器的角色是协调训练过程选择客户端、分发任务、聚合结果每个客户端的角色是接收来自服务器的任务、在本地执行这些任务并把结果返回给服务器。这种结构常被称为Hub-and-Spoke中心辐射拓扑中心 Hub 是服务器周围的 Spoke 是各客户端。但在真实生产部署中同一个联邦上往往需要运行多个不同的项目而每个项目可能使用不同的超参数如轮数、batch size不同的模型架构如 ResNet 与 MLP不同的聚合策略如 FedAvg 与 FedAvgM甚至不同的机器学习框架如 PyTorch 与 TensorFlow。为了让同一套基础设施承载这些互不相同的项目Flower 把服务端和客户端都拆分为两部分长生命周期部分long-lived负责跨网络的通信常驻运行与具体项目无关短生命周期部分short-lived执行任务特定的项目代码随用随启、用完即弃。这一拆分是整个 Flower 部署架构的核心设计思想下文各组件正是围绕长生命周期 通信骨架 / 短生命周期 项目代码来组织的。服务端三组件SuperLink、SuperExec 与 ServerApp一个 Flower服务器由以下三个部分组成组件生命周期职责SuperLink长生命周期向客户端SuperNode转发任务指令并接收任务结果返回是联邦中所有节点间通信的枢纽SuperExec长生命周期通过 SuperLink 按需调度、启动和管理多个应用进程如ServerApp默认由 SuperLink 自动拉起ServerApp短生命周期包含项目特定的服务端代码定制联邦学习的全部服务端逻辑客户端选择、客户端配置、结果聚合这是 AI 研究员与工程师构建 Flower 应用时实际实现的组件SuperLink 的源码实现从源码结构看SuperLink 在当前仓库中位于 flwr/superlink。main.py 中的create_app()构建了 SuperLink 的 FastAPI 服务其关键事实包括中间件链中包含ControlAuthenticationMiddleware、ControlLicenseMiddleware、ProtobufTranslationMiddleware等见 _get_middleware说明 Control API 具备认证、License 与 Protobuf 报文翻译能力路由注册了三类 API健康检查health.router、Control APIcontrol_router、Runtime APIruntime_router并附加了RuntimeVersionDependency版本校验见 main.py#L209-L217。Runtime API 正是 SuperExec 拉取任务所使用的接口Fleet 通信默认使用 gRPCfleet_api_type TRANSPORT_TYPE_GRPC_RERE见 main.py#L124-L143LinkState联邦运行时状态通过对象存储工厂初始化默认使用内存数据库FLWR_IN_MEMORY_DB_NAME也可通过FLWR_DATABASE配置外部数据库。SuperExec 由 SuperLink 自动拉起的证据文档声明 SuperExec 默认由 SuperLink 自动启动。这一事实在源码中得到直接印证flower_superlink.py 中的SuperLinkLifespan持有superexec_process: subprocess.Popen并在 startup 阶段调用_start_superexec_if_needed()以flower-superexec子进程方式启动 SuperExecshutdown 时则会 terminate 该子进程。这与由 SuperLink 自动管理 SuperExec 生命周期的描述完全一致。ServerApp工程师实际编写的项目代码ServerApp的实现在 flwr/serverapp/server_app.py支持两种典型编写方式# 方式一配合已有 Strategy 使用 def server_fn(context: Context): server_config ServerConfig(num_rounds3) strategy FedAvg() return ServerAppComponents( strategystrategy, server_configserver_config, ) app ServerApp(server_fnserver_fn) # 方式二自定义 main 函数 app ServerApp() app.main() def main(grid: Grid, context: Context) - None: print(ServerApp running)源码中还明确约束了两者不可同时提供BOTH_MAIN_FN_SERVER_FN_PROVIDED_ERROR_MSG见 server_app.py#L55-L77这正对应文档中ServerApp 定制客户端选择、配置与结果聚合的定位无论使用内置 Strategy 还是完全自定义的 Grid 主函数项目相关逻辑都被封装在这个短生命周期进程中。客户端三组件SuperNode、SuperExec 与 ClientApp一个 Flower客户端同样由三部分组成组件生命周期职责SuperNode长生命周期连接 SuperLink、请求任务、执行任务例如用你的本地数据训练这个模型并把结果返回给 SuperLinkSuperExec长生命周期通过 SuperNode 按需调度、启动和管理多个应用进程如ClientApp默认由 SuperNode 自动拉起ClientApp短生命周期包含项目特定的客户端代码定制联邦学习的全部客户端逻辑本地模型训练、评估、前后处理这是 AI 研究员与工程师构建 Flower 应用时在客户端侧实现的组件为什么叫 SuperNode官方文档给出的命名解释很直白在联邦学习中客户端才是真正的主角the actual stars of the show——它们持有训练数据、执行真正的训练。因此 Flower 决定将它们命名为SuperNode超级节点而SuperLink的职责则是充当连接所有 SuperNode 的缺失的环节missing link。ClientApp 的源码形态ClientApp实现在 flwr/clientapp/client_app.py。以最典型的用法为例将自定义的Client实现包装进ClientAppfrom flwr.app import Context class FlowerClient(NumPyClient): # ... 训练/评估/查询逻辑 def client_fn(context: Context): return FlowerClient().to_client() app ClientApp(client_fn)源码层面有两点值得注意签名检查与兼容适配_inspect_maybe_adapt_client_fn_signature 会检查client_fn是否为def client_fn(context: Context)形式若用户仍使用旧版client_fn(cid)签名会触发弃用警告并自动包装一个适配器从context.node_config或context.node_id中提取客户端标识——这体现了 Flower 对旧 API 的平滑兼容。消息类型约束当没有提供client_fn而使用app.handle()方式时消息类型必须是category或category.action形式且category必须是train/evaluate/query之一见 client_app.py#L146-L150。SuperNode 侧的 FastAPI 服务位于 flwr/supernode/main.py其应用状态中同样携带superexec_auth_secret用于 SuperNode 与其自动拉起的 SuperExec 之间的认证详见下文。SuperExec 深度解析短生命周期应用进程的管理器SuperExec 是文档中两个部署侧组件服务端与客户端共用的机制也是理解长/短生命周期拆分如何落地的关键。其主实现位于 flwr/supercore/superexec/run_superexec.py。主循环拉取 → 选择 → 认领 → 启动run_superexec()的核心是一个while True轮询循环run_superexec.py#L266-L312每一轮执行executor.reconcile()对现有任务进程做一致性检查client.PullPendingTasks()向 Runtime API 拉取待处理任务列表plugin.select_task(tasks)由插件的选择逻辑挑出一个任务executor.wait_for_capacity(...)按任务类型等待执行容量client.ClaimTask(ClaimTaskRequest(task_id))认领任务服务端返回 token 后才会真正启动应用claim_res.token为空则本轮什么都不做plugin.launch_task(token, task)启动对应的应用进程ServerApp 或 ClientApp并对启动结果ACCEPTED/CAPACITY_REJECTED/FAILED/UNKNOWN做日志与容错处理见 _handle_launch_result。从源码结构看PullPendingTasks与ClaimTask两个方法与 run_superexec.py#L54-L59 中定义的_SUPEREXEC_AUTH_METHODS完全对应——这两个接口受 HMAC 认证拦截器SuperExecAuthHttpInterceptor保护即 SuperLink/SuperNode 与 SuperExec 之间通过superexec_auth_secret共享密钥进行鉴权。轮询间隔配置SuperExec 的任务轮询间隔由环境变量FLWR_SUPEREXEC_TASK_POLL_INTERVAL控制_get_task_poll_interval配置项说明环境变量FLWR_SUPEREXEC_TASK_POLL_INTERVAL单位秒默认值1.0秒允许范围0.0160.0秒且必须为有限数值否则抛出ValueError作用控制 SuperExec 向 SuperLink/SuperNode 轮询新任务的频率与父进程的共生关系run_superexec()接受一个parent_pid参数一旦提供就会调用start_parent_process_monitor(parent_pid)run_superexec.py#L208-L210在父进程退出时让 SuperExec 自动终止。这正是文档所述SuperExec 默认由 SuperLink/SuperNode 自动启动的配套机制——子进程随宿主生命周期共生死。Multi-Run 与多租户一个联邦承载多个项目Flower 的multi-run能力允许在同一个联邦由单个常驻 SuperLink 与多个常驻 SuperNode 组成中同时运行多个ServerApp与ClientApp。这种能力也被称为multi-tenancy多租户或multi-job多作业。理解 multi-run 的关键细节是SuperNode 只有在被选中参与某次训练时才会启动对应的ClientApp。官方文档用两个 run 举例说明[run 1]ServerApp与ClientApp参与第一轮训练本轮中所有 SuperNode 都被选中因此每个 SuperNode 都运行各自的ClientApp[run 2]只有第 1、第 2 个 SuperNode 被选中参与训练其余 SuperNode 保持空闲不启动 ClientApp 进程。因此借助 Flower multi-run不同的 Flower App 项目可以运行在不同的客户端集合上——项目 A 训练时选中全部节点项目 B 训练时只选中部分节点两者共享同一套通信骨架SuperLink SuperNodes而项目特定的计算进程App由各自的 SuperExec 按需拉起。这与上文 SuperExec Pull → Select → Claim → Launch 的任务模型形成了闭环任务携带项目归属信息SuperNode 侧的 SuperExec 只认领属于自己 run 的任务。适用前提与延伸阅读需要明确两个边界本文档覆盖范围官方说明明确注明本文覆盖的是Flower Deployment Runtime部署运行时针对 Flower Simulation Runtime单机仿真运行时的说明文档将另行提供原文档 note 部分。因此上述 SuperLink/SuperNode 部署形态不适用于纯本地仿真场景版本演进Flower 团队在快速迭代中该说明文档会持续更新SuperExec 相关 API 与配置如执行器类型、认证方式以当前仓库源码为准。建议结合以下仓库路径继续深入SuperLink 服务入口与 API 组织framework/py/flwr/superlink/main.pySuperLink CLI 与 SuperExec 自动启动逻辑framework/py/flwr/superlink/cli/flower_superlink.pySuperExec 主循环与任务认领framework/py/flwr/supercore/superexec/run_superexec.pySuperNode 服务端入口framework/py/flwr/supernode/main.py开发者实际编写的两个应用组件framework/py/flwr/serverapp/server_app.py 与 framework/py/flwr/clientapp/client_app.py。小结Flower 部署架构的本质是把通信与计算解耦为两种生命周期的进程SuperLink 与 SuperNode 构成联邦的常驻通信骨架SuperExec 在两端按需拉起承载项目代码的 ServerApp / ClientApp从而让单个联邦能够同时承载多个使用不同超参数、模型、聚合策略乃至不同 ML 框架的训练项目。理解这条长生命周期管通信、短生命周期管业务的主线就能准确把握 Flower 中各个组件的职责边界并在源码中快速定位任意部署问题的责任方。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考