Программирование[11]

[Just.Doit]

ural1qqq написал 6 минут назад:

как у тебя могут работать остальные инстансы если они одинаковые

ну запускаешь и они работают

также как у одного микросервиса несколько инстансов

ural1qqq написал 8 минут назад:

Их делают независимыми чтобы не случилось то что ты написал что они каскадом встанут

ты можешь делать модули в монолите точно также независимыми

я про что и толкую. ничто не мешает тебе делать зависимые микросервисы и независимые модули монолита. вопрос не в сервисах а в модульности

Изменено 30 мая пользователем Just.Doit

[ural1qqq]

а причем тут тогда инстансы? 

ты с чем споришь одним предложением напиши

ты сделал независимые модули в монолите

о нет команда "пизда" пропустила критический баг в промышленную среду в своем функционале

фиксится код в общем репозитории

перекатывается все приложение целиком

 

кажется блять не такое уж и независимое 

[Just.Doit]

ural1qqq написал 38 минут назад:

а причем тут тогда инстансы? 

ты с чем споришь одним предложением напиши

ты сделал независимые модули в монолите

о нет команда "пизда" пропустила критический баг в промышленную среду в своем функционале

фиксится код в общем репозитории

перекатывается все приложение целиком

 

кажется блять не такое уж и независимое 

а в чем проблема что перекатывается все приложение?

это делается без простоев, green-blue deployment, просто процесс обновления инстансов

в чем сложность или проблема?

ural1qqq написал 38 минут назад:

ты с чем споришь одним предложением напиши

я спорю с тем что микросервисы это единственный путь решения обозначенных тобой проблем и тем что монолит сам по себе является их причиной, также как с тем что "очевдино" что МС решают их эффективно - не факт что решает вообще

- то что ты пишешь решается и в монолите, это менее популярно и меньше готовых наработок, но это лишь вопрос популярности и готовности экосистемы, а не неразрешимости проблем с использованием монолита

- большинство проблем которые решают МС это организационные проблемы так что применимость и оправданность МС сильно зависит от размера отдела разработки, а не от технических требований

Изменено 30 мая пользователем Just.Doit

[Index]

Можно делать модульность в монолите. Можно соблюдать в монолите Cohesion-Coupling. Более того это даже правильная стратегия разработки 

Скрытый текст

Потому что всегда можно выделить модуль в микросервис

 

С чем возникают сложности у монолита это с масштабируемостью и с динамическими связами между модулями.

 

Например делаем свой ЮТУБЧИК, пережимать видео во все форматы будем в рамках монолита?

Тут уже по хорошему нужно делать асинхронный пайплайн с энкодерами. (число которых можно скейлить по нагрузке)

 

А ещё микросервисы позволяют тебе делать бизнес-логику на разных технологиях/языках. Не обязательно даже через REST/gRPC общаться те же медиаэнкодеры которые могут брать задачи из кафки и работать с объектным хранилищем.

Но вообще микросервисы пилить диктует бизнес в том числе потому что ты можешь по DDD выделить одному домену один сервис, одну команду разработки которая будет его хуячить. (особенно когда в целом предметная область сложная, в куче доменов перепретаются глоссарии и рядовым кодеркам не нужен весь контекст для их же блага)

 

Как в принципе UNIX, пиши программы, каждая из которых делает ровно одну вещь и делает ее хорошо

[ural1qqq]

Just.Doit написал 55 минут назад:

я спорю с тем что микросервисы это единственный путь решения

понятно, а я говорю что такой подход сильно упрощает решение этой проблемы

 

я кстати не знал про green-blue deployment

[Vova]

Just.Doit написал 4 часа назад:

встал 1 инстанс монолита

 

 

Попроси коллегу девушку помочь решить эту проблему

[madvlaydin]

Vova написал 3 часа назад:

Just.Doit написал 9 часов назад:

встал 1 инстанс монолита

 

 

Попроси коллегу девушку помочь решить эту проблему

грохуф уже один раз попросил, чуть ч работы не кикнули

[faceles5]

привет камунити, у меня вопрос: те кто уже достаточно давно в этой области работают и имеют не малый опыт, скажите как часто вы работали или сталкивались с паралелизмом и асинхронщиной(да я знаю что это не одно и тоже)? и что самое сложное было при работе с ними?

[Arzanis]

По кд.
Хз что по сложности, грейсфул шутдаун наверн

Изменено 31 мая пользователем Arzanis

[faceles5]

т.е. с синхронизацией потоков, дедлоки и прочим проблем нету?) или это все с опытом приходит?

Изменено 31 мая пользователем faceles5

[Arzanis]

А это сильно зависит от платформы и, обычно, решается типовыми способами.
В моей практике сильной жопоболи не вызывает, но у меня бд и гошечка сейчас, и там, и там, всё отлично с инструментами.
На крестах наверн люди страдают, но это они пусть сами пишут.

[faceles5]

если не секрет сколько лет опыта промышленной разработки?

[Grohuf]

faceles5 написал 9 минут назад:

т.е. с синхронизацией потоков, дедлоки и прочим проблем нету?) или это все с опытом приходит?

 

В нормальной инфраструктуре про многопоточность особо не думаешь. Должна быть удобная система из пула потоков и постановки задач в него. Если она есть, то весь код представляет из себя перекидывание задачами из одного таск раннера в другой. Примитивы синхронизации при этом не используются.

[Arzanis]

faceles5 написал 3 минуты назад:

если не секрет сколько лет опыта промышленной разработки?

5

[GoldRobot]

faceles5 написал 24 минуты назад:

привет камунити, у меня вопрос: те кто уже достаточно давно в этой области работают и имеют не малый опыт, скажите как часто вы работали или сталкивались с паралелизмом и асинхронщиной(да я знаю что это не одно и тоже)? и что самое сложное было при работе с ними?

я мне кажется ни одной софтины не помню которая былабы не асинхронной

вне лаб чтоли кто-то синхронку пишет?

однопоточное еще реально, но синхронка это сразу на выкидку

faceles5 написал 19 минут назад:

т.е. с синхронизацией потоков, дедлоки и прочим проблем нету?) или это все с опытом приходит?

просто пиши сразу многопоток

если это работа с сетью, то сразу такой класс чтобы он был тредсейф

никаких ебучих boost::asio::strand подобного дерьма

Изменено 31 мая пользователем GoldRobot

[faceles5]

GoldRobot написал 8 минут назад:

faceles5 написал 29 минут назад:

привет камунити, у меня вопрос: те кто уже достаточно давно в этой области работают и имеют не малый опыт, скажите как часто вы работали или сталкивались с паралелизмом и асинхронщиной(да я знаю что это не одно и тоже)? и что самое сложное было при работе с ними?

я мне кажется ни одной софтины не помню которая былабы не асинхронной

вне лаб чтоли кто-то синхронку пишет?

ну спринг на java синхронщина везде(по умолчанию(даже под капотом)), я с ним работаю

 

Arzanis написал 21 минуту назад:

А это сильно зависит от платформы и, обычно, решается типовыми способами.
В моей практике сильной жопоболи не вызывает, но у меня бд и гошечка сейчас, и там, и там, всё отлично с инструментами.
На крестах наверн люди страдают, но это они пусть сами пишут.

для кого софт пишите?

Изменено 31 мая пользователем faceles5

[Arzanis]

faceles5 написал 6 минут назад:

для кого софт пишите?

Сейчас инхауз мелочь, но с кучей интеграций с другими системами.
До этого свой биллинг на 1кк клиентов.

[Grohuf]

GoldRobot написал 17 минут назад:

если это работа с сетью, то сразу такой класс чтобы он был тредсейф

Это не обязательно, если используется асинхронщина. Но тогда нужно ставить ассерты, если класс дернули не с того потока.

Изменено 31 мая пользователем Grohuf

[faceles5]

Arzanis написал 4 минуты назад:

faceles5 написал 13 минут назад:

для кого софт пишите?

Сейчас инхауз мелочь, но с кучей интеграций с другими системами.
До этого свой биллинг на 1кк клиентов.

*картинка с текстом*

 

Изменено 31 мая пользователем faceles5

[Olololnet]

я бы сказал, что практика такая, что надо хорошо это знать, одновременно с этим столкнуться в большом проекте сложно, т.к. всё уже скорее всего написано, есть только верхний уровень, где не обосраться. это про плюсовый бэкенд