Вполне можно было взять и in-memory хранилище. В нашем случае мы взяли очереди, потому что они логически подходят под задачу, поднимаются кликами мышкой и стоят $10 в месяц :)
Могу рассказать только о том, что видно на сайте, но не о внутренних алгоритмах отсева, иначе этим воспользуются люди, которые продают накрутки. Попробуйте поискать «накрутка голосов мисс россия», например, есть вот такие ребята http://jet-s.ru/blog/konkurs-miss-rossija-pomozhem-vyigrat. Кроме них мы видели с десяток видео, как формировать POST-запросы к предыдущим формам голосования.
О видимых способах отсева:
Убрали обратную связь при голосовании. Это лишает тех, кто тыкает в сайт понимания работает их способ или нет. Они посылают запросы и мы всегда отвечаем, причем мгновенно, что их голос будет учтен. Если бы счетчик обновлялся сразу, то подобрать способ обхода защиты было бы проще.
Проверка по IP. Это, конечно, очень простое ограничение, но не бесполезное.
Recaptcha. Да, мы все знаем о сервисах ручного «взлома» любой капчи :)
Аутентификация через аккаунт в соц. сети. Да, мы в курсе, что аккаут в соц. сети стоит 3-5 рублей за штуку.
«Магия» анализа на клиенте и на сервере, здесь подробностей не будет
Я понимаю, что не приятно читать о своей работе в таком ключе. К сожалению, с этим в данный момент уже ничего нельзя сделать.
Могу заверить, что проект сделали хорошо и своей работой я горжусь. Всё, что написано о «прошлом» проекта я знаю со слов организаторов. Видимо так они видели предыдущее сотрудничество.
если «старую архитектуру» залили бы нормальной железкой
Добавить железку… :) Именно такого решения и ждали заказчики? Текущая стоимость в 3 раза дешевле, чем тот сервер, который якобы держал нагрузку и проблем не вызывал.
Ребята, ну серьезно, заказчик забрал у вас контракт не потому что всё было круто, быстро и все были довольны. Разве не так?
Но вот утверждать, что ваши соседи по индустрии лаптями едят
Где такое было? Жду цитату из статьи и готов взять свои слова обратно, если там есть оскорбление.
Действительно, это можно считать за опечатку. Плекс это панель, но с возможностью менять код. Например, когда во время конкурса запускается голосование, вы заходите в «CMS», открываете PHP-файл и открываете голосование через веб-интерфейс.
Реально описал выше в комментарии. Если коротко: программный комитет конкурса дал на это разрешение и сказал, что на пользователей это никак не повлияет. Мы тоже не увидели проблем с этим решением и сделали так как сделали.
Непонятно другое — каков мотив реализации именно на микросервисах.
Коротко описал в статье, вот выдержка:
Для новой архитектуры мы взяли за основу идеи, которые бы привели к достижению бизнес-целей:
Разделить приложение на (микро)ответственности.
Каждая часть будет идеально выполнять свою роль.
Каждая часть будет сама заботиться о масштабировании.
Тотальная автоматизация.
Более длинно в другой статье в блоге по более глобальному проекту http://blog.byndyu.ru/2016/11/it.html. Понятно, что конкурс не имеет много бизнес-логики, но три части четко выделялись из монолита, что мы и использовали.
Микросервисы недешевы и разрабочикам очень полезно знать, что их окупает.
Это точно! Одна из причин почему мы выбрали микросервисы — у нас есть достаточный опыт, чтобы силами двух человек за 4 недели переделать весь проект на новую архитектуру. Если мы только читали о микросервисах, то переход на них был бы более рискованный, чем дробление легаси-монолита.
довод в пользу хорошего проектирования, а не микросервисов
Да, именно так. Перед нами стоял выбор: дробить старую систему или написать всё заново. У менять не иллюзий на тему «давайте перепишем всё с нуля!!!111111», подробно на эту тему писал здесь http://blog.byndyu.ru/2014/01/blog-post_8.html. Скажу больше, обычно мы не переписываем всё с нуля, т.к. это рисковано и экономически неоправдано. Но конкретно в этом случае мы посчитали, что надо переписывать всё с нуля. Причин было много: плохая архитектура, очень слабо написан front-end, CMS и, самое главное, не много бизнес-логики.
пользователи тоже потеряли обратную связь со всеми вытекающими
Перед принятием решения мы спросили у программного коммитета, который занимается конкурсом десяток лет, допустимо ли показывать инкремент голосования с задержкой. Заказчики сказали, что да, это приемлемо. Тогда мы приняли решение сделать так, как сделали, иначе искали бы другие пути.
селективное горизонтальное масштабирование, когда с одной стороны компоненты нагружены сильно неравномерно
Это и имеется ввиду. Просто никто не говорит «селективное горизонтальное...».
о таком анализе для конкурса «Мисс Россия» в статье ничего нет — только готовое решение
Была надежда, что вы разберетесь с тремя простыми ответственностями на схеме, их границами и способами масштабирования. Пояснять подробнее не планировал.
И насколько это дешевле по сравнению с (хорошо спроектированной) монолитной системой?
Покажите мне хорошо спроектированную монолитную систему и я смогу сравнить.
вы ее порвали не только и столько для ботоводов, сколько для обычных пользователей
Видимо вам лучше знать что и зачем мы сделали. Не буду портить монолог.
Что предлагаете? Рассказать пользователям, что их голос отправлен в очередь? :)
Если серьезно, но их голос будет учтен в среднем в течение 15 секунд, а счетчик сайта обновится через час, так что мы их не обманываем. Ну а если это бот пришел накручивать, то ему без разницы какое сообощение.
С каких это пор собственно масштабируемость — «проблема монолита»?
Горизонтальное масштабирование — это проблема монолита.
Неудачно спроектированное будет плохо масштабироваться независимо от «монолитности» или «микросервисности»
Это точно :)
Необходимость селективного горизонтального масштабирования, оправдывающего внесение дополнительных межсервисных коммуникаций, не показана.
Каждый из трех сервисов масштабируется независимо горизонтально и вертикально. Чтобы увидеть необходимость приведу пример, когда у нас забилась очередь (Якутия активно пошла голосовать, они очень дружные) мы потянули ползунок и докинули сервисов обработки голосов.
«Независимые» микросервисы с общей базой данных — это хуже монолита по построению, в такой конфигурации успешно объединены проблемы и устранены достоинства обоих подходов.
Об общей базе я написал, видимо не достаточно подробно. В данном случае база это не совсем база. Это продажа юнитов к хранилищу. По сути в этом хранилище три «СУБД», но подписка на одну облачную «БАЗУ». Обновление и масштабирование можно сделать независимым, но для этого надо купить три подписки на облачную базу, что в случае этого проекта будет неоправданными расходами. А вообще мы обычно делаем каждому микросервису своё хранилище и DWH для аналитики по всем СУБД.
Про «автономность» тоже одна реклама.
Здесь что-то про эмоции, не понял вопрос.
Проблема-то в том, что вариант использования с голосованием накроется медным тазом
Вы либо не захотели разобраться, либо решили потроллить. В любом случае жду конкретных вопросов, не готов разделять с вами эмоции.
Некоторые инструменты сначала возникают непонятно зачем
Если это так, то надо заранее выяснить, что мы не знаем Зачем, поэтому давайте просто прикольную штуку сделаем. В этом случае бизнес-целей нет и делается продукт для удовольствия. Тогда и оценка результата будет другой.
Ценность анализа в том, чтобы выявить и цели или их отсутсвие.
порасспрашивать её, зачем, какие практики будут окружать эту кнопку
Так и делаем. Я не отметаю никаких идей пользователей, видимо не смог донести это в тексте статьи.
Я пообщался с коллегами из Озона и вот что они ответили:
В данном случае сложно посчитать сколько бы стоила доставка конктретного товара в заказе, ведь в стоимость доставки формируется из разных составляющих и считается на заказ целиком. Например, если доставка заказа из 10 книг в Хабаровск стоила 1000 руб., и 1 из них оказалось бракованной, то как посчитатать стоиимость доставки этой одной книги? по весу, по габаритам? а если эта книга не проходит порог минимальной стоимости заказа? У некоторых доставщиков есть скидка за объем, в случае с доставкой 10 книг скидка будет, а в случае с 1 книгой уже нет, т.е стоимость доставки будет выше. Это учитывать? В общем решение вопроса с возвратом денег за доставку бракованного товара получается не простым. Несмотря на это мы всегда идем навстречу клиенту — как правило наш CRM дает бесплатную доставку или компенсацию в виде баллов.
Я пообщался с коллегами из Озона и вот что они ответили:
Средний срок доставки в Нск 6 дней, в зависимоти от способа и дня недели. Город Новосибирск в ближайшем будущем будет подключен для комплектации со склада в Екатеринбурге и срок доставки сократится. Что касается упаковки, то мы работаем и над поиском новых материалов для упаковки и новых технологий. Например, если в заказе 1 книга, то сейчас используется такой вид коробки (так называемый гофра короб мэйлер), который сохраняет углы книги от повреждений во время транспортировки
Я пообщался с коллегами из Озона и вот что они ответили:
Средний срок доставки в Нск 6 дней, в зависимоти от способа и дня недели. Город Новосибирск в ближайшем будущем будет подключен для комплектации со склада в Екатеринбурге и срок доставки сократится. Что касается упаковки, то мы работаем и над поиском новых материалов для упаковки и новых технологий. Например, если в заказе 1 книга, то сейчас используется такой вид коробки (так называемый гофра короб мэйлер), который сохраняет углы книги от повреждений во время транспортировки
Да, согласен, что справедливо была бы замена товара и бесплатная доставка замены. К сожалению, я не могу на это повлиять :) Попробуйте написать в Озон напрямую была бы замена товара и бесплатная доставка замены.
Могу рассказать только о том, что видно на сайте, но не о внутренних алгоритмах отсева, иначе этим воспользуются люди, которые продают накрутки. Попробуйте поискать «накрутка голосов мисс россия», например, есть вот такие ребята http://jet-s.ru/blog/konkurs-miss-rossija-pomozhem-vyigrat. Кроме них мы видели с десяток видео, как формировать POST-запросы к предыдущим формам голосования.
О видимых способах отсева:
Могу заверить, что проект сделали хорошо и своей работой я горжусь. Всё, что написано о «прошлом» проекта я знаю со слов организаторов. Видимо так они видели предыдущее сотрудничество.
Добавить железку… :) Именно такого решения и ждали заказчики? Текущая стоимость в 3 раза дешевле, чем тот сервер, который якобы держал нагрузку и проблем не вызывал.
Ребята, ну серьезно, заказчик забрал у вас контракт не потому что всё было круто, быстро и все были довольны. Разве не так?
Где такое было? Жду цитату из статьи и готов взять свои слова обратно, если там есть оскорбление.
Коротко описал в статье, вот выдержка:
Для новой архитектуры мы взяли за основу идеи, которые бы привели к достижению бизнес-целей:
Более длинно в другой статье в блоге по более глобальному проекту http://blog.byndyu.ru/2016/11/it.html. Понятно, что конкурс не имеет много бизнес-логики, но три части четко выделялись из монолита, что мы и использовали.
Это точно! Одна из причин почему мы выбрали микросервисы — у нас есть достаточный опыт, чтобы силами двух человек за 4 недели переделать весь проект на новую архитектуру. Если мы только читали о микросервисах, то переход на них был бы более рискованный, чем дробление легаси-монолита.
Да, именно так. Перед нами стоял выбор: дробить старую систему или написать всё заново. У менять не иллюзий на тему «давайте перепишем всё с нуля!!!111111», подробно на эту тему писал здесь http://blog.byndyu.ru/2014/01/blog-post_8.html. Скажу больше, обычно мы не переписываем всё с нуля, т.к. это рисковано и экономически неоправдано. Но конкретно в этом случае мы посчитали, что надо переписывать всё с нуля. Причин было много: плохая архитектура, очень слабо написан front-end, CMS и, самое главное, не много бизнес-логики.
Перед принятием решения мы спросили у программного коммитета, который занимается конкурсом десяток лет, допустимо ли показывать инкремент голосования с задержкой. Заказчики сказали, что да, это приемлемо. Тогда мы приняли решение сделать так, как сделали, иначе искали бы другие пути.
Это и имеется ввиду. Просто никто не говорит «селективное горизонтальное...».
Была надежда, что вы разберетесь с тремя простыми ответственностями на схеме, их границами и способами масштабирования. Пояснять подробнее не планировал.
Покажите мне хорошо спроектированную монолитную систему и я смогу сравнить.
Видимо вам лучше знать что и зачем мы сделали. Не буду портить монолог.
Если серьезно, но их голос будет учтен в среднем в течение 15 секунд, а счетчик сайта обновится через час, так что мы их не обманываем. Ну а если это бот пришел накручивать, то ему без разницы какое сообощение.
Горизонтальное масштабирование — это проблема монолита.
Это точно :)
Каждый из трех сервисов масштабируется независимо горизонтально и вертикально. Чтобы увидеть необходимость приведу пример, когда у нас забилась очередь (Якутия активно пошла голосовать, они очень дружные) мы потянули ползунок и докинули сервисов обработки голосов.
Об общей базе я написал, видимо не достаточно подробно. В данном случае база это не совсем база. Это продажа юнитов к хранилищу. По сути в этом хранилище три «СУБД», но подписка на одну облачную «БАЗУ». Обновление и масштабирование можно сделать независимым, но для этого надо купить три подписки на облачную базу, что в случае этого проекта будет неоправданными расходами. А вообще мы обычно делаем каждому микросервису своё хранилище и DWH для аналитики по всем СУБД.
Здесь что-то про эмоции, не понял вопрос.
Вы либо не захотели разобраться, либо решили потроллить. В любом случае жду конкретных вопросов, не готов разделять с вами эмоции.
Если это так, то надо заранее выяснить, что мы не знаем Зачем, поэтому давайте просто прикольную штуку сделаем. В этом случае бизнес-целей нет и делается продукт для удовольствия. Тогда и оценка результата будет другой.
Ценность анализа в том, чтобы выявить и цели или их отсутсвие.
Так и делаем. Я не отметаю никаких идей пользователей, видимо не смог донести это в тексте статьи.