Rdzeń wielu najemców
Rdzeń wielu najemców to warstwa bazowa platformy/produktu, która obsługuje wielu niezależnych klientów (najemców) na udostępnionych zasobach z gwarantowaną izolacją, zarządzanymi limitami i bezpieczną dostosowaniem. Dobrze zaprojektowany rdzeń zmniejsza TCO, prędkość wejścia na pokład, upraszcza wydania i zapewnia przewidywalną jakość dla każdego najemcy.
1) Model najemcy i granice izolacji
Definicje
Najemca/Org/Konto - organizacja logiczna z własnymi użytkownikami, danymi, zasadami i limitami.
Izolacja: Możliwość zapobiegania wpływowi jednego najemcy na dane, wydajność i bezpieczeństwo drugiego.
Poziomy izolacji
1. Dane: poszczególne bazy danych/schematy/tabele, szyfrowanie z "kluczem', filtry 'lokator _ id'.
2. Obliczenia: kwoty CPU/RAM/IO, pula pracowników najemców lub kolejki ważone.
3. Sieć: segmentacja, prywatne punkty końcowe/VPN, listy zezwoleń przez najemcę.
4. Operacje: migracje, kopie zapasowe, DR i incydenty o granicach wpływu „na jednego najemcę”.
Wzory wielopoziomowe
Silos (izolacja twarda): poszczególne klastry/bazy danych na najemcę. Maksymalne bezpieczeństwo, wysoka cena.
Pula: wspólna infrastruktura z logiczną izolacją; lepsza wydajność, większe ryzyko „hałaśliwego sąsiada”.
Most/Hybrid: hybrydowy - wspólny płaszczyzna sterowania + selektywnie „silos” dla klientów VIP/regulowanych.
2) Identyfikacja i kierowanie wniosków najemców
Rozdzielczość najemcy
Według domeny: 'https ://{ lokator} .example. com"
Po drodze: '/t/{ lokator }/... '
Tytuł: "X-najemca-Id'," X-Org "(weryfikacja podpisu)
Token: znaczki 'lokator _ id',' org _ id', 'plan', 'scopes'
Routing
Brama L7 (brama API/Ingress) wyodrębnia 'lokator _ id', wzbogaca kontekst (' plan ', limity, region), zapisuje do tras/logów.
Usługi funkcyjne akceptują kontekst tylko do odczytu; decyzje dotyczące trasy i limitów są podejmowane przez bramę/silnik polityki.
3) Dane i schematy: strategie
Opcje przechowywania
Wspólny schemat, poziom wiersza: jeden zestaw tabel, pole "lokator _ id', ścisłe zabezpieczenie RLS (Row-Level Security).
Shared-DB, per-schemat: jeden DBMS, oddzielny system na najemcę; równowaga między możliwością sterowania a izolacją.
Per-DB/cluster: oddzielna baza danych/klaster na najemcę; droższe, łatwiejsze dla suwerennych roszczeń.
Kluczowe praktyki
Wszędzie wprost przechodzi 'lokator _ id' i zawiera go w klawiszach/indeksach złożonych.
Zasady dostępu na poziomie RLS/DBMS + walidacja usługi podwójnej blokady.
Szyfrowanie: hierarchia kluczy (główny KMS → klucz-koperta na najemcę → DEK na obiekt).
Archiwum/przechowywanie i „prawo do bycia zapomnianym” są zarządzane przez politykę na poziomie najemcy.
4) Ustawienia, funkcje i wersje
Konfiguracje najemcy
Tabela/przechowywanie „najemca _ config” (plan, kwoty, flagi funkcji, lokalizacja, SLA).
Priorytety konfiguracji: domyślnie → plan → lokator → środowisko → użytkownik.
Buforowanie Config z krótkim TTL i niepełnosprawność przez zdarzenie.
Flagi funkcji i kompatybilność
Włączanie punktu funkcji (per-najemca/per-cohort), walcowania kanaryjskiego.
API versioning: stabilny kontrakt + adaptery na granicy (back/forward-compatible formats).
5) Limity, kwoty i rozliczenia
Polityka konsumpcyjna
Ograniczenie stawki: „żądania/sec” na najemcę/trasę, „token-wiadro” z priorytetami planu.
Kwoty: pojemność magazynowa, liczba obiektów, wiadomości/min, zadania/godzina.
Sprawiedliwość: "ważony harmonogram' kolejek + izolacja pracowników dla VIP.
Rozliczenia
Liczniki przez 'lokator _ id' (metryki użytkowania) → → agregatory faktur.
Migawki na granicy (ochrona przed utratą zdolności i zdarzeń).
Modele: stały plan + zużycie, po wynagrodzeniu/przedpłata, zniżki „wielopoziomowe”.
6) Bezpieczeństwo i dostęp
Uwierzytelnianie/autoryzacja
OIDC/SAML ze znakami 'lokator _ id',' role ',' scopes '.
RBAC/ABAC - Role poziomu najemcy (właściciel/administrator/czytelnik), atrybuty projektu/działu
Obsługa z mTLS i ograniczonymi tokenami.
Granice zaufania
Zasady akceptacji żądań: weryfikacja podpisu nagłówka, nonce/timestamp, wiążące źródło.
Sekrety i klucze: rotacja na najemcę, indywidualne konteksty KMS, audyt kluczowych operacji.
Multi-region & rezydencja danych: przyciągnięcie najemcy do regionu, kontrolowane przepływy międzyregionalne.
7) Obserwowalność „przez najemców”
Ślady i mierniki
Wymagane znaczniki to 'lokator _ id',' plan ',' region ',' punkt końcowy ',' status '.
SLI/SLO na najemcę: „dostępność”, „p95 latency”, „budżet błędu”.
Deski rozdzielcze i wpisy według segmentów (VIP/regulowane/nowe).
Dzienniki i audyty
Dzienniki aktywności (kto/co/kiedy/gdzie) z niezmiennym przechowywaniem i przechowywaniem zgodnie z zasadami najemcy.
Wstępne zagregowanie zdarzeń w celu taniego przechowywania, przywrócenie szczegółów „klikając”.
8) Wydajność i „hałaśliwy sąsiad”
Środki przeciwdziałające hałasowi
Limity poziomu kolejek/pracowników, akcji procesora i proporcji IO na najemcę.
Oddzielenie pamięci podręcznej: lokator prefiksów klucza: {id}:... ', TTL według planów, ochrona przed „cache stampede”.
Indeksy i plany zapytań oparte na selektywności 'lokator _ id'.
Zimne starty i „ciepłe” baseny
Wstępne ogrzewanie dla okien VIP/szczytowych.
Elastyczne baseny pracowników oparte na sygnałach metrycznych (podciśnienie/autoskalowanie).
9) Modernizacje i migracje bez przestojów
Strategia
Wsteczne migracje kompatybilne (rozszerzyć → migrate → kontrakt).
Migracje „przez najemców”: partie z kontrolą postępu, „pauza/rollback” dla określonego 'lokatora _ id'.
Pobieranie próbek i migracje „kanaryjskie” na podzbiorze najemców.
DR i incydenty
plan DR z RTO/RPO na najemcę; częściowy „tryb tylko do odczytu” bez globalnego przestoju.
Izolacja zdarzenia: topienie przez 'lokator _ id', gaszenie najemcy „gorącego” nie wpływa na resztę.
10) API i protokoły
REST/gRPC z obowiązkowym kontekstem najemcy (w znaczkach/nagłówkach).
Zdarzenia (wywołane zdarzeniami): tematy z nazwą „lokator. {id} .event”, filtry i ACL dla subskrypcji.
Globalne punkty wejścia: brama L7 sprawdza kontekst, stosuje limity, szyfruje PII zgodnie z polityką najemcy.
11) Cykl życia najemcy
1. Rezerwacja: tworzenie rekordu najemcy, generowanie klawiszy/konfiguracji, łączenie regionu.
2. Aktywacja: zwolnienie klienta OIDC/SAML, tworzenie ról/polityk, kwoty podstawowe.
3. Operacja: monitorowanie, rozliczanie, aktualizacje flagi/planu.
4. Zawieszenie/rozdrabnianie: zamrozić za pomocą retencji/eksportu danych.
5. Deletion/export: retencja, kopie zapasowe w mothballed, crypto-shredding.
12) Mini-architektura referencyjna (system słowny)
Krawędź (brama API): TLS/mTLS, extraction 'tenant _ id', limity, audyt.
Control Plane: katalog najemców, konfiguracje, flagi funkcji, rozliczenia, polityka.
Data Plane (usługi): usługi bezpaństwowe, kolejki, pracownicy kwot; Redis/kv prefiksowane przez najemcę.
Przechowywanie: RLS-DB/indywidualne schematy/DB; KMS z klawiszami na najemcę; przechowywanie obiektów z szyfrowaniem kopert.
Obserwowalność: śledzenie/metryka/dzienniki z tagiem 'lokator _ id', wpisy na plan.
Administrator: pojedyncze operacje (migracje/kopie zapasowe) na podzbiorze najemców.
13) Lista kontrolna przedsprzedaży
- Jednolity sposób definiowania najemcy _ id na granicy i w usługach.
- Polityka RLS/ACL jest testowana za pomocą testów i „negatywnych skryptów”.
- Kwoty/limity/rozliczenia są zatwierdzane na rzeczywistych ładunkach; istnieje ochrona przed „kroplami rozliczeniowymi”.
- Obserwowalność i SLO na najemcę; wpisy dla VIP/regulowane.
- Migracje są kompatybilne, istnieje częściowy zwrot i partie pożyczki.
- Scenariusze DR z RTO/RPO na najemcę i regularne ćwiczenia.
- Szyfrowanie klucza najemcy, rotacja klucza i audyt klucza.
- Dokumentacja umów/wydarzeń API i polityki wersioning.
14) Typowe błędy
Globalne migracje „w jednym spadły” bez możliwości zatrzymania się na najemcy problemu.
Ukryta zależność od 'lokatora _ id' w pamięci podręcznej/kolejkach → wyciek danych/przekroczenie kolejki.
Mieszanie kontekstowe (operacje administratora przypadkowo bez "najemcy _ id').
Brak „podwójnej blokady”: tylko sprawdzić usługę bez RLS w bazie danych.
Pojedynczy ogranicznik dla całego klastra → „hałaśliwy sąsiad” i naruszenie SLO.
Nieprzejrzyste rozliczenia bez idempotencji i ścieżki audytu.
15) Szybki wybór strategii
Ścisła izolacja/regulacja: Silo (oddzielne bazy danych/klastry), blokada regionalna.
Zrównoważona wydajność: Wspólny DB na schemat + RLS, klawisze na najemcę.
Duży ruch w czasie rzeczywistym: wspólne kolejki z „ważonymi” kwotami i specjalnymi pracownikami VIP.
Wiele dostosowań: posiadają flagi + adaptery API, konfiguracje przechowywania według priorytetów.
Wnioski
Rdzeń wielu najemców to dyscyplina granic inżynieryjnych: wyraźna definicja "najemcy _ id', ścisła izolacja wszystkich warstw, zarządzane kwoty i przejrzyste rozliczenia, a także obserwowalność i kompatybilność uwalniania. Wykonując opisane wzory, możesz skalować produkt bez poświęcania bezpieczeństwa, jakości i szybkości zmian dla każdego najemcy.