Видимо вам - не стало. Предполагаю, из-за отсутствия понимания, как это сделать. Все эти ваши "проблемы" уже сто раз решены.
Более того, вы можете держать "горячую" копию с репликой бд рядом, и если у вас упадёт продукт, вы сможете переключиться на неё автоматически и с минимальной задержкой (k8s). С микросервисами вы держать горячую актуальную копию вряд-ли сможете.
Более того, подсети телеги известны, а частные MTProxy - нет. Вот как раз на распознавании этого траффика, вероятно, и огромном кол-ве ретраев, можно положить DPI и остальное.
Если бы их забанили – то да, для РКН было бы гораздо легче. Но их троттлят, а это нагрузка!
И просто сократив интервалы между ретраями для соединения с серверами и уменьшив таймаут - при таком кол-ве клиентов и TCP соединении, нагрузка на DPI возрастёт не пропорционально.
Есть смысл! Потому что вы произносите, мягко скажем, сомнительные тезисы и чаще всего этими тезисами аргументируете переход на микросервисные/распределённые архитектуры, что удорожает разработку в разы!
Вам сразу зачем то понадобилась изоляция, почему-то монолиты перестали масштабироваться, а отказы у микросервисов вообще пропали как явление)
Если у вас в монолите, по какой-то причине, падает поток/корутина, то это не значит, что у вас должно упасть всё! Это значит, что поток не был покрыт try ... except (python) и не были обработаны все критические участки кода на ошибки.
По такой же причине у вас может упасть любой микро/макро/наносервис!
Так что не надо переваливать ответственность с кривых рук на архитектуру)
UPD Более того, вы все так же можете перезапустить этот поток/корутину, если у вас это продумано и над изоляциями предусмотрены обёртки, которые, в случае падения критически важного потока/корутины, перезапускают её и восстанавливают стейт.
Золотые слова! У нас в России, вот уже лет 15 по моим наблюдениям, кол-во архитектурной астронавтики выросло в разы и удержать архитекторов/лидов от внесения необоснованой сложности - дорогого стоит. Проблема в том, что последствия этой сложности проявляются спустя годы разработки и цена таких ошибок очень велика.
Вас послушать, так можно подумать, что все живут в SAAS-ах, вебе и других продуктах, "варящихся" в своих инфраструктурах. Не забывайте про "коробку" или embedded например - туда вы не втащите всё это барахло, а программирование - далеко не всегда полная свобода действий. В чем-то я с вами соглашусь - та же гарантия доставки должна быть реализована отдельно, если нужно, да и то в случае кластерных многонодовых решений. В остальном - это инструмент для своих задач и называть его анахронизмом я бы не стал.
Если вы только из-за того, что бы реализовать let it crash, будете притягивать микросервисную архитектуру, оркестратор и тд, то это очевидно попахивает архитектурной астронавтикой. Есть инструмент - он хорош для своих задач. Сравнивать готовый инструмент с какой-то там архитектурой, подходящей только для проектов с дикими нагрузками - я бы точно не стал.
Всё верно - его нет. А нет его потому-что в большинстве случаев это кастомный функционал, необходимый на месте и реализовывать его универсальным просто не нужно. А в OTP же это сделать максимально просто с помощью ETS, cb terminate, cb init и конечно try/catch. OTP даёт тебе все инструменты для этого и каркас (supervisor/gen_server/...). Остальное сам)
Потому что BEAM использует потоки ОС и работает над ними, используя асинхронный подход в каждом потоке и довольно сложный шедулер, реализуя аналог корутин + недавно, вроде как, стал более стабилен JIT BEAM
Так же потому, что то, что должно упасть/подняться (основной концепт OTP), должно сделать это максимально быстро, с восстановлением стейта и коммуникаций.
Да к чему она мне, карма местная? Я о другой карме думаю) Да и инфы по теме high availability уж очень много в интернетах. Тут тоже что-то было.
Видимо вам - не стало. Предполагаю, из-за отсутствия понимания, как это сделать. Все эти ваши "проблемы" уже сто раз решены.
Более того, вы можете держать "горячую" копию с репликой бд рядом, и если у вас упадёт продукт, вы сможете переключиться на неё автоматически и с минимальной задержкой (k8s). С микросервисами вы держать горячую актуальную копию вряд-ли сможете.
Swarm, k8s etc всё это умеют.
Более того, подсети телеги известны, а частные MTProxy - нет. Вот как раз на распознавании этого траффика, вероятно, и огромном кол-ве ретраев, можно положить DPI и остальное.
Если бы их забанили – то да, для РКН было бы гораздо легче. Но их троттлят, а это нагрузка!
И просто сократив интервалы между ретраями для соединения с серверами и уменьшив таймаут - при таком кол-ве клиентов и TCP соединении, нагрузка на DPI возрастёт не пропорционально.
Похоже Паша уменьшил интервал и таймаут ретраинга у клиента при реконнекте к своим серверам и ТСПУ (+DPI) встали колом :)
Есть смысл! Потому что вы произносите, мягко скажем, сомнительные тезисы и чаще всего этими тезисами аргументируете переход на микросервисные/распределённые архитектуры, что удорожает разработку в разы!
Вам сразу зачем то понадобилась изоляция, почему-то монолиты перестали масштабироваться, а отказы у микросервисов вообще пропали как явление)
Если у вас в монолите, по какой-то причине, падает поток/корутина, то это не значит, что у вас должно упасть всё! Это значит, что поток не был покрыт try ... except (python) и не были обработаны все критические участки кода на ошибки.
По такой же причине у вас может упасть любой микро/макро/наносервис!
Так что не надо переваливать ответственность с кривых рук на архитектуру)
UPD Более того, вы все так же можете перезапустить этот поток/корутину, если у вас это продумано и над изоляциями предусмотрены обёртки, которые, в случае падения критически важного потока/корутины, перезапускают её и восстанавливают стейт.
Давайте так - это свойство Вашего монолита
Нет у микросервисной архитектуры никакой устойчивости, если вы её сами не реализуете)
Вы сейчас переизобрели event-driven "конвеер" типа ETL.
За статью - спасибо! Простота спасёт мир!
Золотые слова! У нас в России, вот уже лет 15 по моим наблюдениям, кол-во архитектурной астронавтики выросло в разы и удержать архитекторов/лидов от внесения необоснованой сложности - дорогого стоит. Проблема в том, что последствия этой сложности проявляются спустя годы разработки и цена таких ошибок очень велика.
Лично меня это настораживает. Но ладно)
UPD Вообще, у нас в отрасли, там, где должен быть абсолютный прагматизм, поклонение и "горящие глаза" - ну такое. Но статья дельная!
Подтверждаю. Не мог забрать апдейты с AUR без VPN несколько дней назад.
Вас послушать, так можно подумать, что все живут в SAAS-ах, вебе и других продуктах, "варящихся" в своих инфраструктурах. Не забывайте про "коробку" или embedded например - туда вы не втащите всё это барахло, а программирование - далеко не всегда полная свобода действий. В чем-то я с вами соглашусь - та же гарантия доставки должна быть реализована отдельно, если нужно, да и то в случае кластерных многонодовых решений. В остальном - это инструмент для своих задач и называть его анахронизмом я бы не стал.
Если вы только из-за того, что бы реализовать let it crash, будете притягивать микросервисную архитектуру, оркестратор и тд, то это очевидно попахивает архитектурной астронавтикой. Есть инструмент - он хорош для своих задач. Сравнивать готовый инструмент с какой-то там архитектурой, подходящей только для проектов с дикими нагрузками - я бы точно не стал.
Всё верно - его нет. А нет его потому-что в большинстве случаев это кастомный функционал, необходимый на месте и реализовывать его универсальным просто не нужно. А в OTP же это сделать максимально просто с помощью ETS, cb terminate, cb init и конечно try/catch. OTP даёт тебе все инструменты для этого и каркас (supervisor/gen_server/...). Остальное сам)
Потому что BEAM использует потоки ОС и работает над ними, используя асинхронный подход в каждом потоке и довольно сложный шедулер, реализуя аналог корутин + недавно, вроде как, стал более стабилен JIT BEAM
Так же потому, что то, что должно упасть/подняться (основной концепт OTP), должно сделать это максимально быстро, с восстановлением стейта и коммуникаций.
Ещё не пробовал, но это действительно круто!
Ну что можно ожидать от компании, которая делает вот такие потешные "фичи" https://www.cnews.ru/news/top/2023-07-14_ushla_tselaya_epohawindows_bolshe