Рекомендации по архитектуре для мультитенантного решения

Azure

При рассмотрении мультитенантной архитектуры необходимо принять несколько решений и элементов, которые необходимо учитывать.

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

  • Как определить, что такое клиент , для конкретного решения? Соответствует ли клиент, пользователь или группа пользователей, например команде или семье?
  • Как развернуть инфраструктуру для поддержки мультитенантности и сколько изоляции будет иметься между клиентами?
  • Какие коммерческие модели ценообразования будут предлагать ваше решение, и как ваши модели ценообразования влияют на ваши требования к мультитенантности?
  • Какой уровень обслуживания необходимо предоставить клиентам в таких измерениях, как производительность, устойчивость, безопасность и соответствие требованиям, такие как размещение данных?
  • Как вы планируете развивать бизнес или решение? Будет ли оно масштабироваться до количества ожидаемых клиентов?
  • У любого клиента есть необычные или специальные требования? Например, требуется ли вашему самому большому клиенту более высокая производительность или более надежные гарантии, чем другие?
  • Как отслеживать, управлять, автоматизировать, масштабировать и управлять средой Azure, а также как мультитенантность влияет на стратегию управления?
  • Какие компоненты решения обрабатывают подключение клиента и управление и как следует разрабатывать эти компоненты?

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

Например, представьте, что вы создаете мультитенантное решение, которое вы продаете предприятиям в отрасли финансовых услуг. У ваших клиентов есть очень строгие требования к безопасности, и они должны предоставить полный список всех доменных имен, которые использует ваше решение, чтобы они могли добавить его в список разрешений брандмауэра. Это требование влияет на используемые службы Azure и уровень изоляции, который необходимо предоставить между клиентами. Они также требуют, чтобы их решение было минимальным уровнем устойчивости. Существует множество аналогичных ожиданий, как явных, так и неявных, которые необходимо учитывать во всем решении.

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

Целевая аудитория

Статьи, приведенные в этом разделе, особенно важны для технических руководителей, таких как главный технический директор (CTOS) и архитекторов, а также менеджеры по продуктам. Аудитория также включает независимых поставщиков программного обеспечения (ISV) и стартапов, которые разрабатывают решения SaaS. Кроме того, любой, кто работает с мультитенантными архитектурами, должен иметь некоторое знакомство с этими принципами и компромиссами.

Дальнейшие действия

Рассмотрите различные модели аренды для решения.