Bulkhead — bir qismdagi nosozlik yoki ortiqcha yuk butun tizim resurslarini egallamasligi uchun workloadlarni alohida pool, queue yoki failure domainlarga ajratish resilience usulidir. Atama kemadagi suv o‘tmaydigan bo‘limlardan olingan: bitta bo‘lim shikastlansa, qolganlari suzishni davom ettiradi.
Dasturiy izolyatsiya
Bir xil thread pool barcha tashqi xizmat chaqiruvlariga ishlatilsa, bitta sekin dependency threadlarni to‘liq band qilishi mumkin. Bulkhead har dependency yoki muhim workload uchun alohida pool va concurrency limit beradi. Sekin xizmat o‘z bo‘limini to‘ldiradi, boshqalari esa resurs olishda davom etadi.
Queue bulkhead ham cheklangan bo‘ladi. Navbat to‘lganda yangi ish aniq xato yoki fallback bilan rad etiladi. Cheksiz queue izolyatsiyani buzadi, chunki xotira va latency umumiy tizimga tarqaladi. Limit real service time va talab taqsimotiga asoslanadi.
Izolyatsiya darajalari
Thread yoki connection pool eng yengil shakl. Process va container CPU, memory hamda descriptor limitlari bilan kuchliroq chegara beradi. Alohida node, zone yoki cluster fizik va operatsion failure domainni ajratadi, lekin narx va boshqaruv murakkabligi oshadi.
Multi-tenant tizimda har tenant uchun qat’iy alohida resurs berish qimmat bo‘lishi mumkin. Guruhlash, weighted fair queue va per-tenant quota noisy neighbor ta’sirini kamaytiradi. Premium hamda batch workloadlar turli priority va poolga joylashtirilishi mumkin.
Boshqa resilience usullari
Timeout sekin amal resursni qancha vaqt ushlashini cheklaydi. Circuit breaker takroran muvaffaqiyatsiz dependency’ga so‘rovni to‘xtatadi. Rate limit kiruvchi talabni boshqaradi. Bulkhead esa muvaffaqiyatsizlik sodir bo‘lsa uning resurs ta’sirini ma’lum bo‘limda ushlab turadi.
Retry noto‘g‘ri qo‘llansa bulkhead queue’sini tez to‘ldiradi. Retry budget, exponential backoff va jitter talabni nazorat qiladi. Fallback ham cheksiz resurs ishlatmasligi va bir xil nosog‘lom dependency’ga yashirin qaytmasligi kerak.
Loyihalash
Avval kritik user journey va dependency’lar xaritasi tuziladi. Bir-biridan mustaqil qolishi kerak bo‘lgan trafik sinflari aniqlanadi. Har bo‘lim uchun concurrency, queue, timeout va rejection semantikasi belgilanadi. Juda mayda bo‘linish resursdan foydalanishni samarasiz qilib, operatsiyani qiyinlashtirishi mumkin.
Pool sig‘imi Little’s Law, o‘lchangan latency va maqsad throughput asosida taxmin qilinadi, keyin load test bilan tekshiriladi. Runtime’da active worker, queue depth, reject rate, wait time va dependency latency kuzatiladi. Bir pool doim bo‘sh, boshqasi doim to‘la bo‘lsa taqsimot qayta ko‘riladi.
Nosozlik sinovi
Chaos test dependency’ni sekinlashtirib yoki xato qaytarib, faqat unga tegishli bo‘lim to‘lishini tekshiradi. Asosiy xizmatlar SLO doirasida qolishi kerak. Dashboard umumiy o‘rtacha bilan cheklanmay, bulkheadlar kesimida metrika ko‘rsatadi; aks holda lokal saturation yashirin qoladi.
Sig‘imni qarzga berish
Qat’iy bo‘lim bir pool bo‘sh turganda boshqasining so‘rovini rad etishi mumkin. Work-conserving scheduler bo‘sh sig‘imni vaqtincha qarzga beradi, lekin egasi talab qilganda qaytarib oladi. Bu utilizationni oshiradi va minimal kafolatni saqlaydi. Bunday dinamik siyosat murakkabroq: preemption xavfsiz bo‘lishi, bir tenant doimiy qarzni egallamasligi va priority inversion yuz bermasligi kerak. Connection poolni bo‘lishishda database’ning umumiy maksimal connection limiti ham hisobga olinadi; aks holda alohida bulkheadlar yig‘indisi backendni baribir tugatadi.
Har bulkhead uchun alohida alert va runbook bo‘lsa, operator umumiy tizimni qayta ishga tushirmasdan aynan to‘lgan bo‘limga choralar ko‘radi.
Bog‘liq tushunchalar
Fault isolation, Circuit breaker, Thread pool, Load shedding, Noisy neighbor, Resilience