Подход к изоляции
Кроме данных, общих для платформы, в каждой бизнес-таблице есть столбец tenant_id. Когда приходит запрос, цепочка фильтров привязывает тенант вошедшей учётной записи к текущему потоку; тенант-фильтр Hibernate автоматически добавляет условие по тенанту в запросы и подставляет tenant_id при записи. Бизнес-код не может «забыть» добавить условие по тенанту.
Немногие сценарии, которым нужен доступ между тенантами (например, поиск учётной записи по имени пользователя при входе, подсчёт учётных записей по тенантам или фоновые плановые задачи), должны явно входить в «системный контекст», поэтому их легко заметить при просмотре кода.
Общие и принадлежащие тенанту данные
| Общие для всей платформы | Принадлежащие каждому тенанту |
|---|---|
| Приложения и каталог ресурсов, каталог API, OAuth-клиенты, плагины | Учётные записи, подразделения, группы пользователей, должности, роли, выдачи, назначения, политики данных и полей, разделение обязанностей, запросы доступа и проверки, источники идентификации, сервисы данных, аудит |
Имена пользователей уникальны на всей платформе, поэтому при входе не нужно выбирать тенант.
Платформенный тенант
Платформенный тенант создаётся при инициализации и не может быть отключён. Его администраторы управляют данными, общими для платформы, и остальными тенантами; только роли в платформенном тенанте могут использовать область данных «все тенанты».
Идентификаторы
Все первичные ключи — это TSID: 64-битные, упорядоченные по времени и гарантированно уникальные во всём кластере за счёт номеров узлов. Они превышают величину целых чисел, которую JavaScript представляет точно, поэтому в JSON они всегда передаются строками. Каждый экземпляр в кластере должен иметь собственный GRANTFORGE_ID_NODE.