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

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

  • Статья

Применяется к этой рекомендации проверки надежности платформы Azure Well-Architected Framework:

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

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

Определения

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

Основные стратегии проектирования

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

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

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

Упражнения для совместной разработки

Обратитесь к заинтересованным лицам:

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

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

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

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

  • Определите целевые показатели доступности и восстановления для потоков для информирования архитектуры рабочей нагрузки. Бизнес-метрики включают цели уровня обслуживания (SLOS), соглашения об уровне обслуживания (СОГЛАШЕНИЯ об уровне обслуживания), среднее время восстановления (MTTR), среднее время между сбоем (MTBF), целями времени восстановления (ОСРВ) и целями точки восстановления (RPOs). Определите целевые значения для этих метрик. В этом упражнении может потребоваться компрометация и взаимное понимание между технологиями и бизнес-командами для обеспечения того, чтобы цели каждой команды соответствовали бизнес-целям и реалистично. Дополнительные сведения см . в рекомендациях по определению целевых показателей надежности.

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

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

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

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

  • Используйте параметры платформы как услуги (PaaS) вместо инфраструктуры как услуги (IaaS). IaaS предоставляет лишь набор компонентов. Вы можете собрать из них что угодно, но придется делать это самостоятельно. Варианты PaaS проще настраивать и администрировать. Вам не нужно настраивать виртуальные машины или виртуальные сети. Вам также не нужно выполнять задачи обслуживания, такие как установка исправлений и обновлений.

  • Используйте асинхронный обмен сообщениями , чтобы отделить производителя сообщений от потребителя.

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

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

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

Разработка достаточного кода

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

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

  • Используйте библиотеки и платформы.

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

  • Реализуйте подход для определения мертвого кода. Скептицируйте код, который автоматические тесты не охватывают.

Использование лучшего хранилища данных для данных

В прошлом многие организации хранят все данные в больших реляционных базах данных SQL. Реляционные базы данных обеспечивают атомарные, согласованные, изолированные и устойчивые (ACID) гарантии для транзакций реляционных данных. Но эти базы данных приходят с недостатками:

  • Запросы могут требовать дорогостоящих соединений.

  • Необходимо нормализовать данные и реструктурировать его для схемы при записи.

  • Блокировка конфликтов может повлиять на производительность.

Альтернативные варианты реляционных баз данных

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

  • Хранилища "ключ-значение"

  • Базы данных документов

  • Базы данных поисковой системы

  • Базы данных временных рядов

  • Базы данных семейства столбцов

  • Графовые базы данных

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

Например, можно хранить каталог продуктов в базе данных документов, например Azure Cosmos DB, которая поддерживает гибкую схему. Каждое описание продукта является автономным документом. Для запросов по всему каталогу можно индексировать каталог и хранить индекс в Когнитивный поиск Azure. Инвентаризация продуктов может перейти в базу данных SQL, так как для этого требуются гарантии ACID.

Рекомендации

  • Рассмотрим другие хранилища данных. Реляционные базы данных не всегда подходит. Дополнительные сведения см. в разделе "Общие сведения о моделях хранилища данных".

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

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

  • Рассмотрим тип данных, которые у вас есть. Например, хранилище:

    • Транзакционные данные в базе данных SQL.

    • Документы JSON в базе данных документов.

    • Данные телеметрии в базе данных временных рядов.

    • Журналы приложений в Когнитивный поиск Azure.

    • Большие двоичные объекты в Хранилище BLOB-объектов Azure.

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

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

    • Оптимизируйте запросы.

    • Настройка производительности.

    • Обратитесь к соответствующим шаблонам использования.

Учитывайте эти факторы при выборе технологии хранения:

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

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

Упрощение функций Azure

Azure предлагает следующие службы:

  • Функции Azure — это бессерверная служба вычислений, которую можно использовать для создания оркестрации с минимальным кодом.

  • Azure Logic Apps — это бессерверная платформа интеграции рабочих процессов, которую можно использовать для создания оркестрации с помощью графического интерфейса пользователя или редактирования файла конфигурации.

  • Сетка событий Azure — это высокомасштабируемая полностью управляемая служба распространения сообщений публикации и подписки, которая предлагает гибкие шаблоны потребления сообщений, использующие протоколы MQTT и HTTP. С помощью сетки событий можно создавать конвейеры данных с данными устройства, создавать бессерверные архитектуры на основе событий и интегрировать приложения.

Дополнительные сведения см. в разделе:

Пример

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

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

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

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