点完按钮之后，
后端忙了些什么？
把服务端想成一家餐厅：前端负责点餐，后端负责认人、接单、找食材、做菜，还要保证送对桌。
读完你应该能回答三件事：一个请求怎么走；一个需求怎么上线；出问题先查哪一层。
① 罗盘后端架构与业务开发流程 ↗② 后端研发链路分享 · 2026-10-27 ↗
基于文档正文与会议逐字稿独立整理。公开页保留概念与学习方法，未收录内部配置值、业务数据和平台截图。标记「通用补充」的内容是教学延伸。
浏览器发出请求，像递出一张点菜单
怎么看：从左往右找“请求在哪一层停了”。图为概念顺序；真实中间件内部次序要查看对应服务，内部适配入口还可能增加跨区 RPC。
HTTP
像顾客对外点餐。浏览器用 URL、请求方法和 JSON 交流。
RPC
像厨房内部叫另一位厨师帮忙。服务按方法名和类型契约互相调用。
PSM
像餐厅的分店编号。它标识服务；域名、URL、方法名和服务标识各有职责。
旧架构和新架构，怎么理解？
旧链路常有一层 HTTP 接入服务，再转给 RPC 业务服务。目标方向是收拢业务逻辑、减少重复适配，保留需要的兼容入口、内部入口和导出执行服务。
材料有待确认之处：会议约 00:09:42 将 Campaign 业务归到 RPC Campaign；当前文档 1.1 又写了 Campaign HTTP 业务下沉到 RPC Seller，实战章节仍围绕 RPC Campaign 展开。新需求先确认业务 owner、现网路由和当前迁移方案，不能只凭服务名字选仓库。架构目标也不代表迁移已经完成。
开餐厅之前，菜谱和门牌也得准备好
拆需求
页面有哪些区域？每块读什么、写什么？哪些区域、账号、异常需要支持？
定契约
先约好请求与返回，再定义 IDL，生成调用代码；确认兼容方式和数据口径。
并行准备配置
路由、菜单/API 权限、区域治理、服务访问权限、超时和业务开关。
实现与自测
入口整理参数，取数层访问依赖，计算层组装结果；补空数据、异常与边界验证。
部署测试环境
按依赖发布生成包和业务服务；核对版本、区域、泳道，用真实入口联调。
灰度、观察、全量
先让小范围流量试用，观察错误、耗时和数据差异；异常按预案停止灰度或回滚。
IDL 就是前后厨共用的点菜单
你熟悉 TypeScript interface：它告诉你字段形状。IDL 还约定跨服务的方法与字段，并用于生成客户端、服务端等代码。手改生成物，下一次生成就可能丢失。
| 需要约定 | 前端熟悉的例子 | 后端还要确认 |
|---|---|---|
| 身份与店铺 | 当前登录用户、当前店铺 | 有效身份从可信上下文恢复，不能任由请求体中的店铺覆盖权限校验 |
| 日期 | 日期选择器的起止值 | 时区、边界是否包含、实时/离线、比较区间 |
| 数值 | 百分比、金额格式化 | 比例还是百分数，元还是分，币种、精度与缺失值 |
| 列表 | 分页表格、排序按钮 | 稳定排序、分页边界、总数口径、空结果语义 |
| 兼容 | 旧页面还在调用 | 保留既有字段编号和语义；按材料要求追加 optional 字段 |
0 表示数值为零，null 可能表示缺失，[] 表示列表为空，错误表示查询没有成功。别把这几种情况都渲染成“暂无数据”。前端传来的指标类型，后端可以直接照用吗？
材料要求后端维护指标类型与区域能力的映射。某个数据源只支持部分区域时，要在对应区域过滤或采用明确产品规则；不能默认前端传了枚举，目标区域就一定有底表和接口。
代码能运行，请求还得能到达
TLB · 门牌与导航
域名 + path 映射到目标服务、方法和集群。
Cerberus · 顾客门禁
用户 → 角色 → 菜单 → API Group → API，决定子账号能调用什么。
AG / DEC-RPC · 通行声明
处理对应 HTTP / RPC 入口的数据治理与跨区调用约束。
Neptune · 服务门禁与计时
服务能否调用另一个服务，以及调用允许等待多久。
TCC · 控制面板
业务规则、区域映射、灰度开关与默认值。
限流 / OS 授权 · 水龙头
数据接口要授权给实际调用服务，也要承担得住查询频次和并发。
依据：文档 §4、§5.2.2；会议 00:18:22–00:24:02、00:54:00–00:57:58。App 接入在会议末尾明确有待补充，不能直接套用 Web 的全部接入配置。
取到数据之后，还有半场工作
独立任务一起做
像 Promise.all。示例：两个独立查询各 200ms、300ms，串行约 500ms，并行约 300ms 加额外开销。
有依赖的按顺序做
先拿商品 ID，再批量取商品信息。每一行再发一次查询，会造成 N+1 请求和流量放大。
失败要有语义
必需数据源失败就返回错误。可选数据源只有在约好降级规则时，才能省略或回退。
时间选择器为什么不能永远选昨天？
材料中的 available_date 为依赖的离线来源求共同边界；实时场景不按这套方式限制。任务成功还要继续确认查询服务、导入与缓存是否就绪。
Redis、MySQL、数仓，各自像什么？
Redis 像手边便签：适合可重建的热数据缓存和短期状态。MySQL 像正式账本：保存任务、配置和业务状态，使用事务、唯一键或条件更新保证约束。数仓与 OS API 像备菜中心和取餐窗口：先加工分析数据，再以接口提供查询；业务服务按现有数据访问层调用。
Dorado 承担加工、同步；它的任务成功不代表页面已经能查到。通用补充：缓存键要包含影响结果的店铺、区域、日期等维度，写入后要考虑失效策略。
依据：文档 §4.7、§5。
“任务创建成功”距离“文件能下载”还有几站
前端需要约定
任务状态如何显示、如何刷新、失败怎样提示、什么时候显示下载入口，以及下载权限和链接是否可用。
后端需要串通
任务分类 Module/SubModule、任务列表和下载 allowlist、分页、字段投影、模板列、多语言与回调。
创建任务超时了，前端再请求一次就行吗？
不能默认如此。任务可能已经创建，只是响应没回来。按业务键回查确认结果，结合幂等机制决定是否重试；不要自动切到旧实现再创建一次。材料明确要求结果不明时停止自动重试。
发布成功，只证明完成了其中一步
| 看到的信号 | 还不能证明 | 接着验证 |
|---|---|---|
| 代码合入 | 运行环境已更新 | 生成物版本、目标服务实际部署版本 |
| 流水线绿色 | 用户流量已到新代码 | 目标区域/泳道、入口路由、真实 Trace |
| 接口返回成功 | 数据与权限正确 | 业务值、子账号、店铺、日期、分页、异常 |
| 新链路运行正常 | 所有存量任务都结束 | 旧导出 callback、旧任务下载和存量兼容 |
灰度像先开几桌
按方法、入口和区域逐步放量；对比错误率、耗时、数据与副作用。开关缺失、非法或关闭时走什么，要提前定义。
回滚像切回旧厨房
准备开关、路由、服务版本与配置的回退方案。写请求超时先回查，不能盲目转旧路径重做；保留兼容 IDL 和未结束任务需要的回调。
GUI、FTF、Aime：这些检查各自看什么？
GUI：从页面交互回归，结合网络日志找到失败请求。FTF：查看接口回放或差分，核对错误码、结构与业务值。Aime：逐条处理代码评审意见，修复或给出有证据的解释。它们与人工验收互相补充。
材料阅读提醒：会议提到小差异可能是噪声，但不能仅凭差异小就全标噪声。需要同环境、身份、时区与数据窗口下复现并归因；文档里部分 GEC 门禁阈值与审批流程本身仍标注待补，执行时确认现行规则。
拿到 LogID，沿着请求找证据
接口打不通 / 路由找不到
先核对目标域名、path、方法、区域与泳道；检查实际路由和服务版本。通用补充：404 可提供线索，但状态码不能单独确定是哪一层返回。
主账号正常，子账号失败
检查菜单、API Group 与接口绑定，再核对有效用户/店铺上下文。别只改前端按钮可见性。
一个区域正常，另一个区域失败
逐项对照目标区域的路由、部署、开关、治理打标、服务 ACL 和 OS API 授权/发布；再看是否请求了该区域不支持的指标。
接口成功，但数字不对
对齐店铺、时间边界、时区、币种、指标口径和数据产出日期；沿 OS 返回值 → ID 关联/排序 → 计算 → 前端格式化逐层对比。
导出一直处理中 / 文件为空
沿任务 → MQ → 执行服务 → callback → 分页 → 文件上传 → 终态回写检查。保留任务标识、LogID、参数、区域与时间，不要只截图转圈。
依据：文档 §8.4；会议 00:48:52–00:50:28。症状到原因的映射为教学归纳。
从“接口写了”走到“这件事交付了”
练习题：新增一个商品分析列表，支持日期筛选、分页、子账号访问与导出。下面是结合材料编排的练习路线，勾选只在当前页面生效。
已检查 0 / 10 项
让 AI 帮忙，哪些事情还要自己判断？
AI 适合梳理现有代码、生成骨架、补测试、整理配置清单、分析 LogID 和评审意见。你需要拍板需求语义、指标口径、数据与区域边界，确认实际版本和平台状态，判断是否满足上线条件。生成出的配置清单要逐项回读；一段流畅解释不能替代真实请求证据。
先记住这三句话
① 请求走通，要靠代码、路由、权限与依赖一起对齐。
② 数据算对，要核对身份、区域、日期、单位和失败语义。
③ 交付完成，要看真实入口、文件与用户结果，并准备好回滚。