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

Архитектурные подходы для интеграции клиента и доступа к данным

  • Статья

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

Примечание.

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

Ключевые рекомендации и требования

Направление потока данных

Важно понимать направление, в котором потоки данных. Направление потока данных влияет на несколько аспектов архитектуры, таких как управление удостоверениями и топологией сети решения. Существует два распространенных потока данных:

  • Экспорт— это означает, что данные передаются из мультитенантной системы в системы отдельных клиентов.
  • Импорт, что означает, что данные приходят из систем клиентов в мультитенантную систему.

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

Полный или делегированный пользователем доступ

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

Например, рассмотрим Microsoft Power BI, которая является мультитенантной службой, которая предоставляет отчеты и бизнес-аналитику поверх хранилищ данных, принадлежащих клиенту. При настройке Power BI можно настроить источники данных для извлечения данных из баз данных, API и других хранилищ данных. Хранилища данных можно настроить двумя разными способами:

  • Импортируйте все данные из базового хранилища данных. Этот подход требует, чтобы Power BI предоставляла учетные данные для удостоверения, доступ к полному хранилищу данных. Затем администраторы Power BI могут отдельно настроить разрешения для импортированных данных после его импорта в Power BI. Power BI применяет разрешения.
  • Импортируйте подмножество данных из базового хранилища данных на основе разрешений пользователя. Когда пользователь создает источник данных, они используют свои учетные данные и связанные разрешения. Точное подмножество данных, импортируемых Power BI, зависит от уровня доступа пользователя, создавшего источник данных.

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

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

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

Режим реального времени или пакет

Рассмотрите возможность работы с данными в режиме реального времени или отправки данных в пакетах.

Для интеграции в режиме реального времени эти подходы являются общими:

  • Запрос или ответ — это место, когда клиент инициирует запрос на сервер и получает ответ. Как правило, интеграции запросов и ответов реализуются с помощью API или веб-перехватчиков. Запросы могут быть синхронными, где они ожидают подтверждения и ответа. Кроме того, запросы могут быть асинхронными, используя такой шаблон, как шаблон асинхронного ответа для ожидания ответа.
  • Свободно связанная связь часто включается с помощью компонентов обмена сообщениями, предназначенных для слабо связанных систем. Например, Служебная шина Azure предоставляет возможности очереди сообщений, а Сетка событий Azure и Центры событий предоставляют возможности для событий. Эти компоненты часто используются в рамках архитектур интеграции.

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

Объем данных

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

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

Форматы данных

Когда данные обмениваются между двумя сторонами, важно иметь четкое представление о том, как данные будут отформатированы и структурированы. Рассмотрим следующие части формата данных:

  • Формат файла, например JSON, Parquet, CSV или XML.
  • Схема, например список полей, которые будут включены, форматы дат и значение NULL полей.

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

Доступ к системам клиентов

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

Доступ к сети

Рассмотрим топологию сети для доступа к системе клиента, которая может включать следующие параметры:

  • Подключитесь через Интернет. Если вы подключаетесь через Интернет, как будет защищены подключения и как будут зашифрованы данные? Если клиенты планируют ограничить их на основе IP-адресов, убедитесь, что службы Azure, которые ваше решение использует, могут поддерживать статические IP-адреса для исходящих подключений. Например, при необходимости рекомендуется использовать шлюз NAT для предоставления статических IP-адресов. Если требуется VPN, рассмотрите возможность безопасного обмена ключами с клиентами.
  • Агенты, развернутые в среде клиента, могут обеспечить гибкий подход и помочь избежать необходимости в том, чтобы клиенты могли разрешать входящий трафик.
  • Ретрансляторы, такие как Azure Relay, также обеспечивают подход, чтобы избежать входящих подключений.

Дополнительные сведения см. в руководстве по сетевым подходам к мультитенантности.

Проверка подлинности

Рассмотрите способ проверки подлинности с каждым клиентом при запуске подключения. Рассмотрим следующие подходы:

  • Секреты, такие как ключи API или сертификаты. Важно спланировать безопасное управление учетными данными клиентов. Утечка секретов клиентов может привести к крупному инциденту безопасности, потенциально влияя на многих клиентов.
  • Токены Microsoft Entra, где вы используете маркер, выданный собственным каталогом Microsoft Entra клиента. Маркер может быть выдан непосредственно рабочей нагрузке с помощью мультитенантной регистрации приложения Microsoft Entra или определенного субъекта-службы. Кроме того, рабочая нагрузка может запросить делегированное разрешение на доступ к ресурсам от имени конкретного пользователя в каталоге клиента.

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

Доступ клиентов к системам

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

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

  • Используйте шаблон ключа valet, который включает использование таких мер безопасности, как подписанные URL-адреса, для предоставления ограниченного доступа к определенным ресурсам Azure.
  • Используйте выделенные ресурсы для точек интеграции, таких как выделенная учетная запись хранения. Рекомендуется сохранить ресурсы интеграции, отделенные от основных системных ресурсов. Этот подход помогает свести к минимуму радиус взрыва инцидента безопасности. Он также гарантирует, что, если клиент случайно инициирует большое количество подключений к ресурсу и исчерпает его емкость, остальная часть системы продолжает работать.

Соответствие нормативным требованиям

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

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

Предоставление API-интерфейсов

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

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

Рекомендуется использовать шлюз API, например Azure Управление API, для обработки этих проблем и многих других. Шлюзы API предоставляют вам одно место для реализации политик, которые следуют api-интерфейсам, и упрощают реализацию внутренних систем API. Дополнительные сведения о том, как Управление API поддерживает многотенантную архитектуру, см. в статье "Использование Azure Управление API в мультитенантном решении".

Шаблон ключа камердинера

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

Например, этот подход можно использовать при пакетном экспорте большого файла данных. После создания файла экспорта его можно сохранить в контейнере BLOB-объектов в служба хранилища Azure, а затем создать сигнатуру общего доступа только для чтения. Эта подпись может быть предоставлена клиенту вместе с URL-адресом БОЛЬШОго двоичного объекта. Затем клиент может скачать файл из служба хранилища Azure до истечения срока действия подписи.

Аналогичным образом можно создать подписанный URL-адрес с разрешениями на запись в определенный большой двоичный объект. При предоставлении подписанного url-адреса клиенту они могут записывать данные в большой двоичный объект. Интеграция сетки событий для служба хранилища Azure позволяет приложению получать уведомления об обработке и импорте файла данных.

Веб-перехватчики

Веб-перехватчики позволяют отправлять события клиентам по URL-адресу, который они предоставляют вам. При отправке сведений инициируете подключение к веб-перехватчику клиента и включаете данные в полезные данные HTTP-запроса.

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

Кроме того, можно использовать службу, например Сетка событий Azure для предоставления функций веб-перехватчика. Сетка событий работает в собственном коде с CloudEvents и поддерживает домены событий, которые полезны для мультитенантных решений.

Примечание.

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

Делегированный доступ пользователей

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

Например, предположим, что мультитенантная служба выполняет модели машинного обучения по данным клиентов. Вам необходимо получить доступ к экземплярам служб каждого клиента, таким как Azure Synapse Analytics, служба хранилища Azure, Azure Cosmos DB и другие. Каждый клиент имеет собственный каталог Microsoft Entra. Решение можно предоставить делегированный доступ к хранилищу данных, чтобы получить данные, к которым может получить конкретный пользователь.

Делегированный доступ проще, если хранилище данных поддерживает проверку подлинности Microsoft Entra. Многие службы Azure поддерживают удостоверения Microsoft Entra.

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

  1. Создайте мультитенантную регистрацию приложения Microsoft Entra, представляющую ваше решение.
  2. Предоставьте приложению делегированное разрешение на доступ к служба хранилища Azure в качестве пользователя, вошедшего в систему.
  3. Настройте приложение для проверки подлинности пользователей с помощью идентификатора Microsoft Entra.

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

Обмен сообщениями

Обмен сообщениями позволяет асинхронно, слабо связаны связи между системами или компонентами. Обмен сообщениями обычно используется в сценариях интеграции, чтобы отделить исходные и целевые системы. Дополнительные сведения о обмене сообщениями и мультитенантности см. в разделе "Архитектурные подходы к обмену сообщениями" в мультитенантных решениях.

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

В некоторых сценариях вы можете предоставить различные соглашения об уровне обслуживания (СОГЛАШЕНИЯ об уровне обслуживания) или гарантии качества обслуживания (QoS) для разных клиентов. Например, подмножество клиентов может ожидать, что запросы на экспорт данных обрабатываются быстрее, чем другие. Используя шаблон очереди приоритета, можно создать отдельные очереди для разных уровней приоритета, с различными экземплярами рабочих ролей, чтобы определить их приоритет соответствующим образом.

Составные компоненты интеграции

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

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

  • Получение данных из хранилища данных.
  • Преобразование данных в определенный формат или схему.
  • Передача данных с помощью определенного сетевого транспорта или в известный тип назначения.

Как правило, эти отдельные элементы создаются с помощью таких служб, как Функции Azure и Azure Logic Apps. Затем вы определяете общий процесс интеграции с помощью средства, например Logic Apps или Фабрика данных Azure, и вызывает каждую из предопределенных шагов.

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

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

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

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

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

  • Предоставление основным хранилищам данных непосредственно клиентам. Когда клиенты получают доступ к основным хранилищам данных, это может стать труднее защитить эти хранилища данных, и они могут случайно вызвать проблемы с производительностью, влияющие на решение. Избегайте предоставления учетных данных хранилищам данных клиентам и не реплицируйте данные из базы данных-источника в реплики чтения клиентов той же системы баз данных. Вместо этого создайте выделенные хранилища данных интеграции и используйте шаблон ключа Valet для предоставления данных.
  • Предоставление API-интерфейсов без шлюза API. API-интерфейсы имеют определенные проблемы для управления доступом, выставления счетов и измерения. Даже если вы изначально не планируете использовать политики API, рекомендуется включить шлюз API рано. Таким образом, если необходимо настроить политики API в будущем, вам не нужно вносить критические изменения в URL-адреса, от которые зависит сторонняя сторона.
  • Ненужное жесткое связывание. Свободное связывание, например использование подходов к обмену сообщениями, может обеспечить ряд преимуществ для безопасности, изоляции производительности и устойчивости. По возможности рекомендуется свободно сочетать интеграцию с третьими сторонами. Если вам нужно тесно сочетать с третьей стороной, убедитесь, что вы следуйте рекомендациям, таким как шаблон повторных попыток, шаблон разбиения цепи и шаблон перебора.
  • Пользовательские интеграции для определенных клиентов. Функции или код для конкретного клиента могут сделать решение более сложным для тестирования. Это также затрудняет изменение решения в будущем, так как вам нужно понять больше путей кода. Вместо этого попробуйте создать компонуемые компоненты , которые абстрагируют требования для любого конкретного клиента, и повторно использовать их в нескольких клиентах с аналогичными требованиями.

Соавторы

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

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

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

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

Ознакомьтесь с подходами к архитектуре для обмена сообщениями в мультитенантных решениях.