Антон, а подскажите, пожалуйста, вот есть микросервис, обрабатывающий асинхронно вызовы rpc и выполняющий запросы к БД также асинхронно. Насколько целесообразно реализовывать многопоточность, пусть даже на корутинах, lock-free и т.д. по сравнению с пулом однопоточных микросервисов и балансировщиками перед ними? Есть ли профит с точки зрения производительности?
Вебсокет поддерживается, наверное, всем чем можно, а если что-то не поддерживает, то реализовать поддержку можно без проблем, есть RFC 6455 и 8441 сел и написал. GRPC это сильно монструозная штука, имеющая ряд недостатков:
если вы разрабатываете публичный API, то gRPC не для вас, т.к. не gRPC не поддерживается рядом клиентов или же эта поддержка
если вы пишите асинхронный однопоточный микросервис, то встраивание gRPC окажется большой проблемой. Нужно будет решать проблему с очередью сообщений, кроме того однопоточным ваш сервис уже не станет
нужно решать проблему балансировки. Конечно современные прокси-сервисы поддерживают grpc, но в любом случае это добавляет геморроя
если вам нужен нестандартный сериализатор, то это тоже большая проблема
преимущество GRPC в части снижения оверхеда, основанное на предположении, что бинарная сериализация быстрее чем, например, jsonrpc, к сожалению, в данном случае не работает.
Но если ваш API не является публичным, работает в закрытом контуре, и используются многопоточные сервисы, то gRPC весьма хорош.
Почти все вышеперечисленные недостатки касаются также Apache Thrift
В чем же их стиль отвратителен? Вполне разумный, на мой взгляд.
Другое дело, что они же его не всегда соблюдают. Для примера, использование глобальных неразрушаемых переменных запрещено. Однако, в коде grpc сплошь и рядом, из-за чего приходиться писать портянки подавлений для valgrind
Во-первых, gRPC это фреймворк. Это значит, что в нём есть готовый сервер, синхронный и асинхронный, многопоточный и нет, такой же клиент, а также кодогенератор данных и сервисов.
Во-вторых, в grpc не обязательно использовать protobuf и транспорт http/2. Вместо протобафа можно взять, например, flatbuffers, а вместо http/2 реализовать каналы хоть через голубиную почту.
В-третьих, скорость между парсингом Json, даже на потоковом rapidjson и том же flatbuffers (протобаф не использую по религиозным соображениям), не в семь раз, а в десятки и даже сотни при передаче массивов структур. Особенно, при обмене внутри ЦОД между микросервисами.
В-четвёртых, контракты в виде IDL, очень упрощают жизнь.
В-пятых, при небольшой предварительной подготовке фреймворка под себя, добавление новой команды (без реализации логики) в gRPC занимает около минуты.
Да он не идеален. Да требует больших компетенций, чем Rest. Поэтому, для взаимодействия между микросервисами я использую gRPC, а для взаимодействия с клиентскими приложениями - RestAPI.
Кстати, при выборе между gRPC и Thrift был выбран gRPC.
32 bit, нет 4k, нет поддержки HEVC, LDDR3, проблемы с теплоотводом. Но это касается только использования как медиаконтроллеры.
Так штука крайне надёжная
Плюс мне как пользователю RPi не понятно как работать с другим железом. RPi настраивается быстро и легко, переферии полно.
Вы смотрите на это как специалист использующий это дело на работе. Вам переферию создать раз плюнуть, ОС настроить — раз плюнуть.
А у RPi — совершенно другая ЦА. Люди, которые делают домашние простые сборки на её базе.
Если бы я мог использовать промышленные, то я бы не использовал Raspberry ))))
Мы заказываем в Китае, проверенные БП на 3А, не дешманспие, но и не промку.
Просто в некоторых случаях ставим дополнительный стабилизатор напряжения, правда, всё равно иногда отваливается, но значительно меньше
Вы ошибаетесь, даже используя хорошие и дорогие БП, в нестабильной электрической сети без стабилизации есть много шансов нарваться на сбой. У меня таких объектов несколько. Например, магазин, где при включении промышленного холодильника ломаются частоты и, в лучшем случае, отрубается видео, в худшем фриз и ребут по watchdog (Господи, зарезервируй место в раю парню, который придумал аппаратный Watchdog). Или кухня, где куча аппаратуры, которая берёт хороший стартовый ток.
Вы поймите, ваш плеер не даёт нагрузки на чипсет, от слова совсем. А когда используется декодирование H.264 60 FPS FullHD в IP потоке, там нагрузка на грани и любой скачок напряжения критичен.
Я достаточно долго работал с RPi, на объектах стоит больше тысячи устройств, и пришлось дорабатывать напильником (реверс-инжиниринг ThreadX) и видеодрайвера Линукс vc4.
Статья очень толковая, просто мои мысли выразил товарищ. Добавлю пять копеек — медленная память.
По поводу аналогов — очень неплохие и надёжны Odroid XU4, но морально устарели, жаль N1 так и не вышел. Tinker от Asus вроде неплохо, но дохлое комьюнити, проблемы с поддержкой и ещё бОльшие и с поставками. Чипсеты от AMLOGIC принципиально не рассматриваю, побуистичное отношение к дровам. Соки на Nvidia дороги, в конечника цена прилетает такая, что они даже не рассматривают.
Я остановился на соке от Firefly на чипсете Rockchip RK3328-CC, как базовой, и RK3399 для более производительных задач.
Плюсы — унифицированный фреймворк драйверов (мои задачи — видео и NN, дрова для всех моделей одинаковы), DDR4, хороший саппорт, нет проблем с поставками и гарантированный LTS
Очень интересная статья.
Антон, а подскажите, пожалуйста, вот есть микросервис, обрабатывающий асинхронно вызовы rpc и выполняющий запросы к БД также асинхронно. Насколько целесообразно реализовывать многопоточность, пусть даже на корутинах, lock-free и т.д. по сравнению с пулом однопоточных микросервисов и балансировщиками перед ними? Есть ли профит с точки зрения производительности?
RFC 8441
Вебсокет поддерживается, наверное, всем чем можно, а если что-то не поддерживает, то реализовать поддержку можно без проблем, есть RFC 6455 и 8441 сел и написал.
GRPC это сильно монструозная штука, имеющая ряд недостатков:
если вы разрабатываете публичный API, то gRPC не для вас, т.к. не gRPC не поддерживается рядом клиентов или же эта поддержка
если вы пишите асинхронный однопоточный микросервис, то встраивание gRPC окажется большой проблемой. Нужно будет решать проблему с очередью сообщений, кроме того однопоточным ваш сервис уже не станет
нужно решать проблему балансировки. Конечно современные прокси-сервисы поддерживают grpc, но в любом случае это добавляет геморроя
если вам нужен нестандартный сериализатор, то это тоже большая проблема
преимущество GRPC в части снижения оверхеда, основанное на предположении, что бинарная сериализация быстрее чем, например, jsonrpc, к сожалению, в данном случае не работает.
Но если ваш API не является публичным, работает в закрытом контуре, и используются многопоточные сервисы, то gRPC весьма хорош.
Почти все вышеперечисленные недостатки касаются также Apache Thrift
Спасибо, друг!!! Помогло!
В чем же их стиль отвратителен? Вполне разумный, на мой взгляд.
Другое дело, что они же его не всегда соблюдают. Для примера, использование глобальных неразрушаемых переменных запрещено. Однако, в коде grpc сплошь и рядом, из-за чего приходиться писать портянки подавлений для valgrind
Букаф много, но ни о чём.
Во-первых, gRPC это фреймворк. Это значит, что в нём есть готовый сервер, синхронный и асинхронный, многопоточный и нет, такой же клиент, а также кодогенератор данных и сервисов.
Во-вторых, в grpc не обязательно использовать protobuf и транспорт http/2. Вместо протобафа можно взять, например, flatbuffers, а вместо http/2 реализовать каналы хоть через голубиную почту.
В-третьих, скорость между парсингом Json, даже на потоковом rapidjson и том же flatbuffers (протобаф не использую по религиозным соображениям), не в семь раз, а в десятки и даже сотни при передаче массивов структур. Особенно, при обмене внутри ЦОД между микросервисами.
В-четвёртых, контракты в виде IDL, очень упрощают жизнь.
В-пятых, при небольшой предварительной подготовке фреймворка под себя, добавление новой команды (без реализации логики) в gRPC занимает около минуты.
Да он не идеален. Да требует больших компетенций, чем Rest. Поэтому, для взаимодействия между микросервисами я использую gRPC, а для взаимодействия с клиентскими приложениями - RestAPI.
Кстати, при выборе между gRPC и Thrift был выбран gRPC.
Так штука крайне надёжная
Плюс мне как пользователю RPi не понятно как работать с другим железом. RPi настраивается быстро и легко, переферии полно.
Вы смотрите на это как специалист использующий это дело на работе. Вам переферию создать раз плюнуть, ОС настроить — раз плюнуть.
А у RPi — совершенно другая ЦА. Люди, которые делают домашние простые сборки на её базе.
Согласен
Причём
T9 TV Box
:)))))
3390 руб за RPI, если вы onpad смотрите
Вот, за эту же цену на RK3328 http://tvboxshop.ru/buytvbox/t9-tv-box/
https://m.habr.com/ru/post/440584/comments/#comment_19767214
Посмотрите мой комментарий выше в ветке, я расписал с чем работал и на чём остановился.
Мысль ТС, что сегодня есть лучшие альтернативы в сегменте.
Если бы я мог использовать промышленные, то я бы не использовал Raspberry ))))
Мы заказываем в Китае, проверенные БП на 3А, не дешманспие, но и не промку.
Просто в некоторых случаях ставим дополнительный стабилизатор напряжения, правда, всё равно иногда отваливается, но значительно меньше
Вы ошибаетесь, даже используя хорошие и дорогие БП, в нестабильной электрической сети без стабилизации есть много шансов нарваться на сбой. У меня таких объектов несколько. Например, магазин, где при включении промышленного холодильника ломаются частоты и, в лучшем случае, отрубается видео, в худшем фриз и ребут по watchdog (Господи, зарезервируй место в раю парню, который придумал аппаратный Watchdog). Или кухня, где куча аппаратуры, которая берёт хороший стартовый ток.
Вы поймите, ваш плеер не даёт нагрузки на чипсет, от слова совсем. А когда используется декодирование H.264 60 FPS FullHD в IP потоке, там нагрузка на грани и любой скачок напряжения критичен.
Я достаточно долго работал с RPi, на объектах стоит больше тысячи устройств, и пришлось дорабатывать напильником (реверс-инжиниринг ThreadX) и видеодрайвера Линукс vc4.
Статья очень толковая, просто мои мысли выразил товарищ. Добавлю пять копеек — медленная память.
По поводу аналогов — очень неплохие и надёжны Odroid XU4, но морально устарели, жаль N1 так и не вышел. Tinker от Asus вроде неплохо, но дохлое комьюнити, проблемы с поддержкой и ещё бОльшие и с поставками. Чипсеты от AMLOGIC принципиально не рассматриваю, побуистичное отношение к дровам. Соки на Nvidia дороги, в конечника цена прилетает такая, что они даже не рассматривают.
Я остановился на соке от Firefly на чипсете Rockchip RK3328-CC, как базовой, и RK3399 для более производительных задач.
Плюсы — унифицированный фреймворк драйверов (мои задачи — видео и NN, дрова для всех моделей одинаковы), DDR4, хороший саппорт, нет проблем с поставками и гарантированный LTS