微服务架构认知

单体架构：一个应用包含所有功能（订单+用户+商品+支付在一个进程里），部署一次全发布，改一行全回归。

微服务架构：把应用拆成多个独立服务（订单服务/用户服务/商品服务…），每个服务独立开发、独立部署、独立伸缩，服务间通过 HTTP/RPC 通信。

① API 网关（Gateway）

所有请求的唯一入口：路由转发、鉴权、限流、灰度。前端只需知道网关地址，不用关心后端有多少服务。

② 服务注册与发现

服务启动时注册自己到注册中心（Nacos/Consul），调用方动态发现地址 —— 服务实例挂了会自动摘除，前端无感知。

③ 配置中心

所有服务的配置集中管理、热更新 —— 前端相关的网关路由规则、灰度比例都在里面配。

④ 链路追踪

每个请求带 traceId 贯穿网关 → BFF → 服务 → DB。前端请求头带 traceId，出问题能一查到底。

⑤ 容器化与编排（Docker + K8s）

服务打包成镜像，K8s 管理副本、自动扩缩容、滚动发布。前端静态资源也走同一套（CDN + 容器）。

1. API 契约 = 前端与后端的"合同"

用 OpenAPI（Swagger）或 TypeScript 类型定义接口：请求参数、响应结构、错误码。契约先行 = 后端先出契约文档，前端按契约开发（甚至 Mock），两边并行，不等联调。

// 契约示例：OpenAPI 片段（后端产出）
"/api/order/:id": {
  "get": {
    "responses": {
      "200": {
        "schema": { "type": "object", "properties": {
          "orderNo": { "type": "string" },
          "amount": { "type": "number" },
          "status": { "type": "string", "enum": ["paid", "unpaid", "cancelled"] }
        }}
      }
    }
  }
}

2. 前端开发流程（微服务时代）

1. 后端出契约（OpenAPI / 类型文件）→ 前端生成 TS 类型 + Mock
2. 前端按 Mock 开发，联调前自动切换真实环境（环境变量控制 baseURL）
3. 后端灰度发布时，前端按网关 header 区分新旧契约（兼容期双跑）

Docker 三件套：镜像 / 容器 / Dockerfile

# 前端静态站点 Dockerfile（nginx 托管）
FROM node:22-alpine AS build
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN pnpm install
COPY . .
RUN pnpm build

FROM nginx:alpine            # 多阶段构建：产物打进 nginx
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80

发布流程（CI/CD 全景）

1. CI：push → 跑 Lint + 单测 + 构建 → 产出镜像 → 推镜像仓库
2. CD：K8s 滚动发布（先起新副本 → 健康检查通过 → 摘旧副本），失败自动回滚
3. 灰度：网关按用户/流量比例放量，前端可配合"版本号 header"做新旧兼容

背景

电商后端从单体拆成 12 个微服务，前端叫苦：① 订单详情页原来一个接口，现在要问 5 个服务要数据；② 后端每周改契约，前端天天被打破；③ 联调环境混乱。

前端应对方案（三步走）

1. 建 BFF 聚合层：订单详情/首页/个人中心三个"重页面"各建聚合接口，前端代码零改动，直接换地址
2. 契约自动化：后端 OpenAPI 文档 → CI 里自动生成 TS 类型 + 校验脚本，后端契约变更前端立刻报警（而不是上线才发现）
3. 环境与链路：请求头带 traceId（网关分配），前端 error 监控上报时附带，问题一键追踪到具体服务；联调统一走 dev 网关

结果与复盘

• 前端联调返工率 -70%；接口变更引发的线上事故 0
• 复盘：最大的坑是"后端说改了但前端不知道" —— 契约自动生成 + 变更报警是微服务协作的基石，比任何技术都重要

要求

1. 假设公司后端要拆微服务，你作为前端负责人输出一份《前端协作方案》，包含：契约管理、BFF 聚合范围、环境与 Mock 方案、链路追踪接入、灰度兼容策略
2. 画出架构图（文字/表格即可）：前端 → 网关 → BFF → 服务的链路与职责标注
3. 写一份 Dockerfile 把现有静态站点容器化（含多阶段构建）

通关标准

• 文档能被后端/运维看懂并落地执行（不是空话）
• 能口头讲清：网关/注册发现/配置中心/链路追踪各解决什么问题，契约先行为什么关键