Коммуникация микросервисов с малой задержкой в ​​сценариях удаленного доступа, IPC и потоков - PullRequest
Новая
       22

Коммуникация микросервисов с малой задержкой в ​​сценариях удаленного доступа, IPC и потоков

0 голосов
/ 08 января 2019

Я хочу создать сверхскоростное C ++ решение для обработки сообщений, которое будет привязано к процессору и основано на микро-сервисах. Он будет обрабатывать множество сообщений запроса / ответа, которые достаточно малы (от 32 байт до 1 КБ на сообщение).

Некоторые сервисы будут размещаться на разных хостах. Некоторые будут на одном хосте, но в разных процессах. И некоторые внутри одного и того же процесса, но в разных потоках.

В настоящее время я думаю о протоколах связи для топологии таких сервисов. Моей первой идеей было использование связи по протоколу TCP, которая позволяет использовать обратную связь для связи IPC на одном хосте и даже для потоковой связи. Преимущество заключается в наличии единого кода связи, который позволяет экспериментировать с топологией сервисов. Будет легко разместить службу внутри какого-либо процесса или перенести ее на удаленный хост.

Однако я понимаю, что если я хочу иметь решение с малой задержкой с максимальным количеством запросов в секунду и скоростью доставки сообщений, мне придется разделить транспорт в зависимости от типа связи:

  • Связь потоков - наилучших результатов можно достичь при использовании кольцевого буфера или шаблона прерывателя LMAX .

  • IPC-связь - Я думаю, что каналы или кольцевой буфер в разделяемой памяти - это хорошие решения. Есть ли лучший способ сделать IPC?

  • Удаленная связь - асинхронный TCP-сервер / клиент для последовательной доставки сообщений и UDP для многоадресной рассылки.

Также я думаю о Linux-решении, но было бы здорово иметь кроссплатформенность!

Мне кажется, Библиотека Asio C ++ является хорошей отправной точкой для удаленного общения.

У меня следующие вопросы:

  1. Стоит ли создавать собственные решения для IPC / потоковой связи или мне следует начать с TCP-соединений localhost?
  2. Может ли кто-нибудь предоставить мне некоторые результаты сравнения производительности различных методов IPC (locahost tcp против каналов по сравнению с разделяемой памятью) для лучшего RPS небольших сообщений до 1 КБ? (Например, общая память будет в 10 раз быстрее, чем localhost TCP, и в 3 раза быстрее, чем каналы или приблизительные значения RPS для сравнения).
  3. Может быть, я пропустил какую-то хорошую технику или библиотеку IPC / RPC с низкой латентностью, на которую мне стоит обратить внимание?
  4. Или, возможно, для моей проблемы существует какое-либо готовое решение, которое я могу использовать или приобрести лицензию?

Заранее спасибо за ваши ответы и предложения!

Тесты IPC

Я только что нашел и выполнил низкоуровневые тесты IPC под Linux (Linux ubuntu 4.4.0 x86_64 i7-6700K 4.00GHz). Размер сообщения составил 128 байт, а количество сообщений - 1000000. Я получаю следующие результаты:

Трубный эталон: 

Message size:       128
Message count:      1000000
Total duration:     27367.454 ms
Average duration:   27.319 us
Minimum duration:   5.888 us
Maximum duration:   15763.712 us
Standard deviation: 26.664 us
Message rate:       36539 msg/s

Тест FIFO (именованные каналы): 

Message size:       128
Message count:      1000000
Total duration:     38100.093 ms
Average duration:   38.025 us
Minimum duration:   6.656 us
Maximum duration:   27415.040 us
Standard deviation: 91.614 us
Message rate:       26246 msg/s

Тест очереди сообщений: 

Message size:       128
Message count:      1000000
Total duration:     14723.159 ms
Average duration:   14.675 us
Minimum duration:   3.840 us
Maximum duration:   17437.184 us
Standard deviation: 53.615 us
Message rate:       67920 msg/s

Тест общей памяти: 

Message size:       128
Message count:      1000000
Total duration:     261.650 ms
Average duration:   0.238 us
Minimum duration:   0.000 us
Maximum duration:   10092.032 us
Standard deviation: 22.095 us
Message rate:       3821893 msg/s

Тест TCP-сокетов: 

Message size:       128
Message count:      1000000
Total duration:     44477.257 ms
Average duration:   44.391 us
Minimum duration:   11.520 us
Maximum duration:   15863.296 us
Standard deviation: 44.905 us
Message rate:       22483 msg/s

Тест доменных сокетов Unix: 

Message size:       128
Message count:      1000000
Total duration:     24579.846 ms
Average duration:   24.531 us
Minimum duration:   2.560 us
Maximum duration:   15932.928 us
Standard deviation: 37.854 us
Message rate:       40683 msg/s

Тест ZeroMQ: 

Message size:       128
Message count:      1000000
Total duration:     64872.327 ms
Average duration:   64.808 us
Minimum duration:   23.552 us
Maximum duration:   16443.392 us
Standard deviation: 133.483 us
Message rate:       15414 msg/s

Ответы [ 2 ]

0 голосов
/ 13 июня 2019

Может быть, я пропустил какую-то хорошую технику или библиотеку IPC / RPC с низкой латентностью, на которую мне стоит обратить внимание?

Continental опубликовала библиотеку IPC, которая ориентирована на передачу данных с низкой задержкой и высокой пропускной способностью на отдельных хостах (с использованием общей памяти) или между разными хостами (с использованием многоадресной рассылки udp). Это работает на Windows и Linux OS. Взгляните сюда https://github.com/continental/ecal

0 голосов
/ 08 января 2019

Вы писали:

и сверхбыстрая обработка сообщений C ++ решение

Как правило, это означает, что нужно брать руки во все. В конце концов, звучит как интересная библиотека, если вы ее снимите.

В целом ваш вопрос (слишком) слишком широк - тем не менее, вот мои мысли:

  1. Трудно дать какой-либо совет здесь ...

  2. Сравнения будут зависеть от платформы / системы. Например. TCP может быть быстрее или медленнее в зависимости от системы.

  3. OpenMP и boost interprocess приходит на ум.

  4. Вы, возможно, не захотите изучать или начинать, например, с библиотеки apache thrift (хотя она также и мультиязычна - оригинал разработан для бэкэнд-серверов Facebook, я полагаю), вы можете провести некоторые ранние эксперименты и получить понимание некоторых вопросов для рассмотрения.

...