API 开发与系统集成技术方案
先约定业务对象、输入输出和异常处理,再选择架构。下方以内容分发和监测为示例,说明字段映射、队列、回调与交接方式。
以下架构、代码、账号与监测记录为设计示意,其中数字与响应为示意数据,不代表真实客户交付或性能实测。实际范围与性能须按项目实现和验收。
API 项目先确认四项设计输入
| 设计项 | 需要约定的内容 | 验收依据 |
|---|---|---|
| 接口与字段 | 业务对象、输入输出、分页、空值、版本与同步方向 | 脱敏样本、字段映射和接口说明 |
| 账号与权限 | 账号归属、授权范围、客户隔离、撤销与失效处理 | 最小权限用例与越权检查 |
| 状态与恢复 | 超时、重复请求、回调乱序、人工处理和结果对账 | 异常回放与业务结果记录 |
| 交接与维护 | 源码、部署环境、日志、告警、备份和第三方依赖 | 交付清单与部署演练 |
模块选择见API 开发服务;把设计输入写入联调与验收流程后,再估算开发投入。以下内容系统架构按具体业务裁剪。
系统分层
这套结构用于说明方案分层,实际模块按业务与监测范围裁剪。
数据模型
核心只有四张表:account、content、task、result。
内容与平台解耦,平台差异放在 task.payload 里,新增平台不改主表。
| 表 | 关键字段 | 说明 |
|---|---|---|
account | platform, nickname, credential_ref, expires_at | 凭证只存引用,加密后放密钥库 |
content | title, body, media[], versions[] | 平台无关的内容主体 |
task | content_id, account_id, platform, status, publish_at | 一次发布任务 |
result | task_id, platform_post_id, url, error_code | 平台返回结果 |
发布队列与频控
队列按 account_id + platform 分区:同一账号串行,避免自己把自己限流;不同账号并发,保证吞吐。
频控用令牌桶,按平台配置 QPS,429 时读 Retry-After 退避。
for task in queue.consume(partition = account_id):
token = limiter.acquire(account_id, platform)
result = adapter.publish(task, token)
if result.retryable:
queue.retry(task, delay = backoff(task.attempt))
elif result.success:
store.save(task, result.platform_post_id)
events.emit("content.published", task, result)
else:
store.fail(task, result.error_code)
events.emit("content.failed", task, result)
幂等与重试
- 幂等键:由业务生成(如
content_id + account_id的哈希),24 小时内重复请求只建一个任务。 - 可重试:网络超时、平台 5xx、429。指数退避 1s / 2s / 4s,最多 3 次。
- 不可重试:参数错误、权限不足、内容违规。直接落库为 failed,附带平台原始返回。
- 状态机:
queued → publishing → reviewing → success / failed,晚到的 reviewing 不能覆盖 success。
接口长什么样
POST /v1/content/publish
Authorization: Bearer <service-token>
Idempotency-Key: 7b1f9c2e-4a11-4c2e-9f3c
{
"platform": "zhihu",
"account_id": "acc_8f21",
"content_type": "article",
"title": "AI 搜索时代,内容分发怎么做",
"body": "...",
"body_format": "markdown",
"publish_at": "2026-10-24T09:00:00+08:00"
}
完整参数与响应见 接口设计样例。
收录与引用监测
这是最容易「看起来很美」的部分。我们的原则是:数据源分开标注,缺失不补零。
- 收录:优先走百度 / 必应的公开查询,拿不到的用站内搜索抽检。
- AI 引用:固定问题集,每天 2–3 个时段向公开问答入口提问,记录品牌 / 链接 / 观点是否出现及位置,多次取并集。
{
"question_id": "q_1024",
"runs": [
{ "engine": "chatgpt", "at": "2026-10-21T09:00:00Z", "cited": true, "position": 2 },
{ "engine": "chatgpt", "at": "2026-10-21T15:00:00Z", "cited": false, "position": null },
{ "engine": "doubao", "at": "2026-10-21T09:10:00Z", "cited": true, "position": 1 }
],
"sample_size": 3,
"cited_runs": 2
}
安全与合规
- 账号凭证 AES-256 加密存储,密钥与数据分离;不提供明文导出接口。
- 全链路操作审计:谁、什么时候、对哪个账号、发了什么。
- 不收集账号密码、不模拟登录、不绕过平台风控。
- 客户数据按租户隔离,权限最小化;数据保留、删除和备份清理方式按项目确认。
部署形态
三种常见形态,按你的合规要求选:
| 形态 | 适用 | 说明 |
|---|---|---|
| 公有云托管 | 小团队、快速上线 | 我们部署,按年收运维费;数据在云端隔离 |
| 私有化(单机 / 集群) | 品牌、金融、政企 | Docker / K8s,数据库与对象存储用你方现有资源 |
| 混合 | 后台在内网、发布需出网 | 后台与数据在内网,发布服务通过代理出网 |
技术常见问题
为什么不用现成的开源发布系统?
能用的开源方案通常只覆盖「调用一个平台的接口」,账号矩阵、频控、重试、审核回调、多客户隔离这些都要自己补。我们从这些模块开始搭,交付的是能直接接业务的系统,不是一个 SDK Demo。
监测采集会不会很脆弱?
会。AI 问答页面结构经常变,所以采集器做了两层:优先走平台接口或稳定的公开接口,拿不到的用浏览器自动化兜底,并且每个数据源独立降级。前端会把「数据缺失」明确标出来,而不是填 0。
系统能承受多大发布量?
吞吐目标需按账号规模、内容类型、平台限流和部署资源确定;队列可按账号分区并串行发布。实际吞吐须经约定负载测试确认,本页不提供未经测试的 QPS 数值。
可以只用你们的接口层,不做后台吗?
可以。交付形态可以是纯 API 服务 + SDK,接到你现有后台里;也可以带一个最小管理界面。