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

Сводка. Разработка облачных приложений

  • Статья

Совет

Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать в формате PDF

Cloud Native .NET apps for Azure eBook cover thumbnail.

Ниже приведены важные выводы из этого руководства.

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

  • Cloud Native Computing Foundation (CNCF) является влиятельным консорциумом с открытым кодом более 300 крупных корпораций. Она отвечает за внедрение облачных вычислений в технологических и облачных стеках.

  • Рекомендации CNCF рекомендуют, чтобы облачные приложения охватывали шесть важных основных компонентов, как показано на рис. 11-1:

    Cloud-native foundational pillars

    Рис. 11-1. Базовые основы в облаке

  • К этим облачным основам относятся следующие компоненты:

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

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

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

  • gRPC — это современная высокопроизводительная платформа, развивающая протокол вызова удаленной процедуры (RPC). Облачные приложения часто принимают gRPC для упрощения обмена сообщениями между внутренними службами. gRPC использует HTTP/2 для своего транспортного протокола. Это может быть до 8x быстрее, чем сериализация JSON с размером сообщения 60–80 % меньше. gRPC открытый код и управляется Cloud Native Computing Foundation (CNCF).

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

  • Базы данных No-SQL ссылаются на высокопроизводительные нереляционные хранилища данных. Они отличаются своими характеристиками удобства использования, масштабируемости, устойчивости и доступности. Службы с большим объемом, для которых требуется время ответа в секунду, предпочитают хранилища данных NoSQL. Распространение технологий NoSQL для распределенных облачных систем невозможно переоценить.

  • NewSQL — это новая технология базы данных, которая объединяет распределенную масштабируемость NoSQL и гарантии ACID реляционной базы данных. Базы данных NewSQL предназначены для бизнес-систем, которые должны обрабатывать большие объемы данных в распределенных средах с полным соответствием транзакций или ACID. Cloud Native Computing Foundation (CNCF) включает несколько проектов базы данных NewSQL.

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

  • Сетки служб — это настраиваемый уровень инфраструктуры с встроенными возможностями для обработки связи служб и других перекрестных проблем. Они отделяют перекрестные обязанности от бизнес-кода. Эти обязанности перемещаются в прокси-сервер службы. Sidecar patternЭтот прокси-сервер развертывается в отдельный процесс, чтобы обеспечить изоляцию от бизнес-кода.

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

  • Инфраструктура как код является широко принятой практикой, которая автоматизирует подготовку платформы. Инфраструктура и развертывания являются автоматизированными, согласованными и повторяемыми. Такие инструменты, как Azure Resource Manager, Terraform и Azure CLI, позволяют декларативно скриптировать требуемую облачную инфраструктуру.

  • Автоматизация кода — это требование для облачных приложений. Современные системы CI/CD помогают выполнить этот принцип. Они предоставляют отдельные этапы сборки и развертывания, которые помогают обеспечить согласованность и качество кода. Этап сборки преобразует код в двоичный артефакт. Этап выпуска выбирает двоичный артефакт, применяет конфигурацию внешней среды и развертывает ее в указанной среде. Azure DevOps и GitHub являются полнофункционными средами DevOps.

Предыдущий