📚 课程目录第3章隐私共享SDK的架构与核心组件

3. 隐私共享SDK的架构与核心组件：模块划分与数据流

聊到隐私共享SDK，很多人第一反应就是“一堆加密算法拼起来”。其实不然。真正的工业级SDK，它更像一个分工明确的小型系统。每个模块各司其职，数据在里面流转，最终才吐出安全可用的结果。

我个人习惯把SDK的架构拆成四个核心层：接入层、策略层、计算层和输出层。你想想看，任何一条隐私计算请求，都是先敲门（接入），再问规矩（策略），然后干活（计算），最后交结果（输出）。这四层里，输出层就是我们这门课的重头戏——控制策略就在这里落脚。

我记得刚做第一版SDK时，把输出控制写死在业务代码里，结果上线没多久就被运维追着改。打那以后，我就明白了：输出策略必须作为一个独立的模块去设计。

下面这张表，我把SDK的核心模块拆出来给你看。每个模块的职责、输入、输出都列清楚了。后面我们一个个细聊。

💡 个人经验：模块间通信最好用轻量级的protobuf或者flatbuffers，别用JSON。我在一个金融征信项目里吃过亏——JSON序列化太慢，拖累了整个数据流。换成protobuf后，链路耗时降了30%左右。

模块是“房间”，组件就是“房间里的家具”。我把每个模块里的关键组件拎出来，给你讲明白。

权限网关：
- 校验器：每次请求都带一串，网关先查这块是不是伪造的、有没有过期。
- 请求分发器：校验通过后，根据请求类型（比如读数据/写策略）把请求丢给不同的下游模块。
策略引擎：
- 策略仓库：存所有隐私策略的版本。我建议用Git做底层的版本管理，方便回滚。
- 策略匹配器：根据请求的上下文（比如数据用途、参与方ID）匹配最合适的策略。说白了，就是拿你的请求跟仓库里的规则进行比对。
输出控制器（重点来了）：
- 审计日志记录器：每次输出都留痕。谁、什么时候、输出了多少行数据，一条都不能少。
- 脱敏器：按策略要求对结果中的敏感字段做打码、替换或截断。
- 行数限制器：这里有个典型坑——输出行数不是写死的，而是根据数据和策略动态算出来的。

⚠️ 我曾经踩过的坑：输出控制器的脱敏器和行数限制器如果串行执行，会引发性能瓶颈。比如先脱敏再限制行数，脱敏完的数据量可能比预期大很多，白白浪费计算资源。正确做法是先做行数限制，再做脱敏。顺序调一下，性能差一倍。

光看模块有点干。我们走一遍数据流，你就明白它们怎么串起来的。下文这张SVG流程图，把核心路径画得清清楚楚。

OK，结合这张图，我带你捋一遍数据流的每个步骤。下面是一个流程清单，你对照着图看会更清晰。

发起请求：外部消费者把请求（带）发给权限网关。
认证与授权：权限网关验，确认你有没有权限碰这批数据。
查询策略：验过身份后，网关把请求丢给策略引擎。策略引擎从仓库里拉出匹配的隐私策略。
隐私计算：策略引擎拿着策略，跟隐私计算模块协作，算出结果。注意，这里算出来的结果还是原始态的。
输出审计与控制：计算结果先进入输出控制器。控制器把策略引擎下发的策略拿来，开始做三件事：
- 审计日志记录器先记一笔日志——“谁要干嘛”。
- 行数限制器按策略把结果截断至安全行数。
- 脱敏器对敏感字段做脱敏（比如手机号中间四位变*）。
结果返回：经过上述控制的数据，才是最终输出的安全结果。

🔑 核心要点：在整个数据流中，输出控制器是最后一道关卡。它会跟策略引擎保持实时通信，但只接收“规则”，不接收“数据”。我曾经见过一个设计，把原始数据临时存在输出控制器里做二次计算，结果被攻破了内存——这是典型的架构失误。输出控制器应该只做策略执行，不做数据计算。

模块划分清楚了，数据流也走了一遍。我们再看看模块之间的依赖。这部分决定了你SDK部署时，能不能拆分、能不能热升级。

💡 项目实战建议：我在一个联邦学习场景里，把策略引擎跟输出控制器的通信改成了发布/订阅模式。原来每次输出都要请求一次策略，改了之后吞吐量从500 QPS提升到2000 QPS。原因是策略变动频率远低于请求频率。

你可能会问：这个架构我能不能自己改？当然可以。但有个判断标准——高内聚、低耦合。我自己判断一个好架构的办法很简单：试着删掉某个模块，看剩下模块能不能正常运行。如果删掉“输出控制器”，整个SDK就瘫了，说明它内聚够强；如果能正常运行，那这个模块就是多余的。