Auto-Scaling RTSP Streaming Arkitektur med Dobbelt Orkestratorer & Ingen Pakke Tab
En overvågningsplatform havde behov for at skalere sin videostreaming-infrastruktur dynamisk — håndtering af alt fra 10 til 200+ IP-kameraer med hundreder af samtidige seere og AI-behandlingsarbejdere — samtidig med at garantere nul pakkeforsinkelse under skaleringsoperationer og opretholde stabile stream-URL'er, der aldrig ændrer sig.
Diskuter Dit Projekt
Udfordringen
Fast streaming-infrastruktur kunne ikke håndtere de varierende krav fra en voksende overvågningsplatform:
- Skalavariabilitet — Antallet af kameraer og seerkrav svingede dramatisk i løbet af dagen (10x top-til-dal forhold)
- Overprovisioneringsomkostninger — Provisionering til topbelastning betød 70%+ inaktive ressourcer i lavbelastningsperioder
- Pakketab under skalering — Tilføjelse eller fjernelse af streaming-servere forårsagede stream-afbrydelser, der tabte billeder for AI-behandlingsarbejdere
- URL-ustabilitet — Kameraer og seere konfigureret med specifikke server-IP'er skulle rekonfigureres, når infrastrukturen ændrede sig
- Forskellige skaleringsbehov — Kameraindtagelse og seerdistribution havde fundamentalt forskellige belastningsmønstre, der krævede uafhængig skalering
- AI-arbejderforstyrrelse — AI-behandlingspipelines styrtede ned, når deres kilde-stream-server blev skaleret ned
Vores Løsning
Vi designede en dobbelt-orkestrator auto-scaling streaming arkitektur med separate indtags- og distributionsklynger, en 5-fase yndefuld nedlukning for nul pakke tab, stabile DNS-baserede URL'er og automatiseret AI-arbejder genforbindelse.
Arkitektur
- Streaming Server: MediaMTX til RTSP/WebRTC/HLS protokol support
- Indtagsklynge: 1-10 servere modtager kamera RTSP streams
- Distributionsklynge: 2-20 servere betjener seere (WebRTC/HLS) og AI-arbejdere (RTSP)
- Dobbelt Orkestratorer: Uafhængige skaleringskontrollere for indtagelse og distribution
- Load Balancers: Separate load balancers per klynge med protokol-passende algoritmer
- Service Registry: Redis til serverstatus, stream mapping og koordinering
- Sundhedsovervågning: Aktive sundhedstjek med automatiseret genopretning
- DNS Lag: Stabile domænenavne, der peger på load balancers (URL'er ændrer sig aldrig)
Dobbelt Orkestrator Design
Hvorfor To Orkestratorer
Indtagelse og distribution har fundamentalt forskellige skaleringskarakteristika:
- Indtagelse skalerer med antallet af kameraer og indgående båndbredde (forudsigelig, vokser jævnt)
- Distribution skalerer med antallet af seere og AI-arbejder efterspørgsel (sprængvis, uforudsigelig)
Separate orkestratorer tillader hver at skalere uafhængigt med specialiserede politikker, metrikker og tærskler — uden at den ene klynges skaleringsbeslutninger påvirker den anden.
Indtagsorkestrator
- Primær Metrik: Kamera forbindelser per server
- Sekundær Metrik: Indgående båndbreddeudnyttelse
- Skal Op: Når CPU overskrider tærskel eller kameraer per server overskrider kapacitet
- Skal Ned: Når udnyttelse falder under tærskel i en vedvarende stabiliseringsperiode
- Serverområde: 1 til 10 servere
Distributionsorkestrator
- Primær Metrik: Seer + AI-arbejder forbindelser per server
- Sekundær Metrik: Udgående båndbreddeudnyttelse
- Skal Op: Når CPU overskrider tærskel eller forbindelser per server overskrider kapacitet
- Skal Ned: Når udnyttelse falder under tærskel i en vedvarende periode (længere stabilisering end indtagelse)
- Serverområde: 2 til 20 servere (minimum 2 for høj tilgængelighed)
Ingen Pakke Tab: 5-Fase Yndefuld Nedlukning
Når en distributionsserver er planlagt til fjernelse, sikrer en 5-fase proces, at ingen billeder går tabt:
Fase 1: ForhåndsmeddelelseServer markeret som "DRAINING" i service registry. Load balancer vægt reduceret, så nye forbindelser rutes andre steder. Redis pub/sub meddelelser og webhooks advarer AI-arbejdere om at forberede sig på migration.
Fase 2: Load Balancer OpdateringServer fjernet fra load balancer backend pool. Ingen nye forbindelser kan nå den drænende server. Eksisterende forbindelser fortsætter uafbrudt.
Fase 3: AI Arbejder MigrationAI-arbejdere afbryder forbindelsen fra den drænende server og genopretter forbindelse til sunde distributionsservere. Checkpoint-baseret tilstandsbevarelse sikrer, at behandlingen genoptages fra det præcise billede, hvor det blev afbrudt. Total pause: cirka 3 sekunder uden tab af billeder.
Fase 4: Seer DræningResterende seerforbindelser drænes naturligt over et konfigurerbart vindue. Moderne videospillere genopretter automatisk forbindelse til den samme stabile URL, som ruter til sunde servere. De fleste seere oplever ingen afbrydelse.
Fase 5: OprydningBekræft, at alle forbindelser er lukket. Fjern server fra service registry. Ødelæg skyinstansen. Registrer skaleringsmetrikker.
Stabile URL'er
URL-arkitekturen sikrer, at kameraer og klienter aldrig behøver rekonfiguration:
- Kamera publiceringsmål: Et stabilt indtagsdomænenavn
- Seer/AI adgangsmål: Et stabilt distributionsdomænenavn
- DNS-poster peger på load balancer IP'er (som er permanente)
- Load balancers håndterer routing til backend-servere gennemsigtigt
- Backend-servere kan tilføjes, fjernes eller udskiftes uden URL-ændringer
Service Registry (Redis)
En centraliseret Redis-instans koordinerer hele systemet:
- Serverstatussporing (aktiv, drænende, offline)
- Stream-til-server mapping (hvilket kamera er på hvilken indtagsserver)
- AI-arbejder tilstand og checkpoint data
- Belastningsmetrikker per server til skaleringsbeslutninger
- Pub/sub kanaler til realtidskoordinationsbegivenheder
AI Klient Genforbindelse
Et AI klientbibliotek giver problemfri genforbindelse:
- Lytter efter serverfjernelsesmeddelelser via Redis pub/sub
- Automatisk billedcheckpointing med jævne mellemrum
- Genforbindelse til en sund distributionsserver ved meddelelse
- Genoptag behandling fra checkpoint med minimal pause
- Metrikrapportering for genforbindelsesbegivenheder
Sundhedsovervågning
- Aktive sundhedstjek på hver server med jævne mellemrum
- Automatiske load balancer opdateringer ved serverfejl
- Auto-genopretningstriggere for ikke-responsive servere
- Oppetidssporing og tilgængelighedsrapportering
Nøglefunktioner
- Dobbelt Orkestratorer — Uafhængig skalering for indtags- og distributionsklynger
- Ingen Pakke Tab — 5-fase yndefuld nedlukning med AI-arbejder migration
- Stabile URL'er — DNS-baseret routing sikrer, at URL'er aldrig ændrer sig under skalering
- AI Arbejder Genforbindelse — Checkpoint-baseret migration med ~3 sekunders pause og ingen tab af billeder
- Uafhængig Skalering — Indtagelse og distribution skalerer baseret på deres egne metrikker
- Service Registry — Redis-baseret koordinering for serverstatus og stream mapping
- Sundhedsovervågning — Aktive tjek med automatisk genopretning
- Omkostningsoptimering — Automatisk skalering ned i perioder med lav efterspørgsel
Resultater
Teknologistak
caseStudyDetail.more Casestudier
Udforsk flere af vores tekniske implementeringer
AI-drevet fakturabehandling med OCR og QuickBooks-integration
En mellemstor virksomhed, der månedligt behandler hundredvis af leverandørfakturaer, havde brug for at eliminere manuel dataindtastning ved automatisk at udtrække fakturadata ved hjælp af AI/OCR og synkronisere dem direkte til QuickBooks for bogføring og sporing af betalinger.
Klient-side annonceindsættelse (CSAI) med SCTE-35-markørparsing og integration af afspillere på flere platforme
En videostreamingplatform skulle implementere klient-side annonceindsættelse (CSAI) på tværs af web-, mobil- og connected TV-apps – hvilket muliggjorde personaliserede annonceringer på enhedsniveau med fuld support for annonceinteraktion (klikbare overlays, følgebannere, skip-knapper), som server-side indsættelse ikke kan tilbyde.
Klar til at Transformere Din Virksomhed?
Lad os drøfte, hvordan vi kan anvende lignende løsninger til dine udfordringer.