В данном репозитории представлен простой сервер для микросервисов, который может быть использован для учебных целей, а также для бизнес-задач с невысокой нагрузкой.
Данный сервер реализует "централизованную" микросервисную архитектуру для системы. Это подразумевает, что каждый из сервисов общается с другим через посредника - сервер. Такая организация сначала может иметь показаться неуместной, но это не так: централизованность даёт плюс в виде упрощения адресации. Благодаря тому, что все сервисы общаются через один сервер, им не нужно знать сетевые адреса друг друга, а достаточно лишь знать лишь адрес сервера. Это решает проблему с NAT и в принципе упрощает маршрутизацию трафика. Более того, у сервисов нет какого-то уникального идентификатора, который бы идентифицировал сервис, так что сложностей с ключами доступа и аутентификацией тут также нет.
Все сервисы равны и одинаковы с точки зрения сервера. Между сервисами нет никакой разницы.
Если сервис хочет передать какие-то данные другому сервису, он просто отправляет эти данные на сервер, помечая их некой строкой. Эта строка может иметь любое содержание, может формироваться по любым правилам. Эта строка не обязана быть уникальной. Важно лишь чтобы другой сервис, которому предназначаются данные, также знал эту строку (или принцип формирования этой строки).
Если сервис хочет получить данные с сервера, то он отправляет ждущий GET-запрос. Этот запрос ожидает ответа некоторое время, после чего соединение разрывается и сервис сразу же создаёт новый запрос. Ждущие запросы позволяют отреагировать максимально быстро на приход данных на сервер. В GET-запросе на сервер отправляется строка (пометка), о которой говорилось ранее. Если запрошенная строка совпадает с пометкой каких-то данных на сервере, сервер возвращает эти данные сервису. Если на сервере несколько пакетов данных с одинаковой пометкой, они будут по-очереди предоставлены сервису в том же порядке, в каком поступили на сервер.
В репозитории представлено следующее:
- Сервер микросервисов
- Отладчик коммуникации сервисов
- Клиент на C#
- Клиент на Python
- Документация для всего вышеперечисленного
Первое знакомство рекомендуется начать с документации клиента (например, на С#).
В зависимости от надобности, возможно, через какое-то время выйдет версия 3.0, в которой я добавлю хуки на пакеты. Благодаря хукам, при необходимости, сервис сможет настроить перехват пакета данных до того, как этот пакет попадёт в общую очередь. В итоге, получится, что есть очередь из 2 стадий, где первая - обработка хуком (если таковой есть), а вторая - обработка остальными сервисами (не-хуками).
Однако, существует одна небольшая проблема при введении хуков: для стабильной работы хука, потребуется, чтобы хук имел некий уникальный идентификатора (именно хук, остальным идентификатор по-прежнему не нужен), что отчасти идёт вразрез с ранее указанным "все сервисы равны и одинаковы с точки зрения сервера".
Зачем могут понадобиться хуки? В основном как костыль, который позволит какому-то сервису вклиниться в цепочку обработки пакета без внесения изменений в другие сервисы. Также это может быть полезно для организации мониторинга трафика между сервиами. Например, для отображения пользователю прогресса выполнения задачи.
Я так же рассматривал применение сортировки (с лексикографическим сравнением) к идентификаторам хуков, что позволило бы создать очередь хуков. Пока что у меня есть сомнения на счёт надобности очереди хуков.
Сейчас я не уверен в надобности 3 версии, так что если есть что сказать на этот счёт, можете перейти сюда.