发布架构全景：从一行代码到用户手机，系统由哪些部分组成

画出一个可上线产品的完整技术架构：客户端、静态分发、网关、后端、数据库、对象存储、第三方能力与可观测体系，讲清每个组件的职责、数据如何流动，并用朋友好学做真实映射

建立一个完整上线系统的组件全景，不再把「后端」当成一个黑盒
理解客户端、CDN、网关、API、数据库、对象存储、第三方服务各自职责
能跟踪一个典型请求在架构各组件间的流动路径
理解无状态后端、静态与动态分离的设计原则

上线一个产品，远不止「写个 App」

初学者眼里的产品是「App + 服务器」两个方块，真实可上线系统是一组分工明确的组件协作。看不懂这张全景图，部署时就会把所有东西塞进一个进程、出问题不知道是哪一层。这一课先把完整架构画清楚，后面所有中外上架与运维的内容都挂在这张图上。

一张完整的发布架构图

示例

用户设备
 App / H5 浏览器
   │  HTTPS
   ▼
[ CDN / 静态分发 ]  缓存图片、JS/CSS、安装包、静态页面（就近加速）
   │
   ▼
[ 接入网关 Nginx ]  TLS终止、反向代理、负载均衡、限流、日志(443)
   │            ┌──────────────┴───────────────┐
   ▼            ▼                               ▼
[ API 后端 ]  [ 静态资源/对象存储 ]        [ Web 静态站点 ]
 无状态、可扩容    图片/音频/安装包              课程页(SSG)
   │
   ├─ 数据库（持久化用户/进度/订单，主从或备份）
   ├─ 缓存（可选，热点数据/会话/限流计数）
   └─ 第三方能力（服务器到服务器调用）
        大模型 / TTS / 支付 / 短信 / 推送 / 邮件
   │
   ▼
[ 可观测体系 ] 日志收集、指标监控、告警、崩溃上报（贯穿所有组件）
   │
   ▼
[ 分发渠道 ] 应用商店 / 自有下载（让用户拿到安装包）

每个组件分别负责什么

配对题架构组件与它的职责配对

一条关键原则是静态与动态分离：能提前生成的（课程网页、图片、前端 JS、安装包）交给 CDN/对象存储/静态目录，请求时现算的（AI 对话、进度同步、订单）才走 API 后端。这样后端只承担真正动态的流量，既快又稳、还省成本。

跟踪一个典型请求

以朋友好学「用户在 App 里向 AI 提问」为例，走一遍这张图：App 发起 HTTPS 请求；若域名挂了 CDN，静态部分就近返回，动态 /api 回源；请求到 Nginx:443，TLS 终止、按路径分流；转发给无状态的 Node 后端；后端鉴权、查/写数据库、做限流计数；后端在服务器侧调用大模型（密钥不出服务器），流式结果经 Nginx 透传回 App；全过程写日志、上报指标，异常触发告警。理解了这条路径，你就知道「慢」可能慢在 CDN、网关、后端、数据库还是第三方，而不是笼统地说「服务器卡」。

选学

为什么后端要做成「无状态」（选学）

如果把用户登录态、临时数据存在某个后端进程的内存里，一旦你扩容成两台、或进程重启，用户状态就丢了、请求落到不同机器结果不一致。无状态指后端进程本身不存权威状态：会话/数据放数据库或客户端令牌，任何一台后端实例都能处理任何请求。这样才能用负载均衡随意加机器、崩溃自动拉起、发版滚动替换。这和 Stage15-m7 的十二要素完全呼应。

💡独立开发者的「最小架构」长什么样

不必一上来搭微服务集群。朋友好学就是最小可行架构的范例：一台云服务器上 Nginx 当网关、Node 后端、数据库/文件在本机、静态站点本地目录、第三方能力走 API，再加日志轮转备份和基础监控。组件可以少，但「分层清晰、静态动态分离、后端无状态、密钥在服务端」这几条原则从第一天就守住，未来扩容只是把组件逐个拆出去，而不必推倒重来。

选择题

下列架构设计中，最合理、最利于稳定与扩容的是？

本节小结

完整上线架构=客户端→CDN/静态分发→Nginx网关(TLS/反代/负载/限流)→无状态API后端+静态/对象存储→数据库/缓存→服务器侧第三方(大模型/TTS/支付/推送)→日志监控告警→应用商店分发。核心原则：静态动态分离(能预生成的走CDN、现算的走API)、后端无状态(权威状态进数据库、任意实例可处理任意请求以便扩容/重启/滚动发版)、数据库不暴露公网、密钥只在服务端。一个请求可沿链路逐层定位瓶颈。独立开发者可用单机最小架构但必须守住分层原则，未来按需把组件拆出。

资深工程师加餐

底层原理 · 大厂视角 · 工程经验，点卡片展开

versionName 是给用户看的版本名，versionCode（构建号）只能单调递增、绝不回退，构建时间要和服务端升级清单一致。线上包、归档包、OTA 包必须用同一签名，并把文件大小和哈希（如 MD5/SHA）写进服务端元数据；客户端下载完成先校验哈希再安装，能从根上杜绝「下到一半的坏包被安装」。每次发版把这几项列成清单逐项核对。