«Яндекс» выложил в открытый доступ 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.
Вы наверное не в курсе что такое infiniband?
C++ сложный язык с ручным управлением памятью и высокими требованиями к разработчику.Уже давно нет. Смарт поинтеры и RAII конечно не дают таких гарантий как Rust, но в целом все достаточно просто. Из высоких требований только чуть больше почитать документации, чтобы понять концепции.
Эти ограничения имеет смысл принимать, когда требуется низкоуровневая оптимизация производительности, например, при работе с железом.Почему? Вся проблема C++ в том, что нет стандартной библиотеки, которая бы покрывала большую часть "обычных" задач типа хождения в базу или http клиента. Это все решено в конкретном фреймворке. Судя по примерам код там получается не сложнее питона.
Для того что бы показывать котиков в интернетах и клепать веб-сервисы вполне подойдут менее требовательные php/java/python/nodejs/go.Для показывания котиков и микросервисы не нужны.
Просветите нас, мне любопытно. Что там, типичную архитектуру приложения посмотрел бы. Каковы задержки между созданием данных на одной стороне, и получением их на другой (там же не сокетами фигачат пакеты? Там как-то через 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 нс.