История появления микросервисов
В статье От микросервисного монолита к оркестратору бизнес-сервисов (укороченный вариант в видео) я рассматривал механизм эволюции IT-архитектуры и причины, которые подталкивают к изменениям от одной стадии к другой. Я бы хотел дополнительно погрузить вас в историю того, как и почему мы пришли к микросервисам.
В прошлом веке, когда бизнес понял, что с помощью IT можно получить преимущество на рынке, в создание программ начали вкладывать много денег, и стало появляться множество небольших программ и утилит для работы. Их можно сравнить с разными инструментами, которые свалены в кучу, и вам нужен мастер, который соберёт из них конвейер для бизнеса. Инструменты были разношёрстные, а среда, в которой они работали, не была готова управлять сложностью, которая возникала, когда этих утилит становилось слишком много.
Неудобство управления этим «зоопарком» привело к тому, что появились огромные монолитные системы типа Enterprise resource planning (ERP). Их преимущество было в том, что они предложили работу по принципу «одного окна». Стали не нужны множество мелких инструментов, появился универсальный огромный колосс, который сделает всё, что нужно на вашем предприятии. Его можно бесконечно расширять функциями, которые должны быть устроены по его подобию, и которые делают его ещё больше, и благодаря которым он всё глубже пускает корни в вашу компанию.
Такой подход имеет ряд недостатков:
- Доставка бизнес-ценности происходит довольно медленно, потому что монолитная система должна быть целиком согласована, целиком протестирована, целиком выпущена в релиз. В таких системах релизный цикл может быть 6–12 месяцев, что для современных скоростей считается очень медленным.
- Монолитная система часто требует использовать её собственный стек технологий для создания расширений. Даже если существует технология разработки, которая лучше решает конкретную задачу бизнеса, разработчикам придётся использовать технологию монолита, чтобы встроить новый продукт в этот монолит. Такой выбор бывает вреден бизнесу, потому что у конкурентов может не оказаться такого ограничения и они убегут вперёд.
Эти две проблемы тормозили развитие компаний, потому что их невозможно обойти в рамках архитектуры монолита. Отвечая на эти проблемы, разработчики и IT-архитекторы снова начали возвращаться к идеям создания небольших сервисов, каждый из которых отлично решает свою маленькую бизнес-задачу. Они называются микросервисы.
Этот подход очень похож на то, с чего всё начиналось, когда было много независимых утилит. Разница в том, что сейчас более развиты технологии инфраструктуры, где разворачиваются микросервисы. Инфраструктура и подходы к её созданию готовы выдержать сложность управления сотнями таких сервисов. Кроме этого, сильно продвинулись вперёд принципы проектирования классов и сборок, принципы построения IT-архитектуры, модульного и интеграционного тестирования, логирования и мониторинга. Всё это дало ключ к управлению сложностью микросервисной архитектуры.
Почему микросервисы?
Довольно много внимание уделено микросервисам, потому что на данный момент это единственный подход, который создаёт возможность быстро изменять части системы и подстраивать её под постоянные изменения извне.
Микросервисы позволяют создать такой «рой», в котором каждая боевая единица отлично делает свою работу, умеет понимать общие задачи и работать на общую цель, при этом по своим задачами почти автономна. Если в такой «рой» кинуть палку или попытаться сбить его рукой, то структура немного изменится, потому что он (рой) увернётся от удара, но будет продолжать делать своё дело как единое целое; его целостность и работоспособность не нарушится из-за внешних случайностей.
В этом смысле тема микросервисов очень важна для создания антихрупного приложения (это один из инструментов, который обеспечивает антихрупкость в IT). Если же мы создали хрупкое приложение, то оно является уязвимым, оно боится влияющей на него переменчивости. А в современных условиях, когда бизнес часто работает в условиях высокой неопределённости и изменчивости среды, разумно закладывать антихрупкость в систему. В этом смысле создание «роя», который не боится перемен, выгоден для стабильного развития бизнеса.
Ускоренная поставка бизнес-ценности
Когда система состоит из множества независимых друг от друга микросервисов, их можно изменять и обновлять тоже независимо друг от друга. Когда при работе с монолитом все изменения сливались в одну систему, потом всё это тестировалось, потом выходило в релиз, то было ощущение, что многие изменения в системе просто запаздывают не по своей вине. То есть новые функции готовы, но ждут общего релиза.
С микросервисами этой проблемы нет. Если одни микросервис изменился, то только его одного можно зарелизить, не нужно ждать всех остальных.
Такой подход облегчает тестирование и ускоряет поставку релизов пользователям, потому что тестировать нужно только небольшие участки системы. В хороших командах релизы микросервисов поставлены на поток, они делаются автоматически по несколько раз в день. При этом пользователи непрерывно получают обновления, а бизнес успевает обгонять конкурентов.
Дешёвое масштабирование и эффективный расход ресурсов
Каждый микросервис выполняет свою небольшую бизнес-задачу. Если пользователи увеличили нагрузку на систему, то, скорее всего, они нагрузили не все сотни микросервисов, а только 5–6 штук, которые участвовали в обработке этой задачи. Микросервисная архитектура позволяет выделить эти 5–6 микросервисов, дать только им больше ресурсов, чтобы смаштабировать их горизонтально.
Здесь необходимо объяснить разницу между вертикальным и горизонтальным масштабированием. Вертикально масштабируется один мощный сервер, на котором развёрнута система. При таком подходе по мере наращивания железа падает КПД от этого наращивания. Например, если на сервере увеличить мощность в 2 раза, то это может дать прирост на 60–80%, а не в 2 раза. Кроме этого, у серверов и ПО есть предел по вертикальному масштабированию, в который может упереться, не достигнув нужной производительности.
Если у вас есть микросервисы, то вместо увеличения мощности одного сервера, вы можете создать десятки копий вашего приложения и разместить их на небольших серверах, или даже в виртуальных контейнерах, что даст прирост производительности на количество запущенных копий. Я сейчас не буду вдаваться в подробности того, как должны быть спроектированы приложения, которые способны горизонтально масштабироваться, потому что это довольно узкая тема и IT-архитекторы с ней хорошо знакомы. Нам сейчас важно, что микросервисная архитектура позволяет делать горизонтальное масштабирование, которое позволяет почти линейно и бесконечно увеличивать производительность системы.
В пример этого подхода хочу привести проект Мисс Россия. В блоге Microsoft вышла моя статья Как мы «Мисс Россию» на руках переносили. Там описан довольно примечательный для нас кейс. Дело в том, что конкурс «Мисс Россия» проходит две недели в году, в это время система испытывает перегрузки от посетителей и тех, кто голосует за участниц. В остальное время нагрузок нет, а большинство сервисов, которые отвечают за голосование и отсев накрутки голосов, просто выключены.
В этом проекте использование микросервисов дало большую экономию на ресурсах по сравнению с монолитным приложением, которое использовалось до этого:
- Наращивание мощности происходит в облаке в те моменты, когда приходит много пользователей. Для заказчика это значит, что он платит за «железо» только тогда, когда оно необходимо для бизнеса.
- Микросервисы работают независимо друг от друга, поэтому их можно включать и выключать при необходимости. Соответственно, те микросервисы, которые нужны для голосования, выключены и не забирают ресурсы весь год, кроме двух недель.
На этом примере хорошо видно, что бизнес может очень гибко организовывать свои расходы и отвечать на потребности пользователей благодаря микросервисам. С монолитом так изящно сделать бы не получилось.
Переход на микросервисы
Тема перехода на микросервисную архитектуру стала одной из самых горячих на конференциях по архитектуре ПО. Бизнес почувствовал, что такая архитектура даёт преимущество.
Заказчики и разработчики захотели раздробить монолитные приложения на множество маленьких сервисов, чтобы увеличить скорость доставки релизов до пользователей, разделить ответственность команд, уменьшить взаимозависимость бизнес-функций приложения и использовать горизонтальное масштабирование вместо вертикального.
Если вы решите, что для вашего бизнеса будет выгодно использовать микросервисы вместо монолита, то используйте вот эту шпаргалку, чтобы не потратить деньги и время впустую.
Оригинал статьи размещен на Хабре https://habr.com/ru/articles/772078/
Комментариев нет:
Отправить комментарий