Программное обеспечение как услуга (SaaS) — это сложная тема с множеством точек, которые следует рассмотреть. Независимые поставщики программного обеспечения (НЕЗАВИСИМЫЕ поставщики программного обеспечения), которые создают свои решения SaaS в Azure, необходимо решить проблемы и принять такие решения, как:
- Какую модель аренды следует использовать?
- Разделы справки настроить решение удостоверений для использования в мультитенантной архитектуре?
- Разделы справки обработать подключение новых клиентов?
Эта архитектура направлена на ответы на некоторые из этих вопросов и предоставляет отправное место в мире SaaS. Эта архитектура адаптируется к широкому спектру сценариев.
Потенциальные варианты использования
Ниже приведены некоторые примеры вариантов использования, в которых можно использовать эту архитектуру:
- Модернизируйте существующее приложение для поддержки полной мультитенантности в рамках перехода на бизнес-модель на основе SaaS.
- Разработка совершенно нового предложения SaaS.
- Перенос предложения SaaS из другой облачной службы в Azure.
Архитектура
Скачайте файл PowerPoint этой архитектуры.
Терминология
В следующей таблице описываются термины, которые отображаются в этой статье.
| Срок | Description | Пример |
|---|---|---|
| Поставщик SaaS или поставщик программного обеспечения | Сущность, которая владеет приложением SaaS и кодом и продает продукт SaaS. | Contoso Inc, продавая свое приложение SaaS: Contoso Tickets. |
| Клиент | Приобретенный экземпляр приложения SaaS от Поставщика SaaS. | Четвертый кафе. |
| Администратор клиента SaaS | Люди, которые покупают или администрируют клиент приложения. | Джо, владелец четвертого кафе. |
| Пользователь клиента SaaS | Люди, которые используют клиент приложения без администрирования и обычно принадлежат той же компании или группе, что и администратор клиента SaaS. | Джилл, менеджер событий в четвертом кафе, и Сьюзан, клиент четвертого кафе. |
| Трафик | Администратор клиента SaaS, пользователь клиента SaaS или другие типы пользователей, которые появились. Это универсальный термин для описания пользователей, которые входят в приложение. | Джо, Джилл и Сьюзан являются всеми конечными пользователями (с точки зрения ISV). |
| Интерфейсное приложение | Любое интерфейсное приложение. | Подключение и администрирование приложения и приложения SaaS — это интерфейсные приложения. |
Рабочий процесс
Администратор клиента SaaS переходит на сайт, размещенный в приложении "Подключение" и "Администратор".
Администратор клиента SaaS входит в систему с помощью рабочего процесса входа пользователя.
Администратор клиента SaaS завершает поток подключения.
Администратор клиента SaaS переходит в область администрирования клиента в приложении "Подключение" и "Администратор" и добавляет пользователя SaaS в созданный клиент.
Пользователь клиента SaaS переходит к приложению приложения SaaS и использует приложение SaaS.
Вход пользователя
Рабочий процесс входа пользователя состоит из следующих шагов:
Конечный пользователь переходит в интерфейсное приложение и нажимает кнопку входа .
Интерфейсное приложение перенаправляет пользователя на страницу входа, размещенную поставщиком удостоверений.
Конечный пользователь вводит сведения об учетной записи и отправляет форму входа поставщику удостоверений.
Поставщик удостоверений выдает запрос POST с адресом электронной почты и идентификатором объекта конечного пользователя для получения разрешений и ролей.
API данных разрешений ищет сведения конечного пользователя в хранилище данных разрешений и возвращает список разрешений и ролей, назначенных данному пользователю.
Поставщик удостоверений добавляет разрешения и роли в качестве пользовательских утверждений в маркер идентификатора, который является веб-маркером JSON (JWT).
Поставщик удостоверений возвращает маркеридентификатора пользователю и инициирует перенаправление в интерфейсное приложение.
Конечный пользователь перенаправляется в конечную точку входа в интерфейсное приложение и представляет маркер идентификатора.
Интерфейсное приложение проверяет представленный маркер идентификатора.
Интерфейсное приложение возвращает страницу успешного входа, и конечный пользователь вошел в систему.
Дополнительные сведения о том, как работает этот поток входа, см. в статье OpenID Подключение протокол.
Подключение нового клиента
Рабочий процесс подключения клиента состоит из следующих шагов:
Администратор клиента SaaS переходит в приложение "Подключение" и "Администратор" и завершает форму регистрации.
Приложение подключения и администрирования выдает запрос POST к API данных клиента для создания нового клиента.
API данных клиента создает новый клиент в хранилище данных клиента.
API данных клиента выдает запрос POST к API данных разрешений, чтобы предоставить администратору SaaS разрешения только что созданному клиенту.
API данных разрешений создает новую запись разрешений в хранилище данных разрешений.
API данных разрешений успешно возвращается.
API данных клиента успешно возвращается.
Приложение подключения и администрирования выдает запрос POST поставщику уведомлений электронной почты для отправки сообщения электронной почты , созданного клиентом, администратору клиента SaaS.
Поставщик уведомлений по электронной почте отправляет сообщение электронной почты.
Поставщик уведомлений по электронной почте успешно возвращается.
Приложение подключения и администрирования выдает запрос поставщику удостоверений для обновления маркера идентификатора администратора клиента SaaS, чтобы он включал утверждение JWT в только что созданный клиент.
Поставщик удостоверений выдает запрос POST с адресом электронной почты и идентификатором объекта администратора SaaS для получения своих разрешений и ролей.
API данных разрешений ищет сведения администратора клиента SaaS в хранилище данных разрешений и возвращает список разрешений и ролей, назначенных администратору клиента SaaS.
Поставщик удостоверений добавляет разрешения и роли в качестве пользовательских утверждений в маркер идентификатора.
Поставщик удостоверений возвращает маркер идентификатора в подключение и Администратор приложение.
Приложение подключения и администрирования возвращает сообщение об успешном выполнении и новый маркер идентификатора в Администратор SaaS Customer.
Добавление пользователя в клиент
Добавление пользователя в рабочий процесс клиента состоит из следующих шагов:
Администратор клиента SaaS запрашивает список клиентов из области администрирования клиента в приложении "Подключение" и "Администратор".
Приложение для подключения и администрирования выдает запрос GET к API данных клиента, чтобы получить список клиентов для администратора клиента SaaS.
API данных клиента выдает запрос GET к API данных разрешений, чтобы получить список клиентов, у администратора клиента SaaS есть доступ к просмотру.
API данных разрешений возвращает список разрешений клиента.
API данных клиента ищет сведения о клиенте в хранилище данных клиента и возвращает список данных клиента на основе списка полученных разрешений клиента.
Приложение подключения и администрирования возвращает список данных клиента администратору SaaS.
Администратор клиента SaaS выбирает клиент из списка, чтобы добавить пользователя SaaS в адрес электронной почты и ввести адрес электронной почты для пользователя SaaS.
Приложение подключения и администрирования выдает запрос POST к API данных клиента, чтобы добавить разрешение для пользователя SaaS клиента в указанном клиенте.
API данных клиента проверяет, что администратор клиента SaaS имеет допустимое утверждение JWT для указанного клиента и имеет разрешение на запись пользователя.
API данных клиента выдает запрос POST к API данных разрешений, чтобы добавить разрешение для пользователя SaaS клиента в указанном клиенте.
API данных разрешений выдает запрос GET поставщику удостоверений для поиска пользователя SaaS по указанному адресу электронной почты.
Поставщик удостоверений возвращает идентификатор объекта пользователя SaaS клиента.
API данных разрешений добавляет запись разрешений в хранилище данных разрешения для пользователя SaaS в указанном клиенте с помощью идентификатора объекта.
API данных разрешений успешно возвращается.
API данных клиента успешно возвращается.
Приложение подключения и администрирования успешно возвращается.
Компоненты
Эта архитектура использует следующие службы Azure:
Служба приложений позволяет создавать и размещать веб-приложения и приложения API на выбранном языке программирования без необходимости управлять инфраструктурой.
Azure Active Directory B2C позволяет легко управлять удостоверениями и доступом для приложений конечных пользователей.
База данных SQL Azure — это управляемая служба реляционной базы данных общего назначения, которая поддерживает реляционные данные, пространственные данные, JSON и XML.
Azure Logic Apps позволяет быстро создавать мощные интеграции с помощью простого инструмента графического интерфейса.
Альтернативные варианты
Эффективность любого альтернативного выбора зависит от модели аренды, которую планируется поддерживать приложение SaaS. Ниже приведены некоторые примеры альтернативных подходов, которые можно использовать при реализации этого решения:
Текущее решение использует Azure Active Directory B2C в качестве поставщика удостоверений. Вместо этого можно использовать другие поставщики удостоверений, такие как идентификатор Microsoft Entra.
Для более строгих требований к безопасности и соответствию можно реализовать частные сети для межслужбового взаимодействия.
Вместо использования вызовов REST между службами можно реализовать стиль архитектуры на основе событий для обмена сообщениями между службами.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для повышения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Безопасность
Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".
Это решение зависит от идентичности в качестве парадигмы безопасности. Проверка подлинности и авторизация для веб-приложений и API регулируется платформа удостоверений Майкрософт, которая отвечает за выдачу и проверку маркеров идентификатора пользователя (JWTs).
Оптимизация затрат
Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".
Компоненты в этом решении имеют некоторые затраты, связанные с их работой, но стоимость является скромной для большинства веб-приложений и решений SaaS. Кроме того, вы можете управлять затратами, управляя следующими параметрами ресурсов:
Вы можете масштабировать план Служба приложений, который запускает приложение, чтобы соответствовать необходимой пропускной способности. Кроме того, вы можете запустить каждое приложение в отдельном плане, если требуется более высокая пропускная способность, но в результате вы получите более высокую стоимость. Дополнительные сведения см. в статье Обзор планов Службы приложений Azure.
Azure AD B2C предоставляет два номера SKU: Premium P1 и Premium P2. Оба номера SKU включают бесплатное пособие по количеству ежемесячных активных пользователей (MAUS), но необходимо оценить, какие функции предоставляются для каждого номера SKU, чтобы определить, какой из них требуется для вашего варианта использования. Дополнительные сведения см. в Внешняя идентификация Microsoft Entra ценах.
В SQL Azure есть несколько моделей приобретения, которые соответствуют широкому спектру вариантов использования, включая возможность автомасштабирования. Для правильного их размера необходимо оценить использование в собственных базах данных. Дополнительные сведения см. в статье "Сравнение моделей приобретения на основе виртуальных ядер и DTU" База данных SQL Azure.
Оптимизация производительности
Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности производительности".
Эта архитектура должна быть в состоянии масштабироваться, чтобы легко соответствовать большинству средних и средних рабочих нагрузок. Так как архитектура в основном использует службы платформы Azure (PaaS), вы можете настроить масштаб решения на основе ваших требований и нагрузки.
Развертывание этого сценария
Если вы хотите развернуть этот сценарий, ознакомьтесь с пакетом средств разработки SaaS Azure на GitHub. Это развертываемая эталонная реализация этой архитектуры.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Лэндон Пирс | Инженер клиента
Другие участник:
- Крис Айерс | Старший инженер клиента
- Джон Даунс | Старший инженер клиента
- Лабрина Любя | Главный диспетчер инженеров SVC
- Гэри Мур | Программист или писатель
- Ник Пинейро | Старший консультант
- Уильям Салазар | Старший инженер клиента
- Али Санджаби | Старший инженер клиента
- Арсен Владимирский | Главный инженер клиента
- Джейсон Янг | Главный диспетчер инженеров SVC
Следующие шаги
Ниже приведены некоторые дополнительные рекомендуемые ресурсы для создания приложения SaaS в Azure:
- Разработка мультитенантных решений в Azure — описание рекомендаций.
- Рекомендации по isV для целевых зон Azure
- Хорошо разработанная платформа Microsoft Azure
- Приложение SaaS Wing Советы Tickets . Предоставляет сведения о компромиссах между различными моделями аренды в пределах уровня базы данных.
Связанные ресурсы
- Модели аренды для решения с несколькими арендаторами
- Архитектурные подходы к организации вычислений в мультитенантных решениях
- Архитектурные подходы к хранилищу и данным в мультитенантных решениях
- Рекомендации по использованию Службы приложений Azure и Функций Azure для мультитенантности
- Мультитенантная saaS в Azure
- Шаблоны облачного проектирования