Поделиться через

Архитектурные подходы для плоскостей управления в мультитенантных решениях

  • Статья

Плоскости управления являются важной частью программного обеспечения как услуги (SaaS) и мультитенантных решений, особенно для управления решением в масштабе. Как правило, существует два основных компонента, составляющих плоскость управления:

  • Каталог клиентов, в котором хранятся важные сведения о клиентах, например:
    • Конфигурация клиента.
    • Номера SKU, развернутые для ресурсов клиента.
    • Для каких меток развертывания выделяются клиенты.
  • Процессы управления изменениями среды, которые активируются событиями жизненного цикла клиента. Например, подключение клиента, отключение клиента и любое необходимое регулярное обслуживание.

Плоскость управления — это приложение. Вам нужно тщательно подумать о плоскости управления и разработать его с той же строгостью и заботиться, что вы используете с любой другой частью вашего решения. Дополнительные сведения о том, что такое плоскость управления, почему ее следует использовать и рекомендации по проектированию, см . в разделе "Рекомендации по многотенантным плоскостям управления".

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

Подходы и шаблоны, которые следует учитывать

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

Фактор Руководство Низкий код Пользовательское
Операционные издержки Высокая Низкий средний Низкая
Частота событий жизненного цикла подход подходит для Редко Иногда часто Часто
Время и сложность реализации Низкая Средняя Высокая
Обязанности по обслуживанию плоскости управления Низкая Средняя Высокая
Возможность тестирования Низкая Средняя Высокая
Риск несоответствий Высокая Средний низкий Низкая

Ручные процессы

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

Вы можете хранить каталог клиентов где-то централизованно, например в книге Excel или JSON-файле, который хранится в месте, к которому может получить доступ ваша команда. Независимо от формата, рекомендуется хранить информацию структурированным способом, чтобы можно было легко работать с данными программным способом.

Примечание.

Уровень управления вручную — отличный способ приступить к управлению мультитенантным приложением, но он подходит только для небольшого количества клиентов (менее 5–10). Административные издержки и риск несоответствий увеличиваются при подключении каждого клиента вручную. Этот подход следует использовать только в том случае, если у вас есть только несколько клиентов, и вам не нужна автоматическая или самостоятельная адаптация.

Для таких процессов, как подключение клиента и действия по обслуживанию:

  • Создавайте скрипты или автоматические конвейеры, даже если они выполняются вручную. Используя скрипты или конвейеры, необходимо убедиться, что шаги выполняются последовательно для каждого клиента.
  • Для задач, которые изначально не удается выполнить скрипт, задокументируйте процесс тщательно и явно. Задокументируйте , как и почему. Если кто-то заканчивается автоматизацией задачи в будущем, они должны иметь хорошее понимание обоих.

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

Схема, демонстрирующая один из способов использования скриптов и других ручных процессов для плоскости управления.

Скачайте файл Visio для этой архитектуры.

Преимущества ручного подхода

  • Упрощенный: документация, скрипты и конвейеры легко разрабатывать и изменять. Это делает их подходящими при определении процессов, потому что вы можете быстро итерировать и развивать их.
  • Низкая стоимость: обслуживание и выполнение ручного подхода является недорогим.
  • Проверяет процесс. Даже если вы в конечном итоге планируете использовать более автоматизированный подход, начиная с ручного подхода в качестве доказательства концепции является хорошим способом проверки стратегии обслуживания, прежде чем инвестировать время в разработку более надежной автоматизации.

Недостатки ручного подхода

  • Отсутствие контроля: этот подход зависит от всех, кто участвует в выполнении правильных действий. Кто-то может отклоняться от предписанных процессов либо случайно, либо намеренно. Каждый вариант процесса увеличивает риск несоответствия в вашей среде, что делает текущее управление гораздо сложнее.
  • Проблемы управления доступом: при использовании этого подхода обычно необходимо предоставить широкий, высокоразрешительный доступ любому, кто работает с решением, что затрудняет выполнение рекомендаций по сегментации доступа.
  • Масштабируемость. Работа, необходимая для выполнения ручных процессов, масштабируется с количеством клиентов, которыми требуется управлять.
  • Тестируемость. Вручную процессы трудно проверить и проверить.

Когда следует рассмотреть вопрос о переходе от ручного подхода

  • Когда ваша команда не может следить за объемом работы, которую они должны сделать для поддержания приложения. Например, если число клиентов масштабируется за рамки критической точки, которая для большинства команд составляет от 5 до 10 клиентов.
  • Когда вы ожидаете рост клиентов за пределами критического числа клиентов и необходимо подготовиться к работе, связанной с администрированием этого числа клиентов.
  • Если необходимо устранить риск несоответствий. Например, могут возникнуть некоторые ошибки, так как кто-то не следует за процессами правильно, или потому что в процессах слишком много неоднозначности. Риск несоответствия обычно растет, так как больше клиентов подключены вручную, и по мере роста вашей команды.

Плоскость управления с низким кодом

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

Microsoft Power Platform является примером одной из этих платформ. Если вы используете Power Platform, вы можете сохранить каталог клиентов в Dynamics 365, Dataverse или Microsoft 365. Кроме того, можно рассмотреть возможность сохранения того же каталога клиентов, который используется для ручных процессов, если вы не хотите полностью зафиксировать все.

Для подключения и обслуживания клиента можно использовать Power Automate для выполнения рабочих процессов, которые выполняют управление клиентами, настраивают клиенты, активируют конвейеры или вызовы API и т. д. Вы можете использовать Power Automate для просмотра изменений в каталоге клиентов, если данные доступны в Power Automate. Если вы используете каталог клиента вручную, рабочие процессы Power Automate также можно активировать вручную. Вы можете включить вручную шаги утверждения в рабочие процессы, если вам потребуется кто-то из вашей команды, чтобы проверить что-то или выполнить дополнительные действия, которые не могут быть полностью автоматизированы.

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

На следующей схеме показано, как можно создать плоскость управления с самостоятельной регистрации с помощью Microsoft Power Platform:

Схема, демонстрирующая один из способов использования Power Automate и Dataverse в качестве уровня управления с низким кодом.

Скачайте файл Visio для этой архитектуры.

Преимущества подхода с низким кодом

  • Упрощенный: часто это быстро и недорого, чтобы создать набор рабочих процессов с низким кодом и подключить их к окружающим системам.
  • Использует средства платформы: вы можете использовать собственные функции платформы для хранения данных, создания административных порталов для использования командой и отслеживания рабочих процессов при выполнении. Используя собственные функции платформы, вы избегаете создания большого количества компонентов самостоятельно.
  • Настраиваемый вариант. Если требуется дополнительная настройка, обычно можно расширить рабочие процессы с помощью пользовательского кода и процессов. Например, можно использовать Power Automate для активации рабочего процесса развертывания в GitHub Actions или вызвать Функции Azure для запуска собственного кода. Это также помогает упростить постепенную реализацию.
  • Низкие затраты: службы с низким кодом обычно полностью управляются, поэтому вам не нужно управлять инфраструктурой.

Недостатки подхода с низким кодом

  • Необходимый опыт. Чтобы использовать низкокодовые платформы для создания процессов и эффективного использования этих платформ, обычно требуются собственные знания. Многие организации уже используют эти средства, поэтому ваша команда может уже иметь необходимый опыт, но это может не так. Вы должны рассмотреть вопрос о том, нужно ли обучать свою команду, чтобы эффективно использовать эти платформы.
  • Управление. Управление может быть сложной задачей для управления большими объемами конфигурации с низким кодом.
  • Тестируемость. Рассмотрим, как протестировать и повысить уровень изменений в плоскости управления. На управляемой платформе создание типичного процесса DevOps для тестирования и продвижения изменений сложнее, так как изменения обычно выполняются с помощью конфигурации, а не с помощью кода.
  • Проектирование: тщательно думайте о том, как соответствовать нефункциональным требованиям, таким как безопасность и надежность. Эти требования часто управляются на низкой платформе кода.

Когда следует рассмотреть вопрос о переходе от подхода с низким кодом

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

Настраиваемая плоскость управления

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

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

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

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

На следующей схеме показан один из способов создания базовой пользовательской плоскости управления, которая обеспечивает самостоятельную регистрацию:

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

Скачайте файл Visio для этой архитектуры.

Преимущества пользовательского подхода

  • Полная гибкость и возможность настройки: у вас есть полный контроль над тем, что делает ваш уровень управления и может изменить его, если ваши требования изменяются.
  • Тестирование. Вы можете использовать стандартный жизненный цикл разработки программного обеспечения (SDLC) для приложения уровня управления и реализовать обычные подходы к тестированию и развертыванию, как и для основных приложений.

Недостатки пользовательского подхода

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

Гибридные подходы

Вы также можете использовать гибридный подход. Вы можете использовать сочетание ручных и автоматизированных систем или использовать управляемую платформу, например Microsoft Power Platform, и расширить ее с помощью пользовательских приложений. Рассмотрите возможность реализации гибридного подхода, если требуется настраиваемость пользовательской плоскости управления, но не обязательно хотите создавать и поддерживать полностью настраиваемую систему. Имейте в виду, что в какой-то момент автоматические настройки для ручных процессов или управляемой платформы могут стать сложными, как полностью настраиваемая система. Точка подсказки отличается для каждой организации, но если гибридный подход является омоздким для обслуживания, следует рассмотреть возможность перехода к полностью настраиваемой системе.

Постепенная реализация

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

Неподходящие антишаблоны

  • Использование ручных процессов слишком долго. Несмотря на то, что при запуске или при наличии небольшого количества клиентов и требуется достаточно упрощенное управление, необходимо спланировать масштабирование автоматизированного решения по мере роста. Если вам нужно нанять дополнительных участников команды, чтобы соответствовать требованию ваших ручных процессов, это хороший признак того, что вы должны начать автоматизацию частей плоскости управления.
  • Использование недопустимых средств для длительных рабочих процессов. Например, избегайте использования стандартных функций Azure, синхронных вызовов API или других средств, которые имеют ограничение времени выполнения для выполнения длительных операций, таких как развертывания Azure Resource Manager или многофакторные оркестрации. Вместо этого используйте такие средства, как Azure Logic Apps, Устойчивые функции и другие средства, которые могут выполнять длительные рабочие процессы или последовательности операций. Дополнительные сведения см. в разделе Функции Azure производительности и надежности и шаблона асинхронного ответа на запросы.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

Другие участники:

Следующие шаги