SP
ладно там у скриптодетей нет типов и им сваггер заменяет интерфейсы внешние
Size: a a a
2020 June 07
p
зачем нужны микросервисы когда есть типы и каналы?
легче масштабируется
p
и разрабатывается
p
и поддерживается
DS
зачем нужны микросервисы когда есть типы и каналы?
Сильно проще код, процессы и команды организовывать
VS
Тут основная проблема, что ты в такой архитектуре получишь просто дикое латенси на любую нетривиальную операцию.
Ну не такую большую как тебе кажется. Вообше с твоими мышлением - делай монолит с всяким голым SQL без ORM и не парься.
p
Ну не такую большую как тебе кажется. Вообше с твоими мышлением - делай монолит с всяким голым SQL без ORM и не парься.
ну он это и говорит тут постоянно)
DS
ну он это и говорит тут постоянно)
Ну монолит не обязательно, но делать пустые сервисы без особой логики жалко.
VS
@DogeShibu У нас с тобой вообще цели разные. Я за Дерево микросервисов и ORM вроде EF и Чистую Архитектуру. Ты вообще про другое по ходу.
DS
@DogeShibu У нас с тобой вообще цели разные. Я за Дерево микросервисов и ORM вроде EF и Чистую Архитектуру. Ты вообще про другое по ходу.
Я за то, чтобы проектировать приложения сразу помня про перформанс.
Это куда проще, чем потом с пылающей задницей оптимизировать.
Причем, архитектура внутри приложения обычно от этого не сильно страдает. Тот же DAL всё равно изолирует весь SQL в себе, а на остальную архитектуру такие вещи влияния особо не оказывают.
Те же микросервисы - они имеют смысл, но с ними тоже важен баланс, т.к. их инфраструктурная стоимость всё равно велика.
Это куда проще, чем потом с пылающей задницей оптимизировать.
Причем, архитектура внутри приложения обычно от этого не сильно страдает. Тот же DAL всё равно изолирует весь SQL в себе, а на остальную архитектуру такие вещи влияния особо не оказывают.
Те же микросервисы - они имеют смысл, но с ними тоже важен баланс, т.к. их инфраструктурная стоимость всё равно велика.
VS
Я за то, чтобы проектировать приложения сразу помня про перформанс.
Это куда проще, чем потом с пылающей задницей оптимизировать.
Причем, архитектура внутри приложения обычно от этого не сильно страдает. Тот же DAL всё равно изолирует весь SQL в себе, а на остальную архитектуру такие вещи влияния особо не оказывают.
Те же микросервисы - они имеют смысл, но с ними тоже важен баланс, т.к. их инфраструктурная стоимость всё равно велика.
Это куда проще, чем потом с пылающей задницей оптимизировать.
Причем, архитектура внутри приложения обычно от этого не сильно страдает. Тот же DAL всё равно изолирует весь SQL в себе, а на остальную архитектуру такие вещи влияния особо не оказывают.
Те же микросервисы - они имеют смысл, но с ними тоже важен баланс, т.к. их инфраструктурная стоимость всё равно велика.
Был бы для меня важен перформанс - Яб как ты на Rust писал бы.
DS
Был бы для меня важен перформанс - Яб как ты на Rust писал бы.
Эти вещи актуальны и для io-bound задач в той же мере.
Вон, почитай как в stack overflow пишут на C# и экономят на железе за счёт кода сразу написанного с учётом вопросов производительности
Вон, почитай как в stack overflow пишут на C# и экономят на железе за счёт кода сразу написанного с учётом вопросов производительности
NL
Я за то, чтобы проектировать приложения сразу помня про перформанс.
Это куда проще, чем потом с пылающей задницей оптимизировать.
Причем, архитектура внутри приложения обычно от этого не сильно страдает. Тот же DAL всё равно изолирует весь SQL в себе, а на остальную архитектуру такие вещи влияния особо не оказывают.
Те же микросервисы - они имеют смысл, но с ними тоже важен баланс, т.к. их инфраструктурная стоимость всё равно велика.
Это куда проще, чем потом с пылающей задницей оптимизировать.
Причем, архитектура внутри приложения обычно от этого не сильно страдает. Тот же DAL всё равно изолирует весь SQL в себе, а на остальную архитектуру такие вещи влияния особо не оказывают.
Те же микросервисы - они имеют смысл, но с ними тоже важен баланс, т.к. их инфраструктурная стоимость всё равно велика.
Кстати поддерживаю, достичь перфоманса в неожиданном месте, заранее это не планируя, может вылиться в глобальный рефакторинг с разрушением кучи внутренних связей и инвариантов и ещё не факт, что этот перфоманс удастся достичь даже такими жертвами.
У меня был проект, когда заказчик в какой-то момент решил сделать новостную ленту наподобие того, что было в вк раньше. И эта страничка была одной из самых тяжёлых, для отображения которой требовалось сходить буквально во все (за исключением пары) сервисы. Это была полнейшая жопа.
Конечно об этом надо было думать заранее.
У меня был проект, когда заказчик в какой-то момент решил сделать новостную ленту наподобие того, что было в вк раньше. И эта страничка была одной из самых тяжёлых, для отображения которой требовалось сходить буквально во все (за исключением пары) сервисы. Это была полнейшая жопа.
Конечно об этом надо было думать заранее.
VS
Эти вещи актуальны и для io-bound задач в той же мере.
Вон, почитай как в stack overflow пишут на C# и экономят на железе за счёт кода сразу написанного с учётом вопросов производительности
Вон, почитай как в stack overflow пишут на C# и экономят на железе за счёт кода сразу написанного с учётом вопросов производительности
Ну для простой системы таким фасадом в котором будут лежать Saga с этапами типо сходи в МС1, сходи с результатом из МС1 в МС2 и с результатом всего этого либо в МС3 либо в МС4 может служить сам Гейтвей
VS
Сами МС1, 2, 3 и 4 друг о друге понятия не имеют
VS
Хм, я тут подумал. В моём EShopOnBlazor там API это монолит. Наверно напишу статью на его примере как разбить монолит на микросервисы и сделать из монолита Гейтвей + Фасад с Сагами.
DS
Ну для простой системы таким фасадом в котором будут лежать Saga с этапами типо сходи в МС1, сходи с результатом из МС1 в МС2 и с результатом всего этого либо в МС3 либо в МС4 может служить сам Гейтвей
Ну сага это всё же про поддержку консистетности между разными бд в разных сервисах.
Это далеко не везде актуально
Это далеко не везде актуально
VS
Ну сага это всё же про поддержку консистетности между разными бд в разных сервисах.
Это далеко не везде актуально
Это далеко не везде актуально
Ну тогда просто Гейтвей который в одном методе Контроллера тупо вызывает МС1, 2, 3, 4 если там надежности не надо особой и можно с нуля все начинать спокойно
VS
Ну сага это всё же про поддержку консистетности между разными бд в разных сервисах.
Это далеко не везде актуально
Это далеко не везде актуально
Ну не толко БД. Просто когда надо чтобы вот в конце концов выполнился запрос даже если вдруг вырубится МС и запуститься снова тоже удобно. Когда лишние запросы делать не охота и результаты предыдущих сохранить надо как промежуточные данные тоже норм
VS
Ну да, большинство проблем решается изначальной идемпотентностью запросов