Есть менее десятка разных проектов, которые друг с другом общаются.
Один сервер на С#
Одно клиентское приложение на С# для рабочих станций
Несколько разных серверов на Java
Основной протокол общения — SOAP. Но иногда просто XML по HTTP.
Хочется упростить конфигурацию и прописывание разнообразных пар хост\порт где попало.
Посоветуйте что-нибудь из практики. Вот что удалось нарыть в гугле
— Eureka, ZooKeeper, Consul и подобные — умеют делать Discovery, но все остальные фичи ориентированы на кластер, плюс приходится содержать некий центральный реестр.
— WS-Discovery, вроде как, стандартная штука, но давно всеми забытая и мало кем вообще реализованая.
— UPnP, вроде как, подходит, с той лишь разницей что протокол больше ориентируется на девайсы в сети, чем на сервисы.
Хочется что-то простое и кроссплатформенное. Посоветуйте, пожалуйста.
Здравствуйте, Blazkowicz, Вы писали:
B>Привет,
B> Есть менее десятка разных проектов, которые друг с другом общаются. B>Один сервер на С# B>Одно клиентское приложение на С# для рабочих станций B>Несколько разных серверов на Java
B>Основной протокол общения — SOAP. Но иногда просто XML по HTTP.
B>Хочется упростить конфигурацию и прописывание разнообразных пар хост\порт где попало.
B>Посоветуйте что-нибудь из практики. Вот что удалось нарыть в гугле B>- Eureka, ZooKeeper, Consul и подобные — умеют делать Discovery, но все остальные фичи ориентированы на кластер, плюс приходится содержать некий центральный реестр. B>- WS-Discovery, вроде как, стандартная штука, но давно всеми забытая и мало кем вообще реализованая. B>- UPnP, вроде как, подходит, с той лишь разницей что протокол больше ориентируется на девайсы в сети, чем на сервисы.
B>Хочется что-то простое и кроссплатформенное. Посоветуйте, пожалуйста.
На практике так и не дотянулся (пока), но вроде как именно для таких задач есть Enterprise service bus
Здравствуйте, Blazkowicz, Вы писали:
B>- UPnP, вроде как, подходит, с той лишь разницей что протокол больше ориентируется на девайсы в сети, чем на сервисы.
UPnP как раз ориентируется на сервисы, однако это overkill, скорее всего, потому как твои сервисы вряд ли вписываются в стандартные схемы UPnP.
Можно взять кусок оттуда, а именно SSDP (Simple Service Discovery Protocol).
Вот есть библиотечка для .NET https://github.com/Yortw/RSSDP, есть для C https://github.com/zlargon/lssdp
Для Java библиотек не знаю, но протокл простой как валенок, есть куча реализаций в качестве примера.
Здравствуйте, Blazkowicz, Вы писали:
B>- UPnP, вроде как, подходит, с той лишь разницей что протокол больше ориентируется на девайсы в сети, чем на сервисы.
UPnP — отличный вариант. Девайсы в сети не просто же так, они для того, чтобы предоставлять сервисы. Собственно, тебе нужен SSDP
Можно еще всякие ZeroConf посмотреть, но я , лучше он или хуже. Я ковырялся с SSDP, все девайсы у меня в домашней сети откликаются — роутер (старый и новый), NAS, компы. Не знаю, есть ли у всего этого хозяйства поддержка ZeroConf и подобного.
Еще плюс — винда такие устройства сама видит и отображает в корне "Сети", можно какую-то инфу посмотреть без вспомогательных инструментов, перейти на веб-страницу устройства
Здравствуйте, andrey.desman, Вы писали:
B>>- UPnP, вроде как, подходит, с той лишь разницей что протокол больше ориентируется на девайсы в сети, чем на сервисы.
AD>UPnP как раз ориентируется на сервисы, однако это overkill, скорее всего, потому как твои сервисы вряд ли вписываются в стандартные схемы UPnP.
За давностью могу ошибаться, но UPnP, помимо нескольких протоколов, описывает какой-то набор стандартных сервисов/устройств. Но никто не мешает создать свой девайс сервис, не обязательно его где-то регистрировать. UUID сгенерировал свой собственный, и пользуйся, вряд ли с чем-то пересечется
Здравствуйте, Marty, Вы писали:
M>За давностью могу ошибаться, но UPnP, помимо нескольких протоколов, описывает какой-то набор стандартных сервисов/устройств. Но никто не мешает создать свой девайс сервис, не обязательно его где-то регистрировать. UUID сгенерировал свой собственный, и пользуйся, вряд ли с чем-то пересечется
Именно поэтому upnp не нужен, а нужна его часть — SSDP.
Здравствуйте, andrey.desman, Вы писали:
M>>За давностью могу ошибаться, но UPnP, помимо нескольких протоколов, описывает какой-то набор стандартных сервисов/устройств. Но никто не мешает создать свой девайс сервис, не обязательно его где-то регистрировать. UUID сгенерировал свой собственный, и пользуйся, вряд ли с чем-то пересечется
AD>Именно поэтому upnp не нужен, а нужна его часть — SSDP.
Здравствуйте, Blazkowicz, Вы писали:
B>Привет,
B> Есть менее десятка разных проектов, которые друг с другом общаются. B>Один сервер на С# B>Одно клиентское приложение на С# для рабочих станций B>Несколько разных серверов на Java
B>Основной протокол общения — SOAP. Но иногда просто XML по HTTP.
B>Хочется упростить конфигурацию и прописывание разнообразных пар хост\порт где попало.
B>Посоветуйте что-нибудь из практики. Вот что удалось нарыть в гугле B>- Eureka, ZooKeeper, Consul и подобные — умеют делать Discovery, но все остальные фичи ориентированы на кластер, плюс приходится содержать некий центральный реестр. B>- WS-Discovery, вроде как, стандартная штука, но давно всеми забытая и мало кем вообще реализованая. B>- UPnP, вроде как, подходит, с той лишь разницей что протокол больше ориентируется на девайсы в сети, чем на сервисы.
B>Хочется что-то простое и кроссплатформенное. Посоветуйте, пожалуйста.
Consul. Централизованный реестр не нужен — используйте сервисы с инвалидацией по таймауту. Т.е. схема примерно такая:
— поставить кластер консула, можно из одной ноды
— на каждый сервер поставить клиент консула, ему много ресурсов не требуется
— каждое приложение при старте регистрируется в консуле раз в 10 секунд отправляет в localhost:8500 (локальный консул) healthcheck с TTL 15 секунд. Если приложение остановить, его запись в консуле "протухнет" через 15 секунд.
Тогда в консуле всегда будет актуальная информация о живых приложениях, их хостах и портах.
Инфа о сервисах запрашивается тоже через localhost:8500, так что в приложение даже адрес консула зашивать не нужно.
edit: а вот для клиентского приложения адрес сервера лучше всего раздавать через DNS, ну или намутить проксирующий nginx c автообновлением конфига из консула.
Здравствуйте, Blazkowicz, Вы писали:
B>Хочется что-то простое и кроссплатформенное. Посоветуйте, пожалуйста.
Если без легаси можно было бы, то все взаимодействие между сервисами делать через брокер сообщений. То есть на подписку на сообщения или отсылку их.
Но так как у тебя легаси, тут вопрос не архитектуры, а развертывания. Можно развернуть все на облаке в docker контейнерах. А местоположение куда что слать реализовать через API оркестратора этих контейнеров. Например я сейчас подобную проблему через kubernates пытаюсь сделать. Все развертывание делаю на kubernates кластере, едином для всего. На этой платформе у меня есть другие кластеры, объединенные например через hazelcast. Ну а hazelcast сконфигурил таким образом, чтоб он IP нод, которые он будет объединять, узнавал через Kubernates API. Почти доделал уже .
Здравствуйте, elmal, Вы писали:
E>Но так как у тебя легаси, тут вопрос не архитектуры, а развертывания. Можно развернуть все на облаке в docker контейнерах.
Похоже, самого главного я не указал. У меня коробочный продукт. Поэтому и столько возни с развертыванием. Ни облако, ни docker, тут особо не помогают.
Здравствуйте, sr_dev, Вы писали:
_>На практике так и не дотянулся (пока), но вроде как именно для таких задач есть Enterprise service bus
Нет. ESB это транспортный узел связи. Да, он частично решает и мою проблему. Но у нас транспорт уже реализован.
Здравствуйте, scf, Вы писали:
scf>- каждое приложение при старте регистрируется в консуле раз в 10 секунд отправляет в localhost:8500 (локальный консул) healthcheck с TTL 15 секунд. Если приложение остановить, его запись в консуле "протухнет" через 15 секунд.
Это уже всё реализовано в клиентском коде?
scf>edit: а вот для клиентского приложения адрес сервера лучше всего раздавать через DNS, ну или намутить проксирующий nginx c автообновлением конфига из консула.
Почему? Надобность крутить DNS у клиентов только усложняет деплоймент. У нас коробочный продукт. Прошу прощения, если сразу не указал.
Здравствуйте, andrey.desman, Вы писали:
AD>Можно взять кусок оттуда, а именно SSDP (Simple Service Discovery Protocol).
Да, после ресёрча я именно у этому склоняюсь. Но хотел посоветоваться. Вроде как, микросервисы популярый базворд. Может кто-то разбирался.
Здравствуйте, Blazkowicz, Вы писали:
B>Похоже, самого главного я не указал. У меня коробочный продукт. Поэтому и столько возни с развертыванием. Ни облако, ни docker, тут особо не помогают.
У меня тоже коробочный . При этом облако интранетовское. Соответственно нужно на нужные ноды поставить соответствующий оркестратор и докер, настроить это как нужно. У меня админы за неделю справились . И далее это развертывается на раз два и прекрасно мониторится. Как доделаю наконец, будет полный фен шуй .
Здравствуйте, Blazkowicz, Вы писали:
B>Это уже всё реализовано в клиентском коде?
Нет, но реализовывать все равно придется, т.к. именно приложение должно сообщать о себе в service discovery. Другие варианты а-ля централизованный каталог сервисов требует больше времени на обслуживание. Реализация проста, у консула есть REST API.
Впрочем, если у вас не облако (все сервера надежны, приложения деплоятся по одному, а не кластером) и не пугает поддержка каталога, можно просто захостить XML с каталогом сервисов на одной из машин по HTTP и вытягивать его из других приложений.
B>Почему? Надобность крутить DNS у клиентов только усложняет деплоймент. У нас коробочный продукт. Прошу прощения, если сразу не указал.
Тем более, только крутить не у клиентов, а у себя . Схема примерно такая: DNS указывает на 1-2 машины с nginx, а они перенаправляют запросы на нужный бэкенд. Простой и надежный способ обеспечить аптайм и возможность реконфигурации бэкенда. Прослойка в виде nginx нужна, т.к. изменения в DNS применяются не сразу + при балансировке частенько нужно более сложное поведение, чем простой DNS round-robin.
Здравствуйте, elmal, Вы писали:
E>У меня тоже коробочный . При этом облако интранетовское. Соответственно нужно на нужные ноды поставить соответствующий оркестратор и докер, настроить это как нужно. У меня админы за неделю справились . И далее это развертывается на раз два и прекрасно мониторится. Как доделаю наконец, будет полный фен шуй .
Не в службу, а в дружбу... Можешь небольшую статью написать по этому поводу тут, например? Было бы архиполезно почитать про что-то подобное.
Здравствуйте, Blazkowicz, Вы писали:
AD>>Можно взять кусок оттуда, а именно SSDP (Simple Service Discovery Protocol). B>Да, после ресёрча я именно у этому склоняюсь. Но хотел посоветоваться. Вроде как, микросервисы популярый базворд. Может кто-то разбирался.
Хочу напомнить, что UPnP, SSDP и т.п. используют мултикасты. И если сеть в вашей конторе разбита на подсети связанные роутерам, мултикасты из одной подсети вряд ли будут попадать в другую подсеть.
Здравствуйте, Kernan, Вы писали:
K>Не в службу, а в дружбу... Можешь небольшую статью написать по этому поводу тут, например? Было бы архиполезно почитать про что-то подобное.
Сильно лень . Хоть и пилотный кластерный проект удалось запустить со всем этим, но пока это больше эксперимент, у меня даже нужного количества нод нет для кластера.
Если и созрею на статью, это когда проект посерьезнее получится запустить, и когда все таки удастся всю контору на это пересадить. Чтоб был нормальный уровень компетенции у меня, учитывая текущий уровень бюрократии на согласование задач, несколько лет еще потребуется, хотя б пилот удалось нормально запустить.
Собственно и инете до черта инфы по этому делу. В основном рассчитано на готовые развернутые облака. В моем случае все отличия — облако развертывали сами. Развертывал не я, я себе на машине сначала поставил для экспериментов, потом дал админам ссылки как и что ставить и сказал какие машины объединить в кластер. Потом начал развертывать уже не на локальном компе, а на кластере — немного огреб, ибо там виртуальные ip контейнеров оказались в разных сетях, и hazelcast ни хрена не нашел автоматом, у меня получилось не распределенное приложение, а n приложений независимых, выполняющих одно и тоже, и не в состоянии загрузить данные, ибо они не влезали в оперативку . Но погуглив нашел решение, и через kubernetes api узнавал при старте список нод, на котором приложение развернуто, и эти ip кормил hazelcast явно — таким образом заработало. У hazelcast кстати поддержка — я просто в восторге, отвечают практически мгновенно прям в чате, если какая проблема — говорят где в коде посмотреть отладчиком, причем отвечают сами разработчики.
Вроде можно было попробовать для того же самого mesos использовать, но показалось что kubernetes попроще будет для развертывания и там больше из коробки есть. Каких то принципиальных косяков у kubernetes не нашел, хоть и на баги напарывался. Не очень мне правда понятно как обновление самого kubernetes делать чтоб все к чертям не слетело, но это дело будущего.
Здравствуйте, Pzz, Вы писали:
Pzz>Хочу напомнить, что UPnP, SSDP и т.п. используют мултикасты. И если сеть в вашей конторе разбита на подсети связанные роутерам, мултикасты из одной подсети вряд ли будут попадать в другую подсеть.
Да, я в курсе. Спасибо.
, лучше он или хуже. Я ковырялся с SSDP, все девайсы у меня в домашней сети откликаются — роутер (старый и новый), NAS, компы. Не знаю, есть ли у всего этого хозяйства поддержка ZeroConf и подобного.
.
