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

Рекомендации по проектированию для обеспечения простоты и эффективности

  • Статья

Применяется к следующей рекомендации контрольного списка по достижению надежности Well-Architected в Power Platform:

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

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

Определения

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

Ключевые стратегии проектирования

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

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

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

Совместные дизайнерские упражнения

Работайте с заинтересованными сторонами, чтобы:

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

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

    Вот несколько примеров функциональных и нефункциональных требований в контексте рабочей нагрузки по обработке отчетов о расходах:

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

    Для получения дополнительной информации см. учебный модуль под названием Работа с требованиями для Microsoft Power Platform и Dynamics 365.

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

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

  • Определите цели доступности и восстановления для вашей рабочей нагрузки и информирования об архитектурных решениях. Бизнес-метрики включают целевые показатели уровня обслуживания (SLO), соглашения об уровне обслуживания (SLA), среднее время восстановления (MTTR), среднее время наработки на отказ (MTBF), целевые значения времени восстановления (RTO) и целевые точки восстановления (RPO). Определите целевые значения для этих метрик. Это упражнение может потребовать компромисса и взаимопонимания между технологическими и бизнес-группами, чтобы гарантировать, что цели каждой команды соответствуют бизнес-задачам и являются реалистичными. Дополнительные сведения см. в разделе Рекомендации по определению целей надежности. Соглашения об уровне обслуживания Power Platform предусматривают обязательства Microsoft по обеспечению бесперебойной работы и возможности подключения. Разные службы имеют разные соглашения об уровне обслуживания, а иногда и SKU внутри службы имеют разные соглашения об уровне обслуживания. Дополнительные сведения см. в разделе Соглашения об уровнях обслуживания для веб-служб.

Дополнительные рекомендации по проектированию

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

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

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

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

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

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

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

Разрабатывайте ровно столько кода, сколько требуется

Принципы простоты, эффективности и надежности также применимы к вашей практике разработки. Учитывайте следующие рекомендации:

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

  • Внедрите специальные сеансы проверки кода в качестве практики разработки.

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

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

Учитывайте, где находятся ваши данные

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

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

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

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

Возможности в Power Platform

Эта статья Power Apps содержит практические советы по дизайну:

См. также

Контрольный список надежности

Обратитесь к полному набору рекомендаций.

Контрольный список надежности