2. Микросервисы
«Невозможно описать термин „микросервис“, потому что не существует даже словарного запаса для этой области. Вместо этого мы опишем список типичных черт микросервисов, но сделаем это со следующей оговоркой – большинству микросервисных систем присущи лишь некоторые из приведенных черт, но не всегда, и даже для совпадающих черт будут значительные различия от канона.»
Как мы выяснили из первой главы, обзора концепции и технологий, «созданных для облака» (cloud native), практически неотъемлемой частью проектирования и разработки приложений для работы в облаке стали «микросервисы» (microservices), особенно бурно ворвавшиеся в тренд популярности на волне успеха стека технологий и способа разработки Netflix, Twitter, Uber, и до этого идей от Amazon.
Определить точно, что это за архитектура, и чем она формально отличается от очень известного до этого подхода SOA (service oriented architecture), то есть архитектуры ориентированной на сервисы, довольно сложно. Многие копья сломаны на конференциях и форумах, создано множество блогов, можно сделать определенные выводы. Прежде всего микросервисы отличаются от «монолитов» (monolith), приложений, созданных с помощью единой технологии или платформы, внутри которой находятся вся деловая логика системы, анализ данных, обслуживание и выдача данных пользовательским интерфейсам. Любое взаимодействие модулей, сервисов и компонентов внутри монолита как правило происходит в рамках одного или максимум несколько процессов.
Плюсы монолита очевидны – мгновенная скорость общения между сервисами и компонентами, зачастую в рамках одного процесса, общая база кода, меньше ограничений на взаимодействие между компонентами и модулями, менее общие, более точные и выделенные интерфейсы между ними.
Однако с развитием облачных вычислений, и особенно легких контейнеров, изолирующих любые технологии, возрастанием скорости обмена данных по сети, и общей надежности и встроенной устойчивости к отказам, предоставляемых основными провайдерами облака, стало особенно удобно разбивать приложение на множество более мелких приложений. Легко обмениваясь информацией (как правило, это текстовый формат HTTP/JSON, или двоичный формат gRPC), они предоставляют друг другу сфокусированные, маленькие услуги и сервисы, независимые от использованных для их реализации технологий.
Подобное разбиение идеально ложится на разделение бизнес-функций в общем приложении, а что еще лучше, великолепно разделяет обязанности большой команды инженеров на независимые, маленькие команды, способные к экспериментам, быстрым изменениям и использованию любых технологий.