Не только одними микросервисами жива архитектура. Микросервисы популярны, потому что их нагородили столько, что требуются отдельные сервисы, чтобы управлять сервисами и надстройки уровнем выше, чтобы управлять сервисами, которые управляют сервисами.
И это моё субъективное, основанное на практике, мнение.
Я не даю каких-либо оценок, только констатирую имеющий место факт, что в высоконагруженных системах количество микросервисов исчисляется десятками или даже сотнями, и в 100 из 100 случаев семейство сервисов включает в себя неуникальных домочадцев. Иначе говоря, нередки кейсы, в которых одну и ту же задачу решает сразу несколько сервисов, что делает всю систему в целом чувствительной к изменениям и мало управляемой.
Думаю, будет интересно и полезно узнать, как мы докатились до микросервисных архитектур, и что дальше.
Для нас важно понимать, что ни одна из архитектур не была вытестена микросервисной. Более того, не исключено обнаружить в составе микросервисов монолит.
Чтобы понимать разницу, а главное, причины, по которым менялись подходы к конструкциям сервисов и систем, давайте разбираться.
Монолиты
Монолиты - по-прежнему актуальная архитектура, когда и Front и Back выкатываются и обновляются как единое приложение.
Это быстро и удобно для MVP, который совершенно точно нужно будет переписывать или для простой монолитной бизнес-логики, которая не меняется. В данном контексте нет особого смысла городить что-то сложное и подвижное.
Монолит - одна база, один процесс релиза, по отдельности Front & Back катить невозможно. Кроме того, монолитные системы грешат тем, что в них всё завязано на всём, слои исторического кода представляют собой нераспутываемый клубок зависимостей, который не прояснит даже самая четкая документация.
SPA + API
Совершенно нормально, что захотелось снять лютое ограничение монолита и развивать Front & Back параллельно. Думаю, это было основным двигателем для того чтобы разлепить клиентскую и базовую части, вкрутив на средний слой API.
SPA - Single Page Application. Это Web-приложение, которое подгружает одну страницу и меняет состав данных в зависимости от действий пользователя на странице. Отличительная особенность именно в том, что страницы не перезагружаются, обновляется интерфейс и данные. Подробнее о SPA - здесь.
Теперь, давайте представим, что продукт развивается, обрастает бизнес-логикой, фичами, и что происходит с API? Правильно, API превращается в химеру, постичь которую сможет не только лишь каждый. Плюс затраты на поддержку и развитие и невынужденные ошибки.
Что приходит на ум, когда мы сталкиваемся с таким ограничением? Как-то отстроиться и поделить на атомарные сервисы в зависимости от смысловой (функциональной нагрузки) каждого.
SOA
Сервис-ориентированная архитектура или SOA. То есть функции у нас поставляются отдельными сервисами, и продукт утилизирует эти самые сервисы через шину.
ESB - Enterprise Service Bus или шина. Это программное обеспечение, задача которого обеспечивать интеграцию разнородных сервисов. Это решение, которое маршрутизирует, преобразовывает, контролирует, обеспечивает целостность и безопасность данных, а так же мониторит и пишет логи.
Очевидно, что на слое ESB мы имеем внушительное количество логики. Итого, если смотреть снизу вверх, то мы получаем: логика на уровне непосредственно сервиса, закрывающего функцию, логика на слое ESB, логика на слое продукта и совершенно не исключаю наличие (это, конечно, bad practice) логики на уровне фронта.
Все эти логики должны обеспечивать бесперебойную работу продукта.
Будем честными, маловероятно, что логика, размазанная по стольким слоям никогда не сбоит или не вступит в конфликт; себестоимость дебага какой-либо ошибки возрастает значительно, потому как нам необходимо будет ресерчить слой за слоем, и устранять без аффектов.
Или вот ещё одна по истине killer feature от SOA - Bus-factor для ESB. Упала шина - упало всё. Для сервисов с доступностью 24/7 это крайне чувствительная уязвимость.
Но есть и ещё одна (не последняя, но крайне болезненная штука) - это тот факт, что сервис, поставляющий определенную функцию, становится Bottleneck для запросов потребителей, которые отстроены от сервиса посредством шины. Каждый продукт генерирует свои задачи, Backlog растет, и "наш поезд в огне" перманентно.
Микросервисы (MSA)
Логичным шагом является максимальное сокращение точек отказа и повышение управляемости. Таким образом мы приходим к, собственно, сервисам, в которых зашито большинство бизнес логики и набору каналов, задача которых предоставлять доступ к сервису, то есть "не думать".
Важная штука, что в MSA нет необходимости преследовать максимальное переиспользование функции, и в целом, если так можно сказать, то микросервис - это не столько поставщик некой функции для экосистемы, но независимое (в известных пределах) приложение.
Харкатеристики микросервиса:
- Небольшой. Значит, что может быть поддержан, и, в случае чего, переписан одной небольшой (5-7) командой в понятную итерацию. Смыслы сервиса должны умещаться в голове одного человека, неотягощенного несколькими высшими образованиями.
- Независимый. Падение соседа не вызывает каскадной реакции и крушения по типу карточного домика.
- Ограничен по контексту - решает что-то конкретное в конкретном окружении.
- Взаимодействует с другими микросервисами по сети, без доп логики на связующих слоях.
- Готов к падениям - обмазан мониторингами, умеет обрабатывать граничные случаи, восстанавливаться, ожидать, реагировать на нежданчики с минимальным аффектом на продукт. Иными словами, TechLead такого сервиса редко пишет Postmortem.
- Минимально централизован: свои базы, своя логика.
- Развивается итерационно. В идеале способен пережить любое изменение без остановки сервиса.
Микрофронтенды
Микрофронтенды - это когда и Front распилен на приложения. Например, мобильное приложение какого-нибудь ресторана, в котором имеем атомарные (технически - не для пользователя) приложения доставки и заказа. Всё это крутится в оболочке одного Application, однако работает и развивается независимо.
Comments are closed