т
ClickHouse на порядок быстрее будет
Size: a a a
2020 October 29
x
Конечно ооп - это не обязательно наследование)
Вот здесь вы не правы.
Наследование — это один из базовых и ключевых аспектов, которые определяют парадигму.
Именно потому у нас в го "не совсем ООП".
Наследование — это один из базовых и ключевых аспектов, которые определяют парадигму.
Именно потому у нас в го "не совсем ООП".
А
т.е писать в удаленный сервис быстрее чем писать в то же хранилище но в монолите ?
Должно быть быстрее, потому что монолит это Nginx->медленныйYii2->Mysql,
а сервис Nginx->express->mongodb
а сервис Nginx->express->mongodb
OY
ClickHouse на порядок быстрее будет
далеко не всегда, кликхаус создает кучу обезательств, это далеко не панацея от всех болезней
т
Должно быть быстрее, потому что монолит это Nginx->медленныйYii2->Mysql,
а сервис Nginx->express->mongodb
а сервис Nginx->express->mongodb
Экспресс кстати почти самый медленный фреймворк на ноде
D
Должно быть быстрее, потому что монолит это Nginx->медленныйYii2->Mysql,
а сервис Nginx->express->mongodb
а сервис Nginx->express->mongodb
вы только что сравнили два разных стека, причем тут микросервисная архитектура ?
x
такая архитектура в 99% случаев оверхед и не нужна вообще
Микросервисы это про большой бизнес, в котором большое количество команд решают большое количество задач.
Поэтому нет, 99% — это число далёкое от реальности.
Но если заменить "в 99% случаев" на "в большинстве случаев", то да, тезис будет верным.
Поэтому нет, 99% — это число далёкое от реальности.
Но если заменить "в 99% случаев" на "в большинстве случаев", то да, тезис будет верным.
А
Монгодб быстрее на запись по тестам, а у express должен быть отклик быстрее, потому что не yii2)
т
Это не микросервисы уже. На микросервисах это было бы так. Есть месседж брокер, который ловит и рассылает эвенты, сервисы подписаны на ивенты которые им нужны, и сервис аналитики или логгирования бы ловил нужные ивенты и писал бы их к себе в базу. Из которой бы это потом на какие-нибудь дашборды тянулось
D
Микросервисы это про большой бизнес, в котором большое количество команд решают большое количество задач.
Поэтому нет, 99% — это число далёкое от реальности.
Но если заменить "в 99% случаев" на "в большинстве случаев", то да, тезис будет верным.
Поэтому нет, 99% — это число далёкое от реальности.
Но если заменить "в 99% случаев" на "в большинстве случаев", то да, тезис будет верным.
мне кажется, что компаний где действительный нужны микросервисы, очень немного
только не путаем отдельно стоящий сервис логгирования, как выше пример обсуждался, и микросервисы
только не путаем отдельно стоящий сервис логгирования, как выше пример обсуждался, и микросервисы
А
Это не микросервисы уже. На микросервисах это было бы так. Есть месседж брокер, который ловит и рассылает эвенты, сервисы подписаны на ивенты которые им нужны, и сервис аналитики или логгирования бы ловил нужные ивенты и писал бы их к себе в базу. Из которой бы это потом на какие-нибудь дашборды тянулось
Конечно. Я делал именно микросервис - gateway получает запросы, кладет в очередь либо направляет запросы в нужный сервис.
x
Это не микросервисы уже. На микросервисах это было бы так. Есть месседж брокер, который ловит и рассылает эвенты, сервисы подписаны на ивенты которые им нужны, и сервис аналитики или логгирования бы ловил нужные ивенты и писал бы их к себе в базу. Из которой бы это потом на какие-нибудь дашборды тянулось
Микросервисы не обязательно работают через брокеры
т
Микросервисы не обязательно работают через брокеры
Ну когда сервисы общаются напрямую это убивает отказоустойчивость
x
мне кажется, что компаний где действительный нужны микросервисы, очень немного
только не путаем отдельно стоящий сервис логгирования, как выше пример обсуждался, и микросервисы
только не путаем отдельно стоящий сервис логгирования, как выше пример обсуждался, и микросервисы
Их достаточно, поверьте.
И будет всё больше и больше.
И будет всё больше и больше.
А
вы только что сравнили два разных стека, причем тут микросервисная архитектура ?
Один стек в монолите, другой стек решает свою отдельную задачу. Это ведь и есть микросервис.
x
Ну когда сервисы общаются напрямую это убивает отказоустойчивость
Да, но это не имеет отношения к самому паттерну
А
В общем в процессе разработки микросервиса появилось много вопросов, решение которых оказывалось громоздким. Решения этих вопросов можно упростить, но это уже новая экосистема. В общем для одного сервиса нужно поднимать целый стек, и до написания кода проходит много времени
D
Один стек в монолите, другой стек решает свою отдельную задачу. Это ведь и есть микросервис.
да, я вас неправильно понял в предыдущем сообщении, вопрос снимается
А
да, я вас неправильно понял в предыдущем сообщении, вопрос снимается
Ок))
D
но все же остается вопрос, что вы выиграли при записи в монгу через нгинкс+ноду ?
вы же все равно пишете из монолита только, соответственно напрямую из него писать в монгу гораздо быстрее
вы же все равно пишете из монолита только, соответственно напрямую из него писать в монгу гораздо быстрее