5 способов эффективного развертывания микросервисов
3 ноября 2022 г.Микросервисы — это наиболее масштабируемый способ разработки программного обеспечения. Но это ничего не значит, если мы не выберем правильный способ развертывания микросервисов: процессы или контейнеры? Работать на моих серверах или использовать облако? Нужен ли мне Кубернет? Когда дело доходит до микросервисной архитектуры, вариантов так много, что трудно определить, какой из них лучше.
Как мы увидим, идеальное место для размещения микросервисного приложения во многом определяется его размером и требованиями к масштабированию. Итак, давайте рассмотрим 5 основных способов развертывания микросервисов.
5 способов развертывания микросервисов
Микросервисные приложения могут работать разными способами, каждый из которых имеет свои компромиссы и структуру затрат. То, что подходит для небольших приложений, охватывающих несколько служб, вряд ли подойдет для крупномасштабных систем.
Вот пять способов запуска микросервисов, от простого к сложному:
- Один компьютер, несколько процессов: купите или арендуйте сервер и запускайте микросервисы как процессы.
2. Несколько компьютеров, несколько процессов: очевидным следующим шагом является добавление дополнительных серверов и распределение нагрузки, обеспечивающее большую масштабируемость и доступность.
3. Контейнеры: упаковка микросервисов внутри контейнера упрощает развертывание и запуск вместе с другими сервисами. Это также первый шаг к Kubernetes.
4. Оркестратор: такие оркестраторы, как Kubernetes или Nomad, представляют собой законченные платформы, предназначенные для одновременного запуска тысяч контейнеров.
5. Без сервера: без сервера мы можем забыть о процессах, контейнерах и серверах и запускать код непосредственно в облаке.
Впереди два пути: первый — от процессов к контейнерам и, наконец, к Kubernetes. Другой идет по бессерверному маршруту.
Давайте рассмотрим каждый из них более подробно.
Вариант 1. Один компьютер, несколько процессов
На самом базовом уровне мы можем запускать приложение микрослужбы как несколько процессов на одном компьютере. Каждая служба прослушивает отдельный порт и обменивается данными через петлевой интерфейс.
В самой простой форме развертывания микросервиса используется один компьютер. Приложение представляет собой группу процессов, связанных с балансировкой нагрузки.
У этого простого подхода есть несколько очевидных преимуществ:
- Легкий: нет накладных расходов, так как на сервере выполняются только процессы.
- Удобство: это отличный способ познакомиться с микросервисами без необходимости обучения, как в других инструментах.
- Простое устранение неполадок: все находится в одном месте, поэтому найти проблему или вернуться к рабочей конфигурации в случае возникновения проблемы очень просто, если у вас есть непрерывная доставка.
- Фиксированная оплата: мы знаем, сколько нам придется платить каждый месяц.
Самостоятельный подход лучше всего подходит для небольших приложений с несколькими микросервисами. Кроме того, это не соответствует действительности, потому что:
- Нет масштабируемости: как только вы максимально используете ресурсы сервера, все.
- Единая точка отказа: если сервер выходит из строя, приложение падает вместе с ним.
- Хрупкое развертывание: нам нужны настраиваемые сценарии развертывания и мониторинга, чтобы убедиться, что службы установлены и работают правильно.
- Нет ограничений на ресурсы: любой процесс микрослужбы может потреблять любое количество ресурсов ЦП или памяти, что может привести к голоданию других служб и оставлять приложение в деградированном состоянии.
Непрерывная интеграция (CI) для этого варианта будет следовать той же схеме: создать и протестировать артефакт в конвейере CI, а затем развернуть с помощью непрерывное развертывание.
Для развертывания исполняемых файлов, встроенных в конвейер непрерывной интеграции, требуются специальные сценарии.
Это лучший вариант для изучения основ микросервисов. Вы можете запустить небольшое микросервисное приложение для ознакомления. Один сервер поможет вам далеко, пока вам не понадобится расширение, после чего вы сможете перейти на следующий вариант.
Вариант 2. Несколько компьютеров и процессов
Этот вариант, по сути, представляет собой обновление варианта 1. Когда приложение превышает возможности сервера, мы можем масштабировать его (обновить сервер) или горизонтально (добавить больше серверов). В случае микросервисов горизонтальное масштабирование на две или более машин имеет больше смысла, поскольку в качестве бонуса мы получаем повышенную доступность. И если у нас есть распределенная установка, мы всегда можем масштабироваться, обновляя серверы.
Балансировщик нагрузки по-прежнему является единственной точкой отказа. Чтобы избежать этого, несколько балансировщиков могут работать параллельно.
Однако горизонтальное масштабирование не лишено проблем. Преодоление одной машины создает несколько критических моментов, которые значительно усложняют устранение неполадок, и возникают типичные проблемы, возникающие при использовании микросервисной архитектуры.
* Как мы соотносим файлы журналов, распределенные между многими серверами? * Как мы собираем разумные показатели? * Как мы справляемся с обновлениями и простоями? * Как мы справляемся с пиками и падениями трафика?
Все эти проблемы присущи распределенным вычислениям, и вы столкнетесь с ними (и с ними вам придется иметь дело), как только будет задействовано более одной машины.
Этот вариант отлично подходит, если у вас есть несколько свободных машин и вы хотите повысить доступность своего приложения. Пока вы придерживаетесь простых вещей, с более или менее однородными сервисами (один и тот же язык, похожие фреймворки), все будет в порядке. Как только вы преодолеете определенный порог сложности, вам потребуются контейнеры, чтобы обеспечить большую гибкость.
Вариант 3. Развертывание микросервисов с помощью контейнеров
Хотя запуск микросервисов напрямую в виде процессов очень эффективен, за это приходится платить.
- Сервер должен тщательно поддерживаться с помощью необходимых зависимостей и инструментов.
- Безудержный процесс может потреблять всю память или ЦП.
- Развертывание и мониторинг микросервисов — сложный процесс.
Все эти недостатки можно устранить с помощью контейнеров. Контейнеры — это пакеты, содержащие все, что нужно программе для запуска. Образ контейнера — это автономный модуль, который может работать на любом сервере без предварительной установки каких-либо зависимостей или инструментов (кроме самой среды выполнения контейнера).
Контейнеры обеспечивают достаточную виртуализацию для изолированного запуска программного обеспечения. С ними мы получаем следующие преимущества:
- Изоляция: содержащиеся процессы изолированы друг от друга и ОС. Каждый контейнер имеет частную файловую систему, поэтому конфликты зависимостей невозможны (если вы не злоупотребляете томами).
- Параллелизм: мы можем запускать несколько экземпляров одного и того же образа контейнера без конфликтов.
- Меньше накладных расходов: поскольку нет необходимости загружать всю ОС, контейнеры намного легче, чем виртуальные машины.
- Развертывание без установки: установка контейнера — это просто загрузка и запуск образа. Шаг установки не требуется.
- Контроль ресурсов: мы можем установить ограничения ЦП и памяти для контейнеров, чтобы они не дестабилизировали сервер.
Для контейнерных рабочих нагрузок требуется этап сборки образа в CI/CD.
Чтобы узнать больше о контейнерах, ознакомьтесь с этими сообщениями:
Мы можем запускать контейнеры двумя способами: непосредственно на серверах или через управляемую службу.
Контейнеры на серверах
Этот подход заменяет процессы контейнерами, поскольку они обеспечивают большую гибкость и контроль. Как и в варианте 2, мы можем распределить нагрузку на любое количество машин.
Помещение процессов микрослужб в контейнеры делает их более переносимыми и гибкими.
Бессерверные контейнеры
Все варианты, описанные до этого момента, основывались на серверах. Но компании-разработчики программного обеспечения не занимаются управлением серверами — серверами, которые нужно настраивать, исправлять и обновлять, — они занимаются решением проблем с кодом. Поэтому неудивительно, что многие компании предпочитают по возможности избегать использования серверов.
Предложения «контейнеры как услуга», такие как AWS Fargate и Heroku позволяет запускать приложения в контейнерах, не обращаясь к серверам. Нам нужно только создать образ контейнера и указать его облачному провайдеру, который позаботится обо всем остальном: подготовит виртуальные машины, а также загрузит, запустит и отслеживает образы. Эти управляемые службы обычно включают в себя встроенный балансировщик нагрузки, о котором нужно беспокоиться меньше.
Elastic Container Service (ECS) с Fargate позволяет нам запускать контейнеры без аренды серверов. Они поддерживаются облачным провайдером.
Вот некоторые из преимуществ службы управляемых контейнеров:
- Нет серверов: нет необходимости обслуживать или исправлять серверы.
- Простое развертывание: просто создайте образ контейнера и сообщите службе, чтобы он его использовал.
- Автомасштабирование: поставщик облачных услуг может предоставить больше ресурсов при пиковых нагрузках или остановить все контейнеры при отсутствии трафика.
Однако прежде чем приступить к работе, вы должны знать о нескольких существенных недостатках:
- Привязка к поставщику: это важная проблема. Отказ от управляемой службы всегда сопряжен с трудностями, поскольку поставщик облачных услуг предоставляет и контролирует большую часть инфраструктуры.
- Ограниченные ресурсы: управляемые службы налагают ограничения на ЦП и память, которых невозможно избежать.
- Меньший контроль: у нас нет такого уровня контроля, как при других вариантах. Вам не повезло, если вам нужны функции, которые не предоставляются управляемой службой.
Любой вариант контейнера подходит для небольших и средних микросервисных приложений. Если вы согласны с вашим поставщиком, сервис управляемого контейнера проще, так как он позаботится о многих деталях за вас.
Излишне говорить, что для крупномасштабных развертываний оба варианта не годятся. Как только вы достигнете определенного размера, у вас, скорее всего, будут члены команды, которые имеют опыт работы (или желание учиться) с такими инструментами, как Kubernetes, которые полностью меняют способ управления контейнерами.
Вариант 4. Оркестраторы
Оркестраторы — это платформы, специализирующиеся на распределении рабочих нагрузок контейнеров по группе серверов. Самым известным оркестратором является Kubernetes, созданный Google проект с открытым исходным кодом, поддерживаемый Cloud Native Computing Foundation.
Помимо управления контейнерами, оркестраторы предоставляют расширенные сетевые функции, такие как маршрутизация, безопасность, балансировка нагрузки и централизованные журналы — все, что вам может понадобиться для запуска микросервисного приложения.
![Микросервисы, работающие в Kubernetes.]
Kubernetes использует модули в качестве единицы планирования. Модуль — это группа из одного или нескольких контейнеров, имеющих общий сетевой адрес.
С Kubernetes мы отказываемся от пользовательских сценариев развертывания. Вместо этого мы кодируем желаемое состояние с помощью манифеста, а об остальном позаботится кластер.
Конвейер непрерывного развертывания отправляет манифест в кластер, который выполняет действия, необходимые для его выполнения.
Kubernetes поддерживается всеми поставщиками облачных услуг и является де-факто платформой для развертывания микросервисов. Таким образом, вы можете подумать, что это лучший способ запуска микросервисов. Для многих компаний это верно, но следует помнить и о нескольких вещах:
- Сложность: оркестраторы известны своей крутой кривой обучения. Нередко выстрелить себе в ногу, если не соблюдать осторожность. Для простых приложений оркестратор — это излишество.
- Административная нагрузка: поддержка установки Kubernetes требует значительных знаний. К счастью, каждый достойный поставщик облачных услуг предлагает управляемые кластеры, которые берут на себя всю административную работу.
- Набор навыков. Для разработки Kubernetes требуется специальный набор навыков. Чтобы понять все движущиеся части и узнать, как устранять неполадки при неудачном развертывании, могут потребоваться недели. Переход на Kubernetes может быть медленным и снижать производительность, пока команда не ознакомится с инструментами.
Kubernetes — самый популярный вариант для компаний, интенсивно использующих контейнеры. Если это вы, выбор оркестратора может быть единственным путем вперед. Однако, прежде чем сделать рывок, имейте в виду, что недавний опрос показал, что самая большая проблема для большинства компаний при переходе на Kubernetes AWS Lambda и Облачные функции Google обрабатывают все детали инфраструктуры, необходимые для масштабируемых и высокодоступных сервисов, что позволяет нам сосредоточиться на написании кода.
Бессерверные функции масштабируются автоматически и оплачиваются по факту использования.
Это совершенно другая парадигма с другими плюсами и минусами. С другой стороны, мы получаем:
- Простота использования: мы можем развертывать функции на лету, не компилируя и не создавая образы контейнеров, что отлично подходит для тестирования и создания прототипов.
- Легко масштабировать: вы получаете (по сути) бесконечную масштабируемость. Облако предоставит достаточно ресурсов для удовлетворения спроса.
- Плата за использование: вы платите в зависимости от использования. Если нет спроса, плата не взимается.
Тем не менее, недостатки могут быть значительными, что делает бессерверные решения непригодными для некоторых типов микросервисов:
- Привязка к поставщику: как и в случае с управляемыми контейнерами, вы покупаете в экосистеме поставщика. Миграция от поставщика может быть сложной задачей.
- Холодный запуск: запуск редко используемых функций может занять много времени. Это происходит из-за того, что поставщик облачных услуг сокращает ресурсы, связанные с неиспользуемыми функциями.
- Ограниченные ресурсы: у каждой функции есть ограничение по памяти и времени — они не могут быть длительными процессами.
- Ограниченное время выполнения: поддерживается только несколько языков и платформ. Возможно, вам придется использовать язык, который вам не нравится.
Непредвиденные счета: поскольку стоимость зависит от использования, трудно предсказать размер счета в конце месяца. Всплеск использования может привести к неприятному сюрпризу.
Бессерверное решение обеспечивает масштабируемость. По сравнению с Kubernetes, он не дает вам такого большого контроля, но с ним проще работать, так как вам не нужны специальные навыки для работы без сервера. Бессерверная технология — отличный вариант для небольших быстрорастущих компаний, если они могут смириться с ее недостатками и ограничениями.
Заключение
Наилучший способ запуска приложения микрослужбы определяется многими факторами. Один сервер, использующий контейнеры (или процессы), — отличная отправная точка для экспериментов или тестирования прототипов.
Если приложение является зрелым и охватывает множество сервисов, вам потребуется что-то более надежное, например управляемые контейнеры или бессерверные решения, и, возможно, Kubernetes позже, когда ваше приложение будет расти.
Ничто не мешает вам смешивать и сочетать разные варианты. Фактически, большинство компаний используют сочетание серверов без ПО, виртуальных машин, и Кубернеты. Комбинация таких решений, как запуск основных служб в Kubernetes, нескольких устаревших служб на виртуальной машине и резервирование без сервера для нескольких стратегических функций, может быть лучшим способом использовать преимущества облака на каждом шагу.
Спасибо за чтение!
Также опубликовано здесь
Оригинал