Comments 20
Для начала нам нужно найти библиотеку в системе, для этого необходимо написать FindLibEvent.cmake
но зачем? Насколько я понимаю, libevent ожидает что его будут искать через pkg-config. А для работы с ним в cmake есть соответствующий модуль, FindPkgConfig
Рассматривали ли какие-нибудь другие библиотеки, например lithium?
Ну и с чего же начать писать микросервис на Си++?
Вы тут показали как с горем пополам обработать хттп запрос на си++. Это конечно очень круто, но право же не понятно как связанно с микросервисом.
Лучше расскажите как ваш микросервис пишет логи, как общается с базами и другими сервисами, как обрабатывает ошибки, как он скейлится, живет в контейнере или просто так и почему, в чем для вашего проекта выигрыш от микросервисов и насколько они микро, как реализованно управление деплоями и версионированием всего этого добра, есть ли явные преимущества у сервиса на плюсах с сервисами написанными на других ЯП, используете ли крутые фишки 20 плюсов или все по-старинке на 11 (а может даже на 03 )?
Не было ли попыток создать свой опен-сорсный враппер над libevhttp чтобы было удобней им пользоваться?
Вы тут показали как с горем пополам обработать хттп запрос на си++. Это конечно очень круто, но право же не понятно как связанно с микросервисом.
Лучше расскажите как ваш микросервис пишет логи, как общается с базами и другими сервисами, как обрабатывает ошибки, как он скейлится, живет в контейнере или просто так и почему, в чем для вашего проекта выигрыш от микросервисов и насколько они микро, как реализованно управление деплоями и версионированием всего этого добра, есть ли явные преимущества у сервиса на плюсах с сервисами написанными на других ЯП, используете ли крутые фишки 20 плюсов или все по-старинке на 11 (а может даже на 03 )?
Не было ли попыток создать свой опен-сорсный враппер над libevhttp чтобы было удобней им пользоваться?
С чего начать писать микросервис на C++
С молитвы и жертвоприношения :-)
Можно взять GRPC и не мучаться.
для работы по http рассматривали boost::beast?
Библиотека libevent предоставляется в составе пакета libevent-dev и стоит из коробки на множестве unix-подобных ОС.Так как это микросервис и должен быть в контейнере (о чём в статье ни слова), то наличие этого пакета в дистрибутиве не принципиально, тем более, что для контейнеров чаще всего используют минимальный Alpine, а не Debian.
Далее, устанавливать пакет для разработки опять же не обязательно, так как libevent лежит в публичном доступе: github.com/libevent/libevent
Поэтому всё вышеописанное применение CMake можно значительно упростить (и будет работать под любой ОС, не придётся ни чего переписывать для Windows), примерно так
FetchContent_Declare(
libevent
GIT_REPOSITORY https://github.com/libevent/libevent
GIT_TAG ${LIBEVENT_VERSION}
)
# setup specific options
# fetch libevent
FetchContent_MakeAvailable( libevent )
set( LIBEVENT_FOUND true PARENT_SCOPE )
set( LIBEVENT_VERSION ${LIBEVENT_VERSION} PARENT_SCOPE )
set( LIBEVENT_ROOT ${libevent_SOURCE_DIR} PARENT_SCOPE )
set( LIBEVENT_INCLUDE_DIRS ${libevent_SOURCE_DIR}/include PARENT_SCOPE )
set( LIBEVENT_LIBRARIES libevent )
set( LIBEVENT_LIBRARIES ${LIBEVENT_LIBRARIES} PARENT_SCOPE )пример написан тут, возможны ошибки. Правильно было бы ещё использовать mark_as_advanced, но не обязательно.
В контейнерах использую минимальный дебиан(не полноценный), а сами сервисы крутятся в закрытой сети. А про то как их паковать в контейнеры, я планировал отдельный пост.
Суть комментария была в том, что можно каждый раз при полной сборке, клонировать репозиторий libevent и брать нужную версию для своего сервиса, и делать это будет CMake самостоятельно, при этом это переносимо, потому что libevent будет модулем для вашего приложения, а не системной библиотекой.
Плюсы — быстрое обновление до новой версии и полный контроль над версиями библиотеки. Для классического сервера это скорее недостаток, а для контейнера, где «всё своё ношу с собой» это достоинство.
Ну и я, лично, не уверен, что минимальный (неполноценный) Debian, как Вы сами пишите, будет безопасней полноценного Alpine для которого так же существует отдельный пакет
pkgs.alpinelinux.org/package/edge/main/x86_64/libevent-dev
если уж не хочется связываться с модульной сборкой.
Но решать конечно Вам.
Плюсы — быстрое обновление до новой версии и полный контроль над версиями библиотеки. Для классического сервера это скорее недостаток, а для контейнера, где «всё своё ношу с собой» это достоинство.
Ну и я, лично, не уверен, что минимальный (неполноценный) Debian, как Вы сами пишите, будет безопасней полноценного Alpine для которого так же существует отдельный пакет
pkgs.alpinelinux.org/package/edge/main/x86_64/libevent-dev
если уж не хочется связываться с модульной сборкой.
Но решать конечно Вам.
Есть такая еще библиотека https://github.com/microsoft/cpprestsdk
// Так лучше память не выделять
например можно использовать std::unique_ptr<char[]> или shared_ptr
в конкретном случае можно вообще создать std::string длинны length и скопировать данные прямо в него — у него есть гарантия размера и непрерывности
На c++ лучше boost::beast — тут тебе и умные указатели, и современный c++, да еще и вебсокеты.
вместо:
char* data = new char[length];
evbuffer_copyout(input, data, length);
std::string body(data, length);
delete[] data;auto data = std::make_unique<char[]>(length + 1); // уже будет заполнен '\0'
evbuffer_copyout(input, data.get(), length);
return std::string(data.get())Sign up to leave a comment.
С чего начать писать микросервис на C++