Как правильно выстроить архитектуру приложения?

Question

[jajabin]

Реализовал клиент-серверное приложение, Клиент - перехватывает сетевой пакет из очереди изменяет source_ip . dst_ip ,вставляет обратно в очередь и пакет уходит на сервер, который в свою очередь меняет src_ip и dst_ip на изначальные и отправляет все в интерфейс который смотрит в интернет. Данные на сервер о изначальном назначение пакета приходят через Nats, в обратном направление пакет из интернета проходит тот же путь лишь разница в том что данные клиент ещё хранит в кэше, и по записи устанавливает от кого изначально пришёл клиент.
Интересует такой момент, сейчас в клиенте и сервере имеется по две очереди обе очереди форвардят пакеты, но в разных направлениях, все данное дело я хочу привести к нормальному виду, прикрутить пул воркеров для обработки пакетов к каждой очереди, как правильно поступить разделить на микросервисы? каждая очередь как отдельное приложение?Написать приложение ума хватило а как правильно всё организовать в этом пробелы подскажите куда копать. Какие дополнительные инструменты выбрать? redis для бд в памяти или же быстрее будет все хранить в стандартных хэш-таблицах?

Comments

[uvelichitel]

Go chan - это очередь. Теоретически считается правильным поднимать пул воркеров. На практике, моей практике из моего личного опыта, просто обрабатывать каждое соединение в goroutine выходит примерно то же самое , можно не заморачиваться с мониторингом пула воркеров.

[jajabin]

uvelichitel, а что скажете по хранение данных в памяти? лучше в мапе хранить или же использовать редис? данных примерно будет 2000 элементов в стиле map[int]dataStruct

[uvelichitel]

jajabin, redis не будет быстрее и дешевле не будет. redis дает масштабирование и доступность данных для сторонних сервисов - задел на будущее.

[Andrey Tsvetkov]

Если вариантов всего два: мапа и редис, то конечно же мапа.

Но ещё можно взять слайс и там уже либо бинарным поиском либо по индексу доставать данные

Answer 1

[Илья Казначеев]

Все в кучу смешано, но попробую ответить. Вообще не понял, в чем суть данной инфраструктуры, ну да ладно.

Я так понял, у вас клиент-серверное взаимодействие реализовано посредством очередей поверх натса.
Не понятно, зачем у вас клиент хранит данные, хотя этим должен заниматься сервер. Возможно в этом есть некая подмена терминов.

Будем называть это так: есть первый сервис, подменяющий src_ip и dst_ip в пакете из очереди, и отправляющий в другую очередь.
Есть второй сервис, также подменяющий src_ip и dst_ip в пакете из очереди, но уже отправляющий их в сеть напрямую по завершению.
Есть задача в первом сервисе хранить некие персистентные данные.

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

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

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

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

Но вообще выглядит как сильно переусложненная фигня, это можно сделать в одном приложениями с тремя воркерпулами и двумя каналами.