系统架构方案生成

下面给出一份围绕“千人课堂直播+点播、多租户、强一致订单/课程、混合云合规存储、可替换CDN、PostgreSQL/Kafka优先”的完整架构建议，包含架构模式优缺点分析、关键技术选型、混合云拓扑、SLO与HA、可观察性与交付，以及最小可用的文生代码与IaC/CI样例，尽量在预算、团队规模与6个月交付周期内落地。

一、架构模式对比与决策

1. 微服务

• 优点
  • 独立伸缩与演进，支撑多租户差异化定制
  • 故障隔离，契合混合云与多活
  • 与事件驱动结合，可实现读写分离与降耦
• 缺点
  • 运维复杂度高：服务发现、配置、认证、发布、灰度
  • 跨服务事务与一致性复杂，需要Outbox/Saga
  • 小团队初期过度切分会拖慢交付
• 结论：采用“收敛微服务”策略。MVP阶段以6~8个有界上下文服务为主，后续按负载与边界再拆分。

2. 事件驱动

• 优点
  • 降耦、异步化，利于弹性扩展与回放补偿（直播互动、日志审计、巡课分析）
  • 易扩展实时指标、课堂质量分析、推荐等
• 缺点
  • 调试困难，幂等性、顺序保障、死信处理需治理
  • 需要模式治理（Schema Registry）与可观测性
• 结论：核心交易强一致（Postgres内事务+Outbox），围绕课程、课堂、支付构建事件流（Kafka），直播互动与白板等用低延时信令/数据通道实现最终一致。

3. 分布式系统

• 优点
  • 必要的以满足10万并发与多地合规存储
  • 数据/媒体平面分离，边缘就近接入降时延
• 缺点
  • 网络分区/一致性权衡（CAP）、跨域运维成本
• 结论：采用“控制面/数据面分离 + 边缘SFU + 公有云VOD转码/对象存储 + 省内数据域隔离”的分层分域分区策略。

最终架构决策

• 模式：收敛微服务 + 事件驱动 + 数据/媒体平面分离
• 原则：核心交易强一致（ACID），互动与分析最终一致；MVP先小而稳，后续渐进式拆分与自动化治理。

二、总体逻辑架构与服务划分（有界上下文）

• 身份与多租户域：IAM/RBAC、组织/校区、租户策略（Keycloak + OpenFGA）
• 用户域：用户档案、师生关系、家校沟通
• 课程域：课程、排课、课表、教室分配、回放绑定
• 课堂互动域：信令（举手、连麦）、白板、答题、聊天、巡课与课堂质检
• 直播域（媒体面）：WebRTC SFU、录制/推流、转码、低延迟播放
• VOD/作业域：录制存储、转码与回放、作业与批改
• 订单/支付域：订单、支付单、对账、票据与发票
• 通知域：短信/邮件/站内信/推送
• 审计与合规模块：全链路审计日志、内容审核（音频/弹幕/白板快照）
• 观测与平台：日志/指标/追踪、灰度/蓝绿、配置中心、网关/限流 建议MVP微服务清单（8个内）：iam, tenant-org, user, course-schedule, classroom-interaction, live-rtc, vod-recording, order-payment（后续再拆：billing/invoice、notification、audit-analytics）

三、关键技术选型（开源优先，团队擅长TS/Go）

• 运行与集群
  • Kubernetes：云侧用托管K8s（EKS/ACK/TKE任一），边缘用K3s；Helm/ArgoCD GitOps
  • API Gateway：APISIX 或 Kong（JWT、限流、灰度）；Ingress NGINX 或 Envoy Gateway
  • 服务网格（可选，M3后引入）：Linkerd（轻量、mTLS、golden signals）；先期用Gateway+Argo Rollouts满足灰度
• 身份与权限
  • Keycloak（OIDC/SAML、社交登录可选）
  • OpenFGA（细粒度关系型权限，支持课堂资源继承、跨校区角色）
• 数据
  • PostgreSQL 15/16（主从+Patroni/etcd，synchronous_commit=on用于同城双活低RPO）
  • 分区与RLS：pg_partman（时间/租户分区）、RLS实现多租户隔离；大租户可schema-per-tenant
  • 对象存储：MinIO（省内/边缘）+ S3（公有云），基于Bucket策略满足数据属地
  • 分析：ClickHouse（教室质量、互动指标、巡课报表），Kafka -> CH
• 消息/事件
  • Kafka（KRaft）或 Redpanda（Kafka API，易运维），Schema Registry（Apicurio/Confluent开源）
  • CDC：Debezium（Postgres -> Kafka）
  • 短链路低时延信令/房间状态：Redis Cluster Pub/Sub 或 NATS JetStream（更低时延）；Kafka用于可持久的业务事件
• 直播/互动
  • WebRTC SFU：LiveKit OSS 或 Janus/mediasoup（团队TS/Go均可）。建议LiveKit：多区域、录制/egress、Ingress(WHEP/WHIP)、转码生态较全
  • 播放策略：互动用户WebRTC（<500ms）；大规模观看优先LL-HLS/Low-Latency DASH（1~2s），若必须<800ms看播，需级联SFU并付出成本（计算带宽+部署复杂度），MVP以混合策略达成大多数场景
  • 白板：tldraw + Yjs（CRDT），数据通道优先WebRTC DataChannel，退化到WebSocket
  • 录制/转码：LiveKit Egress + FFmpeg/GStreamer Jobs（K8s Jobs/Argo Workflows），对象存储MinIO/S3
• 安全与合规
  • 传输：TLS1.2+，内网mTLS（后续接入Linkerd）
  • 数据：磁盘加密（LUKS），对象存储SSE-KMS（HashiCorp Vault KMS 或云KMS），Postgres敏感列pgcrypto
  • 内容审核：ASR（Whisper小样本+关键词）、图像OCR与涉黄暴恐检测（开源/第三方可插拔），抽样+命中即全量审计
• 可观察性
  • OpenTelemetry SDK全栈；Prometheus + Grafana；Loki(日志) + Tempo(Trace)
  • 告警：Alertmanager + Grafana OnCall，SLO看板（直播时延、卡顿率、掉线率）
• 交付
  • GitHub Actions（主）+ 自建Runner（边缘/内网）；Argo Rollouts（蓝绿/金丝雀）；Trivy镜像扫描；SLSA/供应链签名（cosign）

四、多租户与一致性策略

• 多租户隔离
  • 应用层：每次请求携带tenant_id（从OIDC token提取），API网关注入；服务层强制SQL使用RLS；缓存与Kafka topic加租户前缀/Header
  • 数据层：小租户共享schema+RLS，大租户独立schema或独立库；对象存储按租户/省份分桶
• 一致性
  • 课程、订单：Postgres本地事务 + Outbox表；后台Outbox Relay写入Kafka，消费者构建读模型（Redis/CH）
  • 直播互动：WebRTC/WS最终一致；白板/聊天CRDT合并；重要操作（禁言、点名）走幂等命令+事件回执
  • Saga：支付成功->开课授权->通知->开票；失败补偿与对账异步完成

五、直播/互动性能与扩展设计

• 时延目标：互动用户端到端≤500ms；大规模观看LL-HLS 1~2s（若必须≤800ms，需全WebRTC watch-only + 级联SFU，部署/成本显著上升，需专项评估）
• 规模预估（参考，不同编解码器/码率有差异）
  • 教师推一路1080p（simulcast），N位助教/学生上麦受控（一般<30）
  • 单SFU节点可承载约15002500订阅（CPU 16C/32G/10GbE）；10万并发需4070台SFU分布在多Region/边缘；HPA基于CPU/发送队列/丢包率
  • 级联：边缘SFU只做就近分发，上行集中到区域SFU/云SFU
• 质量保障
  • 自适应码率、SVC/Simulcast、FEC/NACK
  • 巡课Bot加入房间采集QoE（RTT、丢包、卡顿），上报Kafka -> ClickHouse，触发预警与自动迁移边缘

六、混合云拓扑与同城双活

• 拓扑
  • 边缘（校区/省内）：K3s + LiveKit Edge SFU + MinIO（本地合规存储）+ Redis；轻量Web入口
  • 公有云：托管K8s集群（A/B两可用区）+ 控制面服务 + 中央Kafka + ClickHouse + 对象存储；SFU核心集群用于跨省回源/转码
  • 跨区域路由：全局Anycast/GeoDNS，API Gateway按租户/省份策略路由；媒体信令优先就近边缘
• 数据主从
  • Postgres按省份部署主库（省内合规），跨省仅同步脱敏汇总；同城双活采用Patroni + 同步复制（主-同步备）保证RPO≈0（或≤5min改为异步复制）
• RPO/RTO
  • RPO≤5min：Postgres异步复制+WAL归档（5分钟目标）；Kafka RF=3, minISR=2；对象存储异步跨区复制
  • RTO≤10min：K8s多副本+自动故障转移；GitOps一键拉起；数据库故障预案（虚拟IP/代理层切换）

七、安全与审计

• 统一身份：Keycloak（Realm=平台，Client按租户隔离），短期支持SAML/AD对接
• 授权：OpenFGA建模（user, role, classroom, org, tenant），策略变更可热更新
• 审计：API与管理操作落Kafka审计Topic，落地WORM存储（对象存储带保留策略）
• 合规录制：LiveKit Egress录制->MinIO省内桶，设置不可改写保留期

八、可观察性与运维

• 指标：直播延迟P95、卡顿率、失败入会率、订单成功率、数据库写入延时、Kafka滞后
• 追踪：HTTP/gRPC/Kafka header注入traceparent；SFU信令也注入Trace ID
• 日志：结构化JSON，关键信息脱敏；日志样本上报策略避免成本爆炸
• 自动化：HPA + KEDA（按Kafka消费滞后/队列深度），Argo Rollouts（灰度）+ 自动回滚

九、交付路线（6个月，M1出MVP）

• M1 MVP（重点“跑通课”）
  • 登录/多租户/基础RBAC（Keycloak）
  • 课程与排课、开课、直播间创建
  • 基础互动：聊天、举手、上麦（1对多WebRTC）、录制与回放
  • 订单/支付沙盒（创建订单->支付回调->开课授权）
  • GitHub Actions + Helm + ArgoCD，基础观测（Prom/OTel/Logs）
  • 代码生成工具v0：OpenAPI/Proto->服务骨架、客户端SDK、Helm模板
• M2-M3
  • 白板（Yjs+tldraw）、答题、巡课Bot、课堂质量看板
  • 省内边缘节点部署流程与合规存储打通；灰度/蓝绿
  • 内容审核与审计落地
• M4-M6
  • 大班级扩容与级联SFU；作业与批改；发票与对账
  • 优化SLA、ABR策略、自动巡检与弹性
  • 自助化多租户开通、计费与费用核算

十、文生代码/模板样例（可作为“bootstrap”仓库输出）

1. 领域模型与契约

• course.proto（gRPC + Buf）

  syntax = "proto3";
  package edu.course.v1;
  option go_package = "github.com/acme/edu/coursepb;coursepb";
  
  message Course {
    string id = 1;
    string tenant_id = 2;
    string title = 3;
    string teacher_id = 4;
    int64  start_time = 5;
    int64  end_time = 6;
    string status = 7; // DRAFT|PUBLISHED|ONGOING|ENDED
  }
  
  message CreateCourseRequest { Course course = 1; }
  message CreateCourseResponse { Course course = 1; }
  message GetCourseRequest { string id = 1; string tenant_id = 2; }
  
  service CourseService {
    rpc CreateCourse(CreateCourseRequest) returns (CreateCourseResponse);
    rpc GetCourse(GetCourseRequest) returns (Course);
  }
  

• user OpenAPI（YAML片段）

  openapi: 3.0.3
  info: { title: user-service, version: 1.0.0 }
  paths:
    /api/v1/users:
      post:
        security: [{ bearerAuth: [] }]
        requestBody:
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/UserCreate'
        responses:
          '201': { $ref: '#/components/responses/User' }
  components:
    securitySchemes:
      bearerAuth: { type: http, scheme: bearer, bearerFormat: JWT }
    schemas:
      UserCreate:
        type: object
        required: [email, name, tenantId]
        properties:
          email: { type: string, format: email }
          name: { type: string }
          tenantId: { type: string }
    responses:
      User:
        description: ok
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/UserCreate'
  

• 支付 Proto（对账与事件）

  syntax = "proto3";
  package edu.payment.v1;
  message Order { string id=1; string tenant_id=2; int64 amount=3; string currency=4; string status=5; }
  message CreateOrderReq { string tenant_id=1; int64 amount=2; string currency=3; string subject=4; }
  message CreateOrderResp { Order order=1; string pay_qr=2; }
  service PaymentService {
    rpc CreateOrder(CreateOrderReq) returns (CreateOrderResp);
  }
  

• 事件Schema（JSON Schema注册到Schema Registry）

  {
    "$id": "edu.course.v1.CourseCreated",
    "type": "object",
    "properties": {
      "eventId": { "type": "string" },
      "tenantId": { "type": "string" },
      "courseId": { "type": "string" },
      "title": { "type": "string" },
      "startTime": { "type": "integer" }
    },
    "required": ["eventId", "tenantId", "courseId", "startTime"]
  }
  

2. 服务骨架（Go，gRPC + HTTP网关，OTel，Outbox）

• cmd/course/main.go

  package main
  import (... relevant packages ...)
  func main() {
    // load config, init logger
    // init OTel tracer/provider
    // connect Postgres (pgxpool), enable RLS session var: set app.tenant_id
    // init Kafka producer (sarama/redpanda)
    // start gRPC server + grpc-gateway HTTP
  }
  

• internal/course/service.go

  type CourseService struct{ db *pgxpool.Pool; producer sarama.SyncProducer }
  func (s *CourseService) CreateCourse(ctx context.Context, req *pb.CreateCourseRequest) (*pb.CreateCourseResponse, error) {
    // BEGIN TX
    // INSERT course
    // INSERT outbox(event_json) WITH tenant_id
    // COMMIT
    // Async relay: outbox-relayer scans and produce to Kafka
    return &pb.CreateCourseResponse{Course: saved}, nil
  }
  

• outbox-relayer（Go）

  // periodically select for update skip locked from outbox where status='NEW'
  // publish to Kafka with headers: tenantId, traceparent
  // mark SENT
  

3. Node/TypeScript 支付服务骨架（REST + Kafka）

• src/index.ts

  import fastify from 'fastify';
  const app = fastify();
  app.post('/api/v1/orders', async (req, reply) => {
    // validate JWT, extract tenantId
    // create order in Postgres (knex/prisma)
    // write outbox row
    reply.code(201).send({ orderId, pay_qr });
  });
  app.listen({ port: 8080 });
  

4. 测试桩（Go）

func TestCreateCourse(t *testing.T) {
  // spin up test Postgres (testcontainers), apply migrations
  // call CreateCourse, assert response, query DB, check outbox
}

5. Terraform 片段（以Helm方式部署Kafka/MinIO，便于替换）

• terraform/main.tf

  provider "helm" { kubernetes { config_path = "~/.kube/config" } }
  
  module "kafka" {
    source = "helm_release"
    name   = "kafka"
    repository = "https://charts.bitnami.com/bitnami"
    chart  = "kafka"
    namespace = "platform"
    set { name="replicaCount" value="3" }
    set { name="listeners.client.protocol" value="PLAINTEXT" } // MVP内网，生产改TLS/SASL
  }
  
  module "minio" {
    source = "helm_release"
    name   = "minio"
    repository = "https://charts.bitnami.com/bitnami"
    chart  = "minio"
    namespace = "storage"
    set { name="mode" value="distributed" }
    set { name="replicas" value="4" }
  }
  

6. Helm Chart（服务通用模板 values.yaml）

image: ghcr.io/acme/course-service:{{ .Chart.AppVersion }}
replicaCount: 2
env:
  - name: OTEL_EXPORTER_OTLP_ENDPOINT
    value: http://otel-collector:4317
  - name: DB_DSN
    valueFrom: secretKeyRef: { name: course-db, key: dsn }
resources:
  limits: { cpu: "1", memory: "512Mi" }
  requests: { cpu: "200m", memory: "256Mi" }

7. GitHub Actions（CI/CD + 镜像 + Helm 推送，ArgoCD拉取）

name: ci
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
      - run: go test ./...
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with: { registry: ghcr.io, username: ${{ github.actor }}, password: ${{ secrets.GITHUB_TOKEN }} }
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ghcr.io/acme/course-service:${{ github.sha }}
      - name: Generate Helm values
        run: |
          sed -e "s#APP_VERSION#${{ github.sha }}#g" charts/course/values.yaml.tpl > charts/course/values.yaml
      - name: Push Helm chart
        run: helm package charts/course && helm push course-*.tgz oci://ghcr.io/acme/charts

8. 前端 SDK 与组件样例（TS/React）

• OpenAPI 客户端生成（openapi-generator 或 orval）

  // yarn orval --config orval.config.ts
  export const createCourse = (body: CourseCreate) => client.post('/api/v1/courses', body)
  

• 直播接入（LiveKit Web）

  import { connect } from 'livekit-client';
  const room = await connect(lkUrl, token, { adaptiveStream: true, dynacast: true });
  // publish camera for teacher, subscribe for students
  

• 白板（tldraw + Yjs）

  const ydoc = new Y.Doc();
  const provider = new WebrtcProvider(`whiteboard-${roomId}`, ydoc); // 或自建WS provider
  

九个关键治理要点（落地经验）

• 严控服务数量：MVP不超过8个服务，先把课堂跑稳
• 架构双平面：信令/媒体与业务事件彻底分开
• 强一致边界清晰：只有课程与订单在ACID里，其它走事件最终一致
• Outbox/幂等落到代码模板中，避免“事后治理”
• Schema Registry与事件版本管理要求在CI强校验
• 统一追踪上下文：HTTP/gRPC/Kafka/WS全链路traceparent
• 省内合规存储策略由配置与策略服务下发，避免代码分叉
• 发布策略默认金丝雀，带自动回滚
• 直播体验SLO面向用户呈现（P95延迟/卡顿率），业务团队共识与可视化

关于“端到端≤800ms且10万大并发”的现实建议

• 对于“上麦/互动”用户，WebRTC可稳定达成≤500ms（边缘优先路由）
• 对于纯观看用户，若必须≤800ms，需采用全链路WebRTC级联分发（成本/复杂度显著增加）。建议产品分层：互动≤500ms；普遍观看使用LL-HLS 1~2秒，极端大班级对延迟敏感场次再启用WebRTC Watch-only集群。这样能在预算与团队规模内达成体验与成本平衡。

本方案在预算（首年≤80万）、团队（8人）与时间（6个月、1个月MVP）约束下可落地，且技术选型开源优先、可插拔（可替换CDN/SFU/云厂商），满足混合云、多租户合规与运维可控。后续我可以根据你们现有资源（云厂商/边缘机房/省份分布）进一步细化容量规划与成本估算，并把“文生代码工具”做成可一键生成新子域服务的脚手架。