Упражнение. Создание многоуровневой структуры работоспособности
В этом упражнении задача заключается в разработке многоуровневой модели работоспособности для примера приложения. Начните с изучения архитектуры приложения, ключевых служб Azure, которые использует приложение, и того, как службы Azure вносят свой вклад в общую работу пользователей.
Пример приложения
Примером этого упражнения является веб-приложение, используемое Contoso Shoes. Приложение позволяет сотрудникам просматривать каталог продуктов, обновлять отдельные элементы в каталоге и взаимодействовать с другими пользователями, создавая комментарии в приложении.
Группа операций компании Contoso Shoes определила два критически важных бизнес-требования для этого приложения. Сотрудники должны иметь возможность:
- Взаимодействуйте с каталогом, отображая списки элементов и просматривая элементы.
- Создайте примечания для отдельных элементов для просмотра других пользователей.
Модель работоспособности должна включать по крайней мере эти две критически важные операции.
Архитектура
Компоненты
Интерфейсное веб-приложение: пользовательский интерфейс этой рабочей нагрузки, который выполняется в Azure веб-приложения.
- Чтение из: API каталога, Хранилище BLOB-объектов Azure
- Запись в: API каталога
API каталога: уровень API, который интерфейсное веб-приложение использует для операций с данными для элементов каталога и комментариев. Он не записывается в базу данных. Вместо этого сообщение отправляется в концентратор событий для асинхронной обработки. Этот компонент размещен в Функции Azure.
- Чтение из: Azure Cosmos DB
- Записывает данные в: Центры событий Azure
Фоновый обработчик: компонент, который асинхронно обрабатывает обновления базы данных. Обработчик не имеет общедоступной конечной точки. Этот компонент размещен в Функции Azure.
- Считывает из: Центры событий Azure
- Запись в: Azure Cosmos DB
Брокер сообщений: обработчик обмена сообщениями использует Центры событий Azure для передачи сообщений между API каталога и фоновым обработчиком.
База данных: данные сохраняются в Azure Cosmos DB. API каталога считывает данные из базы данных напрямую. Фоновый обработчик обрабатывает операции записи. Изображения хранятся в Хранилище BLOB-объектов Azure.
Секреты: компоненты приложения этой рабочей нагрузки используют секреты для авторизации доступа. Секреты хранятся в Azure Key Vault. API каталога и фоновый процессор используют строка подключения для доступа к базе данных и Центры событий Azure. Интерфейсное веб-приложение использует ключ API для вызова API каталога.
Мониторинг: компоненты приложений отправляют все измерения данных в Application Insights, поддерживаемые рабочей областью Log Analytics. Та же рабочая область используется для сбора других журналов и метрик для этой рабочей нагрузки.
Разделение архитектуры на слоях
Как описано в предыдущем уроке, модель работоспособности должна быть многоуровневой структурой. Процесс моделирования работоспособности — это архитектурное упражнение для определения всех потоков пользователей, сопоставления зависимостей между функциональными и логическими компонентами, а также зависимостей между ресурсами Azure.
Определение потоков пользователей и создание модели работоспособности — это концептуальное упражнение на этом этапе. Используйте перо и бумагу или пустой документ, чтобы заметить отдельные слои и нарисовать структуру.
Для этого упражнения наша модель работоспособности имеет три уровня: потоки пользователей, компоненты приложений и ресурсы Azure.
Маршруты пользователей
Начиная с верхней части архитектуры, думайте о возможных потоках пользователей на основе ожидаемых функциональных возможностей приложения. Попробуйте абстрагировать технические сведения и службы Azure и оценить потоки с точки зрения пользователя.
- Какие процессы критически важны?
- Как сотрудники используют приложение для достижения бизнес-целей?
В зависимости от требований, определенных командой операций, необходимо иметь по крайней мере два потока пользователя на верхнем уровне: элементы каталога списка и добавление комментариев.
Если вы можете подумать больше, включите их в модель работоспособности.
Компоненты приложения
Переместите слой вниз и оцените компоненты приложения. Начните с вопросов, таких как:
- "Какая часть приложения делает этот поток работой?"
- "Какие микрослужбы или компоненты участвуют в этом потоке?"
- "Будет ли этот поток по-прежнему работать, если эта часть завершается ошибкой?"
Цель заключается в определении компонентов приложений на техническом уровне, которые способствуют каждому потоку пользователей. Эти компоненты могут быть API, фоновые рабочие роли, микрослужбы и т. д.
Эта рабочая нагрузка имеет по крайней мере три компонента приложения, которые участвуют в двух определенных потоках пользователей: интерфейсный интерфейс, API каталога и фоновый процессор.
Ресурсы Azure
Нижний слой содержит ресурсы Azure, используемые отдельными компонентами приложения. В этом упражнении компоненты и ресурсы описаны в разделе "Компоненты ".
Примечание.
Реальный сценарий, вероятно, будет иметь больше служб и иметь более сложные отношения между ними. Ключом к созданию успешной модели работоспособности является определение критически важных частей и то, как каждый компонент способствует общей работоспособности системы.
Рисование окончательной структуры модели работоспособности
Поместите сведения, собранные в графическом представлении структуры модели работоспособности. Он должен выглядеть примерно так:
В верхней до нижней части модель работоспособности веб-приложения имеет следующие уровни:
Маршруты пользователей
- Список элементов каталога. Зависит от интерфейсного веб-приложения и API каталога.
- Добавьте комментарий. Зависит от интерфейсного веб-приложения, API каталога и фонового процессора.
Компоненты приложения
- Интерфейсное веб-приложение. Зависит от хранилища BLOB-объектов и API каталога.
- API каталога. Зависит от Azure Cosmos DB, Key Vault и Центров событий.
- Фоновый процессор. Зависит от Azure Cosmos DB, Key Vault и Центров событий.
Ресурсы Azure
- Хранилище BLOB-объектов
- Azure Cosmos DB
- Хранилище ключей
- Центры событий