Comments 15
Расскажите, пожалуйста, зачем вам Erlang (или elixir, смотря, что вы используете)? У вас же, по идее, не так много RPS, как у некоторых ( blog.discordapp.com/scaling-elixir-f9b8e1e7c29b ). Причем, если надо какой-то примитив легче, чем Поток, можно было смотреть на Котлин с корутинами, или Скалу с Akka streams, при этом оставаясь в рамках JVM.
Вы абсолютно не понимаете, зачем нужны Erlang/Elixir.
Высокий RPS — это не про них, сырого перфоманса BEAM не дает.
А вот сравнимого удобства разработки асинхронных штук, смешивания синхронного и асинхронного кода, каскадирования и обработки ошибок нет больше нигде.
А еще, выбирая язык в проект, я хочу мочь нанять людей в команду. Кажется, что на JVM нанять пока легче.
Я с вами полностью согласен по поводу инструментария, написать хорошо можно и на том и на том.
А вот по поводу разработчиков — нет. Мой опыт показывает, что одинаково трудно найти хорошего эрлангиста и хорошего джависта, особенно умеющего в Скалу, а с эрлангистами даже полегче. Может, конечно, это нам так повезло, но реальная статистика найма примерно одинаковая с небольшим перекосом в сторону эрлангистов.
Если в лоб смотреть, то конечно, джавистов на порядки больше, вопрос в качестве и специфике — найти крутого джависта, который умеет в функциональный подход как бы не труднее, чем эрлангиста, где он изначально подразумевается.
Кроме того мы используем разные хитрости, например по вакансии на эрланг также приглашаем разработчиков С++. Их уже гораздо больше, а опыт показывает, что им достаточно легко переквалифицироваться.
Ну, за акку мне сложно говорить, но про корутины котлина я скажу точно, что ни в какое сравнение с эрлангом они не идут, к сожалению. Это снова два цвета функций и два различных мира, которые нужно как-то между собой дружить, как ни крути — много думать приходится.
Про найм людей я полностью согласен с chainick — ничуть не легче нормальных людей на JVM найти, а возможно даже сложнее — людей сильно больше просеивать придется.
И дополню — к тому же, приличные разработчики на Erlang несколько дешевле, потому что их рынок не перегрет крупными лавочками, выметающими всех, кто вообще видел код на Java.
У нас в основном эрланг, эликсир как-то не взлетел пока. Насчет RPS — смотря что считать высоким, у нас довольно высокий рейт, особенно всплески платежей, но даже не в нем суть. Я вообще считаю переоцененными вот эти все статьи про миллион одновременных сессий на одной машине, пожалуй не стал бы подобную архитектуру в продакшене внедрять.
Просто эрланг очень приятный и удобный язык, который хорошо ложится на нашу архитектуру, где все асинхронное, надо надежно обрабатывать большие потоки ивентов, а такде описывать бизнес-процессы в виде автоматной логики.
В принципе, все это можно на любом языке делать, просто у нас эрланг, что называется зашел.
В итоге остановились на разработке своего DSL
а почему не lisp-in-json, типа
["if",
["or",
["=", "maestro", ["ctx-get", "payment_tool/definition/payment_system"]],
["=", "mastercard", ["ctx-get", "payment_tool/definition/payment_system"]]]
[ ...then... ]
[ ...else... ]
](ну или вообще честный лисп, joxa или clojure-erlang, но это я не очень серьезен).
Я просто сталкивался с вашим подходом к конфигурации, и после определенного момента очень хочется вырвать себе глаза.
А мы, кстати, очень серьезно думали, чтобы дать возможность вообще напрямую на эрланге (с определенными оганичениями методов) писать конфиг домена, да и любые конфигурационные штуки. Для техподдрежки ведь по большому счету разницы нет что учить — lua, lisp или эрланг.
Но на json-е остановились потому что
а) уже был написан woorl, мозг научился на лету трифтовые спеки в виде json конвертировать
б) на сложные интерфейсы все равно придется писать JS-веб-интерфейсы, а там опять же json гораздо легче заходит
в) на самом деле любой из этих инструментов после определенного момента превращается в вырвиглазный, а в json хотя бы низкий порог входа
г) гораздо более доступный инструментарий по валидации, готовым онлайн-редакторам и прочей обвязке
Решается ли это хранением копией таких настроек за конкретной сущностью где-либо
Так примерно и решается.
Набор конфигураций обрабатывается сервисом Dominant, который предоставляет CVS-подобный интерфейс (состояние он в МГ хранит). Каждый создаваемый инвойс получает референс на конкретную ревизию конфигурации с которой он был создан и при вызове "создай платеж в этом инвойсе", например через год, просто поднянет ее по номеру ревизии.
Я подробно в предыдущей статье описывал: https://habr.com/ru/company/rbkmoney/blog/443518/, раздел "Настраиваем систему".
*тьфу, то есть в этой статье. Перепутал с https://habr.com/ru/company/rbkmoney/blog/447440/, она более свежая, думал там спросили.
Тогда я, возможно, не понял ваш вопрос? Вроде в этой статье про доминант как раз подробно написано.
RBKmoney Payments под капотом — микросервисы, протоколы и конфигурация платформы