Комментарии 5
Надоела одна и та же теория. А когда доходит до практики - там столько проблем всплывает. Лучше бы рассказали в деталях как было, как стали переводить, с какими проблемами столкнулись и как решали.
Что вы делали когда обработка бизнес запроса стала запаздывать из-за кучи обращений по сети и вышли за пределы требований в 1-3 секунды на один запрос?
Что вы реально делали с распределенными транзакциями? А не абстрактные рассуждения про саги и двухфазные комиты
Какое средство вы применили, когда потребовалось трейсить время прохождения запроса по всем микросервисам, чтобы знать какой именно микросервис тормозит или какая именно БД?
Что там насчет version hell? Вот серьезно - одному клиенту надо часть бизнес процесса обрабатывать по версии 1, для другого клиента по версии 2. Про слабую связанность - это все сказки. Красиво только на учебном примере. В реальности в одном месте поднял версию апи, в других местах понавешал костыли.
Кафку использовали для взаимодействия микросервисов? Что там насчет авто масштабирования?
Как известно, Иннотех сейчас переводит банковское ПО ВТБ на микоросервисную архитектуру и при этом разрабатывает какие-то новые подсистемы.
Возникают вопросы
1. Почему разработчики ВТБ не заметили, что можно сделать декомпозицию подсистем и выделить для каждой из них отдельную базу данных.
2. Создается впечатление, что Иннотех режет ПО ВТБ по живому и разрывает связи между данными, которые могут потребоваться при обработке. Это может привести к существенному замедлению обработки данных.
3. Вообще вопрос декомпозиции сложной системы на независимые подсистемы раньше (20 лет назад) решался достаточно просто —достаточно было посмотреть модель данных сложной системы (например, реляционную модель). Если связей между данными нет, то можно делать декомпозицию. Сейчас это превратилось в религию.
4. Забавно то, что Иннотех соревнуется со Сбером (проект Гостех) в вопросах микросервисной архитектуры. Интересно, кто победит?
Для теории микросервисов - маловато и сухо. Для истории развития бизнеса, слишком поверхностно. Очень модная тема которая во многих местах раскрыта. Вот послушать историю как ночами не спали кололи монолит на части, интересно.
Как дораскалываем до конца года и наконец выспимся может дойдут руки написать статью) Ну а так у всех команд в Иннотех наверное по разному. У нашей все просто, выпиливаем основные домены в отдельные сервисы, приправляем оркестратором, дружим все это по брокеру, поочередно выносим основную функциональность в отдельные сервисы и молимся чтобы сетевые нагрузки не порушили SLA ответов. Ну и попутно заставляем оркестратор раскалывать запросы на куски чтобы часть шла в старый монолит а часть на новые микросервисы и отправляем это дело на продакшн, чтобы выводить в прод и тестировать все это безобразие по отдельности. Затем потихоньку отщипываем функциональность в отдельные сервисы попутно выпиливая их из монолита. Но мы с командой делаем в Иннотех бэк с ml модельками так что у нас домены в принципе не сильно связаны изначально не смотря на монолитную архитектуру. Возможно у команд где есть фронт и сильная связность история будет поинтереснее)
Современная микросервисная архитектура: принципы проектирования