1. 课程导论与架构全景
各位同学好，我是老张。今天咱们开始聊人脸识别API在高并发场景下的架构设计。说实话，这个题目我琢磨了很久才决定开这门课。为什么？因为市面上讲人脸识别的教程不少，但真正能把「高并发」和「工程落地」讲透的，不多。
我记得2018年刚接手一个安防项目时，客户要求每秒处理5000张人脸比对。当时团队用的是单机部署的算法服务，结果压测一上，直接OOM。嗯，那场面挺尴尬的。从那以后，我就开始系统性地思考：到底怎么搭一套能扛住百万级QPS的人脸识别API？
1.1 人脸识别API的业务场景
先说说人脸识别API到底用在哪儿。你想想看，现在几乎每个带摄像头的地方都想做身份识别。我简单列几个典型场景：
- 安防门禁：小区、办公楼、机场闸机，刷脸通行。特点是并发不高但实时性要求极高，延迟超过500ms用户就会骂娘。
- 金融支付：刷脸支付、远程开户。对安全等级要求最高，活体检测必须到位，而且需要和风控系统联动。
- 社交娱乐：美颜相机、短视频特效。并发量巨大，但允许一定的延迟和错误率，说白了就是「差不多就行」。
- 智慧零售：会员识别、客流分析。需要持续的视频流处理，对成本敏感，不能每路都上GPU。
核心观点：不同场景对延迟、吞吐、准确率、成本的要求完全不同。架构设计的第一步，就是搞清楚你的业务到底属于哪一类。
1.2 高并发挑战到底在哪
很多人觉得人脸识别API不就是调个接口吗？有什么难的？我刚开始也这么想，直到被现实教育了。高并发场景下，挑战主要来自这几个方面：
| 挑战维度 | 具体问题 | 典型表现 |
|---|---|---|
| 计算密集 | 人脸特征提取需要GPU推理，单张图耗时10-50ms | CPU跑不动，GPU显存不够，请求排队 |
| 数据量大 | 底库规模从万级到亿级，比对耗时随规模线性增长 | 单次比对从1ms变成100ms，接口超时 |
| 状态复杂 | 活体检测、质量评估、人脸追踪需要维护会话状态 | 分布式环境下session同步困难 |
| 资源昂贵 | GPU服务器成本高，不能随意扩容 | QPS上不去，老板嫌贵 |
我曾经遇到过一个客户，底库有2000万人脸特征，要求单次比对在100ms内返回。当时我们试了各种方案，从暴力比对到KD树，从PQ量化到图索引，最后才找到平衡点。说白了，高并发人脸识别拼的不是算法有多牛，而是工程优化有多狠。
1.3 整体架构分层概览
好，咱们进入正题。这套架构我把它分成四层，每一层解决不同的问题。先看这张图：
这四层各司其职，我一个个说。
1.3.1 接入层
接入层是系统的门面。所有外部请求先到这里。它的核心职责就三个：挡、分、转。
- 挡：用限流和熔断挡住恶意流量和突发峰值。我习惯用令牌桶+滑动窗口双保险。
- 分：根据请求类型、用户等级、算法版本做路由分发。比如VIP用户走专属通道。
- 转：把HTTP协议转成内部RPC协议，做参数校验和格式统一。
避坑指南：我曾经在接入层只做了简单的IP限流，结果被攻击者用分布式代理打穿了。后来加了设备指纹和行为分析，才把误杀率降下来。
1.3.2 服务层
服务层是大脑。它不直接处理图片，而是负责编排整个业务流程。举个例子，一次人脸识别请求，服务层要依次做：
- 检查缓存中是否有该用户的结果
- 调用质量评估服务判断图片是否可用
- 调用算法层提取特征
- 在底库中执行1:N比对
- 返回Top-K结果并记录日志
这里有个关键点：服务层必须支持异步化。对于非实时场景（比如批量入库），我会把请求丢进消息队列，让下游慢慢消费。这样能有效削峰填谷。
1.3.3 算法层
算法层是核心，也是最难优化的部分。它包含人脸检测、特征提取、特征比对、活体检测等模块。每个模块都可能成为瓶颈。
我个人的经验是：算法层一定要做模型热更新和版本管理。为什么？因为算法迭代很快，你不能每次升级都重启服务。我在项目中用了一套模型管理平台，支持灰度发布和A/B测试，效果还不错。
注意：算法层的GPU资源非常宝贵。一定要做好显存管理和推理批处理。我曾经见过一个团队，每来一张图就加载一次模型，结果GPU利用率不到5%。
1.3.4 存储层
存储层负责所有数据的持久化。这里的数据类型很杂：
| 数据类型 | 存储方案 | 关键指标 |
|---|---|---|
| 人脸特征向量 | 向量数据库（Milvus/FAISS） | 召回率 > 99%，延迟 < 10ms |
| 用户基础信息 | MySQL + Redis | 读写QPS > 10万 |
| 原始图片 | 对象存储（S3/MinIO） | 上传带宽 > 1Gbps |
| 操作日志 | Elasticsearch | 写入TPS > 5万 |
| 异步任务 | Kafka/RocketMQ | 消息堆积 > 1亿 |
这里要特别说一下特征向量库。传统的关系数据库根本存不了高维向量，必须用专门的向量检索引擎。我踩过最大的坑就是直接用MySQL存特征，结果500万条数据后，单次比对耗时超过3秒——完全不可用。
1.4 架构设计的核心原则
最后，我想分享几条我在实践中总结出来的原则。这些原则会贯穿整个课程：
- 无状态优先：能无状态就无状态，实在不行才引入会话。这样扩容才方便。
- 异步化改造：同步调用是万恶之源。能用消息队列就别用RPC直连。
- 分层隔离：每一层只关心自己的事。算法层不需要知道业务逻辑，服务层不需要管存储细节。
- 可观测性：没有监控的架构就是盲人摸象。从第一天起就要埋点。
一句话总结：高并发人脸识别API的架构，本质上是在算力、成本、延迟之间找平衡。没有银弹，只有持续优化。
好，第一章就到这里。内容不多，但都是基础中的基础。后面的章节我们会深入每一层的具体实现，包括限流算法、模型部署、向量检索优化等等。准备好了吗？咱们继续。