后端架构核心技术栈详解

Byron07072026-05-24 13:30

下面按"基础设施 → 中间件 → 架构思想"分层介绍，每个技术都会讲清楚 是什么 / 解决什么问题 / 核心原理 / 实战要点。

一、Docker ------ 容器化基石

1.1 是什么

Docker 是一个基于 Linux Namespace + Cgroups 的轻量级虚拟化技术，把应用和它的依赖打包成一个"集装箱"(Container)，做到 "一次构建，到处运行"。

1.2 核心概念

概念 说明
Image (镜像) 只读模板，分层存储 (UnionFS)，类似类
Container (容器) 镜像的运行实例，类似对象
Dockerfile 构建镜像的脚本（FROM/RUN/COPY/CMD）
Registry 镜像仓库（Docker Hub、Harbor）
Volume 数据卷，持久化容器数据
Network 容器网络（bridge、host、overlay）

1.3 关键原理

  • Namespace：进程隔离（PID、Network、Mount、UTS、IPC、User）
  • Cgroups：资源限制（CPU、内存、磁盘 IO）
  • UnionFS（联合文件系统）：镜像分层，节省存储

1.4 常用命令

bash 复制代码 
docker build -t myapp:1.0 .       # 构建镜像
docker run -d -p 8080:8080 myapp  # 后台启动并端口映射
docker ps / docker logs / docker exec -it <id> bash
docker-compose up -d              # 编排多容器

1.5 vs 虚拟机

维度 Docker 虚拟机
启动速度 秒级 分钟级
资源占用 MB 级 GB 级
隔离性 进程级 系统级（更强）
内核共享 共享宿主机内核 独立内核

二、Kubernetes (K8s) ------ 容器编排之王

2.1 是什么

K8s 是 Google 开源的容器编排平台，解决 "成百上千容器如何调度、伸缩、自愈、发布" 的问题。

2.2 核心架构

复制代码 
┌─────────────────── Master 控制平面 ───────────────────┐
│  API Server  ←  外部入口（kubectl/UI 调它）           │
│  Scheduler   ←  决定 Pod 调度到哪个 Node             │
│  Controller  ←  各种控制器（Deployment/ReplicaSet）  │
│  etcd        ←  集群状态存储（KV 数据库）             │
└────────────────────────────────────────────────────┘
              │
┌─────────── Node 工作节点 ───────────┐
│  kubelet  ← 节点代理，管理 Pod      │
│  kube-proxy ← 网络代理，Service 转发 │
│  容器运行时 (containerd/CRI-O)     │
└──────────────────────────────────┘

2.3 核心资源对象

资源 作用
Pod 最小调度单位，1 个或多个共享网络/存储的容器
Deployment 无状态应用部署，管理 Pod 副本数，支持滚动升级
StatefulSet 有状态应用（数据库、Kafka），稳定网络标识
DaemonSet 每个 Node 跑一个（日志收集、监控）
Service 服务发现 + 负载均衡（ClusterIP/NodePort/LoadBalancer）
Ingress 七层路由入口（域名转发、HTTPS）
ConfigMap / Secret 配置注入、敏感信息管理
PV / PVC 持久化存储抽象
HPA 自动水平伸缩（基于 CPU/内存/自定义指标）
Namespace 资源逻辑隔离

2.4 关键特性

  • 自愈：Pod 挂了自动重启、Node 挂了自动迁移
  • 滚动升级：零停机发布，支持回滚
  • 服务发现：DNS + Service，跨节点透明访问
  • 声明式 API：你写"我要 3 个副本"，K8s 负责达成

2.5 实战要点

yaml 复制代码 
# 一个典型 Deployment
apiVersion: apps/v1
kind: Deployment
metadata: { name: user-service }
spec:
  replicas: 3
  selector: { matchLabels: { app: user } }
  template:
    metadata: { labels: { app: user } }
    spec:
      containers:
      - name: app
        image: user-service:1.2
        resources:
          limits: { cpu: 500m, memory: 512Mi }
        readinessProbe:        # 就绪探针
          httpGet: { path: /health, port: 8080 }
        livenessProbe:         # 存活探针
          httpGet: { path: /health, port: 8080 }

三、Nginx + 负载均衡

3.1 Nginx 是什么

高性能 HTTP/反向代理服务器，基于 事件驱动 + 异步非阻塞 (epoll)，单机可支撑十万级并发。

3.2 核心能力

  • 反向代理：客户端 → Nginx → 后端服务（隐藏真实后端）
  • 负载均衡：流量分发到多个后端
  • 静态资源服务：直接返回 HTML/JS/CSS/图片
  • HTTPS 卸载：SSL 在 Nginx 终止，减轻后端压力
  • 限流 / 熔断 / 黑白名单

3.3 负载均衡算法

算法 说明 适用场景
round-robin 轮询(默认) 后端机器性能一致
weight 加权轮询 后端机器性能不一
ip_hash 同一 IP 固定到一台 Session 粘性
least_conn 最少连接数 请求耗时差异大
fair（第三方） 按响应时间分配 动态自适应
url_hash 按 URL 哈希 缓存命中率优化

3.4 典型配置

nginx 复制代码 
upstream user_backend {
    least_conn;                                    # 算法
    server 10.0.0.1:8080 weight=3 max_fails=2;
    server 10.0.0.2:8080 weight=1 backup;          # 备用机
    keepalive 32;                                  # 长连接池
}

server {
    listen 443 ssl http2;
    server_name api.example.com;
    ssl_certificate /etc/nginx/cert.pem;

    location /api/ {
        proxy_pass http://user_backend;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_connect_timeout 3s;

        limit_req zone=api burst=20 nodelay;       # 限流
    }
}

3.5 负载均衡分层

层 协议 代表 特点
二层 MAC LVS DR 模式 性能最高，只改 MAC
四层 TCP/UDP LVS、F5、Nginx stream 不解析应用层
七层 HTTP/HTTPS Nginx、HAProxy 可按 URL/Header 路由

典型架构 ：LVS(四层) → Nginx 集群(七层) → 应用服务

四、Kafka ------ 高吞吐消息队列

4.1 是什么

Kafka 是 LinkedIn 开源的分布式 发布订阅 消息系统，核心定位是 高吞吐、可持久化、可重放 的日志型 MQ。

4.2 核心架构

复制代码 
Producer → Broker(集群) → Consumer Group
              ↓
            Topic（分主题）
              ↓
            Partition（分区，有序）
              ↓
            Replica（副本，HA）

4.3 核心概念

概念 说明
Topic 消息分类
Partition Topic 的分区，每个 Partition 是有序日志，Kafka 顺序性的最小单位
Offset 消息在 Partition 中的位移，由 Consumer 自己维护
Producer 生产者，可指定 key 决定写哪个分区
Consumer Group 消费者组，组内分区互斥消费（一个 Partition 同时只被组内 1 个 Consumer 消费）
Broker Kafka 服务节点
Replica (Leader/Follower) 副本机制，ISR 同步副本集合
Zookeeper / KRaft 元数据管理（2.8 后支持 KRaft 模式去 ZK）

4.4 为什么这么快？

  1. 顺序磁盘 IO：日志追加写，性能逼近内存随机
  2. 零拷贝 (sendfile)：DMA 直接把数据从磁盘到网卡
  3. 批量 + 压缩：Producer 批量发送，支持 gzip/snappy/lz4
  4. 分区并行：水平扩展能力极强
  5. Page Cache：充分利用操作系统缓存

4.5 关键问题

① 顺序消费：同一个 key 路由到同一个 Partition，保证局部有序

② 不丢消息：

  • Producer：acks=all（所有 ISR 副本写入才确认）
  • Broker：replication.factor>=3，min.insync.replicas>=2
  • Consumer：手动提交 offset，业务处理完再提交

③ 不重复消费：

  • 业务侧做幂等（数据库唯一键 / 状态机）
  • Kafka 0.11+ 支持 Exactly-Once 语义

④ 消息积压：

  • 扩 Partition + 扩 Consumer（最多对等）
  • 优化消费逻辑（批量、异步）

4.6 vs 其他 MQ

MQ 吞吐 延迟 特点
Kafka 极高（百万级/s） ms 日志型，大数据/流处理首选
RocketMQ 高（十万级） ms 阿里出品，事务消息强
RabbitMQ 中（万级） μs AMQP 协议，路由灵活
Pulsar 高 ms 存算分离，云原生

五、Nacos ------ 注册中心 + 配置中心

5.1 是什么

阿里开源的 服务发现 + 动态配置 一体化中间件，Spring Cloud Alibaba 标配。

5.2 两大核心能力

服务注册与发现
复制代码 
服务提供方 → 注册到 Nacos → 服务消费方拉取列表 → 本地负载均衡调用
  • 心跳保活、健康检查
  • 临时实例（基于心跳）/ 永久实例（手动下线）
  • 支持权重、就近路由、灰度
动态配置管理
  • 配置集中存储（Data ID + Group + Namespace 三级隔离）
  • 监听机制：配置变更 → 推送到客户端 → 应用动态生效
  • 版本管理、灰度发布、回滚

5.3 核心模型

概念 类比
Namespace 环境隔离（dev/test/prod）
Group 业务分组
Service / Data ID 服务名 / 配置标识
Cluster 集群（机房/可用区）

5.4 一致性协议

  • CP 模式 (Raft)：永久实例，强一致
  • AP 模式 (Distro)：临时实例，最终一致（默认，性能高）

5.5 vs 同类

注册中心 一致性 健康检查 备注
Nacos AP/CP 可选 TCP/HTTP/MySQL 国产，配置中心一体
Eureka AP 心跳 Netflix 已停更
Zookeeper CP Session 强一致，性能一般
Consul CP 多种 HashiCorp

六、Redis ------ 高性能缓存

6.1 是什么

基于内存的 KV 数据库，单线程模型（6.0 后多线程 IO），QPS 可达 10w+。

6.2 五大基础数据类型

类型 底层 用途
String SDS 缓存、计数器、分布式锁
List quicklist 消息队列、最新 N 条
Hash ziplist/hashtable 对象存储
Set intset/hashtable 去重、共同好友
ZSet ziplist/skiplist 排行榜、延迟队列

高级类型：Bitmap（签到）、HyperLogLog（UV 统计）、Geo（地理位置）、Stream（消息流）

6.3 为什么这么快

  1. 纯内存
  2. 单线程（避免上下文切换、锁竞争）
  3. IO 多路复用 (epoll)
  4. 高效数据结构

6.4 持久化

  • RDB：快照，紧凑、恢复快，可能丢数据
  • AOF：追加日志，三种刷盘策略（always/everysec/no）
  • 混合持久化（4.0+）：RDB + 增量 AOF

6.5 高可用方案

方案 说明 适用
主从 一主多从，读写分离 简单场景
哨兵 Sentinel 自动故障转移 中小规模
Cluster 数据分片（16384 个 slot） 大规模，水平扩展

6.6 经典问题

问题 现象 解决
缓存穿透 查不存在的 key 打穿到 DB 布隆过滤器 / 空值缓存
缓存击穿 热点 key 过期，瞬间打 DB 互斥锁 / 永不过期 + 异步刷新
缓存雪崩 大量 key 同时过期 过期时间加随机值 / 多级缓存
缓存一致性 缓存与 DB 不一致 延迟双删 / Canal 订阅 binlog

6.7 典型应用

  • 缓存、Session 共享
  • 分布式锁（SET NX PX + Lua 释放，或 Redisson）
  • 限流（令牌桶 / 滑动窗口）
  • 排行榜（ZSet）
  • 计数器、防刷

七、分布式系统核心理论

7.1 CAP 定理

  • Consistency 一致性
  • Availability 可用性
  • Partition tolerance 分区容错性

三者只能取其二，网络分区不可避免 → 只能在 CP / AP 之间二选一。

  • CP：Zookeeper、etcd、Nacos(CP)
  • AP：Eureka、Nacos(AP)、Cassandra

7.2 BASE 理论

CAP 的工程妥协：Basically Available（基本可用）+ Soft state（软状态）+ Eventually consistent（最终一致）

7.3 分布式事务方案

方案 一致性 性能 实现
2PC 强 低 XA、JTA
3PC 强 低 改进 2PC
TCC 最终 中 Try-Confirm-Cancel，业务侵入
Saga 最终 高 长事务，正向 + 补偿
本地消息表 最终 高 DB + MQ
可靠消息 最终 高 RocketMQ 事务消息
Seata AT 最终 中 自动生成反向 SQL

7.4 分布式 ID

  • UUID：无序、占空间大
  • 雪花算法 Snowflake：时间戳 + 机器 ID + 序列号，64bit 有序
  • 数据库号段：批量取，性能高
  • Redis incr：单调递增
  • 美团 Leaf、百度 UidGenerator

7.5 一致性算法

  • Paxos：理论祖师，难懂
  • Raft：易理解，etcd/Consul/Nacos 用
  • ZAB：Zookeeper 专用
  • Gossip：最终一致，Cassandra/Redis Cluster

八、微服务架构

8.1 是什么

把单体应用按业务边界拆成 多个独立部署、独立技术栈、独立数据库 的小服务，通过轻量协议（HTTP/RPC）通信。

8.2 核心组件全景

复制代码 
┌──────────────────────────────────────────┐
│           网关 (Gateway/Zuul)             │  ← 鉴权、限流、路由
└──────────────────────────────────────────┘
                    ↓
┌──────────────────────────────────────────┐
│         服务调用 (Dubbo/Feign)            │  ← RPC
└──────────────────────────────────────────┘
       ↓              ↓             ↓
   用户服务        订单服务       商品服务
       └──── 注册中心 (Nacos) ────┘
       └──── 配置中心 (Nacos) ────┘
       └──── 链路追踪 (SkyWalking) ─┘
       └──── 熔断降级 (Sentinel) ─┘
       └──── 消息总线 (Kafka) ────┘
       └──── 日志聚合 (ELK) ──────┘

8.3 服务拆分原则

  • 单一职责：一个服务做一件事
  • 业务边界（DDD）：按领域拆分
  • 数据自治：每个服务有自己的数据库
  • 粒度适中：避免过度拆分（分布式单体）

8.4 服务间通信

方式 代表 特点
REST HTTP+JSON 简单通用
RPC Dubbo/gRPC 性能高，强类型
MQ Kafka/RocketMQ 异步解耦

8.5 常见挑战与方案

挑战 方案
服务发现 Nacos / Eureka
负载均衡 Ribbon / LoadBalancer
配置管理 Nacos / Apollo
熔断降级 Sentinel / Hystrix
网关 Spring Cloud Gateway / Kong
链路追踪 SkyWalking / Zipkin
分布式事务 Seata
日志监控 ELK + Prometheus + Grafana

8.6 vs 单体

维度 单体 微服务
复杂度 低 高（运维、调用链）
部署 整体部署 独立部署
扩展 整体扩展 按需扩展
故障 全军覆没 局部隔离
团队 集中 小团队自治

九、数据库主从（主从表/主从复制）

9.1 主从复制

目的：高可用 + 读写分离 + 数据备份

MySQL 主从原理
复制代码 
Master (主)                          Slave (从)
   ↓                                    ↑
binlog (二进制日志)  ──→  IO Thread  ──→  relay log
                                          ↓
                                       SQL Thread (回放)

三种复制模式：

  • 异步复制：默认，主库提交后立即返回，可能丢数据
  • 半同步复制：至少一个从库收到 binlog 才返回
  • 全同步：所有从库都执行完，性能差

9.2 读写分离

应用层（ShardingSphere / MyCAT）或中间件层把：

  • 写 → Master
  • 读 → Slave（多个，负载均衡）

坑：主从延迟导致写完立刻读读不到 → 强一致读走主库、或用缓存兜底

9.3 分库分表

当单表数据量过大（千万级以上）：

维度 说明
垂直分库 按业务拆，用户库 / 订单库
垂直分表 大表按列拆（冷热分离）
水平分库 同一张表的数据分散到多个库
水平分表 同一张表分散到多张子表（user_0、user_1...）

分片键选择：

  • 范围分片（按时间/ID 范围）：易热点
  • 哈希分片：均匀但难范围查询
  • 一致性哈希：扩容平滑

工具：ShardingSphere、MyCAT、TDDL、Vitess

9.4 主表 / 从表（业务概念，外键关系）

如果指的是 关联关系中的主表与从表：

  • 主表 ：被引用的表（如 user）
  • 从表（子表） ：含外键的表（如 order.user_id 引用 user.id）

操作约束：

  • 主表删除前，从表必须先删（或级联 CASCADE）
  • 从表插入时，外键值必须存在于主表

十、整体技术栈如何协同？

下面这张图是一个典型生产级微服务架构，把上面所有技术串起来：

复制代码 
                    用户/客户端
                         ↓
                  ┌─────────────┐
                  │  CDN/DNS    │
                  └─────────────┘
                         ↓
              ┌─────────────────────┐
              │   LVS（四层 LB）    │
              └─────────────────────┘
                         ↓
              ┌─────────────────────┐
              │  Nginx 集群（七层） │  ← HTTPS、限流
              └─────────────────────┘
                         ↓
              ┌─────────────────────┐
              │   API Gateway       │  ← 鉴权、路由
              └─────────────────────┘
                         ↓
        ┌────────────────┼────────────────┐
        ↓                ↓                ↓
   ┌─────────┐      ┌─────────┐     ┌─────────┐
   │ 用户服务 │      │ 订单服务 │     │ 商品服务 │  ← 跑在 K8s Pod 里
   └─────────┘      └─────────┘     └─────────┘
        │                │                │
        └────────────────┼────────────────┘
                         ↓
   ┌──────────────────────────────────────────┐
   │  Nacos（注册+配置） / Sentinel（熔断）   │
   │  Kafka（异步消息） / Redis（缓存）        │
   │  SkyWalking（链路） / ELK（日志）         │
   └──────────────────────────────────────────┘
                         ↓
              ┌─────────────────────┐
              │  MySQL 主从 + 分库分表 │
              └─────────────────────┘

  全部容器化 → Docker
  全部编排   → Kubernetes

一次下单请求的完整流程

  1. 客户端 → DNS → LVS → Nginx（HTTPS 卸载）
  2. → Gateway（鉴权、限流）
  3. → 从 Nacos 拉到 order-service 实例列表，负载均衡选一台
  4. → order-service（运行在 K8s Pod 中的 Docker 容器）
  5. → 查 Redis 缓存（商品库存）
  6. → 通过 Feign/Dubbo 调用 user-service 验证用户
  7. → 写入 MySQL 主库（主从复制到从库，分库分表路由）
  8. → 发送消息到 Kafka（异步通知库存、物流）
  9. → Sentinel 全程熔断保护，SkyWalking 全链路追踪
  10. → 日志收集到 ELK ，指标上报 Prometheus
相关推荐
一个做软件开发的牛马7 小时前
我用 Java 写了一个猜数字游戏，踩了 3 个流程控制的坑
java
格桑阿sir7 小时前
02-大模型智能体开发工程师：Transformer架构核心原理
深度学习·ai·架构·llm·transformer·agent·智能体
专注VB编程开发20年7 小时前
Python 的 C 扩展，本质上就是“去中心化的 COM”
java·服务器·开发语言·ide·python
LB21127 小时前
消灭并发重复调用：基于 Agent 调用 LLM 的分布式 Single-Flight 实战
java·开发语言·redis·分布式·agent
JAVA社区8 小时前
Java进阶全套教程（七）—— Redis超详细实战详解
java·linux·开发语言·redis·面试·职场和发展
皮卡祺q8 小时前
【算法-0】背包问题（三维+二维）
java·javascript·算法
shinelord明8 小时前
【云计算】k8sclient API 镜像操作 Java 类封装
java·kubernetes·云计算
invicinble8 小时前
spring事务相关信息量的沉淀
java·后端·spring
青天喵喵8 小时前
Linux Wi-Fi 实战指南：AP / STA 实战用例（实战篇一）
linux·网络·架构·智能路由器·嵌入式·wi-fi
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法04裂开！ChatGPT 居然开始要手机号验证，附详细解决方法05CC-Switch & Claude 基于 Linux 服务器安装使用指南06【AI】2026 年具身智能模型和世界模型总结07几个好用的ip纯净度检测网站08codex app每次打开重连5次Reconnecting问题解决09装上就回不去了：CodeGraph 让 AI 编程效率飙升 92%，它到底做了什么？10CC-Switch 全平台下载、安装与使用全指南（Windows/macOS/Linux）