架构与分布式 on 方糖猫Blog

☸️ Kubernetes 学习总结与避坑指南

Wed, 12 Feb 2025 10:00:00 +0800

☸️ Kubernetes 学习总结与避坑指南

参考书籍：龚正等《Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触》、Marko Lukša《Kubernetes in Action》目标读者：会一点 Docker、刚接触 K8s，或者「YAML 会抄但一出问题就懵」的同学。

Kubernetes（简称 K8s，因为 K 和 s 之间有 8 个字母）是 Google 开源的容器编排系统，解决了「成百上千个容器跑在成百上千台机器上，谁来调度、谁来扩容、挂了谁来拉起」的问题。它不是一门「背完概念就会」的技术——新人最常见的状态是：每个名词都听过，但它们之间怎么串起来的说不清楚，Pod 一挂就不知道该看哪里。

这篇文章帮你建立主干知识框架：

K8s 集群整体长什么样？Master 和 Node 各自干什么？
Pod、Node、Service、Ingress、ConfigMap 这些核心对象到底是什么关系？
Istio 服务网格在解决什么问题？
共享存储（PV/PVC/NAS）怎么用，有哪些坑？
排查 K8s 问题需要补哪些 Unix 网络编程基础知识？
生产环境如何做内外网访问隔离（私网端点 / 内网 LB / NetworkPolicy）？
在阿里云 ACK（以及 AWS EKS）上落地时要注意什么？
Jenkins 如何与 K8s 打通，实现自动化部署、验证与失败回滚？
遇到 CrashLoopBackOff、OOMKilled、502、DNS 慢这些经典问题，该按什么思路排查？

一、K8s 整体架构：一个「中心化大脑 + 一群干活的节点」

K8s 集群在逻辑上分为两大部分：

控制平面（Control Plane，俗称 Master）：集群的大脑，负责「决策」——调度、扩缩容、故障自愈。
工作节点（Node）：真正跑容器的机器，负责「执行」。

graph TB
    subgraph 控制平面["控制平面 Control Plane（阿里云 ACK 托管，用户不可见）"]
        APIServer[kube-apiserver<br/>集群唯一入口，所有操作都经过它]
        ETCD[(etcd<br/>分布式 KV 存储<br/>集群所有状态都在这里)]
        Scheduler[kube-scheduler<br/>决定 Pod 调度到哪个 Node]
        CM[kube-controller-manager<br/>各种控制器：副本数维持、节点监控等]
        CCM[cloud-controller-manager<br/>对接云厂商：SLB/EBS/路由]
    end

    subgraph 节点1["Worker Node 1"]
        K1[kubelet<br/>节点上的「包工头」]
        P1[kube-proxy<br/>维护 Service 网络规则]
        C1[容器运行时<br/>containerd]
        Pod1[Pod A] ~~~ Pod2[Pod B]
    end

    subgraph 节点2["Worker Node 2"]
        K2[kubelet]
        P2[kube-proxy]
        C2[containerd]
        Pod3[Pod C]
    end

    APIServer --> ETCD
    Scheduler --> APIServer
    CM --> APIServer
    CCM --> APIServer
    K1 --> APIServer
    K2 --> APIServer
    User[kubectl / CI/CD] --> APIServer

记住这条主线：所有组件只跟 apiserver 说话，apiserver 把状态写进 etcd。你敲的每一条 kubectl 命令、每一个控制器的决策，都是「读/写 apiserver」这个动作。理解了这一点，后面所有概念都好串了。

K8s 的核心设计思想是声明式 API + 控制器循环：

graph LR
    A[你提交 YAML<br/>期望状态：3 个副本] --> B[apiserver 存进 etcd]
    B --> C{控制器不断对比<br/>期望状态 vs 实际状态}
    C -->|实际只有 2 个| D[再创建 1 个 Pod]
    D --> C
    C -->|一致| E[什么都不做]

这就是「自愈」的本质：不是有人盯着修，而是控制器永远在循环纠偏。所以 K8s 里的对象是「期望状态」的描述，不是一条条命令。

二、Node：干活的机器

2.1 Node 上有什么

每个 Node 上必装三个组件：

kubelet：节点代理。接收 apiserver 下发的 Pod 定义（PodSpec），调用容器运行时把容器拉起来，并持续上报节点和 Pod 状态。Pod 挂了重启、探针检测，都是 kubelet 干的。
容器运行时：真正拉镜像、跑容器的软件。Docker 已在 K8s 1.24 后被移除，现在主流是 containerd。
kube-proxy：维护节点上的网络规则（iptables/IPVS），让 Service 的虚拟 IP 能转发到真实 Pod。

2.2 节点相关的避坑点

节点 NotReady：最常见的原因是 kubelet 挂了、节点磁盘满（DiskPressure）、内存不足（MemoryPressure）或网络不通。排查顺序：先 kubectl describe node <名字> 看 Conditions，再登节点看 systemctl status kubelet 和日志 journalctl -u kubelet。
磁盘压力：容器日志、镜像、emptyDir 都在吃节点磁盘。务必给应用日志配轮转（logrotate 或运行时自带的日志上限 containerLogMaxSize），否则磁盘写满会把节点上所有 Pod 驱逐（Evicted）。
不要随意登节点手工改东西：K8s 期望节点是「牛」不是「宠物」——可替换、不特殊。手工装的 Agent、改的 iptables 规则，节点一重建全没了。需要节点级能力请用 DaemonSet。

三、Pod：K8s 的最小调度单元

3.1 为什么不是直接调度容器

Pod 是一组共享网络和存储的容器集合。同一个 Pod 里的容器：

共享同一个 IP 和端口空间（通过 localhost 直接互通）
可以共享 Volume

graph TB
    subgraph Pod["Pod（10.0.1.15）"]
        direction LR
        C1[主容器<br/>app:8080]
        C2[边车容器<br/>日志采集]
        V[(共享 Volume<br/>日志目录)]
        C1 --> V
        C2 --> V
    end
    C1 -.->|localhost:8080| C2

这个设计的经典用途就是 Sidecar（边车）模式：日志采集、流量代理（Istio 的 Envoy）都以边车容器形式注入 Pod，主容器无感知。

新人直觉「一个 Pod 跑一个容器」，这对 90% 的场景是对的。只有容器之间必须同生共死、共享 localhost 或共享文件时，才放进同一个 Pod。

3.2 Pod 生命周期与探针

stateDiagram-v2
    [*] --> Pending: 创建，等调度/拉镜像
    Pending --> Running: 调度成功，容器启动
    Running --> Succeeded: 正常退出（Job 类）
    Running --> Failed: 异常退出
    Running --> Running: 探针失败→kubelet 重启容器

三个探针，新人人手必配：

探针	作用	配错的后果
`livenessProbe`	判断容器是否活着，失败则重启容器	太灵敏 → 无限重启循环
`readinessProbe`	判断是否能接流量，失败则从 Service 摘除	不配 → 启动期请求打到没 ready 的 Pod，报 502
`startupProbe`	启动探针，成功前禁用另外两个	慢启动应用（如老 Java 服务）不配 → 被 liveness 误杀

3.3 资源 requests/limits 与 QoS：最容易被忽视的重灾区

resources:
  requests:        # 调度依据：保证分到这么多
    cpu: "250m"    # 0.25 核
    memory: "512Mi"
  limits:          # 使用上限
    cpu: "500m"
    memory: "1Gi"

requests 是调度的唯一依据：节点剩余可分配资源 ≥ Pod 的 requests 总和，Pod 才调度得上去。不配 requests，调度就是瞎排，节点超载。
CPU 超 limit → 被限流（throttle），容器变慢但不死；内存超 limit → OOMKilled，直接杀。这是两种完全不同的失败模式，排查时先分清。
QoS 等级：requests=limits 为 Guaranteed（最后被驱逐）；都不配为 BestEffort（节点资源紧张时最先被杀）。生产核心服务至少配 Burstable。

四、工作负载：不要直接创建裸 Pod

实际工作中你几乎不会手写 Pod，而是使用「管理 Pod 的控制器」：

对象	适用场景	一句话
Deployment	无状态服务（Web/API）	副本数 + 滚动更新 + 回滚
StatefulSet	有状态服务（MySQL/Kafka）	稳定的名字和网络标识、按序启停
DaemonSet	节点级 Agent（日志/监控）	每个 Node 跑一个
Job / CronJob	一次性/定时任务	跑完即退

Deployment 滚动更新过程：

sequenceDiagram
    participant U as 用户
    participant D as Deployment
    participant RS1 as ReplicaSet v1
    participant RS2 as ReplicaSet v2

    U->>D: kubectl set image 更新镜像
    D->>RS2: 创建新 RS，先拉起 1 个新 Pod
    RS2-->>D: 新 Pod ready
    D->>RS1: 缩掉 1 个旧 Pod
    Note over D,RS2: 循环：新 +1 → 旧 -1
    D->>RS1: 缩到 0（旧 RS 保留，可回滚）
    U->>D: kubectl rollout undo（随时回滚）

避坑点：

maxSurge / maxUnavailable 控制滚动节奏。默认 25%/25%，意味着更新中可能瞬间少 25% 的可用副本——容量紧张的服务要调小 maxUnavailable。
回滚靠旧 ReplicaSet 保留的 Pod 模板，revisionHistoryLimit 默认 10，别设成 0 否则无法回滚。
镜像 tag 不要用 latest：无法回滚、无法审计，且 imagePullPolicy 行为反直觉。用 git commit 号或语义化版本。

五、K8s 网络模型与必备的 Unix 网络编程知识

K8s 的网络问题占了线上故障的一半以上。而很多「K8s 网络问题」本质上是 Unix 网络编程/TCP 协议问题，只是发生在容器环境里。这一节把两边打通。

5.1 K8s 网络的三条铁律

K8s 对网络模型只有三个基本要求（具体实现交给 CNI 插件，如 Flannel、Calico、阿里云 Terway）：

每个 Pod 有自己的独立 IP
任意两个 Pod 之间可以直接通信（不经过 NAT）
Node 和 Pod 之间可以直接通信

graph LR
    subgraph 节点A["Node A"]
        PA["Pod A<br/>10.244.1.5"]
    end
    subgraph 节点B["Node B"]
        PB["Pod B<br/>10.244.2.8"]
    end
    PA <-->|"Pod 网络（CNI：Terway/Flannel/Calico）<br/>直连，无 NAT"| PB

5.2 Service：一组 Pod 的稳定入口

Pod 会漂移（重建后 IP 就变了），所以不能在代码里写死 Pod IP。Service 提供一个固定虚拟 IP（ClusterIP）+ DNS 名字，负载均衡到后端 Pod。

graph LR
    Client[客户端 Pod] -->|"访问 my-svc:80<br/>DNS 解析为 10.96.0.10"| SVC["Service: my-svc<br/>ClusterIP 10.96.0.10"]
    SVC -->|kube-proxy 的 iptables/IPVS 规则转发| P1[Pod 1]
    SVC --> P2[Pod 2]
    SVC --> P3[Pod 3]

三种 Service 类型：

ClusterIP（默认）：仅集群内可达
NodePort：在每个节点开一个高端口（30000-32767），可从集群外访问
LoadBalancer：对接云厂商负载均衡器（阿里云 CLB/SLB、AWS NLB/ALB），对外暴露的标准姿势

5.3 为什么排查 K8s 网络要懂 Unix 网络编程

下面这几组知识，是在 K8s 环境里排查连接问题的「元技能」：

（1）TCP 连接状态与 TIME_WAIT

TCP 挥手后主动关闭方会进入 TIME_WAIT 状态，默认保持 2MSL（Linux 上约 60s）。在高并发短连接场景（比如服务间大量 HTTP/1.0 式短调用），客户端端口会被 TIME_WAIT 大量占用，最终 Cannot assign requested address。

stateDiagram-v2
    ESTABLISHED --> FIN_WAIT1: 主动方 close()
    FIN_WAIT1 --> FIN_WAIT2: 收到对端 ACK
    FIN_WAIT2 --> TIME_WAIT: 收到对端 FIN
    TIME_WAIT --> CLOSED: 2MSL 超时（约60s）
    ESTABLISHED --> CLOSE_WAIT: 对端先 close()
    CLOSE_WAIT --> LAST_ACK: 我方 close()
    LAST_ACK --> CLOSED

K8s 里的对应症状与解法：

症状：服务间调用偶发超时，ss -s 看到 timewait 几万。
正解：应用层用长连接 + 连接池（HTTP keep-alive、gRPC），别依赖 net.ipv4.tcp_tw_reuse 这类内核参数硬扛。
另一个常见坑是 CLOSE_WAIT 堆积：对端关了连接但你的代码没 close()（连接泄漏），ss -ant | grep CLOSE_WAIT 一查便知。

（2）socket、backlog 与「连接被 Reset」

服务端 listen(fd, backlog) 的 backlog 是「已完成三次握手但应用还没 accept」的队列长度。K8s 场景下突发流量打到刚重启的 Pod，如果应用 backlog 太小（或迟迟不 accept），内核会直接 RST，客户端看到的是 Connection reset by peer。这类问题在 Pod 扩容瞬间、探针刚通过时高发——readinessProbe 通过 ≠ 应用真的能扛流量。

（3）epoll 与 I/O 多路复用

一个进程通过 epoll 可以管理数万连接（C10K 问题的解法）。Nginx Ingress、Envoy 都是 epoll 模型。要懂的点：

进程能开的连接数受 文件描述符上限限制：ulimit -n。容器里同样生效，高并发服务记得确认 limit（cat /proc/<pid>/limits）。
每个 TCP 连接 = 一个四元组（源IP:源端口 → 目标IP:目标端口）。客户端对单一目标的并发连接数理论上受源端口数（约 2.8 万个可用）限制——这又回到「必须用连接池复用连接」。

（4）conntrack：K8s 特有的网络坑

kube-proxy 的 iptables 模式依赖内核 conntrack（连接跟踪表）。节点上连接数巨大时 conntrack 表被打满（默认 nf_conntrack_max 往往不够），表现为新建连接随机丢包、无日志，极难排查。解法：调大 net.netfilter.nf_conntrack_max，或干脆把 kube-proxy 切到 IPVS 模式。阿里云 ACK 的 Terway 模式在这方面压力小很多。

（5）DNS：K8s 里的「隐形依赖」

集群内所有服务名解析都靠 CoreDNS。两个经典坑：

glibc 的 DNS 解析是串行的，且默认 ndots:5 导致集群内短域名先查 5 次后缀。症状：应用偶发解析慢 5s（一次超时重传）。解法：FQDN 写法 my-svc.my-ns.svc.cluster.local.（结尾加点）或调整 Pod 的 dnsConfig。
Java 应用默认永久缓存 DNS 结果（networkaddress.cache.ttl=-1），Service 后端 IP 变了 JVM 不知道。容器里务必显式设置 DNS 缓存 TTL（如 30s）。

5.4 内外网访问隔离：哪些服务能暴露，哪些必须藏住

生产集群的基本安全原则：默认所有东西都不出集群，只开必要的口子。K8s 默认网络是「全通」的（任何 Pod 可以访问任何 Pod，LoadBalancer 一不小心就开到公网），隔离要靠自己显式配置。隔离分三个层面，从外到内：

graph TB
    Internet[公网用户] -->|只放行 443| WAF[WAF / 安全组<br/>云平台层]
    WAF --> PubLB[公网 ALB/CLB<br/>仅 Web 入口服务]
    PubLB --> PubIng[Ingress Controller<br/>公网命名空间]
    PubIng --> WebSvc[Web Service<br/>ClusterIP]

    Office[办公网/运维] -->|VPN/跳板机| IntLB[内网 LoadBalancer<br/>intranet 类型]
    IntLB --> AdminSvc[管理后台 / 监控<br/>Grafana / Jenkins]

    subgraph 集群内["集群内部（东西向流量）"]
        WebSvc -->|NetworkPolicy 允许| AppSvc[业务 Service]
        AppSvc -->|NetworkPolicy 允许| DBSvc[数据库 Proxy Service]
        AppSvc -.->|NetworkPolicy 拒绝| Other[其他 namespace]
    end

第一层：云网络边界（VPC / 安全组）

API Server 用私网端点：阿里云 ACK 创建集群时选择「专有网络（私网）」API Server 访问，或只绑定内网 EIP，运维通过 VPN/跳板机访问；公网端点即便有证书认证也是攻击面。AWS EKS 对应 endpoint private access。
节点安全组收紧入方向：只放行 NodePort 范围给内网、放行 LB 健康检查来源，其余一律拒绝。ACK 的节点安全组默认规则要审一遍。
数据库、Redis 这类云产品走 VPC 内网地址，安全组只对集群节点网段开放。

第二层：Service 暴露方式——内外网分流的关键

LoadBalancer 类型 Service 默认创建的是公网 LB，这是最常见的「误暴露」事故。面向内部的服务要用注解显式声明内网 LB：

# 阿里云：内网 CLB（VPC 内可达，公网不可达）
apiVersion: v1
kind: Service
metadata:
  name: internal-admin
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"
spec:
  type: LoadBalancer
  ports:
    - port: 80

AWS EKS 对应注解：service.beta.kubernetes.io/aws-load-balancer-internal: "true"（NLB）或 aws-load-balancer-scheme: internal（ALB Controller）。

经验法则：

对外服务：公网 ALB/CLB + Ingress，前面最好再挂 WAF。
对内服务（管理后台、监控、Jenkins）：内网 LB 或纯 ClusterIP，配合 VPN/跳板机访问。
默认用 ClusterIP，需要出集群时再显式升级类型——把「暴露」当成一个需要评审的动作。
Ingress 上还可以用注解做来源 IP 白名单（如 nginx.ingress.kubernetes.io/whitelist-source-range: 10.0.0.0/8），给内部接口再加一道闸。

第三层：NetworkPolicy——集群内部的东西向隔离

即使流量不出集群，「测试 namespace 的 Pod 误连生产数据库」这类事故也常见。NetworkPolicy 是 Pod 级的防火墙（需要 CNI 支持，ACK 的 Terway、Calico 都支持，Flannel 不支持）：

# 第一步：namespace 默认全拒（白名单模式的起点）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: prod
spec:
  podSelector: {}          # 选中 namespace 内所有 Pod
  policyTypes: ["Ingress", "Egress"]
---
# 第二步：只放行需要的流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-app
  namespace: prod
spec:
  podSelector:
    matchLabels: {app: order-svc}
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels: {app: web-frontend}
      ports:
        - port: 8080

避坑点：

NetworkPolicy 是白名单累加模型：任何一条 policy 选中某 Pod，该 Pod 未被放行的方向就被默认拒绝。写漏了 DNS（Egress 到 kube-dns 的 53 端口）会导致全 namespace 解析失败——默认拒绝后记得显式放行 DNS。
策略只对选中后新建立的连接生效，且 Flannel 下写了也不生效（静默失效，最坑的一种）。
云安全组管的是「节点/LB 维度」，NetworkPolicy 管的是「Pod 维度」，两者互补不替代。
上了 Istio 的话，还可以用 AuthorizationPolicy 做带身份（mTLS 服务身份）的七层鉴权，比纯 IP/端口的 NetworkPolicy 更细。

六、Ingress：HTTP 流量的统一入口

Service 解决的是四层（TCP）负载均衡；Ingress 解决的是七层（HTTP/HTTPS）路由：按域名、按路径把外部流量分发到不同 Service。

graph TB
    User[外部用户] -->|HTTPS| LB[云负载均衡<br/>阿里云 ALB/CLB]
    LB --> IC[Ingress Controller<br/>Nginx / ALB Ingress]
    IC -->|"a.example.com/api/*"| S1[Service: api]
    IC -->|"a.example.com/web/*"| S2[Service: web]
    IC -->|"b.example.com/*"| S3[Service: admin]
    S1 --> P1[api Pod]
    S2 --> P2[web Pod]
    S3 --> P3[admin Pod]

注意分清两层：

Ingress 资源（YAML 对象）：只是路由规则的声明，本身不做任何事。
Ingress Controller（真正干活的组件）：如 ingress-nginx、阿里云 ALB Ingress Controller。它 watch Ingress 资源，把规则翻译成 Nginx 配置并热加载。

避坑点：

pathType: Prefix 和 Exact 的区别，/api 配 Prefix 会把 /apiserver 也匹配进去。
后端重写（rewrite-target）是最容易写错的注解，先想清楚「客户端路径 → 后端真实路径」的映射。
HTTPS 证书放在 Secret 里，过期忘续是经典事故——建议上 cert-manager 自动签发续期。
502 的第一排查动作：看 Ingress Controller 日志里 upstream 是「连接拒绝」（Pod 没 ready）还是「超时」（应用卡死）。

七、ConfigMap 与 Secret：配置和代码分离

十二要素应用的第一条就是「配置存环境」。K8s 里对应两个对象：

ConfigMap：普通配置（应用参数、配置文件、特性开关）
Secret：敏感配置（密码、密钥、证书），etcd 中 Base64 编码（注意：Base64 不是加密，生产环境要开 etcd 静态加密或对接 KMS）

两种注入方式：

# 方式一：环境变量
env:
  - name: DB_HOST
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: db_host

# 方式二：挂载为文件（推荐，支持热更新）
volumeMounts:
  - name: config
    mountPath: /etc/app
volumes:
  - name: config
    configMap:
      name: app-config

两个必踩的坑，提前告诉你：

环境变量注入的配置，改了 ConfigMap 不会生效，必须重启 Pod。文件挂载方式会自动更新（kubelet 定期同步，有分钟级延迟），但应用要支持 reload。
subPath 挂载的 ConfigMap 不会自动更新。这是用了 subPath 挂单个配置文件的同学必踩的坑——改完 ConfigMap 发现容器里还是旧的。解法：挂载整个目录，或接受重启 Pod 的事实。
ConfigMap 有 1MB 大小限制，别把大文件塞进去。

八、共享存储：PV / PVC / StorageClass

容器是临时的，数据要持久化就必须落到外部存储。K8s 的存储抽象分三层：

graph TB
    subgraph 管理员/云平台侧
        SC[StorageClass<br/>定义「用什么盘」<br/>如 alicloud-disk-essd / nas]
        PV[PersistentVolume<br/>一块真实的存储<br/>云盘/NAS 文件系统]
    end
    subgraph 应用侧
        PVC[PersistentVolumeClaim<br/>「我要 100Gi 存储」的申请单]
        Pod[Pod 挂载 PVC]
    end
    PVC -->|绑定| PV
    SC -->|动态供给：PVC 一创建<br/>自动开出对应 PV| PV
    Pod --> PVC

现代用法几乎全是动态供给：你只需要写 PVC 声明要多少空间，StorageClass 自动调用云厂商 API 创建云盘/NAS，不用手工建 PV。

三种访问模式（Access Modes）是高频考点：

模式	含义	典型存储
ReadWriteOnce (RWO)	只能挂到一个节点	云盘（阿里云 ESSD、AWS EBS）
ReadWriteMany (RWX)	多节点共享读写	文件存储（阿里云 NAS、AWS EFS）
ReadOnlyMany (ROX)	多节点只读	对象存储挂载、只读数据卷

共享存储的避坑清单：

云盘（RWO）不能跨可用区挂载。PV 创建在可用区 A，Pod 被调度到可用区 B 就永远 Pending。解法：用 WaitForFirstConsumer 模式的 StorageClass（等 Pod 定好节点再开盘），并用拓扑约束调度。
要多副本共享文件（如多个 Web Pod 共享上传目录），必须用 NAS/EFS 这类 RWX 存储，云盘做不到。
NAS 挂载注意权限问题：容器内进程 UID 和 NAS 目录属主不匹配会 Permission denied，用 securityContext.fsGroup 或挂载参数解决。
删除 PVC 会不会丢数据，取决于 PV 的 persistentVolumeReclaimPolicy（Retain 保留 / Delete 连盘一起删）。生产数据盘务必确认是 Retain。
StatefulSet 用 volumeClaimTemplates 给每个副本独立开盘，扩缩容时数据卷跟着 Pod 名字走，这是有状态服务的标准姿势。

九、Istio 服务网格：把「网络能力」从业务代码里剥出来

微服务多了之后，每个服务都要自己实现超时重试、熔断、灰度、流量监控——这些和业务无关。Istio 的思路：给每个 Pod 注入一个 Envoy 边车代理，接管所有进出流量，上述能力全部在代理层实现，业务代码零侵入。

graph TB
    subgraph 控制平面["Istio 控制平面（istiod）"]
        Pilot[配置下发<br/>流量规则]
        Citadel[证书管理<br/>mTLS]
    end
    subgraph 数据平面
        subgraph PodA["Pod A"]
            App1[业务容器] --- E1[Envoy 边车]
        end
        subgraph PodB["Pod B"]
            App2[业务容器] --- E2[Envoy 边车]
        end
    end
    Pilot -.->|xDS 配置下发| E1
    Pilot -.->|xDS 配置下发| E2
    E1 <-->|"mTLS 加密流量<br/>（应用无感知）"| E2

核心能力速览：

流量管理：VirtualService + DestinationRule 实现按权重灰度（v1 90% / v2 10%）、按 Header 路由、超时重试、熔断
安全：服务间自动 mTLS 加密 + 身份认证（AuthorizationPolicy）
可观测：不用改代码就拿到全链路指标、调用拓扑、访问日志
入口：Istio Gateway 替代/补充原生 Ingress，作为网格的南北向入口

避坑点（Istio 坑不少，挑最重要的）：

边车有成本：每个 Pod 多一份 Envoy 的 CPU/内存（默认 requests 约 100m/128Mi），上千 Pod 规模要算这笔账，必要时调小。
Sidecar 启动顺序：业务容器可能比 Envoy 先起来导致启动瞬间网络不通（现在 holdApplicationUntilProxyStarts 可解）；Job 类任务跑完 Envoy 不退导致 Job 永不结束，需要显式退出或关掉注入。
协议识别：Service 端口名要带协议前缀（name: http-xxx），否则 Istio 按 TCP 处理，七层能力全部失效。这是网格内路由不生效的第一嫌疑。
排障三板斧：istioctl analyze（静态检查配置）、istioctl proxy-config（看 Envoy 实际生效配置）、Envoy 的 :15000/stats 和 :15000/clusters。
新人别一上来就上全量 Istio。先在非核心 namespace 开注入练手，理解 VirtualService 再说。

十、云上落地：阿里云 ACK 为主，AWS EKS 对照

自己从零搭一套生产级 K8s（etcd 高可用、证书、网络插件）成本极高，生产环境几乎都用云厂商托管服务。

10.1 阿里云 ACK 关键点

graph TB
    subgraph 阿里云托管["ACK 托管层（免费/Pro）"]
        MA[控制平面：apiserver/etcd/scheduler<br/>阿里云托管，SLA 保障]
    end
    subgraph 你的账号["你的 VPC 内"]
        N1[ECS 节点池 1<br/>按量/抢占式]
        N2[ECS 节点池 2<br/>弹性伸缩 ESS]
    end
    MA --> N1
    MA --> N2
    N1 -.对接.-> CLB[CLB/ALB<br/>负载均衡]
    N1 -.对接.-> NAS[云盘 ESSD / NAS<br/>持久存储]
    N1 -.对接.-> SLS[SLS 日志 / ARMS 监控<br/>可观测]

实践经验：

网络插件选 Terway：Pod 直接用 VPC 弹性网卡 IP，无 overlay 开销、conntrack 压力小，还能配 NetworkPolicy；Flannel 适合小规模简单场景。Terway 模式下规划 VPC 网段要留够，每个 Pod 占一个真实 IP。
节点池 + 弹性伸缩：按业务波峰波谷自动扩缩节点；抢占式实例（Spot）跑无状态任务能省 70% 成本，但要容忍随时被回收。
Ingress 用 ALB Ingress Controller：比自建 Nginx Ingress 省心，ALB 本身按量弹性，且和 ACK 深度集成。
日志和监控开箱即用：日志服务 SLS（采集容器 stdout 和文件日志）、ARMS Prometheus 监控，别再自己搭 ELK 了。
镜像仓库 ACR：用 ACR EE（企业版）+ ACK 免密拉取插件，避免在 YAML 里配 imagePullSecret。
存储选 CNFS/云盘 ESSD（有状态单副本）+ NAS（共享文件）+ OSS（静态资源、备份） 的组合。

10.2 AWS EKS 速查对照

需求	阿里云 ACK	AWS EKS
网络插件	Terway（VPC 网卡直连）	aws-vpc-cni（同理）
七层入口	ALB Ingress	AWS Load Balancer Controller (ALB/NLB)
块存储	云盘 ESSD	EBS (gp3)
共享文件存储	NAS	EFS
日志	SLS	CloudWatch
监控	ARMS Prometheus	Managed Prometheus / Grafana
镜像仓库	ACR	ECR
无服务器节点	虚拟节点（ECI）	Fargate

概念完全互通，换云只是换 Controller 和注解。

十一、典型问题排查手册

11.1 通用排查流程

graph TD
    A[发现问题] --> B{Pod 状态？<br/>kubectl get pods}
    B -->|Pending| C[kubectl describe pod<br/>看 Events]
    C --> C1{原因}
    C1 -->|资源不足| C2[加节点/降 requests<br/>或开弹性伸缩]
    C1 -->|存储挂载失败| C3[检查 PVC 绑定/可用区]
    C1 -->|镜像拉取失败| C4[ImagePullBackOff：查镜像名/凭证/网络]
    B -->|CrashLoopBackOff| D[kubectl logs --previous<br/>看上一个容器的临终日志]
    D --> D1{原因}
    D1 -->|应用自身报错| D2[修代码/配置]
    D1 -->|Exit 137| D3[OOMKilled：调大 memory limit<br/>或查内存泄漏]
    D1 -->|Exit 143| D4[被优雅终止：查探针/滚动更新]
    B -->|Running 但访问异常| E[分层验证]
    E --> E1[1. 进 Pod 内 curl localhost 通吗？]
    E1 --> E2[2. curl Pod IP 通吗？]
    E2 --> E3[3. curl Service ClusterIP 通吗？<br/>查 Endpoints 是否有后端]
    E3 --> E4[4. Ingress 域名通吗？<br/>查 Controller 日志]

11.2 高频问题速查表

症状	最常见原因	第一动作
ImagePullBackOff	镜像名/tag 错、私有仓库无凭证、节点无公网	`describe pod` 看 Events 报错原文
CrashLoopBackOff	配置错、依赖没起来、探针误杀	`kubectl logs --previous`
OOMKilled (137)	内存 limit 太小或泄漏	看监控曲线，调 limit；Java 服务注意堆外内存
Pod 一直 Pending	资源不够、PVC 未绑定、污点/亲和性	`describe pod` 看调度失败原因
服务间偶发超时	conntrack 满、DNS 慢、TIME_WAIT 耗尽	`ss -s`、CoreDNS 日志、查连接池配置
滚动更新后 502	没配 readinessProbe / 没处理 SIGTERM 优雅退出	配探针 + preStop + 应用优雅关闭
ConfigMap 改了不生效	环境变量注入 / subPath 挂载	重启 Pod 或改为目录挂载
跨可用区挂载失败	云盘和节点不在同一 AZ	WaitForFirstConsumer + 拓扑约束

11.3 优雅退出：滚动更新不断流的完整姿势

Pod 被删除时的标准流程（很多人只知道一半）：

sequenceDiagram
    participant K as kubelet
    participant P as Pod
    participant EP as Endpoints

    K->>EP: 把 Pod 从 Service 摘除（不再接新流量）
    K->>P: 执行 preStop 钩子（如 sleep 5，等摘流量生效）
    K->>P: 发送 SIGTERM
    P->>P: 应用应：停止接新请求，处理完存量请求后退出
    Note over K,P: 超过 terminationGracePeriodSeconds（默认30s）
    K->>P: SIGKILL 强杀

三个缺一不可：readinessProbe 保证新 Pod ready 才切流量；preStop/优雅关闭保证老 Pod 处理完存量请求；terminationGracePeriodSeconds 给够时间。Java/Go 服务请确认框架注册了 SIGTERM 处理器（Spring Boot 的 server.shutdown=graceful、Go 的 signal.Notify）。

11.4 kubectl 排障速查

kubectl get pods -o wide -n <ns>          # 看状态和所在节点
kubectl describe pod <pod> -n <ns>        # 看 Events（排障第一步）
kubectl logs <pod> -c <container> --previous   # 崩溃前的日志
kubectl get endpoints <svc> -n <ns>       # Service 后面到底有没有 Pod
kubectl exec -it <pod> -- sh              # 进容器内验证网络
kubectl run debug --rm -it --image=busybox:1.36 -- sh   # 临时网络调试 Pod
kubectl top pod / kubectl top node        # 资源占用
kubectl get events --sort-by=.lastTimestamp -n <ns>     # 按时间看事件

十二、CI/CD：Jenkins 与 K8s 打通，实现自动化部署与验证

手工 kubectl apply 只适合学习。生产环境的标准做法是把「构建 → 推镜像 → 部署 → 验证 → 失败回滚」串成流水线，代码合并后自动完成发布。

12.1 整体流水线长什么样

graph LR
    Dev[开发者 git push] --> Hook[Webhook 触发 Jenkins]
    Hook --> Build[阶段1: 构建<br/>单测 + Docker 镜像]
    Build --> Push[阶段2: 推送镜像<br/>到 ACR/ECR<br/>tag = git commit]
    Push --> Deploy[阶段3: 部署<br/>kubectl set image<br/>更新 K8s]
    Deploy --> Verify[阶段4: 验证<br/>rollout status + 冒烟测试]
    Verify -->|成功| Done[发布完成<br/>钉钉/邮件通知]
    Verify -->|失败| RB[自动回滚<br/>rollout undo] --> Alarm[告警通知]

关键认知：K8s 侧不需要装任何 Jenkins 插件或 Agent 也能被部署——Jenkins 只要有目标集群的 kubeconfig（访问凭证），用 kubectl 就能驱动 apiserver 完成一切。打通的本质就两件事：凭证怎么管、流水线脚本怎么写。

12.2 Jenkins 的两种部署形态

形态	说明	适用
Jenkins 在集群外（独立服务器/另一集群）	通过 kubeconfig 远程操作业务集群	一套 Jenkins 管多个集群，最常见
Jenkins 跑在 K8s 集群内	配合 Kubernetes 插件，每次构建动态拉起一个 Pod 作为构建 agent，用完即销毁	构建任务多、想弹性利用集群资源

graph TB
    subgraph Jenkins侧["Jenkins（集群外或集群内）"]
        J[Jenkins Master]
        C1[凭据1: kubeconfig<br/>Secret file 类型]
        C2[凭据2: ACR 账号<br/>Username/Password 类型]
        J --> C1
        J --> C2
    end
    subgraph 阿里云["阿里云"]
        J -->|docker push| ACR[ACR 镜像仓库]
        J -->|"kubectl（走内网 API Server 端点）"| API[ACK apiserver]
        API --> Pod[滚动更新业务 Pod]
        Pod -->|免密拉取| ACR
    end

推荐做法：Jenkins 与 ACK 在同一 VPC 内，kubectl 直接走 API Server 的内网端点（安全且免公网流量）；镜像仓库用 ACR 企业版 + ACK 免密拉取，业务侧零凭证。

12.3 最小权限的部署凭证：别把 admin kubeconfig 给 Jenkins

这是 CI/CD 安全的第一课。给 Jenkins 一个只能操作特定 namespace、只能改 Deployment 的 ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-deployer
  namespace: prod
---
# Role 只在 prod namespace 内生效
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: prod
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "patch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-deployer
  namespace: prod
subjects:
  - kind: ServiceAccount
    name: jenkins-deployer
    namespace: prod
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

然后为这个 SA 生成 token，做成只含该 token 的 kubeconfig，存进 Jenkins 的 Secret file 凭据。好处：凭证泄露也只影响一个 namespace 的 Deployment，且可以随时 kubectl delete rolebinding 吊销。

12.4 完整 Jenkinsfile 示例

pipeline {
    agent any
    environment {
        IMAGE     = "registry.cn-hangzhou.aliyuncs.com/mycompany/order-svc"
        TAG       = "${env.GIT_COMMIT.take(8)}"   // 用 git commit 做 tag，可回滚可追溯
        KUBECONFIG = credentials('ack-prod-kubeconfig')   // Secret file 凭据
    }
    stages {
        stage('构建') {
            steps {
                sh 'mvn -q test'                       // 先跑单测，挂了直接终止
                sh "docker build -t ${IMAGE}:${TAG} ."
            }
        }
        stage('推送镜像') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'acr-account',
                    usernameVariable: 'U', passwordVariable: 'P')]) {
                    sh 'echo $P | docker login registry.cn-hangzhou.aliyuncs.com -u $U --password-stdin'
                    sh "docker push ${IMAGE}:${TAG}"
                }
            }
        }
        stage('部署到 ACK') {
            steps {
                sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                    set image deployment/order-svc order-svc=${IMAGE}:${TAG}"
            }
        }
        stage('验证') {
            steps {
                // 阻塞等待滚动更新完成；超时/失败会非零退出
                sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                    rollout status deployment/order-svc --timeout=300s"
                // 冒烟测试：走内网 SLB 打健康检查和关键接口
                sh "curl -fsS --retry 5 --retry-delay 3 \
                    http://order-svc-internal.prod.svc.cluster.local/healthz || exit 1"
            }
        }
    }
    post {
        failure {
            // 部署验证失败自动回滚到上一个版本
            sh "kubectl --kubeconfig=$KUBECONFIG -n prod \
                rollout undo deployment/order-svc || true"
        }
    }
}

12.5 「验证」环节的正确姿势

很多流水线只做到 kubectl apply 就算「发布成功」，这是自欺欺人。apply 返回成功只代表 apiserver 收下了 YAML，Pod 起不起得来是另一回事。可靠的验证链：

rollout status 阻塞等待：确认所有新副本 ready（背后靠的就是 readinessProbe——再次体现探针的重要性）。
冒烟测试：对真实入口打 /healthz 和一两个核心业务接口，确认「能起来」且「能干活」。
失败自动回滚：rollout undo 依赖旧 ReplicaSet 还在（revisionHistoryLimit 别设 0）且镜像 tag 可追溯——这就是前面说「不要用 latest」的根本原因。
更严谨的做法是灰度验证：先用 Istio 把 5% 流量切到新版本观察指标，确认无误再全量（见第九章）。

12.6 CI/CD 避坑清单

镜像 tag 必须唯一可追溯：git commit 短哈希或构建号，杜绝 latest，否则回滚时根本不知道该回滚到哪个镜像。
凭据最小化 + 分环境：dev/staging/prod 用不同的 SA 和 Jenkins 凭据，prod 的部署动作加人工审批（Jenkins 的 input 步骤）。
声明式优先：服务变多后，把 kubectl set image 换成 Helm/Kustomize（YAML 也进 Git 仓库，可审计可 diff）；再进一步上 GitOps（ArgoCD/Flux）——Jenkins 只负责构建推镜像，部署由集群内的 ArgoCD 从 Git 仓库自动同步，Jenkins 不再需要生产集群的任何凭证，安全性大幅提升。
Jenkins 到集群的网络：kubectl 走内网 API Server 端点；如果 Jenkins 在另一个 VPC，用云企业网/对等连接打通，不要把 API Server 暴露公网给 Jenkins 用。
构建产物（镜像）与部署配置分离管理，避免「同一个 tag 被覆盖推送」导致回滚失效——ACR 里给 prod 仓库开镜像 tag 不可变（immutable）开关。

十三、学习路线建议

第一周：本地装 minikube 或 kind，把 Deployment/Service/ConfigMap 各玩一遍，亲手制造一次 CrashLoopBackOff 并修好它。
第二周：搞懂网络——Pod 网络、Service 转发（iptables）、Ingress、NetworkPolicy 内外网隔离，配合 tcpdump/ss 在容器里抓包看真实流量。
第三周：上云。开一套阿里云 ACK（按量付费，玩完就删），跑通「ACR 推镜像 → ACK 部署 → ALB Ingress 暴露 → NAS 挂共享盘 → SLS 看日志」全流程。
第四周：打通 CI/CD。用 Jenkins + 最小权限 SA 实现「推代码 → 自动构建 → 自动部署 → rollout 验证 → 失败回滚」完整流水线。
进阶：Helm 包管理、HPA 自动扩缩容、Istio 灰度发布、GitOps（ArgoCD）。

最后送一句《Kubernetes 权威指南》反复强调的心法：K8s 的一切都是声明式的——你描述「我要什么」，控制器负责「做到」。排查问题时永远先问：期望状态（YAML/Spec）是什么？实际状态（Status/Events）是什么？两者的差距就是答案所在。

参考资料：

《Kubernetes 权威指南：从 Docker 到 Kubernetes 实践全接触（第 4 版）》龚正等

《Kubernetes in Action》Marko Lukša

《Unix 网络编程卷1》W. Richard Stevens（网络排障内功）

Kubernetes 官方文档

阿里云 ACK 文档

《设计数据密集型应用》学习总结：存量、流量、回路——每个设计决策都是三者的权衡

Tue, 08 Aug 2023 10:40:00 +0800

《设计数据密集型应用》学习总结：存量、流量、回路——每个设计决策都是三者的权衡

目标读者：写过 CRUD、用过 MySQL/Redis/Kafka，但说不清它们"为什么这么设计"的工程师。
参考书籍：Martin Kleppmann《Designing Data-Intensive Applications》（DDIA，那只野猪书）
阅读目标：不背目录，而是拿到一个能套在任何存储/中间件上的分析框架——存量、流量、回路。

0. 写在前面：别背组件，背权衡

市面上的"中间件教程"有个通病：教你 MySQL 怎么用、Redis 怎么用、Kafka 怎么用，但从不告诉你为什么它们长得这么不一样。同样是存数据，Redis 敢把数据放内存，MySQL 不敢；同样是日志，Kafka 能当数据库用，而大多数人只拿它当管道。

DDIA 这本书最值钱的地方，就是把这些"为什么"串成了一条线。读完我把它提炼成三个词：

存量（State）：数据怎么存——存储引擎（LSM/B-Tree）、编码格式、行存列存。
流量（Flow）：数据怎么动——复制、分区、派生数据、流处理。
回路（Loop）：系统怎么自我纠错——事务、隔离级别、共识、线性一致性。

一句话理解：任何一个数据系统的设计决策，都是在存量成本、流量吞吐、回路强度三者之间做取舍。 你要强一致（回路强），就得牺牲可用性或延迟（流量贵）；你要写入快（流量大），就得接受读时合并或后台压缩的代价（存量结构变复杂）。

避坑指南 0：读完这本书最大的误区是"上来就选最强的一致性"。Kleppmann 自己说过大意如此的话：一致性模型的选择应该由业务能不能容忍异常决定，而不是由工程师的洁癖决定。能容忍就用最终一致，性能白捡。

和博客已有的 Redis/MySQL/MQ 笔记是"原理 vs 用法"的关系：那些笔记讲"这个命令怎么用、这个参数怎么调"，这篇讲"这个组件为什么被设计成这样"。建议搭配阅读——看完这篇再回头看 Redis 的 RDB/AOF、MySQL 的 InnoDB redo log、Kafka 的副本协议，会有"原来如此"的感觉。

第一部分存量：数据怎么存

1. LSM-Tree vs B-Tree：写的快和读的快，不可兼得

数据库索引结构就两大流派，区别一句话：

B-Tree：读的时候顺藤摸瓜，树的高度就是磁盘寻道次数。写入是"就地更新"——找到那一页，改掉。MySQL InnoDB 就是这个。
LSM-Tree：写入只往内存里的有序结构（Memtable）追加，内存写满了就整体刷到磁盘变成一个 SSTable（Sorted String Table，一段有序的文件）。读取时从最新的 SSTable 往最旧的依次找。LevelDB、RocksDB、Cassandra、HBase 都是这个。

SSTable 合并（compaction）是 LSM 的灵魂。因为同一个 key 的新旧版本散落在多个 SSTable 里，后台必须定期把它们归并排序、去重、丢掉被删除的墓碑标记，否则文件越积越多，读放大失控。

flowchart TD
    W["写入请求"] --> L["WAL 追加日志<br/>（崩溃恢复用）"]
    L --> M["Memtable<br/>（内存有序表）"]
    M -->|"写满阈值"| S1["SSTable 1<br/>（不可变文件）"]
    M -->|"再写满"| S2["SSTable 2"]
    M -->|"又写满"| S3["SSTable 3"]
    S1 --> C["后台 Compaction<br/>归并排序 + 去重 + 清墓碑"]
    S2 --> C
    S3 --> C
    C --> S4["合并后的大 SSTable<br/>（旧文件丢弃）"]
    R["读取请求"] --> M
    R --> S3
    R --> S2
    R --> S1
    R -->|"配合布隆过滤器<br/>跳过不含该 key 的文件"| MISS["快速判不存在"]

小数字例子感受写放大：假设每写 1 GB 数据，经过 3 层 compaction，每层都要重写一遍，实际磁盘写入可能是 5~10 GB。这就是"写放大"，也是 RocksDB 调优的核心战场。

LSM 读取慢怎么补救？靠布隆过滤器（Bloom filter）：一个很小的内存位图，能告诉你"这个 key 肯定不在这个 SSTable 里"（可能有误报，但绝不漏报）。查一个不存在的 key 时，布隆过滤器直接拦掉，不用真的去翻磁盘文件——这对"查缓存未命中再查库"的场景是救命优化。Cassandra、HBase、RocksDB 全都内置。

怎么选？ 记住这张对照表：

维度	B-Tree	LSM-Tree
写入	就地更新，写放大相对低但随机 IO	顺序追加，吞吐高但有 compaction 写放大
读取	稳定，一次查找几层树	要查多层文件，靠布隆过滤器和缓存补救
磁盘碎片	页分裂会产生碎片	文件整体重写，天然紧凑
典型代表	InnoDB、PostgreSQL	RocksDB、Cassandra、HBase

一句话理解：B-Tree 是"图书馆书架"，书按位置摆好，找书快、插书要挪位置；LSM 是"先记在便签上，攒一批再上架"，记便签飞快，但定期要整理书架，找书得翻几摞便签。

2. WAL：所有存储引擎的"保命符"

LSM 写 Memtable、B-Tree 改数据页，都是先动内存。断电怎么办？答案是 WAL（Write-Ahead Log，预写日志）：任何修改先追加一条日志到磁盘，再改内存结构。崩溃后重放日志恢复。

这个思想无处不在：

InnoDB 的 redo log 是 WAL；
PostgreSQL 的 WAL 直接就叫 WAL；
Redis 的 AOF 本质也是 WAL；
Kafka 的消息日志、ZooKeeper 的事务日志，全是同一个套路。

一句话理解：WAL 就是把"随机写"变成"顺序写"——磁盘顺序追加比随机写快几个数量级，顺便白捡了崩溃恢复能力。

3. 行存 vs 列存：OLTP 与 OLAP 的分水岭

行存：一行的所有列连续存放。适合"查一个人的全部信息"（点查、事务），即 OLTP。
列存：一列的所有值连续存放。适合"统计一百万人的平均年龄"（聚合、分析），即 OLAP。

为什么列存分析快？小数字例子：一张 100 列的表，分析查询只用 5 列。行存要把 100 列全部从磁盘读出来再丢弃 95 列；列存只读那 5 列，IO 直接省 95%。而且单列数据类型相同，压缩率极高（比如"性别"列去重后就两个值，位图编码一下几乎不占空间）。

代表：Parquet、ORC、ClickHouse、DuckDB 是列存；MySQL、PostgreSQL 是行存。Snowflake、BigQuery 这类数仓全部站在列存一边。

4. 编码与演进： schema 变了，老数据怎么办

存量还有个隐藏维度：数据格式会随时间演化。JSON 灵活但没约束；Protocol Buffers / Thrift / Avro 这类二进制编码通过字段编号实现前后兼容——新增字段给新编号，删掉字段不动旧编号，新老代码就能和平共处。

避坑指南 1：滚动升级时"新代码读老数据"和"老代码读新数据"会同时发生。所以兼容性必须是双向的：向后兼容（新读老）+ 向前兼容（老读新）。只考虑一个方向，升级到一半必出事。

第二部分流量：数据怎么动

单台机器存不下、扛不住、会宕机——这是"流量篇"要解决的三个问题。对应三板斧：复制（同一份数据放多台机器）、分区（不同数据放不同机器）、派生数据（数据从一个系统流向另一个系统）。

5. 复制：主从、多主、无主，三种政治体制

复制的目标是可用性和读扩展，但引入了全书最核心的矛盾：副本之间怎么保持一致。

主从复制（单主）：所有写请求走 Leader，Leader 把变更日志同步给 Follower。读可以分摊到 Follower。简单、直觉，MySQL、PostgreSQL、MongoDB（副本集）、Kafka 分区副本都是这个思路。

但"Follower 的数据是旧版本"这件事，会带来一连串用户可感知的诡异现象：

你刚发的朋友圈自己刷新后消失了 → 需要读己之写（read-your-writes）：用户写完之后，读请求必须走 Leader 或带版本号校验。
你的余额从 100 变成 80 又变回 100（读到了更旧的副本）→ 需要单调读（monotonic reads）：一个用户的连续读请求固定打到同一个副本。
聊天里先看到回复再看到原帖（分区的数据流向不同副本速度不同）→ 需要一致前缀读（consistent prefix reads）：有因果关系的写入，任何读者都应该按相同顺序看到。

sequenceDiagram
    participant C as 客户端
    participant L as Leader（主库）
    participant F1 as Follower 1（同步副本）
    participant F2 as Follower 2（异步副本）

    C->>L: 写 x = 1
    L->>L: 写本地 WAL 并提交
    L->>F1: 同步复制：等 F1 确认
    F1-->>L: ACK
    L-->>C: 写入成功
    L->>F2: 异步复制：后台慢慢发
    Note over F2: 此时 F2 还是旧值 x = 0<br/>复制延迟窗口
    C->>F2: 读 x
    F2-->>C: x = 0（读到旧数据！）
    Note over C,F2: 这就是"读己之写"被破坏的瞬间

同步 vs 异步是个硬权衡：全同步，任何一个副本宕机写入就卡死；全异步，Leader 宕机时没同步完的写入直接丢失。实践中的折中是"半同步"——一个副本同步、其余异步（MySQL 的 semi-sync 就是这个）。

多主复制：多个节点都能接受写，彼此同步。适合多数据中心就近写入，但写冲突是噩梦——两个机房同时改同一条数据，谁说了算？常见解法：LWW（最后写入者胜，靠时间戳，会丢数据）、CRDT（无冲突数据结构）、应用层解决。CouchDB 走这条路。

无主复制（Dynamo 风格）：没有 Leader，写入时客户端把数据发给 N 个副本中的任意 W 个，读的时候从 R 个里读，只要 W + R > N 就能保证读到最新值（法定人数，quorum）。经典参数 N=3, W=2, R=2。

经典案例：Amazon Dynamo 论文与购物车。2007 年 Amazon 发表 Dynamo 论文，动机极其务实：购物车绝不能拒绝写入——用户加购物车被拒，就是真金白银的损失。所以 Dynamo 选择永远可写（AP），哪怕网络分区时也接受写入，事后再合并冲突版本（著名的"向量时钟"就出自这篇论文）。这篇论文直接催生了 Riak、Cassandra、Voldemort 一整代 NoSQL。

一句话理解：单主是"独裁"，多主是"联邦"，无主是"全民投票"。越民主写入越自由，但事后摆平分歧的成本越高。

6. 分区：数据切蛋糕的两种刀法

单机存不下就分区（分片）。两种切法：

按 key 范围分区：字典式切分，A~~M 一个分区、N~~Z 一个分区。范围查询（“查 7 月的所有订单”）天然高效，但热点问题明显——如果 key 是时间戳，所有新写入全砸在最后一个分区上。Bigtable、HBase 用这套。

按键的哈希分区：key 过一遍哈希函数打散。负载均匀，但范围查询要 scatter-gather 到所有分区，效率骤降。Cassandra、DynamoDB 用这套（Cassandra 实际上是"哈希定分区 + 分区内按 key 排序"的混合体）。

再平衡（rebalancing） 是分区系统真正的试金石：加机器、减机器、某分区过热，数据都要搬家。要求搬家期间读写不停、搬迁量最小。

flowchart LR
    subgraph 扩容前["扩容前：3 节点，每节点 4 个虚拟分区"]
        N1["节点 A<br/>v0 v1 v2 v3"]
        N2["节点 B<br/>v4 v5 v6 v7"]
        N3["节点 C<br/>v8 v9 v10 v11"]
    end
    subgraph 扩容后["扩容后：新节点 D 加入<br/>只搬走 3 个虚拟分区，其余不动"]
        N1b["节点 A<br/>v0 v1 v2"]
        N2b["节点 B<br/>v4 v5 v6"]
        N3b["节点 C<br/>v8 v9 v10"]
        N4["节点 D<br/>v3 v7 v11<br/>（从 A/B/C 各搬一个）"]
    end
    扩容前 -->|"固定数量虚拟分区策略<br/>只迁移少量 vNode"| 扩容后

主流策略就是图里这个：固定数量的虚拟分区（vNode）——分区数远多于节点数，加节点时从每个老节点"匀"几个虚拟分区过来。Riak、Cassandra 都这么干。反例是取模哈希（hash mod N）：节点数一变，几乎全部 key 都要搬家，这就是一致性哈希要解决的原始问题。

避坑指南 2：分区键一旦选定，几乎不可更改。用 user_id 做分区键的系统，后来想做"按时间范围全局扫描"，会发现每个查询都要打满全部分区。选分区键时想清楚：你的主要查询模式是什么，热点在哪。

7. 派生数据：一个数据系统的输出，是另一个系统的输入

Kleppmann 有个非常锋利的视角：缓存、搜索索引、数据仓库，本质上都是派生数据——它们都是从某个"真相源"（source of truth）加工出来的冗余副本。

一旦接受这个设定，很多架构问题豁然开朗：

缓存和数据库不一致？因为派生数据没有和源数据同步更新。
ES 里的搜索结果和 MySQL 对不上？同理。
数仓报表延迟一天？因为派生管道是 T+1 的批处理。

于是问题从"怎么让缓存不失效"变成"派生管道怎么设计"，这正是流处理要回答的，下文第 10 节展开。

第三部分回路：系统怎么自我纠错

存量和流量解决了"存得下、流得动"，剩下的问题是：当多个客户端并发操作、机器会宕机、网络会分区时，系统凭什么保证数据不出错？ 这就是回路——一致性保障与反馈机制。

8. 事务与隔离级别：用"弱隔离"换性能，代价是异常

事务（ACID）是数据库给程序员的最大善意：把一堆操作打包成原子单元，要么全成要么全不成，并发的麻烦我来扛。但"我来扛"是有价格的——严格串行执行性能太差，于是数据库发明了隔离级别这个"滑杆"，让你自己选扛多少：

隔离级别	防住的异常	防不住的异常	谁在用
读未提交	几乎啥都不防	脏读、一切	基本没人用
读提交（RC）	脏读、脏写	不可重复读、写倾斜	Oracle、PostgreSQL 的默认
快照隔离（SI）	上面所有 + 不可重复读	写倾斜	PostgreSQL 的 RR、MySQL InnoDB 的 RR
串行化	一切	无	性能最好时的梦想

快照隔离（Snapshot Isolation） 值得单独说，因为它是现代数据库的主力。原理是 MVCC（多版本并发控制）：每次写入不覆盖旧值，而是生成新版本，每个事务看到"它开始那一刻"的数据快照。读不阻塞写、写不阻塞读，性能极佳。InnoDB 的 undo log、PostgreSQL 的多版本堆表，都是 MVCC 实现。

写倾斜（write skew）是快照隔离最大的盲区，也是面试和实战最容易踩的坑。小例子：医院排班系统要求"至少有一名医生值班"，当前有 Alice 和 Bob 两人值班。两人同时点"请假"：

Alice 的事务读到"2 人值班"，判断"我请假后还剩 1 人，OK"，提交；
Bob 的事务同样读到"2 人值班"（快照！他看不到 Alice 未提交的修改），同样判断 OK，提交；
结果：两人都不值班了，约束被破坏。

注意这不是脏读也不是不可重复读——每个事务内部看到的数据完全一致，但两个事务基于同一份过期前提做出了互相冲突的决定。解法只有：升级到串行化，或者用 SELECT ... FOR UPDATE 物化冲突（把隐含的读前提变成显式行锁）。

避坑指南 3：凡是有"读取一个约束条件，然后据此决定写入"模式的代码（库存扣减、名额抢占、余额校验），在 RR/快照隔离下都可能写倾斜。别指望 ORM 救你，老老实实 FOR UPDATE 或上串行化。

串行化的三条实现路线：

真的串行执行：单线程跑事务（Redis 单线程模型、VoltDB），简单暴力，内存够快时性能惊人；
两阶段锁（2PL）：读写都加锁，性能差但正确，MySQL 的串行化级别就是这么实现的，也是死锁的主要来源；
可串行化快照隔离（SSI）：快照隔离之上检测危险读写依赖，有冲突就中止重试。PostgreSQL 9.1+ 的串行化级别用的就是它，是近几十年事务领域最重要的学术成果落地。

9. 共识与线性一致性：分布式系统的"终极回路"

事务解决的是"单机/单系统内的并发正确性"，共识（consensus）解决的是更难的问题：一群会宕机、消息会延迟的机器，怎么对"某件事"达成一致。

先纠正一个常见混淆：

线性一致性（Linearizability）：让系统表现得"像只有一份数据"——任何人读到 x=1 之后，不可能再读到 x=0。它是对单个对象的读写一致性承诺。
共识（Consensus）：多个节点对某个值/某条决策达成不可逆的一致，典型算法 Paxos、Raft、Zab。

两者的关系：要实现线性一致的存储，背后几乎必然要靠共识算法选主或定序。ZooKeeper（Zab）、etcd（Raft）就是共识系统的工业代表，整个 Kubernetes 的正确性底座就是 etcd 里的那套 Raft。

经典案例：Google Spanner 与 TrueTime。Spanner 要在全球范围提供外部一致性（比线性一致更强，跨事务的全局顺序），最大的拦路虎是：分布式系统里各机器时钟不可靠，你没法靠时间戳判断两个事务谁先谁后。Google 的解法粗暴而硬核——给数据中心装 GPS 接收机和原子钟，把时钟误差压缩到一个已知的小区间（TrueTime API 返回的不是一个时间点，而是"真实时间必然落在的这个区间"）。提交事务时，如果发现误差区间还没过去，就故意等待（commit wait）直到确定。用硬件换确定性，用等待换正确性——这是"回路强度可以花钱买"的最著名示范。

FLP 不可能定理泼一盆冷水：在纯异步网络里，哪怕只有一台机器可能崩溃，也不存在确定性的、保证能终止的共识算法。工程上的出路是引入"部分同步"假设（网络总会恢复）和超时机制——所以 Raft/Paxos 的正确性不依赖时钟，但活性（liveness，能不能往前走）依赖。

极端案例：比特币与拜占庭容错。上面说的共识算法都假设节点"可能宕机但不会撒谎"（崩溃容错 CFT）。比特币面对的是更恶劣的环境：节点可能作恶（拜占庭将军问题）。中本聪的解法是放弃确定性共识，改用工作量证明（PoW）+ 最长链规则做概率性共识——一笔交易等 6 个区块确认，被推翻的概率指数级下降但永不为零。性能极差（比特币全网约 7 TPS，对比 Visa 峰值数万 TPS），换来的是"无许可环境下没人能篡改历史"。这是把回路强度推到极限、把流量吞吐牺牲殆尽的极端案例，也完美印证了我们的框架：一切都是权衡。

共识落地前，还有个更现实的问题：故障检测。分布式系统判断"某节点死了"的唯一办法是超时——但超时无法区分"节点真死了"和"节点只是 GC 停顿了 30 秒"（Java 应用的 Full GC、虚拟机的 steal time、网络拥塞都会造成这种"假死"）。于是就有了脑裂（split-brain）：老 Leader 以为自己还是 Leader，新 Leader 已经被选出来，两个"主"同时接受写入，数据互相覆盖。

工程解法是 fencing token（防护令牌）：每次选主，共识系统发一个单调递增的编号，存储层只接受"编号比上次大"的写入。老 Leader 拿着旧编号来写，直接被拒。这个小机制在 ZooKeeper（zxid）、etcd（revision）里都有对应物。

业界掌故：Kleppmann 本人就是分布式锁话题的"圈内名人"——2016 年他发文《How to do distributed locking》批判 Redis 的 Redlock 算法在时钟跳变和进程暂停下不安全，引来 Redis 作者 antirez 的公开反驳，两人来回论战了好几轮，成为分布式领域最著名的公开辩论之一。争论的核心正是上面这些：时钟不可信、暂停不可测，所以任何分布式锁要么上 fencing token，要么干脆用共识系统。

10. 批处理 vs 流处理：同一枚硬币的两面

最后回到流量，看数据处理的两种世界观：

批处理：数据是有界的——一堆文件摆在那，MapReduce/Spark 跑一遍，输出结果。优点是吞吐高、可重跑、容错简单（任务挂了重跑）；缺点是延迟以小时计。Hadoop/MapReduce 的黄金时代（Google 2004 年论文、Yahoo 孵化 Hadoop）就是这套世界观。
流处理：数据是无界的——事件源源不断地来，Kafka + Flink/Storm 逐条处理，延迟毫秒级。难点：乱序、恰好一次语义（exactly-once）、容错状态恢复。

Lambda 架构：流处理快但不准（可能丢、可能重复），批处理准但慢，那就两条都跑——流处理给实时近似结果，批处理定期用精确结果覆盖。维护两套系统、两份代码，运维成本翻倍，是出名的"说起来美、做起来痛"。

Kappa 架构：LinkedIn 的 Jay Kreps（Kafka 作者）提出的简化——只要流处理一条腿。历史数据重算？把 Kafka 的日志保留期拉长，让流处理程序从头重放一遍就行。这个架构能成立的前提，是 Kafka 把"消息队列"做成了"可重放的日志存储"。

flowchart TD
    subgraph 数据源
        DB[("业务数据库<br/>MySQL")]
        APP["应用事件"]
    end
    DB -->|"CDC 变更数据捕获<br/>（Debezium 监听 binlog）"| K["Kafka<br/>（可重放的日志存储）"]
    APP --> K
    K --> S["流处理引擎<br/>Flink / Kafka Streams"]
    S --> V1["派生视图：缓存 Redis"]
    S --> V2["派生视图：搜索索引 ES"]
    S --> V3["派生视图：数仓 ClickHouse"]
    K -->|"日志长期保留<br/>需要重算时从头重放"| S
    subgraph KP["Kappa / 批流一体"]
        S
    end

这张图里藏着 DDIA 全书最重要的思想之一：数据库和消息队列正在融合。Kafka 是可以当数据库用的日志（有保留期、可重放、有流处理）；反过来，数据库的 binlog/WAL 通过 CDC（Change Data Capture）技术流出来，就变成了消息流。Debezium 监听 MySQL binlog 把每一次行变更变成 Kafka 消息，是当下"派生数据管道"的标准做法。

经典案例：Kafka 从 LinkedIn 内部管道到行业标准。Kafka 诞生时（2010 年前后）只是 LinkedIn 内部的一个活动流（activity stream）和日志管道，目标是扛住"每个用户的每个页面浏览都要记录"的巨大流量。它的关键设计——把消息组织成分区有序日志、消费者自己维护 offset、依赖磁盘顺序写+page cache 而非内存——让它意外地发现：这个东西不只是消息队列，而是"以日志为中心的存储系统"。Confluent 成立后，Kafka 成了流处理事实标准，Kreps 那篇《The Log: What every software engineer should know about real-time data’s unifying abstraction》（2013）把"日志是数据系统统一抽象"的思想讲透了——和 DDIA 第 3 章"日志结构存储"一脉相承。

11. 全书串讲：用三个词复盘四个案例

现在用"存量、流量、回路"的框架，把本文案例快速过一遍，你会发现它们只是同一个框架的不同参数组合：

Kafka：存量用顺序日志（LSM 的近亲），流量靠分区+副本，回路选择"至少一次/恰好一次可配"的务实路线。→ 流量优先，回路可调。
Dynamo：无主复制+永远可写，回路是最终一致+应用层冲突解决。→ 流量（可用性）压倒一切，回路最弱。
Spanner：全球分区+同步复制，回路用 TrueTime 堆到最强（外部一致性）。→ 回路优先，花钱买。
比特币：回路要求拜占庭容错（最强敌对环境），代价是吞吐 7 TPS。→ 回路极限，流量牺牲殆尽。

没有银弹，只有取舍。 这就是 Kleppmann 反复想说、而无数"中间件选型指南"不会告诉你的事。

12. 带走的清单

读完 DDIA，做系统设计时问自己这几句话：

存量三问

写入多还是读取多？写多读少看 LSM（RocksDB/Cassandra），读多写少看 B-Tree（MySQL），分析查询上列存（ClickHouse/Parquet）。
崩溃恢复靠什么？找到那个 WAL——它一定存在，可能只是叫别的名字（redo log / AOF / binlog / journal）。
schema 演进支持双向兼容吗？向前向后都要，滚动升级时缺一不可。

流量三问

复制延迟用户能感知吗？能，就按需要补读己之写、单调读、一致前缀读，别等用户来报 bug。
分区键选对了吗？对照主要查询模式和热点，选错分区键≈架构重来。
缓存/索引/数仓是不是派生数据？是，就把"同步管道"当成一等公民来设计（CDC + 流处理），而不是事后打补丁。

回路三问

业务能容忍什么级别的一致性？能用最终一致就别上线性一致，省下的都是真金白银。
有没有"读约束再写入"的代码？有，检查写倾斜——FOR UPDATE 或串行化，二选一。
选主/分布式锁靠什么？别自己造轮子，ZooKeeper/etcd 这类共识系统才是正解（Redis 分布式锁的争议——Martin Kleppmann 本人就是那篇著名批判文章《How to do distributed locking》的作者，还设计了"马丁小花"fencing token 方案）。

最后的避坑清单

别把默认隔离级别当成"安全级别"——PostgreSQL/MySQL 的默认都不是串行化，写倾斜在看着你。
别迷信"分布式 = 高可用"——复制和分区引入的故障模式（脑裂、时钟漂移、复制滞后）比单机复杂一个数量级，Jepsen 测试报告（Kyle Kingsbury 对各大数据库的"虐测"）里全是血泪。
别在不了解权衡时引用 CAP——CAP 只说"网络分区时一致性和可用性二选一"，而网络不分区时你还有延迟与一致性的权衡（PACELC 才是完整版）。
时间不可信：进程会 GC 暂停、线程会被调度、时钟会跳变。所有依赖"本地时钟先后关系"的分布式逻辑都值得怀疑——这正是 Spanner 要装原子钟的原因。

13. 结语：野猪书为什么是神书

市面上讲分布式的书，要么讲理论（一堆证明，读完不会写代码），要么讲产品（一堆配置，换个组件就过时）。DDIA 恰好卡在中间：它讲的是"不会过时的权衡"。

LSM 和 B-Tree 的取舍，二十年前成立，二十年后还会成立；复制滞后引发的那些"诡异现象"，今天在 MySQL 从库上出现，明天就会在你的新数据库上换个马甲出现。工具会死，权衡永存。

顺带给个阅读路径建议：这本书 12 章不必按顺序啃——

日常写业务代码的：先读第 3 章（存储引擎）、第 7 章（事务），性价比最高；
做中间件/基础架构的：第 5、6 章（复制、分区）和第 9 章（共识）是主菜；
做数据平台/实时数仓的：第 10、11 章（批处理、流处理）直接对口；
第 8 章（分布式系统的麻烦）建议所有人都读，它是全书"劝退幻想"的一章，读完你会对时钟和网络产生健康的怀疑。

用一句话收尾，也是这本书给我最大的思维升级：

不要问"这个系统支持什么特性"，要问"这个系统在存量、流量、回路上各做了什么取舍，这些取舍和我的业务匹配吗"。

能问出这个问题，这本书就没白读。

《软件架构：最难的部分》详解：分布式架构的权衡分析实战指南

Wed, 26 Jul 2023 14:00:00 +0800

《软件架构：最难的部分》详解：分布式架构的权衡分析实战指南

《软件架构：最难的部分》（Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures）是 O’Reilly 在 2021 年出版的一本架构书，四位作者都是业内响当当的人物：Neal Ford（《软件架构 fundamentals》作者之一）、Mark Richards（资深架构师、《软件架构 fundamentals》合著者）、Pramod Sadalage（数据库演进专家）和 Zhamak Dehghani（“数据网格"概念的提出者）。

这本书回答了一个非常现实的问题：

当我把一个单体系统拆成微服务时，每一步到底该怎么拆？怎么知道拆得对不对？

市面上的架构书大多告诉你"什么是好架构”，却很少教你"做决策的过程"。这本书补上了这块空白。它的核心立场是：架构里不存在"最佳实践"，只存在"权衡分析"（Trade-off Analysis）。每一个决策都是在拿一些东西换另一些东西，架构师的工作就是把交换的条件摆清楚。

本文面向从未接触过软件架构概念的读者，按全书十五章的顺序逐层展开，配合图解和实例，帮你建立完整的知识地图。

第 1 章当没有"最佳实践"时会发生什么

一切皆权衡

作者开篇就泼了一盆冷水：如果有人问你"微服务和单体哪个好"，唯一正确的回答是——看情况。

架构决策和买东西很像。假如有人不问预算、不问用途，直接告诉你"买这辆车是最好的"，你肯定会觉得他不靠谱。架构也一样：任何脱离上下文的"最佳实践"都是耍流氓。架构师真正的工作流程是：

找到决策涉及的各个维度（性能、成本、耦合度、团队结构……）；
分析每个维度上的得与失；
把分析结果呈现给利益相关者，让他们在知情的情况下做选择。

所以这本书的副标题才是"现代分布式架构的权衡分析"——最难的部分不是技术本身，而是权衡。

贯穿全书的案例：Sysops Squad 工单系统

为了方便讲解，作者虚构了一个贯穿全书的案例。Sysops Squad 是一家 IT 运维支持公司，客户（通常是企业的 IT 部门）遇到设备故障时提交工单（Ticket），系统把工单分配给合适的运维专家（Sysop），专家上门或远程修复，完成后填写处理报告。

他们现在用的是一个大单体应用，随着业务增长越来越痛苦：改一个小功能要全量发布、一个模块的 bug 拖垮整个系统、高峰期扩容只能整体扩容。于是团队决定把它拆成微服务——这本书讲的就是这一路上遇到的每一个"难啃的骨头"。

flowchart LR
    subgraph 拆分前["拆分前：单体应用"]
        M["Sysops Squad 单体系统<br/>工单 + 用户 + 派单 + 报告 + 计费<br/>共享一个大数据库"]
    end
    subgraph 拆分后["拆分后：微服务"]
        A["工单服务"]
        B["用户服务"]
        C["派单服务"]
        D["报告服务"]
        E["计费服务"]
        DB1[("工单库")]
        DB2[("用户库")]
        DB3[("派单库")]
        DB4[("报告库")]
        DB5[("计费库")]
        A --- DB1
        B --- DB2
        C --- DB3
        D --- DB4
        E --- DB5
    end
    拆分前 -->|本书要讲的全过程| 拆分后

看起来很美好对吧？但魔鬼全在细节里：组件怎么划？数据库怎么拆？服务粒度多细合适？公共代码怎么办？跨服务的事务和数据访问怎么办？——这些就是后面十四章要逐一解决的问题。

第 2 章识别软件架构中的耦合

架构量子（Architecture Quantum）

这是全书最重要的概念之一，也是后续所有分析的基本单位。

架构量子：系统中可以独立部署的最小单元，包含它正常运行所必需的一切（代码、数据库、配置等）。

判断一个东西是不是一个架构量子，问三个问题：

能独立部署吗？（改完它不用动别的部分就能上线）
功能内聚性高吗？（它内部的代码是围绕同一个业务目标组织的）
耦合度高吗？（量子内部耦合高没关系，量子之间耦合低才是目标）

一个单体应用就是一个架构量子；一套拆得干净的微服务，每个服务各自是一个量子；而"服务拆了但数据库还共享"的系统，量子边界其实还卡在数据库上——这是新手最容易掉进去的坑。

静态耦合与动态耦合

静态耦合：编译期/部署期就能看到的依赖。比如 A 服务调用了共享库里的类，或者两个服务连同一个数据库 schema。
动态耦合：运行时才发生的调用关系。比如订单服务运行时调用支付服务的接口。

动态耦合由三个维度决定，这是全书反复使用的分析框架：

维度	两个选项	权衡点
通信（Communication）	同步 / 异步	同步简单直观，异步解耦但复杂
一致性（Consistency）	原子 / 最终	原子一致安全，最终一致可用性高
协调（Coordination）	编排 / 编制	编排好管理，编制无中心瓶颈

这三个维度像调色盘的三原色，后面讲工作流（第 11 章）和 Saga（第 12 章）时会反复用到。

第 3 章架构模块化

为什么要模块化？作者给出了五个驱动力，每一个都对应一种"不模块化会疼"的场景：

可维护性（Maintainability）：大泥球代码改一处坏三处，模块化让改动范围可控。
可测试性（Testability）：边界清晰的模块可以单独写测试，不用拉起整个系统。
可部署性（Deployability）：小模块发布风险低、频率高；单体发布一次像发射火箭。
可扩展性（Scalability）：旺季只有"下单"需要扩容，模块化后可以只扩这一个模块。
可用性与容错（Availability/Fault Tolerance）：故障被限制在模块内部，不至于全站瘫痪。

举个生活化的例子：老式组合音响里一个喇叭坏了，整台机器都得拆开修；而现在的家庭影院，功放、音箱、播放器各自独立，坏哪个换哪个——这就是模块化的价值。

第 4 章架构分解

拆分之前，先要学会"测量"耦合，而不是凭感觉。

传入耦合与传出耦合

传入耦合（Afferent Coupling）：有多少别的组件依赖我？——衡量"我有多重要、改动我的风险有多大"。
传出耦合（Efferent Coupling）：我依赖多少别的组件？——衡量"我有多容易被别人拖累"。

主序列距离（Distance from the Main Sequence）

这是 Robert C. Martin 提出的一组度量。想象一条坐标轴：横轴是抽象性（组件里抽象类/接口占的比例），纵轴是不稳定性（传出耦合占比）。

一个组件如果很具体但很多人依赖它（比如工具类被全系统引用），它落在"痛苦区"：难改、一改全崩。
一个组件如果很抽象但没人用（比如过度设计的框架），它落在"无用区"。
理想位置在两者之间的对角线（“主序列”）附近。

这些度量不是让你拿计算器天天算，而是提供一个客观的拆分依据：拆分候选的组件，先看它们的耦合度量，优先拆那些传入传出耦合低、边界清晰的——它们是"最容易摘下来的果子"。

第 5 章基于组件的分解模式

这是全书最"实操"的一章：怎么把一坨单体代码拆成组件？作者给出了一个六步流水线，每一步都有对应的"适应度函数"（自动化检查规则）来保证不跑偏。

flowchart TD
    S1["① 识别并确定组件大小<br/>盘点代码库里有哪些组件、各占多大比例"]
    S2["② 收集公共组件<br/>把多个组件里重复出现的代码收拢到一处"]
    S3["③ 扁平化组件<br/>把代码从根命名空间下沉到有明确职责的叶子节点"]
    S4["④ 确定组件依赖<br/>画出组件依赖图，找出纠缠在一起的循环依赖"]
    S5["⑤ 创建组件域<br/>把职责相近的组件归入同一个领域分组"]
    S6["⑥ 创建领域服务<br/>每个领域组对外暴露成一个粗粒度服务"]
    S1 --> S2 --> S3 --> S4 --> S5 --> S6

几个步骤的直觉解释：

第①步像搬家前盘点家当：先知道自己有什么。适应度函数可以自动检查"任何组件不得超过代码库总量的 X%"、“组件大小不得偏离平均值 N 个标准差”，防止拆出巨型组件。
第②步解决重复：如果"日志工具"“日期处理"在十个组件里各抄了一份，先把它们收拢，否则拆开后会十处同步改。
第③步针对一种常见病：大量代码堆在根命名空间（比如所有代码都在 com.sysops 下面不分层），说明系统从来没有真正的结构，必须先给每段代码找到归属。
第④步是分水岭：依赖图里纠缠不清的组件（A 调 B、B 调 C、C 又调 A）说明领域边界划分有误，要回到业务层面重新划。
第⑤⑥步完成从"代码组件"到"业务服务"的跃迁：同一域内的组件将来部署成一个服务，域与域之间的边界就是服务边界。

**适应度函数（Fitness Function）**是本书反复强调的治理手段：把架构约束写成自动化测试，放进 CI 流水线。比如"报告域的组件不允许依赖计费域的组件"可以直接写成一条 ArchUnit 测试，谁违反了构建就失败——架构约束从"文档里的愿望"变成"会报警的护栏”。

第 6 章拆分运营数据

代码拆完，真正的硬骨头来了：数据库。很多团队服务拆得很漂亮，底下却还用同一个数据库——等于楼分了户、水电还是一户一表，根本没有真正解耦。

拆开数据库的推力与阻力

作者在拆数据这件事上建立了一个"天平"模型：

拆分驱动因素（Data Disintegrators，推着你拆）：

变更控制：一个服务改表结构，不用和别的团队协调。
连接管理：数据库连接数有限，服务多了必须分库。
可扩展性：可以按服务单独扩容数据库。
容错：一个库挂了只影响一个服务。
架构量子：共享数据库会把量子边界撑破。
数据库类型优化：不同服务适合不同数据库（工单用关系库，日志用时序库）。

整合因素（Data Integrators，拽着你不让拆）：

数据关系：外键、JOIN 在跨库之后全部失效。
数据库事务：跨库没有 ACID 事务，必须面对分布式事务的复杂性。

五步数据库分解法

书里给出了一个务实的渐进式拆分流程，核心思想是"先逻辑拆，再物理拆"：

flowchart LR
    P1["① 分析数据库<br/>划分数据域"]
    P2["② 把表分配到<br/>各数据域"]
    P3["③ 数据库连接<br/>按域分离"]
    P4["④ Schema 迁移到<br/>独立数据库服务器"]
    P5["⑤ 切换到完全独立的<br/>数据库"]
    P1 --> P2 --> P3 --> P4 --> P5

关键是第③步：表还没物理分开，就先让各服务只连自己的 schema、只访问自己的表。这一步不动数据，只动代码和连接，风险小、可回滚。等代码层面确认拆分正确了，再做物理迁移（第④⑤步）。这种"小步快跑、每步可退"的思路贯穿全书。

第 7 章服务粒度

拆服务时最纠结的问题：一个服务到底该多大？

作者又祭出了"天平"分析法——这次叫粒度解耦因素（Granularity Disintegrators，推着你往细拆）与粒度整合因素（Granularity Integrators，拽着你往粗合）。

往细拆的理由（Disintegrators）：

服务范围与功能：一个服务只干一件事。
代码波动性：如果系统里"促销规则"每周改、“订单核心"半年不动，就该把促销拆出去，免得高频改动反复惊扰稳定部分。
可扩展性与吞吐量：只有搜索服务需要扛流量，拆细了才能单独扩容。
容错：非关键功能（比如推荐）挂了不该拖垮下单。
安全：处理支付的服务需要更高的安全等级和审计，独立出来好管控。
可扩展性（Extensibility）：新功能以新服务的形式生长，不改老代码。

往粗合的理由（Integrators）：

数据库事务：两个操作必须在同一个 ACID 事务里？那它们最好待在同一个服务里。
工作流与编制：跨服务的编排/编制又慢又难调试，粒度太细会制造大量分布式工作流。
共享代码：两个服务共享大量代码，可能说明它们本来就该是一个。
数据关系：两个服务频繁访问彼此的数据，拆分带来的网络开销和一致性成本可能超过收益。

实例：Sysops Squad 拆出"工单服务"后，争论要不要把"工单指派"再拆成独立服务。分析后发现：指派逻辑改动频繁（每周调规则）、需要单独的弹性伸缩（早高峰派单量是平时的 5 倍）——两个 disintegrator 都很强；而它与工单共享的表只有一张、没有跨库事务需求——integrator 很弱。于是拆。反过来，“工单备注"功能没有任何独立的扩展和发布需求，就留在工单服务里。

这就是权衡分析的样子：不是数哪边的理由多，而是掂量哪边的理由重。

第 8 章复用模式

多个服务都需要同一段代码（比如审计日志、认证），怎么办？书里给了四种方案：

模式	做法	优点	缺点
代码复制	每个服务拷一份	零耦合、零依赖	改 bug 要改 N 处
共享库	打成 jar/npm 包共用	版本可控、无运行时开销	版本地狱、异构技术栈难共享
共享服务	独立部署一个公共服务	改动一处全生效、跨语言	网络开销、单点风险、变更影响面大
Sidecar / 服务网格	功能放进每个服务的伴生容器	跨语言、运维统一	需要容器编排基础设施

选择思路很直接：变化越频繁、越偏向业务的代码，越不要共享（宁肯复制）；越稳定、越偏向技术基础设施的能力（日志、监控、鉴权），越适合共享或 Sidecar。

实例：Sysops Squad 的"专家评分算法"每个服务都在用，但它每月都在调优——选了代码复制，各服务按需演进。而"日志采集"用了 Sidecar，统一由运维团队维护。

第 9 章数据所有权与分布式事务

拆库之后立刻撞上两个难题：一张表被两个服务都要写，归谁？一个业务操作要跨两个服务写数据，怎么保证一致性？

数据所有权

先看所有权的两种场景：

单一所有权：一张表只有一个服务写，其他服务最多只读——理想情况。
共同所有权：多个服务都要写同一张表——必须拆开归属。

处理共同所有权有三种技术：

flowchart TD
    subgraph 表拆分技术["表拆分：按列拆开"]
        T1["customer 表<br/>姓名/联系方式 → 档案服务<br/>信用额度/账单地址 → 计费服务"]
    end
    subgraph 数据域技术["数据域：按行拆开"]
        T2["ticket 表<br/>进行中的工单 → 工单服务<br/>已归档的历史工单 → 报告服务"]
    end
    subgraph 委派技术["委派：一主一从"]
        T3["invoice 表归计费服务所有<br/>工单服务需要时<br/>通过接口委托计费服务写"]
    end

分布式事务的三种模式

跨服务更新数据时，怎么保持一致？

后台同步模式：先各自写，后台进程定时对账、修复不一致。最简单，但不一致窗口最长，适合对实时性无所谓的数据（比如统计报表）。
编排请求模式：由一个编排者按顺序调用各服务，全部确认后才算完成。一致性好，但慢，且编排者成了耦合中心。
基于事件的模式：写本地库后立刻发事件，其他服务异步消费。性能和可用性最好，但要想清楚"事件丢了怎么办”。

实例：工单完成后要同时更新"工单状态"和"专家积分”。如果用编排请求，用户要等两个服务都响应；用事件模式，工单服务先发 TicketCompleted 事件立即返回，积分服务异步加分——用户快了几百毫秒，代价是积分查询页面可能晚几秒才更新。Sysops Squad 选了后者：最终一致性换了响应速度。

第 10 章分布式数据访问

读操作比写操作更常见：服务 A 需要服务 B 拥有的数据，怎么拿？四种模式：

服务间通信：直接调 B 的接口。最简单，但每次查询都是一次网络往返，B 挂了 A 也查不了。
列模式复制：把需要的那几列数据复制一份到 A 的数据库（通过消息保持同步）。查询快、无运行时依赖，但数据有延迟、要处理重复治理。
复制缓存：B 把数据推进共享缓存（如 Redis），A 从缓存读。适合读多写少的参考数据。
数据域：把双方都要的数据干脆划给一个专门的"数据域服务"管理。

选择的关键问题是："这份数据 A 需要多新鲜？B 的可用性 A 能承受吗？“答案不同，模式就不同。比如专家的联系信息（几乎不变）适合复制缓存；工单的实时状态（必须最新）只能走服务间通信。

第 11 章管理分布式工作流

一个业务流程跨多个服务时，谁来当"导演”？两种风格：

flowchart TD
    subgraph 编排["编排 Orchestration：有个总指挥"]
        O["编排者<br/>（工单流程服务）"]
        O --> A["工单服务"]
        O --> B["派单服务"]
        O --> C["计费服务"]
        O --> D["通知服务"]
    end

flowchart LR
    subgraph 编制["编制 Choreography：舞者跟着音乐各自起舞"]
        A2["工单服务"] -->|发事件| B2["派单服务"]
        B2 -->|发事件| C2["计费服务"]
        C2 -->|发事件| D2["通知服务"]
    end

编排（Orchestration）：设一个中心编排者，像乐队指挥，告诉每个服务"现在该你了"。流程一目了然、好监控、好报错；但编排者容易变成新的"小单体"，且是所有服务的耦合点。
编制（Choreography）：没有中心，每个服务监听事件、做完自己的事再发下一个事件，像舞者跟着音乐即兴配合。极度解耦、无单点；但流程分散在各处，“现在进行到哪一步了"这种简单问题都很难回答。

还有一个关键细节：**工作流状态放哪？**编排模式下状态天然在编排者手里；编制模式下要么设一个专门的"状态所有者"服务，要么忍受状态分散的痛苦。

经验法则：流程复杂、分支多、需要人工介入补偿的，用编排；流程线性、追求吞吐量的，用编制。

第 12 章事务性 Saga

Saga 是分布式世界里替代 ACID 事务的方案：把一个跨服务的大事务拆成一串本地小事务，任何一步失败就按相反顺序执行补偿操作（退款、释放库存……）回滚已完成的步骤。

书里把第 2 章的三个维度组合起来，给 Saga 模式起了八个别致的名字（括号里的三个字母依次代表：一致性 a=原子/e=最终、通信 s=同步/a=异步、协调 o=编排/c=编制）：

模式	组合	适用场景
史诗 Saga（a,s,o）	原子+同步+编排	最接近传统事务，但分布式环境下最难实现
电话接龙 Saga（a,s,c）	原子+同步+编制	既要原子性又不想有中心——又慢又脆，慎用
童话 Saga（e,s,o）	最终+同步+编排	简单好用的常见选择
时间旅行 Saga（e,s,c）	最终+同步+编制	高并发下的妥协方案
奇幻小说 Saga（a,a,o）	原子+异步+编排	用异步提高吞吐，靠编排守住一致性
恐怖故事 Saga（a,a,c）	原子+异步+编制	作者直言：别这么干
平行 Saga（e,a,o）	最终+异步+编排	最实用的组合之一
文集 Saga（e,a,c）	最终+异步+编制	最解耦、最高可用，也最难调试

起这些"俗气"的名字是故意的：好记。团队讨论时说"这个流程用文集模式”，比说"最终一致+异步通信+编制协调的 Saga"高效得多。

核心结论：越往左（原子一致），越安全越慢越脆；越往右（最终一致+异步+编制），越快越抗造，但你要为"中间状态"和"补偿逻辑"付出工程成本。没有免费的午餐，只有明摆着的账单。

第 13 章契约

服务之间的接口约定（Contract）该多严格？

严格契约：字段类型、格式全部写死并强校验（如带 schema 的 RPC）。好处是错误在编译/调用瞬间就暴露；代价是任何字段变更都要双方同时升级，耦合很紧。
宽松契约：只约定必需字段，其余自由扩展（如 JSON + 约定）。灵活、可独立演进；代价是错误可能潜伏到运行时才爆发。

还有两个进阶概念：

消费者驱动的契约（Consumer-Driven Contracts）：由服务的调用方写下"我需要这些字段、这种格式"，作为测试放进提供方的流水线。提供方一改接口，立刻知道会弄坏谁——契约从"提供方说了算"变成"对消费者负责"。
戳记耦合（Stamp Coupling）：调用时把一大坨数据结构整个传过去（比如把 50 个字段的 Customer 对象传给只需要 email 的服务）。对方被迫依赖整个结构的形状，改任何一个字段都可能波及无辜。只传对方真正需要的字段。

第 14 章管理分析型数据

运营数据（支撑业务运转）拆给了微服务，那分析数据（做报表、跑 BI、训练模型）怎么办？作者梳理了三代方案：

flowchart LR
    DW["数据仓库<br/>ETL 抽取 → 清洗 → 集中存储<br/>结构化、为报表优化"] --> DL["数据湖<br/>原始数据先倒进去<br/>用的时候再处理<br/>灵活但容易变成数据沼泽"] --> DM["数据网格<br/>按领域分布式的数据产品<br/>数据像微服务一样被治理"]

**数据网格（Data Mesh）**是本章的高潮，也是作者之一 Zhamak Dehghani 原创的概念。它的核心思想是把微服务的哲学搬到数据世界：

领域拥有数据：工单团队对自己的工单数据负责，而不是甩给中央数据团队。
数据即产品：数据要有明确的接口、质量承诺、文档，像 API 一样被消费。
自助式数据平台：基础设施团队提供平台，领域团队自助发布数据产品。
联邦式治理：全局规则（隐私、安全）统一，领域内部自治。

作者也诚实地给出了"什么时候不要用数据网格"：团队小、数据量不大、分析需求简单时，一个数据仓库就够了——架构量子越少越好，够用就行。

第 15 章构建你自己的权衡分析

最后一章是方法论总结：这套"天平分析"手艺怎么用到自己的项目里？

几条核心建议：

找出纠缠的维度：性能和安全往往互相拉扯，先把一个决策涉及的所有维度列出来。
用 MECE 原则列清单：相互独立、完全穷尽，避免漏掉某个维度的代价。
警惕"脱离上下文"的陷阱：网上说"Netflix 用了 X 架构所以 X 好"——Netflix 的上下文（规模、团队、预算）和你完全不同，结论不能直接搬。
定性分析优先于定量：很多时候没法拿到精确数字，用"高/中/低"的比较级就够做决策了，别为了伪精确而瘫痪。
只给结论，别淹没听众：给业务方汇报时，先说"推荐方案 B，因为……"，细节放附录。
远离蛇油和布道：任何声称"无条件最优"的方案（银弹、框架布道者），默认先怀疑。

全书总结：一张权衡分析的思维导图

mindmap
  root((软件架构<br/>最难的部分))
    核心理念
      没有最佳实践
      一切皆权衡
      架构量子是分析单位
    怎么拆
      组件分解六步法
      数据库五步分解
      粒度天平
        Disintegrators 往细拆
        Integrators 往粗合
    拆完怎么办
      复用四模式
      数据所有权
      分布式数据访问
    跨服务协作
      编排 vs 编制
      八种 Saga
      严格 vs 宽松契约
    数据与分析
      数据仓库/湖
      数据网格
    方法论
      适应度函数
      MECE 分析
      警惕脱离上下文

这本书最有价值的不是任何一条具体结论，而是它示范的思考方式：面对任何架构决策，先问"这个选择让我得到什么、失去什么"，把天平两端的砝码摆出来，再结合自己的上下文做判断。

如果你是架构新手，建议阅读顺序是：先读第 1、2 章建立"权衡"和"架构量子"的心智模型，再读第 5、6、7 章学会"拆"，最后按需查阅第 8–14 章解决"拆完之后"的具体问题。第 15 章适合放在手边，每次做重大技术选型前翻一遍——它会让你少交很多学费。

《Elasticsearch 权威指南》详解：零基础读懂 ES 的核心知识体系

Sat, 20 Jun 2020 09:00:00 +0800

《Elasticsearch 权威指南》详解：零基础读懂 ES 的核心知识体系

《Elasticsearch 权威指南》（Elasticsearch: The Definitive Guide，Clinton Gormley & Zachary Tong 著）是学习 Elasticsearch 公认的第一本书。中文版由 looly 等人组织社区翻译。它不是 API 手册，而是沿着"为什么这样设计“的路线，把 ES 从安装、文档 CRUD 一路讲到分布式内核、分词、相关性算分和集群运维。

这本书基于 ES 1.x/2.x 时代写成，个别细节（如 type 概念、TF/IDF 默认评分）在新版本有变化，但核心思想至今不变。本文面向从未读过这本书的人，按"基础概念 → 分布式原理 → 搜索 → 语言处理 → 聚合 → 建模 → 运维"的顺序完整梳理，配图解和可直接运行的实例。

一、Elasticsearch 是什么：先建立直觉

书的开篇用一句话定义 ES：

Elasticsearch 是一个分布式的、实时的文档存储与搜索引擎，基于 Apache Lucene 构建，通过 RESTful API 暴露 Lucene 的全部威力。

Lucene 本身是一个 Java 搜索库，强大但难用——ES 的价值在于把 Lucene 包装成一个可以水平扩展、开箱即用的分布式系统。书中列举的典型用户包括 Wikipedia（全文搜索 + 高亮 + 输入即搜 + 拼写纠错）、GitHub（检索 1300 亿行代码）、StackOverflow（“你可能想问"的 more-like-this 推荐）。

与关系型数据库的概念对照（这是全书最重要的入门表格）：

关系型数据库	Elasticsearch	说明
Database（库）	Index（索引）	逻辑命名空间
Table（表）	Type（类型）	⚠️ 新版已废弃，理解旧书时需要
Row（行）	Document（文档）	一条 JSON 记录
Column（列）	Field（字段）	文档的属性
Schema（表结构）	Mapping（映射）	字段类型定义
SQL	Query DSL	查询语言
index（索引，动词）	index（索引，动词）	把文档写入

关键区别：数据库假设"每行结构相同”，ES 的文档是无模式的 JSON（虽然实际上有 mapping 约束）；数据库为"精确存取"优化，ES 为”相关性检索“优化——它回答的问题不是"有没有”，而是"有多相关"。

1.1 十分钟跑起来：书中的第一个例子

全书第一章用一家虚构公司 megacorp 的员工数据贯穿：

# 写入一个员工文档（PUT = 指定 ID 创建/覆盖）
PUT /megacorp/employee/1
{
  "first_name": "John",
  "last_name":  "Smith",
  "age":        25,
  "about":      "I love to go rock climbing",
  "interests": ["sports", "music"]
}

# 取回（GET）
GET /megacorp/employee/1

# 轻量搜索：查询字符串
GET /megacorp/employee/_search?q=last_name:Smith

# 正式搜索：Query DSL（JSON 请求体）
GET /megacorp/employee/_search
{
  "query": { "match": { "last_name": "Smith" } }
}

注意这里没有建库、没有建表、没有定义字段类型——这就是"无模式"体验。但书里马上提醒：无模式是假象，ES 在背后做了动态映射（dynamic mapping），第一次见 "age": 25 就推断 age 是 long。生产环境应该显式定义 mapping（第四章详解）。

1.2 一个展示"相关性"的例子

GET /megacorp/employee/_search
{
  "query": {
    "bool": {
      "must":     { "match": { "about": "rock climbing" } },
      "filter":   { "range": { "age": { "gt": 30 } } }
    }
  }
}

返回结果中每个文档带一个 _score（相关性得分），按得分降序排列。must 里的 match 参与算分，filter 里的 range 只过滤不算分——这是全书反复出现的 query/filter 二分法，第六章详解。

二、分布式内核：ES 为什么能水平扩展

这是全书的硬核部分，也是 ES 区别于"单机 Lucene"的根本。

2.1 集群、节点与分片

graph TB
    subgraph CLUSTER["集群 cluster（一个 cluster.name）"]
        N1["节点 Node 1<br/>（一个 ES 进程）"]
        N2["节点 Node 2"]
        N3["节点 Node 3"]
    end
    subgraph IDX["索引 blogs（3 主分片 × 1 副本）"]
        P0["主分片 P0"] --- R0["副本分片 R0"]
        P1["主分片 P1"] --- R1["副本分片 R1"]
        P2["主分片 P2"] --- R2["副本分片 R2"]
    end
    N1 -.承载.- P0
    N1 -.承载.- R1
    N2 -.承载.- P1
    N2 -.承载.- R2
    N3 -.承载.- P2
    N3 -.承载.- R0
    style CLUSTER fill:#e8f0fe

要点：

分片（shard）是 ES 分布式能力的最小单元：一个分片就是一个完整的 Lucene 实例。索引只是"一组分片的逻辑命名空间"。
主分片数在创建索引时定死（路由哈希依赖它），副本分片数可以随时调整。
主副本不允许在同一节点——这样任意一台机器宕机，数据不丢、搜索不中断。
集群健康三态：green（所有主副本都就位）/ yellow（主分片齐了，副本缺）/ red（有主分片丢失，数据不可用）。

GET /_cluster/health   # 全书最常用的运维命令

2.2 扩容为什么是"免费"的

graph LR
    subgraph 三节点["3 节点"]
        A1["P0 R1"] 
        B1["P1 R2"]
        C1["P2 R0"]
    end
    subgraph 加一节点["加入第 4 节点后：自动再平衡"]
        A2["P0"]
        B2["P1 R0"]
        C2["P2"]
        D2["R1 R2"]
    end
    三节点 -->|"分片自动迁移<br/>无需停机"| 加一节点

分片是 Lucene 实例，搬分片 = 搬一个独立的小搜索引擎。ES 自动把分片挪到新节点，流量自动均摊。垂直扩容（换大机器）之外，ES 天生支持水平扩容（加机器）——这是书里"scale up vs scale out"一节的核心论点。

2.3 文档是怎么找到家的：路由

写入/读取一个文档时，ES 用它定位分片：

shard = hash(routing) % number_of_primary_shards

routing 默认是文档的 _id，也可以自定义（比如按用户 ID 路由，让同一用户的数据落在同一分片）。这解释了主分片数为什么不能改：改了模数，所有已有文档的哈希结果全部失效。

2.4 写入与读取的分布式流程

sequenceDiagram
    participant C as 客户端
    participant N as 协调节点<br/>（收到请求的任意节点）
    participant P as 主分片所在节点
    participant R1 as 副本节点1
    participant R2 as 副本节点2

    Note over C,N: 写入流程
    C->>N: PUT /blogs/post/123
    N->>N: 计算路由 hash(_id)%3 → P1
    N->>P: 转发写入
    P->>P: 本地写 Lucene + translog
    par 并行同步副本
        P->>R1: 复制写入
        P->>R2: 复制写入
    end
    R1-->>P: ack
    R2-->>P: ack
    P-->>N: 成功
    N-->>C: 201 + _version

    Note over C,N: 读取流程
    C->>N: GET /blogs/post/123
    N->>N: 路由计算 → 分片 P1
    N->>R2: 主/副本轮询负载均衡
    R2-->>N: 文档
    N-->>C: 200 + _source

两个关键设计：

任何节点都能当协调节点——没有单点入口；
写走主分片，读可以走主或副本——副本不仅容灾，还分摊读流量。加副本 = 加读吞吐。

三、近实时的秘密：refresh、translog 与段合并

“文档写入后为什么默认 1 秒才能搜到？“回答这个问题需要理解 Lucene 的存储模型。

3.1 倒排索引与不可变段

ES 快的根源是倒排索引：

graph LR
    subgraph 词典["Term Dictionary"]
        T1["climbing"]
        T2["music"]
        T3["rock"]
    end
    subgraph 倒排表["Posting List"]
        L1["doc 1, doc 5"]
        L2["doc 1, doc 3"]
        L3["doc 1"]
    end
    T1 --> L1
    T2 --> L2
    T3 --> L3

Lucene 把倒排索引持久化为段（segment），段一旦写出就不可变（immutable）。不可变性带来一串好处：不需要锁、可以进文件系统缓存、删除只需打标记。代价是：更新 = 删旧 + 建新，新写的文档必须先攒成新段才能被搜索。

3.2 完整链路

flowchart TD
    W["文档写入请求"] --> MEM["内存缓冲区"]
    W --> TL["translog<br/>（先写 WAL，防宕机丢数据）"]
    MEM -->|"refresh<br/>默认每 1 秒"| SEG["新 segment<br/>写入文件系统缓存<br/>→ 立即可被搜索"]
    SEG -->|"flush<br/>translog 满或定时"| DISK["fsync 落盘<br/>清空 translog"]
    SEG -.->|"后台 merge"| BIG["小段合并成大段<br/>物理清除已删文档"]

三个动作的分工：

refresh：内存 → 新的可搜索 segment（在文件系统缓存里，不落盘）。这就是"近实时（NRT）“的来源——默认 1 秒延迟。批量导入时可以调大 refresh_interval 换吞吐。
translog：预写日志。每个写入先记 translog，节点宕机后用它重放还没 flush 的数据。这是"ES 不丢数据"的底气。
flush：真正 fsync 落盘 + 清空 translog。
merge：小段太多会拖慢搜索（每个查询都要遍历所有段），后台线程持续把小段合并成大段，并顺带物理删除被标记删除的文档。

给初学者的记忆法：refresh 管"搜得到”，flush 管"丢不了”，merge 管"搜得快”。

四、映射与分析：数据进 ES 之前发生了什么

4.1 Mapping：字段的类型决定它能怎么被查

PUT /blogs
{
  "mappings": {
    "properties": {
      "title":    { "type": "text", "analyzer": "ik_max_word" },
      "status":   { "type": "keyword" },
      "views":    { "type": "integer" },
      "created":  { "type": "date" }
    }
  }
}

最核心的类型二分：

text：全文字段，会被分词后存入倒排索引，用于 match 全文检索；
keyword：精确值字段，原样入索引，用于过滤、排序、聚合。

书中金句："exact value 和 full text 的区别，是 SQL 世界和搜索世界的分界"。用 keyword 字段做 match 全文搜索（或反过来）是新手最常见的错误。

⚠️ 版本提示：原书写作时还是 string + analyzed/not_analyzed 的写法，ES 5.x 起拆分为 text/keyword，思想完全一致。

4.2 分析链：分词是怎么发生的

graph LR
    A["原始文本<br/>'The Quick Brown Fox!'"] --> CF["Character Filter<br/>字符过滤<br/>（去 HTML、字符映射）"]
    CF --> TK["Tokenizer<br/>分词器<br/>'The','Quick','Brown','Fox'"]
    TK --> TF["Token Filter<br/>词项过滤器<br/>lowercase → 停用词 → 词干提取"]
    TF --> R["最终词项<br/>'quick','brown','fox'"]

Character Filter：分词前做字符级预处理；
Tokenizer：把文本切成词项（一个分析器只能有一个 tokenizer）；
Token Filter：对词项再加工，可串联多个（lowercase、停用词、同义词、词干提取）。

内置的 standard 分析器 = standard tokenizer + lowercase + stop。可以用 _analyze API 眼见为实：

POST /_analyze
{ "analyzer": "standard", "text": "The Quick Brown Fox!" }
# → the, quick, brown, fox（'The' 被小写化）

中文场景：标准分词器会把中文逐字切开，效果很差。社区方案是 IK 分词器（ik_max_word 细粒度建索引、ik_smart 粗粒度搜索），这是中文 ES 项目的标配。

索引时与搜索时的分析必须配套：文档里的 "Fox" 入库时被分析成 fox；搜索 "FOX" 时查询词也会被同一个分析器处理成 fox 去匹配——这就是为什么 ES 搜索"不区分大小写"：不是查询忽略了大小写，而是两边都被 lowercased 了。

五、搜索：Query DSL 的全景

5.1 Query 与 Filter：全书最重要的性能概念

graph TD
    Q["Query 上下文<br/>'这个文档和查询有多相关？'"]
    F["Filter 上下文<br/>'这个文档是否匹配？'"]
    Q --> A1["计算 _score<br/>结果按相关性排序"]
    F --> A2["只答 yes/no<br/>不算分、结果可被缓存"]
    style Q fill:#fef3e8
    style F fill:#e1f5e1

经验法则：能用 filter 就不用 query。过滤条件（状态、时间范围、ID 列表）放 filter，既省算分开销又能命中 bitset 缓存。

5.2 常用查询速查

查询	用途	例子
`match`	全文搜索（会分词）	标题含"登山装备"
`term`	精确匹配（不分词）	status 等于 “published”
`terms`	多值精确匹配	标签 in [“科幻”,“动作”]
`range`	范围	age ≥ 30
`exists`	字段非空	必须有 poster 字段
`multi_match`	跨多字段全文	同时在标题和简介里搜
`match_phrase`	短语匹配（词序相邻）	搜 “rock climbing” 不拆词
`bool`	组合一切	见下

5.3 bool 查询：乐高积木

GET /megacorp/employee/_search
{
  "query": {
    "bool": {
      "must":     [ { "match": { "about": "rock climbing" } } ],
      "should":   [ { "match": { "interests": "music" } } ],
      "must_not": [ { "term":  { "last_name": "smith" } } ],
      "filter":   [ { "range": { "age": { "gte": 30 } } } ]
    }
  }
}

must：必须匹配，参与算分；
should：最好匹配，匹配上加分（没有 must/filter 时至少命中一个）；
must_not：必须不匹配，不参与算分（在 filter 上下文执行）；
filter：必须匹配，不参与算分。

所有复杂查询都是这四块积木的嵌套。

5.4 相关性算分：_score 是怎么来的

书里讲了经典的 TF/IDF 模型（新版本默认换成 BM25，思想相同，多了文档长度归一化）：

词频 TF：词在本文档出现越多，越相关；
逆文档频率 IDF：词在所有文档中越罕见，区分度越高（“的"不值钱，“攀岩"值钱）；
字段长度：字段越短，匹配越"精悍”，得分越高。

对结果有疑问时用 _explain API 看算分过程——这是调搜索体验的第一件工具。

5.5 深分页陷阱

GET /_search?from=10000&size=10   # ⚠️ 危险

分布式搜索是 scatter-gather 模式：

sequenceDiagram
    participant C as 客户端
    participant CO as 协调节点
    participant S0 as 分片0
    participant S1 as 分片1
    participant S2 as 分片2
    C->>CO: from=10000, size=10
    par scatter
        CO->>S0: 各分片先取 Top 10010
        CO->>S1: 各分片先取 Top 10010
        CO->>S2: 各分片先取 Top 10010
    end
    S0-->>CO: 10010 条
    S1-->>CO: 10010 条
    S2-->>CO: 10010 条
    CO->>CO: 归并 30030 条，取 10001~10010
    CO-->>C: 10 条

取第 1001 页，要在每个分片各取 10010 条再归并。深度翻页成本线性爆炸，书里的忠告是"不要在搜索场景做深翻页”；确实需要遍历全量时，用 scroll（游标快照）或新版本的 search_after。

六、处理人类语言

这一部分是本书区别于普通教程的精华：搜索的本质对手是自然语言的模糊性。

语言分析器：英语词干提取（foxes→fox）、德语的复合词拆分、中文/日文的无空格分词。每种语言的正确处理方式完全不同——选对语言分析器比调任何参数都重要。
拼写纠错（did-you-mean）：term suggester / phrase suggester，“你搜的是不是 elasticsearch？”
输入即搜（search-as-you-type）：用 edge ngram（前缀 ngram）在索引时把 "elasticsearch" 切成 e, el, ela, ...，用户每敲一个字母就能命中。
近似匹配：match 的 fuzziness 参数基于编辑距离，容忍拼写错误（searching 打成 serching 也能命中）。
近似短语：match_phrase 的 slop 参数允许词与词之间隔着几个词仍算匹配。

这一部分的共同心法：召回率与准确率的权衡。ngram 开得越大、fuzziness 越高，召回越好但噪音越多；工程上常用"多层子字段"（精确字段 + 分词字段 + ngram 字段）分层兜底。

七、聚合：从搜索到分析

搜索回答"哪些文档匹配"，聚合（aggregations） 回答"数据整体长什么样"。聚合分两大类，可以无限嵌套：

桶（Bucket）聚合：把文档分组——terms（按字段值）、date_histogram（按时间）、range（按区间）；
度量（Metric）聚合：对组内文档算统计——avg/sum/min/max/stats/cardinality。

7.1 实例：员工数据统计

GET /megacorp/employee/_search
{
  "size": 0,
  "aggs": {
    "by_interest": {              # 桶：按兴趣分组
      "terms": { "field": "interests" },
      "aggs": {
        "avg_age": {              # 嵌套度量：每组平均年龄
          "avg": { "field": "age" }
        }
      }
    }
  }
}

graph TD
    A["全部员工文档"] -->|"terms 桶 by_interest"| B1["sports 组"]
    A --> B2["music 组"]
    A --> B3["forestry 组"]
    B1 --> C1["avg_age = 28.5"]
    B2 --> C2["avg_age = 31.2"]
    B3 --> C3["avg_age = 35.0"]

7.2 要点

size: 0：只要聚合不要文档，省掉无用传输；
聚合只能跑在 keyword/数值/日期等精确值字段上——在 text 字段上聚合会失败或慢到崩溃（需要 fielddata，默认关闭，这是个性能地雷）；
高基数 terms 聚合（如按 userId 分桶）吃内存，新版有 circuit breaker 兜底；
近似聚合是 ES 的特色：cardinality（去重计数）和 percentiles（百分位）都是近似算法，用微小误差换海量数据下的可用性。

八、关系建模：ES 不是数据库

书里最"劝退"也最重要的一章：ES 没有 join。建模关系的四种方式按推荐顺序：

方式	思路	代价	适用
反规范化（Denormalize）	把关联数据冗余进每个文档	数据重复、更新要改多处	首选，读多写少
应用层 join	查两次，在代码里拼接	多一次网络往返	一对多且"多"侧很大
nested 对象	对象数组整体索引，保持内部关联	查询稍慢，更新整文档重建	对象数组（如文章的评论列表）
parent-child（join 字段）	父子文档独立存储，同分片关联	查询开销最大	子文档频繁独立更新

默认答案永远是先反规范化。搜索系统的哲学是"用写入时的冗余，换查询时的简单"——磁盘便宜，join 昂贵。

九、集群管理与运维要点

最后一部分面向生产：

节点角色分工：master 节点管集群元数据（建议 3 个专职 master 防脑裂）、data 节点存数据、协调节点转发请求。大集群应该角色分离。
脑裂与 minimum_master_nodes：网络分区时两个子集群各自选主 = 数据写烂。经典配置是 master 节点数 / 2 + 1（新版本的集群选举机制已自动化）。
分片规划：分片不是越多越好——每个分片都有固定开销（文件句柄、内存、段管理）。单分片控制在几十 GB 量级、节点堆内存 32GB 以内（压指针上限）、堆内存不超过物理内存一半（另一半留给文件系统缓存）。
监控集群健康：green/yellow/red + hot_threads + cat API 家族。
升级与备份：滚动升级逐个节点来；快照（snapshot）到 S3/HDFS 做备份。

十、全书知识地图

graph TD
    CORE["倒排索引<br/>（一切的根基）"]
    CORE --> WRITE["写入链路<br/>refresh/translog/merge<br/>→ 近实时 + 不丢数据"]
    CORE --> SEARCH["搜索<br/>Query/Filter + bool 组合<br/>TF-IDF 相关性算分"]
    CORE --> AGG["聚合<br/>桶 × 度量嵌套"]
    WRITE --> DIST["分布式<br/>分片路由 scatter-gather<br/>主副本容灾"]
    SEARCH --> LANG["语言处理<br/>分析器/纠错/输入即搜"]
    SEARCH --> MODEL["建模<br/>反规范化优先"]
    DIST --> OPS["运维<br/>健康监控/分片规划/防脑裂"]
    style CORE fill:#e1f5e1

如果只能记住三句话：

一切性能与行为的答案都在倒排索引里：不可变段决定了 NRT，分词决定了查不查得到，keyword/text 之分决定了能不能聚合；
query 算分、filter 缓存——写任何查询前先想这一条；
分片是分布式的原子：路由公式决定了主分片数不能改，副本决定了读吞吐和容灾。

参考资料：Clinton Gormley, Zachary Tong. 《Elasticsearch: The Definitive Guide》. O’Reilly, 2015. 中文版：elasticsearch-definitive-guide-cn（looly 等译）。

架构与分布式 on 方糖猫Blog

☸️ Kubernetes 学习总结与避坑指南

☸️ Kubernetes 学习总结与避坑指南

一、K8s 整体架构：一个「中心化大脑 + 一群干活的节点」

二、Node：干活的机器

2.1 Node 上有什么

2.2 节点相关的避坑点

三、Pod：K8s 的最小调度单元

3.1 为什么不是直接调度容器

3.2 Pod 生命周期与探针

3.3 资源 requests/limits 与 QoS：最容易被忽视的重灾区

四、工作负载：不要直接创建裸 Pod

五、K8s 网络模型与必备的 Unix 网络编程知识

5.1 K8s 网络的三条铁律

5.2 Service：一组 Pod 的稳定入口

5.3 为什么排查 K8s 网络要懂 Unix 网络编程

5.4 内外网访问隔离：哪些服务能暴露，哪些必须藏住

六、Ingress：HTTP 流量的统一入口

七、ConfigMap 与 Secret：配置和代码分离

八、共享存储：PV / PVC / StorageClass

九、Istio 服务网格：把「网络能力」从业务代码里剥出来

十、云上落地：阿里云 ACK 为主，AWS EKS 对照

10.1 阿里云 ACK 关键点

10.2 AWS EKS 速查对照

十一、典型问题排查手册

11.1 通用排查流程

11.2 高频问题速查表

11.3 优雅退出：滚动更新不断流的完整姿势

11.4 kubectl 排障速查

十二、CI/CD：Jenkins 与 K8s 打通，实现自动化部署与验证

12.1 整体流水线长什么样

12.2 Jenkins 的两种部署形态

12.3 最小权限的部署凭证：别把 admin kubeconfig 给 Jenkins

12.4 完整 Jenkinsfile 示例

12.5 「验证」环节的正确姿势

12.6 CI/CD 避坑清单

十三、学习路线建议

《设计数据密集型应用》学习总结：存量、流量、回路——每个设计决策都是三者的权衡

《设计数据密集型应用》学习总结：存量、流量、回路——每个设计决策都是三者的权衡

0. 写在前面：别背组件，背权衡

第一部分 存量：数据怎么存

1. LSM-Tree vs B-Tree：写的快和读的快，不可兼得

2. WAL：所有存储引擎的"保命符"

3. 行存 vs 列存：OLTP 与 OLAP 的分水岭

4. 编码与演进： schema 变了，老数据怎么办

第二部分 流量：数据怎么动

5. 复制：主从、多主、无主，三种政治体制

6. 分区：数据切蛋糕的两种刀法

7. 派生数据：一个数据系统的输出，是另一个系统的输入

第三部分 回路：系统怎么自我纠错

8. 事务与隔离级别：用"弱隔离"换性能，代价是异常

9. 共识与线性一致性：分布式系统的"终极回路"

10. 批处理 vs 流处理：同一枚硬币的两面

11. 全书串讲：用三个词复盘四个案例

12. 带走的清单

13. 结语：野猪书为什么是神书

《软件架构：最难的部分》详解：分布式架构的权衡分析实战指南

《软件架构：最难的部分》详解：分布式架构的权衡分析实战指南

第 1 章 当没有"最佳实践"时会发生什么

一切皆权衡

贯穿全书的案例：Sysops Squad 工单系统

第 2 章 识别软件架构中的耦合

架构量子（Architecture Quantum）

静态耦合与动态耦合

第 3 章 架构模块化

第 4 章 架构分解

传入耦合与传出耦合

主序列距离（Distance from the Main Sequence）

第 5 章 基于组件的分解模式

第 6 章 拆分运营数据

拆开数据库的推力与阻力

五步数据库分解法

第 7 章 服务粒度

第 8 章 复用模式

第 9 章 数据所有权与分布式事务

数据所有权

分布式事务的三种模式

第 10 章 分布式数据访问

第 11 章 管理分布式工作流

第 12 章 事务性 Saga

第一部分存量：数据怎么存

第二部分流量：数据怎么动

第三部分回路：系统怎么自我纠错

第 1 章当没有"最佳实践"时会发生什么

第 2 章识别软件架构中的耦合

第 3 章架构模块化

第 4 章架构分解

第 5 章基于组件的分解模式

第 6 章拆分运营数据

第 7 章服务粒度

第 8 章复用模式

第 9 章数据所有权与分布式事务

第 10 章分布式数据访问

第 11 章管理分布式工作流

第 12 章事务性 Saga

第 13 章契约

第 14 章管理分析型数据

第 15 章构建你自己的权衡分析