Comments 14
Очень полезно, спасибо
Я так понимаю это статья для джунов-джунов, а потому делаю постскриптум: монолит твой друг, джун!!!! Остановись, пока не поздно!!!!!!!!! :))
Ну монолит как и микросервисы это не серебряная пули. И оставлять разработчика тел знания и опыта работа микросервисов(или наоборот монолита) такое
Суровая правда в том, что это не так важно - монолит или не монолит. Вернее, это важно только в смысле «сам себе злобный буратина»: проблема масштабирования stateless compute очень маленькая по сравнению с реально сложной вещью - масштабированием stateful database layer.
А почему люди так любят рассуждать про масштабирование compute - да вот как раз поэтому, из-за того, что рассуждать на данную тему легко. Это вообще паттерн: из всей задачи выделить самые простые 5% и раздуть их до 100% в текстах, документации, выступлениях на конференциях и т.д. Касается не только айти кстати, но и других аспектов жизни.
Поэтому я бы сказал не столько «монолит - твой друг», сколько «монолит или не монолит, это мало на что влияет, и можно в любой момент поменять».
А вот если у нас в базе монолит изначально (нет горизонтального масштабирования и не предусматривался такой путь развития), вот это прям беда-беда.
Nginx как прокси для прокси не нужен.
В статью было бы неплохо добавить ответ кракаена на последний http-запрос. А то остаётся только догадываться, как по умолчанию происходит композиция.
А у нас в сервисах в пункте про API-composition разве не должен быть написан "внутренний" эндпоинт? там стоит прокси @app.get("/users/{user_id}/") Хотя по идее должен быть "users_service/{user_id}/". Может я чего-то не понимаю
Спасибо за статью
Микросервисы на пальцах: API‑Gateway, API‑Composition, KrakenD, FastAPI