Рекомендации по проектированию для простоты и эффективности
Применяется к этой рекомендации по контрольным спискам надежности Платформы Azure Well-Architected Framework:
| RE:01 | Проектируйте рабочую нагрузку в соответствии с бизнес-целями и избегайте ненужных сложностей или накладных расходов. Используйте практический и сбалансированный подход для принятия проектных решений, которые обеспечивают желаемые результаты. Сведите свой проект к необходимым, чтобы уменьшить неэффективность и потенциальные проблемы. |
|---|
В этом руководстве описаны рекомендации по минимизации ненужных сложностей и накладных расходов, чтобы обеспечить простоту и эффективность рабочих нагрузок. Выберите лучшие компоненты для выполнения необходимых задач рабочей нагрузки для оптимизации надежности рабочей нагрузки. Чтобы уменьшить нагрузку на разработку и управление, воспользуйтесь преимуществами эффективности предоставляемых платформой служб. Такая схема помогает создать устойчивую, повторяемую, масштабируемую и управляемую архитектуру рабочей нагрузки.
Определения
| Термин | Определение |
|---|---|
| Рабочая нагрузка | Дискретная возможность или вычислительная задача, которую можно логически отделить от других задач. |
Ключевые стратегии проектирования
Ключевым принципом проектирования для обеспечения надежности является обеспечение простоты и эффективности. Сфокусируйте структуру рабочей нагрузки на соответствие бизнес-требованиям, чтобы снизить риск ненужной сложности или лишних накладных расходов. Ознакомьтесь с рекомендациями в этой статье, которые помогут вам принять решения о проектировании для создания экономичной, эффективной и надежной рабочей нагрузки. Разные рабочие нагрузки могут иметь разные требования к доступности, масштабируемости, согласованности данных и аварийному восстановлению.
Каждое проектное решение необходимо обосновать бизнес-требованиями. Этот принцип проектирования может показаться очевидным, но он имеет решающее значение для проектирования рабочей нагрузки. Поддерживает ли ваше приложение миллионы пользователей или несколько тысяч пользователей? Есть ли большие пики трафика или устойчивая рабочая нагрузка? Какой уровень сбоя приложения является допустимым? Эти рекомендации по проектированию учитываются в бизнес-требованиях.
Компромисс. Сложное решение может предложить больше возможностей и гибкости, но может повлиять на надежность рабочей нагрузки, так как требует большей координации, взаимодействия и управления компонентами. Кроме того, более простое решение может не полностью соответствовать ожиданиям пользователей или негативно влиять на масштабируемость и расширяемость по мере развития рабочей нагрузки.
Упражнения по совместному проектированию
Работайте с заинтересованными лицами, чтобы:
Определите и назначьте уровень важности потокам пользователей и системным потокам рабочей нагрузки. Сосредоточьтесь на критически важных потоках , чтобы определить необходимые компоненты и оптимальный подход для достижения требуемого уровня устойчивости.
Определите функциональные и нефункциональные требования. Рассмотрите функциональные требования, чтобы определить, выполняет ли приложение задачу. Рассмотрите нефункциональные требования, чтобы определить, насколько хорошо приложение выполняет задачу. Убедитесь, что вы понимаете нефункциональные требования, такие как масштабируемость, доступность и задержка. Эти требования влияют на проектные решения и выбор технологий.
Разложить рабочие нагрузки на компоненты. Приоритизация простоты, эффективности и надежности проекта. Определите компоненты, необходимые для поддержки потоков. Некоторые компоненты поддерживают несколько потоков. Определите, какую задачу концептуально решает компонент, и рассмотрите возможность удаления компонента из отдельных потоков, чтобы упростить общую структуру и при этом обеспечить полную функциональность. Дополнительные сведения см. в разделе Рекомендации по выполнению анализа режима сбоя.
Используйте анализ режима сбоя для выявления отдельных точек отказа и потенциальных рисков. Подумайте, нужно ли учитывать маловероятные ситуации, например в географической области, где происходит серьезное стихийное бедствие, затрагивающее все зоны доступности в регионе. Это дорого и подразумевает значительные компромиссы для снижения этих необычных рисков. Четкое понимание допустимости риска для вашего бизнеса. Дополнительные сведения см. в разделе Рекомендации по выполнению анализа режима сбоя.
Определите целевые показатели доступности и восстановления для потоков, чтобы информировать архитектуру рабочей нагрузки. Бизнес-метрики включают цели уровня обслуживания (SLO), соглашения об уровне обслуживания (SLA), среднее время восстановления (MTTR), среднее время между сбоями (MTBF), цели времени восстановления (ОРВ) и цели точки восстановления (RPO). Определите целевые значения для этих метрик. Это упражнение может потребовать компромисса и взаимопонимания между технологическими и бизнес-командами, чтобы гарантировать, что цели каждой команды соответствуют бизнес-целям и являются реалистичными. Дополнительные сведения см. в статье Рекомендации по определению целевых показателей надежности.
Дополнительные рекомендации по проектированию
Вы можете выполнять следующие рекомендации без участия заинтересованных лиц:
Стремитесь к простоте и ясности в дизайне. Используйте соответствующий уровень абстракции и детализации для компонентов и служб. Избегайте чрезмерной инженерии или недостаточной разработки решения. Например, если разбить код на несколько небольших функций, его сложно понять, протестировать и поддерживать.
Согласимся, что все успешные приложения со временем меняются, будь то исправление ошибок, реализация новых функций или технологий или создание существующих систем более масштабируемыми и устойчивыми.
По возможности используйте варианты PaaS (платформа как услуга) вместо инфраструктуры как услуги (IaaS). IaaS предоставляет лишь набор компонентов. Вы можете собрать из них что угодно, но придется делать это самостоятельно. Варианты PaaS проще настраивать и администрировать. Вам не нужно настраивать виртуальные машины или виртуальные сети. Вам также не нужно выполнять задачи обслуживания, такие как установка исправлений и обновлений.
Используйте асинхронный обмен сообщениями , чтобы отделить производителя сообщения от потребителя.
Абстрагируйте инфраструктуру от логики предметной области. Убедитесь, что логика предметной области не влияет на функциональные возможности, связанные с инфраструктурой, такие как обмен сообщениями или сохраняемость.
Разгружайте сквозные функции в отдельную службу. Сведите к минимуму необходимость дублирования кода в разных функциях, предпочитая повторно использовать службы с четко определенными интерфейсами, которые могут легко использоваться разными компонентами. Например, если для проверки подлинности запросов требуется несколько служб, можно переместить эту функцию в собственную службу. Затем можно усовершенствовать службу проверки подлинности. Например, можно добавить новый поток проверки подлинности, не касаясь служб, которые его используют.
Оцените пригодность распространенных шаблонов и методик в соответствии со своими потребностями. Избегайте следующих тенденций или рекомендаций, которые могут оказаться не лучшими для вашего контекста или требований. Например, микрослужбы не являются лучшим вариантом для каждого приложения, так как они могут привести к сложности, издержкам и проблемам с зависимостями.
Разработка достаточного количества кода
Принципы простоты, эффективности и надежности также применяются к вашим методикам разработки. В слабосвязанной, компонентной рабочей нагрузке определите функциональные возможности, предоставляемые компонентом. Разработайте потоки, чтобы воспользоваться преимуществами этой функции. Примите во внимание следующие рекомендации для ваших методик разработки:
Используйте возможности платформы, если они соответствуют вашим бизнес-требованиям. Например, чтобы разгрузить разработку и управление, используйте решения с низким уровнем кода, без кода или бессерверные решения, предлагаемые поставщиком облачных служб.
Используйте библиотеки и платформы.
Введите сеансы по программированию пар или выделенному анализу кода в качестве практики разработки.
Реализуйте подход для выявления неработающего кода. Будьте скептически отношусь к коду, который не охватывают автоматические тесты.
Используйте лучшее хранилище данных для своих данных
В прошлом многие организации хранили все свои данные в больших реляционных базах данных SQL. Реляционные базы данных предоставляют атомарные, согласованные, изолированные и устойчивые (ACID) гарантии для транзакций с реляционными данными. Но у этих баз данных есть недостатки:
Запросы могут требовать дорогостоящих соединений.
Необходимо нормализовать данные и реструктурировать их для схемы при записи.
Состязание за блокировку может повлиять на производительность.
Альтернативы реляционным базам данных
В крупном решении одна технология хранилища данных, скорее всего, не соответствует всем вашим потребностям. Альтернативы реляционным базам данных:
Хранилища "ключ-значение"
Базы данных документов
Базы данных поисковой системы
Базы данных временных рядов
Базы данных семейства столбцов
Графовые базы данных
Каждый вариант имеет плюсы и недостатки. Различные типы данных лучше подходят для разных типов хранилищ данных. Выберите технологию хранения, которая лучше всего подходит для ваших данных, и способ их использования.
Например, каталог продуктов можно хранить в базе данных документов, такой как Azure Cosmos DB, которая поддерживает гибкую схему. Каждое описание продукта является автономным документом. Для запросов ко всему каталогу можно индексировать каталог и сохранить индекс в Когнитивный поиск Azure. Инвентаризация продуктов может попасть в базу данных SQL, так как для этого требуются гарантии ACID.
Рекомендации
Рассмотрим другие хранилища данных. Реляционные базы данных не всегда подходит. Дополнительные сведения см. в статье Общие сведения о моделях хранилища данных.
Помните, что данные включают не только сохраненные данные приложения. Есть еще и журналы приложений, события, сообщения и кэши.
Используйте сохраняемость polyglot или решения, использующие сочетание технологий хранилища данных.
Рассмотрим тип имеющихся данных. Например, сохраните:
Данные транзакций в базе данных SQL.
Документы JSON в базе данных документов.
Данные телеметрии в базе данных временных рядов.
Журналы приложений в Когнитивный поиск Azure.
BLOB-объекты в Хранилище BLOB-объектов Azure.
Приоритизация доступности над согласованностью. Теорема CAP подразумевает, что необходимо найти компромисс между доступностью и согласованностью в распределенной системе. Вы не можете полностью избежать сетевых секций, которые являются другим компонентом теоремы CAP. Но вы можете внедрить модель итоговой согласованности, чтобы обеспечить более высокую доступность.
Рассмотрите набор навыков вашей команды разработчиков. Многоязычное хранение дает значительные преимущества, но важно не перейти границы. Для внедрения новой технологии хранения данных требуются новые навыки. Чтобы максимально эффективно использовать технологии, команда разработчиков должна:
Оптимизируйте запросы.
Настройка для повышения производительности.
Работайте с соответствующими шаблонами использования.
При выборе технологии хранения учитывайте следующие факторы:
Используйте компенсирующие транзакции. При сохраняемости polyglot одна транзакция может записывать данные в несколько хранилищ. Если произошел сбой, используйте компенсирующие транзакции, чтобы отменить все завершенные шаги.
Рассмотрим ограниченные контексты, которые являются концепцией проектирования на основе предметной области. Ограниченный контекст — это явная граница вокруг модели предметной области. Ограниченный контекст определяет, к каким частям домена применяется модель. В идеальном случае ограниченный контекст обозначает конкретный сегмент предметной области. Рассмотрите возможность сохранения полиглотов для ограниченных контекстов в системе. Например, продукты могут отображаться в поддомене каталога продуктов и поддомене инвентаризации продуктов. Но, скорее всего, эти два поддомена имеют разные требования к хранению, обновлению и запросу продуктов.
Упрощение поддержки Azure
Azure предлагает следующие службы:
Функции Azure — это бессерверная служба вычислений, которую можно использовать для создания оркестрации с минимальным кодом.
Azure Logic Apps — это бессерверная платформа интеграции рабочих процессов, которую можно использовать для создания оркестрации с графическим интерфейсом пользователя или путем редактирования файла конфигурации.
Сетка событий Azure — это высокомасштабируемая полностью управляемая служба распространения сообщений публикации и подписки, которая предлагает гибкие шаблоны потребления сообщений, использующие протоколы MQTT и HTTP. С помощью Службы "Сетка событий" можно создавать конвейеры данных с данными устройств, создавать управляемые событиями бессерверные архитектуры и интегрировать приложения.
Дополнительные сведения см. в разделе:
Пример
Пример рабочей нагрузки, которая определяет компоненты и их функции на основе требований, см. в разделе Шаблон Reliable Web App.
Связанные ссылки
Контрольный список надежности
См. полный набор рекомендаций.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по