MA
Короче микросервисы это масштабируемость бизнеса и мера вынужденная. Монолит проще развивать
Size: a a a
2019 May 28
V
п. 5 решает)
MG
Лучше без вызовов, а через очереди.
MG
Это чуть сложнее, но решает проблему недоступности.
OR
В случае с (микро)сервисами становится ещё веселее. Это я про очереди.
Ц
Ну и в них стектрейсы понятны. А если 1 микросервис дернул 2й а тот 3й и тот упал то проследить цепочку вызовов откуда началось просто так как в монолите не получится - уже инфраструктура нужна
для этого есть шаблон saga
Ц
в EIP, Apache Camel например
Ц
в отличие от того гребаного стыда что нам навязала банда четырех, EIP крайне полезные шаблоны и пока не подводили при разработке архитектуры
DB
Это чуть сложнее, но решает проблему недоступности.
+
OR
Банда не навязывала, стыд получился от того, что сделали карго-культ, так же как и из сервисов.
VL
ну ведь монолиты это реально боль?
A
ну ведь монолиты это реально боль?
В чем она выражена?
VL
1. тесты прогоняются 15+ минут
2. запускается так, что макбук взлетает
2. запускается так, что макбук взлетает
OR
Давай заменим на локальный кубер
OR
Что-то поменяется кардинально?
VL
Главное чтобы сложность повышалась осознанно, а не просто потому что модно. А напилят сервисов, где достаточно было изолировать модули, а потом решают проблемы, которые сами себе привезли.
я думаю, изоляция модулей это отличная золотая середина
VL
Что-то поменяется кардинально?
ничего
RP
с очередями надо аккуратно: https://programmingisterrible.com/post/162346490883/how-do-you-cut-a-monolith-in-half
OR
ничего
Может местами тесты быстрее будут. Но зато сразу дополнительный оверхед на взаимодействие.