шлет первому что-то, что тот просто в БД положит.
Предлагается между ними очередь впихнуть (со своей БД для надежности передачи). Все это потому что, как я понимаю, чистота микросервисности - у каждого сервиса своя БД.
А так ли нужны тут микросервисы?
Ведь будь это все один монолитик, то код отвечающий за статистику молча положил бы все это в БД куда надо и всего делов.
Я понимаю что они много чего ещё делают. Но вопрос-то все равно остается - а так ли надо их разделять и главное зачем? Уже возникшая проблема, решать которую предполагается ещё повышением complexity - звоночек.
Нет ли здесь overarchitecturing?
Делили на сервисы исходя из следующих условий: в статистике большой объем показателей и данных соответственно. Из них только один параметр влияет на работу основного сервиса, остальные обрабатываются уже в отдельном веб приложении. При этом основной сервис только отвечает на запросы клиентов , в базу сам практически ничего не пишет, только чтение (кром,е опять же, этого пресловутого показателя от сервиса статистики), критично время отклика. Размер баз данных и кол-во обращений к сервисам отличаются в разы. Соответственно, идея - поднимать доп. инстансы для каждого конкретного свервиса в случае нехватки ресурсов. У нас сейчас это вирт машины в облаке, хотя надо уже докер освоить.
Это все зависит от заморочек. И от рук разрабов тоже. Если поток сообщений интенсивен и многопоточен, то становится не так уж просто надежно класть объекты в БД. Допустим за месяц-два пара разрабов средней руки склепает что-то надежное и отказоустойчивое. Цена такого решения на старте порядка 7к зелени и не понятно сколько еще в поддержке. А можно заюзать уже все готовое. Очереди-шмочереди. Поддержка ретраев, dead queue, статистика, веб-морда состояния и так далее. Цена интеграции например неделя-полторы в свободном темпе одним программером + ленивое допиливание. Как-то так.
позанимавшись микросервисами на практие, понимаешь что тут скорее нужны хорошие девопсы для гигантской инфраструктуры, отличный менеджмент для кросс коммуникации команд, и спецы куда которые будут тянуть на себе лямку обратной совместимости
Обсуждают сегодня