Comments 9
Старание это конечно хорошо... но... https://go.dev/
проще все делать в рамках той экосистемы которой автор в совершенстве владеет, тем более когда как мы видим - инструментарий вполне позволяет. не совсем понятно для чего погружаться в чужеродный стэк с большими перспективами забросить.
И прибавить +50% к стоимости разработки без никакого реального выхлопа для бизнеса
Но зачем? Неужели три инстанса на разных портах вместо одного существенно хуже будут обрабатывать? Плюс когда вы все это скейлить будете все равно скорее всего будете делить в какой-то момент по типам запросов, потому что лоадбалансеры придется растащить сначала для разных протоколов, потом для разных путей.
Ну и с точки зрения интеграции rest, вебсокетов и grpc, имхо, гораздо интереснее штуки вроде grpc-gateway, которые при помощи уже практически стандартных http аннотаций могут мапить grpc в рест запросы в автоматическом режиме и даже при большом желании при помощи сторонних плагинов заворачивать честные bi-di grpc стримы, невозможные в текущих браузерах в http, в вебсокеты. И конечно их всего этого можно поднимать сваггер, генерировать документацию, open API спеки и клиентские библиотеки (что для grpc, что для рест)
С тремя инстансами была бы отдельная задача их синхронизировать. Это ведь связанные вещи: пришел запрос на RestAPI, в рамках его обработки нужно вызвать определенных агентов по gRPC, дождаться результата от каждого, собрать ответ, отдать его внешней системе. Все это в асинхронном режиме.
Конечно, удобнее это делать, когда у тебя один инстанс, и состояние обработки каждой задачи, состояние каждого агента - все лежит в общей памяти. И мониторить это дело удобнее.
Альтернативой было бы использование БД, и тогда инстансов стало бы уже не три - а четыре.
Так что у меня встречный вопрос: а зачем усложнять, и вводить четыре инстанса - там, где абсолютно достаточно одного?
Но постойте, ваше приложение получает запрос по http и потом вызывает агентов по grpc, это ведь клиентский запрос от приложения, с этим не должно быть никаких проблем. Или эти же агенты, которые часть этого же приложения вызываются в вашем приложении через внешний grpc интерфейс, который открыт на этом же приложении вместо простого внутреннего прямого вызова процедуры? Мне кажется в этом случае что-то просто фундаментально не так с архитектурой решения, потому что "R" в grpc - это remote.
Схема чуть сложнее. Не HTTP-запрос и HTTP-ответ.
HTTP-вызов на постановку задачи в очередь, и HTTP-ответ на этот запрос "задача принята" (ну или отклоняем по итогам валидации),
Дальше активное асинхронное взаимодействие с агентами - gRPC-вызовы от моего приложения к агентам, затем обратные gRPC-вызовы по факту обработки или изменения статуса от каждого агента в мое приложение. В течение всего времени обработки мое приложение сбрасывает статусы во внешнее приложение (HTTP-запрос от моего приложения), и уже сильно потом, по итогам обработки - доставка результата обработки отдельным HTTP-вызовом от моего приложения во внешнее.
Вот такая, полностью асинхронная, обработка. Причем вполне может быть такое, что кто-то из агентов просто отвалится в процессе работы, и не отдаст ни статус, ни результат. Такие дела.
gRPC, HTTP, Websocket — и все это один сервер