Еще в начале карьеры разработчика я услышала и запомнила два забавных определения:
Если над сервисом работает команда, которую можно накормить всего 2 пиццами, то это микросервис
🍕🍕
Логика микросервиса должна полностью умещаться в голове разработчика.
Это сложно назвать определением, хотя про логику замечание валидное 😃
Со временем я сформулировала для себя такие свойства:
🔴сфокусированность на отдельной бизнес-задаче
🔴возможность реализации разных нефункциональных требований
Например, у микросервиса обработки изображений могут отличаться требования к ресурсам по сравнению с сервисом каталога товаров.
Давайте посмотрим, какие определения дают известные авторы:
➡️ Крис Ричардсон (автор книги "Паттерны микросервисов")
Микросервисы — это сервисы, которые:
independently deployable - можно поставлять независимо (без необходимости одновременно выкатывать другие сервисы)
loosely coupled - слабо связаны друг с другом
Обычно они организованы вокруг бизнес-возможностей, а отдельный сервис часто находится в зоне ответственности одной небольшой команды.
➡️ Сэм Ньюман (автор "От монолита к микросервисам", "Создание микросервисов")
Микросервисы — независимо релизящиеся сервисы, смоделированные вокруг бизнес-домена.
➡️ Влад Хононов (автор книги "Изучаем DDD")
У него есть интересная статья про баланс сложности в распределенных системах.
Локальная сложность — сложность внутри отдельного сервиса
Глобальная сложность — сложность связей и зависимостей между сервисами
Если всё поместить в один компонент, глобальная сложность почти исчезает, зато может вырасти локальная. Если нарезать систему слишком мелко, отдельные сервисы могут стать проще, но количество взаимодействий и зависимостей между ними резко вырастет.
Это то, о чем иногда рассказывают в докладах бигтехов: когда сделали слишком много микросервисов и связей между ними, так что систему стало трудно развивать.
Хононов предлагает необычный взгляд:
Микросервис — это сервис с маленьким публичным интерфейсом.
Условно, сервис может содержать 100 тысяч строк кода, но наружу выставлять буквально несколько высокоуровневых операций:
- createOrder()
- cancelOrder()
- getOrder()
Поэтому прямой доступ одного сервиса в БД другого сервиса — антипаттерн: база фактически становится огромным публичным интерфейсом.
➡️ Отличия от монолита
Одно из ключевых отличий микросервисной архитектуры от монолита — независимость развертывания, а не размер кодовой базы. Об этом пишут и Ричардсон, и Фаулер, и Ньюман.
Монолит может быть модульным и хорошо спроектированным, но он деплоится всегда целиком. А микросервисы деплоятся отдельно.
При этом если наши микросервисы сильно связаны друг с другом, и релиз выглядит так:
Order v5 требует Payment v7
Payment v7 требует Customer v4,
поэтому вынуждены выкатывать всё вместе
то Ньюман и Фаулер называют это распределенным монолитом.
Кто сталкивался, тот сразу вспомнит такие релизы 😂
Нашла еще несколько статей, и во всех можно проследить повторение нескольких вещей:
🔴независимость изменений и деплоя
🔴слабая связанность
🔴осмысленная бизнес-граница
В итоге, если спросят, что такое микросервис, я бы ответила как-то так:
"Микросервис реализует ограниченную часть бизнес-домена. В идеале он должен быть слабо связан с другими сервисами, развиваться и релизиться независимо от них.
В микросервисной архитектуре нужно следить не только за сложностью каждого отдельного сервиса, но и за сложностью связей между ними".
Забавно, что на собесах мне такой вопрос ни разу не задавали. А вас спрашивали, что такое микросервис?