Что такое микросервисы

Разбиваем программу на сотни частей.

Все наши проекты в Коде устроены просто:

• вся разработка ведётся одними и теми же программистами;
• каждый понимает, что делает любая строчка кода;
• если что-то непонятно, это можно выяснить и разобраться за 5 минут в чате;
• а главное, каждый проект — это один большой скрипт или страница, которые полностью отвечают за всю логику работы.

Такой подход работает в маленьких командах. Но что будет, если проект будет намного сложнее? Давайте разбираться.

Проблемы монолитной разработки

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

• регистрация в сервисе,
• напоминание пароля,
• создание нового списка задач,
• управление списками,
• создание новой задачи,
• редактирование задачи,
• удаление задачи.

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

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

Ещё такие проекты сложно оптимизировать, если мы нашли более быструю реализацию какой-то функции. Если мы заменим функцию редактирования задачи на более быструю, нам нужно будет перепроверить заново весь остальной код и убедиться, что ничего не сломалось. Это трудозатратно.

Микросервисы — разбиваем программу на автономные части

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

1. Каждая смысловая часть программы выносится в отдельный код, который делает что-то одно: получает данные от сервера, отправляет логин и пароль на проверку, даёт разрешение пользователю на вход и т. д.
2. Каждая такая программа может получать и отправлять данные в каком-то формате. Благодаря этому программы могут обмениваться данными и управлять друг другом.
3. Такие мини-программы и называются микросервисами.

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

👉 Главный принцип в таком подходе — сделать так, чтобы у каждого микросервиса было понятное описание, в каком формате он получает данные, в каком отправляет и куда именно отправляет.

Пример

Разобъём нашу программу из начала статьи на микросервисы:

Обратите внимание — у нас появились функциональные элементы, которых не было в исходной картинке: например отрисовка интерфейса, запрос данных от пользователя, отправка данных на сервер, запрос в БД.

Всё дело в том, что сама программа и была тем обвесом с дополнительными функциями, которая делала всю остальную работу. Как только мы убрали центральный «пульт управления», нам пришлось добавить несколько микросервисов, которые взяли на себя эту работу.

Плюсы и минусы микросервисов

Микросервисная архитектура решает главную задачу программистов на масштабных проектах: превращает сложную и объёмную программу в набор простых деталей, которые работают вместе. Ещё из плюсов:

• Каждый микросервис можно полностью заменить или переписать без потери качества для проекта, если у него будет тот же формат общения с другими микросервисами.
• Если нужно, можно запустить одновременно несколько одинаковых микросервисов на разных компьютерах, чтобы повысить устойчивость и скорость работы приложения.
• Если какой-то микросервис откажет, то чаще всего это не приводит к падению всего сервиса или программы. Ещё можно настроить автоматический перезапуск микросервиса после аварийного завершения.
• Неважно, на каком языке написан микросервис, если он делает то, что нужно, и умеет общаться с другими. Например, для высокопроизводительных частей можно использовать С++, а для остальных — Java или Kotlin.
• Можно постепенно наращивать возможности приложения, просто подключая новые микросервисы к системе.

Но и минусы у такого подхода тоже есть:

• В простых проектах микросервисы потребуют больше времени, сил и внимания.
• Нет единого стандарта общения между микросервисами. Каждая компания сама определяет формат сообщений и способ передачи данных.
• Если работа одних микросервисов зависит от времени отклика других, а те, в свою очередь, зависят от третьих, то время обработки всех этих запросов может стать проблемой.
• Чем больше микросервисов работает в программе, тем сложнее ими управлять, чтобы всё работало без сбоёв. Часто для этих целей используют специальный софт, например Kubernetes, но владение им требует отдельных навыков.

Пример: работа системы под нагрузкой

Допустим, у нас есть две версии одного и того же сервиса: один сделан единым кодом, второй — на микросервисах.

Пока нагрузка в рамках нормы, оба сервиса работают примерно одинаково:

Но если посетителей внезапно больше (например, отлично сработала рекламная кампания), то монолитный сервис может упасть под нагрузкой. Оказывается, базу данных не оптимизировали под такое количество запросов. А если у нас всё на микросервисах, то отдельная программа, которая за ними следит, увидит, что запросов стало слишком много, и запустит ещё несколько микросервисов с обработками запросов в базу данных:

Это что, теперь каждую программу нужно писать на микросервисах?

Нет, не обязательно. Микросервисы хороши только в сложных проектах или в сервисах с высокой нагрузкой.

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