Чтобы создать приложение обмена сообщениями, я следовал этому примеру: https://github.com/gorilla/websocket/tree/master/examples/chat
Он состоит из концентратора, работающего в одной программе в программе, которая связывает воедино Клиенты (посредник между сокетом и концентратором).
В этом примере каждый клиент (подключенный пользователь / веб-сокет) выполняет 2 процедуры: одну для чтения сообщений, одну для записи. Таким образом, в итоге у нас есть одна подпрограмма для концентратора и множество подпрограмм для всех подключенных пользователей в приложении (по 2 на каждого пользователя)
Но это для приложения, которое все, что оно делает, это передает все сообщения всем подключенным пользователям. Поскольку моя цель - создать приложение для обмена сообщениями (по функциональности похожее на WhatsApp, Messenger и т. П., Где пользователь имеет личные беседы с друзьями), мне нужно соответствующим образом скорректировать этот дизайн.
Итак Я разделил это на два слоя:
- Уровень соединения - Hub + Client. Этот уровень отвечает за поддержание связей с клиентами (плюс все, что с ним связано - чтение / запись сообщений, кодирование / декодирование и т. Д. c.)
- Уровень бизнес-логики c - «ядро» / сама логика c. Значение: общение с БД, будь то SQL или Cache, как Redis, для вставки сообщений, поиска участников в каждом разговоре и т. Д. c.
Задачи :
Поскольку слой Logi c имеет более ресурсоемкие операции (чтение и запись в БД, выяснение, какие пользователи участвуют в диалоге, чтобы он мог сообщить хабу, какие пользователи в его отображении клиентов чтобы отправить сообщение), мне трудно решить, где это должно быть ie и как эти два слоя должны взаимодействовать / общаться друг с другом?
Поскольку концентратор занимает центральное место в приложении и имеет 1 подпрограмму для обработки всего трафика c, я предполагаю, что он не может просто вызвать «processMessage» на уровне сервиса и ждать его ответа. В противном случае мы можем потенциально достичь состояния, когда у нас будет много ожидающих сообщений, и пользователи начнут получать сообщения с большой задержкой. (Пожалуйста, исправьте меня, если я ошибаюсь здесь)
Идеи до сих пор + проблемы :
Так что я, хотя и делаю, это иметь другую служебную программу для приложение, так же как и Hub, которое Hub будет запускать после инициализации, а затем Hub может отправить ему сообщение для обработки, используя канал между ними. Затем, когда Служба завершена, она отправляет обратно на канал Хаба что-то вроде «эй, дорогой Хаб, отправь это сообщение, которое я дал тебе, пользователям: 1, 2, 3».
Но здесь я думаю, что я есть другая проблема - поскольку Hub и Service находятся в разных пакетах, это означает, что мне нужна циклическая зависимость c, потому что Hub знает о Service (он пересылает полученное сообщение для обработки), а Service знает о Hub ( он сообщает концентратору, какое сообщение отправлять, каким пользователям после завершения обработки полученное сообщение из концентратора).
Таким образом, кажется, что у каждого варианта есть либо проблема с производительностью, либо проблема с архитектурой / дизайном. Или оба. Поскольку я не являюсь экспертом в Go, было бы очень полезно узнать, как обрабатывать такие случаи как эффективно (с точки зрения производительности), так и правильно (с точки зрения дизайна).