«Яндекс» выложил в открытый доступ Userver — инструмент для разработки приложений с микросервисной архитектурой Статьи редакции
Компания использует его, например, в «Яндекс Go», «Лавке», «Доставке», «Маркете» и других сервисах.
Яндекс опубликовал исходный код и документацию фреймворка Userver. Его могут использовать все разработчики по открытой лицензии Apache 2.0, инструмент доступен на GitHub.
Userver подходит для разработки приложений с микросервисной архитектурой. Изначально его делали для «Такси», и с его помощью компания перешла с монолитного приложения на архитектуру, которая позволяет разрабатывать отдельные независимые компоненты — микросервисы — и использовать их в разных приложениях.
- Например, микросервис поиска водителя в «Такси» можно использовать для поиска курьера в «Доставке». То же самое можно делать с похожими задачами — расчётом времени прибытия и другими. Микросервисы автономны, поэтому в приложения можно легко добавлять новые функции и обновлять его.
В Userver есть всё необходимое для разработки, диагностики, мониторинга, отладки и экспериментов, говорит Антон Полухин, один из авторов фреймворка и руководитель бэкенд-разработки решений для продуктовых команд RideTech и eCom. Например, он подсказывает как исправить ошибки ещё на этапе компиляции, умеет работать с разными базами данных и другое, а также подходит для разработки приложений как в больших, так и в маленьких компаниях.
зачем писать в 2022 году фреймворк для микросервисов на C++?
Поддерживаю. C++ хорош для CPU&Memory bounded задач. Если ты все равно ждешь сеть, зачем тут C++? Есть множество более высокоуровневых и удобных языков для этой задачи.
У крупных компаний сейчас на стойку без переподписки ставят оборудование на сотни гбит. Думаю у Яндекса сейчас или 25 гбит, либо 100 гбит. Что вы там в сети будете ждать?
Даже самые мощные сетевые карточки медленнее IPC. Нужно правильно выбирать компромиссы. C++ сложный язык с ручным управлением памятью и высокими требованиями к разработчику. Эти ограничения имеет смысл принимать, когда требуется низкоуровневая оптимизация производительности, например, при работе с железом.
Для того что бы показывать котиков в интернетах и клепать веб-сервисы вполне подойдут менее требовательные php/java/python/nodejs/go.
Моё личное имхо, что на С++ ещё и больше времени занимает разработка. Если речь про маленькие проекты, которые делаются несколькими людьми (не несколькими бэкендерами, а в сумме несколькими людьми), то там я слабо представляю, как можно месяца за 4 сделать нормальный MVP для сложной бизнесовой системы на плюсах небольшим коллективом, придется же велосипеды изобретать
userver и есть этот велосипед. Он позволяет разрабатываться быстро. Писать код на C++ не сильно дольше, чем на Go. Я переходил с C++ на Go и первое время было достаточно мучительно жить без нормального RAII, например. Ну или темплейтов.
Это не имхо, это факт)
Вы наверное не в курсе что такое infiniband?
C++ сложный язык с ручным управлением памятью и высокими требованиями к разработчику.Уже давно нет. Смарт поинтеры и RAII конечно не дают таких гарантий как Rust, но в целом все достаточно просто. Из высоких требований только чуть больше почитать документации, чтобы понять концепции.
Эти ограничения имеет смысл принимать, когда требуется низкоуровневая оптимизация производительности, например, при работе с железом.Почему? Вся проблема C++ в том, что нет стандартной библиотеки, которая бы покрывала большую часть "обычных" задач типа хождения в базу или http клиента. Это все решено в конкретном фреймворке. Судя по примерам код там получается не сложнее питона.
Для того что бы показывать котиков в интернетах и клепать веб-сервисы вполне подойдут менее требовательные php/java/python/nodejs/go.Для показывания котиков и микросервисы не нужны.
Комментарий недоступен
Почему она будет протекать? И что такое сложные случаи? У вас деструктор не вызовется у shared/uniq поинтера?
Такая природа рантаймов без сборки мусора. Все равно программисту надо в голове держать время жизни своих объектов.Время жизни не нужно держать, оно и так видно по коду.
Это не плохо и не хорошо,это tradeoff. Я к тому, что когнитивная сложность написания программы на этих языках всегда будет выше, чем на языках со сборкой мусора, даже если документацию прочитал.Ахаха, вы видимо не в курсе какие мега костыли городил Instagram для того, чтобы бороть GC.
P.S. можно и на java/c# написать так, что память потечёт, но сложнее.Не сложнее, я писал off-heap структуры на Java.
Видно пока код ветвиться не начинает. А он начнёт, иначе зачем тебе C++, если не планируешь над указателями колдовать?
При чем тут ветвление и владение объектом?
Просветите нас, мне любопытно. Что там, типичную архитектуру приложения посмотрел бы. Каковы задержки между созданием данных на одной стороне, и получением их на другой (там же не сокетами фигачат пакеты? Там как-то через PCI/DMA?). Можно и просто ссылку на документ, я б погуглил, хз как запрос сформировать.
PS в принципе нашёл по typical infiniband application
https://network.nvidia.com/related-docs/whitepapers/Intro_to_IB_for_End_Users.pdf
без примеров с семплами кода, конечно, чего там синхронизируют в тестах - не совсем ясно. Ясно только, что синхронизируется области памяти на разных машинах. И как это можно быть по задержкам быстрее, чем внутри одной машины - тоже не ясно. Сравнивают там с обычным эзернетом, видимо, по передаче объёма, а не по latency.
Вы написали про IPC, а не про одну машину. IPC может работать и через unix сокеты и пайпы и infiniband и mmap.
А, ну конечно - следовало уточнить, что в пределах одной машины. Я так и не решился использовать эти механизмы в проекте, где были критичны задержки в 1мс и синхронизация, хотя подумывал. Так и собрал многопоточный монолит))
Эмм, я открою наверное секрет, но в современных торовых сетях внутри ДЦ задержки порядка 500-600 нс.
Ну так-то сеть можно и на С++ подождать, невелика проблема-то ).
Можно и микроскопом гвозди забивать, но зачем?
Не завидуйте! Да, люди сильны в плюсах ))
Так то суровый энтерпрайз, кому надо - тому надо, остальные проходят мимо.
В hft торговле тоже сеть ждут. И ничего, Страуструп вон в Морган Стенли её ждёт
Да, все так. А еще в HFT платят большие деньги, что бы твои сервера оказались "рядом" с серверами биржи для уменьшения задержек.