4、故障隔离策略：进程级隔离（Cgroups）、容器级隔离（Docker/K8s）、资源配额与限流
故障隔离，说白了就是「别让一个坏了的零件，把整台机器拖垮」。在边缘节点上，资源本来就紧张，一个进程把CPU吃满，或者内存泄漏，其他服务全得跟着遭殃。我见过不少团队，一开始图省事，所有服务跑在一个进程里，结果一次OOM，整个节点挂了，连远程SSH都进不去——那叫一个狼狈。
所以，隔离是自愈的前提。你没法隔离故障，就谈不上自愈。今天咱们聊聊三种隔离手段：进程级、容器级、以及资源配额与限流。这三种手段，我建议你从底层到上层都掌握，因为不同场景下，它们各有各的用武之地。
4.1 进程级隔离：Cgroups 的硬约束
进程级隔离，最底层的功夫。Linux Cgroups（Control Groups）就是干这个的。它能把进程圈起来，限制它能用多少CPU、多少内存、多少磁盘IO。说白了，就是给每个进程画个圈，不许越界。
我个人习惯，在边缘节点上，所有核心服务都用 systemd 的 slice 来管理。举个例子，一个视频分析服务，我给它分配 2 个 CPU 核心、4GB 内存。这样就算它代码有bug，内存泄漏了，最多吃掉4GB，不会把整个系统拖垮。
# 创建一个 cgroup 并限制内存
mkdir /sys/fs/cgroup/memory/edge_video
echo 4G > /sys/fs/cgroup/memory/edge_video/memory.limit_in_bytes
echo 12345 > /sys/fs/cgroup/memory/edge_video/cgroup.procs嗯，这里要注意：Cgroups 的 CPU 限制分两种——份额（shares）和上限（quota）。份额是软限制，空闲时可以用更多；上限是硬限制，到了就不给用。我在项目中遇到过，一个日志采集进程设置了 CPU 份额，结果高峰期它抢了核心业务的资源，导致视频流卡顿。后来改成 CPU 配额上限，问题就解决了。
4.2 容器级隔离：Docker 与 K8s 的实践
容器级隔离，说白了就是给每个服务一个独立的「小房间」。Docker 容器通过命名空间（Namespace）实现了文件系统、网络、进程号的隔离。K8s 则更进一步，用 Pod 作为最小调度单元，把容器编排起来。
在边缘节点上，我推荐用 K8s 的 DaemonSet 来部署节点代理，用 Deployment 来部署业务服务。每个 Pod 设置资源 requests 和 limits，K8s 会自动调度和限制。
apiVersion: v1
kind: Pod
metadata:
name: edge-ai-inference
spec:
containers:
- name: inference
image: edge-ai:v1.0
resources:
requests:
memory: "2Gi"
cpu: "1"
limits:
memory: "4Gi"
cpu: "2"
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10这段配置里，requests 是保证的资源，limits 是上限。livenessProbe 是健康检查——如果容器挂了，K8s 会自动重启。我曾经遇到过一个情况：某个推理服务因为模型加载失败，进程没挂但接口不响应。livenessProbe 连续三次失败后，K8s 自动重启了 Pod，服务恢复了。这就是容器级隔离+自愈的典型场景。
4.3 资源配额与限流：从源头控制
隔离做好了，还得防流量冲击。资源配额和限流，就是给每个服务设定「流量天花板」。常见的做法有：
- 令牌桶算法：控制请求速率，比如每秒最多处理 100 个请求
- 漏桶算法：平滑突发流量，不管来多快，处理速度恒定
- 熔断器模式：错误率达到阈值，直接断开，防止雪崩
在边缘节点上，我常用 Nginx 的 limit_req 模块做 API 限流，或者用 Envoy 做更精细的流量控制。下面是一个 Nginx 限流的例子：
http {
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;
server {
location /api/ {
limit_req zone=api_limit burst=20 nodelay;
proxy_pass http://backend;
}
}
}这个配置的意思是：每个客户端 IP，每秒最多 100 个请求，允许突发 20 个。超过的直接返回 503。嗯，这里有个细节：burst 参数很关键。没有 burst，流量稍微波动就会丢请求；burst 太大，又起不到限流作用。我个人习惯，burst 设为 rate 的 20% 左右。
除了 API 限流，还有背压（Backpressure）机制。比如消息队列消费太慢，就主动告诉生产者「慢点发」。我在一个 IoT 项目中用过 Kafka 的背压：边缘节点处理不过来时，就降低消费速率，让消息堆积在 Kafka 里。等节点恢复，再慢慢消费。这样不会丢数据，也不会压垮节点。
4.4 三种隔离策略的对比
| 隔离维度 | 实现方式 | 隔离粒度 | 适用场景 | 自愈能力 |
|---|---|---|---|---|
| 进程级 | Cgroups | 单进程/线程组 | 系统服务、守护进程 | 弱（需外部监控） |
| 容器级 | Docker/K8s | 容器/Pod | 微服务、AI推理 | 强（自动重启） |
| 资源配额 | 限流/熔断 | API/服务 | 高并发、流量波动 | 中（降级保护） |
你看，三种策略各有侧重。我个人建议，在边缘节点上优先用容器级隔离，因为它自带健康检查和自动重启，自愈能力最强。进程级隔离作为兜底，防止容器逃逸或资源泄露。资源配额和限流，则是最后一道防线，防止流量冲击把整个节点打垮。
好了，这一章的内容就到这里。记住：隔离不是目的，自愈才是。把隔离做好了，自愈动作才能精准、高效。