Comments 14
А почему "микро"? Меня всегда удивляет любовь к приставкам без смысла.
У нас нет "конвергентных систем", у нас только "гиперконвергентные". Выбирая между скучным "порезали на несколько сервисов" и звучным "микросервисы" всегда выбирают "микросервисы".
... Там же в финале получается ультразвуковой лазерно-магнитный прогреватель "Супер Турбо Плюс" с неонкой внутри.
Действительно часть сервисов - довольно крупные и не могут считаться "микро", однако остальная - вполне себе может. Например оплата, аналитика, файловое хранилище, пользователи, авторизация и т.д. Они маленькие, выполняют единственную задачу и содержат не много кода.
Во! Как только вы говорите про "делать сервисы минимально логически возможные", вот тут вот мы уже переходим к реальным микросервисам. Я бы даже сказал, что слово "микро" тут обманчиво, потому что 1 микросервис == миллион пикосервисов, или нет? Если бы их назвали инфиум-сервисы, было бы точнее.
... И это же позволяет задать главный вопрос к микросервисам - а сдюжите? Если каждый логический блок выносится на сетевой уровень, то его интеграция в готовый продукт ложится на плечи тех, кто сетевой уровень планирует и операционно поддерживает.
Мы подобное и пытались сделать - было два крупных сервиса и общие части стали разделять по функционалу и выносить, в какой-то момент их стало очень много и мы действительно "не сдюжили", да и как показала практика не нужны они были под такую низкую нагрузку. Так что мы теперь объединяем лишнее в монолит, а то что действительно себя хорошо показало в качестве микросервисов - оставляем.
По итогам этой работы мы имели уже два связанных друг с другом сервиса. В каждом были данные пользователей (логин, пароль, ФИО, контакты и др.). При изменении в одном месте приходилось через API менять синхронно в другом месте. Это привело к тому, что у нас начали возникать ошибки синхронизации, а работать с ними стало сложнее.
Если у вас была постоянная необходимость распределенных транзакций, то, возможно, у вас были не микросервисы, а так называемый "микросервисный монолит" (который суть есть антипаттерн).
Требуются клиенты для общения друг с другом, общие пагинаторы, форматтеры, логеры и т.д.
Вот тут как раз микросервисы очень сильно выигрывают. Потому что весь cross-cutting делается в виде отдельных пакетов с версионированием, при этом можно обновить какой-то пакет в одном микросервисе не затрагивая все остальные. В монолите ошибка, к примеру, при рефакторинге какого-нибудь логгера завалит вам весь этот монолит.
Зачастую, даже если кажется, что микросервисы отлично подходят, запускать MVP стоит на монолитной архитектуре.
Но, по статье, вы-то как раз сделали все наоборот - пока были стартапом, то делали микросервисы, а как подросли, то стали переходить на монолит. Что странно, потому что как раз на начальном этапе проекта как раз может быть еще вообще неясно на какие микросервисы систему разбивать и рациональней делать монолит, а потом уже, при большей ясности структуры системы её разбивать. Возможно, что у вас все последующие проблемы как раз из-за этого и возникли.
Но, по статье, вы-то как раз сделали все наоборот - пока были стартапом, то делали микросервисы, а как подросли, то стали переходить на монолит. Что странно, потому что как раз на начальном этапе проекта как раз может быть еще вообще неясно на какие микросервисы систему разбивать и рациональней делать монолит, а потом уже, при большей ясности структуры системы её разбивать. Возможно, что у вас все последующие проблемы как раз из-за этого и возникли.
Делали то, что лучше умели и под текущую задачу бизнеса, так как не ясно что получится в итоге - не угадали, пришлось переделывать. С такой же вероятностью могло сильно стрельнуть и такая архитектура принесла бы свои плюсы.
Если у вас была постоянная необходимость распределенных транзакций, то, возможно, у вас были не микросервисы, а так называемый "микросервисный монолит" (который суть есть антипаттерн).
Тут согласен, увлеклись и стали выносить даже то, что жёстко связано между собой. В итоге довольно вовремя спохватились и собрали обратно, оставив только то, что необходимо.
Вот тут как раз микросервисы очень сильно выигрывают. Потому что весь cross-cutting делается в виде отдельных пакетов с версионированием, при этом можно обновить какой-то пакет в одном микросервисе не затрагивая все остальные. В монолите ошибка, к примеру, при рефакторинге какого-нибудь логгера завалит вам весь этот монолит.
Так и есть сейчас, отдельный наборы пакетов для работы c ними. Хотя необходимость править ещё и их немного напрягает, но это видимо побочный эффект такого подхода и с этим ничего не сделать.
Ничего удивительного в вашем случае нет. Дело тут не в микросервисах или монолитах. Вы начали с проверки гипотез и прототипа - просто не угадали будущего. Обычное дело. Пока продукт более или менее не вырисовывается, продумать подходящую архитектуру невозможно. Правильный ход - делайте то, знаете и то, что быстрее. Если сделали удачную ставку, то потом чуть меньше переделывать. А если не угадали - то всё выиграли время, сэкономили на ресурсах в критический момент старта и получили фидбек рынка.
Помню, в начале 2000-х тоже реализовали нечто подобное. У нас не было куберов и докеров, но были 1С Бухгалтерия и 1С Торговля, и " мы решили сделать так, чтобы они общались между собой. Тем самым мы заложили основу микросервисной архитектуры".
Немного удивили названия функций - getMinimalApiView, getShortApiView... Все они возвращают обычные данные, тогда зачем здесь API в названиях?
Как правило, мы в начале разрабатываем проект, как модульный монолит. И переходим к сервисной архитектуре лишь, когда в команде появляются люди с другими стэком (например ML разработка) или появляется множество технических задач, которые к бизнес-логике мало имеют отношения (множество способов авторизации).
И в большинстве случаев сервисная архитектура выглядит у нас, как "цитадель" (не помню, кто это придумал) - есть core сервис c бизнес логикой, а в все остальные обслуживающего характера функции вынесены в сервисы: авторизация, SMS/Push уведомления, файловые хранилища и т.д. Взаимодействие, тогда становится простым, а необходимость использовать сагу/хореографию сводится к минимуму.
От микросервисов к монолиту — маршрут построен