那些年，我遇到的奇葩需求

引言：需求从来不只是“需求”

作为一名架构师，我在过去几年里经历了无数个从产品侧抛过来的需求。有合理的、有挑战性的、也有让人啼笑皆非的。有些时候，需求本身看起来不难，但背后隐藏的业务逻辑和系统复杂性远超预期。更有些需求，直接用一句话就能让人愣住：“我们想要的是这个……但不能动数据库。”或者，“能实时同步数据吗？但服务器只能部署在本地。”

今天，我想通过几个真实的项目场景，分享一些我在实际工作中遇到的“奇葩”需求及其背后的解决方案。希望能给同样奋战在一线的技术同行们带来一点启发，少走点弯路。

---

一、需求1：用户画像功能 + 脱敏策略 = “既要又要还要”

项目背景

大约两年前，我参与了一个金融客户的数据分析平台项目，核心目标是搭建一套完整的用户画像系统，用于风控建模和营销推荐。

当时的产品经理（一位非常聪明但也极具想象力的朋友）提出了这样一个需求：

“我们希望对用户做多维标签打标，可以自由组合筛选，但是每个维度的数据必须脱敏，不能暴露原始字段。”

听到这句话时，我心里已经开始犯嘀咕了。脱敏？意味着数据库中的字段已经是不可读的加密或哈希值。那怎么做标签呢？

挑战分析

• 数据源头脱敏：整个系统从源头上就没有明文数据，只有哈希或者加密处理后的结果。
• 标签组合动态化：运营需要灵活组合多个标签进行筛选，比如“年龄30岁以上 AND 区域华北 AND 最近登录超过3次”。
• 性能要求高：用户量级达到千万级别，响应时间不能超过2秒。

如果只是脱敏，那还好办；如果只是标签系统，也还能应对。但问题是，这两者要在同一套系统中融合，并且要保证灵活性和性能。

技术方案与实现思路

经过几轮讨论和权衡，我们最终设计了一套基于“标签引擎 + 元信息映射”的架构方案：

架构图简述如下：

[前端] -> [标签服务API] -> [标签规则引擎] -> [元数据表 + 数据存储]

关键设计点：

1. 标签元信息表：我们构建了一张“标签元表”，记录每一个标签对应的业务含义、字段路径、脱敏函数类型及参数等信息。
2. 标签计算引擎：采用类似SQL解析的方式，将前端传来的组合条件拆解成结构化查询语句，然后由标签引擎去调用不同的处理模块。
3. 数据脱敏中间层：所有的数据访问都经过一层“数据翻译器”，它会根据配置的脱敏策略，对结果进行逆向还原（仅限展示）。

举个例子，一个用户的手机号被SHA-256加密保存，标签引擎内部记录了该字段对应“注册渠道=移动端”的规则。当筛选时，实际上是通过加密值进行匹配，而不是使用原始文本。

工具与技术栈选型：

• 标签计算引擎：自研轻量级DSL解释器，基于Java开发
• 存储层：ClickHouse + Redis缓存高频标签
• 权限控制：结合RBAC模型，在标签层级做细粒度权限隔离

小插曲：调试阶段遇到的坑

有一次测试同学反馈说筛选出来的结果为空。我们查了好久发现，问题出在一个“区域”字段的脱敏方式不同——部分字段用了MD5，另一些用了Base64编码。我们在标签元表中没有统一标准化，导致查询逻辑无法识别正确的映射关系。

这提醒我们一个教训：即使做了脱敏，也需要对数据格式保持一致性约束。

效果总结

系统上线后运行稳定，单次筛选响应时间基本控制在1秒以内，支撑了上千种标签组合。更重要的是，客户审计部门对这套脱敏机制表示认可，既满足了安全合规要求，又未影响业务分析能力。

---

二、需求2：零延迟数据同步 + 本地私有网络 + 千万级并发？

项目背景

另一个让我印象深刻的项目是去年的一个电商直播平台项目。他们想构建一个实时订单监控看板，支持每秒数万甚至数十万笔交易事件的接收和展示。

产品经理的需求文档里赫然写着：

“我们要看到每一笔新订单产生的那一刻，页面就要显示出来，不允许任何延迟。”

听起来像是典型的“实时推送”应用场景。然而，接下来一句话差点把我吓懵：

“系统必须全部部署在内网环境，公网不能有任何暴露端口。”

换句话说，他们想要公网级别的实时能力，但整个系统都在私网里。再加上，他们计划接入至少10家第三方销售平台的订单接口，每家都有自己的接入协议和数据格式。

挑战分析

• 实时性要求极高：期望延迟低于100ms。
• 网络隔离严重：所有服务必须部署在公司内网，外部数据源通过代理访问。
• 异构数据源众多：不同平台返回的数据结构差异大，需统一抽象建模。
• 并发压力大：预估峰值QPS可达80,000以上。

解决方案

我们最终决定采用以Kafka为核心的流式架构：

架构概览：

[外部订单源] 
    → [边缘采集服务，Nginx代理] 
        → [Kafka消息队列] 
            → [Flink实时处理] 
                → [Redis缓存 + MySQL写入] 
                    → [WebSocket推送前端]

实现细节：

1. 边缘采集层：为每一家平台定制适配器，负责接收原始数据并转换为统一结构的消息体。通过Nginx反向代理打通内外网通道。
2. Kafka集群：作为消息缓冲中枢，解决流量削峰填谷的问题。
3. Flink流处理引擎：负责清洗、转换、聚合实时订单数据，并写入缓存和数据库。
4. WebSocket推送：前端通过SockJS+Spring WebFlux建立长连接，接收实时更新。

特别优化点：

• Kafka分区策略：按照订单ID Hash分片，确保同用户订单落在同一个分区，避免数据混乱。
• Flink状态管理：利用RocksDB后端支持亿级状态维护，保障聚合准确性。
• 本地DNS缓存：由于部署于内网，DNS解析成为瓶颈之一。我们在边缘节点加了本地缓存，显著提升初始化速度。

小感悟

这个项目最艰难的部分不是技术实现，而是说服运维团队接受这种混合架构的安全性。尤其是关于是否允许Kafka外网可访问这一块，我们开了整整三次评审会议才达成共识。

最终，这套系统扛住了双十一期间的流量洪峰，前端订单看板实现了真正的毫秒级更新。

---

三、需求3：微服务之间共享用户身份认证信息，但不想用OAuth2？

项目背景

再往前推一年，我曾参与过一个企业内部办公系统的重构项目。原有系统是典型的单体架构，现在正在迁移到Spring Cloud微服务架构。

其中有个看似简单、实则很绕的需求：

“我们的用户鉴权已经有一套完善的SSO系统，但不想重新引入OAuth2或JWT，能不能在各微服务之间共享session信息？”

乍一听没问题，但深入考虑你会发现：如果不用标准协议，session如何跨服务共享？而且是在微服务架构下，各服务独立部署！

挑战分析

• 拒绝使用标准协议：已有的认证体系不兼容主流协议。
• 跨服务身份传递困难：每个请求都需要携带当前用户上下文。
• 分布式Session管理成本高：传统Redis共享session方案存在并发锁和性能问题。

我们的做法

我们最终采取了一种折中方案：自定义Token + 上下文拦截器 + 分布式缓存。

具体流程如下：

1. 用户登录后，SSO系统生成一段加密字符串（token），内容包含用户ID、签名、有效期等。
2. 每个微服务的Filter拦截到请求头中的token，校验签名有效后提取用户信息。
3. 用户信息存储在ThreadLocal变量中，供后续业务代码获取。
4. Token缓存在Redis中，设置短时效（如5分钟），并定期刷新续期。

优势与代价：

优点	缺点
不依赖现有协议，平滑迁移原有系统	安全性略弱，需自行实现加密/签名校验
可控性强，无需改动现有认证机制	Token泄露风险需额外控制
易于集成进现有微服务框架	维护成本稍高

小Tips

• 建议在Token中嵌入随机salt，防重放攻击；
• 使用AOP切面统一处理token解析逻辑，减少业务侵入性；
• 结合白名单机制，限制Token的来源IP和使用场景。

---

四、经验总结与建议

回顾这些年的从业经历，我发现所谓的“奇葩需求”其实往往来自以下几个方面：

1. 业务方对技术认知不足：他们可能并不了解技术边界，提出的需求看似合理实则难以落地。
2. 历史包袱沉重：旧系统遗留下来的逻辑和技术债务，让新需求变得畸形。
3. 安全与效率之间的博弈：特别是在金融、政务等领域，合规性与用户体验往往难以两全。

面对这些问题，我认为架构师最重要的一点就是：保持沟通，提前介入需求设计阶段。

以下是一些具体建议：

• 尽早与产品沟通技术可行性，不要等到开发阶段才发现问题。
• 用技术手段抽象业务复杂度，比如用标签引擎来封装复杂的组合逻辑。
• 适当妥协但坚持原则，对于不合理的需求要敢于说“不”，同时给出替代方案。
• 重视日志与监控体系建设，很多奇葩需求上线后容易出问题，提前埋好监控点至关重要。

---

写在最后

这些年来，我越来越觉得，架构师的价值不仅在于设计一个优雅的技术方案，更在于理解那些不完美、不合理的需求背后的业务诉求。很多时候，我们需要做的并不是反驳，而是寻找一种既能满足业务又能控制成本的平衡点。

当然，如果你也遇到过“客户希望把大象装冰箱，但冰箱门不能打开”的情况，欢迎留言交流，让我们一起在代码的世界里，笑着面对一切“奇葩”。

技术人的日常，就是在各种不可能之间找到一条可行之路。而这条路，往往也是最有意思的地方。