GH GambleHub

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.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Telegram
@Gamble_GC
Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.