Что такое "ориентированный на облако"?
Совет
Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
Остановите то, что вы делаете, и попросите своих коллег определить термин Cloud Native. Есть хороший шанс, что вы получите несколько различных ответов.
Начнем с простого определения:
Облачная архитектура и технологии — это подход к проектированию, созданию и эксплуатации рабочих нагрузок, встроенных в облако, а также к использованию модели облачных вычислений.
Cloud Native Computing Foundation предоставляет официальное определение:
Облачные технологии позволяют организациям создавать и запускать масштабируемые приложения в современных динамических средах, таких как общедоступные, частные и гибридные облака. Контейнеры, сетки служб, микрослужбы, неизменяемая инфраструктура и декларативные API иллюстрируют этот подход.
Эти методы позволяют слабо связаны системы, которые являются устойчивыми, управляемыми и наблюдаемыми. В сочетании с надежной автоматизацией инженеры позволяют инженерам часто и предсказуемо вносить изменения с минимальным уровнем нагрузки.
Облачная машинная среда — это скорость и гибкость. Бизнес-системы развиваются от включения бизнес-возможностей к оружию стратегического преобразования, которые ускоряют скорость бизнеса и рост. Очень важно немедленно получить новые идеи на рынок.
В то же время бизнес-системы также становятся все более сложными с пользователями, требуя больше. Они ожидают быстрое реагирование, инновационные функции и нулевое время простоя. Проблемы с производительностью, повторяющиеся ошибки и неспособность быстро перемещаться больше не допускаются. Ваши пользователи будут посещать своего конкурента. Облачные системы предназначены для быстрого изменения, большого масштаба и устойчивости.
Ниже приведены некоторые компании, которые реализовали облачные методы. Подумайте о скорости, гибкости и масштабируемости, которую они достигли.
| Company | Взаимодействие |
|---|---|
| Netflix | Имеет 600+ служб в рабочей среде. Развертывает 100 раз в день. |
| Uber | Имеет 1000+ служб в рабочей среде. Развертывается несколько тысяч раз в неделю. |
| Имеет 3000+ служб в рабочей среде. Развертывает 1000 раз в день. |
Как видите, Netflix, Uber и WeChat предоставляют облачные системы, состоящие из множества независимых служб. Этот архитектурный стиль позволяет им быстро реагировать на рыночные условия. Они мгновенно обновляют небольшие области динамического, сложного приложения без полного повторного развертывания. Они по отдельности масштабируют службы по мере необходимости.
Основные принципы облачной собственной среды
Скорость и гибкость машинного облака являются производными от многих факторов. Прежде всего это облачная инфраструктура. Но есть больше: Пять других базовых столпов, показанных на рис. 1-3, также предоставляют основу для облачных систем.
Рис. 1-3. Базовые основы в облаке
Давайте заберем некоторое время, чтобы лучше понять важность каждого столпа.
Облако
Облачные системы используют все преимущества модели облачной службы.
Разработанная для процветания в динамической виртуализированной облачной среды, эти системы используют инфраструктуру вычислений платформы как услуги и управляемые службы. Они обрабатывают базовую инфраструктуру как удаляемую — подготовленную в минутах и измененную, масштабируемую или уничтоженную по требованию— с помощью автоматизации.
Рассмотрим разницу между тем, как мы лечим домашних животных и сырьевых товаров. В традиционном центре обработки данных серверы рассматриваются как домашние животные: физический компьютер, учитывая понятное имя и заботился о них. Масштабируйте путем добавления дополнительных ресурсов на тот же компьютер (увеличение масштаба). Если сервер заболеет, вы кормите его обратно в здоровье. Если сервер станет недоступным, все замечают.
Модель обслуживания сырьевых товаров отличается. Вы подготавливаете каждый экземпляр как виртуальную машину или контейнер. Они идентичны и назначают системный идентификатор, например Service-01, Service-02 и т. д. Вы масштабируете, создавая дополнительные экземпляры (масштабирование). Никто не замечает, когда экземпляр становится недоступным.
Модель сырьевых товаров охватывает неизменяемую инфраструктуру. Серверы не восстанавливаются или не изменяются. Если один из них завершается ошибкой или требует обновления, он уничтожен и подготовлен новый — все выполняется с помощью автоматизации.
Облачные системы принимают модель службы сырьевых товаров. Они продолжают работать как инфраструктура масштабируется в или вне без учета компьютеров, на которых они работают.
Облачная платформа Azure поддерживает этот тип высокоэластичной инфраструктуры с автоматическим масштабированием, самовосстановлением и возможностями мониторинга.
Современный дизайн
Как создать облачное приложение? Как будет выглядеть архитектура? Каким принципам, шаблонам и рекомендациям вы будете придерживаться? Какие проблемы с инфраструктурой и операционной деятельностью будут важны?
Приложение двенадцатифакторов
Широко приемлемая методология создания облачных приложений — это приложение двенадцатифакторов. В нем описывается набор принципов и методик, которые разработчики следуют созданию приложений, оптимизированных для современных облачных сред. Особое внимание уделяется переносимости между средами и декларативной автоматизации.
Несмотря на то, что применимо к любому веб-приложению, многие практикующие специалисты считают Двенадцатифактор твердым фундаментом для создания облачных приложений. Системы, основанные на этих принципах, могут быстро развертывать и масштабироваться и добавлять функции для быстрого реагирования на изменения рынка.
В следующей таблице описана методология двенадцатифакторов:
| Множитель | Описание |
|---|---|
| 1 . База кода | Отдельная база кода для каждой микрослужбы, хранящейся в собственном репозитории. Отслеживаемая с помощью управления версиями, она может развертываться в нескольких средах (QA, промежуточной, рабочей среде). |
| 2 . Зависимости | Каждая микрослужба изолирует и упаковывает свои собственные зависимости, охватывая изменения, не влияя на всю систему. |
| 3. Конфигурации | Сведения о конфигурации перемещаются из микрослужбы и внешние с помощью средства управления конфигурацией за пределами кода. То же развертывание может распространяться в разных средах с правильной конфигурацией. |
| 4. Резервные службы | Дополнительные ресурсы (хранилища данных, кэши, брокеры сообщений) должны предоставляться с помощью URL-адреса, допускающего адрес. Это позволяет отделить ресурс от приложения, что позволяет ему быть взаимозаменяемым. |
| 5. Сборка, выпуск, запуск | Каждый выпуск должен обеспечивать строгое разделение по этапам сборки, выпуска и выполнения. Каждый из них должен быть помечен уникальным идентификатором и поддерживать возможность отката. Современные системы CI/CD помогают выполнить этот принцип. |
| 6 . Процессы | Каждая микрослужба должна выполняться в собственном процессе, изолированном от других запущенных служб. Внешний тип требуемого состояния в резервной службе, например распределенном кэше или хранилище данных. |
| 7 . Привязка портов | Каждая микрослужба должна быть автономной с его интерфейсами и функциональностью, предоставляемыми на собственном порту. Это обеспечивает изоляцию от других микрослужб. |
| 8 — параллелизм | При увеличении емкости горизонтальное масштабирование служб между несколькими идентичными процессами (копиями) в отличие от масштабирования одного крупного экземпляра на самом мощном компьютере. Разработайте приложение для параллельного масштабирования в облачных средах. |
| 9 . Удаление | Экземпляры служб должны быть удалены. Предпочитайте быстрый запуск, чтобы увеличить возможности масштабируемости и корректное завершение работы, чтобы оставить систему в правильном состоянии. Контейнеры Docker вместе с оркестратором по сути удовлетворяют этому требованию. |
| 10 — Dev/Prod Parity | Сохраняйте среды в жизненном цикле приложения как можно скорее, избегая дорогостоящих сочетаний клавиш. Здесь внедрение контейнеров может значительно способствовать продвижению той же среды выполнения. |
| 11 . Ведение журнала | Обрабатывать журналы, созданные микрослужбами, как потоки событий. Обработайте их с помощью агрегатора событий. Распространяйте данные журнала на средства управления данными, такие как Azure Monitor или Splunk, и в конечном итоге к долгосрочной архивации. |
| 12 — процессы Администратор | Выполнение задач администрирования или управления, таких как очистка данных или аналитика вычислений, в качестве одноуровневых процессов. Используйте независимые средства для вызова этих задач из рабочей среды, но отдельно от приложения. |
В книге,За пределами двенадцатифакторного приложения автор Кевин Хоффман подробно описывает каждый из исходных 12 факторов (написанных в 2011 году). Кроме того, он обсуждает три дополнительных фактора, которые отражают современный дизайн облачных приложений.
| Новый фактор | Описание |
|---|---|
| 13 — API first | Сделайте все службы. Предположим, что код будет использоваться интерфейсным клиентом, шлюзом или другой службой. |
| 14 . Телеметрия | На рабочей станции у вас есть глубокое представление о приложении и его поведении. В облаке нет. Убедитесь, что проект включает в себя коллекцию данных мониторинга, домена и работоспособности и системных данных. |
| 15. Проверка подлинности и авторизация | Реализуйте удостоверение с самого начала. Рассмотрим функции RBAC (управление доступом на основе ролей), доступные в общедоступных облаках. |
Мы будем ссылаться на многие из 12+ факторов в этой главе и на протяжении всей книги.
Платформа Azure с продуманной архитектурой
Проектирование и развертывание облачных рабочих нагрузок может быть сложной задачей, особенно при реализации облачной архитектуры. Корпорация Майкрософт предоставляет стандартные отраслевые рекомендации, помогающие вам и вашей команде предоставлять надежные облачные решения.
Платформа Microsoft Well-Architected Framework предоставляет набор руководящих принципов, которые можно использовать для улучшения качества облачной рабочей нагрузки. Платформа состоит из пяти основных компонентов качественной архитектуры:
| Принципов | Description |
|---|---|
| Управление затратами | Сосредоточьтесь на создании добавочного значения раньше. Применение принципов Build-Measure-Learn для ускорения времени на рынке, избегая капиталоемких решений. Используя стратегию оплаты по мере использования, инвестируйте по мере масштабирования, а не предоставляя большие инвестиции вперед. |
| Эффективность работы | Автоматизация среды и операций для повышения скорости и уменьшения человеческой ошибки. Откат обновлений проблем обратно или вперед быстро. Реализуйте мониторинг и диагностика с самого начала. |
| Оптимизация производительности | Эффективнее удовлетворять требования, заданные для рабочих нагрузок. Предпочитайте горизонтальное масштабирование (масштабирование) и проектируйте его в ваших системах. Постоянно проводите тестирование производительности и нагрузки для выявления потенциальных узких мест. |
| Надежность | Создайте рабочие нагрузки, которые являются устойчивыми и доступными. Устойчивость позволяет рабочим нагрузкам восстанавливаться после сбоев и продолжать работу. Доступность обеспечивает пользователям доступ к рабочей нагрузке в любое время. Разработка приложений для ожидания сбоев и восстановления от них. |
| Безопасность | Реализуйте безопасность в течение всего жизненного цикла приложения, от проектирования и реализации до развертывания и операций. Обратите особое внимание на управление удостоверениями, доступ к инфраструктуре, безопасность приложений и суверенитет данных и шифрование. |
Чтобы приступить к работе, корпорация Майкрософт предоставляет набор онлайн-оценок , которые помогут вам оценить текущие облачные рабочие нагрузки по пяти хорошо архитекторам.
Микрослужбы
Облачные системы принимают микрослужбы, популярный архитектурный стиль для создания современных приложений.
Построенный как распределенный набор небольших независимых служб, взаимодействующих через общую структуру, микрослужбы имеют следующие характеристики:
Каждый реализует определенную бизнес-возможность в более крупном контексте домена.
Каждая из них разрабатывается автономно и может быть развернута независимо.
Каждая из них является автономной инкапсулирующей собственную технологию хранения данных, зависимости и платформу программирования.
Каждый выполняется в собственном процессе и взаимодействует с другими пользователями, используя стандартные протоколы связи, такие как HTTP/HTTPS, gRPC, WebSockets или AMQP.
Они составляют вместе, чтобы сформировать приложение.
Рис. 1–4 контрастирует монолитный подход приложения с подходом микрослужб. Обратите внимание, что монолит состоит из многоуровневой архитектуры, которая выполняется в одном процессе. Обычно она использует реляционную базу данных. Однако подход микрослужб разделяет функциональные возможности на независимые службы, каждая из которых имеет собственную логику, состояние и данные. Каждая микрослужба размещает собственное хранилище данных.
Рис. 1-4. Архитектура монолитных и микрослужб
Обратите внимание, как микрослужбы способствуют принципу процессов из двенадцатифакторного приложения, описанного ранее в главе.
Фактор 6 указывает: "Каждая микрослужба должна выполняться в собственном процессе, изолированная от других запущенных служб".
Зачем нужны микрослужбы
Микрослужбы обеспечивают гибкость.
Ранее в главе мы сравнили приложение электронной коммерции, созданное как монолитное, с микрослужбами. В примере мы увидели некоторые четкие преимущества:
Каждая микрослужба имеет автономный жизненный цикл и может развиваться независимо и часто развертывать. Вам не нужно ждать ежеквартального выпуска, чтобы развернуть новую функцию или обновление. Вы можете обновить небольшую область динамического приложения с меньшим риском нарушения всей системы. Обновление можно выполнить без полного повторного развертывания приложения.
Каждая микрослужба может масштабироваться независимо. Вместо масштабирования всего приложения в виде одной единицы вы масштабируете только те службы, которые требуют больше мощности обработки для удовлетворения требуемых уровней производительности и соглашений об уровне обслуживания. Точное масштабирование обеспечивает более широкий контроль над системой и помогает сократить общие затраты по мере масштабирования частей системы, а не всего.
Отличное справочное руководство по пониманию микрослужб — микрослужбы .NET: архитектура для контейнерных приложений .NET. Книга подробно описывает дизайн и архитектуру микрослужб. Это компаньон для эталонной архитектуры микрослужб полного стека, доступной как бесплатная загрузка от Майкрософт.
Разработка микрослужб
Микрослужбы можно создавать на любой современной платформе разработки.
Платформа Microsoft .NET является отличным выбором. Бесплатный и открытый код имеет множество встроенных функций, упрощающих разработку микрослужб. Платформа .NET кроссплатформенная. Приложения можно создавать и запускать в Windows, macOS и большинстве вариантов Linux.
.NET является высокопроизводительным и хорошо оценивается по сравнению с Node.js и другими конкурирующими платформами. Интересно, что TechEmpower провел широкий набор показателей производительности на многих платформах и платформах веб-приложений. .NET забил в топ-10 - значительно выше Node.js и других конкурирующих платформ.
.NET поддерживается корпорацией Майкрософт и сообществом .NET на GitHub.
Проблемы микрослужб
Хотя распределенные микрослужбы на основе облака могут обеспечить огромную гибкость и скорость, они представляют множество проблем:
Связь
Как интерфейсные клиентские приложения взаимодействуют с внутренними микрослужбами? Вы разрешаете прямую связь? Кроме того, можно абстрагировать внутренние микрослужбы с фасадом шлюза, обеспечивающим гибкость, контроль и безопасность?
Как серверные микрослужбы взаимодействуют друг с другом? Можно ли разрешить прямые HTTP-вызовы, которые могут увеличить связь и повлиять на производительность и гибкость? Или вы можете рассмотреть возможность отсоединения обмена сообщениями с технологиями очередей и разделов?
Обмен данными рассматривается в разделе "Шаблоны обмена данными на основе облака".
Устойчивость
Архитектура микрослужб перемещает систему из процесса в внепроцессное сетевое взаимодействие. В распределенной архитектуре происходит, когда служба B не отвечает на сетевой вызов из Service A? Или что происходит, когда служба C временно недоступна и другие службы, вызывающие ее, становятся заблокированными?
Устойчивость рассматривается в разделе о устойчивости на основе облака.
Распределенные данные
По проектированию каждая микрослужба инкапсулирует собственные данные, предоставляя операции через его общедоступный интерфейс. Если да, как запрашивать данные или реализовывать транзакцию в нескольких службах?
Распределенные данные рассматриваются в разделе "Шаблоны данных на основе облака".
Секреты
Как микрослужбы безопасно хранят секреты и конфиденциальные данные конфигурации?
Секреты подробно рассматриваются в облачной безопасности.
Управление сложностью с помощью Dapr
Dapr — это распределенная среда выполнения приложения с открытым кодом. Благодаря архитектуре подключаемых компонентов она значительно упрощает сантехнику распределенных приложений. Он предоставляет динамический клей, который привязывает приложение с предварительно созданными возможностями и компонентами инфраструктуры из среды выполнения Dapr. На рисунке 1-5 показан Dapr с 20 000 футов.
Рис. 1-5. Дапр в 20 000 футов.
В верхней строке рисунка обратите внимание, что Dapr предоставляет пакеты SDK для конкретных языков для популярных платформ разработки. Dapr версии 1 включает поддержку .NET, Go, Node.js, Python, PHP, Java и JavaScript.
Хотя пакеты SDK, относящиеся к языку, расширяют возможности разработчика, Dapr — это не зависящая от платформы. Под капотом модель программирования Dapr предоставляет возможности через стандартные протоколы связи HTTP/gRPC. Любая платформа программирования может вызывать Dapr через собственные API HTTP и gRPC.
Синие прямоугольники по центру фигуры представляют стандартные блоки Dapr. Каждый предоставляет предварительно созданный код сантехники для возможности распределенного приложения, которую может использовать ваше приложение.
Строка компонентов представляет большой набор предварительно определенных компонентов инфраструктуры, которые может использовать ваше приложение. Думайте о компонентах как код инфраструктуры, которые вам не нужно писать.
В нижней строке выделена переносимость Dapr и разнообразные среды, в которых она может выполняться.
Заглядывая вперед, Dapr имеет потенциал, чтобы иметь глубокое влияние на разработку облачных приложений.
Контейнеры
Естественно услышать термин контейнера, упоминание в любой облачной беседе. В книге Cloud Native Patterns автор Корнелия Дэвис отмечает, что "Контейнеры являются большими поддержку облачного программного обеспечения". Cloud Native Computing Foundation помещает контейнеризацию микрослужб в качестве первого шага в схеме cloud-Native Trail — руководство для предприятий, начинающие свое облачное путешествие.
Контейнеризация микрослужбы является простой и простой. Код, его зависимости и среда выполнения упаковываются в двоичный файл, называемый образом контейнера. Образы хранятся в реестре контейнеров, который выступает в качестве репозитория или библиотеки для образов. Реестр может находиться на компьютере разработки, в центре обработки данных или в общедоступном облаке. Docker сам поддерживает общедоступный реестр через Docker Hub. Облако Azure предоставляет частный реестр контейнеров для хранения образов контейнеров, близких к облачным приложениям, которые будут запускать их.
При запуске или масштабировании приложения образ контейнера преобразуется в запущенный экземпляр контейнера. Экземпляр выполняется на любом компьютере с установленным подсистемой среды выполнения контейнеров. Вы можете иметь столько экземпляров контейнерной службы, сколько необходимо.
На рисунке 1–6 показаны три различных микрослужбы, каждая из которых содержит собственный контейнер, все запущенные на одном узле.
Рис. 1-6. Несколько контейнеров на одном узле
Обратите внимание, что каждый контейнер поддерживает собственный набор зависимостей и среды выполнения, которые могут отличаться друг от друга. Здесь мы видим разные версии микрослужбы Product, запущенные на одном узле. Каждый контейнер использует срез базовой операционной системы узла, памяти и процессора, но изолирован друг от друга.
Обратите внимание, насколько хорошо модель контейнера принимает принцип зависимостей из приложения Двенадцатифакторов.
Фактор 2 указывает, что "Каждая микрослужба изолирует и упаковывает свои собственные зависимости, охватывая изменения, не влияя на всю систему".
Контейнеры поддерживают рабочие нагрузки Linux и Windows. Облако Azure открыто принимает оба. Интересно, что это Linux, а не Windows Server, который стал более популярной операционной системой в Azure.
Хотя существует несколько поставщиков контейнеров, Docker захватил львиную долю рынка. Компания управляет перемещением контейнеров программного обеспечения. Он стал де-факто стандартом упаковки, развертывания и запуска облачных приложений.
Зачем нужны контейнеры?
Контейнеры обеспечивают переносимость и гарантируют согласованность в разных средах. Инкапсулируя все в один пакет, вы изолируете микрослужбу и ее зависимости от базовой инфраструктуры.
Контейнер можно развернуть в любой среде, где размещается подсистема среды выполнения Docker. Контейнерные рабочие нагрузки также устраняют расходы на предварительную настройку каждой среды с платформами, библиотеками программного обеспечения и подсистемами выполнения.
Предоставляя общий доступ к базовой операционной системе и ресурсам узла, контейнер имеет гораздо меньше места, чем полная виртуальная машина. Меньший размер увеличивает плотность микрослужб или количество микрослужб, которые может выполняться в один раз заданный узел.
Оркестрация контейнеров
Хотя такие средства, как Docker, создают образы и запускают контейнеры, вам также нужны инструменты для управления ими. Управление контейнерами выполняется с помощью специальной программы программного обеспечения, называемой оркестратором контейнеров. При работе в масштабе с большим количеством независимых запущенных контейнеров оркестрация необходима.
На рисунке 1–7 показаны задачи управления, которые оркестраторы контейнеров автоматизируют.
Рис. 1-7. Что делают оркестраторы контейнеров
В следующей таблице описаны распространенные задачи оркестрации.
| Задачи | Описание |
|---|---|
| Составление расписания | Автоматическая подготовка экземпляров контейнеров. |
| Affinity/anti-affinity | Подготовьте контейнеры рядом или далеко друг от друга, помогая в доступности и производительности. |
| Мониторинг работоспособности | Автоматическое обнаружение и исправление сбоев. |
| Отработка отказа | Автоматическое повторное создание экземпляра сбоем на работоспособном компьютере. |
| Масштабирование | Автоматическое добавление или удаление экземпляра контейнера для удовлетворения спроса. |
| Сеть | Управление сетевой наложением для взаимодействия с контейнерами. |
| Обнаружение служб | Включите контейнеры для поиска друг друга. |
| Последовательные обновления | Координация добавочных обновлений с нулевым развертыванием простоя. Автоматически откат проблемных изменений. |
Обратите внимание, как оркестраторы контейнеров принимают принципы удаления и параллелизма из приложения Двенадцатифакторов.
Фактор #9 указывает, что "Экземпляры служб должны быть удалены, предпочитая быстрые запуски, чтобы повысить масштабируемость и корректное завершение работы, чтобы оставить систему в правильном состоянии". Контейнеры Docker вместе с оркестратором, по сути, удовлетворяют этому требованию".
Фактор #8 указывает, что службы масштабируются в большом количестве небольших идентичных процессов (копий), а не масштабируются один крупный экземпляр на самом мощном компьютере.
Хотя существует несколько оркестраторов контейнеров, Kubernetes стал де-факто стандартом для облачного мира. Это переносимая, расширяемая платформа с открытым кодом для управления контейнерными рабочими нагрузками.
Вы можете разместить собственный экземпляр Kubernetes, но затем вы будете отвечать за подготовку ресурсов и управление ими, что может быть сложным. Облако Azure предоставляет Kubernetes в качестве управляемой службы. Оба Служба Azure Kubernetes (AKS) и Azure Red Hat OpenShift (ARO) позволяют полностью использовать функции и возможности Kubernetes в качестве управляемой службы, не устанавливая и поддерживая ее.
Оркестрация контейнеров подробно рассматривается в масштабировании облачных приложений.
Резервные службы
Облачные системы зависят от множества различных вспомогательных ресурсов, таких как хранилища данных, брокеры сообщений, мониторинг и службы удостоверений. Эти службы называются резервными службами.
На рисунке 1–8 показаны многие распространенные службы поддержки, которые используют облачные системы.
Рис. 1-8. Общие службы резервного копирования
Вы можете разместить собственные службы резервного копирования, но затем вы будете отвечать за лицензирование, подготовку и управление этими ресурсами.
Поставщики облачных служб предлагают широкий спектр управляемых служб поддержки. Вместо того чтобы принадлежать службе, вы просто используете ее. Поставщик облачных служб управляет ресурсом в масштабе и несет ответственность за производительность, безопасность и обслуживание. Мониторинг, избыточность и доступность встроены в службу. Поставщики гарантируют производительность уровня обслуживания и полностью поддерживают управляемые службы. Откройте запрос и исправьте проблему.
Облачные системы предпочитают управляемые службы поддержки от поставщиков облачных служб. Экономия во времени и труде может быть значительной. Операционный риск размещения ваших собственных и испытывающих проблемы может получить дорогой быстрый.
Рекомендуется рассматривать резервную службу как подключенный ресурс, динамически привязанную к микрослужбе с информацией о конфигурации (URL-адресом и учетными данными), хранящимся во внешней конфигурации. Это руководство описано в приложении Двенадцатифакторов, рассмотренном ранее в главе.
Фактор 4 указывает, что службы резервного копирования должны предоставляться через адресируемый URL-адрес. Это различает ресурс от приложения, что позволяет ему быть взаимозаменяемым".
Фактор 3 указывает, что "Сведения о конфигурации перемещаются из микрослужбы и внешние через средство управления конфигурацией за пределами кода".
С помощью этого шаблона резервная служба может быть присоединена и отключена без изменений кода. Вы можете повысить уровень микрослужбы из QA в промежуточную среду. Вы обновляете конфигурацию микрослужб, чтобы указать на резервные службы в промежуточном режиме и внедрить параметры в контейнер с помощью переменной среды.
Поставщики облачных служб предоставляют API для взаимодействия со своими собственными службами поддержки. Эти библиотеки инкапсулируют собственные сантехники и сложности. Однако взаимодействие напрямую с этими API тесно связано с вашим кодом с этой конкретной службой резервного копирования. Это широко принятая практика изоляции сведений о реализации API поставщика. Введите уровень посредника или промежуточный API, предоставляя универсальные операции коду службы и упаковав код поставщика внутри него. Это свободное подключение позволяет переключить одну резервную службу на другую или переместить код в другую облачную среду без внесения изменений в код службы mainline. Dapr, рассмотренный ранее, следует этой модели с его набором предварительно созданных стандартных блоков.
На последней мысли, резервное обслуживание также способствует принципу без отслеживания состояния из двенадцатифакторного приложения, рассмотренного ранее в главе.
Фактор 6 указывает, что "Каждая микрослужба должна выполняться в собственном процессе, изолированном от других запущенных служб. Инициализация требуемого состояния в резервной службе, например распределенном кэше или хранилище данных".
Службы резервного копирования рассматриваются в шаблонах данных на основе облака и шаблонах обмена данными на основе облака.
Автоматизация
Как вы уже видели, облачные системы принимают микрослужбы, контейнеры и современную систему для достижения скорости и гибкости. Но, это только часть истории. Как подготовить облачные среды, в которых выполняются эти системы? Как быстро развернуть функции и обновления приложений? Как вы округляете полную картину?
Введите общепринятую практику инфраструктуры в виде кода или IaC.
С помощью IaC вы автоматизируете подготовку платформы и развертывание приложений. Вы, по сути, применяете такие методики проектирования программного обеспечения, как тестирование и управление версиями к вашим методикам DevOps. Инфраструктура и развертывания являются автоматизированными, согласованными и повторяемыми.
Автоматизация инфраструктуры
Такие инструменты, как Azure Resource Manager, Azure Bicep, Terraform из HashiCorp и Azure CLI, позволяют декларативно выполнять скрипт облачной инфраструктуры. Имена ресурсов, расположения, емкости и секреты параметризованы и динамически. Скрипт версии и проверка в управление версиями в качестве артефакта проекта. Вы вызываете скрипт для подготовки согласованной и повторяемой инфраструктуры в системных средах, таких как QA, промежуточное и рабочей среды.
Под капотом, IaC является идемпотентным, что означает, что вы можете запустить один и тот же сценарий над и более без побочных эффектов. Если команде нужно внести изменения, они редактируют и повторно запускают скрипт. Затронуты только обновленные ресурсы.
В статье " Что такое инфраструктура как код, автор Сэм Гукенхаймер описывает, как"Teams, реализующие IaC, могут быстро и масштабировать стабильные среды. Они избегают ручной настройки сред и обеспечивают согласованность путем представления требуемого состояния сред с помощью кода. Развертывания инфраструктуры с помощью модели IaC являются повторяемыми и предотвращают проблемы во время выполнения, вызванные смещением конфигурации или отсутствием зависимостей. Команды DevOps могут работать вместе с единым набором методик и инструментов для доставки приложений и их вспомогательной инфраструктуры быстро, надежно и в масштабе".
Автоматизация развертываний
Приложение Двенадцатифакторов, описанное ранее, вызывает отдельные шаги при преобразовании завершенного кода в работающее приложение.
Фактор #5 указывает, что "Каждый выпуск должен обеспечить строгое разделение между этапами сборки, выпуска и запуска. Каждый из них должен быть помечен уникальным идентификатором и поддерживать возможность отката".
Современные системы CI/CD помогают выполнить этот принцип. Они предоставляют отдельные этапы сборки и доставки, которые помогают обеспечить согласованный и качественный код, доступный пользователям.
На рисунке 1–9 показано разделение между процессом развертывания.
Рис. 1-9. Этапы развертывания в конвейере CI/CD
На предыдущем рисунке обратите особое внимание на разделение задач:
- Разработчик создает функцию в своей среде разработки, итерируя то, что называется "внутренним циклом" кода, запуска и отладки.
- По завершении этот код отправляется в репозиторий кода, например GitHub, Azure DevOps или BitBucket.
- При отправке запускается этап сборки, который преобразует код в двоичный артефакт. Работа реализуется с конвейером непрерывной интеграции (CI ). Он автоматически создает, тестирует и упаковает приложение.
- Этап выпуска выбирает двоичный артефакт, применяет сведения о конфигурации внешнего приложения и среды и создает неизменяемый выпуск. Выпуск развертывается в указанной среде. Работа реализуется с конвейером непрерывной доставки (CD ). Каждый выпуск должен быть идентифицирован. Вы можете сказать: "Это развертывание выполняется в выпуске 2.1.1 приложения".
- Наконец, выпущенный компонент запускается в целевой среде выполнения. Выпуски являются неизменяемыми, что любое изменение должно создать новый выпуск.
Применение этих методик, организации радикально изменились, как они передают программное обеспечение. Многие из них перешли с квартальных выпусков на обновления по запросу. Цель заключается в том, чтобы поймать проблемы в начале цикла разработки, когда они менее дороги для устранения. Чем дольше продолжительность интеграции, тем дороже проблемы становятся для решения. Благодаря согласованности в процессе интеграции команды могут чаще фиксировать изменения кода, что приводит к повышению качества совместной работы и программного обеспечения.
Инфраструктура как код и автоматизация развертывания, а также GitHub и Azure DevOps подробно рассматриваются в DevOps.
