Комментарии 109
для большого мира монолит это микросервис
Пара вопросов:
Если не секрет, какого максимального масштаба продукты вы разрабатывали, сколько разработчиков/команд в них было, сколько было бизнес-доменов (см. Domain Driven Design), сколько длился самый длинный проект?
Чем "форпост" отличается от микросервиса?
Думаю, вы все-таки спросили про проектирование, а не про разработку, поправьте, если я ошибаюсь. Тогда максимальной по объему и нагрузке была система для онлайн/оффлайн ритейлера федерального масштаба. Максимальное количество разработчиков - в районе 300, порядка 25 bounded context, говоря ubiquitous language-ом :) Этот проект ещё идет, так как пожелания ритейлеров неисчерпаемы. И модульный монолит прекрасно справляется.
Цитадель - это монолит, сумевший вовремя остановиться в процессе миграции на микросервисы :)
Думаю, вы все-таки спросили про проектирование, а не про разработку, поправьте, если я ошибаюсь. Тогда максимальной по объему и нагрузке была система для онлайн/оффлайн ритейлера федерального масштаба. Максимальное количество разработчиков - в районе 300, порядка 25 bounded context, говоря ubiquitous language-ом :) Этот проект ещё идет, так как пожелания ритейлеров неисчерпаемы. И модульный монолит прекрасно справляется.
надеюсь, не B2C? То-то я думаю, что все приложения Лента, Окей, Пятерочка так плохо работают )))))
Интересный и масштабный опыт, моё уважение! А сколько у вас проходит от постановки задачи до появления фичи в продакшене? Как вы скейлите по нагрузке свой модульный монолит? Запускаете десяток инстансов?
Из всего выходит так, что форпост = микросервис, да еще и с микрофронтендом. И очень странно, что админ туда у вас не ходит. А то что вы решили отстрелить микросервису ногу (асинхронность) - ну такой себе "плюс".
Поясню про асинхронность. У вас форпост стучиться в монолит с некоторой регулярностью и либо он должен туда стучаться, условно, очень часто, либо мы будем добавлять задержку в среднем в половину периода опроса.
Сейчас я уже активно не участвую в этом проекте, но тем не менее информацией поделиться могу. С момента постановки задачи до раскатки на сервера львиная доля времени уходит на все, что связано с разработкой и это время зависит много от чего. Думаю, вы не об этом хотели спросить. Насчёт масштабирования всё просто - хватило двух нижних осей, т.е. количества инстансов и количества шардов по географии.
Форпост не обязан иметь микрофронт. И следуя метафоре, которая кажется мне очень удачной, форпост нужен для сдерживания потока внешних врагов - врагов определенного вида. И ходить в цитадель он будет не часто, ввиду своей самодостаточности.
Тут я ожидал ответ вида "в среднем N недель".
Можно тогда пример форпоста? Потому что если он самодостаточен и ходит к соседям не часто, то он прям совсем хороший микросервис. А в целом, откуда это название "форпост", сами придумали или это какой-то более менее сложившийся шаблон и где-то можно прочитать, чтобы вас не мучать вопросами?
Если в среднем, то полторы-две недели.
Корни цитадели идут отсюда https://blog.appsignal.com/2020/04/08/the-citadel-architecture-at-appsignal.html
К сожалению, название этого паттерна активно применяют только в сообществах архитекторов, так что можно считать это первой попыткой вынести его наружу в русскоязычном сообществе.
Звучит волшебно, снимаю шляпу по поводу того, как у вас организован процесс, если 300 разработчиков не мешают друг другу с релизами, видимо, несколько раз в неделю.
Прочитал, спасибо. Кстати, в appsignal форпост постоянно стучится в цитадель, да еще и асинхронно через кафку. Так что вся эта история с цитаделью и форпостами - по сути про микросервисы, как бы не хотелось сделать вид, что это не они. И да, видимо вы тоже их применяете, надеюсь успешно :)
Здесь два момента. Первый - как я уже говорил, это из моего прошлого опыта. Второй - моей заслуги в этом мало, там была реально сильная команда тимлидов и проектных менеджеров и большое доверие от бизнеса. В общем, звезды сошлись так.
Применяем, но там, где они действительно нужны. Просто с какого-то времени это перестало быть опцией по умолчанию, продаваемой направо и налево. Ради этого пришлось сделать некоторые эмоциональные вбросы по тексту. Надеюсь, меня простят за это :)
Я не автор, но на второй вопрос ответ - практически ничем. По сути, такая архитектура мало отличается от принятой у "грандов" вроде SAP - когда ядро системы, оно же "монолит" - прячется за "стенами" из CAP (client access point) и кастомных модулей, имплементирующих большую часть специфики заказчика.
В недавнем проекте - мы шли похожим путем, введя мораторий на изменения монолита - кроме добавления событий в нужные точки и выделения клиенто-независимых API. Вся клиенто-зависимая логика ушла в сравнительно легковесные микросервисы-CAP, расширения - в микросервисы-обработчики событий. Все работало, пока сменившееся руководство не решило переписать и ядро на микросервисы, убрать события/асинхронность и т.п.
ща подтянутся адвокаты микросервисов ))
Сетевые вызовы
Тут ещё такой момент, что некоторые вещи, которые относительно вполне себе нормально делаются в монолите очень трудно или почти невозможно делать в микросервисах.
Например, сделать торговый сервер (биржу) обрабатывающий в одиночку поток в 10 Gbit FIX сообщений с латентностью в пределах, скажем, 20 микросекунд — задача непростая, но осуществимая. А сделать сервер с такой же логикой на микросервисах уже просто не выйдет, так как каждый сервис в цепочке обработки будет кратно увеличивать и трафик, и латентность.
Тут проблема не столько в микросервисах и сетевых задержках, как в выделении границ для разбиения на микросервисы.
Почему же? Проблема именно в появлении сетевого слоя там, где не нужно. У меня внутри монолита вполне могут быть высокоизолированные компоненты, которые асинхронно общаются между собой через высокопроизовдительную общую шину. Каждый компонент — самодостаточен. И всё прекрасно работает в монолите за счёт того, что передача сообщения между компонентами — в пределах десятков (ли хотя бы сотен) наносекунд. А если те же компоненты превратить в микросервисы (концептуально-то они хорошо соответствуют) — вы просто не пройдёте по техническим требованиям из-за сетевых издержек.
Максимум, что у вас есть — нотификация через вебхуки (аналог ивент баса по сути)
Давайте предположу: вы из протоколов коммуникации между системами используете только JSON/Rest, а поток данных обычно ограничен парой тысяч запросов в секунду?
Это не сетевой слой где не нужно, это граница неверно проложена
я тоже не понял вас. Если для обработки запроса нужно уложиться в 100 мс, а у вас обработка запроса проходит через 5 микросервисов, каждый из которых даёт latency пусть 30-60 мс, то как тут поможет установка границ? Лейтенси между микросервисами ненулевое же, так? И оно меньше чем лейтенси внутри одной ноды, так?
Или вы имеете в виду что переход на асинхронность решает эту проблему? Т.е. message bus или просто реактивные сервисы.
Если для обработки запроса нужно уложиться в 100 мс, а у вас обработка запроса проходит через 5 микросервисов
Скорее всего это означает, что там, где должен был быть один микросервис, у вас их 5 штук.
Скорее всего это означает, что там, где должен был быть один микросервис, у вас их 5 штук.
почему? Как вы это определили, не видя систему?
проходит через 5 микросервисов, каждый из которых даёт latency пусть 30-60 мсЭто Вы про сетевую задержку? Если да, то она решается переходом с сети на shared memory, и с json, на sbe. При этом задержка передачи данных становится ровно такой же как в монолите. Ну а время обработки не зависит монолит это или микросервис.
Откуда такие выводы?
Ну, вы почему-то сразу про "вебхуки", хотя я про веб ни слова не говорил.
Это не сетевой слой где не нужно, это граница неверно проложена
Эм. А как она должна быть проложена? Вот логические сервисы, вот в монолите они общуются напрямую, а в микросервисах будет какой-то RPC. При чём тут граница? Как поможет "перенос границы" в другое место, если проблема изначально с тем, что поток данных очень "толстых", а требования по latency - очень жёсткие?
Чтобы выделить микросервис недостаточно логической целесообразности. Нужна ещё реальная независимость сервисов. В частности, есть правило, что микросервисы должны делиться так, чтобы не пересекать transaction boundary.
В идеале никакой сервис не должен дергать другой сервис. Если у вас после проектирования получилось так, что пайплайн запроса состоит из пяти микросервисов, то это серьёзная ошибка, имхо.
(т.е практически любая имплементация микросервисной архитектуры - неправильная, потому что мало у кого есть вообще необходимость в микросервисах, но все с ними хотят работать даже ценой боли)
В частности, есть правило, что микросервисы должны делиться так, чтобы не пересекать transaction boundary.
В идеале никакой сервис не должен дергать другой сервис. Если у вас после проектирования получилось так, что пайплайн запроса состоит из пяти микросервисов, то это серьёзная ошибка, имхо.
занятная мысль)
но я видел немало таких длинных цепочек обработки запроса. И это не считая еще гейтвэя и может 1-2 доп. прокси. Понимаете, ваша мысль звучит вполне здраво, но те системы что я видел повсеместно нарушают это. Разве есть хоть какое-то доказательство (назовём это "закон длины цепочки для микросервисов") что любая распределенная система из микросервисов может быть спроектирована таким образом что длина цепочки обработки запроса не превышает заданного N ? Причем независимо от бизнес-логики и прочих факторов. Т.к. то что вы говорите, неявно опирается на веру в подобного рода закон.
Netflix делал всё что мог чтоб сократить задержки, например client service discavery. А взять хотя бы distributed tracing? Вряд ли он возник из необходимости трасировать цепочки из 2 запросов. А значит такая ситуация длинных цепочек возникает нередко. То что такие штуки возникли, говорит о том что ваша идея расходится с реальностью.
Понимаете, ваша мысль звучит вполне здраво, но те системы что я видел повсеместно нарушают это
Почему так происходит:
Микросервисы пишут люди средние по рынку, а не гении. И солюшены тоже средние по рынку, а не с какими-то дикими нефункциональными ограничениями. Если солюшен с цепочкой в 5 микросервисов работает и фирма не банкротится — все будет крутиться так и дальше. Если в монолите лапша, но он тоже работает — все будет крутиться так и дальше.
Опять же, есть много хайповодов, конечно, которые не соображают, что делают. Я, когда в первые познакомился с микросервисами в их исполнении - долго ненавидел концепцию. Голову на место мне вставила книжечка по DDD+микросервисам - показала, где именно есть место микросервисам
Изначально микросервисы идут из мира огроменных солюшенов. Даже если разработчики гении, то огроменный солюшен нельзя выдержать качественным со всех точек зрения. Он обязательно будет ошибочно спроектированным, даже если на его проектирование затратили тысячи человеколет.
Разве есть хоть какое-то доказательство (назовём это "закон длины цепочки для микросервисов") что любая распределенная система из микросервисов может быть спроектирована таким образом что длина цепочки обработки запроса не превышает заданного N ? Причем независимо от бизнес-логики и прочих факторов. Т.к. то что вы говорите, неявно опирается на веру в подобного рода закон.
Нет такого доказательства. И нет, на ничего подобного я не опираюсь. Если я говорю о том, что нельзя выделять микросервис просто так, то это не значит, что его всегда можно выделить.
Вот смотрите. Есть такое правило. Надо писать код без goto. Нарушается? Нарушается! Раньше — больше. Сейчас — куда меньше, но все равно goto есть и нужен. Разве правило дурацкое? Да ни в коем случае, замечательное правило.
Пишите код без goto, делите микросервисы с учетом transaction boundary.
Netflix делал всё что мог чтоб сократить задержки, например client service discavery. А взять хотя бы distributed tracing? Вряд ли он возник из необходимости трасировать цепочки из 2 запросов. А значит такая ситуация длинных цепочек возникает нередко. То что такие штуки возникли, говорит о том что ваша идея расходится с реальностью.
Вдумайтесь только, у netflix >1000 микросервисов! Это же очень-очень-очень прилично. Distributed tracing в такой системе является необходимостью, даже если большинство цепочек из всего 1-2 микросервисов. И более того, в системе таких размеров написание distributed tracing - это просто капля в море затрат. Тем более, продукт такого уровня обязан иметь хороший годный тулинг для дебага.
Просто представьте. Вот у вас в системе один клиентский запрос, увы, обрабатывается 2-мя микросервисами последовательно (т.е. один дергает другой). Вот что-то упало во втором микросервисе. Не имея матчинга хотя-бы уровня correlation-id вы просто задолбетесь понимать из логов, что именно стало причиной падения. Даже 3-го уровня не нужно, чтобы появилась нужда в нормальном тулинге.
Так что я не думаю, что моя идея расходится с реальностью.
---
И раз уж мы говорим о солюшене типа netflix, то давайте говорить честно. Нужно сравнивать монолит размера netflix и сравнивать солюшен из микросервисов тоже размера netflix.
Если netflix внезапно переедет из микросервисов в монолит, то они не смогут выдерживать ни темпы разработки, ни требования к downtime; да и скейлится им будет тяжелее. Им будет тяжелее мерджиться, им будет тяжелее гонять тесты, им будет тяжелее деплоиться. Да и архитектура после такой миграции вообще поедет нафиг. Сэкономили на сетевых затратах, но зато получили пачку других проблем.
Netflix является и типичным, и атипичным примером. Типичным — потому что именно для таких компаний как netflix микросервисы дают огроменную выгоду. Атипичным — потому что в большинстве систем будет 10-100 микросервисов, а не 1000.
Голову на место мне вставила книжечка по DDD+микросервисам - показала, где именно есть место микросервисам
А не подскажете, как называлась эта книжечка?
Голову на место мне вставила книжечка по DDD+микросервисам - показала, где именно есть место микросервисам
присоединяюсь к просьбе, что за книжечка?
Вот смотрите. Есть такое правило. Надо писать код без goto. Нарушается? Нарушается! Раньше — больше. Сейчас — куда меньше, но все равно goto есть и нужен. Разве правило дурацкое? Да ни в коем случае, замечательное правило.
Так что я не думаю, что моя идея расходится с реальностью.
Netflix является и типичным, и атипичным примером. Типичным — потому что именно для таких компаний как netflix микросервисы дают огроменную выгоду. Атипичным — потому что в большинстве систем будет 10-100 микросервисов
Изначально микросервисы идут из мира огроменных солюшенов. Даже если разработчики гении, то огроменный солюшен нельзя выдержать качественным со всех точек зрения. Он обязательно будет ошибочно спроектированным, даже если на его проектирование затратили тысячи человеколет.
(цитирую разные участки чтоб собрать в кучу цепочку мыслей)
идея понятна - надо стараться делать как лучше, несмотря на плохие примеры в отрасли. Т.е. вы считаете что обычно у компаний 10-100 микросервисов, и такие ситуации когда обрабатывают запрос 5 микросервисов по цепочке - скорее всего в 99% случаев результата плохого проектирования, верно?
просто вы сами отметили, что спроектировать правильно почти никому не удаётся, потому-то и интересно - не становятся ли бест-практики для микросервисов своего рода недостижимым идеалом. У вас не было в личной практике случаев перепроектирования и скажем упрощения архитектуры с урезанием числа микросервисов?
Это была книжечка Patterns, Principles, and Practices of Domain-Driven Design
В ней вам будут интересны следующие главы:
"Chapter 6 Maintaining the Integrity of Domain Models with Bounded Contexts"
"Chapter 7 Context Mapping"
"Chapter 8 Application architecture"
"Chapter 11 Introduction to Bounded Context Integration"
"Chapter 12 Integrating via Messaging"
"Chapter 13 Integrating via HTTP with RPC and REST"
---
Ща, дальше дисклеймер и поотвечаю на вопросы. У меня не то, чтобы прям так много опыта с микросервисами. Есть кое-какая рабочая практика с хорошими и плохими примерами. Но я далеко не знаток.
идея понятна - надо стараться делать как лучше, несмотря на плохие примеры в отрасли
Тут в общем какая хрень мною была обнаружена. Если внезапно микросервисы сделаны так, что ты начинаешь их ненавидеть, то это потому что тот, кто их делал - неопытен в этом деле или даже в программировании вообще.
Это довольно частая беда для разработки ПО. Практически с каждой технологией так. Просто микросервисная архитектура больше остального требует квалификации от архитектора (или команды, если архитектора нет).
Т.е. вы считаете что обычно у компаний 10-100 микросервисов
Да. Можно считать, что микросервис - это какая-то отдельная фича. Возьмите свой проект и посчитайте, сколько там фич.
Если так трудно, то можно от обратного. Возьмите пару средних фич. Посчитайте, сколько они занимает таблиц в бд (например, три или пять таблиц на одну фичу). И поделите общее количество таблиц на количество таблиц для фичи.
и такие ситуации когда обрабатывают запрос 5 микросервисов по цепочке - скорее всего в 99% случаев результата плохого проектирования
Да, у меня такие мысли.
Такое решение (5 в цепочке) не имеет много пользы от микросервисов (а именно: независимые беклоги, устойчивость остальной системы при временном выпадении одного микросервиса etc).
Зато имеет от микросервисов кучу проблем (а именно: проблемы с транзакционностью, необходимость синкать данные, сетевые задержки, тяжелый дебаг, размазанность кода etc).
И в принципе, если у вас 5 микросервисов в цепочке, то получается, что вы поделили систему по "слоям", а не по "фичам"; да еще и с чертовски сильной связностью.
просто вы сами отметили, что спроектировать правильно почти никому не удаётся, потому-то и интересно - не становятся ли бест-практики для микросервисов своего рода недостижимым идеалом
Насколько я понял, бест-практики являются недостижимым идеалом, потому что никто о них не знает.
У вас не было в личной практике случаев перепроектирования и скажем упрощения архитектуры с урезанием числа микросервисов?
Немного было. В основном из-за очень дебильных ошибок. Было например такое, что команда почему-то решила одну сущность раскладывать в два микросервиса. Причем взаимозависимость была максимальная, все данные тупо редактировались вместе и не могли быть разъединены. Причин для этого серьезных не было, а проблем было очень много.
В целом — скорее согласен с комментарием, но есть встречные комментарии.
В частности, есть правило, что микросервисы должны делиться так, чтобы не пересекать transaction boundary.
Это стараются обходить сагами и прочими ухищрениями, то есть правило не железобетонное. Но хорошее, да — всё-таки саги — это дополнительная сложность, дополнительная сложность заставляет меня грустить (поэтому обхожусь пока без саг).
В идеале никакой сервис не должен дергать другой сервис.
Ну, это слишком уж строгое ограничение. А лучший код — тот, который не написан? И то и другое звучит красиво, но работает редко.
Скажем так, если один микросервис изредка вызывает другой — не вижу проблемы. А вот если один микросервис постоянно вызывает другой — тут уже возникают вопросы, правильно ли выбрали границы.
Если у вас после проектирования получилось так, что пайплайн запроса состоит из пяти микросервисов, то это серьёзная ошибка, имхо.
Здесь согласен. Разве что, в качестве исключения могут быть инфраструктурные вызовы (положить в интеграционную шину, просигналить о необходимости отправки оповещения и т.п.). Но у всех по-разному это происходит — где-то для инфраструктуры библиотеки подключены, где-то — отдельные микросервисы.
И всё прекрасно работает в монолите за счёт того, что передача сообщения между компонентами — в пределах десятков (ли хотя бы сотен) наносекунд.
Это нужно ещё постараться, чтобы внутри процесса, через шину, данные прошли за сотни наносекунд. Я бы ждал микросекунды. Ваш аргумент понятен, но что делать бирже, если регулятор требует high availability? Все известные мне биржи только от этого уже становятся распределенными, нужно хотя бы дождаться ответа от реплики.
Насколько мне известно, 20 мкс бирже не особо нужно, скорее это маркет мейкер, который за это время должен пару десятков байт в запросе поменять и отправить его назад.
Да собственно даже тот-же Сэм Ньюмен говорит, что монолит должен быть вариантом по-умолчанию и делать микросерсисы, или переделывать монолит на них стоит только имея веские причины для этого, не знаю, упоминал он это в книге, или нет.
Кстати, на картинке со стрелочками от каждой буквы к следующей буковке не микросервисы, а распределенный монолит. :) Суть микросервисов в т.ч. и в независимости, если они сильно зависят друг от друга - что-то спроектированно не так.
И еще, с чем я не согласен, так это с тем, что монолит просто разрабатывать. Поначалу да, очень просто, красивая, логичная архитекрура и тд. Но когда он становится огромным, проблемы начинают лезть все сильнее и сильнее. Чем он огромнее, тем больше команд работают над ним, все больше надо межкомандного взаимодействия и надо либо все держать в одном монорепозитории, имея растущие проблемы связанные с этим (типа сделал пул-реквест, его проверили и отпричили, но замержить нельзя, ибо сонаркуб не закончил свою проверку, а как закончил, оказалось кто-то другой успел замержиться перед тобой, надо заново подмерживаться в свою ветку, просить опять отптичить пул-реквест, ибо он поменялся, и заново ждать, так могут целые дни проходить), либо разбиваться на разные репозитории и иметь свои проблемы связанные с этим. И вот в какой-то момент начинаешь мечтать о наборе полностью независимых сервисов, каждая команда работает над своим сервисом, или набором сервисов и с кем-то еще пересекается крайне редко.
Да по сути основной посыл статьи как раз об этом. Микросервисы не должны быть вариантом по умолчанию только потому, что это модно. Это инструмент решения определенного класса задач, причём достаточно ограниченного.
Если на картинке стрелочки расставить так, как оно обычно бывает в микросервисах, можно было бы сложить по связям много интересных слов :) поэтому я не рискнул.
Проблемы монолитов часто идут от того, что они растут из решений, которые не предполагали увеличения нагрузок. И часто такие решения разрабатывались людьми, которые не имели на тот момент нужных знаний или опыта. А как известно, исправление ошибок проектирования намного дороже исправлений кода. Вот и откладывается это на лучшие времена, а потом ищутся серебряные микросервисные пули.
А все почему?
Потому что, во-первых, надо правильно описывать архитектурно значимые требования. Например, для кейса с торговым ботом действительно очень важна низкая латентность. А вот для какого-нибудь сайта магазина - важна эластичность в зависимости от кол-ва пришедших клиентов.
Потому что нужно управлять сложностью и техдолгом. Толку от фичи, запиленной прямо сейчас, если завтра из-за нее мы сможем вносить изменения в 10 раз медленнее?
К сожалению, в нашем неидеальном для ИТ мире позиция архитектора закрывается по низшему приоритету. И это понятно - зачем бизнесу вкладываться в завтра, если непонятно, выживет ли он сегодня.
Бывают, конечно, случаи, когда разработчик внезапно проявил незаурядные таланты в проектировании - но это близкая к погрешности удача.
Подавляющая часть софта в мире спроектирована и сделана обычными разработчиками. Хорошими, но именно разработчиками.
Зря вы так превозносите архитекторов. Они в среднем бесполезны.
Бывают всякие особенности наименований. Я под разработчиком имею в виду человека который пишет код в продакшен хотя бы 3 дня в неделю.
Зря вы так превозносите архитекторов. Они в среднем бесполезны.
Вот не хотел я, чтобы мой комментарий так воспринимали. Видимо, не удалось правильно сформулировать.
Архитектор - по должности/лычкам и архитектор по складу ума/призванию - разные понятия. Я имею в виду именно вторых.
Ещё я хотел бы сделать акцент на том, что проектирование и разработка приложений с одной стороны, и программных систем с другой - это все-таки отличающиеся вещи, в которых полезны разные навыки. Кроме того, условные 20+ лет боевого многопроектного опыта против курсов переподготовки "вайти" могут сыграть свою роль.
Присоединяюсь. Мы начали отрезать куски от монолита, когда в большой распределенной команде у этого монолита тесты проходили час. И после первых N итераций у нас стало несколько сервисов, у каждого время пробегания тестов не больше 10 минут, а чаще около пары минут.
Поделитесь своим опытом:
Как изменился у вас объём тестирования при этом? Сколько тестов вы выкинули, сколько переписали? Как вы сейчас тестируете решение целиком? Если речь о тестировании функционала в рамках своего контекста/микросервиса, что мешало запускать тесты в параллель помодульно? Если перешли на CDC подход, что мешало применять его в модульном монолите?
Объем тестирования остался прежним. Тесты переписали, конечно. У нас был такой монолит, в котором не было dependency injection, и поднять для тестов можно было только все целиком. А в микросервисах мы всё сделали по уму, да ещё в части сервисов перешли с мавена на грейдл, что тоже дало ускорение билдов с тестами.
Помодульно запускать было можно, наверное, просто никто такое разделение не сделал.
Для решения целиком у нас есть отдельные end to end тесты, но они и с монолитом были. Ускорили мы юнит- и интеграционные тесты путем выделения его частей в микросервисы.
CDC у нас буквально несколько тестов, в основном потому что очень мало вызовов через REST, почти всё идет через мессаджинг.
Надеюсь, ответил
Чем он огромнее, тем больше команд работают над ним, все больше надо межкомандного взаимодействия и надо либо все держать в одном монорепозитории, имея растущие проблемы связанные с этим, либо разбиваться на разные репозитории и иметь свои проблемы связанные с этим.
Думаю, это основная причина по которой следует рассмотреть переход на микросервисы. Микросервисы это скорее не про архитектуру приложения, а про управление процессом разработки разработки в больших командах разработчиков.
Но к сожалению, зачастую в компаниях выбор в сторону микросервисов, принимается, на хайпе, менеджерами высшего звена. При этом команда проекта состоит из десятка разработчиков.
Давайте я вам свое расскажу за монолиты. За то как я на них погорел. Люблю их до боли. А все почему?
Писал всегда только монолиты. Что пишу - то и люблю. Иначе вот не получается как-то.
Всегда практически все полностью сам от начала до конца, от кода до развертывания. Типа самоделкин. Ну или фуллстек, как нынче принято. Приятно. В этом есть смак. Костыли, не костыли - нет проблем. Пока помню свою же архитектуру - вопросов ноль. Паттерны - по желанию. Есть страшные magic-куски и phd-code, да не беда, замечательно же. Приятно даже иногда.
Жаба мое все уже лет 8-10. Но вот недолюбливаю спринги с хибером и вообще любые фреймворки. Почти всегда можно самому сделать все, что они предлагают, и обычно это легко и просто. Обычно легче. Обычно производительнее. Обычно понятнее. Обычно удобнее. Свои DI и IOС, свой пул препередстейтметов без вымывания кеша, причем не ручками а рефлесией наделанный - ну вот что может быть проще.
Ненавижу всякие улучшайзеры и облегчаторы. Ломбок - как пример. Предурацкая же вещица. Типа - скажем нет бойлерплейту, а на самом деле втихую он же именно его и генерит. Ну вот какой в том смысл - загадка. Макрос в IDE - влегкую такое умеет.
и т.д. и т.п. Могу долго ныть == выпендриваться.
Почему все это плохо? Да потому, в основном, что мне полсотни лет в обед погожего августовского дня было.
Я как бы не самый бестолковый, и кандидат технических, и доктор экономических, и что, я полагаю, что весьма крут и хорош? А вот ни разу. Я буду совершенно точно не у дел, и вы тоже будете точно не у дел, потому что сейчас рынку нужно другое.
Что? А вот что: круд за утро накатать, к обеду затестить, а вечером надо закрыть таску и ждать CI+CD, которые желательно, чтобы не ругнулись даже. Те кто будут этот ваш круд дергать в него никогда не заглянут. Некогда. Все в гонке.За углом на питоне модель предсказания рынка вашего стека парни в кластере катают, а за другим углом из айфонового и флаттерного миров к вам постучали мобильные разрабы, за третьим на котлине хотят стильно-модно-молодежно, за четвертым на сях переписали узкий кусок или jvm на нейтив решили заменить. Плюс если бизнес взлетает, то надо за вечер его отмасштабировать в ширину и глубину. И? Вот и все. Вот вам они - микросервисы. Вот 12-ти факторные приложения, с очередями и реактивщиной. Вот он - 21 век, прошу любить и жаловать.
А еще, вот вам и вывод: монолиты - лепота, но увы, пока-пока. К ламповым приемникам и винилу плиз.
Знаете, я где-то понимаю и даже разделяю вашу грусть. И если рынок будет диктовать своё намерение переводить свои системы на микросервисную архитектуру, у меня есть аргументы за то, чтобы хотя бы подумали об альтернативах.
Но если решение уже принято окончательно и бесповоротно - ок, этот инструмент тоже есть в моём арсенале и мой священный долг как архитектора - минимизировать возможный вред от этого решения.
Если рынок хочет мы ему что угодно напишем. Пока деньги платят, проблем вообще нет.
Но хочется хотя бы иногда сделать хорошо. И не городить 100500 сервисов ради типовой задачи где в обозримом будущем от них точно не будет пользы. А распределенный монолит отработает идеально. И если бизнесу интересно, то всегда с радостью. И пошардируем хорошо и балансировщиками обвесим и отказоустойчивость на высшем уровне сделаем и маштабирование горизонтальное будет и скорость работы отличную сделаем и монолит красивый напишем.
Бизнесу этого на обозримый срок хватит. А если он сможет начать в Амазон превращаться, то все переписать заново это в любом случае самый разумный подход.
круд за утро накатать, к обеду затестить, а вечером надо закрыть таску и ждать CI+CD
Не знаю, что вам тут кажется необычным, но например на PHP это вполне реально, и не только для круд. Разделение на монолиты и микросервисы с этим никак не связано.
Такое ощущение что текущий проект, на котором я работаю делали по такому-же принципу.
Чертова куча велосипедов с квадратными колесами. Может оно поначалу и было легче, понятнее и производительнее, но сейчас это адЪ разработчика, в котором до конца не разбирается уже никто, даже те кто работает давно. Какие-то простые вещи в распространенных фреймворках, вроде - добавить новую табличку, написать для нее CRUD, пробросить денные через слои к внешнему API, то что обычно делается быстро и легко, потому что тривиально, у нас приходится исполнять с кучей танцев вокруг самописных фреймворков, глючных, кривых, неудобных и с массой загадочной магии под капотом.
Как-то понадобилось кое-что набросать на нормальном современном стеке, так я просто отдыхал, все просто, быстро и легко, при этом работает ну вот совсем не хуже этой груды велосипедов (лучше так-то, причем ощутимо).
А насчет ломбока - а не пофигу что он там генерит под капотом? Главное что он реально избавляет от бойлеркода. Вместо многословной простыни с массой геттеров, сеттеров, "private final" и прочей воды, имеем небольшой, аккуратный класс в котором нет ничего лишнего, код, который приятно изучать и сопровождать.
Писать под каждый ларек микросервисами исходя из того что он через какое-то время смаштабируется до пятерочки как-то мне кажется слишком. Крупные масштабирования - это уникальные, единичные случаи. Которые в обязательном порядке потребуют переписывания всего, и микросервисов тоже, даже если изначально с применением их было всё написано.
Мне не понятно отчего две копии монолита, запущенные на разных машинах, лучше, чем два микросервиса? И так и так распределённая система получается, со всеми вытекающими.
Самая большая разница в направлениях и объёмах потоков данных. Функциональная декомпозиция предполагает намного большую интенсивность взаимодействий между нодами, так как доменную логику реализуют сервисы запущенные на них. Даже с учетом выделения ограниченных контекстов.
В случае горизонтального масштабирования или шардирования монолитов ноды могут вообще не взаимодействовать явно, т.е. в вырожденном случае это будет не классическая распределенная система, а многоуровневая с некоторыми нюансами в виде балансировщика, аналитического хранилища и иже с ними.
В случае горизонтального масштабирования или шардирования монолитов ноды могут вообще не взаимодействовать явно, т.е. в вырожденном случае это будет не классическая распределенная система, а многоуровневая с некоторыми нюансами в виде балансировщика, аналитического хранилища и иже с ними.
и неявными требования. Потому что если этот монолит хранит внутри себя стейт - вы обрекаете себя на настройку чего-нибудь типа стики сессий на балансировщике. И количество костылей вокруг монолита при его масштабировании начинает расти в геометрической прогрессии. Мне кажется, что все через это проходили...
Липкие сессии - это решение для горизонтального масштабирования и применимо оно как для монолитов, так и для микросервисов. В статье картинка про куб масштабирования есть, там это отдельное измерение.
Я для себя вывел эмпирические правила - 1) масштабировать сначала по измерениям, наименее ограниченным окружением или внутренностями предметной области, и 2) не вводить новые измерения без крайней необходимости.
Где-то так.
Топологий распределенных систем можно много придумать, от этого они не перестают быть распределенными. Все приведенные варианты отличаются в деталях, но движущая сила одна и та же - надо как-то решать проблемы синхронизации разных нод между собой.
Есть идеальный случай. Синхронизация не нужна вообще или хватает типичного общего кеша. Тот же Редис из коробки. Это покрывает процентов 95 всех апишек ко всему.
Вот когда вам перестает хватать такой синхронизации стоит крепко подумать перед тем как дробить или распределять дальше. Монолит может оказаться лучше и надежнее.
Красный флаг это общий стейт или общие транзакции между сервисами. Написать-то можно. Но это прям очень сложно и очень долго. Вероятность что получится написать правильно и это окупится для бизнеса минимальна.
Я не соглашусь. Конечно, надо как-то решать проблему. Но есть разница между использованием существующего решения и написанием своего кастомного.
Вы же не пишите свою собственную бд.
Автономность команд разработки.
А так ли они автономны? Взаимодействие между микросервисами все равно ведь надо налаживать. Кажется, что проблема высокой связанности команд с разбиением на микросервисы не решается, а переводится в другую плоскость.
Думаю тут скорее изолированность. Все что происходит в Лас-Вегасе микросервисе, остается в микросервисе. С другой стороны в монолите тоже так легко можно изолировать модуль, только что там так-же легко можно эту изолированность и поломать, просто заюзав функционал в обход API модуля, что с микросервисом не получится.
Плюсану. Вы очень ёмко выразили основную мысль, которую я сам хотел донести в комментарии ниже. Но у меня огромный комментарий получился из нескольких частей, прям, монолит какой-то...
Мысль понятна. Но в модулях, думаю, статическим анализом можно добиться того же. Так что тут преимущество микросервисов разве что в дефолтности такого поведения.
А объясните мне, старому дураку, чем новомодные микросервисы отличаются от старых добрых акторов, которые еще в 70-х придумали?
Если основной посыл статьи — "думайте, прежде чем использовать микросервисы" — на 100% согласен.
Disclaimer: я не сторонник "пихать микросервисы везде", я за их умеренное использование там, где они уместны. На контрасте со статьёй дальнейшие слова могут показаться "фанатскими", однако, это не так.
Лично для меня основное удобство микросервисов в том, что в статье упомянуто как "Код небольшой и простой в обслуживании". Только в нашем случае (имею в виду часть проектов моей компании) я бы добавил "относительно" к "небольшой" и "простой"...
Когда кода реально много — появляются проблемы с тем, что, как ни старайся соблюдать границы внутри монолита, появляются "клубочки". Например, когда программисту проще смешать всё в одну кучу, потому что так удобнее решить конкретную задачу. А потом, с большой вероятностью, получить неожиданные сюрпризы из-за большой связанности кода.
Мы боремся с такими проблемами тем, что делаем явные границы, вынося их в API, которое уже контролируется и версионируется. Это создаёт дополнительные накладные расходы в разработке, спору нет. Зато дисциплинирует и позволяет надеяться на то, что, если поменяли только внутренности модуля, а мажорных изменений API нет, то поведение для вызывающего кода будет тем же.
А ещё, у каждого модуля свой жизненный цикл и вносить изменения в один модуль проще (в т.ч. с точки зрения тестирования). Конечно, до тех пор, пока не приходится делать мажорные изменения — тут уже надо решать, поддерживаем ли старую версию (и сколько старых версий) или всё настолько серьёзно, что лучше обновить все зависимости сразу.
Зато внутри модулей, особенно новых и не "устоявшихся", частично может быть подход "фигак-фигак и в продакшн", но он не распространяется как раковая опухоль на всё, а решение целиком работает приемлемо.
Почему я говорю про "модули" а не "микросервисы"? Потому что, строго говоря, те же самые преимущества можно получить и в рамках монолита (никто же не мешает сделать отдельные проекты и даже отдельные репозитории под модули). Но, на мой взгляд, сделать это сложнее, в основном — из-за возможности прямых вызовов.
Да, про прямые вызовы. У нас есть возможность сделать так, чтобы оба модуля были в одном процессе, но вызовы выглядят всё равно как внешние, через "прокси". И сериализацию параметров полезно оставить (чтобы, опять же, не прокрались лишние зависимости). Такой вот ".NET Remoting наоборот".
Возможно, мы какие-то нетипичные разработчики микросервисов и вообще (ужас!) — мы Docker не используем, хотя сервисы обычно распределены либо на несколько виртуалок, либо на несколько физических серверов.
В общем, из моего опыта (не буду называть что-то явно плюсом или минусом, не всё так просто):
- микросервисы заставляют тратить больше усилий на этапе проектирования;
- продуманный API — наше всё (мелкие исправления вносить несложно, а вот сильно переделывать — больно);
- некоторые "минусы" микросервисов можно обойти, когда есть возможность править (или написать свой) код, отвечающий за инфраструктуру (внешние вызовы и т.п.);
- не стоит ставить целью делать "мельчайшие" микросервисы, выше был правильный комментарий про Transaction Boundary и т.п.
P.S. "спец-циалисты" — прям хорошо!
Мне кажется, микросервисы это такой шаг назад в те времена, когда ещё были популярны EJB.
EJB тоже же задумывались как изолированные модули, которые можно было бы развёртывать по-отдельности. Кроме того, EJB из коробки предоставляли весьма полезные фичи: проброска секьюрного и транзакционного контекстов, сериализация из коробки.
Но в итоге они ушли в небытие. Почему? Потому что поддержка зоопарка EJB, написание ненужных интерфейсов, усложнение развёртывания, проблемы с несериализуемыми объектами, обратными вызовами и повышенное потребление ресурсов сильно усложняют и удорожают разработку и тестирование.
Зачем же мы делаем этот шаг назад? Неужели история нас ничему не научила?
Я ещё не видел инженеров, которые бы ратовали за микросервисы.
Создаётся впечатление, что единственным драйвером в поддержку микросервисов является стремление занять работой "архитекторов".
Затем, что концепт коммерческого сервера приложений сильно устарел, а на замену пришли коммерческие клауд платформы. С конспирологической точки зрения весь хайп вокруг микросервисов был создан исключительно, чтобы увеличить потребление бизнес приложениеми ресурсов клауда, а соответственно и стоимость. Реально микросервисная архитектура нужна лишь единицам, однако в АйТи как нигде силен культ карго...
Создаётся впечатление, что единственным драйвером в поддержку микросервисов является стремление занять работой "архитекторов".
Концепт сильно не поменялся -- так было и раньше. Стоимость разработки и поддержки растет, все заняты работой: менеджеры раздают таски, архитекторы рисуют интерфейсы, девелоперы клепают микросервисы, а девопсеры специалисты CI/CD поднимают стопицот тулзов и контейнеров, чтобы создать "пайплайн" -- без него никак. Все это деплоится в клауд, потребляя тонны ресурсов, и там потихоньку ворочается.
Не работал с EJB, но судя по пробросу транзакционного контекста из коробки они весьма связанные между собой штуки.
Мне кажется микросервисы не слишком удачно названны. Микро - как будто это что-то прям очень маленькое, вот и старается народ нарезать все на мелкие кусочки и отхватывает головную боль. На самом деле хотя-бы то, что у каждого микросервиса должна быть своя база данных и он не должен лазить в чужие говорит о том, что имеет смысл делать их довольно крупными, иначе начинает разваливаться согласованнось данных и приходится прилагать дофига усилий для ее обеспечения. Идеальная микросервисная архитектура это такая, при которой микросервисы никак не общаются друг с другом вообще (хотя на практике такое удается весьма редко). Что-то мне подсказывает, что EJB вообще не про это.
Я вот ратую за микросервисы. Только в моем понимании эти микросервисы подписываются на определенные каналы брокера сообщений и результаты обработки отправляют туда же (в другие каналы, разумеется). А общением с внешним миром - занимаются сервисы-гейтвеи, преобразующие сообщения в REST, веб-сокеты или что там еще понадобится, вплоть до электрических импульсов. Очень удобная, эффективная и расширяемая архитектура.
Зависимость от единственного физического узла.
Архитектура не влияет на физическое расположение. Монолит точно так же можно засунуть в оркестратор как и микросервисы.
Монолит точно так же можно засунуть в оркестратор как и микросервисы.
можно, но придется на уровне оркестратора сделать кучу настроек, чтобы что-то не пошло не так. Простой пример - монолит не умеет в две реплики, ну, так его написали. Засунешь в оркестратор наивно - в какой-то момент времени данные могут превратиться в труху, потому что две реплики таки запустилось. Приходится донастраивать, писать всякие костыли, чтобы это хоть как-то хромало
Сегодня в Telegram-канале ИТ Архитекторов я получил разгоромный комментарий от одного из участников и с его разрешения делюсь им. На мой взгляд, это хорошо оформленная точка зрения, показывающая неоднозначность темы, и я должен ей поделиться. Далее по тексту:
Про плюсы монолита:
Простота разработки в IDE зависит от того, монорепа или нет. Сколько сервисов - пофиг, IDE все стерпит )
Аналогично, нет проблем рефакторить и множество сервисов.
А почему монолит проще тестировать? Скорее сложнее, связей внутренних обычно больше.
Если развертывание идет через копирование файлов - то у вас большие проблемы с процессами, увы. Выкладка монолита - тоже сложный процесс, с миграциями, плановым остановом (если не поддерживается выкладка без простоя) и так далее.
Минусы тоже не совсем про монолиты:
Что значит "сложно разрабатывать разнородную функциональность"? Как это выражается? Почему в монолите это сложнее?
Можно и монолит частично выкладывать, делов-то. Ну, если это нужно. Технологий для этого куча.
Можно и монолит сделать кластеризуемым, это не сложно. И масштабируемым.
Нарисованные картинки с архитектурой цитадели вызывают много вопросов (особенно про отдельный интерфейс форпостов, это обычно не очень хороший подход, особенно в данном случае, лучше уж многослойную архитектуру рисовать). Впрочем, термин цитадали неплохо вносить в массы, это плюс.
Из плюсов микросервисов
непрерывную доставку можно делать и на монолите, микросервисы тут не при чем.
автономность команд не очень зависит от микросервисов или монолитов, а скорее от процессов.
Среди минусов не названы самые главные:
Версионирование взаимодействия и вытекающие проблемы с выкладкой
Поддержка кучи разных БД
Гарантии для бизнес-транзакций между разными БД
Из плюсов микросервисов
Я бы добавил:
3) API-first дизайн дает более чистую модель взаимодействия между бизнес компонентами и исключает "спагетти из вызовов", которые зачастую встречаются в монолитах. Ну по крайней мере теоретически.
Среди минусов не названы самые главные:
3) Гарантии для бизнес-транзакций между разными БД
А если учесть, что большинство коннектит свои микросервисы к одной и той же БД, напрочь теряя всякую возможность для ACID, то на мой взгляд это один из основных недостатков. Кто-то не заморачивается и тупо забивает на ACID, провоцируя неконсистентность в данных при отказе. А кто-то пытается городить велосипеды типа "сага", на смену того, что раньше решалось в две строчки, и которые к тому же не дают гарантий уровня ACID.
4) В разы более высокий расход ресурсов как для разработки, так и для продакшна. В миллионы раз более медленная скорость межкомпонентного взаимодействия.
5) Близорукость. Расхайпованный крупными техкомпаниями, продающими облачные мощности и сервисы, концепт микросервисов для многих стал своего рода культом карго и серебряной пулей для принятия решений об архитектуре системы, даже в самых явных случаях, когда микросервисная архитектура заведомо неоправданна.
А можно ссылку на этот телеграм чат/канал (интересно читать обсуждения там) или это закрытое сообщество?
Ничего секретного, в телеграме по поиску "Архитектура ИТ" легко находится: https://t.me/itarchitect
Если абстрагироваться от микросервисы vs монолит, то я вижу только такие частые причины выделять модуль в отдельный сервис:
1) модуль написан на другом языке или использует конфликтующие библиотеки,
2) модуль используется из разных клиентов, при этом, кеширует данные из своей собственной, принадлежащей ему, базы данных,
3) модуль имеет простой чёткий API и обновляется значительно чаще чем остальное приложение
Какие проблемы микросервисы не решают:
1) упрощение тестирования. Тестирование микросервисов сложнее. Необходимость тестировать систему в сборе никто не отменял.
2) упрощение развёртывания, масштабирование и надёжность: в этом смысле монолиты ничем не отличаются от микросервисов
Кроме очевидных технических сложностей, которые нет смысла перечислять, микросервисы выявляют организационные проблемы:
1) Нет чёткого понимания, какую именно проблему решает выделение модуля как отдельный сервис
2) проектирование сервисов заранее, хотя во всех книгах пишут что всегда начинайте с монолита и только потом выделяйте сервисы, если в этом есть необходимость
Хотя всё разумно и логично, но не мешало бы какую либо практическую привязку - "был монолит, перешли на микросервисы ... вернулись на монолит и живем счастливо". Либо - "начали с микросервисов - не пошло вернулись на монолит". Пускай даже случай не автора, а знакомых и пр.
Таким опытом не принято делиться, потому что:
такие шатания из стороны в сторону - расходование проектного бюджета с нулевым выхлопом (если только списать что-то на обучение команды, очень дорогое обучение);
вернуться обратно к монолитному решению для многих - это как расписаться в том, что "не шмогла я", поэтому будут идти до конца. Хотя бы, чтоб потом можно выступить на какой-то конференции с горячим докладом;
это не модно
... и много чего ещё.
Из своего опыта: я видел систему, спроектированную по всем канонам микросервисного искусства. С сагами, контейнерами и хранилищем в облаках.
Но не взлетевшую.
Сейчас эта система, собранная в монолит, обрабатывает запросы пользователей на ресурсах, на порядок меньших изначальных, и командой, в разы меньшей.
Чья в этом вина? Бизнеса, неверно рассчитавшего рыночную потребность, или архитектора, сделавшего хорошее (подчеркну еще раз, хорошее) но, увы, не в этих условиях решение?
Я бы ещё отзывы самих разработчиков послушал, а не теоретику
Тогда получилась бы другая статья. Мне уже здесь прилетело за "неструктурированность, непонятный посыл и отсутствие практических выводов". Добавьте сюда проектную практику с примерами, отзывы сейлзов, мнения стейкхолдеров и тестировщиков - и получится такая каша, которая как бы для всех, но в реальности для никого. Хотя все вроде бы и по теме.
Так что пусть это будет в другой статье: моей, вашей или чьей-нибудь еще.
Остальное детали — как разбивать, какие при этом появляются проблемы и как их решать.
Потому что приходишь ты на проект, а там дяди гоняют файл в сто мегабайт между двумя микросервисами раз пять за запрос.
В целом потому что тема очень сложная, а практика применения не очень хорошо наработанная.
Можно рассматривать сейчас топик "микросервисы vs монолит" как "c++ vs java". Примерно такая же байда. Или есть риск ногу отсрелить, или некоторые задачи будут решаться хуже.
Если коротко - проблема в том что между вызовами методов появляется сеть. Это добавляет сложность разработки и поддержки, которые неоправданно растут (не окупаются со временем).
вопрос к знатокам, может кто в теме: вроде как классическим стэком для микросервисов длительное время был стэк Netflix (по большей части это java и Spring). Но в последние годы всё больше двигаются в сторону Kubernetes. Как считаете, лучше ли Kubernetes? Что насчет service mesh?
Какая связь между java + Spring и Kubernetes?
речь не о Spring+java, а о стэке Netflix для микросервисов, который (так уж совпало) базируется в основном на Spring.
Я читал вот тут, https://en.wikipedia.org/wiki/Microservices (см раздел A comparison of platforms) в связи с чем и возник вопрос
Микросервисы. Не всё то золото, что хайп