Ну как меняет... добавляет :)

и переписывает продакшн, да :)

А, ты в этом смысле? Да не, акстись!

Мы, правда, потихоньку с JS на TS переходим :) Но это ооооочень постепенно.

ну ок, команда... она точно постоянно изменяется, и если на старте 90% любят и умеют nodejs то возможно через пару лет другие люди уже будут любить golang

Я думаю, можно подружить акторы, написанные на разных языках. Почему нет?

Но это если совсем прижмёт

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

и раз в месяц меняться :) типа "я вон напилил кучу, иди ты теперь с бизнесом общайся а я наконец-то прочитаю все статьи которые сохранил в избранное" :)

Привет. 29-го числа будет небольшой совместный митап piterjs и Яндекса. Если есть желание выступить с докладом - пишите)

А давайте немножко поофтоплю, хочу услышать ваше мнение (многабукв будет). Хочу чтобы вы выступили в роли "адвоката дьявола" и покритиковали меня
в результате может придем к какому-то общему решению:

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

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

- максимально простой протокол чтобы его можно было реализовать под любой язык
- с поддержкой версионирования для возможности переключения между сервисами рабочими
- из коробки всякие балансировки, загрузки и прочее что требуется для современных сервисов
- обязательна работа в двух режимах: посылке команд напрямую другим сервисам ("вопрос-ответ") и подписка на события от других сервесов ("событийно-ориентированая система")

Основную идею я взял отсюда https://runnable.com/blog/event-driven-microservices-using-rabbitmq но расширил добавив дополнительный транспорт (преимущества добавления транспорта опишу в конце):

В фреймворке существует три типа передачи данных:
1) Таски: действия которые модифицируют состояние, могут выполняться только внутри одного сервиса (важно: не в одном процессе, а в одном из процессов одного сервиса - они могут и будут размазаны по разным компьютерам). То есть, когда надо выполнить задачу она посылается в очередь и первый процесс сервиса который свободен берет ее и выполняет.
2) События: по факту выполнения таски генерируется событие на который может быть подписан _любой_ сервис.
3) Внешние запросы: когда сервису нужно получить данные от другого сервиса он генерирует внешний запрос к тому сервису. А тот сервис скорее всего запустит таску которая обработает этот запрос, но это необязательно.

Первые два типа реализуются через один из событийно-ориентированных протоколов: amqp, mqtt, или даже redis pub/sub. Третий тип может использовать gRPC, REST, graphQL, amqp и все что угодно. Все это выбирается плагинами (реализован будет только amqp для тасков/событий и gRPC для внешних запросов).

Специально не буду описывать почему выбраны эти транспорты, какие преимущества и недостатки, как будет достигаться версионность и прочее. Если дойдем до этого и будет интересно то распишу, пока лишь просто хочу узнать мнение об общей концепции.

https://docs.google.com/spreadsheets/d/1l-jbEGlkW83Hcb122oHZZ8SGTdE1nRQVOT5gnWvbXO0/edit#gid=0 - недоделал :)

А какую работу будет выполнять фреймворк за нас?

предоставлять api для общения между компонентами, балансировка, файловер, циркут брекер, мониторинг и все прочее :)

в случае amqp например через брокер типа rabbitmq, в случае gRPC через внешние сервисные меши типа isio/linterd

"но это не точно" (с) :)

мне на самом деле очень лениво все это делать самому, поэтому если уже есть готовые решения под описаные вещи (то есть и "евент-драйвен", и "запрос-ответ") то сообщайте, с радостью поковыряю

Ну вот в Comedy, например, (https://github.com/untu/comedy) есть балансировка (пока простейшая) и фейловер, а также сбор метрик. Правда там не совсем про микросервисы.

Ничего другого на ум не приходит :)