Я бы сказал, что это радость от правильно организованной распределённой архитектуры, а не только rabbit :) Я не агитирую конкретно за PHP, но это популярный язык, который понятен многим читателям.
Конкретный пример: допустим, есть «облачный сервис» — таск-менеджер (или багтрекер). Пользователю по текущему тарифу разрешено создавать в нём не более 10 проектов, за каждый из которых он платит 100 рублей в месяц. От пользователя пришла входящая задача — создать новый проект. Исполняющий сервис ожидает сообщения одновременно из четырёх очередей:
A) подтверждение, что пользователь валиден, авторизован, и вообще имеет право выполнять действие project.create;
B) подтверждение, что у пользователя в данный момент не более 10 проектов;
C) подтверждение, что у пользователя на балансе вообще есть сумма не менее 100 рублей (ну или подтверждение списания 100 рублей, если так понятнее);
D) подтверждение от валидатора, что название проекта (поддомен) не содержит нецензурных или оскорбительных слов.
Только по получению сообщений об успехе из всех четырёх очередей — исполнительный сервис может приступать к фактическому созданию проекта.
Однако заметно, что достаточно получить как минимум два сообщения о НЕуспехе, например из «A» и «B», и результат из «C» и «D» нам становится неинтересен. Поскольку, напомню, процессорное время стоит денег — ожидание двух последних становится лишней работой, которая расходуется впустую — а значит впустую тратятся деньги. Уточню, что сообщения приходят в непредсказуемое время, и быстрее всех могут придти как A и B, так и например B и D, в зависимости от текущей нагрузки на тот или иной сегмент системы.
Если же мы развернём эти проверки в последовательность действий (A-B-C-D), мы удлинним всю цепочку — и снова потратим процессорные ресурсы впустую в том случае, если например A, B, C будут успешны, а D — зафэйлится. Не говоря уже о том, что приложение может потерять в «отзывчивости», визуально станет медленнее работать. Можно было бы сказать «заранее думайте о порядке действий», но это неудобно и ухудшает архитектурную простоту системы.
Это плохо, потому что:
— если например комбинация сообщений B и C уже позволяет выполнить следующий шаг бизнес-логики, то ждать сообщения из A нам смысла нет. Нет никакого способа «из коробки» поймать такую ситуацию в коде PHP.
— consume на одну из очередей означает, что процессорные ресурсы потребляются по сути на прогон пустого цикла ожидания. Нет никакого способа «из коробки» дёрнуть действие только по получению всех трёх сообщений, а пока они все не пришли — заниматься другими задачами.
Во-вторых, ack сообщений не атомарен, как например в редисе (там можно завернуть несколько действий в атомарную транзакцию). Если ваш скрипт получил сообщения из трёх очередей, сделал первому ack, второму ack, а третьему не успел — умер (в ДЦ попал метеорит) — вы получили неконсистентность данных.
В-третьих, если у вас несколько воркеров, то вам нужно сделать чтобы все три сообщения в очередях A, B и C, составляющие «смысловую тройку» по бизнес-логике, попали строго в один воркер. Никаких round-robin.
Естественно, речь идёт о высоконагруженных проектах, сопоставимых с… скажем с Вконтакте или Amazon. В проектах меньшего масштаба на всё перечисленное можно забить болт :)
Надеюсь, я достаточно подробно объяснил почему нормальный multi-consumer не так просто реализовать?
Автор, лучи добра тебе и пожелание попасть в рай без очереди :)
А вот что нам понадобилось в реальной практике и было сходу непонятно как реализовать:
— как сделать подписку по маске (каюсь, не сразу нашли звездочку и решётку);
— как сделать, когда надо чтобы оба консумера получили мессадж, и когда надо чтобы строго один консумер из N возможных;
— как сделать, чтобы консумер выполнял действие, только получив сообщения из двух и более очередей, делая ack только по получению всех и не потребляя процессорные ресурсы между этими сообщениями (multi-queue consumer)
Блин, ну вот что за дурацкие вопросы?
Крупные проекты деплоятся ежечасно, кто-то деплоит даже каждые полчаса. Это автоматизировано и является неотъемлимой частью процесса континьюс интегрэйшен. Как правило, с использованием шелла, с исполнением скриптов (например миграций БД) на стороне сервера.
Пост, блеать, про серьёзные инструменты для разработчиков. Не валяйте дурака. Если там ssh нет — к нормальному техпроцессу разработки этот джеластик-хреноластик не прикрутить.
Без иронии, это движение в правильную сторону. Но, а) тема сисек не раскрыта, и б) ох уж эти унылые «особенности» джеластика для LAMP-стэка.
Во-первых, использовать неебическую хренотень, чтобы ручками редактировать innodb_flush_method — это за гранью добра и зла. Могу поспорить, что даже внутри команды Юми никто толком не знает, чего эта штука делает.
Во-вторых, Jelastic это инструмент для менеджмента окружений. Гораздо правильнее было бы рассмотреть кейс, когда с помощью Jelastic реализуется процесс непрерывной интеграции сайта на UMI.CMS через dev-stage-prod-окружения. Как вносятся изменения в конфигурацию, как они мигрируют по этому процессу от дева к проду. Как осуществляется деплой проекта, откат, работа с feature-branches, их тестирование и вывод в продакшен.
Интересно, а зачем акцентировать внимание именно на Германии?
Все пункты Ваших выводов, ну может быть кроме первого, 100% актуальны для России.
В России точно так же нужен компетентный человек, коммуникабельный, способный вписаться в команду, проявить заинтересованность, вести собственные проекты на гитхабе, не стесняющийся называть говнокод — говнокодом, разбирающийся (как минимум) в понятиях SOLID и CI. Всё точно так же. А где не так?
Николай, я думаю мы с Вами оба понимаем, что утверждения типа «любой сайт, независимо от платформы, внутренних особенностей или клиентской логики можно положить в облако» — не более чем marketing bullshit.
Поэтому хочется кратко и по делу, насколько я понял, по сути вы сделали следующее:
— прикрутили днс-балансер
— продублировали бэкэнды, поставив перед ними балансировщик
— отдаёте статику по CDN
— кэшируете и жмёте всё что жмётся гугловским pagespeed-ом
Ну круто, да, а база? В любом веб-проекте тормозит всегда хранилище данных. Это разрабочтикам сайта надо быть последними отморозками, чтобы сайт тормозил из-за отдачи статики.
Поставить пару модулей к nginx и прикрутить CDN — это ещё ни разу не облако и вообще задача для слабо одарённого школьника. Что вы реально сделали, чтобы обеспечить «из коробки» отказоустойчивость БД, кей-вэлью стораджей, серверов очередей, любого другого софта который может быть в проекте?
Привет, конкуренты! :)
Во-первых — респект, у вас получилось лучше, чем у Селектела.
Но есть и во что потыкать грязным пальцем:
а) вы пока не допёрли, как это продавать разным целевым аудиториям. Мониторинг нужен разный, отдельно разработчикам и отдельно «прочим гуманитариям», для совершенно разных целей и задач.
б) вы не мониторите мат, экстремизм, нелегальный контент и ссылки на него. А новые дурацкие законы РФ вполне создают спрос на это дело.
в) вы пока не понимаете, что никому нафиг не сдался тот факт, что «сервис упал». Людям нужно преждевременное уведомление о начинающемся процессе деградации, вы должны проводить анализ динамики и предоставлять клиенту выводы на его основе.
г) присоединюсь к предыдущему оратору, у вас не сказано ни слова о том, как мониторинг мониторит сам себя. Например заббикс, когда я на него последний раз смотрел, не умеет нормально кластеризоваться и переживать «смерть» любой из своих нод. Если вы это сделаете по-нормальному — будет ещё один плюсик к надёжности.
А в целом, повторюсь — респект, развивайтесь, а то мы вас догоним и перегоним :)
Как устроено масштабирование и балансировка?
Как реализован шардинг и репликация БД?
Как реализуется бэкап?
Как устроена ваша CDN?
Как обеспечивается failover при выходе какого-либо физического сервера из строя?
Как устроена защита от DDoS?
Как устроена защита от ботов?
Какова архитектура приложений в целом?
Как сишные и пхпшные сервисы общаются между собой?
Как реализуются параллельные вычисления на сложных участках?
Как реализован деплой и роллбэк, в частности при изменений структур БД?
Как управляется железная инфраструктура в датацентрах?
Как мониторите нелегальный контент?
Весь подкаст (и соответственно вся статья) — какое-то маркетинговое бла-бла на уровне студентов первого курса. Подробности давайте.
Автор, при том кто Вы и какие методологии продвигаете — не развернуть тему до конца просто стыдно. Алгоритмические метрики сложности ПО существуют годы, десятки лет. Анализаторы сложности (JDepend, PHP Depend, etc) используются в Continuos Integration в каждом мало-мальски серьёзном проекте.
Abstraction instability chart, average hierarchy heigh, cyclomatic complexity, ещё десяток основных метрик. Все цифры есть как на ладони. Ваши филосовствования нафиг никому не нужны. Берите инструменты и применяйте их на практике.
Да я вижу, у вас типично «скриптовый» образ мышления, это когда пишут приложения на PHP/Perl/etc — как скрипты, которые при каждом запросе пользователя считываются с диска, интерпретируются, лезут в базу с одними и теми же запросами и т.д.
Понимание того, что так делать не надо, приходит обычно когда начинаешь обрабатывать более 1к пользователей в секунду, а база проекта начинает измеряться сотнями миллионов объектов и расползаться по 10-20 серверам.
Посмотрел бы я на вас, если бы вы решили приджойнить к чему-нибудь табличку users с 10 миллионами пользователей, ещё с GROUP BY и ORDER BY впридачу, ага :)
Но большинство «разработчиков» до жопы ленивы, всю жизнь клали болт на своё развитие и самообучения, никогда даже рядом с такими проектами не стояли, предпочитают вместо профессионального роста дрочить на карму на хабре, и до седых волос будут считать что JOIN-ы и вся вышеперечисленная %уйня — это нормально.
Быть среди таких или думать своей башкой — вам решать.
О-о-о… Далеко пойдёте с таким подходом. Может быть, у вас приложение каждый раз заново инициализируется при каждом обращении пользователя? Этакий PHP-стайл мышления, раз мысль об оптимизации повторяющися действий кажется вам странной.
Топикстартер вроде как про развитие писал, а Вы в каменном веке застряли.
Ну я надеюсь, по крайней мере, что не будет :)
Потому что JOIN — это операция объединения данных, происходящая в оперативной памяти (а иногда и на диске), которая происходит каждый раз при вызове такого запроса. Зачем это делать? Зачем заставлять компьютер раз за разом объединять данные, когда можно их объединить один раз где-то на стороне, и хранить уже объединённые? Процессорное время стоит денег, особенно если ваше приложение работает в «облаке» на десятках компьютеров с оплатой за потребление ресурсов.
Погуглите по фразе «денормализация БД».
Потому что, в контексте отказоустойчивости, мини-кластер из двух компьютеров экономически выгоднее одного (даже более мощного), так как обеспечивает работу приложения (а значит непрерывность бизнес-процессов) при выходе из строя например блока питания или процессора одного из них.
Потому что, изначально дублируя каждый компонент приложения в двойном экземпляре, гораздо легче потом (при росте нагрузки) сделать 3-ий, 4-ый узел и так далее. Не заложив этого в фундаменте приложения, потом будет труднее.
Потому что существуют, например, физические пределы скорости жестких дисков, и распараллелить задачу требующую дисковую активность — на два (на 3, 4, 5...) физических компьютера — означает выполнить её быстрее.
Достаточно?
Годная статья, но хочу добавить: учить конкретный стек языков и технологий — вообще бесперспективное занятие. В другой задаче они будут другие. Учить надо базисные вещи, на уровне физики и математики 7 класса школы: почему память быстрее диска, почему сетевое соединение не надёжно, почему сложные выборки медленнее простых, почему целые числа быстрее дробных, почему несколько мелких файлов лучше одного большого, почему память сегментирована, почему два слабых компьютера выгоднее одного мощного, и так далее.
Владея этими базовыми пониманиями, человек никогда не будет творить %уйню типа SQL-запросов с JOIN-ами, XML-шаблонизаторов, баз данных на миллионы строк и монолитных веб-приложений :)
Хочу поделиться наблюдением о том, как использование облаков и CDN в обозримом будущем повлияет на мозги разработчиков сайтов. Которые привыкли динамически генерить страницу (по шаблону) в ответ на запрос, а потом подгружать на неё элементы дизайна. В то время как для эффективности сегодня надо наоборот максимально быстро отдать статический каркас страницы из CDN, а затем асинхронно подрузить на неё динамику от апачей.
Насколько я знаю, никто из российской топовой тройки CMS так пока не делает. А у вас как?
Конкретный пример: допустим, есть «облачный сервис» — таск-менеджер (или багтрекер). Пользователю по текущему тарифу разрешено создавать в нём не более 10 проектов, за каждый из которых он платит 100 рублей в месяц. От пользователя пришла входящая задача — создать новый проект. Исполняющий сервис ожидает сообщения одновременно из четырёх очередей:
A) подтверждение, что пользователь валиден, авторизован, и вообще имеет право выполнять действие project.create;
B) подтверждение, что у пользователя в данный момент не более 10 проектов;
C) подтверждение, что у пользователя на балансе вообще есть сумма не менее 100 рублей (ну или подтверждение списания 100 рублей, если так понятнее);
D) подтверждение от валидатора, что название проекта (поддомен) не содержит нецензурных или оскорбительных слов.
Только по получению сообщений об успехе из всех четырёх очередей — исполнительный сервис может приступать к фактическому созданию проекта.
Однако заметно, что достаточно получить как минимум два сообщения о НЕуспехе, например из «A» и «B», и результат из «C» и «D» нам становится неинтересен. Поскольку, напомню, процессорное время стоит денег — ожидание двух последних становится лишней работой, которая расходуется впустую — а значит впустую тратятся деньги. Уточню, что сообщения приходят в непредсказуемое время, и быстрее всех могут придти как A и B, так и например B и D, в зависимости от текущей нагрузки на тот или иной сегмент системы.
Если же мы развернём эти проверки в последовательность действий (A-B-C-D), мы удлинним всю цепочку — и снова потратим процессорные ресурсы впустую в том случае, если например A, B, C будут успешны, а D — зафэйлится. Не говоря уже о том, что приложение может потерять в «отзывчивости», визуально станет медленнее работать. Можно было бы сказать «заранее думайте о порядке действий», но это неудобно и ухудшает архитектурную простоту системы.
Вот конкретный пример :) Как будем решать?
Уважаемый limitium, у Вас очень поверхностный взгляд на проблему.
Во-первых, если подписываться можно, то слушать одновременно более 1 очереди (по крайней мере из PHP) нельзя. Когда PHP-скрипт повисает на consume очереди, его выполнение приостанавливается. Если мы слушаем три очереди (A, B, C), повисли на consume первой из них (A), но из внешних источников быстрее поступили сообщения во вторую (B) и третью ©, то мы так и будем тупо висеть и ждать сообщения в первой.
Это плохо, потому что:
— если например комбинация сообщений B и C уже позволяет выполнить следующий шаг бизнес-логики, то ждать сообщения из A нам смысла нет. Нет никакого способа «из коробки» поймать такую ситуацию в коде PHP.
— consume на одну из очередей означает, что процессорные ресурсы потребляются по сути на прогон пустого цикла ожидания. Нет никакого способа «из коробки» дёрнуть действие только по получению всех трёх сообщений, а пока они все не пришли — заниматься другими задачами.
Во-вторых, ack сообщений не атомарен, как например в редисе (там можно завернуть несколько действий в атомарную транзакцию). Если ваш скрипт получил сообщения из трёх очередей, сделал первому ack, второму ack, а третьему не успел — умер (в ДЦ попал метеорит) — вы получили неконсистентность данных.
В-третьих, если у вас несколько воркеров, то вам нужно сделать чтобы все три сообщения в очередях A, B и C, составляющие «смысловую тройку» по бизнес-логике, попали строго в один воркер. Никаких round-robin.
Естественно, речь идёт о высоконагруженных проектах, сопоставимых с… скажем с Вконтакте или Amazon. В проектах меньшего масштаба на всё перечисленное можно забить болт :)
Надеюсь, я достаточно подробно объяснил почему нормальный multi-consumer не так просто реализовать?
А вот что нам понадобилось в реальной практике и было сходу непонятно как реализовать:
— как сделать подписку по маске (каюсь, не сразу нашли звездочку и решётку);
— как сделать, когда надо чтобы оба консумера получили мессадж, и когда надо чтобы строго один консумер из N возможных;
— как сделать, чтобы консумер выполнял действие, только получив сообщения из двух и более очередей, делая ack только по получению всех и не потребляя процессорные ресурсы между этими сообщениями (multi-queue consumer)
Блин, ну вот что за дурацкие вопросы?
Крупные проекты деплоятся ежечасно, кто-то деплоит даже каждые полчаса. Это автоматизировано и является неотъемлимой частью процесса континьюс интегрэйшен. Как правило, с использованием шелла, с исполнением скриптов (например миграций БД) на стороне сервера.
Пост, блеать, про серьёзные инструменты для разработчиков. Не валяйте дурака. Если там ssh нет — к нормальному техпроцессу разработки этот джеластик-хреноластик не прикрутить.
Во-первых, использовать неебическую хренотень, чтобы ручками редактировать innodb_flush_method — это за гранью добра и зла. Могу поспорить, что даже внутри команды Юми никто толком не знает, чего эта штука делает.
Во-вторых, Jelastic это инструмент для менеджмента окружений. Гораздо правильнее было бы рассмотреть кейс, когда с помощью Jelastic реализуется процесс непрерывной интеграции сайта на UMI.CMS через dev-stage-prod-окружения. Как вносятся изменения в конфигурацию, как они мигрируют по этому процессу от дева к проду. Как осуществляется деплой проекта, откат, работа с feature-branches, их тестирование и вывод в продакшен.
Вот это было бы круто и по делу. А так — нет.
Все пункты Ваших выводов, ну может быть кроме первого, 100% актуальны для России.
В России точно так же нужен компетентный человек, коммуникабельный, способный вписаться в команду, проявить заинтересованность, вести собственные проекты на гитхабе, не стесняющийся называть говнокод — говнокодом, разбирающийся (как минимум) в понятиях SOLID и CI. Всё точно так же. А где не так?
Поэтому хочется кратко и по делу, насколько я понял, по сути вы сделали следующее:
— прикрутили днс-балансер
— продублировали бэкэнды, поставив перед ними балансировщик
— отдаёте статику по CDN
— кэшируете и жмёте всё что жмётся гугловским pagespeed-ом
Ну круто, да, а база? В любом веб-проекте тормозит всегда хранилище данных. Это разрабочтикам сайта надо быть последними отморозками, чтобы сайт тормозил из-за отдачи статики.
Поставить пару модулей к nginx и прикрутить CDN — это ещё ни разу не облако и вообще задача для слабо одарённого школьника. Что вы реально сделали, чтобы обеспечить «из коробки» отказоустойчивость БД, кей-вэлью стораджей, серверов очередей, любого другого софта который может быть в проекте?
Во-первых — респект, у вас получилось лучше, чем у Селектела.
Но есть и во что потыкать грязным пальцем:
а) вы пока не допёрли, как это продавать разным целевым аудиториям. Мониторинг нужен разный, отдельно разработчикам и отдельно «прочим гуманитариям», для совершенно разных целей и задач.
б) вы не мониторите мат, экстремизм, нелегальный контент и ссылки на него. А новые дурацкие законы РФ вполне создают спрос на это дело.
в) вы пока не понимаете, что никому нафиг не сдался тот факт, что «сервис упал». Людям нужно преждевременное уведомление о начинающемся процессе деградации, вы должны проводить анализ динамики и предоставлять клиенту выводы на его основе.
г) присоединюсь к предыдущему оратору, у вас не сказано ни слова о том, как мониторинг мониторит сам себя. Например заббикс, когда я на него последний раз смотрел, не умеет нормально кластеризоваться и переживать «смерть» любой из своих нод. Если вы это сделаете по-нормальному — будет ещё один плюсик к надёжности.
А в целом, повторюсь — респект, развивайтесь, а то мы вас догоним и перегоним :)
Ну не хотите по делу рассказывать — Ваше право, посмотрю презентации. Нафига только было пост писать, неясно, если вопросы вглубь не копать.
Монолит, модульная, SOA с общением напрямую, SOA с ESB, очереди сообщений?
Я видел Фотострану изнутри + по Мамбе с Федоровским общался, интересно какой путь вы избрали.
Как устроено масштабирование и балансировка?
Как реализован шардинг и репликация БД?
Как реализуется бэкап?
Как устроена ваша CDN?
Как обеспечивается failover при выходе какого-либо физического сервера из строя?
Как устроена защита от DDoS?
Как устроена защита от ботов?
Какова архитектура приложений в целом?
Как сишные и пхпшные сервисы общаются между собой?
Как реализуются параллельные вычисления на сложных участках?
Как реализован деплой и роллбэк, в частности при изменений структур БД?
Как управляется железная инфраструктура в датацентрах?
Как мониторите нелегальный контент?
Весь подкаст (и соответственно вся статья) — какое-то маркетинговое бла-бла на уровне студентов первого курса. Подробности давайте.
Abstraction instability chart, average hierarchy heigh, cyclomatic complexity, ещё десяток основных метрик. Все цифры есть как на ладони. Ваши филосовствования нафиг никому не нужны. Берите инструменты и применяйте их на практике.
Понимание того, что так делать не надо, приходит обычно когда начинаешь обрабатывать более 1к пользователей в секунду, а база проекта начинает измеряться сотнями миллионов объектов и расползаться по 10-20 серверам.
Посмотрел бы я на вас, если бы вы решили приджойнить к чему-нибудь табличку users с 10 миллионами пользователей, ещё с GROUP BY и ORDER BY впридачу, ага :)
Но большинство «разработчиков» до жопы ленивы, всю жизнь клали болт на своё развитие и самообучения, никогда даже рядом с такими проектами не стояли, предпочитают вместо профессионального роста дрочить на карму на хабре, и до седых волос будут считать что JOIN-ы и вся вышеперечисленная %уйня — это нормально.
Быть среди таких или думать своей башкой — вам решать.
Топикстартер вроде как про развитие писал, а Вы в каменном веке застряли.
Потому что JOIN — это операция объединения данных, происходящая в оперативной памяти (а иногда и на диске), которая происходит каждый раз при вызове такого запроса. Зачем это делать? Зачем заставлять компьютер раз за разом объединять данные, когда можно их объединить один раз где-то на стороне, и хранить уже объединённые? Процессорное время стоит денег, особенно если ваше приложение работает в «облаке» на десятках компьютеров с оплатой за потребление ресурсов.
Погуглите по фразе «денормализация БД».
Потому что, изначально дублируя каждый компонент приложения в двойном экземпляре, гораздо легче потом (при росте нагрузки) сделать 3-ий, 4-ый узел и так далее. Не заложив этого в фундаменте приложения, потом будет труднее.
Потому что существуют, например, физические пределы скорости жестких дисков, и распараллелить задачу требующую дисковую активность — на два (на 3, 4, 5...) физических компьютера — означает выполнить её быстрее.
Достаточно?
Владея этими базовыми пониманиями, человек никогда не будет творить %уйню типа SQL-запросов с JOIN-ами, XML-шаблонизаторов, баз данных на миллионы строк и монолитных веб-приложений :)
Хочу поделиться наблюдением о том, как использование облаков и CDN в обозримом будущем повлияет на мозги разработчиков сайтов. Которые привыкли динамически генерить страницу (по шаблону) в ответ на запрос, а потом подгружать на неё элементы дизайна. В то время как для эффективности сегодня надо наоборот максимально быстро отдать статический каркас страницы из CDN, а затем асинхронно подрузить на неё динамику от апачей.
Насколько я знаю, никто из российской топовой тройки CMS так пока не делает. А у вас как?