计算机系统八大维度最佳实践 #

高性能、高可用、高并发、可扩展、容灾容错、安全可靠、可观测性、资源优化！所有计算机系统底层原理完全通用！

📋 目录 #

一、开篇：八大维度 × 八大技术领域
二、高性能篇
三、高可用篇
四、高并发篇
五、可扩展篇
六、容灾容错篇
七、安全可靠篇
八、可观测性篇
九、资源优化篇
十、实战案例
十一、面试题汇总与答案

一、开篇：八大维度 × 八大技术领域 ⭐⭐⭐⭐⭐ #

核心观点：八大维度，一套通用技术池！ #

八大维度全景表 #

维度	核心目标	关键技术
高性能	低延迟、高吞吐	CPU亲和性、NUMA、大页内存、零拷贝、DPDK/RDMA
高可用	99.99%+可用性	冗余、心跳、故障转移、热迁移、Keepalived
高并发	高连接数、高并发	epoll、io_uring、事件驱动、批处理、连接池
可扩展	弹性伸缩	水平扩展、资源池化、自动伸缩、解耦
容灾容错	灾难恢复、数据不丢	多AZ、副本、快照、混沌工程
安全可靠	零信任、合规	最小权限、隔离、加密、审计、安全启动
可观测性	全栈可观测	eBPF、Prometheus、日志、追踪、性能分析
资源优化	降本增效	配额、超卖、压缩、冷热分层、电源管理

八大技术领域 #

领域	范围	代表技术
T1 虚拟化	计算虚拟化、内存虚拟化、网络虚拟化、存储虚拟化	KVM / VMware / Xen / QEMU
T2 操作系统	进程调度、内存管理、文件系统、IO栈、内核	Linux Kernel / eBPF / cgroups
T3 网络	协议栈、负载均衡、DNS、CDN、SDN/VPC	LVS / Nginx / HAProxy / DPDK
T4 存储	块存储、文件存储、对象存储、分布式存储	Ceph / NFS / NVMe / RAID
T5 容器	容器运行时、编排调度、服务网格	Docker / K8s / containerd / Istio
T6 硬件	CPU、NUMA、内存通道、SSD、网卡	x86 / ARM / PCIe / RDMA
T7 Linux管理	系统初始化、资源管理、安全加固	systemd / SELinux / firewalld
T8 云原生	IaaS、PaaS、基础设施即代码	Terraform / Ansible / OpenStack

一图览：各技术领域 × 各维度映射 #

通用技术	虚拟化(T1)	操作系统(T2)	网络(T3)	存储(T4)	容器(T5)	硬件(T6)	Linux(T7)	云原生(T8)
高性能	✅ virtio/SR-IOV	✅ io_uring	✅ DPDK	✅ NVMe	✅ kata	✅ NUMA	✅ 内核调优	✅ autoscaler
高可用	✅ HA/热迁移	✅ systemd	✅ VRRP	✅ RAID	✅ PDB	✅ 冗余电源	✅ Pacemaker	✅ 多AZ
高并发	✅ vhost-net	✅ epoll	✅ LVS	✅ 异步IO	✅ HPA	✅ RSS	✅ ulimit	✅ 弹性伸缩
可扩展	✅ 资源池	✅ cgroups	✅ SDN	✅ 弹性卷	✅ 联邦	✅ 刀片	✅ Ansible	✅ IaC
容灾	✅ 跨AZ迁移	✅ 备份	✅ BGP容灾	✅ 快照	✅ Velero	✅ 热插拔	✅ DRBD	✅ 多区域
安全	✅ SEV加密	✅ SELinux	✅ TLS	✅ 加密盘	✅ NetworkPolicy	✅ TPM	✅ auditd	✅ 零信任
可观测	✅ libvirt	✅ perf/bcc	✅ tcpdump	✅ iostat	✅ cAdvisor	✅ IPMI	✅ journalctl	✅ OpenTelemetry
资源优化	✅ 超卖	✅ cgroups	✅ tc	✅ 去重	✅ limits	✅ 调频	✅ tuned	✅ Spot实例

学习方法：先通原理，再看具体 #

第一步：理解八大维度的通用技术池 ← 掌握核心
    ↓
第二步：看某技术领域如何应用这些技术 ← 举一反三
    ↓
第三步：对比不同技术领域的实现方式 ← 发现都是同一套
    ↓
第四步：融会贯通，任意计算机系统问题手到擒来

二、高性能篇 #

2.1 通用高性能技术池 ⭐⭐⭐⭐⭐ #

2.1.1 CPU亲和性与绑核 #

原理：

将进程绑定到特定CPU核心，避免跨核心迁移
减少CPU缓存（L1/L2）失效，提升缓存命中率
对延迟敏感型应用效果显著

各技术领域应用：

领域	实现方式	命令/配置
虚拟化	vCPU pinning	`virsh vcpupin vm1 0 2,3`
操作系统	taskset/cpuset	`taskset -c 0-3 ./app`
容器	cpuset	`docker run --cpuset-cpus=0-3`
K8s	CPU Manager静态策略	`cpu-manager-policy: static`
DPDK	lcore绑定	`-l 0,1,2,3 -n 4`

2.1.2 NUMA架构优化 #

原理：

多CPU服务器中，每个CPU（或一组核心）有本地内存（Local Memory）
访问本地内存 ~80ns，访问远端内存 ~150ns+，差距近2倍
跨NUMA访问还会占用QPI/UPI总线带宽

各技术领域应用：

领域	NUMA优化方案	配置示例
虚拟化	vNUMA拓扑，虚拟机感知物理NUMA	`<numa><cell cpus='0-3' memory='8192'/></numa>`
数据库	interleave模式或绑NUMA节点	`numactl --interleave=all mysql`
K8s	拓扑管理策略	`topology-manager-policy: best-effort`
Redis	绑NUMA节点	`numactl --cpunodebind=0 --membind=0 redis-server`

# 查看NUMA拓扑
numactl --hardware

# 绑NUMA节点运行应用
numactl --cpunodebind=0 --membind=0 ./high_perf_app

# K8s Pod NUMA感知（静态CPU管理）
# kubelet config:
cpuManagerPolicy: static
topologyManagerPolicy: best-effort

2.1.3 大页内存（Huge Pages） #

原理：

标准页大小4KB → TLB miss频繁
大页2MB/1GB → 减少TLB miss，减少页表项

页大小	TLB覆盖率	适用场景
4KB	低	通用应用
2MB	高	数据库、虚拟化、DPDK
1GB	极高	超大内存应用

各技术领域应用：

领域	配置方式	配置示例
虚拟化	KVM透传大页	`<memoryBacking><hugepages/></memoryBacking>`
数据库	MySQL/PostgreSQL	`innodb_buffer_pool_size` + HugePages
DPDK	必须使用	`-m 1024`（2MB页数）
容器	挂载大页	`--privileged -v /dev/hugepages:/dev/hugepages`
K8s	大页中间件	`resources.hugepages-2Mi`

# 配置大页内存（2MB）
echo 1024 > /proc/sys/vm/nr_hugepages  # 分配1024个2MB大页 = 2GB

# 永久配置
vm.nr_hugepages = 1024

# K8s Pod使用大页
# spec.containers[].resources:
#   hugepages-2Mi: "200Mi"

2.1.4 零拷贝技术 #

零拷贝方式：

sendfile：磁盘→内核→网卡，跳过用户空间
mmap：用户空间映射内核缓冲区，省一次拷贝
splice：管道间零拷贝数据传输

各技术领域应用：

领域	零拷贝实现	场景
Nginx	`sendfile on`	静态文件传输
Kafka	sendfile + Page Cache	消息传输
Java	FileChannel.transferTo	NIO零拷贝
容器	overlayfs联合挂载	镜像分层
KVM	virtio-blk数据路径优化	虚拟磁盘IO

# Nginx零拷贝配置
location /download/ {
    sendfile on;         # 启用sendfile
    tcp_nopush on;       # 配合sendfile
    aio on;              # 异步IO
}

2.1.5 DPDK与RDMA #

技术	原理	延迟	吞吐	适用场景
内核网络	中断+系统调用	~10-50μs	~10Gbps	通用
DPDK	用户态轮询+零拷贝	~1-5μs	~100Gbps	NFV、网关
RDMA	绕过CPU直接访问远程内存	~1μs	~200Gbps	高性能计算、分布式存储

# DPDK绑定网卡
dpdk-devbind.py --bind=vfio-pci 0000:01:00.0

# K8s使用SR-IOV + DPDK
# Multus CNI + SR-IOV Device Plugin
# Pod annotation:
# k8s.v1.cni.cncf.io/networks: sriov-dpdk

2.1.6 中断亲和性与RPS/RFS #

原理：

默认所有中断集中在CPU0 → CPU0成为瓶颈
将中断分散到多个CPU核心 → 并行处理

# 设置网卡中断亲和性（将中断分散到CPU 2-5）
for irq in $(cat /proc/interrupts | grep eth0 | awk '{print $1}' | tr -d ':'); do
    echo "2-5" > /proc/irq/$irq/smp_affinity_list
done

# RPS（Receive Packet Steering）软件层分发
echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus

# RFS（Receive Flow Steering）按流分发到应用所在CPU
echo 256 > /proc/sys/net/core/rps_sock_flow_entries
echo 256 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

2.1.7 批处理与合并 #

思想：

传统：10000次请求 → 10000次系统调用/网络往返
批量：10000次请求 → 合并1次 → 批量执行

领域	批处理方式	配置示例
磁盘IO	IO调度器合并	`echo cfq > /sys/block/sda/queue/scheduler`
网络	TCP_CORK/GSO/TSO	`setsockopt(fd, IPPROTO_TCP, TCP_CORK, ...)`
数据库	批量INSERT	`INSERT INTO t VALUES (1),(2),(3)`
虚拟化	virtio-blk批量提交	`iothread` + 批量IO
容器	联合提交	overlayfs写时复制合并

2.2 虚拟化技术高性能实践 #

2.2.1 半虚拟化（Virtio）vs 全虚拟化 #

对比项	全虚拟化（QEMU模拟）	半虚拟化（Virtio）	硬件辅助（SR-IOV）
原理	软件模拟真实硬件	前后端驱动协作	硬件直接透传
性能	低	高	极高
网络	e1000/r8169	virtio-net	SR-IOV VF直通
磁盘	IDE/SCSI	virtio-blk/scsi	NVMe直通
适用	兼容性优先	性能+兼容均衡	极致性能

<!-- KVM虚拟机使用virtio -->
<devices>
  <disk type='file' device='disk'>
    <driver name='qemu' type='qcow2' cache='none' io='native'/>
    <source file='/vm/ubuntu.qcow2'/>
    <target dev='vda' bus='virtio'/>  <!-- virtio磁盘 -->
  </disk>
  <interface type='bridge'>
    <model type='virtio'/>  <!-- virtio网卡 -->
  </interface>
</devices>

2.2.2 SR-IOV网络直通 #

# 开启SR-IOV（以Intel网卡为例）
echo 7 > /sys/class/net/eth0/device/sriov_numvfs  # 创建7个VF

# 绑定VF到VFIO驱动
dpdk-devbind.py --bind=vfio-pci 0000:01:10.0

# 虚拟机使用VF直通
virsh attach-device vm1 vf-passthrough.xml

2.2.3 KVM内存优化 #

<!-- KVM虚拟机内存优化配置 -->
<memory unit='KiB'>8388608</memory>
<currentMemory unit='KiB'>8388608</currentMemory>
<memoryBacking>
  <hugepages/>           <!-- 大页内存 -->
  <locked/>              <!-- 锁定内存，防止swap -->
  <source type='memfd'/> <!-- memfd后端 -->
</memoryBacking>

优化项	配置	效果
大页内存	`<hugepages/>`	减少TLB miss
内存锁定	`<locked/>`	防止被swap出去
KSM	`/sys/kernel/mm/ksm/run`	内存去重（适合同类VM）
内存气球	`<memballoon>`	动态回收/分配内存
EPT	硬件辅助	减少影子页表开销

2.3 操作系统内核高性能实践 #

2.3.1 io_uring：下一代异步IO #

io_uring优势：

共享环形缓冲区（Submission Queue + Completion Queue）
零系统调用（批量提交后一次enter）
支持注册固定缓冲区，真正零拷贝

// io_uring使用示例
struct io_uring ring;
io_uring_queue_init(32, &ring, 0);

struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
io_uring_prep_read(sqe, fd, buf, 4096, 0);
io_uring_submit(&ring);

struct io_uring_cqe *cqe;
io_uring_wait_cqe(&ring, &cqe);
// cqe->res = 读取字节数
io_uring_cqe_seen(&ring, cqe);

2.3.2 内核网络参数调优 #

# /etc/sysctl.conf 高性能网络参数
# === 缓冲区 ===
net.core.rmem_max = 16777216          # 最大接收缓冲区 16MB
net.core.wmem_max = 16777216          # 最大发送缓冲区 16MB
net.core.rmem_default = 262144        # 默认接收缓冲区
net.core.wmem_default = 262144        # 默认发送缓冲区
net.ipv4.tcp_rmem = 4096 87380 16777216   # TCP接收缓冲区 min/default/max
net.ipv4.tcp_wmem = 4096 65536 16777216   # TCP发送缓冲区 min/default/max

# === 连接 ===
net.core.somaxconn = 65535            # 连接队列最大长度
net.ipv4.tcp_max_syn_backlog = 65535  # SYN队列长度
net.core.netdev_max_backlog = 5000    # 网卡接收队列

# === 性能 ===
net.ipv4.tcp_tw_reuse = 1             # TIME_WAIT复用
net.ipv4.tcp_fin_timeout = 15         # FIN超时缩短
net.ipv4.tcp_slow_start_after_idle = 0 # 禁用空闲后慢启动
net.ipv4.tcp_no_metrics_save = 1      # 不缓存TCP指标
net.core.default_qdisc = fq           # 默认队列调度

# === BBR拥塞控制 ===
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

2.3.3 内存管理优化 #

# /etc/sysctl.conf 内存参数
vm.swappiness = 1                     # 尽量不用swap
vm.dirty_ratio = 10                   # 脏页占物理内存10%时写回
vm.dirty_background_ratio = 5         # 5%时后台写回
vm.dirty_writeback_centisecs = 500    # 5秒写回一次
vm.overcommit_memory = 0              # 禁止过度提交

# Transparent Huge Pages（数据库建议关闭）
echo never > /sys/kernel/mm/transparent_hugepage/enabled

# OOM Killer配置（保护关键进程）
echo -1000 > /proc/$(pidof mysql)/oom_score_adj

2.4 计算机网络高性能实践 #

2.4.1 LVS四层负载均衡 #

LVS三种模式对比：

模式	原理	优点	缺点
NAT	修改目的IP	RS无需公网IP	Director瓶颈
DR	修改MAC地址	性能最高	RS需在同一网段
TUN	IP隧道	跨网段	需IP隧道支持

# LVS DR模式配置
ipvsadm -A -t 10.0.0.100:80 -s rr
ipvsadm -a -t 10.0.0.100:80 -r 10.0.0.11:80 -g -w 1
ipvsadm -a -t 10.0.0.100:80 -r 10.0.0.12:80 -g -w 1
ipvsadm -a -t 10.0.0.100:80 -r 10.0.0.13:80 -g -w 1

2.4.2 Nginx七层负载优化 #

# nginx.conf 高性能配置
worker_processes auto;                    # 自动匹配CPU核心数
worker_cpu_affinity auto;                # CPU亲和性
worker_rlimit_nofile 65535;              # 文件描述符上限

events {
    worker_connections 65535;             # 单worker最大连接
    use epoll;                            # 使用epoll
    multi_accept on;                      # 一次性接受所有连接
}

http {
    sendfile on;                          # 零拷贝
    tcp_nopush on;                        # 减少报文段
    tcp_nodelay on;                       # 禁用Nagle
    keepalive_timeout 65;                 # 长连接

    upstream backend {
        least_conn;                       # 最少连接调度
        server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
        server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
        keepalive 32;                     # 到后端的长连接池
    }
}

2.4.3 内核网络协议栈优化 #

# 接收端缩放（RSS）- 网卡硬件层分发
ethtool -L eth0 combined 8  # 8个接收队列

# XDP（eXpress Data Path）- 内核最前层处理
# 在网卡驱动层丢弃/转发包，绕过整个内核协议栈
# 示例：XDP DDOS防护
# xdp_drop.c 编译后加载
ip link set dev eth0 xdp obj xdp_drop.o

2.5 存储系统高性能实践 #

2.5.1 NVMe SSD优化 #

优化项	配置	说明
IO调度器	`noop`/`none`	NVMe无需调度，直接提交
队列深度	`nr_requests=1024`	增大队列深度
IO策略	`direct=1`	绕过Page Cache
命名空间	多Namespace并行	NVMe支持多队列

# NVMe优化
echo none > /sys/block/nvme0n1/queue/scheduler    # IO调度器
echo 1024 > /sys/block/nvme0n1/queue/nr_requests  # 队列深度
echo 1024 > /sys/block/nvme0n1/queue/iostats      # IO统计

# fio性能测试
fio --name=nvme-test --filename=/dev/nvme0n1 --ioengine=libaio \
    --iodepth=64 --rw=randread --bs=4k --numjobs=4 --time_based \
    --runtime=30 --group_reporting

2.5.2 文件系统优化 #

# XFS优化（高性能场景推荐）
mkfs.xfs -f -b size=4096 -d su=256k,sw=1 /dev/sdb1

# 挂载优化
mount -o noatime,nodiratime,discard /dev/sdb1 /data

# ext4优化
mkfs.ext4 -b 4096 -O ^has_journal -E stride=256,stripe_width=256 /dev/sdb1

2.5.3 RAID级别选择 #

RAID级别	冗余	空间利用率	随机读	随机写	适用场景
RAID0	无	100%	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	临时数据
RAID1	有	50%	⭐⭐⭐⭐	⭐⭐⭐	系统盘
RAID5	有	(N-1)/N	⭐⭐⭐⭐	⭐⭐	读多写少
RAID10	有	50%	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	高性能数据库
RAID6	双冗余	(N-2)/N	⭐⭐⭐⭐	⭐	归档存储

2.6 容器与编排高性能实践 #

2.6.1 K8s CPU管理策略 #

# Kubelet配置：静态CPU管理
# /var/lib/kubelet/config.yaml
cpuManagerPolicy: static
cpuManagerReconcilePeriod: 10s

# Pod请求整核CPU，获得独占资源
apiVersion: v1
kind: Pod
metadata:
  name: cpu-intensive
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "4"        # 整数 → 独占CPU核心
        memory: "4Gi"
      limits:
        cpu: "4"
        memory: "4Gi"

2.6.2 容器运行时优化 #

优化项	方案	说明
Kata Containers	轻量VM运行时	硬件级隔离+接近容器性能
gVisor	用户态内核	安全沙箱，兼容性好
CRI-O	专为K8s设计	更轻量，安全边界清晰
containerd	默认运行时	高效稳定，生产推荐

# containerd性能优化
# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.9"
[plugins."io.containerd.grpc.v1.cri".containerd]
  snapshotter = "overlayfs"    # overlayfs性能最佳
  disable_snapshot_annotations = false

2.7 服务器与硬件高性能实践 #

2.7.1 BIOS/UEFI优化 #

设置项	推荐值	说明
Power Policy	Performance/Max Performance	禁用省电模式
Turbo Boost	Enabled	CPU睿频
Hyper-Threading	视场景	计算密集开启，IO密集关闭
NUMA	Enabled	确保NUMA启用
C-States	C1 only	减少深度睡眠唤醒延迟
SR-IOV	Enabled	网络虚拟化直通

2.7.2 PCIe与RDMA配置 #

# 查看PCIe链路速率
lspci -vvv | grep -A 20 "Ethernet"

# RDMA配置（RoCEv2）
# 启用PFC（Priority Flow Control）
# 交换机端配置优先级3为无损
mlnx_qos -i eth0 --pfc 0,0,0,1,0,0,0,0

# 配置GRH（Global Routing Header）
echo 0 > /sys/module/mlx5_core/parameters/fdb_unsafe

2.8 Linux系统管理高性能实践 #

2.8.1 系统级调优（tuned） #

# 安装tuned
yum install -y tuned
systemctl enable --now tuned

# 使用吞吐量优化profile
tuned-adm profile throughput-performance

# 自定义profile
mkdir /etc/tuned/custom-performance
cat > /etc/tuned/custom-performance/tuned.conf << 'EOF'
[main]
summary=Custom high performance profile

[cpu]
governor=performance
energy_perf_bias=performance
min_perf_pct=100

[vm]
transparent_hugepages=never

[sysctl]
vm.swappiness = 1
vm.dirty_ratio = 10
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
EOF

tuned-adm profile custom-performance

2.8.2 文件描述符与资源限制 #

# /etc/security/limits.conf
*    soft    nofile    65535
*    hard    nofile    65535
*    soft    nproc     65535
*    hard    nproc     65535
*    soft    memlock   unlimited
*    hard    memlock   unlimited
root soft    nofile    65535
root hard    nofile    65535

# systemd服务资源限制
# /etc/systemd/system/myservice.service
[Service]
LimitNOFILE=65535
LimitNPROC=65535
LimitMEMLOCK=infinity

2.9 云原生基础设施高性能实践 #

2.9.1 自动伸缩（Cluster Autoscaler + HPA） #

# HPA配置
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300

2.9.2 Spot实例 + 混合部署 #

# Terraform创建Spot实例池
resource "aws_spot_fleet_request" "fleet" {
  iam_fleet_role      = "arn:aws:iam::xxx:role/aws-ec2-spot-fleet-tagging-role"
  spot_price          = "0.05"
  target_capacity     = 10
  allocation_strategy = "capacity-optimized"

  launch_specification {
    instance_type     = "c5.4xlarge"
    ami_id            = "ami-xxx"
    weighted_capacity = 1
  }
}

三、高可用篇 #

3.1 通用高可用技术池 ⭐⭐⭐⭐⭐ #

3.1.1 冗余架构设计 #

模式	可用性	资源利用率	复杂度	适用场景
主备	99.9%	50%	低	数据库、关键服务
双活	99.99%	100%	中	Web服务、API网关
集群N+M	99.999%	N/(N+M)	高	大规模分布式系统

3.1.2 心跳检测与健康检查 #

各技术领域应用：

领域	健康检查方式	配置
Keepalived	VRRP心跳	`advert_int 1`（1秒间隔）
K8s	livenessProbe/readinessProbe	`httpGet`/`tcpSocket`/`exec`
LVS	ldirectord健康检查	检查RS端口
Nginx	`max_fails` + `fail_timeout`	被动检查
HAProxy	`check` + `inter`	主动健康检查

3.1.3 故障转移（Failover） #

故障转移类型：

类型	方式	切换时间	数据丢失
冷备	手动切换	分钟~小时	无
温备	自动检测+半自动切换	秒~分钟	可能少量
热备	自动检测+自动切换	毫秒~秒	无
无缝	状态同步+自动切换	毫秒	无

3.1.4 Keepalived + VRRP #

# Keepalived MASTER配置
# /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100                    # MASTER优先级高
    advert_int 1                    # 心跳间隔1秒
    authentication {
        auth_type PASS
        auth_pass 123456
    }
    virtual_ipaddress {
        10.0.0.100/24              # VIP
    }
    track_script {
        chk_http_port              # 健康检查脚本
    }
}

3.2 虚拟化技术高可用实践 #

3.2.1 KVM高可用（HA + 热迁移） #

# libvirt热迁移（在线迁移，零停机）
virsh migrate --live --persistent --undefinesource \
    --verbose vm1 qemu+tcp://node2/system

# oVirt/OpenStack自动HA
# VM自动重启策略：
# - HA：主机故障后自动在另一节点重启
# - Live Migration：维护前自动迁移

3.2.2 存储多路径 #

# 安装multipath
yum install -y device-mapper-multipath

# /etc/multipath.conf
defaults {
    user_friendly_names yes
    path_grouping_policy multibus
    path_selector "round-robin 0"
    failback immediate
    no_path_retry 12
}

# 查看多路径
multipath -ll

3.3 操作系统高可用实践 #

3.3.1 systemd服务自动重启 #

# /etc/systemd/system/myapp.service
[Unit]
Description=My Application
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/myapp
Restart=always                    # 总是重启
RestartSec=5                      # 重启间隔5秒
StartLimitBurst=5                 # 10秒内最多重启5次
StartLimitIntervalSec=10
WatchdogSec=30                    # 看门狗30秒

[Install]
WantedBy=multi-user.target

3.3.2 Pacemaker + Corosync集群 #

# 安装
yum install -y pacemaker corosync pcs

# 配置集群资源
pcs resource create vip ocf:heartbeat:IPaddr2 \
    ip=10.0.0.100 cidr_netmask=24 op monitor interval=30s

pcs resource create web systemd:nginx \
    op monitor interval=30s

# 资源约束：VIP和Web在同一节点
pcs constraint colocation add web with vip INFINITY
pcs constraint order start vip then web

3.4 计算机网络高可用实践 #

3.4.1 ECMP多路径路由 #

# ECMP配置（等价多路径）
ip route add 10.0.0.0/24 \
    nexthop via 192.168.1.1 weight 1 \
    nexthop via 192.168.1.2 weight 1 \
    nexthop via 192.168.1.3 weight 1

3.4.2 BGP高可用 #

特性	说明	配置
BFD	毫秒级故障检测	`bfd interval 50 min_rx 50 multiplier 3`
Graceful Restart	重启不中断	`graceful-restart`
BGP AnyCast	多节点同IP	多节点宣告相同前缀

3.5 存储系统高可用实践 #

3.5.1 Ceph多副本 + 纠删码 #

# Ceph存储池配置
# 副本池（默认3副本，高性能）
ceph osd pool create pool-replicated 128 replicated
ceph osd pool set pool-replicated size 3      # 3副本
ceph osd pool set pool-replicated min_size 2   # 最小2副本写入成功

# 纠删码池（节省空间，适合冷数据）
ceph osd pool create pool-ec 128 erasure
ceph osd pool set pool-ec erasure-code-profile k=4,m=2  # 4+2，容错2盘

策略	空间利用率	容错能力	性能	适用场景
3副本	33%	2盘故障	高	热数据、数据库
4+2 EC	67%	2盘故障	中	冷数据、日志
8+3 EC	73%	3盘故障	低	归档数据

3.6 容器与编排高可用实践 #

3.6.1 K8s Pod反亲和性与PDB #

# Pod反亲和性：确保副本分布在不同节点
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: web-app
            topologyKey: kubernetes.io/hostname

---
# PDB（PodDisruptionBudget）：确保升级时至少2个Pod可用
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web-app

3.6.2 etcd高可用集群 #

# etcd三节点集群部署
etcd --name etcd1 \
  --initial-advertise-peer-urls http://10.0.0.11:2380 \
  --listen-peer-urls http://10.0.0.11:2380 \
  --initial-cluster etcd1=http://10.0.0.11:2380,etcd2=http://10.0.0.12:2380,etcd3=http://10.0.0.13:2380 \
  --initial-cluster-token etcd-cluster \
  --advertise-client-urls http://10.0.0.11:2379

3.7 服务器与硬件高可用实践 #

冗余组件	方案	说明
电源	1+1 / 2+1冗余电源	热插拔更换
风扇	N+1冗余	单风扇故障不影响
网卡	Bond / LACP	双网卡聚合
磁盘	RAID1 / RAID5	热备盘自动重建
内存	ECC + 内存镜像	自动纠正单比特错误
PCIe	PCIe热插拔	部分服务器支持

# 网卡Bond配置（LACP模式）
# /etc/network/interfaces
auto bond0
iface bond0 inet dhcp
    bond-mode 4          # 802.3ad LACP
    bond-miimon 100      # 心跳间隔100ms
    bond-lacp-rate fast  # 快速LACP
    bond-slaves eth0 eth1

3.8 Linux系统管理高可用实践 #

3.8.1 Watchdog看门狗 #

# 安装watchdog
yum install -y watchdog

# /etc/watchdog.conf
watchdog-device = /dev/watchdog
interval = 10           # 10秒心跳
temperature-sensor = /sys/class/hwmon/hwmon0/temp1_input
max-temperature = 120   # 温度阈值

systemctl enable --now watchdog

3.9 云原生基础设施高可用实践 #

3.9.1 多AZ K8s集群 #

# EKS多AZ部署
eksctl create cluster \
    --name prod-cluster \
    --region us-east-1 \
    --nodegroup-name workers \
    --node-type c5.4xlarge \
    --nodes 6 \
    --nodes-min 4 \
    --nodes-max 20 \
    --node-zones us-east-1a,us-east-1b,us-east-1c

四、高并发篇 #

4.1 通用高并发技术池 ⭐⭐⭐⭐⭐ #

4.1.1 IO多路复用（epoll） #

epoll vs select vs poll：

模型	最大连接	性能	原理
select	1024 (FD_SETSIZE)	O(n)遍历	线性扫描所有fd
poll	无限制	O(n)遍历	同select，无硬限制
epoll	无限制	O(1)就绪	事件通知，仅返回就绪fd

epoll两种触发模式：

LT（Level Triggered，水平触发）：默认模式，只要缓冲区有数据就通知
ET（Edge Triggered，边沿触发）：只在新事件到来时通知一次，必须一次读完

// epoll ET模式示例（高性能）
int epfd = epoll_create1(0);
struct epoll_event ev;
ev.events = EPOLLIN | EPOLLET;  // 边沿触发
ev.data.fd = listen_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

// 事件循环
while (1) {
    int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
    for (int i = 0; i < n; i++) {
        if (events[i].data.fd == listen_fd) {
            // accept所有连接（ET模式必须）
            while ((conn_fd = accept(listen_fd, ...)) > 0) {
                setnonblocking(conn_fd);
                ev.events = EPOLLIN | EPOLLET;
                ev.data.fd = conn_fd;
                epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev);
            }
        } else {
            // 读取所有数据（ET模式必须）
            while ((n = read(fd, buf, sizeof(buf))) > 0) {
                handle_data(buf, n);
            }
        }
    }
}

4.1.2 io_uring：异步高并发IO #

// io_uring批量提交多个IO请求
struct io_uring ring;
io_uring_queue_init(256, &ring, IORING_SETUP_SQPOLL);  // 内核轮询模式

// 批量提交100个读请求
for (int i = 0; i < 100; i++) {
    struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);
    io_uring_prep_readv(sqe, fds[i], iovecs[i], 1, 0);
    sqe->user_data = i;
}
io_uring_submit(&ring);  // 一次系统调用提交100个请求

// 批量收割完成事件
for (int i = 0; i < 100; i++) {
    struct io_uring_cqe *cqe;
    io_uring_wait_cqe(&ring, &cqe);
    process_result(cqe->user_data, cqe->res);
    io_uring_cqe_seen(&ring, cqe);
}

4.1.3 事件驱动 + Reactor模式 #

各技术领域应用：

领域	事件驱动实现	模式
Nginx	master(worker进程)	多进程Reactor
Netty	Boss(Group) + Worker(Group)	主从Reactor
Redis	单线程epoll	单Reactor
Node.js	libuv事件循环	单Reactor
DPDK	rte_eal轮询	Poll模式

4.1.4 连接池与长连接 #

技术	说明	配置
TCP Keepalive	检测死连接	`net.ipv4.tcp_keepalive_time=600`
连接池	复用连接	HikariCP、Nginx upstream keepalive
长连接	减少握手	HTTP/1.1 keep-alive、HTTP/2多路复用
连接复用	多路复用	HTTP/2 stream、gRPC

# Nginx到后端的长连接池
upstream backend {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    keepalive 64;          # 保持64个空闲长连接
}

server {
    location /api/ {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

4.2 虚拟化高并发实践 #

4.2.1 virtio-net多队列 #

<!-- KVM虚拟机多队列网卡 -->
<interface type='bridge'>
  <model type='virtio'/>
  <driver name='vhost' queues='4'/>  <!-- 4个队列 -->
  <target dev='vnet0'/>
</interface>

# 虚拟机内部多队列绑定不同CPU
# ethtool -L eth0 combined 4

4.3 操作系统高并发实践 #

4.3.1 C10M：百万并发连接 #

# /etc/sysctl.conf C10M参数
net.ipv4.ip_local_port_range = 1024 65535     # 端口范围
net.ipv4.tcp_tw_reuse = 1                     # TIME_WAIT复用
net.ipv4.tcp_fin_timeout = 10                 # FIN超时
net.ipv4.tcp_max_syn_backlog = 65535          # SYN队列
net.core.somaxconn = 65535                    # listen队列
net.ipv4.tcp_max_tw_buckets = 65535           # TIME_WAIT上限
net.ipv4.tcp_syncookies = 1                   # SYN Cookie防泛洪
net.core.netdev_max_backlog = 65535           # 网卡接收队列

# 文件描述符
fs.file-max = 1048576
fs.nr_open = 1048576

# /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576

4.4 计算机网络高并发实践 #

4.4.1 LVS高并发连接 #

参数	说明	推荐值
conntrack	连接跟踪表大小	`net.netfilter.nf_conntrack_max=1048576`
TIME_WAIT	快速回收	`tcp_tw_reuse=1`
SYN Cookie	防SYN泛洪	`tcp_syncookies=1`
连接超时	缩短空闲连接超时	`tcp_fin_timeout=10`

# LVS持久化连接（解决长连接问题）
ipvsadm -A -t 10.0.0.100:443 -s rr -p 3600  # 持久化1小时

4.5 存储系统高并发实践 #

# IO调度器选择
# SSD → noop（无调度）
echo noop > /sys/block/nvme0n1/queue/scheduler

# HDD → deadline（避免饥饿）
echo deadline > /sys/block/sda/queue/scheduler

# 增大IO队列深度
echo 1024 > /sys/block/nvme0n1/queue/nr_requests

# 开启异步IO（数据库）
# PostgreSQL: effective_io_concurrency = 200
# MySQL: innodb_io_capacity = 2000, innodb_io_capacity_max = 4000

4.6 容器与编排高并发实践 #

4.6.1 K8s高并发配置 #

# K8s API Server高并发配置
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
apiServer:
  extraArgs:
    max-requests-inflight: 1500      # 非mutating请求并发上限
    max-mutating-requests-inflight: 500 # mutating请求并发上限

# Ingress高并发
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "5"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/upstream-keepalive-connections: "100"

4.7 服务器与硬件高并发实践 #

4.7.1 网卡多队列（RSS） #

# 查看网卡队列数
ethtool -l eth0

# 设置网卡多队列
ethtool -L eth0 combined 16  # 16个接收/发送队列

# RPS软件层分发（补充RSS）
echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus

4.8 Linux系统管理高并发实践 #

4.8.1 突破文件描述符限制 #

# 查看当前限制
ulimit -n            # 默认1024

# 临时修改
ulimit -n 1048576

# 永久修改
# /etc/systemd/system.conf
DefaultLimitNOFILE=1048576
DefaultLimitNPROC=1048576

# /etc/sysctl.conf
fs.file-max = 1048576
fs.nr_open = 1048576

4.9 云原生基础设施高并发实践 #

4.9.1 KEDA事件驱动伸缩 #

# KEDA事件驱动伸缩
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: queue-consumer
spec:
  scaleTargetRef:
    name: consumer
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: kafka:9092
      consumerGroup: my-group
      topic: orders
      lagThreshold: "100"           # 堆积超过100条就扩容
      cooldownPeriod: 30

五、可扩展篇 #

5.1 通用可扩展技术池 ⭐⭐⭐⭐⭐ #

5.1.1 水平扩展 vs 垂直扩展 #

对比项	垂直扩展	水平扩展
方式	升级单机配置	增加机器数量
成本	指数增长（顶级硬件贵）	线性增长
上限	有物理上限	理论无上限
停机	通常需要	无缝扩展
推荐	快速缓解	✅ 长期方案

5.1.2 无状态化设计 #

有状态：客户端请求 → 必须打到同一节点（会话绑定）
    ↓ 重构
无状态：客户端请求 → 任意节点都能处理（状态外置）

状态外置方案：

状态类型	外置方案	技术
会话	分布式缓存	Redis / Memcached
文件	对象存储	S3 / Ceph / NFS
配置	配置中心	etcd / Nacos / Consul
定时任务	分布式调度	XXL-Job / K8s CronJob

5.1.3 自动伸缩策略 #

策略	触发条件	适用场景
HPA	CPU/内存/自定义指标	无状态服务
VPA	历史资源使用	资源配置优化
CA	节点资源不足	集群扩缩
KEDA	事件驱动（队列长度等）	事件消费

5.2 虚拟化可扩展实践 #

5.2.1 资源池化 #

# 热添加CPU（在线扩容）
virsh setvcpus vm1 8 --live --config

# 热添加内存
virsh setmaxmem vm1 16G --config
virsh setmem vm1 12G --live

# 热添加磁盘
virsh attach-disk vm1 /path/new-disk.qcow2 vdb --live --config

5.3 操作系统可扩展实践 #

5.3.1 cgroups v2资源隔离 #

# cgroups v2限制资源
mkdir /sys/fs/cgroup/myapp
cd /sys/fs/cgroup/myapp

# CPU限制（最多使用2核）
echo "200000 1000000" > cpu.max        # 20% = 0.2核

# 内存限制（最大2GB）
echo "2G" > memory.max

# IO限制（限制读写带宽）
echo "8:0 rbps=104857600 wbps=52428800" > io.max

5.4 计算机网络可扩展实践 #

5.4.1 SDN网络架构 #

SDN能力	说明	技术
网络虚拟化	VPC、子网、安全组	Open vSwitch / Calico
服务发现	自动注册/发现	Consul / CoreDNS
流量调度	灰度、金丝雀	Istio / Nginx
负载均衡	L4/L7分发	LVS / MetalLB

5.5 存储系统可扩展实践 #

5.5.1 Ceph弹性扩展 #

# Ceph增加OSD（扩容）
ceph osd crush add osd.16 host=node8  # 添加OSD到node8
ceph osd crush reweight osd.16 1.0    # 设置权重

# 数据自动重平衡
ceph osd set backfillfull 0.85        # 85%开始数据迁移

# 添加新节点
ceph orch host add node9 10.0.0.19

5.6 容器与编排可扩展实践 #

5.6.1 K8s VPA自动垂直伸缩 #

# VPA（Vertical Pod Autoscaler）- 自动调整资源requests
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  updatePolicy:
    updateMode: Auto               # 自动更新Pod资源
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 4
        memory: 8Gi

5.6.2 K8s集群联邦（多集群扩展） #

5.7 服务器与硬件可扩展实践 #

扩展方式	说明	场景
刀片服务器	统一机箱，按需插入刀片	数据中心扩容
机架扩展	标准化机架，快速部署	通用场景
NVMe热插拔	在线添加NVMe盘	存储扩容
PCIe热插拔	在线添加网卡/加速卡	网络扩容

5.8 Linux系统管理可扩展实践 #

5.8.1 基础设施即代码（IaC） #

# Ansible批量管理
# inventory.ini
[webservers]
web01 ansible_host=10.0.0.11
web02 ansible_host=10.0.0.12
web03 ansible_host=10.0.0.13

# playbook.yml
- hosts: webservers
  become: yes
  tasks:
  - name: Install Nginx
    yum: name=nginx state=latest

  - name: Configure Nginx
    template: src=nginx.conf.j2 dest=/etc/nginx/nginx.conf

  - name: Start Nginx
    service: name=nginx state=started enabled=yes

# 执行
ansible-playbook -i inventory.ini playbook.yml

5.9 云原生基础设施可扩展实践 #

5.9.1 Terraform动态扩展节点池 #

# Terraform动态扩展K8s节点池
resource "aws_eks_node_group" "workers" {
  cluster_name    = aws_eks_cluster.cluster.name
  node_group_name = "workers"
  node_role_arn   = aws_iam_role.node.arn
  subnet_ids      = aws_subnet.private[*].id

  scaling_config {
    desired_size = 6
    max_size     = 20
    min_size     = 3
  }

  instance_types = ["c5.4xlarge", "c5.2xlarge"]  # 混合实例类型
}

六、容灾容错篇 #

6.1 通用容灾容错技术池 ⭐⭐⭐⭐⭐ #

6.1.1 容灾等级与RTO/RPO #

指标	含义	目标值（高要求）
RTO (Recovery Time Objective)	恢复时间	< 30秒（同城）/ < 5分钟（异地）
RPO (Recovery Point Objective)	数据丢失量	≈ 0（同步）/ < 1秒（异步）

6.1.2 多AZ/多机房架构 #

6.1.3 混沌工程 #

混沌工程核心流程：
1. 定义稳态假设 → 系统正常运行时的指标
2. 注入故障 → 杀进程、断网络、加延迟、关节点
3. 观察系统 → 是否自动恢复？是否降级？是否触发告警？
4. 改进系统 → 发现的薄弱环节逐一加固

工具	层级	故障类型
Chaos Mesh	K8s平台	Pod杀死、网络注入、IO故障
LitmusChaos	K8s平台	Pod混沌、节点混沌、云混沌
Gremlin	全栈	基础设施、网络、应用层
Pumba	容器	容器杀停、网络延迟

6.2 虚拟化容灾容错实践 #

6.2.1 虚拟机跨AZ迁移 #

# 存储实时复制 + 热迁移
# 方案1：基于Ceph RBD镜像
rbd mirror pool add rbd pool2
rbd mirror pool enable rbd image

# 方案2：基于存储阵列同步
# 1. 存储层复制（同步/异步）
# 2. 计算层热迁移
virsh migrate --live --persistent --copy-disk-all \
    vm1 qemu+tcp://remote-host/system

6.3 操作系统容灾容错实践 #

6.3.1 数据备份策略 #

# 全量备份（每周）
tar czf /backup/system-full-$(date +%Y%m%d).tar.gz /

# 增量备份（每天）- 使用rsync
rsync -avz --delete --link-dest=/backup/last-full/ \
    /data/ /backup/inc-$(date +%Y%m%d)/

# 数据库备份
mysqldump --single-transaction --master-data=2 \
    --all-databases | gzip > /backup/mysql-full.sql.gz

# 定时备份（crontab）
0 2 * * 0 /usr/bin/mysqldump ... > /backup/weekly.sql
0 2 * * 1-6 /usr/bin/mysqldump ... > /backup/daily.sql

6.4 计算机网络容灾容错实践 #

6.4.1 BGP多路径容灾 #

# BGP配置 - 双上行到不同运营商
router bgp 65001
  neighbor 203.0.113.1 remote-as 64512    # 运营商A
  neighbor 198.51.100.1 remote-as 64513   # 运营商B

  # BFD快速故障检测
  neighbor 203.0.113.1 fall-over bfd
  neighbor 198.51.100.1 fall-over bfd

  # Graceful Restart
  neighbor 203.0.113.1 graceful-restart
  neighbor 198.51.100.1 graceful-restart

6.5 存储系统容灾容错实践 #

6.5.1 Ceph跨站点灾备 #

# Ceph RBD镜像（跨站点实时复制）
# 站点A
rbd mirror pool enable rbd image

# 站点B - 配置对端
rbd mirror pool peer add rbd client.remote@site_a

# 查看同步状态
rbd mirror image status rbd/myimage

# 故障切换
rbd mirror image promote rbd/myimage

6.5.2 快照策略 #

# Ceph RBD快照（定时）
rbd snap create rbd/volume1@snap-$(date +%Y%m%d)
rbd snap purge rbd/volume1  # 清理旧快照

# LVM快照
lvcreate -L 10G -s -n backup_snap /dev/vg0/data
mount /dev/vg0/backup_snap /mnt/backup
tar czf /backup/data.tar.gz /mnt/backup/
umount /mnt/backup
lvremove -f /dev/vg0/backup_snap

6.6 容器与编排容灾容错实践 #

6.6.1 Velero K8s备份恢复 #

# 安装Velero
velero install --provider aws \
    --plugins velero/velero-plugin-for-aws:v1.7.0 \
    --bucket my-cluster-backup \
    --secret-file ./credentials-velero \
    --backup-location-config region=us-east-1

# 备份整个集群
velero create backup full-backup --include-all-namespaces

# 备份特定命名空间
velero create backup myapp-backup --include-namespaces myapp

# 恢复
velero restore create --from-backup full-backup

# 定时备份
velero schedule create daily-backup \
    --schedule="0 2 * * *" --include-namespaces production

6.7 服务器与硬件容灾容错实践 #

硬件容错	技术	说明
ECC内存	Single/Dual/Quad-bit纠错	自动纠正1位，检测多位
热备盘	Hot Spare	自动替换故障盘
RAID重建	自动重建	热插拔更换后自动恢复
冗余电源	PSU冗余	单电源故障不影响
IPMI/iDRAC	远程管理	远程开关机、KVM、监控

# 使用ipmitool远程管理
ipmitool -H 10.0.0.100 -U admin -P pass power status  # 查看电源状态
ipmitool -H 10.0.0.100 -U admin -P pass sensor list    # 查看传感器
ipmitool -H 10.0.0.100 -U admin -P pass sel list       # 查看事件日志

6.8 Linux系统管理容灾容错实践 #

6.8.1 DRBD块级复制 #

# DRBD配置（双机实时块复制）
# /etc/drbd.d/r0.res
resource r0 {
    protocol C;                # 同步复制（强一致）
    on node1 {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 10.0.0.11:7788;
    }
    on node2 {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 10.0.0.12:7788;
    }
}

# 初始化并启动
drbdadm create-md r0
drbdadm up r0
drbdadm primary --force r0

6.9 云原生基础设施容灾容错实践 #

6.9.1 多区域K8s部署 #

# 多集群灾备方案
# 1. 主集群正常服务
# 2. DNS健康检查，主集群不可达时自动切换
# 3. 数据通过跨区域复制同步

# AWS Route53健康检查 + 自动故障转移
aws route53 create-health-check \
    --health-check-config '{
        "Port": 443,
        "Type": "HTTPS",
        "ResourcePath": "/healthz",
        "FullyQualifiedDomainName": "primary.example.com"
    }'

七、安全可靠篇 #

7.1 通用安全技术池 ⭐⭐⭐⭐⭐ #

7.1.1 安全纵深防御模型 #

7.1.2 最小权限原则 #

最小权限 = 仅授予完成任务所需的最低权限

应用层：容器只读文件系统 + 非root运行
网络层：NetworkPolicy仅允许必要端口通信
数据层：数据库账号仅授权必要表和操作
系统层：Linux capabilities精简，禁用不必要的SUID

7.1.3 网络隔离策略 #

隔离层级	技术	说明
物理隔离	独立网卡/VLAN	管理网、业务网、存储网分离
网络分段	子网/VPC	不同业务不同网段
微隔离	NetworkPolicy/SG	Pod/VM级别的细粒度控制
加密通道	TLS/IPSec/WireGuard	所有通信加密

7.2 虚拟化安全实践 #

7.2.1 虚拟机安全加固 #

<!-- KVM安全配置 -->
<domain>
  <!-- 禁用不必要的设备 -->
  <devices>
    <!-- 禁用USB -->
    <controller type='usb' model='none'/>
    <!-- 禁用图形设备 -->
    <video model='none'/>
  </devices>

  <!-- 启用SEV加密（AMD） -->
  <sev type='encrypted'/>
  <launchSecurity type='sev'>
    <cbitpos>47</cbitpos>
    <reducedPhysBits>1</reducedPhysBits>
  </launchSecurity>
</domain>

安全措施	说明
SEV (AMD)	内存加密，宿主无法窥探VM内存
TDX (Intel)	信任域扩展，硬件隔离
virtio安全	SELinux标签隔离设备访问
QEMU沙箱	限制QEMU进程权限

7.3 操作系统安全实践 #

7.3.1 SELinux强制模式 #

# 查看SELinux状态
sestatus
# SELinux status: enabled
# Current mode: enforcing

# 查看安全上下文
ls -Z /var/www/html/

# 自定义策略（示例：允许nginx监听自定义端口）
grep nginx /var/log/audit/audit.log | audit2allow -M nginx_custom
semodule -i nginx_custom.pp

# 常用命令
getenforce           # 查看当前模式
setenforce 1         # 设为enforcing
semanage port -a -t http_port_t -p tcp 8080  # 添加允许端口

7.3.2 Linux Capabilities #

# 替代root权限，只授予必要的capability
# 仅允许绑定<1024端口
setcap 'cap_net_bind_service=+ep' /usr/bin/myapp

# 仅允许抓包
setcap 'cap_net_raw=+ep' /usr/bin/tcpdump

# 查看capabilities
getcap /usr/bin/myapp

# 容器中使用capabilities
# docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx

7.4 计算机网络安全实践 #

7.4.1 防火墙配置 #

# firewalld配置
firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --permanent --zone=public --add-rich-rule='\
    rule family="ipv4" source address="10.0.0.0/8" port port="3306" protocol="tcp" accept'
firewall-cmd --permanent --zone=public --add-rich-rule='\
    rule family="ipv4" source address="0.0.0.0/0" port port="22" protocol="tcp" reject'
firewall-cmd --reload

# nftables（新一代防火墙）
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input tcp dport { 80, 443 } accept
nft add rule inet filter input tcp dport 22 ip saddr { 10.0.0.0/8 } accept

7.4.2 WireGuard VPN #

# 安装WireGuard
yum install -y wireguard-tools

# 生成密钥
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub

# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = <server-private-key>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <client-public-key>
AllowedIPs = 10.10.0.2/32

# 启动
systemctl enable --now wg-quick@wg0

7.5 存储系统安全实践 #

7.5.1 LUKS磁盘加密 #

# 创建加密分区
cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 encrypted_data

# 格式化并挂载
mkfs.xfs /dev/mapper/encrypted_data
mount /dev/mapper/encrypted_data /secure_data

# 自动解锁（/etc/crypttab）
encrypted_data /dev/sdb1 /root/keyfile luks

# Ceph加密存储池
ceph osd pool set rbd encryption at-rest  # 静态数据加密

7.6 容器与编排安全实践 #

7.6.1 Pod Security Standards #

# Pod安全标准（K8s 1.25+）
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true               # 不以root运行
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault           # 默认seccomp
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      allowPrivilegeEscalation: false  # 禁止提权
      readOnlyRootFilesystem: true     # 只读文件系统
      capabilities:
        drop: ["ALL"]                  # 移除所有capability
        add: ["NET_BIND_SERVICE"]      # 仅添加必要的

7.6.2 NetworkPolicy网络策略 #

# 仅允许web Pod访问db Pod的3306端口
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 3306

7.7 服务器与硬件安全实践 #

安全技术	说明
TPM 2.0	可信平台模块，安全启动链
Secure Boot	防止引导层恶意代码
UEFI Secure	签名验证固件
Intel SGX	飞地，硬件隔离敏感计算
Intel TXT	可信执行技术

# 检查Secure Boot状态
mokutil --sb-state

# 查看TPM状态
tpm2_getcap properties-fixed

7.8 Linux系统管理安全实践 #

7.8.1 审计与日志 #

# auditd审计规则
# 审计文件修改
auditctl -w /etc/passwd -p wa -k identity
auditctl -w /etc/shadow -p wa -k identity
auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config

# 审计系统调用
auditctl -a always,exit -F arch=b64 -S execve -k exec_audit

# 查看审计日志
ausearch -k identity
aureport -x  # 系统调用报告

# SSH安全加固 /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
Protocol 2

7.9 云原生基础设施安全实践 #

7.9.1 零信任安全模型 #

零信任 = 不信任任何网络位置，每次访问都需要验证

核心原则：
1. 永远验证（Verify Always）
2. 最小权限（Least Privilege）
3. 假设已被入侵（Assume Breach）

实现方式：
- mTLS（双向TLS）服务间通信
- Service Mesh（Istio）统一策略
- SPIFFE/SPIRE 身份框架

# Istio mTLS配置
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # 强制mTLS

八、可观测性篇 #

8.1 通用可观测性技术池 ⭐⭐⭐⭐⭐ #

8.1.1 可观测性三大支柱 #

支柱	回答什么问题	核心工具	数据特征
Metrics	系统怎么样了？	Prometheus + Grafana	数值、时间序列
Logs	发生了什么？	ELK / Loki	文本、结构化
Tracing	请求经过了哪些环节？	Jaeger / SkyWalking	跨服务调用链
Profiling	性能瓶颈在哪？	eBPF / perf / Pyroscope	CPU/内存火焰图

8.2 虚拟化可观测性实践 #

8.2.1 libvirt + Prometheus #

# libvirt-exporter采集虚拟机指标
# prometheus.yml
scrape_configs:
  - job_name: 'libvirt'
    static_configs:
      - targets: ['libvirt-exporter:9177']
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'libvirt_domain_.*'
        action: keep

关键指标	说明
`libvirt_domain_cpu_seconds_total`	虚拟机CPU使用
`libvirt_domain_memory_usage_bytes`	虚拟机内存使用
`libvirt_domain_block_stats_*`	虚拟机磁盘IO
`libvirt_domain_interface_stats_*`	虚拟机网络IO

8.3 操作系统可观测性实践 #

8.3.1 eBPF全栈可观测 #

# bcc工具集（eBPF前端）
# 网络延迟分析
tcplife                 # TCP连接生命周期
tcprtt                 # TCP往返时间
tcpretrans             # TCP重传统计

# 文件系统
opensnoop              # 跟踪文件打开
biolatency             # 块设备IO延迟
ext4slower             # 慢文件操作

# 进程
execsnoop              # 跟踪新进程
runqlat                # CPU调度延迟
offcputime             # 进程离CPU时间

# 性能分析
profile -f 99          # CPU火焰图采样

8.3.2 perf性能分析 #

# CPU火焰图
perf record -F 99 -p $(pidof myapp) -g -- sleep 30
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg

# 系统全局性能
perf top                    # 实时查看热点函数
perf stat -p $(pidof app)   # 进程统计信息

# 内核跟踪点
perf probe -x /lib/x86_64-linux-gnu/libc.so.6 'open'
perf record -e probe_libc:open -a

8.4 计算机网络可观测性实践 #

8.4.1 网络诊断工具链 #

# 连通性
ping -c 3 10.0.0.1
mtr -r -c 10 10.0.0.1       # traceroute + ping

# DNS
dig @8.8.8.8 example.com
dig +trace example.com      # 跟踪DNS解析链

# 流量分析
tcpdump -i eth0 -nn port 80
ss -s                       # Socket统计
ss -tnp                     # TCP连接详情

# 带宽
iftop -i eth0               # 实时流量
nethogs                     # 按进程统计流量

# sFlow/NetFlow（交换机级别）
# 配置交换机：sflow sampling-rate 1000
# 采集工具：sflowtool / ntopng

8.4.2 eBPF网络可观测（Cilium Hubble） #

# 安装Hubble（Cilium的可观测平台）
cilium hubble port-forward &
hubble observe --since 1m    # 观察流量
hubble observe --pod nginx   # 观察特定Pod流量
hubble observe --protocol dns # 观察DNS请求

8.5 存储系统可观测性实践 #

# IO监控
iostat -x 1                  # 实时IO统计
iotop                        # 按进程IO排序

# 磁盘性能
fio --name=test --filename=/dev/nvme0n1 \
    --ioengine=libaio --iodepth=64 --rw=randrw \
    --bs=4k --rwmixread=70 --size=1G --time_based \
    --runtime=60 --group_reporting

# Ceph监控
ceph osd df                  # OSD空间使用
ceph osd pool stats          # 存储池状态
ceph status                  # 集群健康状态

# NFS监控
nfsstat -m                   # 挂载统计
nfsstat -c                   # 客户端RPC统计
exportfs -v                  # 导出列表

8.6 容器与编排可观测性实践 #

8.6.1 Prometheus + Grafana监控栈 #

# node-exporter（主机指标）
# kube-state-metrics（K8s资源指标）
# cAdvisor（容器指标）

# 关键告警规则
groups:
- name: k8s-alerts
  rules:
  - alert: PodCrashLooping
    expr: rate(kube_pod_container_status_restarts_total[5m]) * 60 * 5 > 0
    for: 15m
    labels:
      severity: critical

  - alert: NodeMemoryPressure
    expr: kube_node_status_condition{condition="MemoryPressure",status="true"} == 1
    for: 5m
    labels:
      severity: warning

  - alert: PVCAlmostFull
    expr: (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) > 0.85
    for: 5m
    labels:
      severity: warning

8.7 服务器与硬件可观测性实践 #

# IPMI传感器监控
ipmitool -H 10.0.0.100 -U admin -P pass sensor list

# REDFISH（新一代服务器管理）
curl -k -u admin:pass https://10.0.0.100/redfish/v1/Chassis/System1 \
    | jq '.Thermal | .Temperatures'

# SMART磁盘健康
smartctl -a /dev/sda
smartctl -t long /dev/sda       # 长时间自检
smartctl -l selftest /dev/sda   # 查看自检结果

# 温度监控
sensors                        # lm_sensors

8.8 Linux系统管理可观测性实践 #

8.8.1 journalctl日志管理 #

# 查看服务日志
journalctl -u nginx --since "1 hour ago" -f

# 按优先级过滤
journalctl -p err -b           # 本次启动以来的错误

# 资源使用日志
journalctl -u sshd --since today | grep "Failed password"

# 持久化配置
# /etc/systemd/journald.conf
SystemMaxUse=1G               # 最大日志大小
MaxRetentionSec=30day          # 保留30天
Compress=yes                   # 压缩日志
ForwardToSyslog=no            # 不转发到rsyslog

8.9 云原生基础设施可观测性实践 #

8.9.1 OpenTelemetry统一可观测 #

# OpenTelemetry Collector配置
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 5s
    send_batch_size: 1024

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
  jaeger:
    endpoint: jaeger-collector:14250
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [jaeger]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]

九、资源优化篇 #

9.1 通用资源优化技术池 ⭐⭐⭐⭐⭐ #

9.1.1 资源配额与超卖 #

超卖比参考：

资源类型	推荐超卖比	原理
CPU	4:1 ~ 8:1	多数时间空闲，时间片复用
内存	1.2:1 ~ 1.5:1	过度提交+swap兜底
磁盘	取决于去重率	精简配置+去重+压缩
网络	不超卖	带宽是硬上限

9.2 虚拟化资源优化实践 #

9.2.1 KVM CPU超卖 #

<!-- CPU超卖：物理8核 → 分配20个vCPU -->
<vcpu placement='auto' current='4'>20</vcpu>
<cpu mode='host-passthrough'/>  <!-- CPU特性透传 -->

<!-- 内存超卖 + 内存气球 -->
<memory unit='KiB'>16777216</memory>
<currentMemory unit='KiB'>8388608</currentMemory>
<memballoon model='virtio'>
  <stats period='10'/>
</memballoon>

<!-- 内存限制 -->
<memtune>
  <hard_limit unit='KiB'>16777216</hard_limit>
  <soft_limit unit='KiB'>12582912</soft_limit>
  <swap_hard_limit unit='KiB'>20971520</swap_hard_limit>
</memtune>

9.2.2 KSM内存去重 #

# 开启KSM（Kernel Same-page Merging）
echo 1 > /sys/kernel/mm/ksm/run

# KSM调优
echo 1000 > /sys/kernel/mm/ksm/sleep_millisecs  # 扫描间隔
echo 1000 > /sys/kernel/mm/ksm/pages_to_scan     # 每次扫描页数

# 查看效果
cat /sys/kernel/mm/ksm/pages_shared     # 共享页数
cat /sys/kernel/mm/ksm/pages_sharing    # 节省的页数

# 精简配置磁盘
qemu-img create -f qcow2 -o preallocation=metadata vm-disk.qcow2 100G
# 实际只占用元数据大小，按需分配

9.3 操作系统资源优化实践 #

9.3.1 cgroups资源限制 #

# cgroups v2资源管理
# 创建资源组
mkdir /sys/fs/cgroup/web

# CPU限制
echo "200000 1000000" > /sys/fs/cgroup/web/cpu.max       # 0.2核

# 内存限制
echo "1G" > /sys/fs/cgroup/web/memory.max                # 最大1GB
echo "512M" > /sys/fs/cgroup/web/memory.high              # 软限制512MB
echo "800M" > /sys/fs/cgroup/web/memory.swap.max          # swap限制

# IO限制（blkio v2）
echo "8:0 rbps=52428800 wbps=104857600" > /sys/fs/cgroup/web/io.max

# PIDs限制
echo "100" > /sys/fs/cgroup/web/pids.max

# 将进程加入组
echo $(pidof nginx) > /sys/fs/cgroup/web/cgroup.procs

9.4 计算机网络资源优化实践 #

9.4.1 流量控制（TC + HTB） #

# HTB（Hierarchical Token Bucket）带宽管理
tc qdisc add dev eth0 root handle 1: htb default 30

# 总带宽10Gbps
tc class add dev eth0 parent 1: classid 1:1 htb rate 10gbit

# 子类分配
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5gbit ceil 10gbit  # 优先业务
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3gbit ceil 8gbit   # 普通业务
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 2gbit ceil 5gbit   # 低优先

# u32过滤规则（按端口/IP分类）
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
    match ip dport 443 0xffff flowid 1:10    # HTTPS走优先队列

9.5 存储系统资源优化实践 #

9.5.1 存储压缩与去重 #

技术	压缩率	CPU开销	适用场景
zstd	高	低	Ceph、ZFS
lz4	中	极低	实时压缩
snappy	中	低	Hadoop、Cassandra
gzip	高	高	归档存储

# Ceph启用压缩
ceph osd pool set mypool compression_algorithm zstd
ceph osd pool set mypool compression_mode aggressive  # 激进压缩
ceph osd pool set mypool compression_required_ratio 0.8  # 压缩比<0.8不存

# ZFS压缩
zfs create tank/data -o compression=zstd
zfs set compression=zstd tank/data

9.5.2 冷热数据分层 #

9.6 容器与编排资源优化实践 #

9.6.1 K8s Requests & Limits优化 #

# 资源requests和limits最佳实践
apiVersion: v1
kind: Pod
metadata:
  name: optimized-pod
spec:
  containers:
  - name: app
    image: myapp:latest
    resources:
      requests:
        cpu: "500m"        # 请求0.5核（调度依据）
        memory: "512Mi"    # 请求512MB
      limits:
        cpu: "2000m"       # 限制最大2核
        memory: "1Gi"      # 限制最大1GB
    # 启用QoS Class: Burstable

QoS等级与资源策略：

QoS等级	条件	行为
Guaranteed	requests == limits	最高优先级，不会被杀
Burstable	requests < limits	中等优先级，内存压力大时可能被杀
BestEffort	无requests/limits	最低优先级，最先被杀

9.6.2 Cluster Autoscaler + Spot实例 #

# 混合节点池（按需 + Spot）
# K8s Cluster Autoscaler配置
# --balance-similar-node-groups  自动平衡同类节点池
# --expander=least-waste          扩展浪费最少的节点池
# --skip-nodes-with-system-pods=false

# Spot实例Node标签 + Taint
kubectl taint nodes spot-xxx spot=true:NoSchedule

# Pod容忍Spot Taint
tolerations:
- key: "spot"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"

9.7 服务器与硬件资源优化实践 #

9.7.1 CPU电源管理 #

# 查看当前CPU调频策略
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# 性能模式（生产环境推荐）
cpupower frequency-set -g performance

# 省电模式（开发/测试环境）
cpupower frequency-set -g powersave

# 关闭不使用的CPU核心（节能）
echo 0 > /sys/devices/system/cpu/cpu7/online

# 查看CPU C-States
cat /sys/devices/system/cpu/cpu0/cpuidle/state*/name

9.8 Linux系统管理资源优化实践 #

9.8.1 tuned性能档案 #

# 查看可用profile
tuned-adm list

# 推荐：虚拟化主机
tuned-adm profile virtual-host

# 推荐：数据库服务器
tuned-adm profile oracle          # 或 virtual-guest

# 自定义节能profile
cat > /etc/tuned/power-save/tuned.conf << 'EOF'
[main]
summary=Power saving profile

[cpu]
governor=powersave
energy_perf_bias=powersave
min_perf_pct=50

[vm]
transparent_hugepages=always

[sysctl]
vm.dirty_writeback_centisecs = 1500
EOF

tuned-adm profile power-save

9.9 云原生基础设施资源优化实践 #

9.9.1 成本优化策略 #

策略	节省	风险	适用
Spot实例	60-90%	可能被回收	无状态/可容忍中断
预留实例	30-50%	需长期承诺	稳定负载
Savings Plans	20-40%	灵活承诺	混合负载
自动伸缩	20-50%	需合理配置	弹性负载
Right-sizing	10-30%	需分析历史	资源过剩

# kubectl资源使用分析
kubectl top nodes                    # 节点资源使用
kubectl top pods -A --sort-by=cpu    # Pod CPU排序
kubectl top pods -A --sort-by=memory # Pod内存排序

# Kubecost成本分析
helm install kubecost cost-analyzer \
    --repo https://kubecost.github.io/cost-analyzer/ \
    --namespace kubecost --create-namespace

十、实战案例 #

10.1 虚拟化平台高可用架构设计 ⭐⭐⭐⭐⭐ #

八大维度全覆盖方案：

维度	方案
高性能	virtio半虚拟化、SR-IOV网络直通、大页内存、CPU绑核
高可用	计算节点N+1冗余、Ceph三副本、Keepalived VIP、热迁移
高并发	virtio-net多队列、vhost-net、bond双网卡聚合
可扩展	按需创建VM、热添加vCPU/内存/磁盘、Ceph横向扩展
容灾	Ceph跨机架故障域、VM快照定时备份、异地DR站点
安全	虚拟网络隔离(VLAN)、SEV加密、libvirt SELinux
可观测	Prometheus + node-exporter + libvirt-exporter + Grafana
资源优化	CPU超卖4:1、内存气球+KSM去重、Ceph精简配置

10.2 K8s集群性能调优实战 ⭐⭐⭐⭐⭐ #

调优清单：

层级	调优项	配置
Node	内核参数	BBR、大页内存、文件描述符
Kubelet	CPU Manager	static策略
调度	TopologyManager	best-effort
网络	Cilium eBPF	替代kube-proxy
Pod	资源request	整数CPU = 独占
存储	Local PV	NVMe本地盘
监控	全链路	Prometheus+OTel+Grafana

10.3 万兆网络高并发优化实战 #

# 万兆网络优化完整配置

# 1. 网卡参数
ethtool -L eth0 combined 16           # 16个队列
ethtool -G eth0 rx 4096 tx 4096      # 增大ring buffer
ethtool -K eth0 tso on gso on gro on lro on  # 卸载

# 2. 中断亲和性
for irq in $(ls /proc/irq/ | grep eth | head -16); do
    core=$((irq % 8))
    echo $core > /proc/irq/$irq/smp_affinity_list
done

# 3. 内核网络参数
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.netdev_max_backlog = 10000
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_tw_reuse = 1

# 4. XDP加速（可选）
# 编译XDP程序：xdp_drop_blacklist.o
ip link set dev eth0 xdp obj xdp_drop_blacklist.o

10.4 eBPF全栈可观测方案 ⭐⭐⭐⭐ #

工具链：

层级	工具	用途
应用	bpftrace + USDT	函数级追踪
内核	bcc tools	系统调用、调度、IO
网络	Cilium Hubble	网络流量、策略审计
容器	Pixie	K8s原生可观测
安全	Tetragon	运行时安全监控

10.5 混沌工程实战：K8s故障演练 #

# Chaos Mesh安装
helm install chaos-mesh chaos-mesh/chaos-mesh \
    --namespace chaos-mesh --create-namespace

# 实验1：随机杀死Pod
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-test
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
    - production
    labelSelectors:
      app: web
  scheduler:
    cron: "@every 5m"

# 实验2：网络延迟注入
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay-test
spec:
  action: delay
  mode: one
  selector:
    labelSelectors:
      app: web
  delay:
    latency: "200ms"
    correlation: "50"
  direction: to
  target:
    selector:
      labelSelectors:
        app: database

十一、面试题汇总与答案 #

通用原理题 #

1. 计算机系统八大维度是什么？与中间件维度有何异同？ #

答案：

维度	核心目标	与中间件异同
高性能	低延迟、高吞吐	相同：CPU/NUMA/大页是系统独有
高可用	99.99%+可用	相同：热迁移/冗余是系统独有
高并发	高连接数	相同：epoll/io_uring更底层
可扩展	弹性伸缩	相同：资源池化/自动伸缩
容灾容错	灾难恢复	相同：多AZ/快照是系统独有
安全可靠	零信任、合规	相同：SELinux/TPM更底层
可观测性	全栈可观测	相同：eBPF/perf更底层
资源优化	降本增效	新维度：超卖/压缩/分层

核心差异：中间件维度关注软件层面，计算机系统维度更关注硬件+内核+基础设施层面。

2. 什么是NUMA？为什么NUMA对性能影响大？ #

答案：

NUMA（Non-Uniform Memory Access）：多CPU服务器中，每个CPU有本地内存，访问本地快、远端慢
本地内存 ~80ns，远端 ~150ns+，差距近2倍
优化方案：CPU绑核（taskset/numactl）、内存本地化、K8s拓扑管理策略

虚拟化面试题 #

3. KVM有哪些半虚拟化设备？为什么比全虚拟化快？ #

答案：

设备	全虚拟化	半虚拟化（Virtio）	提升原因
网卡	e1000	virtio-net	减少VM Exit
磁盘	IDE	virtio-blk/scsi	批量提交+零拷贝
balloon	无	virtio-balloon	动态内存回收
GPU	无	virtio-gpu	图形加速

原理：全虚拟化每次IO需要VM Exit（陷入宿主内核），半虚拟化通过前后端驱动协作，批量处理减少VM Exit次数。

4. 什么是SR-IOV？与virtio有何区别？ #

答案：

对比项	Virtio	SR-IOV
原理	前后端驱动	硬件虚拟化（PF/VF）
路径	经过宿主内核	直接透传到VM
性能	高	极高（接近物理机）
灵活	支持热插拔/迁移	迁移受限
适用	通用场景	极致网络性能

操作系统面试题 #

5. epoll的LT和ET模式有什么区别？ #

答案：

模式	触发条件	编程要求	适用
LT	缓冲区有数据就通知	简单，不用一次读完	简单场景
ET	新数据到来时通知一次	必须一次读完（循环read/accept）	高性能场景（Nginx/Redis）

ET模式为什么更快：减少epoll_wait调用次数，减少系统调用开销。

6. io_uring相比传统AIO有什么优势？ #

答案：

对比项	传统AIO	io_uring
系统调用	每个IO一次	批量提交+收割
缓冲区	用户/内核拷贝	支持注册固定缓冲区（零拷贝）
轮询模式	无	SQPOLL内核线程轮询
扩展性	差	支持百万级并发

网络面试题 #

7. LVS的NAT、DR、TUN三种模式区别？ #

答案：

模式	流量路径	性能	网络要求	RS要求
NAT	Client→Director→RS→Director→Client	低（Director瓶颈）	无	无需VIP
DR	Client→Director→RS→Client	高（RS直连）	同一网段	lo绑定VIP
TUN	Client→Director→IP隧道→RS→Client	高	支持跨网段	支持IP隧道

8. BBR拥塞控制为什么比CUBIC好？ #

答案：

CUBIC：基于丢包判断拥塞（有丢包才降速），高延迟+高带宽链路利用率低
BBR：基于带宽和RTT建模，主动探测带宽上限，不依赖丢包
优势：高延迟链路吞吐量提升2-25倍，减少缓冲膨胀（bufferbloat）

存储面试题 #

9. RAID5和RAID10如何选择？ #

答案：

场景	推荐	原因
数据库（高写）	RAID10	写性能好，50%利用率
文件服务（读多）	RAID5	空间利用率高，读性能好
归档存储	RAID6/EC	空间利用率高，容错能力强
随机写密集	RAID10	无写惩罚

容器面试题 #

10. K8s中Pod QoS等级是什么？如何保证关键Pod不被驱逐？ #

答案：

QoS	条件	优先级	驱逐顺序
Guaranteed	requests == limits	最高	最后被驱逐
Burstable	requests < limits	中	内存超Limit时按优先级
BestEffort	无requests/limits	最低	最先被驱逐

保证关键Pod：

设置Guaranteed QoS（requests == limits）
配置PriorityClass（system-cluster-critical）
配置PDB（PodDisruptionBudget）
节点Pod反亲和性

安全面试题 #

11. SELinux和AppArmor有什么区别？ #

答案：

对比项	SELinux	AppArmor
模型	TE（Type Enforcement）DAC+MAC	路径-based MAC
粒度	更细（文件、端口、IPC等）	较粗（基于路径）
配置	复杂，学习曲线高	简单，配置文件直观
默认	RHEL/CentOS	Ubuntu/Debian
适用	高安全要求	快速部署

可观测性面试题 #

12. eBPF为什么被称为Linux可观测性的革命？ #

答案：

内核级可观测：直接在内核hook点采集数据，零侵入
低开销：JIT编译为机器码，性能接近原生
安全：验证器确保程序不会crash内核
统一：一套技术覆盖网络、存储、安全、性能全栈
工具丰富：bcc、bpftrace、Cilium、Tetragon等

资源优化面试题 #

13. KVM虚拟化中CPU超卖是如何实现的？ #

答案：

原理：物理CPU时间片在多个vCPU间轮转分配
宿主调度：KVM作为QEMU进程参与Linux CFS调度
超卖比：vCPU总数 / 物理CPU核数，推荐4:1以内
风险：CPU密集型VM竞争激烈，导致性能抖动
控制：cgroups限制CPU配额，CPU shares权重分配

14. 容器中requests和limits的最佳实践？ #

答案：

场景	requests	limits	QoS
关键服务	= limits	= requests	Guaranteed
普通服务	历史P50	2× requests	Burstable
批处理	适当设置	不设或大	Burstable/BestEffort
不要	不设	不设	BestEffort（不可控）

优化方法：VPA根据历史使用自动推荐、Kubecost分析资源浪费

🔗 相关笔记 #

最后更新: 2026-05-06