Ого, да тут целый дисс на меня и мое выступление в позапрошлом году! Придется ответ писать, что поделать...
Почитаю попозже, ибо многабукав, а я только-только проснулся. В любом случае, автору спасибо.за мнение (каким бы оно ни было) В спорах пождается истина.
Китайцы тоже начали с копирования. Дерьмового, сырого и кривого. Но они учились, и вырастили своих инженеров на этом. Вы же предлагаете даже не учиться. Совок делал копии тоже кривые, но если бы не закрытие "копирующих" НИИ - сейчас могло бы (насколько "бы" применимо к истории) быть лучше
Шаттл, насколько я помню, зажигался от искр, которые сыпались под соплами, чтобы поджечь выходящий газ. Не палка, конечно, но дешево, сердито и эффективно.
А между тем, это лишь философское наблюдение, записанное в единственно доступной массам человеков на тот момент форме - религиозной. Но подрыв жоп в виде минусов впечатляет.
Контроль четности я видел на военной советской технике родом из 70-80-х. А если учесть что существенная ее часть подсмотрена у IBM, то контроль четности очень стар и распространен в этих ваших айти.
Если бы на Хабре действительно были дискуссии - то вы правы. Но опыт показывает, что тут уровень дискуссии очень быстро скатывается до уровня остального интернета. А раз так, то зачем ходить сраться в несколько мест? Достаточно твитера и фейсбука
heartbeat-ы в кролике тоже нам попили крови, ага. Мне больше нравится слово "пульс", т.к. печатать меньше :) Нужно в потоке обработки что-нибудь дернуть в кролике, какой-нибудь статус проверить, тогда отошлется пульс. А если забрал сообщение и долго процессишь, то драйвер порвет соединение. Большая часть клиентов кролика построена на либе rabbitmq-c, а она не имеет метода автоматического асинхронного "пульсирования". Отсюда поведение в ноде, питоне и даже 1С - такое
Порядок сообщений возникает, когда например у вас на основании каких-то статусов заказов что-то происходит в бизнесе. Клиент создал заказ, клиент поменял заказ, клиент отменил заказ, клиент оплатил заказ.
Так вот, оплата может быть как до отмены, так и после. Причем это ПОСЛЕ может случиться и в реальном мире (действительно сначала отменил, а потом оплатил) так и из-за сбоев в сервисах. На каждый из случав нужна разная реакция бизнеса. Если в event-driven логика завязана на порядок сообщений - вас ждут проблемы. Это не масштабируется.
Еще пример: есть одна очередь, в ней порядкозависимые события. Если у нас один воркер ее разгребает - все хорошо. но вот он перестал справляться. Мы не можем добавить еще один на эту же очередь, поскольку теперь какое сообщение попадет в обработку быстрее №1 или №2? Пусть воркер А почему-то долго обрабатывает сообщение №1 (база тупит, сеть залагала, мало ли). Воркер Б получает сообщение 2, которое не может наступить раньше, чем сообщение 1. Но про сообщение 1 то воркер не знает ничего. И о том как оно обработано тоже (транзакция воркера А еще не завершена).
Придется масштабировать не воркерами, а очередями. Например была 1 очередь на все магазины, стало 20 очередей по числу магазинов. Ну и вообще, ухищрений и велосипедов связанных с обеспечением идемпотентности, порядка, throttling - очень много возникает.
А сколько классных глюков несет эта архитектура (как и любая другая распределенная), когда порядок сообщений сбивается, или когда оно доставлено не во все места, куда должно... там столько веселья кроется, что синхронные проблемы "сервис недоступен" покажутся раем.
То, что о чистоплотных компаниях не слышно - вина чистоплотных компаний. На Хабр написать - недорого стоит. А так да, в госсекторе ценник умножается на 5 просто потому, что так можно. Грусть-печаль и вот это все. А было бы много имен на рынке, было бы сложнее делать конкурсы под откат
Странно, что никто не написал до сих пор: "азазаза у вас там линукс, и байкал - это сертифицированный ARM, это не отечественное, вы просто бирки наклеили". Взрослеем что-ли?
Ого, да тут целый дисс на меня и мое выступление в позапрошлом году! Придется ответ писать, что поделать...
Почитаю попозже, ибо многабукав, а я только-только проснулся. В любом случае, автору спасибо.за мнение (каким бы оно ни было) В спорах пождается истина.
Прикольно. Но маловато. Кишочков бы еще, побольше, побольше! Даешь geek porn!
"Даже википедия пишет" это, конечно, шикарный аргумент ))))
Китайцы тоже начали с копирования. Дерьмового, сырого и кривого. Но они учились, и вырастили своих инженеров на этом. Вы же предлагаете даже не учиться. Совок делал копии тоже кривые, но если бы не закрытие "копирующих" НИИ - сейчас могло бы (насколько "бы" применимо к истории) быть лучше
Я не видел, как зажигается Союз, как?
Шаттл, насколько я помню, зажигался от искр, которые сыпались под соплами, чтобы поджечь выходящий газ. Не палка, конечно, но дешево, сердито и эффективно.
А между тем, это лишь философское наблюдение, записанное в единственно доступной массам человеков на тот момент форме - религиозной. Но подрыв жоп в виде минусов впечатляет.
Контроль четности я видел на военной советской технике родом из 70-80-х. А если учесть что существенная ее часть подсмотрена у IBM, то контроль четности очень стар и распространен в этих ваших айти.
Подождите, а как же старый-добрый контроль четности и "контрольный разряд" в регистре? Разве он не предназначен как раз и защищать от сбоя в один бит?
Хотите сказать что рынок не знает про 1С?
Если бы на Хабре действительно были дискуссии - то вы правы. Но опыт показывает, что тут уровень дискуссии очень быстро скатывается до уровня остального интернета. А раз так, то зачем ходить сраться в несколько мест? Достаточно твитера и фейсбука
Почему без морали? Разве в сети мало места сейчас, где можно отвести душу и устроить баталии с оппонентами? Зачем нужно еще одно?
Даже Марго Робби может надоесть... Так устроены человеки
heartbeat-ы в кролике тоже нам попили крови, ага. Мне больше нравится слово "пульс", т.к. печатать меньше :) Нужно в потоке обработки что-нибудь дернуть в кролике, какой-нибудь статус проверить, тогда отошлется пульс. А если забрал сообщение и долго процессишь, то драйвер порвет соединение. Большая часть клиентов кролика построена на либе rabbitmq-c, а она не имеет метода автоматического асинхронного "пульсирования". Отсюда поведение в ноде, питоне и даже 1С - такое
Порядок сообщений возникает, когда например у вас на основании каких-то статусов заказов что-то происходит в бизнесе. Клиент создал заказ, клиент поменял заказ, клиент отменил заказ, клиент оплатил заказ.
Так вот, оплата может быть как до отмены, так и после. Причем это ПОСЛЕ может случиться и в реальном мире (действительно сначала отменил, а потом оплатил) так и из-за сбоев в сервисах. На каждый из случав нужна разная реакция бизнеса. Если в event-driven логика завязана на порядок сообщений - вас ждут проблемы. Это не масштабируется.
Еще пример: есть одна очередь, в ней порядкозависимые события. Если у нас один воркер ее разгребает - все хорошо. но вот он перестал справляться. Мы не можем добавить еще один на эту же очередь, поскольку теперь какое сообщение попадет в обработку быстрее №1 или №2? Пусть воркер А почему-то долго обрабатывает сообщение №1 (база тупит, сеть залагала, мало ли). Воркер Б получает сообщение 2, которое не может наступить раньше, чем сообщение 1. Но про сообщение 1 то воркер не знает ничего. И о том как оно обработано тоже (транзакция воркера А еще не завершена).
Придется масштабировать не воркерами, а очередями. Например была 1 очередь на все магазины, стало 20 очередей по числу магазинов. Ну и вообще, ухищрений и велосипедов связанных с обеспечением идемпотентности, порядка, throttling - очень много возникает.
А сколько классных глюков несет эта архитектура (как и любая другая распределенная), когда порядок сообщений сбивается, или когда оно доставлено не во все места, куда должно... там столько веселья кроется, что синхронные проблемы "сервис недоступен" покажутся раем.
сдается мне, в компаниях, в которых такие политики безопасности, бюджеты безопасников и таймтрекерщиков - бесконечные
Вьетнам и Корею забыли
То, что о чистоплотных компаниях не слышно - вина чистоплотных компаний. На Хабр написать - недорого стоит. А так да, в госсекторе ценник умножается на 5 просто потому, что так можно. Грусть-печаль и вот это все. А было бы много имен на рынке, было бы сложнее делать конкурсы под откат
Значит надо вообще ничего не делать и экспертизу не накапливать. Верно?
Странно, что никто не написал до сих пор: "азазаза у вас там линукс, и байкал - это сертифицированный ARM, это не отечественное, вы просто бирки наклеили". Взрослеем что-ли?