moleculer - не подойдет, он ляжет на 100к, проверено. Для того чтобы, что-то поконкретней посоветовать, нужно ответить на такие вопросы: Нужна ли вам гарантированная доставка сообщений. Есть ли у вас реверсы в workflow. Валидация входящий и исходящих сообщений? Микросервисы максимально легкими нужно делать. Есть ли возможность делать балансировку на стороне клиента?  Разворачивать сразу рекомендую в Kubernetes, это упростит в дальнейшем подбор(настройку) балансировщика, Брокер сообщений (Kafka или Nats), если замороченный workflow тогда сразу обратите внимание на manager workflow Zeebee либо NiFi. Прототип можно и на ноде, но с очень большой вероятностью часть критических микросервисов придется делать на чем-то вроде Rust(Вы слишком мало дали вводных, что бы что корректно вам посоветовать).

А есть какая-то статья, тесты с результатами по молекуляру? Ляжет на 100к из-за чего именно? То есть что именно станет препятствием?

сами проводили нагрузочный тест. Ситуация примерно такая же как в коментах к этой статье https://habr.com/ru/post/439810/

Там в комментариях были вопросы, но не было ответов
А вы маштабировали ноды при тестировании?

Да, маштабировали, там начинал захлебываться service brocker, примерно на 20к первые признаки, появлялись. Т.е. как выход маштабировать service brocker, но тогда зачем он нужен? Уже проще kubernetes все маштабировать(что мы в итоге и сделали отказавшись от микросервисных фреймворков за ненадобностью)

Вообще с появлением kubernetes не вижу смысла в них. Оверхеад лишний.

Если бы автор вопроса имел бы ответ хотя бы на один из ваших вопросов. Да что ответ, если бы он хотя бы задал сам себе эти вопросы, то пришел бы сюда за рекомендациями другого плана :).

А так самый верный вариант, который сработает - каждому запросу (или юзеру) по своему серверу.

А по поводу микросервисов - с вами абсолютно согласен. После определенного количества RPS траффик и обработка внутренних событий достигают значений, которые эти микросервисы или шина данных не в состоянии обработать.
На практике сталкивался со случаем, когда такое межсервисное взаимодействие приводило к тому, что сообщения просто физически не успевали отправляться, они начинали накапливаться системных буферах, выжирали всю память и сервер попросту ложился.

В автомобилях эту задачу решают разделением (can)шин с проксированием важных событий в соседние шины
Интересно есть ли подобные реализации в it
Вернее, думаю реализации есть, и интересно было бы посмотреть на них

Т.е. как выход маштабировать service brocker, но тогда зачем он нужен?
Если я правильно понимаю, масштабировать его можно и нужно. Он один в рамках одной ноды, которая представляет один или несколько сервисов
Из доки: Each node must have an instance of Service Broker. И выше: A single instance of a node can host one or many services.

То есть скорее всего вы не отмасштабировали проект так, как это позволяет (и, видимо, рекомендует) делать молекуляр

@tshemsedinov Добрый день, подскажите, будет ли запись вашего доклада в AllStars-IT Ukraine

это когда железо греется

Я не знаю, напишу после доклада

Спасибо

Давайте внесу некоторые пояснения, чтобы картина была полной. Тестировали 1.5 года назад(возможно сейчас все гораздо лучше). На сервис брокере был поднят сервис API gateway service и отдельно две ноды воркера которые отдавали json на 2к строк. Стратегия балансировки раунд-робин.  Предположили, что такая конфигурация в состоянии держать 50к, на 20к пошли потери и к 30-40к оно просто умерло. Без всяких предупреждений и попыток восстановиться.
Перед тем как использовать технологию, первый вопрос, который я задаю себе  - “Какой профит я получу (какие проблемы решит эта технология).”  Предполагается, что микросервисный фреймворк, в первую очередь решит проблемы с межсервисной балансировкой, и добавит стандартный шаблон сервиса, в котором уже все разнесено по слоям, что в дальнейшем должно упростить расширяемость и поддержку проекта.  
Если мне нужно масштабировать сервис брокера с API gateway , то наверно, что-то пошло не так и я уже делаю балансировку над балансировщиком. Напрашивается вопрос зачем мне это ? Ведь эти вопросы должен решать фреймворк. Если я уже балансирую нагрузку между сервис брокерами с API gateway, то мне совершенно не сложно балансировать и между сервисами, и фреймворк для этого мне не нужен. Все что нужно толковый шаблон сервиса с нормально нарезанными слоями.  Еще смущает использование в molecular socket.io, express, это явно не добавит rps, хотя возможно это добавлено по “просьбам страждущих”. Было бы справедливым признать, что свой шаблон мы писали опираясь на подход molecular, в этом он мне импонирует. Т.е. если вы никогда не имели дела с микросервисной архитектурой, то molecular неплохой старт, для того чтобы собрать свою пачку граблей.

Api gateway не является балансировщиком, и не задумывался как балансировщик. По крайней мере в доках я ничего такого не увидел
Про использование express и socket.io тоже не понятно: github.com/moleculerjs/moleculer/blob/master/package.json - нет таких зависимостей
В доках только упомянуто, что moleculer-web, который является реализацией api gateway,
support Connect-like middlewares in global-level, route-level and alias-level и middleware mode (use as a middleware with Express). Но это не то же самое, что использование express и socket.io

У нас продукт на молекулере ещё не вышел, хотя первые пользователи уже есть. Поэтому про то, как он держит нагрузку в реальной жизни, сказать пока ничего не могу. Но на этапе тестирования подобных проблем, чтобы были потери, или тем более что-то умирало, не наблюдалось
Поэтому меня с одной стороны несколько пугают рассказы о том, что кто-то проводил тестирование, и оно было неуспешным. С другой, пока что я продолжаю думать, что с планируемой нагрузкой молекуляр должен справиться если его правильно приготовить

Да.. сори за socket.io(moleculer-io), express, , запамятовал (давно было) они отдельными пакетами идут. В сам molecular не входят. Мы на тесты просто с examples брали код, и как-то отложилось. https://moleculer.services/docs/0.14/moleculer-web.html#Examples

А вы нагрузочное делали ? или для вас это не критично ?

Так как я пришёл уже тогда, когда выбор молекуляра был сделан, о нагрузках и вообще тестировании при выборе архитектуры ничего сказать не могу. Знаю, что они (нагрузки) были, и результат удовлетворил
Сейчас нагрузочного тестирования не делается (по крайне мере как надо не делается). А живые пользователи дают такую нагрузку, с которой пока даже масштабировать ничего не надо. По крайней мере в части молекуляра (за нами стоит настоящий бек, там тоже микросервисы, но уже в .net стеке, и там как раз нагрузка уже большая, особенно на сохранение)

Ребята, является ли Моки, Стабы в тестах реализацией паттерна Декоратор?

А может это паттерн Proxy?