Comments 24
Меня временами терзает один вопрос: почему люди не могу воспринимать советы, рекомендации и чужой опыт бесплатно? Почему нужна платная экспертиза? Нужно участие в платных конференциях и советы от бывалых воротил? Либо, нужен именно свой, печальный опыт. Я часто говорю, что путь к Erlang не может быть прямым, а должен идти через боль и страдания в попытках решить задачи другими инструментами. А ведь я был в Тензоре на собеседовании в конце 2014 года, говорил и с начальником разработки си++ и выше. Рекомендовал Erlang. Помню, как Д. Новиков мне сказал «если ваш Erlang такой хороший, почему же его все не используют?». Похоже, что было не то время, не те обстоятельства и не тот советчик.
Добро пожаловать в Erlang )
Добро пожаловать в Erlang )
А был опыт разработки на Эрланге перед приходом мысли написать свой модуль? Или, хотя бы, хорошие знания о том, что это такое и с чем его едят?
Какая задержка в итоге?
По моему проще было написать свой сервис на Erlang. Почему все стараются использовать какие-то стандартные решения, а потом адаптируют их костылями под свои нужды?
+1
Был интересный доклад на эту тему на fpconf 2016 — «Почему в вашем следующем проекте вам нужно писать велосипеды на ерланге». Там был сделан велосипед как раз вместо RabbitMQ.
Был интересный доклад на эту тему на fpconf 2016 — «Почему в вашем следующем проекте вам нужно писать велосипеды на ерланге». Там был сделан велосипед как раз вместо RabbitMQ.
Здесь всегда два мнения: «зачем изучать и настраивать что-то готовое, ведь проще запилисть своё?» и «зачем изобретать велосипед, если есть готовое?», и выбор зависит от ситуации. На момент старта у нас не было специалистов по Erlang, а RabbitMQ имел всё на борту. За 4 года жизни проекта на фикс проблем ушло наверное не более 2 человекомесяцев.
Здесь вопрос не в этом, а в другом: «Я беру черную кробку, представляю как оно работает снаружи, вообще не понимаю как оно работает внутри, думаю что оно мне подходит.» Но потом, оказывается что надо адаптировать, причем внешними каким-то штуками. В конце концов выясняется что 2 месяца одного разработчика надо чтобы сделать простой сервис очередей :)
А вообще, конечно, это ваш старт, и ваше решение.
А вообще, конечно, это ваш старт, и ваше решение.
Ну вообще справедливости ради, это хоть и «простой сервис очередей», но это кластерное решение, стабильно работающее под нагрузкой. Отлаженное, проверенное, с документацией, некоторой админкой, гарантированно совместимое с разными клиентами. При этом внутри есть очень много чего, если вдруг понадобится. Если все что надо — малость доработать напильником. Два человека месяца в разрезе вышесказанного — это не так и много. Да и человекомесяцы очень разные бывают.
Дак я ж ничего не имею против стабильного и отлаженного. Ну если вы не умеете готовить Erlang, то пользуйтесь RMQ. Я ж вам не запрещаю.
В данном случае говорилось о конкретном применении, с конкретным кастомным JS клиентом.
Просто моё впечатление о статье — это не как приготовили высокопроизводительный сервис, а как на каждом этапе собирали какие-то узкие места RMQ и обходили их с помощью плагинов, а особенно внутренней структуры сервиса. Хотя по сути, работа любого инженера в ИТ это обход каких-то существующих ограничений на легаси коде.
В данном случае говорилось о конкретном применении, с конкретным кастомным JS клиентом.
Просто моё впечатление о статье — это не как приготовили высокопроизводительный сервис, а как на каждом этапе собирали какие-то узкие места RMQ и обходили их с помощью плагинов, а особенно внутренней структуры сервиса. Хотя по сути, работа любого инженера в ИТ это обход каких-то существующих ограничений на легаси коде.
При таком раскладе вообще не надо пользоваться готовыми решениями?
То есть, если Вам требуется использовать стороннее открытое решение, то первым делом Вы становитесь профессионалом (а лучше экспертом) в языке, на котором написано данное ПО, а затем его анализируете на идеальность. Причём заранее имеете чёткую задачу, которая никогда не изменятся в будущем. И весь этот труд оплачивается вашей компанией. Так?
Я конечно может отстал от жизни, но обычно если нужно использовать стороннее решение, то проводится его тестирование на пригодность с точки зрения функционала и других требований.
И, следуя Вашей логике, если когда-то в будущем потребуется, скажем, написать какой-то порт на С++ для Erlang, то получается надо было всё сразу писать на С++ согласно вашей фразе: «Почему все стараются использовать какие-то стандартные решения, а потом адаптируют их костылями под свои нужды?».
Я конечно может отстал от жизни, но обычно если нужно использовать стороннее решение, то проводится его тестирование на пригодность с точки зрения функционала и других требований.
И, следуя Вашей логике, если когда-то в будущем потребуется, скажем, написать какой-то порт на С++ для Erlang, то получается надо было всё сразу писать на С++ согласно вашей фразе: «Почему все стараются использовать какие-то стандартные решения, а потом адаптируют их костылями под свои нужды?».
> То есть, если Вам требуется использовать стороннее открытое решение, то первым делом Вы становитесь профессионалом (а лучше экспертом) в языке, на котором написано данное ПО, а затем его анализируете на идеальность.
А в чем фишка открытости системы, которую вы используете, если вы не в состоянии поддерживать этот код? В таком случае эффект тот же самый что от закрытого. Пользуйтесь, я не запрещаю
Если вам так действительно сильно нужна поддержка по Erlang, то её всегда можно получить на оутсорсе или фрилансе.
> Причём заранее имеете чёткую задачу, которая никогда не изменятся в будущем.
Как минимум требования должны собираться. А из этого сразу следовало бы что первый вариант самый не очень. Т.е. даже на его реализацию вы сэкономили бы время.
Я то не против использования RMQ, но по моему статья не о том, как вы построили систему, а как собирали слабые стороны RMQ и что-то пытались фиксить, хотя на самом деле достаточно было сделать свою собственную разработку на «все времена». Она бы получилась меньше, и более гибкой.
RMQ он для бедных. Все свойства RMQ вытекают из свойства Erlang. По сути RMQ ничего нового не предлагает, кроме обертки в виде некоего протокола AMQP, ну который достаточно тяжелый для случаев всякого уведомления веб-клиентов.
Попробуйте написать своё решение, я думаю разница производительности будет в 2-3 раза в пользу своего. А объем кода в десятки раз меньше RMQ.
А в чем фишка открытости системы, которую вы используете, если вы не в состоянии поддерживать этот код? В таком случае эффект тот же самый что от закрытого. Пользуйтесь, я не запрещаю
Если вам так действительно сильно нужна поддержка по Erlang, то её всегда можно получить на оутсорсе или фрилансе.
> Причём заранее имеете чёткую задачу, которая никогда не изменятся в будущем.
Как минимум требования должны собираться. А из этого сразу следовало бы что первый вариант самый не очень. Т.е. даже на его реализацию вы сэкономили бы время.
Я то не против использования RMQ, но по моему статья не о том, как вы построили систему, а как собирали слабые стороны RMQ и что-то пытались фиксить, хотя на самом деле достаточно было сделать свою собственную разработку на «все времена». Она бы получилась меньше, и более гибкой.
RMQ он для бедных. Все свойства RMQ вытекают из свойства Erlang. По сути RMQ ничего нового не предлагает, кроме обертки в виде некоего протокола AMQP, ну который достаточно тяжелый для случаев всякого уведомления веб-клиентов.
Попробуйте написать своё решение, я думаю разница производительности будет в 2-3 раза в пользу своего. А объем кода в десятки раз меньше RMQ.
А в чем фишка открытости системы, которую вы используете, если вы не в состоянии поддерживать этот код? В таком случае эффект тот же самый что от закрытого.
Смысл опенсорса же в поддержке сообществом, а не отдельно взятым пользователем.
Если вам так действительно сильно нужна поддержка по Erlang, то её всегда можно получить на оутсорсе или фрилансе.
Так вроде проблем с поддержкой как раз не возникло. Потому и не было смысла пилить свое.
Если вам так действительно сильно нужна поддержка по Erlang, то её всегда можно получить на оутсорсе или фрилансе.
Нам поддержка не нужна, мы же как раз и не агитируем писать всё на Erlang с нуля.
но по моему статья не о том, как вы построили систему, а как собирали слабые стороны RMQ и что-то пытались фиксить
Естественно никто не будет фиксить сильные стороны. Мы рассказали о применени конкретного инструмента в нашей практие и как его можно расширить под свои нужны (пользуясь существующим механизмом плагинов) по мере роста потребностей.
Попробуйте написать своё решение, я думаю разница производительности будет в 2-3 раза в пользу своего. А объем кода в десятки раз меньше RMQ.
Безусловно уже смотрели, и выигрышь будет больше, но затраты на разработку пока будут выше, чем профит. Потому-что это не просто нафигачить 500 строк кода, как у человека на видео выше, а делать надо адекватно, с поддержкой многих клиентов, кейсов использования, возможности расширения, всевозможных видов тестирования и интеграцией в CI. Какие-то тестовые испытательные образцы у нас на «4 ядрах» отправляли и по 500-600к/сек.
Спасибо, интересно было почитать.
Последний вопрос: какую структуру нам нужно использовать, чтобы уметь проверять существование обменника в списке, удалять его оттуда, а также искать уже просроченные обменники с наименьшими затратами?
Раз уж вы всё равно запускаете erlang процесс, то наиболее разумно было бы использовать для этого ETS-таблицу. Для контейнеров с более чем 100-200 элементов как правило удобнее её использовать. А в случае ordered_set вы сможете её и для сортировки по таймстемпу использовать.
gb_tree, хорош для нахождения минимального значения (обменника с наименьшим временем истечения срока годности, которое сравниваем с текущим временем), в качестве ключа структура {ExpireTime, Exchange}, а значение равно 0 (не используется).
Если знгачение не используется, то лучше использовать gb_sets
Sign up to leave a comment.
Сервис оповещения миллиона пользователей с помощью RabbitMQ