多租户 SaaSCASE 01
一套企业项目 SaaS 的所有层怎样连在一起？
用户正在做什么
企业员工从浏览器登录、查看项目、上传合同并接收通知。
业务会出什么问题
只看单个页面无法理解身份、API、数据、文件、消息、部署和监控之间的依赖。
技术怎样介入
请求从 Edge 进入前端和 API，业务服务操作数据库、缓存、存储与队列，Platform 负责运行和观测。
产品与设计怎样落地
用完整链路检查每个页面状态是否有真实系统支撑。
M5 · Chapter 16
把所有知识重新连成一张图
用完整案例训练“看到页面，向下还原系统”的能力。
先看哪些场景
多租户 SaaS、项目与协作、文件与 Excel、AI 生成、稳定性与运维等场景
它是什么
系统全景能力是把用户任务、界面状态、API、业务、数据、运行和质量串成同一条链。
为什么需要
孤立术语只有在真实流程里连接起来，才能支持设计判断、开发沟通和 AI 生成验收。
位于哪一层
位于课程整合阶段，把前 15 章放回完整系统。
和谁连接
前端、API、后端、数据库、存储、缓存、队列、微服务、容器、CI/CD、监控和 AI。
项目里怎么出现
创建项目、上传文件、生成 AI 报告和企业多租户系统会贯穿全部层。
Learning Outcomes
学完这一章，你应该能
- 能画出典型 SaaS 总架构
- 能追踪创建项目与文件上传链路
- 能理解 AI 长任务如何进入传统系统
- 能从问题现象推断可能故障层
16.01
一个 SaaS 产品的完整架构
用户通过多个客户端访问统一业务，系统由应用、数据和运行层共同支撑。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
Web 和 App 通过 CDN、负载均衡或 API Gateway 访问后端。后端可以是模块化单体，也可以包含多个服务。
核心数据进入 PostgreSQL，热点数据进入 Redis，文件进入对象存储，异步任务进入队列，搜索和 AI 使用专用能力。容器与云负责运行，CI/CD 负责发布，可观测性负责线上反馈。
Clients → Edge / Gateway → Application → Data & Services → Platform & Observability
System View
Web / App / 小程序
CDN / Gateway / Load Balancer
Backend Modules / Services
PostgreSQL / Redis / Storage / Search / Queue / AI
Docker / Kubernetes / Cloud
CI/CD / Security / Observability
Designer Lens
架构图要围绕用户任务和数据流，不要只堆技术 Logo。
SaaSEdgePlatform
16.02
案例一：创建项目
一个表单提交可以串起前端、权限、业务、数据库和事件。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
项目与协作CASE 01
创建项目的主事务、后续事件和审计如何协作？
用户正在做什么
用户创建项目后，系统还要生成默认任务、通知成员并记录操作。
业务会出什么问题
把所有附加动作塞进一次请求会变慢，任何通知失败都可能让核心创建失败。
技术怎样介入
创建项目作为 Primary Transaction 先落库，随后发布 Domain Event，通知和审计异步处理。
产品与设计怎样落地
核心成功先进入项目页，通知状态可稍后完成，历史记录可追踪。
前端收集名称、负责人和时间，做基础校验并发送 POST /projects。后端认证用户、判断创建权限、校验配额与日期。
Project Service 在事务中创建项目和默认成员，写入审计日志，发布 ProjectCreated 事件。通知和分析异步处理，前端收到 201 后进入详情。
Form → POST API → Auth → Service → Transaction → Event → Response
System View
填写表单
→
前端校验
→
POST /projects
→
权限与业务校验
→
事务写库
→
发布事件
→
返回详情
Designer Lens
界面需要覆盖字段错误、权限、配额不足、重复提交、创建成功和后续异步初始化。
真实项目
如果通知失败，项目仍可创建成功；通知服务通过队列重试。主任务与附加任务的成功标准需要分开。
Primary TransactionDomain EventAudit
16.03
案例二：上传并解析 Excel
文件传输、对象存储、异步任务和结果反馈共同完成导入。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
文件与 ExcelCASE 01
从上传 Excel 到看到导入结果，完整链路是什么？
用户正在做什么
运营上传十万行客户数据并等待校验、写入和错误报告。
业务会出什么问题
上传、解析和写库混在一起会导致超时，也无法展示真实 Progress。
技术怎样介入
文件入存储后创建 Import Job，Worker 分批校验和 Batch Write，任务持续记录成功、失败和进度。
产品与设计怎样落地
设计上传阶段、任务阶段、部分成功、错误报告、重新执行和历史记录。
前端选择文件并获取直传凭证，把文件上传到对象存储。后端保存文件记录并创建 Import Job。
Worker 从队列读取任务，下载文件、解析行、校验数据并批量写库。错误行生成结果文件，前端通过轮询或 SSE 更新进度。
Upload → Storage → Job → Queue → Worker → Validation → Batch Write → Result
System View
选择与校验
上传文件
创建任务
排队
解析与验证
批量导入
生成结果
完成通知
Designer Lens
导入功能需要展示上传进度、解析进度、成功数量、失败原因、可下载错误文件和重新处理。
Import JobBatch WriteProgress
16.04
案例三：AI 生成报告
长任务会同时使用业务数据、RAG、模型、工具、队列和存储。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
AI 生成CASE 01
从点击“生成报告”到可下载文件，完整链路是什么？
用户正在做什么
用户选择数据范围和模板，AI 生成可编辑报告。
业务会出什么问题
模型调用时间长、格式可能不稳定、部分数据可能缺失。
技术怎样介入
Orchestration 编排取数、检索、模型和导出；模型返回 Structured Report；关键结论进入 Human Review。
产品与设计怎样落地
设计步骤进度、引用、字段校验、人工修改、版本和导出。
用户选择项目和模板，后端检查权限并创建 Report Job。Worker 读取项目数据，检索知识，调用模型生成结构化章节，必要时调用图表或文件工具。
结果经过校验后保存数据库和对象存储。前端持续显示阶段，用户预览、编辑和确认发布。模型调用、检索来源和工具执行都进入日志与评测。
UI → AI Job → Business Data + RAG + LLM + Tools → Validation → Storage → Review
System View
提交任务
→
创建 AI Job
→
检索与组装上下文
→
模型/工具执行
→
结构校验
→
保存报告
→
用户审核
Designer Lens
把“AI 正在生成”拆成读取数据、检索资料、生成章节、制作图表、排版、校验和保存。
OrchestrationStructured ReportHuman Review
16.05
案例四：企业多租户系统
一套软件服务多个组织时，身份、数据隔离和配置会更复杂。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
多租户 SaaSCASE 01
同一套系统怎样保证 A 公司看不到 B 公司的数据？
用户正在做什么
多个企业共用一套 SaaS，每个企业都有成员、项目和合同。
业务会出什么问题
查询遗漏 Tenant 条件会造成严重数据泄露。
技术怎样介入
Multi-tenancy 为每条数据绑定 Tenant，并在认证、查询、缓存和存储层执行 Data Isolation。
产品与设计怎样落地
组织切换、跨组织成员、管理员视角和导出范围要清晰展示。
Tenant 代表企业或团队。用户可能属于多个 Tenant，每个 Tenant 有成员、角色、订阅、数据和主题配置。请求必须携带当前租户上下文。
后端在每次查询中限制数据范围，文件路径、缓存 Key、搜索索引和 AI 知识库也要隔离。计费、配额、审计和管理员权限围绕租户组织。
User ↔ Membership ↔ Tenant → Data / Config / Billing / AI Knowledge
System View
Tenant：组织边界
Membership：用户与组织关系
Role：组织内权限
Plan：订阅与配额
Data Isolation：数据隔离
Audit：组织操作记录
Designer Lens
租户切换、角色差异和数据隔离必须在导航、权限和反馈中清楚表达。
Multi-tenancyTenantData Isolation
16.06
从界面现象反推故障层
不同问题现象可以帮助定位可能的系统层。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
稳定性与运维CASE 01
页面一直转圈，问题可能在哪一层？
用户正在做什么
用户打开项目详情后骨架屏持续不消失。
业务会出什么问题
现象可能来自前端异常、网络失败、API 超时、数据库慢或权限判断卡住。
技术怎样介入
先稳定 Reproduction，再区分 Symptom 与 Root Cause，沿请求链逐层检查。
产品与设计怎样落地
错误状态要暴露足够线索：网络、权限、处理中、无数据和服务器错误不能都显示同一句话。
页面完全打不开可能涉及 DNS、CDN、证书、入口或前端构建；某个接口失败可能涉及权限、后端、数据库或第三方；数据旧可能涉及缓存、复制或索引同步。
一次判断无法直接确认根因，需要结合 Network、日志、指标和追踪。全景认知的价值在于快速缩小范围并提出正确问题。
User Symptom → Candidate Layers → Evidence → Root Cause
System View
现象
- 白屏
- 接口 500
- 数据没更新
- 任务一直排队
- 只有部分用户失败
可能层
- 前端/资源/入口
- 后端/数据库/依赖
- 缓存/复制/索引
- 队列/Worker
- 权限/灰度/地域
Designer Lens
与开发沟通时描述操作、期望、实际、时间、账号、环境和是否可复现。
Root CauseSymptomReproduction
16.07
如何画一张有用的系统图？
一张图只表达一个视角，并清楚标注边界和数据流。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单与支付CASE 01
同一个支付系统为什么需要三种不同的图？
用户正在做什么
团队既要给业务解释边界，也要梳理支付步骤，还要说明部署位置。
业务会出什么问题
一张图塞入所有细节会失去阅读目标。
技术怎样介入
Context Diagram 展示系统与外部对象，Sequence Diagram 展示支付时序，Deployment Diagram 展示服务运行位置。
产品与设计怎样落地
画图前先确定读者要做什么决策，再选择信息层级。
上下文图展示用户与外部系统，容器图展示应用和数据系统，组件图展示某个应用内部模块，时序图展示一次流程的先后顺序。
图中要保持抽象层级一致。用动词标注箭头，用边框表达边界，用注释说明同步、异步和数据归属。
Choose View → Define Scope → Place Boundaries → Draw Flows → Add Legend
System View
Context：系统与外部角色
Container：应用与数据系统
Component：应用内部模块
Sequence：一次流程
Deployment：运行节点
Data Flow：数据移动与存储
Designer Lens
面向设计与产品沟通时优先展示用户任务和数据；面向开发时再补协议、技术和部署信息。
Context DiagramSequence DiagramDeployment Diagram
Chapter Recap
本章小结
- 01完整架构从客户端一路连接到数据、平台和可观测性。
- 02创建项目、文件导入和 AI 报告展示了同步与异步链路。
- 03多租户把身份、数据、配置和计费组织成隔离空间。
- 04系统图需要选择视角、边界和一致抽象层级。
Practice
把认知变成一张图
选择你正在做的一个产品，分别画 Context、Container 和一个关键流程的 Sequence 三张图。
Quick Check
随堂检查
QUESTION 01
Excel 导入为什么常创建后台 Job？
大文件解析与导入适合异步任务。
QUESTION 02
数据刚更新却搜索不到，最可能先检查什么？
搜索索引通常从数据库异步同步，可能有延迟。