Микросервисы. Руководство для начинающих

Вы наверняка слышали подобные высказывания: «Наши сервисы состоят из множества масштабируемых микросервисов», «Мы планируем перейти на архитектуру микросервисов». Но что такое микросервисы? Я постараюсь объяснить это на примерах из реального мира. 

Монолит —  машина по производству мороженого

Отвлечёмся на минуту от микросервисов и представим аппарат по производству мороженого. Он состоит из 4 отсеков: с мороженым, орехами, шоколадом и сиропом. В чашу можно добавить все ингредиенты, из которых только мороженое является обязательным, а остальные по желанию.

Монолитное приложение — большая машина мороженого

Открыв свой магазинчик мороженого, вы начнёте с одного небольшого аппарата, в который встроены все 4 компонента. По мере роста вашего бизнеса вы можете решить приобрести аппараты побольше, чтобы обслуживать больше клиентов за то же время. Такой подход приведёт к тому, что рано или поздно у вас будет самый большой аппарат из возможных. На этом развитие и закончится.

Предел масштабируемости — у вас уже самый большой аппарат

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

Увеличение количества монолитов

А что, если внедрить множество таких аппаратов и обойти ограничения? И так вы решаете вместо покупки одного большого аппарата, приобрести несколько маленьких.

Это называется клонированием. Вы используете множество экземпляров приложения, чтобы обслуживать запросы пользователей.

Теперь всё отлично, ваше мороженое становится всё более популярным. В конечном итоге, вам всё равно придётся обновить все свои аппараты для мороженого до самых мощных версий.

Клонирование — множество экземпляров монолита

Исправление ошибок

На первом этапе развития вы нанимаете одного специалиста, который решает все технические проблемы с аппаратом для мороженого. Пока всё идёт гладко. Но когда у вас появится множество аппаратов, вам понадобится больше специалистов, чтобы они успевали исправлять неполадки.

Однажды вы решаете, что было бы неплохо продавать ещё и шоколадное мороженое. Тогда вам необходимо добавить дополнительный отсек. Из-за того, что все части встроены в один аппарат и зависят друг от друга, вашим специалистам придётся постараться, чтобы внедрить новый компонент. Но после того, как работа сделана, оказывается, что аппарат перестал добавлять сироп. Такое может произойти из-за того, что компоненты взаимозависимы. Стукнешь здесь — треснет там.

Одно изменение ломает другие компоненты

Микросервис. Для каждой задачи — отдельный аппарат

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

Разделение на отдельные независимые части — микросервисы

Это и есть суть архитектуры микросервисов — одно большое монолитное приложение разделяется на независимые модули. Каждый модуль сам по себе является приложением и решает определённые задачи.

Монолит или Микросервис

• Масштабируемость: как вы уже поняли, самый большой аппарат из возможных является пределом масштабируемости. В случае с микросервисами вы всегда можете добавлять новые компоненты к уже существующей системе.
• Обслуживание: добавление новых компонентов в монолитную архитектуру может привести к поломкам из-за взаимозависимости компонентов. Например, если один модуль приложения требует изменения в схеме базы данных, то оно может привести к ошибкам в других частях приложения. В случае с микросервисами за каждую часть приложения отвечает отдельная команда, что позволяет избежать конфликтов из-за зависимой архитектуры. Независимая архитектура позволяет выпускать новые фичи быстрее, потому что коммуникация внутри команды происходит быстрее, чем между командами, как в больших организациях.
• Стоимость: может показаться, что вопрос масштабируемости решится покупкой нескольких больших аппаратов, но что, если вам нужно увеличить производительность только одного компонента. С монолитной архитектурой вам придётся каждый раз покупать новый аппарат. Благодаря микросервисам вы просто добавляете нужный компонент. Это сократит ваши затраты, поскольку вы сможете масштабировать экземпляры для каждой независимой службы в зависимости от ее нагрузки.
• Время на установку: в монолитной архитектуре все компоненты интегрированы, вам нужно просто, не нарушая этой структуры, начать использование. Из-за того, что микросервисы необходимо подключать в одну систему, вам потребуется больше времени.
• Тестирование и развёртывание: взаимозависимость компонентов монолитной архитектуры создаёт определённые трудности для тестирования и развёртывания системы. С микросервисами всё проще, потому что вы можете сосредоточиться на отдельных компонентах.

Стоит ли сразу начинать с микросервисов

Коротко говоря — нет. Многие эксперты утверждают, что если у вас нет необходимости в такой архитектуре, то лучше этого не делать. Продолжайте использовать монолитную архитектуру, пока не начнутся трудности с обслуживанием и масштабируемостью системы. Когда это произойдёт, разделите сервис на отдельные части.

Микро не всегда означает — маленький

Если вы думаете, что микросервис это некий маленький компонент, то вы ошибаетесь. Микросервис может быть большим сам по себе, или он может иметь несколько клонов, параллельно обслуживающих запросы пользователей. Например, в аппарате может быть 20 отсеков с мороженым, если большинство клиентов предпочитают мороженое без наполнителей.

Также микросервисом может быть отдельное приложение, далеко не маленькое и требующее больших усилий для обслуживания и масштабирования.

Заключение

Некоторые крупные софтверные компании, которые используют архитектуру микросервисов, начинали с монолитных приложений. Столкнувшись с ограничениями, они разделили монолит на отдельные независимые компоненты.

Несомненно, архитектура микросервисов позволяет использовать разные технологии для разных сервисов, а также даёт больше возможностей масштабирования и обслуживания приложений. С другой стороны, это требует привлечения опытных специалистов. Поэтому лучше начать с хорошо структурированной монолитной архитектуры, а затем перейти на микросервисы.

---

Перевод статьи