Многонаемателски SaaS: изолация и архитектурни компромиси

Многонаемателска архитектура трябва да разделя клиентските данни и действия през всички пътища, не само през основния API.

Три отделни клиентски отделения, свързани с обща основа за услуги.

Многонаемателска архитектура трябва да разделя клиентските данни и действия през всички пътища, не само през основния API. Изборът между общи таблици, отделни бази и отделни внедрявания зависи от изолация, възстановяване, мащаб и оперативен капацитет. Нито един вариант не премахва нуждата от разрешения.

Изберете границата по изисквания

Общи таблици с клиентски идентификатор улесняват споделена инфраструктура, но изискват последователно прилагане на контекст. Отделни схеми или бази дават различна граница и възможности за операции по клиент, но добавят миграции и връзки. Отделни ресурси позволяват по-независим капацитет, като увеличават броя наблюдавани и обновявани среди. Оценете целия живот на решението. Лесното създаване на първите клиенти не доказва, че екипът може безопасно да управлява много такива единици.

Пренасяйте доверен контекст

Определяйте принадлежност и права от проверена идентичност и сървърни правила, а не само от поле, изпратено от браузъра. Контекстът трябва да стига до заявки, опашки, кеш, файлове, експорти и административни операции. Изолация в базата не компенсира общ кеш ключ или неправилно споделен файл. Опишете и действията на служител, който може да работи с няколко клиента. Така привилегированият достъп остава ограничен и проследим вместо да се превърне в неявен обход на модела.

Проверявайте повече от успешен API отговор

Използвайте разрешени тестови профили в различни организации с ясно отделени данни. Проверете четене, запис, търсене, експорт, фонови задачи и операторски действия. Сменено клиентско поле не трябва да дава чужд ресурс. Отказът също не трябва да разкрива чувствителни подробности. Повторете при кеширане и след преместване на потребител между организации. Записвайте очаквано и действително поведение, така че тестът да проверява истинска бизнес граница, а не просто различен HTTP код.

Разгледайте и конкуренцията за ресурси

Правилна изолация на данни не предотвратява един клиент да изчерпи обща база или опашка. Измерете представителна тежка операция заедно с нормален трафик на друг клиент. Помислете за лимити, планиране или отделяне на конкретно натоварване. Не въвеждайте отделно внедряване за всеки клиент без операционна обосновка. Приемането включва както отказ на неправомерен достъп, така и съгласувано ниво на обслужване при очаквана конкуренция и възстановяване на засегнатите данни.

Често задавани въпроси

Достатъчен ли е tenant идентификатор в таблиците?

Не. Заявки, задачи, кеш, файлове и административни операции трябва да прилагат доверения контекст.

Нужна ли е база за всеки клиент?

Не винаги. Изберете според изолация, възстановяване, мащаб и цена на управление.

Отделна база заменя ли правата?

Не. Приложението и оперативният достъп още изискват разрешения и контролирани ключове.

Как да тестваме изолация?

С разрешени отделни профили и данни през четене, запис, експорт, задачи и привилегировани действия.

Какво е шумен съсед?

Клиентско натоварване, което влошава общата услуга чрез споделени ресурси.

От идея до изпълним обхват

Споделете потребителския път, интеграциите и условията за стартиране. Можем да подготвим оценка с допускания и изключения.

Вижте обхвата на услугата →