Комментарии 52
— кроссплатформенность: это будет работать в разных дистрибутивах Linux, и вообще не только в Linux
— проще фиксировать версию либы, она сама не обновится
— можно собирать либы со своими нужными флагами
— в Сonan central registry могут быть либы, которых нет в официальных репозиториях (хотя может быть и наоборот)
— Conan вполне удобен и без докера, тогда как управлять зависимости без докерфайла ручными установками нужных пакетов довольно неудобно
Именно из-за кроссплатформенности. Тк сижу на Mac OS, но хотелось чтоб работало и под Linux.
Но conan не знает, что она есть в POCO и не умеет ее билдить, в репозитории лежит устаревший конфигурационный файл (я уже написал об этой ошибке создателям POCO). А значит, придется искать другую библиотеку.
Интересная логика, без причин завязались на не особо популярный пакетный менеджер и выбирали инструмент по принципу — чего бы нашлось…
Из-за кроссплатформенности conan. Если есть другие идеи и решения — я только за. Если расскажете.
Тоже можно везде запускать и он сам разрешает зависимости?
Они уже в процессе, похоже. Как минимум в roadmap есть, что уже не может не радовать.
Так что жюри сказало?
Микросервисом и rest как-то не пахнет.
Ну, основная цель была проверить, можно ли вообще также легко как и на питоне собрать себе сервис. Почему же rest не пахнет и как бы вы решили такую задачу?
Что я вижу: собранный на коленке из всего подряд hello world, который даже свой «hello world» отдает не правильно.
Error: Parse error on line 1:
{ hello: heh}
--^
Expecting 'STRING', '}', got 'undefined'Если задача состоит в rest api на poco, то первых двух ответ в гугле по запросу «poco rest api» хватит, чтобы ее решить.
А по части микросервисов на C++ — нет не выдумка, но больно и дорого, в итоге нужно и доступно далеко не всем. Какой-нибудь требовательный микросервис или, скажем какой-нибудь WebRTC relay, писать на нём вполне можно. Для чего-то более общего, как мне кажется, нет подходящих библиотек или даже вернее будет сказать фреймворков, которые бы скрывали сложность от конечного разработчика.
Микросервисы (как и просто сервисы), конечно, пишутся и на C++. Я пишу, например. Но нужно понимать — зачем. Я разрабатываю рекламные платформы, нагрузка — сотни тысяч запросов в секунду, поэтому C++ позволяет получать больше производительности с одной ноды.
Думаю, что если требований к нагрузке особых нет, то и разрабатывать что то на плюсах особо не интересно. Есть куча языков с готовыми библиотеками, где многие вещи делаются в пару строк.
То есть у вас такие сервисы, которые ни вовне не обращаются, ни запросы в БД не делают? Иначе все вот эти оптимизации практически сходят на нет.
К БД обращаются. Но БД нужны специальные, рассчитанные на такие нагрузки. NoSQL в основном. Aerospike например. Кластер из 8 нод легко переживает 0.5 — 1 миллион запросов в секунду. Но там уже все в сетку и ssd упирается.
Реляционные БД используются тоже, но к ним не обращаются на каждый запрос. Только к кэшированные данным. Ну а запись в них только пакетная.
И само собой, чем больше локально кэшированных данных, тем лучше.
К внешним сервисам тоже обращаюсь. Но они должны уметь отвечать за десятки миллисекунд. Иначе, делаем очередь и уже из неё вызываем медленные сервисы.
И знаете, что я узнал? Она есть в POCO! Но conan не знает, что она есть в POCO и не умеет ее билдить
Скажу честно, на это ушла большая часть времени, и не только потому, что я нуб, что необходимо было каждый раз пересобирать библиотеки, а из-за подводных камней conan.
Ох, этим всегда заканчиваются попытки заюзать пакетный менеджер из плюсов. Я уже давно перестал пытаться. Подключить либу по документации (или инструкции со стековерфлов) — это чёткие 15-20 минут и она станет, как влитая. Заюзать пакетный менеджер — от 15 секунд до 4 часов (плюс всегда захватывающий вариант «невозможно в принципе»).
1) Выбрали библиотеку
2) Проверили, есть ли в Conan
3) Если есть, то за 15 секунд подключили
4) Если за 15 секунд не справились — плюнули и подключили по старинке.
Времени дольше не заняло, а шанс того, что сэкономите время заметно увеличивается. И чем дальше, тем больше либ появляются в Conan и исправляются рецепты.
Я вот тут как раз в своём pet project пишу C++ микросервисы на основе gRPC. Увы, в штатном конане его нет.
В результате, я написал велосипед на cmake, который по минимально описанному конфигу умеет скачивать и собирать сторонние библиотеки через ExternalProject_Add. И никаких питонов.
Если дойдут руки до документации, выложу в open source. Пока там, к примеру, даже не пахнет поддержкой винды для некоторых сочетаний компиляторов / платформ. Ну и собрать OpenSSL под винду с помощью mingw без Cygwin — тот ещё квест.
A POCO действительно хороший выбор для реально нагруженного сервера?
А это уже другой вопрос. Я хотел посмотреть, возможно ли также быстро как и на питоне написать шаблон, с помощью которого можно написать сервис. Может, замерю работу в будущем)
Мне показалось, что POCO не самый лаконичный в плане выразительности вариант. А какие еще альтернативы вы смотрели и почему отказались от них в пользу POCO?
Жаль, я думал, что вы провели поиск и сможете рассказать о причинах, которые оттолкнули вас от других вариантов. Такая информация мне лично была бы очень полезна.
Типа crow?
Он же мертв.
Не уследил, но никто не гарантирует, что либы, выбранные автором, не постигнет такая же судьба
Так и есть. Но экспериментировать сейчас, имхо, имеет смысл на том, что сейчас еще живо (ну или подает признаки жизни).
Тем более, что как я понял, автор захотел сделать шаблон, которым можно было бы воспользоваться когда срочно потребуется. На будущее точно не стоит закладываться на заведомо умерший проект, а в репе crow уже два года никакой активности.
проще говоря, струсил
я бы назвал это осторожностью
Ну вот кстати кажется мне, что в случае плюсов вероятность случайно сделать UB очень уж пугает и очень маловероятно, что она стоит улучшения перфоманса, которое еще и никто не гарантирует. Ведь если задача io bound, то весь прирост от плюсов будет сьеден ожиданиями.
К тому же на плюсах сложно писать асинхронный код.
Интересно, как живут тысячи компаний, у которых софт на плюсах?
Да нормально живут. У нас внутренний репозиторий для самособранных библиотек. Стандартный apt-get install bla-bla. Ну и немного кастомных cmake для их подключения.
Ужасы подключения библиотек сильно преувеличены. В основном, все проблемы огребает тот спец, который разбирается с новой либой (или апдейтит существующую). Остальные просто устанавливают и пользуются.
Докер — тоже не вижу сложностей. С появлением multistage сборок — докером стало очень удобно пользоваться для сборки
К тому же на плюсах сложно писать асинхронный код.
Если stackful — Boost.Coroutine2 и вперёд. Если stackless — то C++20 с корутинами + cppcoro и вперёд (но я бы лично сейчас так не делал).
Нужна асинхронная либа для http-сервера — restinio.
Например, пытался юзать в msvc — ловил прикольные эффекты с goto в catch блок без исключения.
Или цикл while (true) с вызовами async_write/async_read (из буста) выходил после первой итерации — помогала запись bool dummy = true;
while (dummy).
Вобщем, все надежды на с++20, верим и ждём. Пока писать асинхронный код действительно тяжело (или по крайней мере неудобно) по сравнению с другими языками.
написать высоконагруженный сервис
Что-то не заметил ничего, что бы отражало эту высоконагруженность, если честно.
Неужели POKO настолько хорош, что сам всё сделает? ;)
Микросервисы на С++. Выдумка или реальность?