舱壁模式核心是为每个服务或依赖单元设置独立资源边界，通过线程池隔离（如feign接口专属线程池）、多租户逻辑分组、基础设施配额（k8s limits、istio连接池）及熔断降级闭环，实现故障不扩散。
微服务之间实现舱壁模式隔离，核心是让每个服务或依赖单元拥有独立资源边界，避免一个出问题拖垮全部。它不是靠“断开连接”，而是靠“划清地盘、配好份额、守住底线”。
按调用方维度做线程池隔离
这是最常见也最直接的舱壁落地方式。比如用 Spring Cloud Alibaba Sentinel 或 Hystrix 时，为每个远程 Feign 接口单独配置线程池：
- 给订单服务调用用户服务分配独立线程池（如 20 线程 + 队列长度 10）
- 给订单服务调用库存服务再配另一组（如 15 线程 + 队列长度 5）
- 当库存服务响应变慢或超时，只耗尽它的那 15 个线程，用户服务调用不受影响
按业务身份或租户做逻辑分组隔离
面向多租户或分级客户场景，把流量和资源按身份硬性切片：
- VIP 租户走专属服务实例组（K8s 中用 label selector + deployment 分离部署）
- 免费用户走共享集群，但通过网关路由规则限制其最大并发数与请求超时时间
- 不同租户使用各自独立的 Redis 连接池、数据库连接池，不共用连接句柄
在基础设施层设置硬性资源配额
光靠代码层隔离不够，必须结合容器与调度平台做兜底：
- Kubernetes 中为每个微服务 Pod 设置 requests/limits：CPU 0.5 核、内存 512Mi、GPU 显存 2Gi（如有）
- 服务网格（如 Istio）中为每个服务对配置 connection pool settings：最大连接数、空闲连接超时、健康检查阈值
- API 网关（如 Kong、Envoy）按 route 级别设 rate limit 和 circuit breaker，故障触发后仅封禁该路径，不影响其他接口
配合熔断与降级形成闭环防护
舱壁隔离解决的是“资源不被抢走”，但无法阻止上游持续发错请求。需叠加主动防御：
- 对下游服务失败率超过 50% 持续 10 秒，自动触发熔断，后续请求快速失败而非排队等待
- 熔断期间返回预设降级结果（如缓存数据、静态兜底页、空对象），保障主流程可用
- 降级逻辑与主逻辑分离部署，避免降级代码缺陷反过来污染正常链路
