微服务架构

**现代微服务架构 = API 网关 + 微服务 + Docker + Kubernetes

• 异步消息 + 自动扩展
• 可观测性 + 自动化交付**

一、为什么要微服务？

1️⃣ 传统单体架构的问题

早期系统通常是一个大项目：

Web + 业务逻辑 + 数据库

问题：

• 项目一大，改一行全系统重启
• 多人协作冲突严重
• 扩容只能整体扩
• 技术栈被锁死

📌 结论：单体在规模上不行

---

二、什么是微服务架构？

👉 把一个大系统拆成一组小而独立的服务

每个服务：

• 功能单一
• 独立部署
• 独立扩容
• 独立数据库（理想状态）

一个经典例子（电商）

用户服务
订单服务
支付服务
库存服务
推荐服务

每个服务：

• 自己的代码
• 自己的 Docker 镜像
• 跑在 k8s 上

---

三、现代微服务的整体架构图（心智模型）

        ┌──────────┐
        │  Client  │
        └────┬─────┘
             │
      ┌──────▼──────┐
      │ API Gateway │
      └──────┬──────┘
             │
 ┌───────────┼───────────┐
 │           │           │
▼           ▼           ▼
User       Order       Payment
Service    Service     Service
 │           │           │
 ▼           ▼           ▼
 DB          DB          DB

      ↓ 异步事件 ↓
          Kafka
      ↓ 数据处理 ↓
       Spark / Flink

---

四、现代微服务的关键组成部分

1️⃣ API Gateway（网关）

👉 所有请求的“统一入口”

作用：

• 路由
• 鉴权
• 限流
• 日志
• 版本控制

常见：

• Kong
• Nginx
• Spring Cloud Gateway
• Istio Gateway

---

2️⃣ 服务间通信

同步调用

• HTTP / REST
• gRPC

特点：

• 简单
• 易理解
• 延迟低

问题：

• 强依赖
• 雪崩风险

---

异步通信（推荐）

• Kafka
• RabbitMQ
• Pulsar

特点：

• 解耦
• 高可用
• 抗流量冲击

📌 现代架构强调：能异步就别同步

---

3️⃣ 数据管理（最容易踩坑）

❌ 错误做法

所有微服务共用一个数据库

✅ 正确思想

一个服务 = 一个数据库

挑战：

• 分布式事务
• 数据一致性

解决方案：

• 事件驱动
• 最终一致性
• Saga 模式

---

4️⃣ 容器化（Docker）

每个服务：

• 一个 Dockerfile
• 一个镜像
• 可复现部署

好处：

• 环境一致
• 快速回滚
• 易扩展

---

5️⃣ 容器编排（Kubernetes）

k8s 在微服务中负责：

• 自动部署
• 服务发现
• 自动扩容（HPA）
• 故障自愈
• 滚动升级

📌 微服务 = Docker + k8s 才算“现代”

---

五、服务治理（现代微服务的灵魂）

1️⃣ 服务发现

• k8s Service
• DNS

2️⃣ 负载均衡

• kube-proxy
• Service Mesh

3️⃣ 容错机制

• 超时
• 重试
• 熔断
• 限流

4️⃣ Service Mesh（服务网格）

👉 把“治理逻辑”从代码中剥离

代表：

• Istio
• Linkerd

Sidecar 模式：

Service A + Envoy
Service B + Envoy

---

六、可观测性（不然你根本不知道哪里炸了）

三大支柱

• Metrics（指标）
• Logs（日志）
• Traces（链路追踪）

常用技术：

• Prometheus + Grafana
• ELK
• Jaeger / Zipkin

📌 现代系统：先做可观测性，再谈稳定性

---

七、CI / CD（持续交付）

典型流程：

代码提交
 → 自动测试
 → 构建 Docker 镜像
 → 推送镜像仓库
 → k8s 滚动更新

工具：

• GitHub Actions
• GitLab CI
• Jenkins
• Argo CD