.webp)
.webp)
За последние годы микросервисы прошли путь от обычного переоцененного модного словечка до вещи, которую вы, как специалист по программному обеспечению, обязаны знать.
Согласно опросу разработчиков, проведенному компанией O’Reilly в 2020 году:
- 61% компаний в течение последнего года использовали микросервисы
- 29% утверждают, что, как минимум, половина их систем построены с использованием микросервисов
- 74% утверждают, что их команды проводят этапы разработки/тестирования/развертывания для их приложений
Эти цифры со временем будут только расти, поскольку экосистема вокруг микросервисов вполне себе развивается и делает процесс освоения еще проще.
Это ни в коем случае не означает, что для того, чтобы устроиться на работу, вам не нужно быть специалистом в области микросервисов, но это, абсолютно точно, приятный бонус, по крайней мере, для тех, кто хочет понять основные принципы.
На самом деле микросервисы не так трудны для понимания, если свести их к основным понятиям. Самая большая проблема состоит в том, что большая часть ресурсов, доступных на данный момент, написаны для того, чтобы впечатлять читателей, а не для того, чтобы их обучать.
Еще одна проблема заключается в том, что не существует какого-то точного определения, что же такое микросервис. В результате чего существует огромное количество частично дублирующих друг друга определений и невнятных слов, а это приводит к тому, что люди, которые пытаются выяснить, что такое микросервисы, просто путаются.
В этой статье я постараюсь убрать всю шелуху и уделить больше внимания ключевым концепциям того, что же на самом деле такое микросервисы. Для того, чтобы упростить понимание абстрактных понятий и идей, я буду использовать различные реальные примеры и аналогии.
Что такое микросервисы: аналогия с открытием своего собственного бизнеса
Представим, что вы специалист по программному обеспечению, и вы решили начать заниматься фрилансом для того, чтобы подзаработать немного денег. Поначалу у вас есть несколько клиентов, и все идет гладко. Вы тратите довольно много времени на написание кода, и ваши клиенты довольны вашей работой.
Но спустя какое-то время, по мере роста бизнеса, вы начинаете сбавлять обороты. Вы тратите все больше времени, обслуживая клиентов, отвечая на электронные письма, внося какие-то незначительные изменения в заказы прошлых клиентов и т.д., и все это никак не продвигает ваше дело с точки зрения дохода.
Вы понимаете, что вы, как специалист по программному обеспечению, используете свое время не очень рационально, поэтому нанимаете специального сотрудника, который будет заниматься обслуживанием клиентов за вас.
По мере того, как ваш бизнес растет, вы нанимаете все больше сотрудников, обладающих специальными навыками. Вы нанимаете маркетолога для того, чтобы серьезно заняться привлечением новых клиентов. Вы нанимаете менеджера по проектам, дополнительных специалистов по программному обеспечению, и, в конце концов, создаете отдел кадров, который будет помогать вам работать со всеми этими сотрудниками.
Это все было необходимо для того, чтобы ваш бизнес смог выйти за пределы того, с чем вы могли справиться в одиночку, но здесь, разумеется, есть некоторые проблемы, связанные с развитием вашего бизнеса.
Иногда могут возникать недопонимания между командами и отделами, и клиенты огорчаются, когда некоторые детали остаются незамеченными. Кроме того, вам нужно выплачивать сотрудникам зарплату, может присутствовать внутреннее соперничество между командами и возникать множество других проблем по мере того, как будет развиваться ваша компания.
Этот пример в какой-то степени показывает то, как компания, занимающаяся разработкой программного обеспечения, может перейти от монолитной архитектуры к архитектуре на основе микросдужб. Изначально всю работу выполняет один человек, потом постепенно появляются специализированные команды, которые работают вместе, достигая общей цели компании.
Это очень напоминает то, как технологические компании, использующие монолитные архитектуру, перешли на архитектуру на основе микрослужб. И несмотря на тот факт, что эти примеры, возможно, не очень подходят для описания микрослужб, общие проблемы одни и те же:
- Масштабирование. Лучше всего, если вы будете оперативно набирать штат и линейно увеличивать производительность вашей компании.
- Коммуникация. Нанимая все больше и больше сотрудников, вы увеличиваете затраты на координацию работы и коммуникацию в рамках всей организации. Существует большое количество стратегий, которые компании пытаются использовать для того, чтобы сделать процесс коммуникации эффективным, тем более сейчас, в эпоху удаленной работы.
- Адаптация. Стоит дать возможность определенным группам в организации проявлять самостоятельность для того, чтобы они могли решать проблемы эффективным способом, а не навязывать стандартные протоколы, независимо от ситуации. У каждого клиента свои потребности, поэтому вполне логично предоставить командам некоторую гибкость в том, как они справляются с некоторыми вещами.
Как перейти от монолитной архитектуры к архитектуре на основе микросервисов
Для того, чтобы понять, как все устроено сейчас, нужно понять, как все было устроено раньше. На протяжении довольно долгого времени программное обеспечение проектировалось в монолитном стиле, и все работало в связке как единое приложение. Как и у всего в этой жизни, у такого подхода к проектированию приложений есть свои плюсы и минусы.
Монолитные архитектуры не так уж и плохи по своей сути, и многие сторонники микросервисов даже рекомендуют начинать именно с монолита и придерживаться его до тех пор, пока вы не столкнетесь с проблемами. После чего, по понятным причинам, вы можете постепенно разбить свой монолит на микросервисы.
Преимущества монолитной архитектуры
Более быстрый процесс разработки на первоначальных этапах
Когда вы только начинаете, скорость работы небольшой команды разработчиков может быть довольно большой.
Это связано с тем, что проект небольшой, все понимают, как устроено приложение, и все идет гладко. Члены команды точно знаю, как все работает, и могут оперативно внедрять новые функции.
Простое развертывание
Монолиты работают как единое целое, что довольно серьезно упрощает такие вещи, как тестирование и ведение журналов. Кроме того, гораздо проще создать и развернуть единый монолит, а не кучу отдельных микросервисов.
Недостатки монолитной архитектуры
Несмотря на то, что на ранних этапах монолиты имеют преимущества, по мере роста компании они чаще всего сталкиваются с рядом проблем на организационном и техническом уровнях, которые связанны именно с их монолитной природой.
Сильная связанность модулей
Многие компании, которые используют монолитные приложения, пытаются разделить монолит с логической точки зрения, то есть разбить на функциональные модули согласно сценариям их использования, для того, чтобы все было организовано. Взять к примеру такие вещи, как аутентификация, комментарии, пользователи и публикации в блоге.
Проблема состоит в том, что для того, чтобы поддерживать все это в течение долгого времени, необходима крутая дисциплина в том, что касается техники. Как правило, когда сроки начинают поджимать, все установленные правила начинают игнорироваться. В результате, в критических ситуациях прибегают к легким путям, которые порождают запутанный взаимосвязанный код, и он постепенно накапливается в виде технического долга.
Реальный пример. Попытки сохранить «монолитную» дисциплину очень похожи на попытки придерживаться режима тренировок или диеты. Многие люди входят в азарт и могут придерживаться диеты в течение нескольких недель, но, рано или поздно, вмешивается быт, и вы возвращаетесь к обычному образу жизни.
Попытка реализовать слабую связанность с помощью монолитов похожа на эту ситуацию – когда вы оказываетесь в критической ситуации, появляется слишком много соблазнов пойти в обход правил.
Усложняется процесс адаптации новых сотрудников
Что касается новых сотрудников, для того, чтобы они могли стать полезными для компании, им, как правило, нужно немало времени на то, чтобы изучить, как все взаимосвязанные части монолита работают в связке. Только после этого они могут осмелиться внести какие-либо изменения в отдельные части приложения.
Мы наслышаны, что новым сотрудникам требуются месяцы на то, чтобы почувствовать себя комфортно, работая с огромной кодовой базой. И все равно у них присутствует подсознательный страх того, что, добавив какой-то новый код, они могут разрушить все приложение.
Сравнение с точки зрения реальной жизни. Научить кого-то выполнять одну задачу, например, забивать гвозди, и научить кого-то выполнять все без исключения возможные задачи на строительной площадке.
Необходимость обучения нового сотрудника абсолютно всему, что относится к его работе, увеличивает стоимость найма новых сотрудников.
Противоречивые требования к ресурсам
В рамках монолитной архитектуры у разных модулей могут быть разные требования к оборудованию. Для некоторых задач важна высокая вычислительная мощность процессора, а для некоторых – большая оперативная память.
Но так как все приложение должно работать на одном сервере, вы не можете предоставить определенный тип оборудования для каждой задачи.
Реальный пример. Конкретные виды транспортных средств лучше подходят для каких-то определенных задач.
Если вы собираетесь в дорожное путешествие, то вам больше всего подойдет автомобиль, который бы максимально экономично расходовал топливо, чтобы вы могли сэкономить на этом деньги. Если вы переезжаете в новую квартиру, то вам больше всего подойдет вместительный автомобиль, чтобы вам не пришлось много раз ездить за вещами.
Одна ошибка может «сломать» все приложение
Приложение развертывается как одно целое, а это значит, что любая команда может случайно создать ошибку, которая «сломает» весь монолит.
Реальный пример. Для того, чтобы из-за одной утечки не затонул весь корабль, используют переборки для герметизации секций в случае затопления.
микросервисы работают по аналогии, то есть каждая служба развертывается независимо от других. Таким образом, вероятность того, что одна ошибка приведет к поломке всего приложения, снижается.
Ограничивает возможность экспериментировать
Когда вы создаете монолитное приложение, вы фактически связываете себя по рукам и ногам, используя экосистему языка программирования, на котором был написан монолит. Самый простой пример: необходимость выбора между низкоуровневыми и высокоуровневыми языками программирования.
В случае архитектуры на основе микросервисов, если вы сталкиваетесь с трудностями при масштабировании какой-либо службы, вы можете переписать ее на более высокопроизводительном языке, например, C++ или Go.
Что касается других служб, для которых производительность не так важна, вы можете ускорить процесс разработки путем использования языков более высокого уровня, например, Python или JavaScript.
Кроме того, монолитная архитектура может путать команду, не позволяя увидеть какое-то альтернативное решение проблемы. Когда у тебя есть только молоток, то все будет выглядеть как гвоздь.
Сравнение с точки зрения реальной жизни. Пицца - это, конечно, хорошо, но вы, навряд ли, захотите есть ее каждый день до конца своих дней.
К тому же, в определенных обстоятельствах процесс приготовления пиццы может быть просто обременительным. Гораздо проще приготовить что-нибудь другое. Иногда было бы здорово просто перекусить по-быстрому или съесть что-нибудь более полезное.
Процесс развертывания может стать не таким быстрым
Одно из преимуществ монолита, которое мы упомянули ранее, рано или поздно, может стать его недостатком. Тот факт, что все приложение развертывается разом, может стать проблемой для крупный монолитов, так как развертывание всей службы может занять довольно много времени. За счет этого скорость, с которой команды могут выполнять итерации и вносить изменения, может снижаться.
Каждый раз, когда они будут вносить даже какое-то незначительное изменение, для того, чтобы провести тестирование, они будут вынуждены ждать, чтобы выполнились сборка и развертывание приложения.
Реальный пример. У вас есть мечта – вы хотите приготовить самое лучшее в мире печенье. Быстрее всего вы можете этого добиться, пробуя печь как можно больше партий печенья, постепенно меняя и улучшая рецепт до тех пор, пока он не станет идеальным.
А теперь представьте, что у вас всего одна духовка. В таком случае скорость, с которой вы можете пробовать различные рецепты печенья, будет гораздо меньше, чем если бы у вас было 10 духовок.
Преимущества архитектуры на основе микросервисов
Итак, теперь, когда вы уже знаете все плюсы и минусы монолитной архитектуры, давайте посмотрим на архитектуру на основе микросервисов.
Увеличивает скорость разработки
Так как вы больше не занимаетесь развертыванием монолита, команды могут увеличить скорость своей работы, связанной с добавлением новых функций. Команды могут выпускать обновления независимо от других команд, и им не нужно переживать о согласовании своих действий с другими командами.
При условии, что внешний интерфейс, который другие микросервисы используют для того, чтобы взаимодействовать со службой команды, остается прежним, команда разработчиков (если они так захотят) могут полностью переписать систему на другом языке программирования.
У независимого развертывания есть еще одно преимущество, которое заключается в том, что процесс сборки занимает меньше времени, так как каждая сборка сама по себе меньше. Это значит, что время итерации также сокращается.
Реальный пример. Когда вы заказываете еду в ресторане, вас не волнует, поменялось ли что-то на кухне, до тех пор, пока еда там вкусная.
Возможно, они поменяли духовки или фритюрницы, но поскольку еда на вкус остается прежней, об этом можно не беспокоится. Единственное, что для вас, как для внешнего потребителя, имеет значение, – это конечный продукт.
Более быстрая адаптация новых сотрудников
Для того, чтобы приступить к работе и начать вносить свой вклад, новые сотрудники могут изучить одну систему. Постепенно они могут продолжать изучать больше обо всем приложении, но не обязательно это делать сразу.
Реальный пример. Конвейерная линия сборки произвела революцию в производстве, разбив процесс производства на части. Теперь каждый сотрудник не должен был знать, как производить продукт с нуля, им достаточно было изучить один единственный этап, над которым им нужно работать. Таким образом удалось сократить время, затрачиваемое на обучение новых сотрудников, и увеличить масштаб производства.
Отказоустойчивость
Несмотря на то, что микросервисы, как правило, полагаются друг на друга при выполнении задач, архитектура, которая была спроектирована надлежащим образом, будет иметь встроенную избыточность и будет устойчивой к отказам, дабы предотвратить отказ всей системы в случае, если какая-то из служб даст сбой.
Чаще всего здесь задействуется повторная отправка запросов с увеличивающимся периодом ожидания между запросами или резервным значением по умолчанию, которое возвращается в случае, если служба недоступна.
Реальный пример. Если «сломалась» лишь служба рекомендаций Netflix, то нет никакого смысла возвращать пользователю сообщение о полном отказе.
Вместо этого Netflix может просто вернуть список популярных фильмов по умолчанию и пытаться вызывать службу рекомендаций в фоновом режиме до тех пор, пока она не ответит и не вернет индивидуальные рекомендации для пользователя.
Гибкая масштабируемость
Каждая служба развертывается в индивидуальном порядке, а это значит, что вы можете копировать и масштабировать каждую службу отдельно. Если бы компания использовала монолитную архитектуру, то ей пришлось бы масштабировать все приложение целиком, несмотря на то, что больше трафика стал получать только один компонент.
Использование архитектуры на основе микросервисов позволяет компании масштабировать исключительно ту службу, которая должна обрабатывать больше трафика. Такой подход более эффективен и может сэкономить вам деньги, поскольку не дает вам тратить ресурсы впустую.
Реальный пример. Давайте рассмотрим что-то наподобие Киберпонедельника на Amazon. В этот день количество размещенных заказов будет больше, чем обычно, но большая часть людей, скорее всего, уже выбрали, что бы они хотели заказать и добавили это в свою корзину.
Получается, что служба заказов будет получать во много раз больше трафика, чем обычно, а вот интенсивность использования, например, службы поиска и прочих может быть практически в норме.
Это особенно актуально в том случае, когда служба является довольно ресурсоемкой и может использовать для этой задачи специальное оборудование.
Если служба требует большой мощности ЦП, но при этом ей нужно не так много оперативной памяти, компания может сэкономить свои деньги на использовании серверов общего назначения. Компании, которая использует чистейший монолит, ничего не остается, кроме как проводить масштабирование с помощью серверов из разряда «мастер на все руки».
Недостатки архитектуры на основе микросервисов
микросервисы далеки от идеала. Да, переход от монолитной архитектуры к архитектуре на основе микросервисов устраняет некоторые проблемы, но создает новые.
Общая сложность
Несмотря на то, что гораздо легче понять каждую службу в отдельности, всю систему саму по себе понять довольно сложно. Эта дополнительная сложность привела к тому, что появились такие инструменты, как Docker и Kubernetes, которые позволяют абстрагироваться от этого, насколько это возможно.
Цель таких инструментов состоит в том, чтобы разработчики программного обеспечения могли создавать функции, как обычно и не беспокоится ни о чем, в частности о том, как все это работает «за кадром».
Взаимодействие
Одна из самых больших проблем микросервисов – то, как они взаимодействуют друг с другом.
Один внешний запрос, полученный от пользователя, может потребовать совместной работы нескольких служб. Давайте в качестве примера возьмем размещение онлайн-заказа, и посмотрим, как это работает:
- Пользователь размещает заказ в приложении
- Балансировщик нагрузки направляет запрос доступным службам для обработки запроса
- Служба корзины передает список заказанных товаров
- Служба инвентаризации подтверждает, что товар есть в наличие на складе
- Служба доставки рассчитывает примерную стоимость и срок доставки
- Платежная служба подтверждает, что платеж покупателя прошел
- Служба рекомендаций использует заказанные товары для того, чтобы позже создать новые рекомендации для покупателя
- Служба отзывов планирует отправку электронного письма с просьбой оставить отзыв
Отказ одной службы на любом из этапов может привести к нарушению всего процесса заказа или к тому, что пользователь будет недоволен.
Управление взаимодействием этих служб и решение вопросов, связанных с частичными сбоями, - это и есть огромная проблема архитектур на основе микросервисов.
Обработка данных
Одна их самых сложных задач для микросервисов – обработка запросов, которые затрагивают несколько служб и нуждаются в обновлении данных.
Что будет если запрос не выполниться по ходу того, как выполняются действия, причем в одной службе данные будут обновлены, а в остальных – нет? Вы не сможете выставить пользователю счет, но, в таком случае, он не получит то, за что он заплатил, поскольку служба не работает.
В рамках монолитной архитектуры вы можете прибежать к помощи ACID-транзакций для того, чтобы иметь возможность откатить изменения в базе данных, если вдруг что-то пойдет не так. С микросервисами такое провернуть гораздо сложнее; с ними связано то, что называется распределенными транзакциями между службами.
Среда разработки
Большая часть инструментов были разработаны с учетом монолитных архитектур, и с появлением архитектуры на основе микросервисов процесс разработки в целом становится сложнее.
Для того, чтобы проводить тестирование, необходимо моделировать взаимодействия с другими службами. Отладка еще сложнее, так как она выходит за пределы одного процесса, а ведение журналов должно выполняться в нескольких службах.
Даже, казалось бы, такая простая вещь как попытка отследить, почему блог медленно загружается, сложнее, чем вы думаете.
Предположим, что, проанализировав данные, вы заметили, что страницы вашего блога загружаются в течение 5 секунд. Используй вы монолит, отследить эту проблему было бы довольно легко, но в случае с архитектурой на основе микросервисов вам нужны специальные инструменты, которые будут отслеживать внешние запросы по мере того, как их обрабатывают различные службы.
Заключение
Хотелось бы надеяться, что эта статья помогла вам хорошо понять, что такое микросервисы и зачем они нужны, а также понять на интуитивном уровне, как они работают, даже если вы не понимаете всех технических моментов, происходящих «за кадром».
