3. 水印平台需求分析：别急着写代码，先想清楚要扛多大流量

做平台工程这些年，我见过太多团队一上来就咔咔写代码，等上线了才发现——用户并发一大，服务直接挂掉；算法扩展个新版本，得改半个月代码。说白了，需求分析没做透，后面全是坑。

这一章我们聚焦水印平台的需求。我把它拆成两块来聊：业务需求和非功能需求。业务需求回答“系统要做什么”，非功能需求回答“系统要做到什么程度”。两者缺一不可。

3.1 从业务场景到平台需求

先看业务需求。水印平台不是给一个人用的。内部多部门、外部多家客户，甚至还要支持第三方开发者接入。这就引出了三个核心问题。

3.1.1 多用户模型：租户隔离与权限分级

我记得在一家金融客户现场，他们要求同一个水印平台同时服务风控部、合规部和产品部。三个部门要互相看不见对方的水印模板和数据。这其实就是多租户架构的典型场景。

3.1.2 高并发场景：别让你的平台变成“排队机”

水印生成的并发压力往往集中在两个时刻：一是批量任务触发（比如凌晨对全量图片打水印），二是实时接口调用（比如用户上传图片后立即返回加水印的结果）。

• 批量场景：需要异步队列+工作节点横向扩缩。建议用Kafka或RabbitMQ做缓冲。
• 实时场景：请求必须快速响应。不能因为一个慢算法阻塞了所有其他请求。

我建议在设计初期就把实时和异步两条路径分开设计。异步任务可以容忍几秒甚至几分钟的延迟，但实时接口的SLA通常要求在200ms以内。混在一起搞，两边都做不好。

3.1.3 算法可插拔：水印算法的“乐高”模式

你想想看，今天系统跑的是频域水印，明天客户要换基于深度学习的隐写水印。如果算法是硬编码在业务逻辑里的，每次改算法都得重新部署整个服务。这不科学。

正确的做法是将算法定义为插件接口。每个算法实现一个统一的 Service Interface，通过注册中心动态加载。我过去在项目中用SPI机制做了类似设计，效果不错。

// 算法插件接口示例（简化版）
public interface WatermarkAlgorithm {
    String getAlgorithmId();
    WatermarkResult apply(WatermarkRequest request);
    AlgorithmConfig getDefaultConfig();
}

新算法只要实现这个接口，丢进类路径或配置中心，平台就能动态识别并启用。不需要改主流程代码。

3.2 非功能需求：延迟、吞吐量、可用性

非功能需求才是平台工程的硬仗。业务需求写再漂亮，性能不达标都是白搭。下面是我个人比较看重的三个核心指标。

3.2.1 延迟：满足用户对“快”的期待

对实时水印接口来说，延迟是用户体验的生命线。我记得之前一个客户明确要求P99延迟不超过300ms。为了达到这个目标，我们做了几件事：

1. 算法预热：在服务启动时预加载算法模型，避免首次调用时冷启动延迟。
2. 内存级缓存：对于相同图片参数的水印结果，做短时间缓存（几秒到几分钟）。
3. 隔离慢算法：把计算密集型算法（如深度学习水印）放到独立线程池，避免拖累轻量算法。

3.2.2 吞吐量：系统能扛多少活

吞吐量和延迟是跷跷板。同样的硬件资源，追求极低延迟就要牺牲吞吐量，追求高吞吐量就会增加延迟。所以不能只看单一指标。

我建议用吞吐量-延迟曲线来衡量系统能力。逐步增加并发数，观察延迟拐点。那个拐点就是系统的安全水位。

这里有一个常见的误区：很多人以为吞吐量不够就加机器。其实很多时候是锁竞争或者IO瓶颈导致的。我曾经遇过一个案例，数据库连接池设太小，导致大量请求排队等待连接，加再多应用节点也没用。

3.2.3 可用性：把系统做成“不倒翁”

水印平台往往是核心业务的一环。比如电商平台的大促期间，图片水印如果挂了，直接影响商品上架和营销活动。可用性要求一般至少是99.9%，核心链路甚至要求99.99%。

要支撑这个级别的可用性，架构上得下功夫：

• 无状态设计：水印生成服务本身不保存状态，所有状态放Redis或数据库。这样节点挂了可以随意替换。
• 冗余部署：至少两个可用区。单可用区故障时，流量自动切到另一个。
• 优雅降级：如果复杂的深度学习水印算法扛不住了，自动降级到轻量的传统水印，保证核心功能可用。

3.3 一张图看懂：水印平台需求全景

3.4 常见误区：我踩过的几个坑

• 需求分析只写功能，不写指标。 结果开发完后，测试验收时才发现延迟、吞吐量都不达标，不得不返工重构。
• 只压测一个场景。 我曾经只压测了实时水印接口，没压测批量任务，结果上线后批量任务把CPU打满，拖垮了实时接口。所以要混合场景压测。
• 忽略了“冷启动”问题。 很多水印算法第一次调用时，要加载模型文件、初始化CUDA上下文，耗时可能达到几秒。如果没做预热，第一波用户的体验会很差。
• 可用性只依赖单一容灾策略。 比如只做了多副本，但没做熔断降级。当数据库抖动时，所有副本同时受影响，照样不可用。