Рекомендации по проектированию для обеспечения простоты и эффективности
Применимо к этой рекомендации Power Platform контрольного списка надежности, хорошо продуманной архитектуры:
РЕ: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 Copilot Studio
Внедрите специальные сеансы проверки кода в качестве практики разработки.
Внедрите подход для выявления мертвого кода. Скептически относитесь к коду, который не охватывается вашими автоматическими тестами.
Учитывайте набор навыков вашей команды разработчиков. Чтобы освоить новый навык или внедрить новую технологию, требуется время.
Учитывайте, где находятся ваши данные
В рамках архитектурного проекта вам необходимо подумать о том, как хранить данные или как извлекать их для операций чтения. Данные можно извлекать и хранить различными способами:
Новые данные: Если ваше приложение создает данные, которых еще не существует, например, когда существующий бизнес-процесс был выполнен на бумаге, мы рекомендуем хранить данные в Microsoft Dataverse.
Чтение/запись из существующей системы: если вашему приложению необходимо извлекать данные из существующей базы данных или системы, вам необходимо оценить наилучший способ подключения к базе данных или системе: с помощью готового коннектора, настраиваемого коннектора или виртуальных таблиц.
Создайте копию данных: в ситуациях, когда исходные данные никогда не должны изменяться или перезаписываться, вы можете скопировать данные в другой хранилище данных, например Dataverse. Эта стратегия сохраняет исходные данные системы неизменными, позволяя приложению работать с ними. Этот сценарий распространен при работе с данными в бухгалтерском учете и системами, связанными с доходами. Вам необходимо учитывать, как данные копируются, как часто они обновляются и требуется ли двусторонняя синхронизация.
Возможности в Power Platform
Практические советы по дизайну можно найти в следующих статьях:
Power Apps:
- Определение места размещения логики в вашей системе: приложения на основе холста, приложения на основе модели, Microsoft Dataverse или потоки Power Automate
- Определение типа приложения для создания: приложения на основе моделей или приложения на основе холста
- Моделирование данных: проектирование структуры данных
- Проектирование данных: работа с корпоративными системами
Power Automate:
Copilot Studio:
- Microsoft Copilot Studio Руководство по внедрению предоставляет основу для проведения всестороннего обзора вашего проекта. Задавая контрольные вопросы, он выявляет потенциальные риски и пробелы, согласовывает проект с дорожной картой продукта и делится рекомендациями, передовым опытом и примерами референтной архитектуры.
- Microsoft Copilot Studio Руководящая документация содержит передовой опыт, советы по внедрению и рекомендации по архитектуре от команды, которая сотрудничает с нашими корпоративными клиентами.
Дополнительные сведения
- Соглашения об уровне обслуживания для онлайн-сервисов
- Работа с требованиями для Microsoft Power Platform и Dynamics 365
- Планирование Power Apps проекта
- Планирование Power Automate проекта
- Планирование проекта разговорного ИИ
Контрольный список надежности
Обратитесь к полному набору рекомендаций.