从单体到微服务
单体架构的瓶颈
当业务系统发展到一定规模时，单体架构会遇到以下问题：
- 代码库庞大，编译部署耗时
- 任何模块的修改都需要重新部署整个应用
- 无法针对热点模块单独扩容
- 团队协作困难，代码冲突频繁
微服务的核心思想
将单体应用按业务边界拆分为多个独立的小服务，每个服务：
- 独立开发、独立部署、独立运行
- 拥有自己的数据库（数据隔离）
- 通过API（通常是REST或gRPC）与其他服务通信
- 可以使用不同的技术栈
微服务架构的挑战
引入微服务的同时也引入了分布式系统的复杂性：
| 挑战 | 解决方案 |
|---|---|
| 服务发现 | Nacos、Consul、Eureka |
| 负载均衡 | 客户端负载均衡（Ribbon）、服务端负载均衡（Nginx） |
| 配置管理 | Nacos、Apollo、Spring Cloud Config |
| 服务网关 | Kong、Spring Cloud Gateway、NestJS Gateway |
| 分布式事务 | Saga模式、TCC模式、消息队列最终一致性 |
| 链路追踪 | Jaeger、Zipkin、SkyWalking |
| 熔断降级 | Sentinel、Resilience4j |
容器化与Kubernetes
为什么需要容器化
微服务数量增多后，手动管理每个服务的部署、扩缩容、健康检查变得不现实。容器化技术（Docker）解决了"在我机器上能跑"的问题，将应用和运行环境一起打包，确保在任何环境下都能一致运行。
Kubernetes的核心概念
Kubernetes（K8s）是容器编排平台，自动化管理容器的生命周期：
| 概念 | 说明 |
|---|---|
| Pod | 最小调度单元，包含一个或多个容器 |
| Service | 为一组Pod提供稳定的访问入口 |
| Deployment | 管理Pod的副本数量和更新策略 |
| ConfigMap / Secret | 管理配置和敏感信息 |
| Ingress | HTTP路由规则，将外部流量导入集群 |
| HPA | 水平Pod自动扩缩容，根据CPU/内存使用率自动调整 |
K8s在前端项目中的应用
前端项目部署到K8s的典型方式：
- 构建Docker镜像（Nginx + 静态资源）
- 编写Deployment和Service配置
- 配置Ingress路由规则
- 通过HPA根据流量自动扩缩容
微服务 + K8s的完整架构
客户端 → CDN → 负载均衡 → Ingress → API网关
↓
┌─────────┼─────────┐
↓ ↓ ↓
用户服务 订单服务 内容服务
↓ ↓ ↓
用户DB 订单DB 内容DB
text
每个微服务独立部署在K8s集群中，通过Service相互访问，通过HPA自动扩缩容。这种架构可以根据各服务的负载情况独立扩展资源，是云原生应用的标准架构模式。
↑