Comments 33
Какой-то зоопарк для такого простого сервиса.
Почему бы не ипользовать наиболее удобный инструмент для каждой задачи? В целом DDD на это и ориентирован, и это куда лучше возьни с монолитом и вебсокетами на руби.
По микросервису на каждый из 10 запросов в сутки — это же наверное удобнее в поддержке и разработке? Всего 1000 заказов в сутки, но языков я уже насчитал 5 (ruby, node, clojure, python, go).
Надо вебсокеты — бери и пили монолит на ноде. Хотя я уверен, что и long-polling'a на jquery и рельсе с головой хватит.
Короче, я так понял, компания не любит легких решений, палит из пушки по вообразимому хайлоаду и каждый пишет на том, на чем хочет.
Надо вебсокеты — бери и пили монолит на ноде. Хотя я уверен, что и long-polling'a на jquery и рельсе с головой хватит.
Короче, я так понял, компания не любит легких решений, палит из пушки по вообразимому хайлоаду и каждый пишет на том, на чем хочет.
Если не хочешь иметь отдельных ios/android разработчиков с соответсвующими языками, а хочешь общий интерфейс для web и мобильного приложения, то берешь react/react-native, который на js и автоматом тянет ноду.
Потом у тебя становится больше тысячи клиентов, работающих друг с другом и ты хочешь знать, как лучше совмещать их потребности — нужен анализ данных и тут же появляется питон. Неужели переписать numphy на руби было бы проще?
Какие-то задачи становятся очень высоконагруженными и хочется их распараллелить — появляется go, как наиболее подходящий для этого язык. В rails сообществе не просто так появилась реализация вебсокетов AnyCable, с бэком на go, руби для подобного просто не годится.
Из всего вышеперечисленного мне только кложа непонятна, но может там что-то хорошо описывающееся функциональщиной крутится.
Потом у тебя становится больше тысячи клиентов, работающих друг с другом и ты хочешь знать, как лучше совмещать их потребности — нужен анализ данных и тут же появляется питон. Неужели переписать numphy на руби было бы проще?
Какие-то задачи становятся очень высоконагруженными и хочется их распараллелить — появляется go, как наиболее подходящий для этого язык. В rails сообществе не просто так появилась реализация вебсокетов AnyCable, с бэком на go, руби для подобного просто не годится.
Из всего вышеперечисленного мне только кложа непонятна, но может там что-то хорошо описывающееся функциональщиной крутится.
Какие-то задачи становятся очень высоконагруженными и хочется их распараллелить — появляется go, как наиболее подходящий для этого язык.А какие задачи у вас становятся «высоконагруженными»? И что значит «высоконагруженными»?
Это вы меня спрашиваете? Я лично go не использую )
Хотя какой-нибудь общий сервис авторизации для микросервисной архитектуры начал бы писать на нем, скорее всего. Или чатик, или балансир запросов к чему-нибудь. Вариантов много.
Хотя какой-нибудь общий сервис авторизации для микросервисной архитектуры начал бы писать на нем, скорее всего. Или чатик, или балансир запросов к чему-нибудь. Вариантов много.
У нас в сутки выполняется 1000 заказов. Но нужно понимать, что хитов у нас гораздо больше. Суммарная медианная загрузка балансировщиков в районе 100rps. Да, половина из этого статика, но остальное — это заходы пользователей: работа с личным кабинетом, подпиской; различные акции, лендинги и тд. Перед нами стояла задача собирать аналитику по каждому действию пользователя как на сайте, так и в мобильном приложении и складывать это в нашу аналитическую базу. Мы взяли на клиентах решение на базе snowplow, допилили его под свои нужды, а в качестве бекенда написали простой сервис на Go, цель которого валидировать и обрабатывать поступающие данные и класть в базу в нужном формате. Ruby для этого по нашим тестам не подходил, поэтому выбрали go. Нагрузка тут не при чём, просто под конкретную задачу выбрали конкретный инструмент.
Я думаю, классический вопрос: «А почему не элексир?»
Какие-то preformance тесты проводились?
Сможете написать что-то на подобии habrahabr.ru/post/351012 по своему выбору?
Какие-то preformance тесты проводились?
Сможете написать что-то на подобии habrahabr.ru/post/351012 по своему выбору?
На момент выбора эликсир не рассматривался как production-ready. Перфоманс тесты проводили, но по конкретному кейсу написать настолько подробно уже не сможем. Однако, в планах стоит написать подробную статью про переход с нативных приложений на react native: на что смотрели, как тестировали, как и почему делали выбор.
… смотрите не ужасайтесь, некоторое время назад я изучал Qlean по просьбе потенциального конкурента, и тогда мне показалось что эта компания ради компании…
Так часто выглядят проекты мажоров, в хорошем смысле этого слова, и разводил, в плохом. Компания делается нарочито правильно и модно с точки зрения менеджмента оной, разводилам так легче привлекать инвестиции и отмазываться потом, а мажоры просто верят что так правильно и наверняка взлетит (и иногда оно действительно взлетает, но очень редко)…
Не знаю что у них сейчас, но этот пост, он «каг-бэ намекае»
Так часто выглядят проекты мажоров, в хорошем смысле этого слова, и разводил, в плохом. Компания делается нарочито правильно и модно с точки зрения менеджмента оной, разводилам так легче привлекать инвестиции и отмазываться потом, а мажоры просто верят что так правильно и наверняка взлетит (и иногда оно действительно взлетает, но очень редко)…
Не знаю что у них сейчас, но этот пост, он «каг-бэ намекае»
Расскажите ещё про аналитику, мне кажется, она у вас достаточно интересная.
Что-то странное происходит в королевстве Qlean. За 6 месяцев по данным similarweb посещаемость сайта упала в 10 раз! Similarweb так сильно ошибаться не может.
Сейчас основной трафик — прямые заходы, походу закончились деньги на рекламу ((
И да, на 123k визитов в месяц 30 микросервисов / 70 виртуалок — явно многовато)
Да и на 1.5 млн визитов в месяц достаточно 1 выделенного сервера, и Ruby on Rails прекрасно это тянет.
Спасибо за годный комментарий.
На самом деле тут очень интересный опыт, который, возможно, достоин отдельного поста. В 2017 году мы очень экстенсивно развивались: запустили несколько городов, жгли кучу денег на маркетинг, скидки, акции, даже пробовали рекламу на ТВ. В какой-то момент мы заигрались и не сразу поняли, что результаты довольно грустные: да, у нас стабильно росла пользовательская база, мы регулярно отмечали рекорды по количеству уборок, но при этом падали когорты, средний чек и, вообще, всё что касалось юнит экономики. В итоге, в ноябре приняли решение что пока низкий сезон (в январе-марте традиционно меньше уборок) мы займёмся работой над ошибками: автоматизируем то что не было автоматизировано, оптимизируем операционку, настроим сегменты и поймём что кому можно предлагать. Сейчас мы опять вкладываемся в маркетинг, но теперь у нас гораздо больше опыта, знаний и понимания того чего мы хотим и как этого достигнуть. В итоге, оглядываясь назад, мы воспринимаем эту ошибку как очень дорогой, но ценный опыт.
Про микросервисы и выделенный сервер — тут я не вижу связи. Суммарная вычислительная мощность всей нашей системы небольшая и весь наш парк сервисов спокойно поместится на 3 сервера (третий для резервирования). Такое количество сервисов связано не с нагрузкой, а с логическим делением на какие-то небольшие независимые бизнес процессы: crm, найм исполнителей, аналитика, оплата/создание заказа и тд, плюс разделение на front и back.
На самом деле тут очень интересный опыт, который, возможно, достоин отдельного поста. В 2017 году мы очень экстенсивно развивались: запустили несколько городов, жгли кучу денег на маркетинг, скидки, акции, даже пробовали рекламу на ТВ. В какой-то момент мы заигрались и не сразу поняли, что результаты довольно грустные: да, у нас стабильно росла пользовательская база, мы регулярно отмечали рекорды по количеству уборок, но при этом падали когорты, средний чек и, вообще, всё что касалось юнит экономики. В итоге, в ноябре приняли решение что пока низкий сезон (в январе-марте традиционно меньше уборок) мы займёмся работой над ошибками: автоматизируем то что не было автоматизировано, оптимизируем операционку, настроим сегменты и поймём что кому можно предлагать. Сейчас мы опять вкладываемся в маркетинг, но теперь у нас гораздо больше опыта, знаний и понимания того чего мы хотим и как этого достигнуть. В итоге, оглядываясь назад, мы воспринимаем эту ошибку как очень дорогой, но ценный опыт.
Про микросервисы и выделенный сервер — тут я не вижу связи. Суммарная вычислительная мощность всей нашей системы небольшая и весь наш парк сервисов спокойно поместится на 3 сервера (третий для резервирования). Такое количество сервисов связано не с нагрузкой, а с логическим делением на какие-то небольшие независимые бизнес процессы: crm, найм исполнителей, аналитика, оплата/создание заказа и тд, плюс разделение на front и back.
Спасибо за развернутый ответ)
У меня вопрос только в целесообразности микросервисов, как следствие зоопарк языков, сложности с оркестровкой, логированием, деплоем, когда все тоже самое может делать монолит.
Например мне не ясен смысл отдельного микросервиса для оплаты.
Добавление оплаты в основном сервисе — это 1-2 контроллера, 1 gem, config, несколько полей в базе, несколько env значений окружения. Всё. А вот в отдельном сервисе придется делать дополнительно к этому:
— config
— подгрузку .env
— deploy
— логирование
— отлов ошибок
— модель Order
— config database.yml
— ORM
etc
А если все это еще и на отдельном языке, то список «дополнительного» становится еще длиннее.
Я понимаю, зачем, например, Lenta делает микросервис для отдачи feed новостей на мобильные. У них во время каких-то критичных новостей и событий очень сильный пик нагрузки. А вот зачем вам — не понимаю. Данные по нагрузке приводил как раз к тому, что Rails вашу нагрузку держат без напряга, даже без горизонтального масштабирования.
Но это холивар последний нескольких лет и он явно выходит за рамки этой статьи и тем более комментов)
У меня вопрос только в целесообразности микросервисов, как следствие зоопарк языков, сложности с оркестровкой, логированием, деплоем, когда все тоже самое может делать монолит.
Например мне не ясен смысл отдельного микросервиса для оплаты.
Добавление оплаты в основном сервисе — это 1-2 контроллера, 1 gem, config, несколько полей в базе, несколько env значений окружения. Всё. А вот в отдельном сервисе придется делать дополнительно к этому:
— config
— подгрузку .env
— deploy
— логирование
— отлов ошибок
— модель Order
— config database.yml
— ORM
etc
А если все это еще и на отдельном языке, то список «дополнительного» становится еще длиннее.
Я понимаю, зачем, например, Lenta делает микросервис для отдачи feed новостей на мобильные. У них во время каких-то критичных новостей и событий очень сильный пик нагрузки. А вот зачем вам — не понимаю. Данные по нагрузке приводил как раз к тому, что Rails вашу нагрузку держат без напряга, даже без горизонтального масштабирования.
Но это холивар последний нескольких лет и он явно выходит за рамки этой статьи и тем более комментов)
Вы простите за нетехнический отзыв, но 5 часов на регулярную (еженедельную) уборку квартиры ставят крест на вашем сервисе для нашей семьи. :-( Тут уже никакие промо-коды не помогут...
5 часов мы обычно выделяем на большую трехкомнатную квартиру. Чтобы прийти к «стандарту» в 5 часов, мы сначала накопили данные о том, сколько в среднем занимает уборка трешки. Регулярная уборка должна постепенно снижать это время, потому что клинер учится наводить порядок именно так, как вам нужно, и со временем делает это быстрее.
Не соглашусь с вами. У нас много лет приходила уборщица убирать квартиру 100м2.
Два раза в неделю часа по 4. Это со стиркой, сушкой белья, глажкой.
И не было разделения на генеральная уборка или нет. Просто если весна — то мылись окна, не все за раз, а по одному за приход. Когда-то мылся шкаф, когда-то холодильник. Когда-то чистился диван. Зато всегда чисто)
Так что 4 часа, особенно если есть ребенок, на регулярную уборку — IMHO это нормально.
Два раза в неделю часа по 4. Это со стиркой, сушкой белья, глажкой.
И не было разделения на генеральная уборка или нет. Просто если весна — то мылись окна, не все за раз, а по одному за приход. Когда-то мылся шкаф, когда-то холодильник. Когда-то чистился диван. Зато всегда чисто)
Так что 4 часа, особенно если есть ребенок, на регулярную уборку — IMHO это нормально.
4 часа на 100 квадратов + стирка/сушка/глажка vs. 5-6 часов на 70 кв.м. только регулярная уборка. По-моему, есть разница...
В неделю: 8 часов на 100м2 || 5-6 часов на 70м2 — не такая уж и разница большая
И еще надо учесть, что в нашем случае квартира в целом чистая, потому что убиралась 3-4 дня назад. Думаю, что Qlean неоднократно сталкивался с не очень чистыми квартирами, которые быстро не уберешь. Представьте себе 70м2, которые не убирали полгода?) Отсюда и запас по прочности + как правильно выше отметили, время на знакомство, и изучение, где что и как.
И еще надо учесть, что в нашем случае квартира в целом чистая, потому что убиралась 3-4 дня назад. Думаю, что Qlean неоднократно сталкивался с не очень чистыми квартирами, которые быстро не уберешь. Представьте себе 70м2, которые не убирали полгода?) Отсюда и запас по прочности + как правильно выше отметили, время на знакомство, и изучение, где что и как.
Хм, если у вас эти два раза в неделю задачи по уборке вообще не пересекаются (считаем это за одну уборку, а не за две с некоторыми отличиями) – то это тоже очень долго, ИМХО. Я вот не представляю для нас как это вообще может работать. Разве что все уходят на работу на целый день и никого в квартире нет.
Ну да. В нашем случае всегда так и было)
Пришел вечером домой и чисто)) Приятно)
Пришел вечером домой и чисто)) Приятно)
Можно вызвать на утро, отдать ключи и попросить кинуть их в почтовый ящик или оставить консьержу. Это без дополнительных затрат. Плюс есть услуги по забору и доставке ключей.
Сидеть над клинером нет нужды, на качество работы это не влияет.
Сидеть над клинером нет нужды, на качество работы это не влияет.
Спасибо за обзор, статья легко читается, и интересно! Вопрос вот в чем, я, наверное, не уловил идею. То есть при любом изменении в заказах (т.е. отказался исполнитель, отказался заказчик) происходит глобальный пересчет всего? И правильно ли я понял, задача в том, чтобы оптимально распределить исполнителей между заказчиками? Спасибо)
Происходит пересчет, но не всего.
Если отказался исполнитель, то нужно подобрать нового. Изначально, когда заказ создался, ему подбирается набор подходящих исполнителей и автоматически назначается лучший. Если он отказался, то подбирается следующий и т.д.
Если заказчик перенес уборку, то исполнитель слетает с заказа (если у него есть другой в это время), либо остается на заказе. Если исполнитель слетел, то подбираем следующего, как написано выше.
Если заказчик отказался, то никого искать не нужно)))
Да, задача в том, чтобы оптимально распределить ВСЕ заказы без участия нашего колл-центра.
Если отказался исполнитель, то нужно подобрать нового. Изначально, когда заказ создался, ему подбирается набор подходящих исполнителей и автоматически назначается лучший. Если он отказался, то подбирается следующий и т.д.
Если заказчик перенес уборку, то исполнитель слетает с заказа (если у него есть другой в это время), либо остается на заказе. Если исполнитель слетел, то подбираем следующего, как написано выше.
Если заказчик отказался, то никого искать не нужно)))
Да, задача в том, чтобы оптимально распределить ВСЕ заказы без участия нашего колл-центра.
Прошу прощения, но более 25 человек — это сколько? 25 с половиной?
О, 25 (поправка, 27) чел уже мало! Они еще ищут moikrug.ru/vacancies/1000041413
чтобы поддерживать монстра, которого наворотили. Красавцы, давайте выходите уже на уровень «каждому отдельному клиенту по микросервису (или даже 2)».
чтобы поддерживать монстра, которого наворотили. Красавцы, давайте выходите уже на уровень «каждому отдельному клиенту по микросервису (или даже 2)».
Сколько гневных комментов… Ничего плохого в разделении на сервисы при такой не большой посещаемости нет. И то что два человека на сервис, в этом тоже есть свои плюсы. С узкой ответственностью можно глубже «нырнуть». Если процесс коммуникации хороший, то вероятно качество каждого сервиса будет выше и системы в целом выше.
Sign up to leave a comment.
Что стоит за чистотой в вашей квартире, или препарация Qlean