Bulkhead Pattern

在微服务架构中，单个应用程序被分解为数十或数百个独立的协作服务。虽然这种设计提高了模块化性和可扩展性，但它也带来了一个重大风险：一项服务的故障可能会级联并导致整个系统瘫痪。 如果下游服务变得缓慢或无响应，则对上游服务的传入请求将开始堆积。如果它们都共享相同的内存、CPU 或线程池，则缓慢的依赖关系可能会快速耗尽所有可用资源，导致整个应用程序崩溃。 这种级联失败被称为多米诺骨牌效应。为了防止这种情况，系统架构师使用 Bulkhead 模式。 在本指南中，我们将探讨 Bulkhead 模式是什么、它是如何工作的，以及如何使用简单的类比、架构概念以及 Java (Resilience4j) 和 Go 中的代码示例来实现它。 现实世界的类比：水密船舶舱壁 这种图案的名字来源于造船业。 舱壁是建在船体内部的水密墙。船体内部不是一个单一的、巨大的开放空间，而是被分成几个独立的密封隔间。 如果船与障碍物相撞并且船体破裂，水就会涌入受损的舱室。然而，由于水密舱壁的存在，水被限制在单个隔间中。船的其余部分保持干燥和浮力，使其能够保持漂浮并到达安全地带。 如果没有舱壁，水会在整个船体中自由流动，最终导致船舶沉没。 在软件工程中： The Ship 是您的整个应用程序或服务。 隔间是隔离的资源池（线程、连接、CPU）。 船体破裂是下游微服务的故障或速度减慢。 洪水是资源耗尽。 问题：共享资源池和线程耗尽 为了理解为什么需要隔板，让我们看看当资源在全球范围内共享时会发生什么。 想象一下 API 网关或处理用户请求的 Web 服务器。它有一个包含 100 个线程的全局线程池来处理所有传入呼叫。服务器与三个下游服务交互： 目录服务（快速，读取产品列表） 支付服务（快速、流程结帐） 推荐服务（慢，计算个性化物品） 正常情况下，一切正常。但假设推荐服务遇到数据库死锁，并且开始需要 30 秒而不是 200 毫秒来响应。 发生的情况如下： 用户持续访问首页，触发推荐服务请求。 服务器从全局池中为每个请求分配一个线程。 由于推荐服务速度较慢，因此这些线程会等待响应。 几秒钟内，池中的所有 100 个线程都在等待推荐服务。 当新用户尝试结账或查看目录时，服务器没有剩余线程来处理他们的请求。 尽管目录和支付服务完全健康，但它们现在无法访问，因为缓慢的推荐服务耗尽了共享线程池。整个系统已经离线。