Miez multi-chiriaș

Un miez multi-chiriaș este stratul de bază al unei platforme/produs care deservește mulți clienți independenți (chiriași) pe resurse partajate cu izolare garantată, limite gestionate și personalizare sigură. Un nucleu bine conceput reduce TCO, accelerează la bord, simplifică lansările și oferă o calitate previzibilă pentru fiecare chiriaș.

1) Modelul chiriașului și limitele de izolare

Definiții

Chiriaș/Org/Cont - o organizație logică cu proprii utilizatori, date, politici și limite.
Izolare: Capacitatea de a împiedica un chiriaș să afecteze datele, performanța și securitatea altuia.

Niveluri de izolare

1. Date: baze de date/scheme/tabele individuale, criptare cu "cheia chiriașului", filtre "chiriaș _ id'.
2. Calcule: cote CPU/RAM/IO, piscină lucrător chiriaș sau cozi ponderate.
3. Rețea: segmentare, puncte finale private/VPN, liste de permise de către chiriaș.
4. Operațiuni: migrații, copii de rezervă, DR și incidente cu limite de impact „per chiriaș”.

Modele multi-chirie

Siloz (izolare dură): clustere individuale/baze de date pe chiriaș. Securitate maximă, preţ mare.
Pool: infrastructură comună cu izolare logică; eficiență mai bună, risc mai mare de „vecin zgomotos”.
Bridge/Hybrid: hibrid - plan de control comun + selectiv „siloz” pentru clienții VIP/reglementați.

2) Identificarea și rutarea solicitărilor chiriașilor

Rezoluția chiriașilor

După domeniu: 'https ://{ chiriaș} .example. come '

Pe parcurs: '/t/{ chiriaș }/... '

După titlu: "X-Tenant-Id'," X-Org "(verificarea semnăturii)

După token: timbre 'chiriaş _ id',' org _ id', 'plan', 'scopes'

Rutare

Gateway-ul L7 (API gateway/Ingress) extrage 'tenant _ id', îmbogățește contextul (' plan ', limite, regiune), scrie la trasee/jurnale.
Serviciile funcționale acceptă un context read-only; deciziile privind traseul și limitele sunt luate de motorul gateway/policy.

3) Date și scheme: strategii

Opțiuni de stocare

Schema partajată, la nivel de rând: un set de tabele, câmpul "chiriaș _ id', RLS strict (Row-Level Security).
Shared-DB, per-schema: un DBMS, o schemă separată pentru fiecare chiriaș; echilibru între controlabilitate și izolare.
Per-DB/cluster: bază de date separată/cluster per chiriaș; mai scump, mai ușor pentru revendicările suverane.

Practici cheie

Peste tot trece explicit "chiriaș _ id' și să-l includă în chei compuse/indici.
Politici de acces la nivel RLS/DBMS + validare a serviciilor cu dublă blocare.
Criptare: ierarhie cheie (rădăcină KMS → cheie-plic pe chiriaș → DEK pe obiect).
Arhiva/retenția și „dreptul de a fi uitat” sunt gestionate de politici la nivel de chiriași.

4) Setări, caracteristici și versiuni

Configurații chiriași

Tabel/stocare „chiriaș _ config” (plan, cote, steaguri de caracteristici, localizare, SLA).
Prioritățile configurațiilor: planul implicit de → → chiriașul → mediul → utilizatorul.
Config caching cu TTL scurt și handicap de eveniment.

Caracteristică steaguri și compatibilitate

Activarea funcțiilor punct (per-chiriaș/per-cohortă), canar de rulare.
Versionare API: contract stabil + adaptoare la frontieră (formate compatibile înapoi/înainte).

5) Limite, cote și facturare

Politici de consum

Limitarea ratei: „cereri/sec” per chiriaș/traseu, „cupă-token” cu priorități de plan.
Cote: capacitate de stocare, număr de obiecte, mesaje/min, locuri de muncă/oră.
Corectitudine: „orarul ponderat” al cozilor + izolarea lucrătorilor pentru VIP.

Facturare

Contoare după 'chiriaș _ id' (valori de utilizare) → → agregatoare de facturi.
Instantanee de utilizare pe frontieră (idempotență și protecție împotriva pierderilor de evenimente).
Modele: plan fix + consum, post-pay/pre-pay, reduceri „pe niveluri”.

6) Securitate și acces

Autentificare/Autorizare

OIDC/SAML cu marcajele "chiriaș _ id'," roluri "," scopes ".

RBAC/ABAC - Roluri la nivel de chiriaș (Proprietar/Admin/Reader), atribute de proiect/departament

Service-to-service cu mTLS și jetoane restricționate.

Limite de încredere

Solicitați politici de acceptare: verificarea semnăturii antetului, nonce/timestamp, obligativitatea sursei.
Secrete și chei: rotație per chiriaș, contexte individuale KMS, auditul operațiunilor cheie.
Rezidență multiregională și de date: fixarea unui chiriaș într-o regiune, fluxuri transregionale controlate.

7) Observabilitate „de chiriași”

Urme și măsurători

Etichetele necesare sunt 'tenant _ id',' plan ',' regiune ',' endpoint ',' status '.
SLI/SLO per chiriaș: „disponibilitate”, „latență p95”, „buget de eroare”.
Tablouri de bord și alerte pe segmente (VIP/reglementate/noi).

Jurnale și audituri

Jurnalele de activitate (cine/ce/când/unde) cu stocare și păstrare neschimbabile în conformitate cu politica chiriașilor.
Pre-agregarea evenimentelor pentru stocarea ieftină, restaurarea detaliilor „prin clic”.

8) Performanță și „vecin zgomotos”

Măsuri anti-zgomot

Limite privind nivelul cozilor/lucrătorilor, al acțiunilor CPU și al proporției IO pentru fiecare chiriaș.
Separarea memoriei cache: chiriașul prefixelor cheie: {id}:... ", TTL de planuri, protecție împotriva" cache busculada ".
Indexuri și planuri de interogare bazate pe selectivitatea "chiriaș _ id'.

Porniri reci și piscine „calde”

Pre-încălzire pentru ferestre VIP/vârf.
Bazine elastice de lucrători bazate pe semnale metrice (backpressure/autoscaling).

9) Upgrade-uri și migrații fără întreruperi

Strategie

Migrații compatibile înapoi (extindeți → migrați → contract).
Migrații "de chiriași": loturi cu control al progresului, "pauză/rollback" pentru un anumit "chiriaș _ id'.
Prelevarea de probe și migrațiile „canare” pe un subset de chiriași.

DR și incidente

Planul DR cu RTO/RPO per chiriaș; parțial „read-only mode” fără întreruperi globale.
Izolarea incidentului: fuzionarea prin "chiriaș _ id', stingerea chiriașului" fierbinte "nu afectează restul.

10) API-uri și protocoale

REST/gRPC cu context de chiriaș obligatoriu (în timbre/anteturi).
Evenimente (event-driven): subiecte cu denumirea 'chiriaș. {id} .event', filtre și ACL-uri pentru abonamente.
Puncte de intrare globale: gateway-ul L7 validează contextul, aplică limite, criptează PII-ul în conformitate cu politica chiriașului.

11) Ciclul de viață al chiriașilor

1. Provizionare: crearea unei înregistrări de chiriaș, generarea de chei/configurații, conectarea unei regiuni.
2. Activare: eliberarea clientului OIDC/SAML, crearea de roluri/politici, cote primare.
3. Funcționare: monitorizare, facturare, actualizări de pavilion/plan.
4. Suspend/throttling: congela cu păstrarea datelor/export.
5. Ștergere/export: retenție, backup-uri mothballed, crypto-mărunțire.

12) Arhitectura mini-referință (schema verbală)

Edge (API gateway): TLS/mTLS, extracție "chiriaș _ id', limite, audit.
Plan de control: catalog de chiriași, configurații, steaguri de caracteristici, facturare, politică.
Data Plane (servicii): servicii apatrizi, cozi, lucrători la cotă; Redis/kv prefixat de chiriaș.
Stocare: RLS-DB/scheme individuale/DB; KMS cu chei per chiriaș; stocare obiect cu criptare plic.
Observabilitate: trasare/metrica/busteni cu eticheta 'chirias _ id', alerte per plan.
Admin: operațiuni izolate (migrații/backup-uri) pe un subset de chiriași.

13) Lista de verificare pre-vânzare

• O singură modalitate de a defini chiriaș _ id la frontieră și în servicii.
• Politicile RLS/ACL sunt testate cu teste și „scripturi negative”.
• Cotele/limitele/facturarea sunt validate pe sarcini reale; există protecție împotriva „picăturilor de facturare”.
• Observabilitate și SLO per chiriaș; alerte pentru VIP/reglementate.
• Migrațiile sunt compatibile, există un rollback parțial și loturi împrumutătoare.
• Scenarii DR cu RTO/RPO per chiriaș și exerciții regulate.
• Chiriaș cheie de criptare, rotație cheie, și audit cheie.
• Documentarea contractelor/evenimentelor API și a politicilor de versionare.

14) Erori tipice

Migrațiile globale „într-o singură lovitură”, fără capacitatea de a opri pe un chiriaș problemă.
Dependența ascunsă de memoria cache/cozile de date → scurgerea datelor/trecerea cozii.
Amestecarea contextului (operații de administrare accidental fără 'chiriaș _ id').
Absența „blocării duble”: numai verificarea serviciului fără RLS în baza de date.
Un singur limitator pentru întregul grup → „vecinul zgomotos” și încălcarea SLO.
Facturare netransparentă fără idempotență și pistă de audit.

15) Selectarea rapidă a strategiei

Izolare/reglementare strictă: siloz (baze de date separate/clustere), region-lock.
Eficiență echilibrată: Shared-DB per schema + RLS, chei per chiriaș.
Trafic ridicat în timp real: cozi comune cu cote „ponderate” și lucrători dedicați pentru VIP.
Multe personalizări: dispun de steaguri + adaptoare API, stocarea configurațiilor după prioritate.

Concluzie

Nucleul multi-chiriaș este disciplina limitelor inginerești: definirea explicită a "chiriaș _ id', izolarea strictă pe toate straturile, cotele gestionate și facturarea transparentă, plus observabilitatea și compatibilitatea eliberării. Urmând modelele descrise vă permite să scalați produsul fără a sacrifica siguranța, calitatea și viteza schimbării pentru fiecare chiriaș.