企业官网建设流程全解析

1. 狂潮分布式训练系统的架构缘起与设计哲学

1.1 从单机训练到分布式集群的必然跨越

做过大模型训练的人都有一个共识：单卡训不动，多卡不好训。当模型参数量从亿级跃升到百亿甚至千亿级别，单张显卡的显存和算力就成了硬天花板。我最早接触大模型微调的时候，用一张消费级显卡跑7B模型的全量微调，batch size只能开到1，梯度累积步数拉到32才勉强看到收敛趋势，一个epoch跑下来接近两天。这种效率在工业场景里根本不可接受。

分布式训练要解决的核心问题就三个：算力聚合、显存分摊、通信协调。数据并行把batch切到多卡上，每张卡持有完整模型副本，适合中小模型；张量并行把单层权重切到多卡上，适合单层参数巨大的情况；流水线并行把不同层分配到不同设备，适合层数极深的网络。狂潮分布式训练系统的设计出发点，就是把这三种并行策略统一到一个可配置、可扩展的框架里，同时用一套清晰的权责架构来约束各模块的行为边界。

为什么权责架构这件事值得单独拿出来讲？因为分布式训练系统最大的坑往往不在算法层面，而在工程层面。我见过太多团队在调试分布式训练时，因为某个进程越权访问了不属于它的显存区域，导致整个训练任务在跑了十几个小时之后突然崩溃，日志里只有一行含糊的CUDA error。这种问题的根源就是模块之间的权限边界没有定义清楚。

1.2 六层原子化权责架构的整体设计思路

狂潮系统的六层架构不是拍脑袋想出来的，它对应的是分布式训练任务从提交到完成的完整生命周期。每一层只做一件事，层与层之间通过明确定义的接口通信，任何跨层调用都必须经过权限校验。

这六层从下到上分别是：硬件抽象层、通信原语层、并行策略层、任务调度层、权限规约层、用户接口层。每一层都是原子化的，意味着它可以独立替换或升级，不会影响其他层的稳定性。比如你把底层的通信库从NCCL换成Gloo，只需要在通信原语层做适配，上层的并行策略和任务调度完全不用动。

这种设计的优势在于故障隔离。当训练任务出现异常时，你可以快速定位到是哪一层出了问题。如果是通信超时，问题大概率在通信原语层或硬件抽象层；如果是梯度同步不一致，问题可能在并行策略层；如果是权限拒绝导致的任务中断，那就要检查权限规约层的配置。

注意：原子化不等于简单化。每一层的内部实现可以很复杂，但对外暴露的接口必须足够简洁。这是狂潮系统设计时坚持的一条铁律。

1.3 模块边界与权限规约的核心价值

模块边界解决的是“谁能做什么”的问题，权限规约解决的是“谁能看什么”的问题。这两件事在单机训练时几乎不需要考虑，因为所有代码跑在同一个进程里，所有内存都是共享的。但到了分布式环境，每个进程、每个设备、每个通信组都有自己的状态，如果不加约束，就会出现资源竞争、数据污染、死锁等一系列问题。

狂潮系统的权限规约采用能力令牌机制。每个模块在启动时会被分配一个令牌，令牌里编码了该模块可以访问的资源范围、可以调用的接口列表、可以使用的通信组ID。当模块尝试执行一个操作时，权限规约层会检查令牌是否允许该操作。这种机制的好处是最小权限原则可以落地执行，而不是停留在文档里。

我实测下来，这套机制在排查“某个worker偷偷修改了全局配置”这类问题时特别有效。因为每次配置修改都会记录令牌ID，谁改的一查便知。

2. 六层架构逐层拆解与核心机制

2.1 硬件抽象层：屏蔽设备差异的第一道防线

硬件抽象层的职责是把不同厂商、不同型号的加速设备统一成一套标准接口。狂潮系统支持的主流加速卡包括NVIDIA的A100/H100系列、AMD的MI系列、以及部分国产加速卡。每类设备的驱动接口、内存管理方式、通信库都不尽相同，硬件抽象层通过适配器模式把这些差异封装起来。

具体来说，硬件抽象层定义了四个核心接口：device_init、memory_alloc、memory_free、stream_create。上层模块只调用这四个接口，不直接接触任何厂商特定的API。这样做的好处是，当你需要把训练任务从A100集群迁移到H100集群时，只需要在硬件抽象层更新适配器，上层的并行策略和任务调度代码一行都不用改。

这里有一个实操细节值得展开。硬件抽象层在初始化设备时，会为每个设备创建一个设备上下文，上下文里记录了设备的算力等级、显存容量、通信带宽、拓扑位置等信息。这些信息会被任务调度层用来做资源分配决策。比如调度器会优先把通信密集的并行组分配到NVLink带宽更高的设备上，把计算密集的任务分配到算力更强的设备上。

提示：设备上下文的初始化是一次性的，不要在训练循环里反复查询设备信息，那样会引入不必要的开销。我见过有团队在每次前向传播时都调用一次设备查询接口，结果训练速度直接掉了15%。

2.2 通信原语层：分布式训练的血管系统

通信原语层封装了所有跨设备的数据传输操作。狂潮系统在这一层提供了六种基础通信原语：broadcast、all_reduce、all_gather、reduce_scatter、send、recv。这六种原语可以组合出几乎所有分布式训练需要的通信模式。

为什么是这六种？因为它们是集合通信的最小完备集。broadcast用于参数服务器向所有worker分发初始权重；all_reduce用于梯度同步，这是数据并行的核心操作；all_gather用于收集各卡上的分片结果；reduce_scatter用于ZeRO优化器中的梯度分片归约；send和recv用于流水线并行中的阶段间通信。

通信原语层的实现基于NCCL和Gloo双后端。NCCL针对NVIDIA GPU做了深度优化，在NVLink和InfiniBand环境下能跑出接近线性的加速比。Gloo则作为CPU通信和跨平台场景的备选方案。狂潮系统会根据设备类型和网络拓扑自动选择后端，也支持手动指定。

这里有一个参数选择的关键点：通信组的大小。在数据并行中，所有参与梯度同步的worker构成一个通信组。通信组越大，all_reduce的延迟越高，但梯度平均的效果越好。我的经验是，当通信组超过64个worker时，all_reduce的延迟会显著上升，这时候需要考虑用分层all_reduce或者异步梯度更新来缓解。

# 通信组初始化示例 import kuangchao.distributed as kc # 创建包含8个worker的通信组 comm_group = kc.CommGroup( ranks=[0, 1, 2, 3, 4, 5, 6, 7], backend='nccl', timeout_ms=30000 ) # 执行all_reduce操作 kc.all_reduce(tensor=gradient_tensor, group=comm_group, op='sum')

2.3 并行策略层：数据、张量、流水线的统一编排

并行策略层是狂潮系统最核心的模块之一。它负责把用户的模型定义和训练配置转换成具体的并行执行计划。狂潮系统支持三种并行策略的任意组合，也就是常说的3D并行。

数据并行的实现相对直接：每个worker持有完整的模型副本，输入数据按batch维度切分，前向传播各自独立，反向传播后通过all_reduce同步梯度。狂潮系统在数据并行上做了一个优化：梯度累积与通信重叠。当梯度累积步数大于1时，系统会在计算当前微batch的梯度时，异步通信上一个微batch的梯度，这样通信时间就被计算时间掩盖了。

张量并行的实现要复杂得多。狂潮系统采用Megatron-LM风格的张量切分方案，把Transformer层的注意力矩阵和FFN矩阵按列或按行切分到不同设备上。列切分时，每张卡计算部分输出，然后通过all_gather拼接；行切分时，每张卡计算部分和，然后通过all_reduce求和。张量并行的通信量很大，所以狂潮系统建议只在NVLink域内使用张量并行，跨节点场景优先用流水线并行。

流水线并行的核心是微批次调度。狂潮系统实现了1F1B和交错式1F1B两种调度策略。1F1B的意思是前向一次、反向一次交替执行，这样可以把流水线气泡控制在合理范围内。交错式1F1B则进一步把每个设备上的层分成多个阶段，进一步压缩气泡。实测下来，在8卡流水线并行中，交错式1F1B比朴素1F1B能提升约20%的吞吐量。

2.4 任务调度层：资源分配与容错恢复

任务调度层负责把训练任务映射到具体的物理设备上，并在训练过程中监控设备状态，处理故障恢复。狂潮系统的调度器采用两级调度架构：第一级是集群级调度，决定任务分配到哪些节点；第二级是节点内调度，决定任务在节点内哪些GPU上运行。

集群级调度考虑的因素包括节点间的网络带宽、节点的当前负载、任务的优先级。狂潮系统实现了一个基于拓扑感知的调度算法，会优先把同一个任务的worker分配到网络延迟最低的节点上。在典型的叶脊网络架构中，这意味着同一个任务的worker尽量集中在同一个叶交换机下。

节点内调度则要考虑GPU之间的NVLink拓扑。8卡A100服务器通常有4组NVLink桥接，每组连接2张卡。调度器会尽量把通信密集的worker分配到同一组NVLink桥接的卡上。这个细节对训练效率的影响很大，我实测过，不考虑NVLink拓扑的调度方案比考虑拓扑的方案慢12%左右。

容错恢复是调度层的另一个核心功能。狂潮系统采用检查点+重试的策略。训练任务每隔一定步数会保存一次检查点，检查点包含模型权重、优化器状态、学习率调度器状态、数据加载器状态。当某个worker失败时，调度器会重新分配资源，从最近的检查点恢复训练。检查点的保存频率需要权衡：太频繁会影响训练速度，太稀疏会导致故障时丢失太多进度。我的经验是每500到1000步保存一次比较合适。

2.5 权限规约层：能力令牌与访问控制

权限规约层是狂潮系统区别于其他分布式训练框架的关键设计。它用能力令牌机制来约束每个模块的行为。令牌在模块初始化时由权限规约层签发，令牌里包含以下信息：

• 模块ID：唯一标识一个模块实例
• 资源范围：该模块可以访问的设备列表、内存区域、通信组
• 接口白名单：该模块可以调用的接口列表
• 有效期：令牌的过期时间
• 签名：防止令牌被篡改

当模块尝试执行一个操作时，权限规约层会拦截该操作，检查令牌是否允许。如果不允许，操作会被拒绝并记录审计日志。这种机制的好处是默认拒绝，而不是默认允许。任何未明确授权的操作都无法执行，这大大降低了误操作和恶意操作的风险。

我举个实际例子。在数据并行训练中，每个worker只需要访问自己的本地梯度，然后通过all_reduce同步。如果某个worker尝试直接读取另一个worker的本地梯度，权限规约层会拒绝这个操作，因为令牌里没有授权跨worker的直接内存访问。这种约束在调试阶段可能会觉得麻烦，但在生产环境中能避免很多诡异的问题。

注意：能力令牌的有效期不宜设置过长。我建议在长时间训练任务中，令牌有效期设置为1小时，到期前由权限规约层自动续签。这样即使令牌泄露，影响范围也有限。

2.6 用户接口层：配置即代码的实践

用户接口层是用户与狂潮系统交互的入口。狂潮系统采用配置即代码的理念，用户通过一个YAML配置文件来描述训练任务的全部信息，包括模型结构、数据集路径、并行策略、超参数、权限规约等。

为什么选择YAML而不是Python脚本？因为YAML更适合表达声明式的配置，而且可以方便地做版本管理和差异对比。Python脚本虽然灵活，但容易把配置逻辑和训练逻辑混在一起，导致复现困难。狂潮系统的YAML配置支持继承和覆盖，用户可以定义一个基础配置，然后针对不同实验覆盖特定字段。

# 狂潮训练配置示例 task: name: "llama3-8b-finetune" priority: "high" model: type: "llama" params: 8e9 checkpoint: "/data/checkpoints/llama3-8b" parallel: data_parallel_size: 4 tensor_parallel_size: 2 pipeline_parallel_size: 2 micro_batch_size: 4 gradient_accumulation_steps: 8 optimizer: type: "adamw" lr: 2e-5 weight_decay: 0.01 permission: token_ttl_seconds: 3600 audit_log: "/var/log/kuangchao/audit.log" allowed_interfaces: - "all_reduce" - "all_gather" - "broadcast"

用户接口层还提供了命令行工具和Python SDK两种交互方式。命令行工具适合快速提交任务和查看状态，Python SDK适合集成到现有的训练流水线中。

3. 实操部署与核心环节实现

3.1 环境准备与依赖安装

部署狂潮系统之前，需要确保集群环境满足以下条件：所有节点安装了兼容版本的CUDA驱动和NCCL库；节点间网络互通，且带宽满足训练需求；共享存储可用，用于存放检查点和日志；Python环境版本一致，建议3.9以上。

安装狂潮系统本身很简单，一条pip命令就能搞定。但真正的坑在于依赖版本的对齐。我踩过最惨的一次坑是NCCL版本不一致导致all_reduce结果随机错误，训练loss曲线看起来正常，但模型效果就是上不去，排查了三天才发现是两台机器的NCCL版本差了小版本号。

# 安装狂潮系统 pip install kuangchao-distributed # 验证安装 kc --version kc doctor # 检查环境依赖是否满足

kc doctor命令会检查CUDA版本、NCCL版本、网络连通性、共享存储挂载状态等，并给出修复建议。我建议在每次部署新集群时都先跑一遍这个命令。

3.2 集群初始化与节点发现

狂潮系统支持两种集群初始化方式：静态配置和动态发现。静态配置适合节点数量固定的场景，用户在一个配置文件里列出所有节点的IP和端口。动态发现适合弹性集群，节点启动后自动注册到调度器。

静态配置的示例如下：

cluster: mode: "static" nodes: - host: "10.0.1.1" gpus: 8 role: "worker" - host: "10.0.1.2" gpus: 8 role: "worker" - host: "10.0.1.3" gpus: 8 role: "parameter_server"

动态发现模式下，需要先启动一个注册中心，然后每个节点启动时向注册中心上报自己的信息。注册中心维护一个节点列表，调度器从注册中心获取可用节点。

节点发现完成后，狂潮系统会执行一次拓扑探测，收集节点间的网络延迟和带宽信息。这个信息会被调度器用来做资源分配决策。拓扑探测的结果会缓存起来，后续任务可以直接复用。

3.3 并行策略配置与调优

并行策略的配置是训练任务能否高效运行的关键。狂潮系统提供了一个自动并行功能，可以根据模型大小和集群规模推荐一个初始的并行配置。但自动推荐的结果不一定最优，还需要根据实际运行情况调优。

调优的核心指标是吞吐量和显存利用率。吞吐量用每秒处理的token数来衡量，显存利用率用峰值显存占设备总显存的比例来衡量。理想情况下，显存利用率应该在80%到90%之间，太低说明并行度不够，太高说明有OOM风险。

调优的步骤一般是：先固定数据并行度，调整张量并行度和流水线并行度，找到吞吐量最高的组合；然后微调micro batch size和梯度累积步数，进一步优化显存利用率和吞吐量。

我整理了一个调优的速查表：

3.4 权限规约配置与审计

权限规约的配置需要根据实际的安全需求来定。在内部可信集群中，可以适当放宽权限，减少令牌校验的开销。在多方共享的集群中，则需要严格配置权限，确保任务之间不会互相干扰。

狂潮系统的权限规约支持角色基础访问控制。用户可以定义不同的角色，每个角色有一组权限，然后把角色分配给模块。比如trainer角色可以访问模型参数和梯度，data_loader角色只能访问数据集，monitor角色只能读取训练指标。

审计日志是权限规约的重要组成部分。每次权限校验的结果都会记录到审计日志中，包括时间戳、模块ID、操作类型、校验结果。审计日志可以用于事后追溯和安全分析。我建议把审计日志输出到独立的存储中，避免被训练任务的大量日志淹没。

# 查看审计日志 kc audit --task llama3-8b-finetune --since "2024-01-01" --action "deny" # 输出示例 # 2024-01-15 10:23:45 | worker-3 | memory_read | DENIED | token expired # 2024-01-15 10:24:12 | worker-5 | all_reduce | ALLOWED | -

3.5 训练启动与监控

配置完成后，用一条命令就可以启动训练任务：

kc train --config llama3-8b-finetune.yaml

训练启动后，狂潮系统会输出实时的训练指标，包括loss、学习率、吞吐量、显存利用率、通信耗时占比等。这些指标可以通过命令行查看，也可以接入Prometheus和Grafana做可视化。

监控中有几个关键指标需要特别关注。通信耗时占比反映了通信开销在总训练时间中的比例，如果这个比例超过30%，说明通信是瓶颈，需要考虑优化并行策略。梯度范数反映了训练的稳定性，如果梯度范数突然增大，可能是出现了梯度爆炸，需要检查数据或降低学习率。显存利用率的波动反映了显存管理的效率，如果波动很大，可能存在显存碎片问题。

4. 常见问题与排查技巧实录

4.1 通信超时与死锁排查

通信超时是分布式训练中最常见的问题之一。表现是训练任务卡住不动，日志里出现NCCL timeout或Gloo timeout错误。排查思路是：先确认是哪个通信组超时，然后检查该通信组内所有worker的状态，找出没有响应all_reduce的worker。

常见原因包括：某个worker的GPU出现硬件故障；某个worker的进程被OOM killer杀掉；网络抖动导致部分worker失联；通信组配置不一致，比如有的worker用了NCCL后端，有的用了Gloo。

我遇到过一次很隐蔽的通信死锁：两个通信组的rank顺序不一致，导致all_reduce时互相等待。这种问题在日志里看不出来，需要用kc debug comm命令 dump 出所有通信组的状态才能发现。

提示：在训练脚本里加一个心跳检测机制，每隔30秒往一个共享的Redis里写一次时间戳。如果某个worker超过2分钟没有更新心跳，就可以判定它失联了。

4.2 梯度同步不一致的定位方法

梯度同步不一致的表现是：每个worker上的loss曲线 diverged，或者模型收敛速度明显慢于单卡训练。定位方法是：在每个worker上保存一份梯度快照，然后对比不同worker之间的梯度差异。

狂潮系统提供了一个kc debug gradient命令，可以自动对比所有worker的梯度，并输出差异最大的参数名称和差异值。如果差异集中在某几层，说明这几层的并行策略可能有问题。如果差异是全局性的，说明all_reduce的配置有问题。

我处理过的一个案例是：张量并行中列切分和行切分的顺序搞反了，导致梯度在all_reduce时维度不匹配，但系统没有报错，而是静默地做了截断。这种问题非常隐蔽，需要仔细检查并行策略的配置。

4.3 显存溢出与碎片化处理

显存溢出（OOM）是另一个高频问题。狂潮系统在OOM时会输出详细的显存分配记录，包括每个模块申请的显存大小和释放情况。通过分析这些记录，可以定位到是哪个模块占用了过多显存。

显存碎片化是OOM的一个隐蔽原因。当显存中散布着很多小的空闲块，但没有足够大的连续空间来分配新张量时，就会发生OOM。狂潮系统通过显存池化来缓解碎片化：预先分配一大块显存，然后在池内做分配和回收，避免频繁向驱动申请和释放显存。

如果碎片化问题严重，可以尝试调整memory_pool_size参数，增大显存池的大小。另外，及时释放不再使用的中间张量也很重要。狂潮系统提供了kc.memory.release_unused()接口，可以在训练循环的合适位置手动触发显存回收。

4.4 权限拒绝的常见场景与解决

权限拒绝通常是因为令牌配置不当。常见场景包括：令牌过期未续签；模块尝试访问未授权的设备；模块调用了不在白名单里的接口。

解决方法是查看审计日志，找到被拒绝的操作和对应的模块ID，然后检查该模块的令牌配置。如果是令牌过期，需要调整token_ttl_seconds参数或启用自动续签。如果是权限不足，需要在配置文件中把对应的资源或接口加入白名单。

我建议在开发阶段把权限规约的日志级别调到DEBUG，这样可以看到每次权限校验的详细信息。在生产阶段再调回INFO或WARN，避免日志过多。

4.5 检查点恢复失败的处理

检查点恢复失败通常是因为检查点文件损坏或版本不兼容。狂潮系统的检查点包含模型权重、优化器状态、随机数生成器状态等。如果检查点是在不同版本的狂潮系统上保存的，恢复时可能会因为格式变化而失败。

处理方法是：先用kc debug checkpoint命令检查检查点文件的完整性；如果文件损坏，尝试从更早的检查点恢复；如果版本不兼容，用kc checkpoint convert命令做格式转换。

我个人的经验是，每次保存检查点时同时保存一份元数据文件，记录狂潮系统版本、模型配置、并行策略配置。恢复时先读元数据文件，确认兼容性后再加载检查点。这样可以避免很多不必要的麻烦。

5. 性能调优与扩展实践

5.1 通信优化：从all_reduce到分层通信

通信是分布式训练的主要瓶颈之一。狂潮系统在通信优化上做了几件事：通信与计算重叠、分层all_reduce、梯度压缩。

通信与计算重叠是最基本的优化。在反向传播计算最后一层梯度时，前面层的梯度已经可以开始all_reduce了。狂潮系统通过CUDA stream的优先级调度，让通信kernel和计算kernel并行执行。

分层all_reduce适合大规模集群。当worker数量超过单交换机容量时，先在交换机内部做all_reduce，然后在交换机之间做all_reduce，最后再广播回所有worker。这样可以把跨交换机的通信量降低一个数量级。

梯度压缩是有损优化，通过量化或稀疏化减少通信数据量。狂潮系统支持FP16压缩和Top-K稀疏化。FP16压缩把梯度从FP32降到FP16，通信量减半，对精度影响很小。Top-K稀疏化只传输最大的K个梯度，通信量可以降到10%以下，但需要配合误差补偿来维持收敛性。

5.2 计算优化：算子融合与混合精度

计算优化的核心是减少kernel启动开销和充分利用Tensor Core。狂潮系统内置了算子融合功能，可以把多个小算子合并成一个大kernel，减少kernel启动次数。比如把LayerNorm的多个操作融合成一个kernel，把注意力计算中的softmax和dropout融合。

混合精度训练是另一个重要的优化手段。狂潮系统支持AMP自动混合精度，前向和反向传播用FP16计算，权重更新用FP32。这样可以在保持精度的同时，把计算速度提升1.5到2倍，显存占用降低约40%。

注意：混合精度训练中，loss scaling是关键。狂潮系统默认使用动态loss scaling，会根据梯度是否溢出自动调整scale因子。如果训练中出现大量溢出，可以手动降低初始scale因子。

5.3 扩展性测试：从8卡到512卡的线性度分析

狂潮系统在扩展性上做了大量优化，但实际扩展效果取决于集群的网络和存储。我做过一组扩展性测试，从8卡扩展到512卡，记录吞吐量的变化。

在8卡到64卡范围内，吞吐量基本线性增长，扩展效率在90%以上。从64卡到128卡，扩展效率降到80%左右，主要瓶颈是跨交换机通信。从128卡到512卡，扩展效率进一步降到65%左右，这时候需要考虑用分层all_reduce和梯度压缩来优化。

扩展性测试的结果可以帮助确定最优的并行配置。如果扩展效率低于70%，说明继续增加worker数量不划算，应该考虑优化单卡效率或者换用更高效的并行策略。

5.4 多模态大模型训练的适配要点

多模态大模型训练对分布式系统提出了额外要求。多模态模型通常包含视觉编码器和文本解码器两部分，两部分的计算特性和通信模式不同。狂潮系统支持异构并行，可以为视觉编码器和文本解码器分别配置不同的并行策略。

视觉编码器的参数量相对较小，但输入分辨率高，计算密集。文本解码器的参数量大，但输入序列长度可变。狂潮系统建议对视觉编码器使用数据并行，对文本解码器使用张量并行加流水线并行。

多模态训练中的数据加载也更复杂。图像需要解码、缩放、归一化，文本需要分词、padding。狂潮系统的数据加载层支持流水线预取，在GPU计算的同时，CPU预取并预处理下一批数据，避免数据加载成为瓶颈。

6. 个人实操体会与后续扩展方向

这套六层架构我在三个不同规模的集群上都部署过，从8卡的小型集群到256卡的中型集群，整体稳定性比我之前用过的其他方案要好。权限规约层虽然增加了一些配置复杂度，但在多团队共享集群的场景下，它带来的隔离性和可追溯性是值得的。

有一个细节我想特别提一下：狂潮系统的日志格式是结构化的JSON，每条日志都包含时间戳、模块ID、日志级别、消息内容。这种格式对后续的日志分析和告警配置非常友好。我基于这些日志搭了一个简单的异常检测脚本，当某个worker的通信耗时突然增大时自动发告警，提前发现了好几次网络故障。

后续如果要扩展这套系统，我觉得有几个方向值得尝试。一是支持弹性训练，在训练过程中动态增减worker，适应集群负载变化。二是集成自动超参调优，根据训练曲线自动调整学习率和batch size。三是支持联邦学习场景，在多个数据孤岛之间做分布式训练而不共享原始数据。这些方向都需要在现有的六层架构上做扩展，但核心的权责分离和权限规约思想是可以复用的。