Ну ситимобил сложно считать - он совместный, остальное - полностью свои продукты

Я смотрел статистику по MRG, как по группе. Одноклассники точно там, Delivery тоже (в активах точно)

Открой wiki и смотри

Крупная, да, тут не поспоришь.

Delivery скорее всего нет, там выручка по ним вроде не консолидированна в отчётах

Хм, 100% в собственности, по идее должна консолидироваться.

самая большая газпром

Ну сложнее, требует привычки, но может эффективнее.

Выкатили в опенсорс одну внутреннюю утилиту. Асинхронный фреймворк для быстрого создания сервисов общающихся через RabbitMQ. Если кому будет полезна - будем рады.

https://github.com/alem-research/mela

Это к чему?

я не хочу показаться грубым но... а то к чему было? А так может будет польза от готового решения с теми же целями (удобно делать сервисы с pub/sub и сервис энвоуком). Может быть поможет вам отказаться от велосипедов

Выкатили в опенсорс потенциально полезную утилиту. Решил поделиться вот.

Ну делать велосипед или не делать - нам виднее. Нам на нём ездить ещё.

Если говорить про готовые аналогичные решения, то ближе всего будет Celery, но абсолютно точно не dapr.

Однако, Celery не асинхронное. Нам же важна асинхронность.

Celery это task queue, то есть оч узкая штука. Dapr в целом это "именно то" просто больше по юзкейсам. Это скорее "кое как" можно с nservicebus сравнить в плане возможностей, только нет ограничений на каком языке у тебя приложение.

Опять же, писать свой message bus это весело, но не нужно...

Хм, а что из коробки в RabbitMQ не хватает для task queue или вообще для взаимодействия между сервисами? Т.е. зачем что-то еще прикручивать?

Всего хватает. Я не понимаю Сергея, если честно. Celery "прячет" от разработчика всё, что касается общения с рэббитом (или с другим брокером), и позволяет разработчику просто писать бизнес-логику. Точно для этой же цели мы написали Mela.

Грубо говоря, если взять просто pika или даже kombu, то код конечного сервиса будет содержать примерно 150-200 служебных строк, описывающих взаимодействие с реббитом. При этом у нас около 100 таких сервисов. Иногда бывает что там бизнес-логики на пару строк буквально.

Также систематически возникают проблемы с вариативностью. Из-за того, что сервисы пишутся разными людьми в разное время - эта самая "служебная часть", несмотря на то, что она одинакова во всех сервисах, реализовывается очень по-разному. Кроме того, бизнес-логику от этой служебной части довольно сложно отделить. То есть, чтобы понять что происходит в каком-то сервисе, тебе нужно прочитать строк 200 кода, в каждом сервисе ещё и написанного чуть-чуть по-своему.

Вот эту проблему как раз и решаем: прячем служебную часть сервисов внутрь фреймворка, а на верхнем уровне оставляем чистую бизнес-логику.

Хм, то есть это это просто библиотека поверх RabbitMQ API?
Не совсем понимаю, где там место для framework'а

Но где там место для opensource - особенности-то у всех скорее всего свои и эти 100 строк стоит написать один раз в компании и все.
Мне даже странно, что у вас в каждом сервисе это писали по разному, точно нет проблем с коммуникациями внутри?

а завтра к этой либке надо будет прикрутить какой opentracing. А после завтра надо будет заморочаться с авториацией и как роутинг сообщений между сервисами мутить. А потом кто-то захочет писать сервисы не на питоне.

p.s. у меня у самого есть такие велосипеды для "общения сервисов" и по этой причине я ищу способы уйти от этого за счет тулов типа Dapr которые по настоящему комуникации и бойлерплейт скрывают