Operare
Pagina asta e pentru cine ține platforma în funcțiune: ce e o instalație, cum se scalează, ce cere o repornire și ce rămâne pe disc.
Mai multe motoare, fără cluster de administrat
Porniți același program din nou, pe o stocare partajată. Copiile se coordonează doar prin lacăte de fișier: fără orchestrator, fără consens, fără registru de noduri.
Un singur program de instalat, de actualizat și de salvat
- Punctele de intrare ale fluxurilor, WSDL-ul, verificarea de sănătate, lucrătorii de coadă, planificatorul de orare și interfața de administrare rulează în același proces. Interfața nu e un al doilea binar și nu are portul ei.
- Ușa gRPC ascultă pe un port separat, în același proces, și numai dacă i se cere la pornire.
- Un singur proprietar de runtime în proces, iar o platformă la capacitate refuză zgomotos, cu urmă în jurnal.
- O instalație pornește știind numai manualul de operare: primul flux rulează cu poarta închisă și cu configurarea din mediu, în imaginea livrată.
TLS se termină la proxy-ul invers al dumneavoastră, în fața platformei.
Starea e un director, iar copia de siguranță e a directorului
| Fișier | Ce ține |
|---|---|
| registry.db | Registrul de artefacte, tenanții, cheile de API, configurarea de sistem |
| nexus-audit.db | Lanțul de audit |
| nexus-log.db | Jurnalul, ieșirea în bază de date |
| nexus-ui.db | Utilizatorii și sesiunile interfeței de administrare |
| logs/ | Jurnalul, ieșirea în fișier, câte unul pe zi |
| queues/ | Cozile, câte un set de fișiere pe pereche tenant–flux |
Se salvează ca un întreg. O bază luată fără cozile ei descrie o instalație care n-a existat niciodată.
Lanțul de audit din nexus-audit.db se poate verifica oricând, cu nexus audit --tenant <t> --verify sau cu butonul din pagina de audit. Un verdict de ruptură numește numărul de ordine al intrării atinse. Un lanț pe care nimeni nu l-a cerut nu se verifică de la sine, iar o listare nu spune nimic despre integritate. Comanda cere un tenant, deci o instalație cu mai mulți se verifică pe rând.
Pornirea refuză, în loc să tacă
Un flux declară ce configurare de mediu îi trebuie, iar o cheie declarată pe care instalația n-o oferă oprește pornirea, cu cheia numită. La pornire, nu la primul mesaj.
Aceeași întrebare se poate pune fără să pornească nimic: nexus config check dă același verdict ca pornirea și se încheie cu cod de eroare când lipsește o cheie. Un verdict, două momente, nu o a doua implementare care s-ar învechi tocmai în varianta pe care operatorul o rulează.
Și o scanare de pornire nu poate tăcea: un registru care nu se poate lista oprește pornirea, în loc să o lase să pară verificată.
Ce cere o repornire
- Configurarea de mediu se ia o dată, la pornire. O schimbare de configurare cere o repornire: dacă valorile s-ar reciti pe parcurs, poarta de la pornire ar fi verificat alte valori decât cele pe care rulează platforma.
- Adăugarea, schimbarea sau scoaterea unui orar cere o repornire. Schimbarea pașilor unui flux deja programat nu cere: ticul următor ia versiunea nouă.
- Tabela de rutare gRPC se construiește la pornire. Un flux publicat după aceea nu e rutat până la o repornire, iar unul retras răspunde ca unul inexistent.
- Plafoanele de debit trăiesc în memoria procesului. O repornire le golește, iar două motoare țin două contoare: o cheie configurată la
rcereri pe secundă poate cheltui până laN × rpeste N motoare. Plafonul se dimensionează pentru motor, nu pentru instalație.
Un mesaj confirmat supraviețuiește unei căderi; o reîncercare programată, unei reporniri
- Ordinea se păstrează numai la prima livrare. O reîncercare intră în ordinea în care i-a venit rândul, nu în cea în care a sosit mesajul.
- Plafonul de lucrători nu e un debit: e numărul de cozi distincte care pot fi drenate pe serverul ăsta. Se numără cozile, nu traficul.
- După o repornire, mesajele neprelucrate ale unei cozi stau pe disc până când ceva se trimite din nou fluxului acela. Lucrătorul pornește la prima trimitere, nu la pornirea procesului.
- O coadă drenată își recuperează octeții, iar lucrătorul continuă să consume; un mesaj aruncat din coada moartă chiar dispare de pe disc, la următorul drenaj.
Declarați deduplicarea în flux, iar a doua livrare a aceleiași chei nu-l mai rulează.
Orare
Un flux poate purta un orar cu șase câmpuri, iar un tic lasă în jurnal aceeași pereche (primire plus verdict) ca o cerere venită pe ușa din față, pe canalul cron. Un orar care a eșuat nu e invizibil.
Și în aceeași suflare, fiindcă un operator trebuie să afle asta înainte, nu la trei dimineața: lacătul de planificare face ca un singur motor să poarte orarele, deci nimic nu se declanșează de două ori. Alegerea se face însă o singură dată, la pornire. Dacă motorul care ține lacătul se oprește, orarele tac până la următoarea repornire a unui motor. Repornirea se planifică; preluare automată nu există.
O singură fereastră de retenție, și numai peste jurnal
Jurnalul are două ieșiri: rânduri într-o bază de date și fișiere pe disc. O singură fereastră de retenție le guvernează pe amândouă, într-o singură trecere, cablată în procesul care servește.
Fereastra aia nu trece dincolo de jurnal: nu atinge cozile, nu atinge registrul, nu atinge lanțul de audit și nu atinge starea de flux. Cine planifică spațiul pe disc al unei instalații planifică patru lucruri, nu unul.