# 后端架构演进：从单机到云原生
::: tip 🎯 核心问题
**代码写好了,怎么让全世界的人都能访问?** 这就像问:你是想开一家路边小摊,还是经营一家跨国连锁餐厅?后端架构的选择,决定了你的"餐厅"能服务多少顾客。
:::
---
## 1. 为什么要了解架构演进?
想象一下,你正在规划一次长途旅行。你可以选择骑自行车、开私家车、坐高铁,或者乘飞机。每种方式都有其适用的场景:自行车适合短距离且想锻炼身体的情况,飞机则适合跨越大陆的长途旅行。
**后端架构的选择也是如此。**
从互联网诞生到现在,后端架构经历了多次重大变革。每一次变革都不是为了"追新潮",而是为了解决当时面临的特定问题:
| 年代 | 核心问题 | 架构演进 |
| ----- | ------------------------ | ------------------- |
| 1990s | 如何把网站跑起来 | 物理服务器 |
| 2000s | 代码越来越乱怎么维护 | 单体架构 + MVC |
| 2010s | 系统太大怎么扩展和协作 | 微服务 + 容器化 |
| 2020s | 如何降低运维成本和复杂性 | Serverless + 云原生 |
::: tip 📊 从表格中你能看到什么?
让我们逐行解读这张表:
**1990s → 2000s**:从"能跑就行"到"需要维护"。网站从静态页面变成动态应用,代码量激增,需要更好的组织方式。
**2000s → 2010s**:从"单机"到"分布式"。用户量爆炸式增长,单台服务器扛不住了,需要拆分系统,水平扩展。
**2010s → 2020s**:从"自己运维"到"云服务"。容器和微服务虽然强大,但运维成本太高,Serverless 让开发者只关注业务逻辑。
**核心启示**:架构演进不是技术选型的游戏,而是**解决实际问题**的过程。每个阶段都有其适用的场景,没有"最好的架构",只有"最适合的架构"。
:::
**了解架构演进的意义在于:**
1. **避免重复造轮子**:很多"新"概念其实早在几十年前就有雏形,了解历史能让你站在巨人的肩膀上
2. **做出合理的技术选型**:没有最好的架构,只有最适合当前阶段的架构
3. **理解技术背后的权衡**:每一次架构演进都是在**开发效率**、**系统性能**、**运维复杂度**之间做取舍
4. **预判技术趋势**:历史总是押韵的,理解过去的演进规律有助于把握未来方向
---
## 2. 物理服务器时代 (1990s)
### 2.1 什么是物理服务器?
在互联网刚起步时,后端就是一台放在机房里的**物理服务器**(一台真实的电脑)。
::: tip 💡 通俗解释
**物理服务器**就像你家里的台式机,但它:
- 7×24小时不关机
- 放在专门的数据中心(有空调、UPS电源、消防系统)
- 有更快的网络带宽(企业级光纤)
- 有固定的公网IP地址(全世界都能访问)
这就好比你家 vs 餐厅:你家只是偶尔做饭,餐厅则是专业厨房,全天候营业,设备更专业。
:::
### 2.2 核心特点
- **单机部署**:所有应用运行在一台物理机上
- **手动运维**:需要人工上架、布线、安装系统
- **垂直扩展**:性能不够时只能买更强的机器
::: details 🔧 垂直扩展 vs 水平扩展
**垂直扩展**(Scale Up):升级单台服务器的配置(更多CPU、更大内存、更快硬盘)。
**水平扩展**(Scale Out):增加更多服务器,让它们一起工作。
**比喻**:
- 垂直扩展:把小餐厅改成大餐厅,装修更豪华,但只有一个厨师
- 水平扩展:开连锁店,每个店规模不大,但有100家分店
**优缺点**:
- 垂直扩展简单,但有上限(顶级服务器很贵,且有限制)
- 水平扩展理论上无限,但需要解决数据一致性问题
:::
### 2.3 痛点
- **慢**:每次改代码都要手动上传,然后重启服务器
- **贵**:扩容只能买更大的机器(垂直扩展)
- **难扩展**:一台机器顶住所有请求,CPU满载时就只能排队
### 2.4 物理服务器时代的优缺点
| 维度 | 评价 |
| ------------ | ------------------------------------------------------------ |
| **优点** | 完全掌控硬件,性能可预测;没有虚拟化开销;数据物理隔离,安全性高 |
| **缺点** | 采购周期长(数周);前期投入大(CapEx);资源利用率低;扩容困难 |
| **适用场景** | 金融核心系统、政府涉密系统、对数据主权有严格要求的场景 |
::: tip 💡 CapEx vs OpEx
**CapEx**(Capital Expenditure):资本性支出,一次性投入大量资金购买硬件。
**OpEx**(Operating Expenditure):运营性支出,按使用量付费(如云服务器)。
**比喻**:
- CapEx:买房,一次性付几百万,之后每月只需交物业费
- OpEx:租房,每月交房租,不用一次性掏大钱
**云时代**的启示:Serverless 和云服务让更多公司从 CapEx 转向 OpEx,降低创业门槛。
:::
---
## 3. 单体架构时代 (2000s)
### 3.1 什么是单体架构?
随着框架的出现(Rails / Django / Spring),大家把所有功能都塞进一个应用里。
::: tip 💡 通俗解释
**单体架构**(Monolith)就像一个超级商场:
- 服装区、食品区、电器区都在同一栋楼里
- 所有员工在一个管理系统里工作
- 如果整栋楼停电,所有区域都停止营业
对比微服务就像商业街:每家店独立运营,一家店关门不影响其他店。
:::
### 3.2 核心特点
- **单一代码库**:所有功能模块在同一个项目中
- **共享数据库**:所有模块共用同一个数据库
- **统一部署**:整个应用作为一个整体打包部署
### 3.3 优点
- **开发简单**:一个项目搞定所有功能
- **部署方便**:把一个大包扔到服务器上就行
- **调试容易**:本地启动就能调试所有功能
### 3.4 痛点:雪崩效应
想象一下,如果"切菜"的师傅不小心切到了手(代码出了Bug),整个后厨都要停下来处理伤口,导致所有客人都吃不上饭。
这就是单体架构最大的风险:**隔离性差**。
::: details 🚨 真实的雪崩案例
某电商公司双十一大促:
- 订单服务因为某个商品的价格计算错误,抛出异常
- 异常没有被正确捕获,导致线程池耗尽
- 所有后续请求(包括商品浏览、搜索、用户登录)都被阻塞
- 整个网站彻底瘫痪,持续1小时
**如果用微服务**:
- 订单服务挂了,但商品浏览、搜索、用户登录仍然可用
- 用户至少可以继续浏览商品,损失降到最低
:::
### 3.5 单体架构的优缺点与适用场景
| 维度 | 评价 |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **优点** | 开发简单,无需考虑分布式复杂性;调试方便,本地启动即可调试全功能;部署简单,一个包即可运行;事务管理容易,单机数据库即可保证ACID |
| **缺点** | 代码耦合度高,随着业务增长代码膨胀;技术栈单一,难以局部升级;扩展困难,只能整体扩容;故障隔离差,一个模块故障影响全局;团队协作效率低,多人改同一套代码 |
| **适用场景** | 初创公司MVP验证、小型团队(<10人)、业务相对简单、对交付速度要求高于扩展性的场景 |
| **不适用场景** | 大型团队并行开发、需要频繁发布不同模块、某些模块需要独立扩容的场景 |
::: tip 🎯 初学者建议
如果你正在学习后端开发,**强烈建议从单体架构开始**:
1. **先学会走路**:理解HTTP、数据库、基本的MVC架构
2. **再考虑跑步**:当项目真的遇到扩展性问题,再考虑微服务
3. **避免过度设计**:很多公司的"微服务"其实是"分布式单体",更难维护
**学习路径**:
- 阶段1:用 Spring Boot / Django / Rails 写一个完整的单体应用
- 阶段2:遇到性能瓶颈时,尝试拆分出1-2个服务
- 阶段3:当团队规模>50人,系统真的复杂了,再全面微服务化
:::
### 3.6 单体架构的技术栈
| 语言/框架 | 特点 | 代表企业 |
| -------------------------- | ---------------------------- | --------------------- |
| **Java + Spring** | 企业级开发首选,生态完善 | 阿里巴巴、京东 |
| **PHP + Laravel/ThinkPHP** | 快速开发,适合中小型项目 | 早期 Facebook、微博 |
| **Python + Django/Flask** | 开发效率高,适合快速原型 | Instagram、Pinterest |
| **Ruby on Rails** | 约定优于配置,初创公司最爱 | GitHub、Twitter(早期) |
| **Node.js + Express** | 前后端统一语言,I/O密集型场景 | Netflix、Uber |
---
## 4. 容器化与微服务 (2010s)
### 4.1 为什么需要微服务?
单体架构的痛点在2010年代集中爆发:
- **代码太庞大**:一个项目几百万行代码,新人入职要花一个月才能看懂
- **部署太慢**:构建一次要30分钟,发布一次要小心翼翼
- **协作太难**:100个开发者改同一个项目,代码冲突每天发生
- **扩展太贵**:只需要扩展"聊天服务",却要复制整个应用
**微服务的核心思想**:把大应用拆成多个小服务,每个服务:
- 独立开发、独立部署
- 有自己的数据库
- 通过API通信
::: tip 💡 Docker是什么?
**Docker**就像是"集装箱":
- 每个集装箱里有独立的货物(代码 + 依赖库 + 运行环境)
- 无论运到哪里(哪台服务器),打开集装箱就能直接开工
- 不用担心"我这台机器没有Python 3.9"、"那个机器缺少某个库"
**比喻**:
- 没有 Docker:每次搬家,要把家具、电器、衣服一件件搬上卡车,到了新家再一件件摆好
- 有 Docker:所有东西打包进集装箱,卡车直接运走,到了新家放下就能用
**核心价值**:"一次构建,到处运行"。
:::
### 4.2 技术栈时间线
### 4.3 微服务架构
为了解决单体的问题,我们把大厨房拆成了很多个小厨房(服务):
- 专门负责用户的服务
- 专门负责订单的服务
- 专门负责支付的服务
### 4.4 Kubernetes 编排
当集装箱数量到达成百上千,就需要一个"港口调度系统":
- **Kubernetes (K8s)**:负责把容器安排到合适的机器上(调度、扩缩容、滚动更新)
- **Service Mesh**:负责服务之间的交通规则(熔断、限流、重试、可观测)
::: tip 💡 什么是"编排"?
**编排**(Orchestration)是指自动管理大量容器的系统。
**比喻**:
- 没有 K8s:你手动管理100个容器,哪个挂了要手动重启,哪个流量大了要手动加机器
- 有 K8s:你告诉它"我要这个服务一直有10个实例运行",它会自动完成:
- 哪台服务器资源充足,就把容器调度到那里
- 容器挂了,自动重启
- 流量大了,自动扩容到20个实例
- 更新代码时,滚动更新(先停1个旧实例,启动1个新实例,逐个替换)
**关键点**:微服务不是"拆开就好",真正的难点在于**治理和运维**。
:::
### 4.5 微服务与容器化的优缺点
| 维度 | 评价 |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **优点** | 服务独立部署,技术栈可异构;故障隔离,单个服务崩溃不影响全局;按需扩展,热点服务单独扩容;团队协作友好,不同团队负责不同服务;代码库更小,易于理解和维护 |
| **缺点** | 分布式复杂性高(网络延迟、分布式事务、服务发现);运维成本高,需要专业的DevOps团队;调试困难,问题可能需要跨多个服务追踪;数据一致性难以保证;部署和监控基础设施要求复杂 |
| **适用场景** | 大型团队(>50人)、业务复杂需要分模块独立演进、某些模块需要独立扩容、需要多语言技术栈、对可用性要求高的系统 |
| **不适用场景** | 小型团队、业务简单、流量小且稳定、没有专业运维团队的情况 |
::: details ⚠️ 微服务的陷阱
**陷阱1:分布式单体**
拆了10个微服务,但它们之间紧密耦合:
- 服务A调用服务B,服务B调用服务C,服务C又调用服务A
- 改一个功能,要同时改5个服务
- 部署时,必须按顺序依次部署,否则系统报错
**这比单体更糟糕**:你拥有了单体的复杂性,又没有享受到微服务的独立部署好处。
**陷阱2:过度拆分**
把只有100行代码的功能也拆成一个独立服务:
- 10个服务,每个只有100行代码
- 服务间通信的开销(网络序列化/反序列化)比实际业务逻辑还重
- 运维成本爆炸:要部署、监控、日志收集10个服务
**正确做法**:从功能内聚的角度拆分,一个微服务应该是一个完整的业务能力(如"订单服务",而不是"订单创建服务"、"订单查询服务")。
:::
### 4.6 微服务技术栈
| 类别 | 技术/工具 | 作用 |
| ------------ | ---------------------------------- | -------------------- |
| **容器化** | Docker, containerd | 应用打包与隔离 |
| **编排调度** | Kubernetes, Docker Swarm | 容器管理与自动扩缩容 |
| **服务发现** | Consul, etcd, ZooKeeper | 服务注册与发现 |
| **API网关** | Kong, Zuul, Envoy | 统一入口、路由、限流 |
| **配置中心** | Apollo, Nacos, Spring Cloud Config | 集中配置管理 |
| **监控告警** | Prometheus, Grafana, ELK | 指标监控与日志分析 |
| **链路追踪** | Jaeger, Zipkin, SkyWalking | 分布式请求追踪 |
| **服务网格** | Istio, Linkerd | 流量治理与安全 |
---
## 5. Serverless 与云原生时代 (2020s+)
### 5.1 为什么需要 Serverless?
微服务虽然好,但维护几十个小厨房还是很累。你需要担心:
- 厨房够不够大?(服务器扩容)
- 停电了怎么办?(高可用)
- 容器太多怎么管?(运维成本)
::: tip 💡 Serverless 不是真的"没有服务器"
**Serverless**的意思是"你不需要管理服务器",而不是真的没有服务器。
**比喻**:
- **物理服务器时代**:你买地、盖房、装修、雇厨师、买食材...全部自己来
- **云服务器时代**:你租一个已经装修好的餐厅,但自己雇厨师、管理运营
- **Serverless时代**:你只需要设计菜单,云端有共享厨房,有专业厨师,你下单他们做,按次付费
**核心变化**:
- 以前:买服务器 → 配环境 → 部署代码 → 监控 → 扩容 → 维护
- 现在:写代码 → 上传 → 按使用量付费
**就像外卖**:你不需要厨房,只需要设计菜单,有人帮你做。
:::
### 5.2 什么是 Serverless?
**Serverless = FaaS + BaaS**
**FaaS**(Function as a Service,函数即服务):
- 你只写函数(如"用户注册时发送欢迎邮件")
- 云厂商负责运行这个函数,自动扩缩容
- 典型代表:AWS Lambda、阿里云函数计算
**BaaS**(Backend as a Service,后端即服务):
- 登录 → Auth0 / Supabase Auth
- 支付 → Stripe
- 数据库 → Supabase / Firebase / DynamoDB
- 消息 → Kafka / SQS
::: tip 🎯 Serverless 适用场景
**最佳场景**:
1. **潮汐流量**:外卖软件,中午流量大,半夜没人。Serverless会自动在中午分配1000台机器,半夜缩减到0台
2. **事件驱动**:"用户上传图片后,自动压缩图片"
3. **快速验证**:小团队、MVP、黑客松项目
**不适合场景**:
1. **长时间运行的任务**:视频转码(可能跑1小时,函数最大执行时间通常只有15分钟)
2. **需要低延迟的应用**:高频交易(冷启动延迟可能几十毫秒到几秒)
3. **需要精细控制底层**:操作系统内核调优、GPU直接访问
:::
### 5.3 Serverless 与云原生的优缺点
| 维度 | 评价 |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **优点** | 零运维成本,开发者只需关注业务代码;自动扩缩容,完美应对流量峰值;按需付费,无流量时成本接近零;快速上线,几分钟即可部署全球;高可用内置,云服务自动处理故障转移 |
| **缺点** | 冷启动延迟(几百毫秒到数秒);运行时长限制(通常5-15分钟);调试困难,本地难以完全模拟云环境;供应商锁定风险;不适合长时间运行或计算密集型任务;成本在高频持续流量下可能反超传统方案 |
| **适用场景** | 事件驱动处理(图片处理、消息通知);潮汐流量应用(活动页、促销);快速原型验证和MVP;低频API或后台任务;无专职运维团队的小团队 |
| **不适用场景** | 需要持续低延迟的应用;长时间计算任务;对冷启动敏感的场景(高频交易);需要精细控制底层基础设施的场景 |
::: details 💰 成本对比:何时Serverless更贵?
**场景1:低频访问**
- 传统服务器:每月$20(不管有没有人访问)
- Serverless:100万次请求 × $0.0002/次 = $20(仅在有流量时付费)
- **结论**:低频场景,Serverless更省钱
**场景2:高频持续访问**
- 传统服务器:每月$20
- Serverless:1亿次请求 × $0.0002/次 = $20,000
- **结论**:高频持续场景,传统服务器更省钱
**场景3:潮汐流量**
- 传统服务器:为了应对峰值,需要$100/月的服务器(平时资源利用率只有10%)
- Serverless:峰值时$20,平时几乎$0
- **结论**:潮汐流量场景,Serverless节省成本
**启示**:不要盲目上Serverless,要根据实际流量特征做成本测算。
:::
### 5.4 Serverless 技术栈与平台
| 类别 | 技术/平台 | 特点 |
| ------------ | ------------------------ | ---------------------------- |
| **FaaS平台** | AWS Lambda | 最早的FaaS服务,生态最成熟 |
| | Azure Functions | 微软云集成度高,.NET友好 |
| | Google Cloud Functions | 与GCP服务深度集成 |
| | 阿里云函数计算 | 国内生态完善,冷启动优化好 |
| | 腾讯云云函数 | 与微信生态整合 |
| | Vercel/Netlify Functions | 前端开发者友好,边缘部署 |
| **BaaS服务** | Firebase | Google的移动端后端方案 |
| | Supabase | PostgreSQL的Firebase开源替代 |
| | AWS Amplify | AWS的移动和Web应用开发平台 |
| **部署工具** | Serverless Framework | 多云部署,社区活跃 |
| | Terraform | 基础设施即代码 |
| | Pulumi | 用编程语言定义基础设施 |
---
## 6. 各架构阶段对比与选型指南
### 6.1 架构演进全景对比
| 维度 | 物理服务器 | 单体架构 | 微服务+容器 | Serverless |
| ---------------- | ---------------------- | ------------------ | ------------------------ | ------------------ |
| **团队规模** | 1-5人 | 5-50人 | 50-500人 | 1-20人 |
| **部署复杂度** | 极高 | 低 | 极高 | 极低 |
| **运维成本** | 高 | 中 | 很高 | 低 |
| **扩展性** | 差 | 垂直扩展有限 | 水平扩展优秀 | 自动扩展 |
| **技术栈灵活性** | 无 | 单一 | 多样化 | 受限 |
| **冷启动** | 无 | 无 | 容器启动时间 | 有延迟 |
| **适用场景** | 遗留系统、特殊合规要求 | 初创公司、业务简单 | 大型互联网公司、复杂业务 | 快速验证、事件驱动 |
### 6.2 技术选型决策树
```
开始选型
│
├─ 团队有专业运维人员?
│ ├─ 是 → 考虑微服务或物理机
│ └─ 否 → 继续判断
│
├─ 需要快速上线验证想法?
│ ├─ 是 → Serverless 或单体
│ └─ 否 → 继续判断
│
├─ 团队规模 > 50人?
│ ├─ 是 → 考虑微服务
│ └─ 否 → 继续判断
│
├─ 流量有明显峰谷特征?
│ ├─ 是 → Serverless
│ └─ 否 → 单体架构(推荐初创)
│
└─ 特殊要求(合规、遗留系统)?
└─ 是 → 物理服务器
```
::: tip 🎯 初学者选型建议
**如果你是个开发者或小团队:**
1. **阶段0 (学习)**:本地跑单体应用,理解HTTP、数据库、基本架构
2. **阶段1 (MVP)**:部署单体应用到云服务器(如阿里云ECS、AWS EC2)
3. **阶段2 (增长)**:当团队>10人、业务变复杂,考虑拆分出1-2个微服务
4. **阶段3 (成熟)**:当团队>50人、流量百万级,全面微服务化
**关键原则**:不要一开始就上微服务,那是"过早优化"。让架构随业务成长而演进。
:::
### 6.3 不同场景下的推荐架构
#### 场景一:独立开发者/兼职项目
- **推荐架构**:Serverless (Vercel/Netlify) 或 单体应用
- **理由**:几乎零运维成本,按需付费,快速上线
- **示例技术栈**:Next.js + Vercel + Supabase
#### 场景二:初创公司MVP验证
- **推荐架构**:单体架构 + 云服务器
- **理由**:开发速度快,团队可以专注于业务逻辑而非基础设施
- **示例技术栈**:Spring Boot / Django / Rails + RDS + ECS
#### 场景三:成长型公司(10-50人团队)
- **推荐架构**:模块化单体 或 轻量级微服务
- **理由**:开始面临代码耦合问题,但还不需要完整的微服务复杂度
- **示例技术栈**:Spring Cloud / Go Micro + Kubernetes
#### 场景四:大型互联网公司
- **推荐架构**:微服务 + 服务网格 + 中台架构
- **理由**:团队规模大,业务复杂,需要独立的发布节奏和技术栈
- **示例技术栈**:自研RPC框架 + Istio + 自建PaaS平台
#### 场景五:事件驱动/潮汐流量应用
- **推荐架构**:Serverless + 事件总线
- **理由**:流量波动大,需要极致的成本优化和自动扩缩容
- **示例技术栈**:AWS Lambda + API Gateway + EventBridge
---
## 7. 总结与学习路线
### 7.1 核心要点
后端架构的演进,本质上是在做**加法**和**减法**:
| 时代 | 架构 | 开发者要做的事 | 运维要做的事 |
| :------------- | :----- | :--------------- | :----------------- |
| **物理时代** | 单机 | 写脚本、手动部署 | 维护机房与硬件 |
| **单体时代** | 一整块 | 写所有业务逻辑 | 维护几台大服务器 |
| **微服务时代** | 拆分 | 关注单一业务 | 维护K8s集群(很累!) |
| **Serverless** | 函数 | 只写核心函数 | 喝茶(云厂商全包了) |
**关键洞察**:
- 架构演进不是"新技术取代旧技术",而是**适用场景的变化**
- 没有银弹,每个架构都有其适用的边界
- 选择架构要考虑:团队规模、业务复杂度、流量特征、运维能力
### 7.2 学习路线建议
根据你的职业阶段,推荐以下学习路径:
#### 阶段一:打好基础(0-1年)
**目标**:理解后端核心概念,能独立开发单体应用
- 掌握一门后端语言(Java/Python/Go任选其一)
- 学习HTTP协议和RESTful API设计
- 掌握关系型数据库(MySQL/PostgreSQL)
- 了解缓存基础(Redis)
- 学习Git和基础Linux命令
- **实践项目**:用单体架构完成一个CRUD应用(如博客系统、待办事项)
#### 阶段二:扩展能力(1-3年)
**目标**:理解分布式系统,能参与微服务开发
- 深入学习微服务架构和拆分策略
- 掌握Docker和Kubernetes基础
- 学习消息队列(Kafka/RabbitMQ)
- 了解分布式事务和一致性
- 掌握监控和日志(Prometheus/ELK)
- **实践项目**:将单体应用拆分为3-5个微服务,使用Docker部署
#### 阶段三:专业深化(3-5年)
**目标**:能设计大型系统,具备技术选型能力
- 深入理解云原生架构(Service Mesh、Serverless)
- 掌握容量规划和性能调优
- 了解多活架构和灾备设计
- 学习DDD(领域驱动设计)
- 培养技术判断力和架构思维
- **实践项目**:设计一个支持百万级用户的系统架构,包含高可用、弹性伸缩等方案
### 7.3 持续学习资源推荐
**书籍**:
- 《设计数据密集型应用》(DDIA)- 分布式系统必读
- 《云原生模式》
- 《微服务设计》
- 《领域驱动设计》
**在线资源**:
- AWS/Azure/阿里云官方架构文档
- CNCF(云原生计算基金会)项目文档
- 各大公司技术博客(Netflix Tech Blog、阿里技术公众号等)
---
## 8. 名词速查表(Glossary)
| 名词 | 全称 | 解释 |
| :---------------- | :-------------------------------- | :------------------------------------------------ |
| **Backend** | - | 服务器端系统,负责处理业务逻辑、数据存储和对外接口 |
| **CGI** | Common Gateway Interface | 早期动态网页技术,通过脚本处理请求并返回结果 |
| **Monolith** | - | 单体架构,把所有业务逻辑打包在同一个应用中 |
| **Microservices** | - | 微服务架构,把业务拆分成多个独立服务 |
| **Container** | - | 容器化技术,把应用和依赖打包成可移植单元 |
| **K8s** | Kubernetes | 容器编排平台,用于调度、扩缩容和治理容器 |
| **Service Mesh** | - | 服务网格,负责微服务间通信治理、观测与安全 |
| **Serverless** | - | 无服务计算,开发者只写函数,平台自动运行与扩缩容 |
| **BaaS** | Backend as a Service | 即插即用的后端云服务(认证、数据库、支付等) |
| **CI/CD** | Continuous Integration / Delivery | 持续集成与持续交付,自动化测试与部署流程 |
| **Observability** | - | 可观测性,利用日志/指标/追踪理解系统运行状态 |