Дизайн многопользовательской системы

задняя часть Архитектура

Системная классификация SaaS

5 уровней модели зрелости системной архитектуры SaaS — от «хаоса» до «утопии»

  • Уровень 0 (Хаос): каждый раз, когда добавляется клиент, добавляется экземпляр программного обеспечения.
  • Уровень 1 (управляемый хаос): все клиенты работают на одной и той же версии программного обеспечения, и любая настройка выполняется путем изменения конфигурации.
  • Уровень 2 (мультитенантный [multi-tenant], высотные здания [Highrise]): все клиенты готовы работать с одной и той же версией программного обеспечения, и все они работают на одном и том же «экземпляре».
  • Уровень 3 (мультитенантность, наращивание): на этом этапе у вас есть многопользовательская модель программного обеспечения с одной версией. Однако аппаратное масштабирование все же возможно.
  • Уровень 4 (Утопия): аналогичен уровню 3, за исключением того, что вы можете найти эффективный способ запуска разных версий программного обеспечения на разных «экземплярах».

Приложение должно поддерживать мультиарендность:

Мультитенантность можно разделить на несколько категорий:

  • Простая виртуализация в облаке, где совместно используется только оборудование.
  • Общие приложения, использующие разные базы данных для каждого арендатора.
  • Обмен приложениями и базами данных (самая высокая эффективность, настоящий мультиванта).

То, чего мы хотим достичь, — это наиболее эффективная бизнес-модель с многопользовательским доступом. Тем не менее, существует процесс проверки для выбора.Ниже описаны различные схемы изоляции данных с несколькими арендаторами.

Независимая независимая библиотека приложений

Несколько различных приложений, каждое со своей собственной базой данных. Хотя этот метод обеспечивает изоляцию данных арендатора, он является худшим с точки зрения масштабируемости и стоимости, поэтому этот метод следует исключить в первую очередь.

Одно и то же приложение, одна библиотека на каждого арендатора

Преимущество

  • Данные арендатора физически изолированы от обслуживания базы данных,
  • Поскольку это библиотека для каждого арендатора, дизайн библиотеки таблицы может быть расширен отдельно, но это также вызывает проблемы совместимости приложений

Недостатком являются высокие затраты на обслуживание и базу данных (например: в случае, когда одна и та же структура данных или добавление столбцов в индексную таблицу требуют работы с множеством библиотек), стоимость разработки также высока.

то же приложение, та же база данных

Недостаток: мультитенантные базы данных неизбежно жертвуют изоляцией арендаторов. Данные для нескольких арендаторов хранятся вместе в одной базе данных. Во время разработки убедитесь, что запросы не предоставляют данные от нескольких арендаторов.

Преимущества: Это самая низкая стоимость из всех программ.

Разделенная мультиарендность

Шардинг и мультиарендность: мультитенантное одно приложение + мультитенантная единая база данных (шардинг)

Похожа ли она на первую картинку: одно и то же приложение, одна библиотека на тенанта похожа, но в каждой библиотеке больше данных тенанта?

Это на самом деле совсем другое.

Во-первых, в первом режиме библиотеки разных тенантов могут расширяться отдельно, то есть структура может быть разной, но шардированный мультитенант — это одна и та же структура данных.

Во-вторых, режим шардирования хорошо масштабируется: это может быть один шард с одним тенантом или один шард с несколькими тенантами, в зависимости от конкретной стратегии шардирования.

Давайте посмотрим на конкретные показатели в режиме шардинга:

показатель Разделенная мультиарендность
Масштабируемость Неограниченно 1-1000000s
Изоляция арендатора средний
Стоимость базы данных на одного арендатора самый низкий
Мониторинг и управление производительностью Интегрированные и одиночные (частично интегрированные)
сложность разработки средний
Сложность эксплуатации и обслуживания От низшего уровня к высокому управление одним арендатором усложняется

Наш выбор моделей

Основываясь на приведенном выше анализе, мы решили использовать модель сегментирования и мультиарендности, поскольку она может обеспечить неограниченную масштабируемость, а также лучше изолировать данные арендатора.

В этом случае структура базы данных унифицирована, а разные шарды имеют одинаковую структуру таблиц базы данных. Конкретные правила подбиблиотеки могут быть настроены, рекомендуется следоватьОдин арендатор, одна библиотекаконфигурация политики.

практика разработки

  • При разработке каждой таблицы следует учитывать, следует ли добавлять поле «идентификатор арендатора», чтобы различать разных «арендаторов» или разных клиентов. Кроме того, также удобно использовать «идентификатор аренды» в качествеОсколочный ключ

  • Мы представим ShardingSphere, чтобы помочь нам создать подбазу данных и подтаблицу базы данных, которая относительно прозрачна для приложения, уменьшая сложность разработки приложения на уровне базы данных из-за введения подбазы данных и подтаблицы.

  • Мы используем правила сегментирования для сегментирования данных, например, настраиваем правила сегментирования на основе идентификаторов арендаторов.

# 配置分片规则
- !SHARDING
  tables:
    # 配置 t_order 表规则
    t_order: 
      actualDataNodes: ds${0..1}.t_order${0..1}
      # 配置分库策略
      databaseStrategy:
        standard:
          shardingColumn: user_id
          shardingAlgorithmName: database_inline
      # 配置分表策略
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: table_inline
    t_order_item: 
    # 省略配置 t_order_item 表规则。..
    # ...
    
  # 配置分片算法
  shardingAlgorithms:
    database_inline:
      type: INLINE
      props:
        algorithm-expression: ds${user_id % 2}
    table_inline:
      type: INLINE
      props:
        algorithm-expression: t_order_${order_id % 2}
  • При изменении структуры таблицы базы данных (DDL), выполните модификацию прокси через ShardingProxy, и ShardingProxy автоматически изменит таблицы с несколькими базами данных в соответствии с правилами подбазы данных и подтаблицы.

Драйвер метаданных/конфигурации

Хорошее решение SaaS должно быть эффективным мультиарендным. Мультиарендность может быть достигнута с помощью метаданных для каждого арендатора. Метаданные могут быть определены для каждого конкретного компонента. Он определяет данные приложения во время выполнения, базовые функции приложения, а также данные и настройки клиента (если таковые имеются).

В частности, например, наше управление конфигурацией разрешений RBAC для мультитенантных систем — это конфигурация метаданных. Вы можете обратиться к:

Ссылаться на

Категории