Как стать автором
Обновить

Комментарии 36

Какой-то зоопарк для такого простого сервиса.
Почему бы не ипользовать наиболее удобный инструмент для каждой задачи? В целом DDD на это и ориентирован, и это куда лучше возьни с монолитом и вебсокетами на руби.
По микросервису на каждый из 10 запросов в сутки — это же наверное удобнее в поддержке и разработке? Всего 1000 заказов в сутки, но языков я уже насчитал 5 (ruby, node, clojure, python, go).
Надо вебсокеты — бери и пили монолит на ноде. Хотя я уверен, что и long-polling'a на jquery и рельсе с головой хватит.
Короче, я так понял, компания не любит легких решений, палит из пушки по вообразимому хайлоаду и каждый пишет на том, на чем хочет.
Если не хочешь иметь отдельных ios/android разработчиков с соответсвующими языками, а хочешь общий интерфейс для web и мобильного приложения, то берешь react/react-native, который на js и автоматом тянет ноду.
Потом у тебя становится больше тысячи клиентов, работающих друг с другом и ты хочешь знать, как лучше совмещать их потребности — нужен анализ данных и тут же появляется питон. Неужели переписать numphy на руби было бы проще?
Какие-то задачи становятся очень высоконагруженными и хочется их распараллелить — появляется go, как наиболее подходящий для этого язык. В rails сообществе не просто так появилась реализация вебсокетов AnyCable, с бэком на go, руби для подобного просто не годится.
Из всего вышеперечисленного мне только кложа непонятна, но может там что-то хорошо описывающееся функциональщиной крутится.
Какие-то задачи становятся очень высоконагруженными и хочется их распараллелить — появляется go, как наиболее подходящий для этого язык.
А какие задачи у вас становятся «высоконагруженными»? И что значит «высоконагруженными»?
Это вы меня спрашиваете? Я лично go не использую )
Хотя какой-нибудь общий сервис авторизации для микросервисной архитектуры начал бы писать на нем, скорее всего. Или чатик, или балансир запросов к чему-нибудь. Вариантов много.
Простите, мне показалось, что вы имеете отношение к описанному в статье сервису и можете пролить свет на то, что там относится к высокой нагрузке.
У нас в сутки выполняется 1000 заказов. Но нужно понимать, что хитов у нас гораздо больше. Суммарная медианная загрузка балансировщиков в районе 100rps. Да, половина из этого статика, но остальное — это заходы пользователей: работа с личным кабинетом, подпиской; различные акции, лендинги и тд. Перед нами стояла задача собирать аналитику по каждому действию пользователя как на сайте, так и в мобильном приложении и складывать это в нашу аналитическую базу. Мы взяли на клиентах решение на базе snowplow, допилили его под свои нужды, а в качестве бекенда написали простой сервис на Go, цель которого валидировать и обрабатывать поступающие данные и класть в базу в нужном формате. Ruby для этого по нашим тестам не подходил, поэтому выбрали go. Нагрузка тут не при чём, просто под конкретную задачу выбрали конкретный инструмент.
Я думаю, классический вопрос: «А почему не элексир?»
Какие-то preformance тесты проводились?
Сможете написать что-то на подобии habrahabr.ru/post/351012 по своему выбору?
На момент выбора эликсир не рассматривался как production-ready. Перфоманс тесты проводили, но по конкретному кейсу написать настолько подробно уже не сможем. Однако, в планах стоит написать подробную статью про переход с нативных приложений на react native: на что смотрели, как тестировали, как и почему делали выбор.
… смотрите не ужасайтесь, некоторое время назад я изучал Qlean по просьбе потенциального конкурента, и тогда мне показалось что эта компания ради компании…
Так часто выглядят проекты мажоров, в хорошем смысле этого слова, и разводил, в плохом. Компания делается нарочито правильно и модно с точки зрения менеджмента оной, разводилам так легче привлекать инвестиции и отмазываться потом, а мажоры просто верят что так правильно и наверняка взлетит (и иногда оно действительно взлетает, но очень редко)…
Не знаю что у них сейчас, но этот пост, он «каг-бэ намекае»

Расскажите ещё про аналитику, мне кажется, она у вас достаточно интересная.

да, обязательно расскажем в следующей статье
image

Что-то странное происходит в королевстве Qlean. За 6 месяцев по данным similarweb посещаемость сайта упала в 10 раз! Similarweb так сильно ошибаться не может.
Сейчас основной трафик — прямые заходы, походу закончились деньги на рекламу ((

И да, на 123k визитов в месяц 30 микросервисов / 70 виртуалок — явно многовато)
Да и на 1.5 млн визитов в месяц достаточно 1 выделенного сервера, и Ruby on Rails прекрасно это тянет.
Спасибо за годный комментарий.
На самом деле тут очень интересный опыт, который, возможно, достоин отдельного поста. В 2017 году мы очень экстенсивно развивались: запустили несколько городов, жгли кучу денег на маркетинг, скидки, акции, даже пробовали рекламу на ТВ. В какой-то момент мы заигрались и не сразу поняли, что результаты довольно грустные: да, у нас стабильно росла пользовательская база, мы регулярно отмечали рекорды по количеству уборок, но при этом падали когорты, средний чек и, вообще, всё что касалось юнит экономики. В итоге, в ноябре приняли решение что пока низкий сезон (в январе-марте традиционно меньше уборок) мы займёмся работой над ошибками: автоматизируем то что не было автоматизировано, оптимизируем операционку, настроим сегменты и поймём что кому можно предлагать. Сейчас мы опять вкладываемся в маркетинг, но теперь у нас гораздо больше опыта, знаний и понимания того чего мы хотим и как этого достигнуть. В итоге, оглядываясь назад, мы воспринимаем эту ошибку как очень дорогой, но ценный опыт.

Про микросервисы и выделенный сервер — тут я не вижу связи. Суммарная вычислительная мощность всей нашей системы небольшая и весь наш парк сервисов спокойно поместится на 3 сервера (третий для резервирования). Такое количество сервисов связано не с нагрузкой, а с логическим делением на какие-то небольшие независимые бизнес процессы: crm, найм исполнителей, аналитика, оплата/создание заказа и тд, плюс разделение на front и back.
Спасибо за развернутый ответ)

У меня вопрос только в целесообразности микросервисов, как следствие зоопарк языков, сложности с оркестровкой, логированием, деплоем, когда все тоже самое может делать монолит.

Например мне не ясен смысл отдельного микросервиса для оплаты.
Добавление оплаты в основном сервисе — это 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 часа на 100 квадратов + стирка/сушка/глажка vs. 5-6 часов на 70 кв.м. только регулярная уборка. По-моему, есть разница...

В неделю: 8 часов на 100м2 || 5-6 часов на 70м2 — не такая уж и разница большая

И еще надо учесть, что в нашем случае квартира в целом чистая, потому что убиралась 3-4 дня назад. Думаю, что Qlean неоднократно сталкивался с не очень чистыми квартирами, которые быстро не уберешь. Представьте себе 70м2, которые не убирали полгода?) Отсюда и запас по прочности + как правильно выше отметили, время на знакомство, и изучение, где что и как.

Хм, если у вас эти два раза в неделю задачи по уборке вообще не пересекаются (считаем это за одну уборку, а не за две с некоторыми отличиями) – то это тоже очень долго, ИМХО. Я вот не представляю для нас как это вообще может работать. Разве что все уходят на работу на целый день и никого в квартире нет.

Ну да. В нашем случае всегда так и было)
Пришел вечером домой и чисто)) Приятно)
Можно вызвать на утро, отдать ключи и попросить кинуть их в почтовый ящик или оставить консьержу. Это без дополнительных затрат. Плюс есть услуги по забору и доставке ключей.

Сидеть над клинером нет нужды, на качество работы это не влияет.

Это всё понятно, я как раз про то и говорю – нет возможности уходить из дома на 5 часов всей семьёй.

Спасибо за обзор, статья легко читается, и интересно! Вопрос вот в чем, я, наверное, не уловил идею. То есть при любом изменении в заказах (т.е. отказался исполнитель, отказался заказчик) происходит глобальный пересчет всего? И правильно ли я понял, задача в том, чтобы оптимально распределить исполнителей между заказчиками? Спасибо)
Происходит пересчет, но не всего.
Если отказался исполнитель, то нужно подобрать нового. Изначально, когда заказ создался, ему подбирается набор подходящих исполнителей и автоматически назначается лучший. Если он отказался, то подбирается следующий и т.д.
Если заказчик перенес уборку, то исполнитель слетает с заказа (если у него есть другой в это время), либо остается на заказе. Если исполнитель слетел, то подбираем следующего, как написано выше.
Если заказчик отказался, то никого искать не нужно)))
Да, задача в том, чтобы оптимально распределить ВСЕ заказы без участия нашего колл-центра.
Спасибо за ответ =)
Прошу прощения, но более 25 человек — это сколько? 25 с половиной?
практически :) на текущий момент 27 человек в it отделе (QA/Front/Back).
О, 25 (поправка, 27) чел уже мало! Они еще ищут moikrug.ru/vacancies/1000041413
чтобы поддерживать монстра, которого наворотили. Красавцы, давайте выходите уже на уровень «каждому отдельному клиенту по микросервису (или даже 2)».
Сколько гневных комментов… Ничего плохого в разделении на сервисы при такой не большой посещаемости нет. И то что два человека на сервис, в этом тоже есть свои плюсы. С узкой ответственностью можно глубже «нырнуть». Если процесс коммуникации хороший, то вероятно качество каждого сервиса будет выше и системы в целом выше.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.