Taktinen viestintäarkkitehtuuri: NATS vs Kafka vs MQTT C2-järjestelmiin

Taktinen komento- ja valvontajärjestelmä on hajautettu sovellus, joka toimii radioiden, ajoneuvojen, jalkamiestoimijoiden ja takaosa-palvelimien välillä. Viestiväylä on selkäranka. Valitse väärä ja järjestelmä tuntuu nopealta laboratoriossa ja kuolee kiisteltyyn linkkiin. Valitse oikea ja operaattori näkee fuusioidun kuvan päivittyvän päätössyklinsä sisällä.

Tämä artikkeli käy läpi neljä ehdokasta, jotka todella esiintyvät tuotanto-C2-rakennuksissa — NATS, Apache Kafka, MQTT ja RabbitMQ — ja esittää päätöskehyksen niiden välillä valitsemiseksi. Lyhyt versio: ei ole yhtä vastausta. Todelliset järjestelmät käyttävät kahta tai kolmea, yhdistettynä silloilla.

1. Taktinen viestintäongelma

Taktiset verkot eivät ole konesaliverkkoja. Kaistanleveys tyypillisessä VHF-taisteluradiossa mitataan kilobitteinä sekunnissa, ei megabitteinä. Pyöristysajat MANET-verkon (mobiili ad-hoc-verkko) yli ylittävät rutiininomaisesti 500ms. Pakettihäviö yli 20% on normaali häirintätilanteessa. Linkit flappivat kun alustat liikkuvat maaston taakse. Satcom-yhteyskaista ruuhkautuu aamutyönnön aikana ja uudelleen pimeäntulon aikaan.

Operaattori ei siedä vanhentunutta dataa. Fuusioitu jälki, joka on kaksi minuuttia vanha, on huonompi kuin ei jälkeä ollenkaan — se esittää itsevarmasti valheen siitä, missä uhka on. Väylän on siksi toteutettava viestin vanhentuminen, priorisoitava tuore tila ruuhkan yli ja heikennettävä sulavasti, kun linkki palautuu osion jälkeen sen sijaan, että se kaatuisi kymmenen minuutin jononäisessä telemetriassa kerralla.

Järjestys on myös tärkeä, mutta ei tasaisesti. Telemetriaa voidaan yhdistää (vain viimeisin sijainti on tärkeä). Komentoja ei voida — myöhässä saapunut T+3:ssa annettu "weapons free" ei saa ohittaa T+5:ssä annettua "weapons hold". Väylällä on oltava erilaiset toimitustarkoitukset aiheittain, ei yksi globaali takuu.

Lopuksi väylän on selviydyttävä osiosta. Kun radiolinkki palaa viiden minuutin keskeytyksen jälkeen, kolme käyttäytymistapaa on väärää: kaikkien jonossa olevien viestien kaaataminen kerralla (ylikuormittaa kuluttajan), kaiken hiljaisesti hylkääminen (menettää järjestetyt komennot) ja uudelleenjärjestäminen saavutuksen aikana (toimittaa vanhentunut weapons-free tuoreen weapons-holdin jälkeen). Oikea käyttäytyminen on aiheittainen: telemetrian yhdistäminen toipumisen yhteydessä, järjestetty tyhjennys aikaleimoin komennoille, täydellinen uusinta auditointilokeille. Mikään yksittäinen toimitusmalli ei tyydytä kaikkia kolmea.

2. NATS ja JetStream

NATS on pieni, mielipiteellinen julkaise-tilaa-väylä, kirjoitettu Golla. Yksittäinen binääri, ei ulkoisia riippuvuuksia, oletuksena muistissa olevat aiheet ja alle millisekunnin julkaise-toimita-viive lähiverkossa. Jalanjälki on kymmenissä megatavuissa — pieni riittää ajoneuvon tietokoneelle tai karsitulle reunasolmulle.

Ydin-NATS on tulipalojen-ja-unohda. JetStream on pysyvyyskerros lisätty vuonna 2020: kestävät virrat, uusinta sekvenssillä tai ajalla, kuluttajaosoittimet, viestin vanhentuminen ja per-aihe duplikaationpoistamisikkuna. JetStream käyttää Raftia replikaatiolle. 3-solmuinen JetStream-klusteri on vakio taktinen ydin käyttöönotto — kvorumi selviää yhden solmun menetyksestä ja virrat replikoituvat ilman erillistä Zookeeper-tyylinen koordinaattori.

NATS voittaa, kun hallitseva liikenne on pieniä, tiheitä, matalaviiveisiä viestejä palveluiden välillä — komennot, fuusioitujen jälkien päivitykset, mikropalvelun RPC pyyntö-vastaus-aiheiden kautta. Se on oletusviestiväylä palvelu-palvelu-liikenteelle fuusiomoottorin sisällä.

Missä se hajoaa: JetStreamin replikaatio on erinomainen klusterin sisällä mutta se ei ole suunniteltu kattamaan heikentynyttä WAN:ia. Lehtsolmut voivat laajentaa NATS-topologiaa reunalaitteisiin, mutta jos lehti on offline-tilassa tuntikausia, saavutusikkuna on rajattu virran säilytyksellä — ei lehden odotuksilla. Käsittele NATS ydinviestiväylänä, ei laajakalvaisena väylänä.

Vikasietoisuuden kompromissi, jonka kannattaa mainita: JetStream Raft -kvorumi vaatii enemmistöä replikoilta kuittaamaan kirjoituksen. 3-solmuklusteissa se tarkoittaa kahta kuittausta. Jos yksi solmu on alhaalla huollon vuoksi ja toinen menettää levyn, kirjoitukset pysähtyvät — klusteri säilyttää johdonmukaisuuden saatavuuden kustannuksella. Taktiselle ytimelle tämä on oikea valinta; operatiivisen kuvan johdonmukaisuus on neuvottelematon. Mutta operaattorimalli on tärkeä: älä käytä JetStream 3-solmuklustereita, joissa kaksi solmua jakavat yhden vikakohdan kuten yhden kytkimen tai yhden virtansyötön.

3. Apache Kafka

Kafka on kestävyysmestari. Lisäysloki per osio, konfiguroitava replikointikerroin per aihe, säilytys mitattuna päivissä tai viikoissa ja kuluttajamalli, joka antaa uusien asiakkaiden uusia historian nollasta offsetista. Jälkitoimintatarkastelua, auditointilokeja ja analytiikkaa historiallisesta operatiivisesta datasta varten Kafka on lähes aina oikea vastaus.

Se on myös kallis. Tuotanto-Kafka-klusteri haluaa vähintään kolme välittäjää, nopeita paikallisia levyjä, gigatavuja sivuvälimuistia ja joko Zookeeperinä (perintö) tai KRaftin (nykyinen, Kafka 3.3 GA:sta lähtien loppuvuodesta 2022, oletus 3.5+). Osioiden tasapainotus verkkoosion alla on tunnettu operatiivinen riski. Kuluttajaryhmän koordinointi olettaa vakaan yhteyden ryhmäkoordinaattorivälittäjälle.

"Kafka kaikkeen" -malli, joka toimii pilviohjattuissa kaupoissa, epäonnistuu taktisella reunalla kolmesta syystä. Ensinnäkin resurssien jalanjälki on väärä — JVM-pohjainen välittäjä tuulettomalla reunalaatikolla häviää NATS-binäärille joka kerta. Toiseksi Kafkan vahva kestävyys oletuksena rankaisee sinua korkeahäviöisellä linkillä: tuottajat pysähtyvät odottaessaan kuittauksia. Kolmanneksi operatiivinen monimutkaisuus (välittäjäkonfiguraatio, aiheen osiointistrategia, säilytyssäätö, ISR-seuranta) on perustelematon, kun laite on miehittämätön eteentyönnetyssä asemassa.

Kafka kuuluu strategiselle tasolle — takaosa-klusterille, joka ottaa aggregoituja tapahtumavirtoja eteenpäin käyttöönotetuista yhdyskäytävistä ja tarjoaa ne analytiikalle, koulutustietoputkille ja pitkäaikaisarkistoille.

4. MQTT

MQTT suunniteltiin 1999 öljyputkiston telemetriaan satelliittilinkillä — juuri se verkkoparametri, jonka taktinen sensorverkko esittää nykyisin. Pieni otsakkeen ylimäärä (2-tavu kiinteä otsake minimaalitapauksessa), kolme palveluntasoa (0 tulipalo-ja-unohda, 1 vähintään-kerran, 2 täsmälleen-kerran) ja aiheehierarkia, joka kartoittuu luonnollisesti sensori → yksikkö → porrastusrakenteisiin.

MQTT 5.0, viimeistelty 2019, lisäsi ominaisuudet, jotka tekevät siitä operatiivisesti vakavan puolustuskäyttöön. Jaetut tilaukset ($share/ryhmä/aihe) kuormittavat aihetta kuluttajaryhmässä — hyödyllinen anturidatan fan-out-käsittelyyn. Viestin vanhentumisvälit hylkäävät vanhentunut taktinen data automaattisesti välittäjällä. Käyttäjäominaisuudet kantavat luokitusmerkintöjä ja julkaisumerkintöjä viestimetatiedoina. Aihealiastukset puristavat toistuvia pitkiä aihemerkkijonoja yhteen tavuun ensimmäisen julkaisun jälkeen — todellinen voitto 9600 bps radiolla.

Välittäjäpuoli on kypsä: Mosquitto pienille jalanjäljille, EMQX tai HiveMQ suurempiin klusteroituihin käyttöönottoihin jaetuilla tilauksilla ja silloilla. Kaikki kolme toimivat reuna-luokan laitteistolla. MQTT-SN (Sensor Networks) laajentaa protokollaa ei-TCP-kuljetusten yli todella pienille — paristokäyttöisille antureille ilman IP-pinoa.

MQTT:n heikkous on kestävyys. Pysyvät istunnot ja QoS 2 antavat luotettavan toimituksen tunnetulle asiakkaalle, mutta MQTT ei ole tapahtumoloki — ei ole uudelleentoisto-offsetilla-semantiikkaa. Jos kuluttaja katkaisee yhteyden istuntonsa vanhentumisen jälkeen, viestit ovat hävinneet. Anturin telemetrialle se on hyväksyttävää. Auditointijäljelle se ei ole.

5. RabbitMQ ja AMQP

RabbitMQ edeltää pilviohjattua viestintäaaltoa ja ansaitsee edelleen paikkansa. AMQP 0-9-1 -malli — vaihdot, sidokset, jonot — antaa reititysjoustavuutta, jota julkaise-tilaa-väylät eivät pysty tarjoamaan. Aihevaihdot yleismerkkisidoksilla, otsikkovaihdot sisältöpohjaiseen reititykseen, kuolleiden kirjainten jonot epäonnistuneille viesteille, per-jono TTL:t ja per-viestikuittaus uudelleentoimitusmäärällä.

Työnkuluille, joissa viestin on käsiteltävä täsmälleen kerran täsmälleen yhdellä työntekijällä, eksplisiittisellä kuittauksella ja uudelleenyrityssemantiikalla, RabbitMQ on edelleen siistim vastaus. Esimerkkejä C2-pinossa: tehtävätyönkulut, joissa jokainen tehtävä menee yhdelle operaattorille, geokoodauspyynnöt, jotka osuvat ulkoiseen palveluun, OCR-tehtävät taltioidun kuvan perusteella. Nämä ovat jono-ongelmia, ei virta-ongelmia, ja jono-semantiikka on mitä RabbitMQ tekee.

Havaittavuus on toinen hiljainen vahvuus — hallintaliittymä, Prometheus-viejä ja per-jono-mittarit tekevät siitä helpoimmaksi neljästä käyttää klo 03:00, kun jokin menee vikaan. Pienelle ops-tiimille, joka käyttää miehittämätöntä taktista pilveä, se on tärkeää.

RabbitMQ:n rajat näkyvät erittäin korkealla läpäisyllä (se ei ole miljoona-viestiä-sekunnissa-väylä) ja epävakailla verkoilla (yhteysorientoitunut AMQP-malli ei pidä linkkihuojuntaa). Käytä sitä työnkulkukerrokselle, ei telemetriavirralle.

6. Väylien yhdistäminen silloilla

Tuotanto-C2-järjestelmät käyttävät kahta tai kolmea väylää samanaikaisesti. Edustava käyttöönotto: MQTT reunalla sensori- ja radioliikenteelle, NATS taktisessa ytimessä palvelu-palvelu-komennoille ja fuusioiduille jäljille, Kafka strategisella tasolla kestävää tapahtumaarkistoa varten. RabbitMQ voi esiintyä NATS:n rinnalla työnkulkukerrokselle.

Sillat ovat ensiluokkaisia komponentteja, ei jälkiajatuksia. MQTT-NATS-yhdyskäytävä tilaa valitut MQTT-aiheet, muuntaa hyötykuorman kanoniseen sisäiseen skeemaan ja julkaisee uudelleen NATS-aiheelle. NATS-Kafka-silta kuluttaa JetStream-virtoja ja tuottaa Kafka-aiheille samalla osioavainstrategialla. Skeeman kääntäminen, takaisinpaineen käsittely ja idempotenten uudelleenjulkaisu sillan uudelleenkäynnistyksen yhteydessä ovat vaikeat osat — ei itse yhteys.

Rakenna sillat samalla insinöörikurilla kuin mikä tahansa muu palvelu: terveystarkistukset, mittarit, määritelty uudelleentoistomenettely uudelleenkäynnistyksen yhteydessä ja selkeä omistajuus. Klassinen vikatila on silta, joka hiljaisesti pudottaa viestejä kuormituksen alla, koska sen sisäinen jono on ylivuotanut.

7. Turvallisuus ja luokittelu

Jokainen väylä puhuu TLS:ää. Jokainen väylä tukee molemminpuolista TLS:ää asiakasvarmennekuiten kanssa. Se on välttämätöntä, mutta ei riittävää.

Per-verkkosaarekkeen eristys on seuraava kerros: erillinen välittäjäinstanssi erillisellä varmenneviranomaisella kullekin luokitustasolle. Väylä SECRET-verkkosaarekkeen sisällä ei koskaan puhu suoraan väylälle UNCLASSIFIED-verkkosaarekkeen sisällä. Toimialueiden välinen julkaisu menee hyväksytyn suojauksen tai toimialueiden välisen ratkaisun kautta, joka poistaa, muuntaa ja julkaisee uudelleen — ei koskaan välittäjäsillan kautta.

Per-aihe-ACL:t ovat kolmas kerros. NATS:lla, tilit ja aihekäyttöoikeudet. MQTT:lla, välittäjän ACL-tiedostot tai laajennus. Kafkalla, ACL:t AdminClient API:n kautta. RabbitMQ:lla, käyttäjä-vhost-resurssi-käyttöoikeudet. Oletus-kiellä on ainoa hyväksyttävä asento: palvelu voi julkaista ja tilata täsmälleen ne aiheet, joita sen rooli vaatii, eikä muita.

Viestien metatiedot kantavat luokitusmerkintöjä — MQTT 5 käyttäjäominaisuudet, NATS-otsikot, Kafka-otsikot. Välittäjä ei toteuta luokitussemantiikkaa; kuluttajapalvelut ja toimialueiden välinen suojaus tekevät sen. Välittäjä toteuttaa, kuka voi lukea mitä aihetta.

8. Päätöskehys

Pistytä jokainen liikenneluokka neljän akselin mukaan:

Viivebudjetti. Alle millisekunnin palvelu-palvelu-RPC: NATS. Kymmeniä millisekunteja anturitelemetrialle: MQTT. Sekunteja arkisto-ingestiolle: Kafka. Per-viestin työnkulun vaiheet kuittaussemantiikalla: RabbitMQ.

Läpäisy. Jopa noin 10k viestiä/sek per aihe vaatimattomalla laitteistolla: mikä tahansa neljästä. 100k+ jatkuvasti per aihe: NATS tai Kafka. Miljoonia monien aiheiden kautta: Kafka. Sensorin fan-in tuhansista matalan nopeuden asiakkaista: MQTT jaetuilla tilauksilla.

Kestävyys. Uusinta ei vaadita: ydin-NATS tai MQTT QoS 0/1. Uusinta istunnon tai lyhyen ikkunan sisällä: NATS JetStream, MQTT pysyvät istunnot. Monen päivän auditointilaatu-uusinta: Kafka. Per-viesti-kuittaus uudelleenyritys ja kuolleiden kirjainten jonoilla: RabbitMQ.

Reunaverkon todellisuus. 9600 bps radio 30% häviöllä: MQTT, aihealiastuksilla ja QoS 1. Taktinen lähiverkko ajoneuvon sisällä: NATS. Strateginen WAN takaosa-klusterille: Kafka yhdyskäytävällä edessä. Katkonainen satcom: MQTT telemetrialle, asynkroninen Kafka-tuottaja paikallisella keelalla arkistoon.

Rakenna matriisi omaa järjestelmääsi varten. Jokainen liikenneluokka kartoittuu yhteen väylään. Niiden väliset sillat ovat eksplisiittisiä. Käyttöönotto käyttää tarvitsemiaan väylä eikä enempää — väylän lisäämisellä on operatiivinen kustannus, ja se kustannus maksetaan jokaisella vuorolla, ei vain integraatioaikana.