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